| Oracle® Database 2日でReal Application Clustersガイド 11gリリース2(11.2) B56291-07 |
|
 前 |
 次 |
ワークロード管理を使用すると、ワークロードを複数のデータベース・インスタンスに分散し、ユーザーおよびアプリケーションに対するデータベースおよびクラスタのパフォーマンスを最適化できます。この章の内容は次のとおりです。
クラスタ・データベースを使用するアプリケーションでは、通常、クラスタ間でのワークロードのロード・バランスが必要です。Oracle Real Application Clusters(Oracle RAC)には、Oracle RACとカスタム・エンタープライズ・アプリケーションの間に必要なサービスおよび統合点を提供する高可用性(HA)アプリケーション・フレームワークが含まれます。
Oracle RACデータベース環境およびシングル・インスタンスのOracle Database環境をデプロイして、ワークロード管理機能を様々な方法で使用できます。ノード数および使用環境の複雑さと使用目的によって異なりますが、最適なワークロード管理および高可用性構成は、この章で説明する様々な考慮事項を検討して決定してください。
Oracle RACデータベースのワークロード管理を実装する際は、複数の異なる機能を使用できます。この項の内容は次のとおりです。
Oracle Database 10gでは、データベース・サービスと呼ばれる自動ワークロード管理機能が導入されました。データベース・サービス(サービス)は、Oracle Databaseでワークロードを管理するための論理的な抽象概念です。サービスは、ワークロードを互いに共通の要素を持たないグループに分割します。各サービスは、一般的な属性、サービス・レベルしきい値および優先度でワークロードを表します。
単一のサービスで、1つのアプリケーション、複数のアプリケーション、または1つのアプリケーションのサブセットを表すことができます。たとえば、Oracle E-Business Suiteでは、総勘定元帳、売掛金勘定、受注など、職務ごとにサービスを定義します。単一のサービスをOracle RACデータベースの1つ以上のインスタンスに関連付けると、単一のインスタンスで複数のサービスをサポートできます。
|
注意: データベース・サービスは、単一のネットワーク上でのみ提供できます。 |
サービスには、次のメリットがあります。
同じリソースについて競合するアプリケーションを管理するための単一のエンティティ
各ワークロードが1つのユニットとして管理可能になること
クラスタの複雑性をクライアントから隠すことができること
ワークロードを管理するために、特定のアプリケーションまたはアプリケーションの一部の操作に割り当てるサービスを定義できます。サービスを使用して、異なるタイプの作業のワークロードを管理することもできます。たとえば、オンライン・ユーザー、バッチ処理、レポートは、それぞれ異なるサービスを使用できます。
従来、Oracle Databaseでは単一のサービスを提供し、すべてのユーザーはその同じサービスに接続していました。データベースには、このデフォルトのデータベース・サービスが、データベース名で常に存在します。このサービスは変更不能であり、これにより、データベースへの接続が常に可能となります。
ユーザーまたはアプリケーションがデータベースに接続するときには、接続用のサービスを使用することをお薦めします。Oracle Databaseでは、データベースの作成時にデータベース・サービスが自動的に1つ作成されます。ほとんどのインストール環境では、このサービスのみで十分です。データベースを使用してワークロードをより柔軟に管理する場合は、複数のサービスを作成し、どのデータベース・インスタンスでサービスを提供するかを指定できます。
|
注意: デフォルトでは、指定されたユーザーがサーバー・プールを作成できます。この権限を持つオペレーティング・システム・ユーザーを制限するには、特定のユーザーをCRS管理者のリストに追加することをお薦めします。CRS管理者のリストへのユーザーの追加の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
ポリシー管理および管理者管理の両方のデータベース用にサービスを定義できます。
ポリシー管理データベース: ポリシー管理データベースのサービスを定義する場合は、データベースが実行されているサーバー・プールにサービスを割り当てます。サービスは、均一(サーバー・プール内のすべてのインスタンスで実行)またはシングルトン(サーバー・プール内の1つのみのインスタンスで実行)のいずれかとして定義できます。
管理者管理データベース: 管理者管理データベースのサービスを定義する場合、どのインスタンスが通常そのサービスをサポートするかを定義します。これらはPREFERREDインスタンスと呼ばれます。優先インスタンスに障害が発生したときにサービスをサポートする他のインスタンスを定義することもできます。これらはAVAILABLEインスタンスと呼ばれます。
サービスはデータベース・リソース・マネージャに統合されており、データベース・リソース・マネージャでは、インスタンス内のサービスで使用されるリソースを制限できます。また、Oracle Schedulerのジョブは、特定のインスタンスではなく、サービスを使用して実行できます。
サービスの優先インスタンスを指定した場合、通常の処理では、そのサービスは優先インスタンスで稼働します。Oracle Clusterwareは、サービスがそのサービス用に構成されたすべての優先インスタンスで常に稼働している状態を維持しようとします。インスタンスに障害が発生すると、そのサービスは使用可能インスタンスに再配置されます。また、サービスを使用可能インスタンスに手動で再配置することもできます。
サービスが使用可能インスタンスにフェイルオーバーした場合、そのサービスが優先インスタンスに自動的に戻ることはありません。ただし、コールアウトを使用すると、優先インスタンスへのサービスの再配置を自動化できます。コールアウトの詳細は、「FANコールアウトの概要」を参照してください。優先インスタンスにサービスを再配置するコールアウト・スクリプトの例は、Oracle Technology Network (http://www.oracle.com/technetwork/database/enterprise-edition/twpracwkldmgmt-132994.pdf)で入手できます。
サービスに使用可能インスタンスを指定する必要はありません。サービスの作成時に優先インスタンスまたは使用可能インスタンスを指定しない場合、デフォルトでOracle RACデータベースのすべてのインスタンスがそのサービスの優先インスタンスになります。ただし、サービスの優先インスタンスを構成する際にそのサービスに対して使用可能インスタンスを1つ以上指定しない場合、優先インスタンスが失敗してもサービスは他のインスタンスに再配置されません。
「未使用」としてインスタンスを指定することもできます。この設定により、サービスの優先インスタンスが失敗しても、そのサービスはインスタンスで稼働しません。
均一サービスを指定すると、Oracle Clusterwareは、指定されたサーバー・プールのすべての使用可能インスタンスで常にサービスが実行されるようにします。インスタンスが失敗すると、サービスは、そのインスタンスで利用できなくなります。サーバー・プールのカーディナリティが増加し、インスタンスがデータベースに追加されると、新しいインスタンスでサービスが開始されます。サービスを特定のインスタンスに手動で再配置することはできません。
シングルトン・サービスを指定すると、Oracle Clusterwareは、指定されたサーバー・プールの使用可能インスタンスの1つのみで常にサービスが実行されるようにします。インスタンスが失敗すると、サービスは、サーバー・プール内の別のインスタンスにフェイルオーバーします。サーバー・プール内のどのインスタンスでサービスを実行させるかは指定できません。
シングルトン・サービスの場合、新しいインスタンスにフェイルオーバーしたサービスは、元のインスタンスが再び使用可能になっても、そのインスタンスに戻ることはありません。
サービスを定義する場合に、そのサービスの管理ポリシーを定義することもできます。自動または手動の管理ポリシーを選択できます。
自動: データベースの起動時に、常に、サービスが開始されます。
|
注意: 管理者管理データベースで自動サービスを使用すると、計画されたデータベースの起動中に、サービスは優先インスタンスではなく使用可能インスタンスになる最初のインスタンスで開始される場合があります。 |
手動: データベースの起動後、ユーザーが手動でサービスを開始する必要があります。Oracle Database 11 gリリース2(11.2)より前の場合、すべてのサービスは、手動管理ポリシーで定義されたように動作していました。
データベース・リソース・マネージャはデータベース機能の1つであり、これを使用すると、ユーザー、アプリケーションおよびサービスに割り当てられたデータベース・リソースを制御できます。このアプローチにより、ユーザー、アプリケーションおよびサービスは使用可能な分のデータベース・リソースを確実に受け取れます。データベース・リソース・マネージャを使用すると、1つ以上のノードで実行されるOracle RACデータベースで、複数のアプリケーションおよび混合ワークロードを効率的にサポートできます。
データベース・リソース・マネージャには、Oracle DatabaseまたはOracle RAC環境内の作業に優先度を設定する機能があります。たとえば、オンライン・ワーカーなどの優先度の高いユーザーに多くのリソースを割り当ててレスポンス時間を最短に抑え、バッチ・ジョブやレポートなどの優先度の低いユーザーには割り当てるリソースの量を抑えて実行時間を長くできます。この方法では、リソースをより細かく制御できます。
リソースは、データベース管理者が指定したリソース・プランに従ってユーザーに割り当てられます。リソース・プランの指定には、次の用語が使用されます。
リソース・プランでは、リソースを各種ユーザー(リソース・コンシューマ・グループ)間で分散する方法を指定します。
リソース・コンシューマ・グループを使用すると、管理者は、ユーザー・セッションをリソース要件別にグループ化できます。リソース・コンシューマ・グループはユーザー・ロールとは異なり、1データベース・ユーザーに対して、異なるリソース・コンシューマ・グループに割り当てられている異なる複数のセッションを指定できます。
リソース割当てメソッドは、データベース・リソース・マネージャで特定のリソースを割り当てる際に使用するメソッドまたはポリシーです。リソース割当てメソッドは、リソース・コンシューマ・グループおよびリソース・プランで使用されます。データベースには使用可能なリソース割当てメソッドが用意されていますが、どのメソッドを使用するかはDBAが決定します。
リソース・プラン・ディレクティブは、特定のプランにコンシューマ・グループを割り当て、リソース割当てメソッドごとにパラメータを指定してコンシューマ・グループ間でリソースをパーティション化する方法です。
DBAによってリソース・プラン内に作成可能なサブプランにより、アプリケーションの複数のユーザー間でリソースをさらに分散できます。
レベルは、使用可能なユーザー間での未使用リソースの分散を指定するメカニズムです。最大で8レベルのリソース割当てを指定できます。
サービスを使用して接続するユーザーは特定のリソース・コンシューマ・グループのメンバーであるため、データベース・リソース・マネージャによってリソース・コンシューマ・グループをサービスにマップできます。したがってリソース・コンシューマ・グループに対して使用可能なリソースを制限できます。
Oracle Enterprise Managerを使用したデータベース・リソース・マネージャの管理についてさらに学ぶには、次の手順を実行します。
「データベース: ホーム」ページにアクセスします。
ページの上部で、「サーバー」をクリックし、「サーバー」ページを表示します。
「リソース・マネージャ」セクションで「スタート・ガイド」をクリックします。
Oracle RACの高可用性フレームワークを使用すると、実行中の状態にあるデータベース、コンポーネントおよびアプリケーションを常にOracle RACで管理できます。インスタンス、コンポーネントまたはアプリケーションに障害が発生しても自動的に再起動できるため、Oracle Databaseの動作を最適な状態に保つことができます。
Oracle Databaseはサービスの可用性の維持に重点を置いています。Oracle RACでは、Oracleサービスは1つ以上のインスタンスでワークロードを共有し、継続的に使用できるように設計されています。Oracle RACの高可用性フレームワークでは、各サービスの構成情報をOracle Cluster Registry(OCR)に格納することでサービスの可用性が維持されます。Oracle Clusterwareは、サービス定義に基づいて複数のインスタンス間でサービスのリカバリおよび調整を行います。
高可用性アプリケーションの主要な要件の1つとして、システムの重要なコンポーネントに問題が発生した場合に、迅速にアプリケーションへの通知が行われることがあげられます。これにより、アプリケーションでイベント処理プログラムを実行できます。そのようなプログラムを即時に実行することによって、コストのかかる接続のタイムアウトおよびアプリケーションのタイムアウトを回避し、クラスタのリソース構成の処理にかかる時間およびクラスタ・コンポーネントの障害の影響を最小化します。
高速アプリケーション通知は、Oracle RACで他のプロセスにクラスタ構成およびサービス・レベルの情報を通知するために使用される通知メカニズムであり、この情報としてはUPイベントやDOWNイベントなどのステータスの変更が含まれます。FANのUPイベントおよびDOWNイベントは、インスタンス、サービスおよびノードに適用できます。FANでは、ロード・バランシング・アドバイザのイベントもパブリッシュされます。
FANを使用すると、クラスタ・コンポーネントに障害が発生したときのアプリケーションの自動リカバリが可能となります。クラスタ構成の変更に対しては、Oracle RACの高可用性フレームワークにより、クラスタ内のインスタンスの状態に関して変更が発生すると同時にFANイベントがパブリッシュされます。アプリケーションは、データベースの問合せと問題の検出を待たずに、FANイベントを受信して即時に対応できます。
FANのUPおよびDOWNイベントには、次のメリットがあります。
DOWNイベントでは、障害が発生したインスタンスまたはノードに接続されているセッションを終了できるため、アプリケーションの中断を最小限に抑えることができます。未完了のトランザクションを終了でき、アプリケーション・ユーザーは即時に通知されます。接続をリクエストしているアプリケーション・ユーザーは、リクエストされたサービスを提供している起動済のインスタンスに送られます。
UPイベントでは、サービスおよびインスタンスが起動されている場合、アプリケーションが追加のリソースを即時に利用できるように、新しい接続を作成できます。
Oracle ClusterwareおよびOracle RACでは、Oracle Notification Services(ONS)を使用してOracleクラスタ内およびクライアント(または中間層マシン)の両方に対してFANメッセージを伝播します。ONSはOracle RACとともにインストールされ、ONSデーモンを管理するOracle Clusterwareリソースがインストール・プロセス中に自動的に作成されます。ONSデーモンはローカルに実行され、構成リストの(他のONSデーモンがアクティブとなっている)ノードとの間でメッセージを送受信します。
FANコールアウトは、高可用性イベントの発生と同時にOracle RACによって実行されるサーバー側の実行可能ファイルです。コールアウトは基本的にシェル・スクリプトであるか、またはなんらかのプログラム言語で書かれてプリコンパイルされた実行可能ファイルです。クラスタ構成でのイベントの発生時に実行されるアクションを、FANコールアウトを使用して自動化する例を次に示します。
サーバー側のアプリケーションの起動および停止
優先度の高いサービスがオンラインになった場合の優先度の低いサービスの再配置
ページャへのテキストまたは数値メッセージの送信
シェル・スクリプトの実行
FANコールアウトの実行可能ファイルは、Grid_home/racg/usrcoサブディレクトリに格納されます。このサブディレクトリがGridホームにない場合は、Grid_home/racg/tmpサブディレクトリと同じ権限および所有権でこのディレクトリを作成する必要があります。
ONSからFANイベントを受信すると、Grid_home/racg/usrcoサブディレクトリのすべての実行可能ファイルは非同期処理で即時に実行されます。Oracle Clusterwareを実行するすべてのノードに、FANコールアウトで使用される実行可能ファイルのコピーを用意しておく必要があります。コールアウト・スクリプトの例は、Oracle Technology Network(http://www.oracle.com/technetwork/database/enterprise-edition/twpracwkldmgmt-132994.pdf)で入手できます。
|
参照:
|
ロード・バランシング・アドバイザは、Oracle RACデータベース・インスタンスが提供している現在のサービス・レベルの情報をアプリケーションやクライアントに提供します。アプリケーションでは、サービスに定義されたワークロード管理ディレクティブに基いて最高のパフォーマンスが達成されるように、ロード・バランシングの高速アプリケーション通知(FAN)イベントを利用してクラスタ内のインスタンスにリクエストを送信できます。また、インスタンスが再起動すると、最近起動したインスタンスへの接続が接続プールによって作成され、このインスタンスが提供する追加のリソースが利用されるため、Oracle RACではFANを使用してアプリケーションの接続プールを通知します。
ロード・バランシング・アドバイザはOracle Database 11gに組み込まれた自動ワークロード・リポジトリと統合されています。自動ワークロード・リポジトリは、各サービスについて応答時間とCPU消費を測定します。
ロード・バランシング・アドバイザによって示されるアドバイスでは、サーバーの処理能力およびサーバー上のサービスの現在のワークロードが考慮されます。ロード・バランシング・アドバイザを有効にすることにより、負荷が高いインスタンス、動作が遅いインスタンス、応答がないインスタンス、または障害が発生しているインスタンスで作業を行わないことによって、アプリケーションのスループットを向上させることができます。
ランタイム接続ロード・バランシング機能を備えた統合Oracleクライアントを使用すれば、プログラムを修正せずに、アプリケーションでロード・バランシング・アドバイザを利用できます。FANとの統合によって、Oracle統合クライアントでは、Oracleクラスタの現在のステータスをより迅速に認識します。これにより、クライアント接続が、使用できなくなったインスタンスへの接続を試みたり、それを待機することを防げます。FANイベントに対応する統合クライアントには、Oracle Database 11g JDBC、Oracle Database 11g ODP.NETおよびOracle Database 11g Oracle Call Interface(OCI)が含まれます。
使用されている各サービスにサービス・レベル目標を定義して、ロード・バランシング・アドバイザを使用するようにOracle RAC環境を構成できます。サービス・レベル目標を定義することで、そのサービスのロード・バランシング・アドバイザが有効になり、FANロード・バランシング・イベントの発行が有効になります。ランタイム接続ロード・バランシングにおけるサービスレベルの目標値には、次の2つのタイプがあります。
サービス時間: ロード・バランシング・アドバイザでは、インスタンスに対する作業リクエストの送信を、そのインスタンスのレスポンス時間に応じて試行します。ロード・バランシング・アドバイザのデータは、そのサービスを使用した接続で作業が完了するまでの経過時間と、そのサービスに到達するまでに使用できるバンド幅に基づいています。この目標は、インターネットのショッピング・システムなどの、完了までにかかる時間が変動するワークロードに最適です。
スループット: ロード・バランシング・アドバイザでは、サービスに対してCPUで消費される合計レスポンス時間の割合が測定されます。この値からは、レスポンス時間ではなくインスタンスの効率性がわかります。この目標はトレーディング・システムなどの、各作業リクエストがほぼ同じ時間内に完了する必要のあるワークロードに最適です。
「ロード・バランシング・アドバイザの有効化」オプションを選択していない場合は、サービス・レベルの目標値が「なし」に設定され、そのサービスに対するロード・バランシングが無効になります。
|
参照:
|
Oracle Netは、クライアントおよびOracle Databaseサーバー上に存在するソフトウェア・コンポーネントです。このコンポーネントは、クライアント・アプリケーションとサーバー間の接続を確立して維持し、業界標準プロトコルを使用してクライアントとサーバー間でメッセージを交換します。クライアント・アプリケーションとデータベースが通信するには、クライアント・アプリケーションが接続先のデータベースの場所の詳細を指定し、データベースがIDまたはアドレスなどを示す必要があります。
データベース・サーバー上には、Oracle Netリスナーが存在し、これは通常リスナーと呼ばれます。リスナーは、クライアント接続リクエストをリスニングするプロセスです。リスナーの構成ファイルはlistener.oraです。
Oracle Database 11gのデータベース・クライアントでは、データベースとの接続にSCANおよび簡易接続メソッドを使用します。SCANは、パブリック・クライアント接続を処理するクラスタ内の複数のリスナーに対応する、複数のIPアドレスに解決できます。簡易接続メソッドを使用すると、すべてのクライアント・ネットワーク・ファイルを構成する必要がありません。接続識別子は、次の形式で簡単に指定できます。
SCAN[:port]/service_name
SCANはクラスタのSCANです。TCPポート識別子の指定はオプションです。service_nameはデータベース・サービス名です。
Net Configuration Assistant(NETCA)を使用して、データベース・サービスの単純な名前であるネット・サービス名を作成することもできます。ネット・サービス名は、データベースのネットワーク・アドレスおよびデータベース・サービスの名前を表す接続記述子に変換されます。接続記述子のアドレスの一部は実際にリスナーのプロトコル・アドレスです。 クライアントは接続記述子を使用して、クライアントが接続するデータベースまたはインスタンスを指定します。
ネット・サービス名を使用する場合は、最初にネット・サービス名を接続記述子にマッピングした際に、データベース・インスタンスへの接続が確立されます。このマッピング情報は、ネーミング・メソッドを使用してアクセスされた1つ以上の情報リポジトリに格納されます。最もよく使用されるネーミング・メソッドはローカル・ネーミングであり、これを使用すると、ネット・サービス名および接続記述子はtnsnames.oraというローカライズ済の構成ファイルに格納されます。
クライアントがサービスを使用してクラスタ・データベースに接続する場合に、Oracle Netの接続ロード・バランシング機能を使用して、そのサービスをサポートするすべてのインスタンス間でユーザー接続を分散できます。実装可能なロード・バランシングには、クライアント側とサーバー側の2種類のロード・バランシングがあります。Oracle RACデータベースのクライアント接続では、両方のタイプの接続ロード・バランシングを使用する必要があります。Oracle Database Configuration Assistant(DBCA)を使用してOracle RACデータベースを作成した場合、デフォルトでは、サーバー側のロード・バランシングが構成されて有効化されます。
クライアント側のロード・バランシングでは、接続リクエストをリスナー間で均等に分散します。リスナーは、接続リクエストを受信すると、リクエストされたサービスを提供することをリスナーが認識するインスタンスにユーザーを接続します。
クライアント側のロード・バランシングは、tnsnames.oraファイルにパラメータLOAD_BALANCE=yesを設定して、クライアントの接続定義に定義します。このパラメータをyesに設定すると、Oracleクライアントはアドレス・リストから無作為にアドレスを選択し、そのノードのリスナーに接続します。その結果、クラスタ内の使用可能なリスナー間で、クライアント接続が均等に分散されます。
DBCAを使用してOracle RACデータベースを作成する場合、アシスタントでは、tnsnames.oraファイルにロード・バランシング接続定義のサンプルが作成されます。
クライアント側のロード・バランシングには、接続フェイルオーバーが含まれます。接続フェイルオーバーを使用すると、選択したアドレスからエラーが返された場合にOracle Net Servicesによってアドレス・リストにある次のアドレスが試され、これは接続に成功するか、アドレス・リストにあるすべてのアドレスが試されるまで続けられます。
サーバー側のロード・バランシングでは、ロード・バランシング・アドバイザからの情報を使用して、リスナーにより、現在サービスを提供している最適なインスタンスに接続リクエストが転送されます。
各サービスに対して、接続ロード・バランシングの目標を設定し、リスナーでのロード・バランシングの使用方法を定義できます。接続ロード・バランシングには、長期または短期のいずれかの目標を使用できます。これらの目標の特性は次のとおりです。
短期: サービスの使用時間に基づいて、複数のインスタンスに接続が分散されます。短期の接続ロード・バランシングの目標は、短期間の接続を行うアプリケーションに使用します。
長期: サービスをサポートする各インスタンスにおいて、インスタンスごとのセッション数に基づいて接続が分散されます。長期の接続ロード・バランシングの目標は、長期間の接続を行うアプリケーションに使用します。これは通常、接続プールやSQL*Formsセッションで使用されます。長期の目標は、デフォルトの接続ロード・バランシングの目標です。
DBCAを使用して作成されたサービスでは、長期の接続ロード・バランシングの目標がデフォルトで使用されます。
|
注意: データベースの作成にDBCAを使用しなかった場合、またはデフォルトの1521以外のリスナー・ポートを使用している場合は、SCAN:portを指すようにクラスタ・データベースのLOCAL_LISTENERおよびREMOTE_LISTENERデータベース初期化パラメータを構成する必要があります。 |
ランタイム接続ロード・バランシングはOracle接続プールの機能の1つであり、これを使用すると、ロード・バランシング・アドバイザの情報に基づいて、クライアントの作業リクエストをOracle RACデータベースのインスタンス間で分散させることができます。接続は、ロード・バランシング・アドバイザのFANイベントに従って、データベース・インスタンスにより提供される現在のパフォーマンス・レベルに基づいて割り当てられます。これによって、最初のデータベース接続時のロード・バランシングではなく、トランザクション・レベルでのロード・バランシングが実現します。
ランタイム接続ロード・バランシングでは、高いパフォーマンスを実現するために、アプリケーションがロード・バランシング・アドバイザの情報を使用します。OCIセッション・プールおよびODP .NET接続は、ランタイム接続ロード・バランシングをサポートします。Javaアプリケーションに対しては、ユニバーサル接続プール(UCP)をお薦めします。ユニバーサル接続プールは、ロード・バランシング・アドバイザの情報を活用するように統合されています。Oracle Database 11gパッチ・セット1(11.1.0.7)で導入されたUCPは、Oracle Database 10gまたはOracle Database 11gに対して使用可能です。
次のような構成のサービスで、ランタイム接続ロード・バランシングに対してクライアント・データ・ソースを有効にする必要があります。
ロード・バランシング・アドバイザが有効にされ、サービス・レベル目標が「サービス時間」または「スループット」のいずれかに設定されている。
サービスの接続ロード・バランシング目標が「短い」に設定されている。
図7-1「ランタイム接続ロード・バランシング」は、ランタイム接続ロード・バランシングを説明したものです。この図では、Oracle RACデータベースに3つのインスタンスがあります。ここで、インスタンス1およびインスタンス3のパフォーマンスは最適であり、インスタンス2のパフォーマンスは現在は最適ではないとロード・バランシング・アドバイザで示されているとします。暗黙的な接続キャッシュでランタイム接続ロード・バランシングが有効になっている場合、次のプロセスが発生します。
クライアントが接続プールからの接続をリクエストします。
ランタイム接続ロード・バランシングにより、最も効率的な(最適な)インスタンスに属する接続が接続プールから選択されます。図7-1では、接続のルーティング先となるノードが3つ存在します。CPUワークロードが最も少ないインスタンス1には、現在、着信接続の約60パーセントが割り当てられています。現在過負荷の状態にあるインスタンス2には、着信接続の約10パーセントしか割り当てられていません。ワークロードの高いインスタンス3には、着信接続の約30パーセントが割り当てられています。この場合、接続リクエストの処理に最適なインスタンスは、インスタンス1です。
作業リクエストを最短のレスポンス時間で処理する接続をクライアントが受信します。
Oracle Database 11gでは、ロード・バランシング・アドバイザのイベントに、アフィニティ・ヒントというフラグが導入されました。アフィニティ・ヒントはサービスに目標を設定してロード・バランシング・アドバイザをオンにすると自動化されます。このフラグはWebセッションの継続期間中の一時アフィニティとなります。Webでの対話は、セッション全体の間に接続と切断を頻繁に繰り返します。これらの接続ではそれぞれ、ショッピング・カート、Siebelなど、同じデータまたはほぼ同じデータにアクセスする可能性があります。アフィニティによってバッファのキャッシュ効率が向上し、CPU使用率およびトランザクションの遅延が減少します。アフィニティ・ヒントとは、インスタンスとサービスの特定の組合せに対して、アフィニティがアクティブであるか非アクティブであるかを示すフラグのことです。同じサービスを提供する別のインスタンスで、アフィニティ・ヒントを異なる設定にすることができます。
Oracle Database 11gおよびUCPを使用するアプリケーションは、この新たなアフィニティ機能を活用できます。アフィニティ・フラグをロード・バランシング・アドバイザのイベントでオンにすると、UCPはWebセッション用のアフィニティ・コンテキストを作成します。この際、セッションはプールから接続し、そのプールは常に最初にセッションを取得したインスタンスに対して接続を試みます。最初に接続するインスタンスは、現在のロード・バランシング情報に基づいて選択します。
ワークロードを管理するために、特定のアプリケーションまたはアプリケーションの一部の操作に割り当てるサービスを定義できます。サービスを使用して、異なるタイプの作業のワークロードを管理することもできます。Oracle Enterprise Manager Database Controlを使用してサービスを作成できます。
サービスを作成するには、次の手順を実行します。
「クラスタ・データベース: ホーム」ページで「可用性」をクリックします。
「可用性」ページが表示されます。
「サービス」セクションで「クラスタ管理データベース・サービス」をクリックします。Oracle RACデータベースおよびホストのオペレーティング・システムに対する資格証明を入力または確認し、「続行」をクリックします。
「クラスタ管理データベース・サービス」ページが表示されます。
「サービスの作成」をクリックします。
「サービスの作成」ページが表示されます。
「サービス名」フィールドに、サービスの名前(DEVUSERSなど)を入力します。
サービスを作成した後でそれを開始するには、「作成後にサービスを開始」を選択します。Database Controlで新規サービスをローカルのOracle Net Servicesのtnsnames.oraファイルに追加する場合、「ローカル・ネーミング・パラメータ(tnsnames.ora)ファイルの更新」を選択します。
(ポリシー管理データベースの場合のみ)サービス・タイプに均一またはシングルトンを選択します。
(管理者管理データベースの場合のみ)インスタンスごとに、優先インスタンスであるか、または使用可能インスタンスであるかを選択します。どのような状況でもインスタンスでサービスを実行しない場合は、そのインスタンスの「サービス・ポリシー」に「未使用」を設定します。
接続数の合計ではなく、経過時間に基づいて接続ワークロードを分散させるには、「サービス・プロパティ」セクションの「接続ロード・バランシングの目標」で「短い」を選択します。それ以外の場合は、「長い」を選択します。
次のスクリーンショットに示すように、「通知プロパティ」サブヘッダーの下の「ロード・バランシング・アドバイザの有効化」を選択し、このサービスのロード・バランシング・アドバイザを有効化します。「サービス時間」または「スループット」のいずれかのサービス・レベルの目標を選択します。
このサービスをOracle Call Interface(OCI)またはODP.NETアプリケーションで使用してFANを有効化する場合、「通知プロパティ」ヘッダーの下の「高速アプリケーション通知の有効化」を選択します。
「サービスしきい値レベル」セクションで、「経過時間」および「CPU時間」メトリックの「警告」および「クリティカル」しきい値(ミリ秒)を入力することにより、サービス・レベルしきい値をオプションで設定できます。
このサービスで使用されるリソースを制御するリソース・プランを使用する場合、「リソース管理プロパティ」セクションの「コンシューマ・グループ・マッピング」リストからコンシューマ・グループの名前を選択します。たとえば、LOW_GROUPというコンシューマ・グループを選択すると、開発ユーザーに与えるデータベース・リソースへの優先度を低くすることができます。
|
注意: 「サービスの編集」ページでは、サービスに対するコンシューマ・グループ名を変更できません。これは、特定のサービスに関連付けられたコンシューマ・グループが複数存在する場合があるためです。ただし、「サービスの編集」ページには、「リソース・コンシューマ・グループ・マッピング」ページへのリンクが含まれており、ここでサービスに対するコンシューマ・グループ・マッピングを変更できます。 |
このサービスが特定のOracle Schedulerジョブ・クラスで使用される場合、「リソース管理プロパティ」の「ジョブ・スケジューラ・マッピング」リストから名前を選択してマッピングを指定できます。
「OK」をクリックして、サービスを作成します。
|
参照:
|
Oracle Enterprise Managerでサービスを作成および管理できます。また、SRVCTLユーティリティを使用すると、大部分のサービス管理タスクを実行できます。
次の項では、クラスタ・データベース用のサービスの管理方法について説明します。
「クラスタ管理データベース・サービス」ページは、サービス関連のすべてのタスクを開始するマスター・ページです。このページにアクセスするには、「クラスタ・データベース: メンテナンス」ページに移動し、「サービス」セクションの「クラスタ管理データベース・サービス」をクリックします。このページとページ内のリンクを使用して、次の操作を実行できます。
クラスタのサービスのリストの表示。
各サービスが現在実行されているインスタンスの表示。
各サービスのステータスの表示。
サービスの作成または編集。
サービスの開始または停止。
サービスの有効化または無効化。
サービスに関するインスタンス・レベルのタスクの実行。
サービスの削除。
Oracle Enterprise Managerを使用してサービスを管理する際に、「クラスタ管理データベース・サービス」ページを使用します。
「クラスタ管理データベース・サービス」ページで、次のタスクを実行できます。
クラスタのサービス、各サービスが現在実行されているインスタンス、各サービスのステータス、サービスに関連付けられたサーバー・プール、サービスの応答性、およびそのサービスのアラートまたはメッセージのリストの表示。
サービスの開始または停止。
サービスの接続テスト、または使用中のOracle Net TNS文字列の表示。
「サービスの作成」ページへのアクセス。
サービスの編集、削除、有効化または無効化。
各サービスに関連付けられたサーバー・プールの「サーバー・プールの編集」ページへのアクセス。
「クラスタ管理データベース・サービス」ページにアクセスするには、次の手順を実行します。
「クラスタ・データベース: ホーム」ページで、「可用性」タブをクリックします。
「可用性」サブページの「サービス」ヘッダーの下で、「クラスタ管理データベース・サービス」をクリックします。
「クラスタ管理データベース・サービス: クラスタおよびデータベースのログイン」ページが表示されます。
データベースの資格証明と、Oracle RACデータベースをホストするクラスタの資格証明を入力して、「続行」をクリックします。
「クラスタ管理データベース・サービス」ページが表示され、そのクラスタ・データベース・インスタンス上で使用可能なサービスが表示されます。
GNSを使用し、クラスタにSCANを構成すると、各クライアントでネットワーク設定を変更する必要がなくなります。この項では、新しいサービスがOracle Netで認識されてデータベース・クライアントから使用可能となっていることを検証する方法を説明します。
クラスタ、データベース、データベース・インスタンス、Oracle Automatic Storage Management(Oracle ASM)およびリスナーの管理にユーティリティを使用する際は、管理対象のオブジェクトやコンポーネントのホーム・ディレクトリにある適切なバイナリを使用し、さらにORACLE_HOME環境変数がこのディレクトリを指すように設定します。たとえば、lsnrctlを使用してデータベース・インスタンスまたはそのリスナーを管理するには、データベース・インスタンスやリスナーが実行されているOracleホームにあるバイナリを使用し、ORACLE_HOME環境変数にはそのOracleホームの場所を設定します。
新規作成されたサービスがOracle Net Servicesでサポートされていることを確認するには、次の手順を実行します。
次のコマンドを使用して、ローカル・ノード上のリスナーによって新しいサービスが認識されるかどうかを確認します。
lsnrctl status LISTENER_SCAN1
次のような新しいサービスのリストが表示されます。
Services Summary... Service "DEVUSERS.example.com" has 2 instance(s). Instance "sales1", status READY, has 1 handler(s) for this service... Instance "sales2", status READY, has 1 handler(s) for this service...
新しく作成したサービスの表示名(DEVUSERS.example.comなど)は、接続文字列内で使用するサービス名です。
SQL*PlusおよびSCANを使用してOracle RACデータベースへの接続を試行することにより、Oracle Net Servicesの構成をテストします。簡易接続ネーミングの接続識別子は、次の形式です。
"[//]SCAN[:port]/service_name"
SCANはクラスタのSCANであり、デフォルトではcluster_name.GNS_sub_domainです。service_nameは、データベースへの接続に使用するデータベース・サービスの名前です。オプションとして、Oracle SCANリスナーが接続をリスニングするTCPポート番号を指定できます。
たとえば、次のコマンドを使用すると、docracクラスタ内にあるOracle RACデータベースのDEVUSERSサービスに接続できます。
$ sqlplus /nolog
SQL> CONNECT system@"docrac/DEVUSERS.example.com"
Enter password: password
パスワードを入力すると、Oracle RACデータベースに正常に接続していることを示すメッセージが表示されます。エラー・メッセージが表示された場合は、接続識別子を調査して、ユーザー名、パスワード、およびサービス名が正しく入力されたか、Oracle RAC環境のすべての情報が正しいかを検証します。
アプリケーション・クライアントのフェイルオーバーを自動化する場合、考慮する主要な要素が2つあります。1つは、新規のデータベース・インスタンスへの接続が試行される前のTCP/IPネットワーク・タイムアウトの待機を避けるために、障害発生時に接続されているクライアントに障害が発生したことを迅速かつ自動で通知する必要があることです(タイムアウトの範囲は8分から2時間の間で、オペレーティング・システムによって異なります)。Oracle RAC構成では、高速アプリケーション通知(FAN)を使用してJDBCクライアント、OCIクライアントおよびODP.NETクライアントに通知します。FANイベント通知およびコールアウトによって、サイトでの障害発生後にクライアントが自動かつ迅速にリダイレクトできます。
2つ目のクライアント・フェイルオーバーの主要な要素は、障害発生後の新規インスタンスへのクライアントのリダイレクトで、これはサービスを使用して実装できます。Oracle RACデータベースでのサービス作成時にサービスを割り当てたインスタンスが使用できなくなった場合、Oracle RACでは、データベースで使用可能なインスタンスにサービスを再配置します。接続リクエストが入るときにどのインスタンスが現在サービスを提供しているかを、リスナー登録を使用してクラスタ内のすべてのリスナーが認識できるようにするために、ユーザーはインスタンスから独立したサービスにアクセスできます。
FANに加え、クライアントは接続リストにある次のアドレスがTCP/IPネットワークのタイムアウトを待つことがないように、時間を制限してサーバーからのレスポンスを待つことができます。タイムアウトの制限を有効にするには、sqlnet.oraパラメータsqlnet.outbound_connection_timeout = xを設定する必要があり、ここでxは最大時間を秒単位で表すため、たとえば3秒間でクライアントがデータベース・インスタンスにOracle Net接続を確立するには次のようにします。
sqlnet.outbound_connection_timeout = 3
|
注意: Oracle Clusterwareの操作に影響する可能性があるため、サーバーのsqlnet.oraファイルのsqlnet.outbound_connection_timeoutパラメータは構成しないようにしてください。 |
この項では、アプリケーション・クライアントのFANを構成します。この項には次のトピックが含まれます。
JDBC接続を使用するアプリケーションでは接続プールを利用できるので、データにアクセスするたびにデータベースへの接続を新しく作成するかわりに、プールの既存の接続を使用できます。Universal Connection Pool(UCP)はJavaベースの接続プールで、すべてのタイプのデータベース(OracleまたはOracle以外)に対する、すべてのタイプの接続(JDBC、LDAP、JCA)をサポートしており、任意の中間層を持っています(OracleまたはOracle以外)。また、TopLinkやBPELといったスタンドアロンのデプロイメントもサポートしています。UCPには、高速接続フェイルオーバー、ランタイム接続ロード・バランシング、ならびにOracle RACインスタンス用の接続アフィニティを含む、Oracle RACといったOracle Databaseの統合機能があります。
高速接続フェイルオーバーがない状態で、ノードが停止しアプリケーションがそのインスタンスに接続を試みると、接続リクエストが数分間ハングしTCPがタイムアウトに達するまで待機することがあります。統合されたFCF機能を持つ接続プールを使用しない場合でも、接続障害通知機能を構成することで、ご使用のアプリケーションでは引き続きOracle RAC高可用性イベントが通知されます。
この項では、Java Database Connectivity(JDBC)クライアントを構成する方法について説明します。
|
注意: 接続障害通知は、UCPで実装された高速接続フェイルオーバーと機能が重複しています。同じアプリケーションで両方を構成しないようにしてください。 |
高速接続フェイルオーバーを構成すると、ユニバーサル接続プールによってFANロード・バランシング・イベントが自動的にサブスクライブされます。接続プールは使用されていない接続を作業リクエストに無作為に割り当てるのではなく、受信した最新の情報に従って、最適なサービスを提供する接続を選択します。ノードがハングすると、接続プールは、ハング・ノードからクラスタ内の別のノードへ徐々に接続を移動します。
高速接続フェイルオーバーのためにJDBCクライアントを構成するには、次の手順を実行します。
Oracle Enterprise Manager Database ControlまたはOracle Enterprise Manager Grid Controlのクラスタ管理サービスに関するページを使用して、新規サービスを作成します。サービスの作成の詳細は、「サービスの作成」を参照してください。
UCP DataSourceプロパティFastConnectionFailoverEnabledをTRUEに設定して、JDBCクライアントの高速接続フェイルオーバーを有効化します。また、次の例に示すように、JDBCクライアントでリモートOracle Notification Services(ONS)サブスクリプションを構成し、クライアントでONSデーモンが必要とされないようにします。
PoolDataSource pds = PoolDataSourceFactory.getPoolDataSource(); Pds.setConnnectionPoolName(”FCFSampleUCP”); pds.setONSConfiguration(”nodes=racnode1:4200,racnode2:4200”); pds.setFastConnectionFailoverEnabled(true); pds.setConnectionFactoryClassName(”oracle.jdbc.pool.OracleDataSource”);
リモートONSサブスクリプションには、クライアント・アプリケーションでフェイルオーバーに使用できるすべてのホストが含まれている必要があります。
oracle.net.ns.SQLnetDef.TCP_CONNTIMEOUT_STRプロパティをデータ・ソース上でゼロ以外の値に設定します。JDBCクライアントがこのプロパティの設定時に、使用できないホストに接続しようとした場合、接続試行はoracle.net.ns.SQLnetDef.TCP_CONNTIMEOUT_STRに対して指定した時間にバインドされます。指定した時間が過ぎても接続に成功しない場合、クライアントはアドレス・リストにある次のホストに接続しようとします。ほとんどのインストールに対して十分なプロパティの設定値は3秒です。
SCANとサービス名を含む接続記述子を使用するよう、JDBCクライアントを構成します。接続記述子には、オプションでSCANリスナーがリスニングするポート番号を含めることができます。次に、例を示します。
@//docrac.example.com:1521/orcl_JDBC
|
注意: 透過アプリケーション・フェイルオーバー(TAF)処理はFAN ONS処理を妨害する可能性があるため、TAFをJDBCクライアントの高速接続フェイルオーバーで構成しないでください。 |
JDBCアプリケーションでは、次のような接続記述子を使用してデータベースに接続します。
pds.setURL("jdbc:oracle:thin:@//docrac.example.com:1521/orcl_JDBC")
JDBCドライバではOracle Netを使用しないため、JDBCドライバを使用する場合は、URLに完全な接続記述子を含む必要があります。
アプリケーションのCLASSPATHにucp.jarおよびons.jarの両方が含まれていることを確認してください。
|
参照:
|
JDBC接続障害通知により、スタンドアロンのOracle JDBC接続はノード障害にすばやく応答できます。この機能により、スタンドアロンの接続は、Oracle RACノードのダウン・イベントをリスニングし、接続を閉じることや、リカバリを迅速に開始してユーザー・アプリケーションを許可することで、ノードのダウン・イベントに対応できます。ノードがダウンした後で、JDBCメソッド・コールがすぐに例外をスローする場合を除き、アプリケーションの動作は変更されません。
接続障害通知を構成するには、ConnectionFailureNotificationプロパティを使用します。
接続障害通知のためにJDBCクライアントを構成するには、次の手順を実行します。
接続障害通知プロパティは、-Dオプションを使用してシステム・プロパティとして設定するか、または接続作成時に接続プロパティの引数に含めることによって設定します。
システム・プロパティとして設定するには、次のようなコマンドを使用します。
java -Doracle.jdbc.ConnectionFailureNotification=true
接続プロパティの引数で設定するには、次のようなコードを使用します。
Properties props = new Properties();
props.put("ConnectionFailureNotification", "true");
Connection = DriverManager.getConnection(url, props);
ノードのダウン・イベントを受信する転送メカニズムを構成します。ONSが転送メカニズムとして選択されている場合、次のコードに示すように、SetONSConfigurationプロパティを使用します。racnode1およびracnode2は、ONSを実行するクラスタ内のノードを示します。
props.setONSConfiguration(”nodes=racnode1:4200,racnode2:4200”);
ons.jarがアプリケーションのCLASSPATHにあることを確認してください。
|
参照:
|
Oracle Call Interface(OCI)によって、FANおよびロード・バランシング・アドバイザ・イベントが統合されます。ロード・バランシング・アドバイザを利用するには、OCIセッション・プールを有効にする必要があります。OCIクライアントはOracle RAC高可用性イベントの発生時に通知を受信して応答するように登録できます。これにより、OCIの接続フェイルオーバーのレスポンス時間が向上し、中断した接続を接続プールおよびセッション・プールから削除できます。この機能はすべてのOCIクライアント・アプリケーションで動作します。
FAN通知を受信するようにOCIクライアントを構成するには、次の手順を実行します。
Oracle Enterprise Manager Database ControlまたはOracle Enterprise Manager Grid Controlのクラスタ管理サービスに関するページを使用して、OCIクライアントのサービスを作成します。サービスの作成の詳細は、「サービスの作成」を参照してください。
サービスに対する優先インスタンスとしてプライマリ・インスタンスを構成する必要があります。「通知プロパティ」で「OCIおよびODP.NETアプリケーションでの高速アプリケーション通知(FAN)の有効化」を選択します。
Oracle Enterprise Managerを使用したサービスの変更の詳細は「サービスの管理」を参照してください。
OCI_EVENTSパラメータで環境を初期化して、OCIクライアントのFANを有効化します。次に例を示します。
OCIEnvCreate(...OCI_EVENTS...)
OCIクライアント・アプリケーションをスレッド・ライブラリlibthreadまたはlibpthreadにリンクします。
次の例のように、イベントが発生したかどうかをアプリケーションでチェックする必要があります。
void evtcallback_fn(ha_ctx, eventhp)
...
printf("HA Event received.\n");
if (OCIHandleAlloc( (dvoid *)envhp, (dvoid **)&errhp, (ub4) OCI_HTYPE_ERROR,
(size_t) 0, (dvoid **) 0))
return;
if (retcode = OCIAttrGet(eventhp, OCT_HTYPE_EVENT, (dvoid *)&srvhp, (ub4 *)0,
OCI_ATTR_HA_SRVFIRST, errhp))
checkerr (errhp, (sword)retcode;
else {
printf("found first server handle.\n");
/*get associated instance name */
if (retcode = OCIAttrGet(srvhp, OCI_HTYPE_SERVER, (dvoid *)&instname,
(ub4 *)&sizep, OCI_ATTR_INSTNAME, errhp))
checkerr (errhp, (sword)retcode);
else
printf("instance name is %s.\n", instname);
HAイベントの受信後、クライアントおよびアプリケーションでは、高可用性イベントが発生するたびに起動するコールバックを登録できます。次に、例を示します。
/*Registering HA callback function */
if (checkerr(errhp, OCIAttrSet(envhp, (ub4) OCI_HTYPE_ENV,
(dvoid *)evtcallback_fn, (ub4) 0,
(ub4)OCI_ATTR_EVTCBK, errhp)))
{
printf("Failed to set register EVENT callback.\n");
return EX_FAILURE;
}
if (checkerr(errhp, OCIAttrSet(envhp, (ub4) OCI_HTYPE_ENV,
(dvoid *)evtctx, (ub4) 0,
(ub4)OCI_ATTR_EVTCTX, errhp)))
{
printf("Failed to set register EVENT callback context.\n");
return EX_FAILURE;
}
return EX_SUCCESS;
イベントのコールバックとコンテキストを登録した後、OCIは高可用性イベントが発生するたびに登録された関数を1回コールします。
|
参照:
|
Oracle Data Provider for .NET(ODP.NET)の接続プールは、サーバーの稼働中または停止中に表示されるOracle RACからのFAN通知をサブスクライブします。これらの通知に基づいて、ODP.NET接続プールはアイドル接続、前回ノードへの接続に失敗した接続、が再び利用可能になります。可能な場合には、正常なノードに対する新しい接続も作成します。
ODP.NETは、ランタイム接続ロード・バランシングを提供しアプリケーション・ワークロードのロード・バランスを拡張します。接続プールから使用可能な接続を無作為に選択するのではなく、現在のワークロード情報に基づいて最適なサービスを提供できる接続を選択します。
ODP.NETを有効化する手順は、FCFの有効化に接続文字列内でのパラメータの設定が必要という点で、JDBCを有効化する手順と似ています。この項では、FANイベントを使用してフェイルオーバーのOracle Data Provider for .NET(ODP.NET)クライアントを構成する方法を説明します。
FAN通知を受信するようにODP.Netクライアントを構成するには、次の手順を実行します。
Oracle Enterprise Manager Database ControlまたはOracle Enterprise Manager Grid Controlのクラスタ管理サービスに関するページを使用して、ODP.NETクライアントのサービスを作成します。サービスの作成の詳細は、「サービスの作成」を参照してください。
「通知プロパティ」で「OCIおよびODP.NETアプリケーションでの高速アプリケーション通知(FAN)の有効化」を選択します。「接続ロード・バランシングの目標」を「長い」に設定します。
FAN高可用性イベントをサブスクライブすることによって、ODP.NET接続プールの高速接続フェイルオーバーを有効にします。このためには、接続時またはデータ・ソース定義中のいずれかでha events接続文字列属性をtrueに設定します。この設定が機能するのは接続プールを使用している場合のみであることに注意してください(pooling属性がtrueの場合のみ)。
ロード・バランシングの接続文字列の属性をtrueに設定して、ランタイム接続ロード・バランシングも有効にできます。
次のようなコードを使用します。ここで、usernameはアプリケーションがデータベースへの接続に使用するデータベース・ユーザーの名前、passwordはそのデータベース・ユーザーのパスワードです。サービス名はodpservです。
// C#
using System;
using Oracle.DataAccess.Client;
class HAEventEnablingSample
{
static void Main()
{
OracleConnection con = new OracleConnection();
// Open a connection using ConnectionString attributes
// Also, enable "load balancing"
con.ConnectionString =
"User Id=username;Password=password;" +
"Data Source=//docrac.example.com/odpserv;" +
"Min Pool Size=10;Connection Lifetime=120;Connection Timeout=60;" +
"HA Events=true;Incr Pool Size=5;Decr Pool Size=2";
con.Open();
// Carry out work against the database here.
con.Close();
// Dispose OracleConnection object
con.Dispose();
}
}
HAイベントはSYS.SYS$SERVICE_METRICSキュー内のメッセージとしてパブリッシュされます。アプリケーションでデータベースへの接続に使用するデータベース・ユーザーに対して、このキューのデキュー権限を付与する必要があります。
次のようなコマンドを使用します。ここで、usernameは.NETアプリケーションがデータベースへの接続に使用するデータベース・ユーザー名です。
execute
dbms_aqadm.grant_queue_privilege('DEQUEUE','SYS.SYS$SERVICE_METRICS', username);
この手順で指定されるusernameは、前の手順のUser ID引数に使用されたusernameと同じです。
|
参照:
|
