1. 管理およびデプロイメント・ガイド
  2. 動的データベース・サービスによるワークロード管理

5 動的データベース・サービスによるワークロード管理

ワークロード管理には、ロード・バランシング、Oracle Real Application Clusters (Oracle RAC)のクライアントの有効化、分散トランザクション処理、およびサービスが含まれます。

この章の内容は次のとおりです。

5.1 接続ロード・バランシング

Oracle Net Servicesでは、Oracle RAC構成内のインスタンス間でクライアント接続を分散する機能を使用できます。

実装可能なロード・バランシングには、クライアント側とサーバー側の2種類のロード・バランシングがあります。クライアント側のロード・バランシングでは、接続要求は各クライアントから独立してリスナーをまたいで分散されます。サーバー側のロード・バランシングの場合、SCANリスナーはサービスの-clbgoalおよび-rlbgoal設定に基づいて、現在サービスを提供している最適なインスタンスに接続要求を送ります。

SCANリスナーはHTTPプロトコルを認識するため、HTTPクライアントを適切なハンドラ(クラスタ内のSCANリスナーが存在するノードとは別のノードに存在する可能性がある)にリダイレクトできます。

Oracle RACデータベースのクライアント接続では、両方のタイプの接続ロード・バランシングを使用する必要があります。

関連項目

5.1.1 サーバー側のロード・バランシング

DBCAを使用してOracle RACデータベースを作成すると、次の処理が自動的に実行されます。

  • サーバー側のロード・バランシングの構成および有効化

  • サーバー上のtnsnames.oraファイルにおけるクライアント側のロード・バランシング接続定義のサンプルの作成

Oracle Clusterwareデータベース・エージェントの役割は、LISTENER_NETWORKSパラメータの管理です。

注意:

注意: REMOTE_LISTENERパラメータを手動で設定している場合は、このパラメータをscan_name:scan_portに設定します。

FAN、高速接続フェイルオーバーおよびロード・バランシング・アドバイザは、正確な接続時ロード・バランシング構成(サービスに対する接続時ロード・バランシングの目標の設定など)に基づいて処理を実行します。接続時ロード・バランシングでは、LONGまたはSHORTのいずれかの目標を使用できます。これらの目標の特性は次のとおりです。

  • SHORT: SHORT接続時ロード・バランシング方式は、ランタイム・ロード・バランシングを使用するアプリケーションに使用します。ロード・バランシング・アドバイザに統合されている接続プールを使用する場合は、CLB_GOALをSHORTに設定します。次の例では、SRVCTLを使用して、サービスoltpappを変更し、接続時ロード・バランシングの目標にSHORTを設定しています。 

    $ srvctl modify service -db db_unique_name -service oltpapp -clbgoal SHORT

  • LONG: LONG接続時ロード・バランシング方式は、ランタイム・ロード・バランシングが必要でない場合に使用します。このことは、バッチ操作の場合に一般的です。LONGは、デフォルトの接続時ロード・バランシングの目標です。次の例では、SRVCTLを使用してサービスbatchconnを変更し、長時間セッション用の接続時ロード・バランシングの目標を定義しています。 

    $ srvctl modify service -db db_unique_name -service batchconn -clbgoal LONG

5.1.2 一般的なデータベース・クライアント

Oracle Net Servicesを使用すると、CONNECT_TIMEOUT、RETRY_COUNT、およびTRANSPORT_CONNECT_TIMEOUTパラメータをtnsnames.ora接続文字列に追加できます。

たとえば、SCANアドレスをデータベースのリモート・リスナーに使用する場合は次のようになります。

jdbc:oracle:thin:@(DESCRIPTION =
 (TRANSPORT_CONNECT_TIMEOUT=3)(CONNECT_TIMEOUT=60)
 (RETRY_COUNT=3)(FAILOVER=ON)
 (ADDRESS_LIST =(ADDRESS=(PROTOCOL=tcp)
  (HOST=CLOUD-SCANVIP.example.com)(PORT=5221))
 (CONNECT_DATA=(SERVICE_NAME=orcl)))
Remote_listeners=CLOUD-SCANVIP.example.com:5221

たとえば、データベースのVIPを指すリモート・リスナーを使用する場合は次のようになります。

jdbc:oracle:thin:@(DESCRIPTION =
 (TRANSPORT_CONNECT_TIMEOUT=3)
 (CONNECT_TIMEOUT=60)(RETRY_COUNT=20)
 (RETRY_DELAY=3)(FAILOVER=ON)
 (ADDRESS_LIST=
 (ADDRESS=(PROTOCOL=tcp)(HOST=CLOUD-VIP1)(PORT=1521) )
 (ADDRESS=(PROTOCOL=tcp)(HOST=CLOUD-VIP2)(PORT=1521) )
 (ADDRESS=(PROTOCOL=tcp)(HOST=CLOUD-VIP3)(PORT=1521) ))
 (CONNECT_DATA=(SERVICE_NAME=GOLD)))

これらのパラメータの値を表す単位は秒です。前述の例では、Oracle Netは各完全接続が応答を受信するのを60秒待機した後、障害が発生したと想定して、ADDRESS_LISTの次のリストを再試行します。Oracle Netは、アドレス・リストを3回試行すると、クライアントに失敗メッセージを返します。TRANSPORT_CONNECT_TIMEOUTパラメータは、データベース・サーバーへのTCP接続の確立を待機する時間を設定します。

SCANの場合、クライアントに失敗を返す前に、(SCANにより返される) 3つのアドレスすべてがOracle Net Servicesによって試行されます。EZConnectとSCANを併用した場合、この接続のフェイルオーバー機能が使用できます。

この動作は、Oracle Net接続フェイルオーバーと呼ばれます。リスト内の選択されたアドレスからエラーが戻されると、Oracle Net Servicesによってリストの次のアドレスが試行され、接続が成功するか、またはリスト内に試行するアドレスがなくなるまで続けられます。

5.1.3 古いクライアント用のクライアント側の接続構成

クライアント側のロード・バランシングに加えて、Oracle Net Servicesには接続フェイルオーバーが含まれています。リスト内の選択されたアドレスからエラーが戻されると、Oracle Net Servicesによってリストの次のアドレスが試行され、接続が成功するか、またはリスト内に試行するアドレスがなくなるまで続けられます。SCANの場合、クライアントに失敗を返す前に、Oracle Net Servicesによって3つのアドレスすべてが試行されます。EZConnectとSCANを併用した場合、この接続のフェイルオーバー機能が使用できます。

可用性を高めるために、Oracle Netがエラーを戻すまでにリスナーからの応答を待機する時間のタイムアウトを指定できます。このタイムアウト・パラメータを設定する方法は、クライアント・アクセスのタイプによって異なります。Oracle Netは、下位互換性のためにこれらのパラメータを維持します。

この項には次のトピックが含まれます:

5.1.3.1 JDBC-Thinクライアント

次のようにoracle.net.ns.SQLnetDef.TCP_CONNTIMEOUT_STRプロパティを設定することによって、遅延を回避できます。 

Properties prop = new Properties ();
prop.put (oracle.net.ns.SQLnetDef.TCP_CONNTIMEOUT_STR,
"" + (1 * 1000)); // 1 second
dbPools[ poolIndex ].setConnectionProperties ( prop );

パラメータの値は、ミリ秒単位で指定します。このため、アプリケーションが再度接続を試みた場合のタイムアウトを500Msに短縮できます。

5.1.3.2 OCIクライアント

OCIクライアントには、クライアント側でローカルのsqlnet.oraファイルを作成します。

次の行を追加してこのファイルに接続タイムアウトを構成します。

sqlnet.outbound_connect_timeout = number_of_seconds

OCIクライアントのタイムアウト値の粒度は秒単位です。sqlnet.oraファイルは、このクライアントを使用するすべての接続に適用されます。

注意:

サーバーのsqlnet.oraファイルには接続タイムアウトを構成しないでください。

5.1.4 クライアント側のロード・バランシング

クライアント側のロード・バランシングは、パラメータLOAD_BALANCE=ONを設定して、クライアントの接続定義(tnsnames.oraファイルなど)に定義します。このパラメータをONに設定した場合は、Oracle Databaseによってアドレス・リストから無作為にアドレスが選択されて、そのノードのリスナーに接続されます。これによって、クラスタ内で使用可能なSCANリスナー間で、クライアント接続が均等に分散されます。

接続要求用にSCANを構成した場合、クライアント側ロード・バランシングは、SCANアクセスをサポートするクライアントには関係しません。クライアントがSCANを使用して接続する場合、EZConnectを使用していないかぎり、Oracle NetはSCANに対して定義された3つのIPアドレスの間でクライアント接続要求の負荷を自動的に均等に分散します。

SCANリスナーは、(-clbgoalがSHORTに設定されている場合は)最もロードされていないインスタンスのローカル・リスナーに接続要求をリダイレクトし、要求されたサービスを提供します。接続要求を受信したリスナーは、要求されたサービスを提供するとリスナーが認識しているインスタンスにユーザーを接続します。リスナーがサポートしているサービスを確認するには、lsnrctl servicesコマンドを実行します。

クライアントがSCANを使用して接続する場合、Oracle NetはSCANに対して定義された3つのIPアドレスの間でクライアント接続要求のロード・バランシングを自動的に行います。ただし、EZConnectを使用している場合は行いません。

SCANをサポートしていないクライアントを使用している場合(クライアント・バージョンがOracle Database 11gリリース2 (11.2)よりも前の場合など)、SCANを使用するには、SCAN VIPを含めるようにクライアントtnsnames.oraを変更し、LOAD_BALANCE=ONを設定してVIP間の要求を均等に分散するようにする必要があります。次に例を示します。 

Sales.example.com=(DESCRIPTION=
  (ADDRESS_LIST=(LOAD_BALANCE=ON)(FAILOVER=ON)
    (ADDRESS=(PROTOCOL=TCP)(HOST=172.22.67.192)(PORT=1521))
    (ADDRESS=(PROTOCOL=TCP)(HOST=172.22.67.193)(PORT=1521))
    (ADDRESS=(PROTOCOL=TCP)(HOST=172.22.67.194)(PORT=1521))
    (CONNECT_DATA=(SERVICE_NAME=salesservice.example.com))
  ))

注意:

データベースがOracle Database 11gリリース2 (11.2)以上で、SCANを使用する場合は、SCAN VIPをREMOTE_LISTENERパラメータに追加して、適切なリスナー・クロス登録を有効にします。

関連項目

5.2 ロード・バランシング・アドバイザ

この項では、ロード・バランシング・アドバイザについて説明します。内容は次のとおりです。

5.2.1 ロード・バランシング・アドバイザの概要

ロード・バランシングは、使用可能なすべてのOracle RACデータベース・インスタンス間で作業を分散します。アプリケーションでは、特定のサービスを提供するインスタンス間をまたがって実行される、接続が永続的な接続プールを使用することをお薦めします。永続接続を使用すると、接続が作成される頻度は低く、長期間存在します。作業は頻繁にシステムに送られ、この接続を利用し、比較的短時間存続します。ロード・バランシング・アドバイザは、受信した作業に対して最適なサービス・クオリティを提供するインスタンスにその作業を転送する方法についてのアドバイスを提供します。これにより、後で作業を再配置する必要性が最小化されます。

ロード・バランシング・アドバイザおよびランタイム接続ロード・バランシングの目標を使用することで、フィードバックはシステムに組み込まれます。作業は、システム全体で最適なサービス時間が実現されるようにルーティングされ、システムの状態変化に透過的に対応します。安定した状態のシステムでは、Oracle RACのすべてのインスタンスでスループットが向上した状態が維持されるようになります。

ロード・バランシング・アドバイザを使用できる標準アーキテクチャには、接続時ロード・バランシング、トランザクション処理モニター、アプリケーション・サーバー、接続コンセントレータ、ハードウェアおよびソフトウェアのロード・バランサ、ジョブ・スケジューラ、バッチ・スケジューラおよびメッセージ・キューイング・システムが含まれます。これらすべてのアプリケーションでは、作業を割り当てることができます。

ロード・バランシング・アドバイザは、リスナー、JDBCユニバーサル接続プール、OCIセッション・プール、Oracle WebLogic Server Active GridLink for Oracle RAC、ODP.NET接続プールなどの主要なOracleクライアントとともにデプロイされます。また、サードパーティ・アプリケーションは、JDBCとOracle RAC FAN APIを使用するか、またはOCIでコールバックを使用して、ロード・バランシング・アドバイザ・イベントをサブスクライブすることもできます。

5.2.2 ロード・バランシング・アドバイザを使用する環境の構成

ロード・バランシングを有効にする各サービスにサービス・レベルの目標を定義して、ロード・バランシング・アドバイザを使用するように環境を構成できます。

サービス・レベルの目標を構成すると、ロード・バランシング・アドバイザが有効になり、そのサービスのFANロード・バランシング・イベントのパブリッシュが可能になります。ランタイム接続のロード・バランシングにおけるサービス・レベルの目標値には、次の2つのタイプがあります。

  • SERVICE_TIME: 応答時間に基づいて、作業要求をインスタンスに割り当てます。ロード・バランシング・アドバイザのデータは、サービスで完了した作業の経過時間およびサービスに対して使用可能な帯域幅に基づきます。SERVICE_TIMEの使用例としては、需要が変動するインターネット・ショッピングなどのワークロードがあります。次の例は、onlineサービスを使用して、目標を接続のSERVICE_TIMEに設定する方法を示します。 

    $ srvctl modify service -db db_unique_name -service online
  -rlbgoal SERVICE_TIME -clbgoal SHORT

  • THROUGHPUT: スループットに基づいて、作業要求をインスタンスに割り当てます。ロード・バランシング・アドバイザのデータは、サービスで完了した作業の処理速度およびサービスに対して使用可能な帯域幅に基づきます。THROUGHPUTの使用例としては、前のジョブが完了してから次のジョブを開始するバッチ処理などのワークロードがあります。次の例は、sjobサービスを使用して、目標を接続のTHROUGHPUTに設定する方法を示します。 

    $ srvctl modify service -db db_unique_name -service sjob
  -rlbgoal THROUGHPUT -clbgoal LONG

ランタイム接続ロード・バランシングの目標をNONEに設定すると、サービスのロード・バランシングが無効になります。データ・ディクショナリのサービスの目標設定は、DBA_SERVICESビュー、V$SERVICESビューおよびV$ACTIVE_SERVICESビューを問い合せて確認できます。また、Oracle Enterprise Managerを使用して、サービスのロード・バランシング設定を確認することもできます。

関連項目

5.2.3 ロード・バランシング・アドバイザのFANイベント

ロード・バランシング・アドバイザのFANイベントでは、ロード・バランシング・アルゴリズムのメトリックが提供されます。

このイベントを使用する最も簡単な方法は、JDBC、Universal Connection Pool (または非推奨の暗黙的な接続キャッシュ)、ODP.NET接続プール、OCIセッション・プール、Oracle WebLogic Server Active GridLink for Oracle RACなどのOracle統合クライアントのランタイム接続ロード・バランシング機能を使用することです。他のクライアント・アプリケーションは、Oracle RAC FAN APIを使用することでFANをプログラムで利用し、FANイベントをサブスクライブしたり、受信時にイベント処理アクションを実行できます。表5-1に、ロード・バランシング・アドバイザのFANイベント・パラメータを示します。

関連項目:

Oracle RAC FAN APIの詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。

表5-1 ロード・バランシング・アドバイザのFANイベント

パラメータ 説明 
VERSION

イベント・レコードのバージョン。リリースの変更を識別するために使用されます。 

EVENT_TYPE

ロード・バランシング・アドバイザ・イベントは、常にSERVICEMETRICSイベント・タイプです。 

SERVICE

サービス名。DBA_SERVICESのNAMEの値に該当します。 

DATABASE

サービスをサポートしている一意のデータベースを示し、DB_UNIQUE_NAME初期化パラメータの値と一致します。このパラメータのデフォルト値は、初期化パラメータDB_NAMEの値です。 

INSTANCE

サービスをサポートしているインスタンスの名前であり、ORACLE_SIDの値と一致します。 

PERCENT

そのデータベース・インスタンスに送信する作業要求の割合。

 
FLAG

サービスの目標を基準としたサービス品質。有効な値は、GOOD、VIOLATING、NO DATAおよびBLOCKEDです。 

TIMESTAMP

通知イベントをオーダーする場合に使用するローカル・タイム・ゾーン。

注意:

INSTANCE、PERCENTおよびFLAGイベント・パラメータが、サービスを提供する各インスタンスに生成されます。インスタンス・データの各セットは、中カッコ({})で囲まれます。

関連項目

5.2.4 ロード・バランシング・アドバイザのFANイベントの監視

ロード・バランシング・アドバイザのFANイベントの内部キュー表に対して次の問合せを使用すると、インスタンス用に生成されたロード・バランシング・アドバイザ・イベントを監視できます。

SET PAGES 60 COLSEP '|' LINES 132 NUM 8 VERIFY OFF FEEDBACK OFF
COLUMN user_data HEADING "AQ Service Metrics" FORMAT A60 WRAP
BREAK ON service_name SKIP 1
SELECT
 TO_CHAR(enq_time, 'HH:MI:SS') Enq_time, user_data
 FROM sys.sys$service_metrics_tab
 ORDER BY 1 ;

この問合せの結果には、次のような行が含まれます。

02:56:05|SYS$RLBTYP('hr', 'VERSION=1.0 database=sales service=hr
   { {instance=sales_4 percent=38 flag=GOOD aff=TRUE}{instance=sales_1
   percent=62 flag=GOOD aff=TRUE} } timestamp=2012-07-16 07:56:05')

次に、Oracle RAC FAN APIを使用してOracle Notification Serviceから取得された、2つのインスタンス(orcl1およびorcl2)で提供されるlba_servサービスのロード・バランシング・アドバイザ・イベントの例を示します。 

Notification Type: database/event/servicemetrics/lba_serv.example.com
   VERSION=1.0 database=orcl service=lba_serv.example.com { {instance=orcl2
   percent=50 flag=UNKNOWN aff=FALSE}{instance=orcl1 percent=50 flag=UNKNOWN
   aff=FALSE} } timestamp=2012-07-06 13:19:12

注意:

SERVICMETRICSイベントは、FANコールアウト・メカニズムを介しては認識されません。

5.3 Oracle RACのクライアントの有効化

Oracle RACデータベースへの接続に使用される多くの一般的なクライアント・アプリケーション環境は、FANと統合されています。そのため、FANを使用する最も簡単な方法は、Oracle統合クライアントを使用することです。

次の項では、FANをOracleクライアントと統合する方法と、いくつかの特定のクライアント開発環境でFANイベントを有効にする方法について説明します。

5.3.1 Oracle統合クライアントとFANの概要

FANの全体的な目的は、アプリケーションのエンドツーエンドの完全自動リカバリ、および実際のトランザクション・パフォーマンスに基づいたロード・バランシングを可能にすることです。

アプリケーションは、FAN高可用性(HA)イベントを使用して、失敗を高速に検出し、失敗後の接続プールを均等に分散し、失敗したコンポーネントが修復されると接続を再度分散します。

ロード・バランシング・アドバイス・ヘルプ接続プールを持つFANイベントは、最適なサービスを提供する使用可能なインスタンスに接続を一貫して配信します。FAN HAは、JDBC-thinドライバおよびOCIドライバと統合されています。FAN HAおよびFANロード・バランシングの両方が、JDBC Universal Connection Pool (および非推奨の暗黙的な接続キャッシュ)、OCIセッション・プール、ODP.NET接続プールおよびOracle WebLogic Server Active GridLink for Oracle RACと統合されています。

FANとの統合によって、Oracle統合クライアントはOracle RACクラスタの最新のステータスをより迅速に認識します。これによって、クライアント接続が使用できなくなったインスタンスやサービスを待機したり接続試行することがなくなります。インスタンスが起動すると、Oracle RACでは、最近起動されたインスタンスへの接続を接続プールで作成し、このインスタンスで提供される追加リソースを接続プールで使用できるように、FANを使用して接続プールに通知します。

FANと統合されたOracle クライアント・ドライバでは次のことが適用されます。

  • 終了した接続を削除すると同時に、サービスがインスタンスでDOWNとして宣言され、ノードも同時にDOWNとして宣言されます。

  • サービスが再起動を繰り返し試行する間クライアントを待機させるかわりに、NOT RESTARTING状態がOracle Databaseで検出されるとすぐにエラーをクライアントにレポートします。

FANと統合されたOracle接続プールでは、次の処理を実行できます。

  • サービスの起動時に、Oracle RACのすべてのインスタンス間で接続を均等に分散します。この方法は、接続プールで定義されているセッションを、サービスがサポートされている最初のOracle RACインスタンスに割り当てるよりも有効です。

  • ロード・バランシング・アドバイザのイベントを使用して、実行時の作業要求を均等に分散します。

クライアント・ドライバや接続プールとFANを使用する場合、FANイベントをクライアントに配信するようにOracle Notification Serviceを適切に構成する必要があります。また、ロード・バランシングの場合は、接続プールで使用されるサービスを提供するすべてのインスタンスへのデータベース接続のロード・バランシングを構成する必要があります。Oracle Net Servicesでクライアント側とサーバー側のロード・バランシングを構成することをお薦めします。DBCAを使用してデータベースを作成すると、デフォルトで、クライアント側とサーバー側の両方のロード・バランシングが構成されます。

関連項目

5.3.2 JDBC-Thinクライアントでの高速接続フェイルオーバーの有効化

Universal Connection PoolおよびOracle WebLogic Server Active GridLink for Oracle RACで高速接続フェイルオーバー(FCF)を有効化すると、FAN HAおよびロード・バランシング・アドバイザ・イベントを使用できるようになります。

Universal Connection PoolでFANを使用する場合、アプリケーションは、JDBC OCIクライアントまたはJDBC ThinクライアントのどちらのJDBC開発環境も使用できます。Java Database Connectivity Oracle Call Interface (JDBC/OCI)ドライバ接続プール機能は、JDBC-thinクライアントの一部です。この機能は、OracleOCIConnectionPoolクラスによって提供されます。

JDBC-thinクライアント用のFCFを有効にするには、最初のgetConnection()リクエストを行う前に、oracle.jdbc.poolパッケージのOracleDataSourceクラスのメソッドsetFastConnectionFailoverEnabled(true)を呼び出します。JDBC-thinクライアント用のFCFを有効にすると、フェイルオーバー・プロパティは接続プール内のすべての接続に適用されます。JDBC-thinドライバまたはJDBC/OCIクライアントでFCFを有効にすると、接続プールですべてのFANイベントを受信して、これらのイベントを処理できます。

JDBCアプリケーションの開発者は、Oracle Database 11gリリース2 (11.2)で導入された一連のAPIを使用して、プログラムでFANと統合できます。Oracle RAC FAN APIを使用すると、Oracle RACによって送信されるFANイベント通知の、アプリケーション・コードによる受信と応答が次の方法で可能になります。

  • Oracle RACサービスの停止イベント、サービスの起動イベントおよびノードの停止イベントのリスニング

  • ロード・バランシング・アドバイザ・イベントのリスニングと、それに対する応答

関連項目

5.3.2.1 JDBC-Thinクライアント用のOracle Notification Service

FCFは、Oracle Notification Serviceを利用して、接続プールとOracle RACデータベース間でデータベース・イベントを伝播します。実行時、接続プールは、Oracle Notification Service環境を設定できる必要があります。Oracle Notification Service(ons.jar)は、Oracleクライアント・ソフトウェアの一部として含まれています。Oracle Notification Serviceは、リモート構成またはクライアント側のOracle Notification Serviceデーモン構成のいずれかを使用して構成できます。リモートOracle Notification Serviceサブスクリプションを使用すると、次のメリットがあります。

  • すべてのJava中間層ソフトウェアがサポートされます。

  • クライアント・システムではOracle Notification Serviceデーモンが不要なため、このプロセスを管理する必要はありません。

  • データソース・プロパティを使用して、構成作業を簡単に行うことができます。

5.3.2.2 JDBC/OCIおよびJDBC Thinドライバ・クライアント用のFCFの構成

Universal Connection Poolまたは暗黙接続キャッシュ用のFCFを有効にできます。

暗黙接続キャッシュは非推奨であるため、Universal Connection PoolをJavaに使用することをお薦めします。Oracle WebLogic Server Active GridLink for Oracle RACを使用することもできます。

この項では、JDBC用のFCFを有効にする方法について説明します。JDBC/OCIクライアントでFCFを有効にしている場合は、Oracle Database 11gリリース2 (11.2)で使用されているOCI クライアント用にFANを有効化する方法(サービスでnotificationをTRUEに設定)は使用せず、クライアントまたはサーバーのいずれにもTAFを構成しないでください。アプリケーション・コンティニュイティおよびトランザクション・ガードを構成することもできます。

FCFを有効にするには、次の手順で説明するように、最初にUniversal Connection Poolを有効にする必要があります。

  1. 接続プールを作成し、setFastConnectionFailoverEnabled(true)を設定します。

    次の例では、接続プールを作成し、FCFを有効にします。この例を使用する場合、ucp.jarライブラリはアプリケーションのCLASSPATHに含まれる必要があります。 

    PoolDataSource pds = PoolDataSourceFactory.getPoolDataSource();
pds.setFastConnectionFailoverEnabled(true);

  2. Oracle Notification Serviceリモート・サブスクリプションに使用するポートを特定します。

    次の例に示すように、Oracle Clusterwareを実行している各ノードで、次のコマンドを使用してOracle Notification Service構成を表示します。

    srvctl config nodeapps -onsonly

    このコマンドの出力では、Oracle Notification Service用に構成されているローカル・ポートおよびリモート・ポートがリストされます。

    注意:

    Oracle Notification Service構成は、Oracle Clusterwareのインストール時に自動的に完了しているはずです。

  3. リモートOracle Notification Serviceサブスクリプションを構成します。

    ユニバーサル接続プールを使用する場合、アプリケーションはOracleDataSourceインスタンスのsetONSConfigurationをコールして、使用するノード番号とポート番号を指定します。次の例に示すように、各ノードで使用されるポート番号は、ステップ2の各ノードで表示されるリモート・ポートと同じです。この例を使用する場合、ons.jarライブラリはアプリケーションのCLASSPATHに含まれる必要があります。 

    pds.setONSConfiguration("nodes=racnode1:6200,racnode2:6200");

    リモートOracle Notification Service構成を使用するアプリケーションでは、次の例のように、アプリケーションを起動する前に、oracle.ons.oraclehomeシステム・プロパティにORACLE_HOMEの場所を設定する必要があります。 

    java -Doracle.ons.oraclehome=$ORACLE_HOME ...

  4. 接続URLを構成します。

    FCFを使用する場合、コネクション・ファクトリの接続URLはサービス名構文を使用する必要があります。サービス名は、接続プールをサービスにマップするために使用されます。次の例では、接続URLの構成を示しています。

    pds.setConnectionFactoryClassName("oracle.jdbc.pool.OracleDataSource");
pds.setURL("jdbc:oracle:thin@//SCAN_name:service_name");...

5.3.3 JDBCクライアントでのランタイム接続ロード・バランシングの有効化

実行時接続ロード・バランシングには、Oracle JDBCドライバおよびOracle RACデータベースを使用する必要があります。

Oracle JDBC Universal Connection PoolおよびOracle WebLogic Server Active GridLink for Oracle RACでは、Oracle RACデータベースによって提供されるロード・バランシング機能が利用されます。

ロード・バランシング・アドバイザの情報を利用するために、Universal Connection PoolおよびOracle WebLogic Server Active GridLink for Oracle RACが統合されています。Oracle Database 11g リリース11.1.0.7.0では、JDBCのユニバーサル接続プールが導入されました。そのため、Oracle RACデータベースで使用するためにOracle Database 10g リリース1で導入された既存のJDBC接続プール(暗黙接続キャッシュ)が非推奨になりました。Oracle Database 12cに加えて、Oracle Database 10gまたはOracle Database 11gでもUniversal Connection Poolを使用できます。

実行時接続ロード・バランシングには、FCFが有効であり、適切に構成されていることが必要です。また、Oracle RACロード・バランシング・アドバイザは、接続プールで使用されるサービスごとにサービス・レベルの目標で構成される必要があります。接続時ロード・バランシングの目標は、次の例のとおり、SHORTに設定される必要があります。 

srvctl modify service -db db_unique_name -service service_name
   -rlbgoal SERVICE_TIME -clbgoal SHORT

関連項目

5.3.4 Javaのアプリケーション・コンティニュイティのためのJDBC-Thinクライアントの構成

リプレイ・データ・ソース(oracle.jdbc.replay.OracleDataSource)は、アプリケーション・コンティニュイティがJavaで必要とするJDBC-thinデータ・ソースです。

このデータ・ソースは、新しい物理JDBC接続をUniversal Connection PoolおよびOracle WebLogic Server Active GridLink for Oracle RACデータ・ソースの両方に生成するコネクション・ファクトリとして機能します。JDBCリプレイ・ドライバは、Oracle Database 12cとのクライアント対話中のコールの履歴を、Oracle Databaseと協力して保持します。データベース・サービスの欠落で生じるセッションの停止(計画済または計画外)に続いて、データベースの指示のもとで、JDBCリプレイ・ドライバは、非トランザクションおよびトランザクションのデータベース・セッション状態の再構築を試行し、これによって停止は遅れた実行として示されます。

Javaのアプリケーション・コンティニュイティおよびJDBCリプレイ・ドライバを使用するには、Oracle Database 12cクライアントを使用してOracle Database 12cデータベースに接続する必要があります。Javaのアプリケーション・コンティニュイティは次の構成でサポートされています:

  • Oracle JDBCリプレイ・データ・ソースを使用し、Universal Connection PoolまたはOracle WebLogic Server Active GridLink(典型的なサード・パーティ製JDBCベースの接続プール)を使用しないJDBCアプリケーション

  • Universal Connection Poolデータ・ソースを使用するJDBCアプリケーション(Universal Connection Poolデータ・ソースを使用するように構成されたスタンドアロンまたはサード・パーティ製のアプリケーション・サーバー)

  • Oracle WebLogic Server Active GridLinkのみを使用して、Universal Connection Poolデータ・ソース(典型的なOracle WebLogic Server J2EEケース)を使用しないJDBCアプリケーション

JDBCリプレイ・ドライバを使用するようにJDBC-thinクライアントを構成するには:

  1. リプレイ用に認証されているアプリケーションを使用してください。

  2. アプリケーションで使用するサービスがまだ存在しない場合は、SRVCTLを使用してそのサービスを作成します。このサービスで-failovertypeパラメータをTRANSACTIONに設定し、-commit_outcomeパラメータをTRUEに設定します。

  3. 次の例に示すとおり、PoolDataSourceオブジェクトを使用して接続要素を構成します。 

    PoolDataSource rds = PoolDataSourceFactory.getPoolDataSource();
rds.setConnnectionPoolName("replayExample");
rds.setONSConfiguration("nodes=racnode1:4200,racnode2:4200");
rds.setFastConnectionFailoverEnabled(true);
rds.setConnectionFactoryClassName("oracle.jdbc.replay.OracleDataSourceImpl");

Connection conn = rds.getConnection();

  4. データベースへの接続時に、サービスを提供するすべてのインスタンスにアクセス可能なURLを使用します。

関連項目

関連項目:

アプリケーション・コンティニュイティを有効化しないトランザクション・ガードの構成の詳細は、Oracle Database JDBC開発者ガイドを参照

5.3.5 トランザクション・ガード用のJDBC-Thinクライアントの構成

トランザクション・ガードは、計画済および計画外の停止の場合に、実行を1回以下にするためにアプリケーションで使用されるプロトコルおよび汎用ツールを提供します。

アプリケーションでは論理トランザクションIDを使用して、停止に続くデータベース・セッション内でオープンになっている最終トランザクションの結果が判断されます。トランザクション・ガードを使用しないと、停止の後にエンド・ユーザーまたはアプリケーションが操作を再試行しようとして、トランザクションが重複してコミットされたり、順序が不適切にトランザクションがコミットされることで、論理破損が発生する可能性があります。

関連項目

5.3.6 OCIクライアントでの高速接続フェイルオーバーの有効化

OCIクライアントは、Oracle RAC高可用性FANイベントの通知を受信するように登録し、イベント発生時に応答することによって、FCFを有効にできます。FCFを使用すると、OCIアプリケーションでのセッション・フェイルオーバー応答時間が向上し、接続プールおよびセッション・プールから機能していないインスタンスへの接続も削除されます。FCFはOCIアプリケーションで使用でき、このアプリケーションはTAF、OCIドライバ(独自の接続プールを含む)、OCI接続プールおよびOCIセッション・プールも使用します。FANは、高可用性およびロード・バランシング・イベントのためにOracle Notification Serviceでポストされます。

FCFを使用するには、FANが有効なサービスを使用する必要があります。FANは、Oracle Notification Service経由で公開されます。クライアント・アプリケーションには、イベント発生時に使用するコールバックを登録することもできます。これによって、接続障害が検出されるまでの時間が短縮されます。

DOWNイベントの処理中に、OCIでは次の処理が実行されます。

  • クライアントで影響を受ける接続が終了し、エラーが戻されます。

  • OCI接続プールおよびOCIセッション・プールから接続を削除します。OCIセッション・プールでは、各セッションが接続プールの物理的な接続とマッピングされています。1つの接続に複数のセッションが存在する場合もあります。

  • TAFが構成されている場合、接続をフェイルオーバーします。TAFが構成されていない場合、接続先のインスタンスに障害が発生しても、クライアントはエラーを受信するだけです。

アプリケーションでTAFを使用している場合は、SRVCTLまたはOracle Enterprise Managerを使用して、サービスのTAFプロパティを有効にする必要があります。構成済のサービスを使用して、Oracle RACデータベースに接続するようにOCIクライアント・アプリケーションを構成します。

注意:

OCIはUPイベントを管理しません。

OCIクライアント用のFCFの構成

OCIアプリケーションは、Oracle RACインスタンスに接続して、HAイベント通知を有効にする必要があります。さらに、これらのアプリケーションは、次のステップを実行してOCIクライアント用のFCFを構成する必要があります。

  1. 次の例に示すとおり、FAN、接続時ロード・バランシングおよびランタイム接続ロード・バランシングを有効にするように、OCI接続プールのサービスを構成します。

    $ srvctl modify service -db crm -service ociapp.example.com -notification TRUE

  2. アプリケーションをスレッド・ライブラリにリンクします。

  3. スレッド・ライブラリにリンクした後、アプリケーションは、FANイベントが発生すると常に起動されるコールバックを登録できます。

関連項目

5.3.7 OCIクライアントでのランタイム接続ロード・バランシングの有効化

Oracle Database 12cでは、OCIセッション・プールによって、動的に管理される事前作成済のデータベース・セッションのセットをアプリケーションの複数スレッドで使用できます。

接続プーリングではプール要素は接続ですが、セッション・プーリングではプール要素はセッションとなります。Oracle Databaseでは、セッション・プール内のセッションを継続的に再利用して、インスタンスへのほぼ永続的なチャネルを形成することによって、アプリケーションでセッションが必要になるたびにセッションを作成してクローズするオーバーヘッドを削減できます。

ランタイム接続ロード・バランシングは、デフォルトでOracle Database 11gリリース11.1以上、Oracle Database 10gリリース10.2以上のサーバーとのクライアント通信で有効になっています。Oracle RAC環境の場合、アプリケーションのセッション要求を均等に分散させるために、セッション・プールは、高速アプリケーション通知(FAN)イベントを介してOracle RACロード・バランシング・アドバイザ脚注1から受信されるサービス・メトリックを使用します。セッション・プールに入ってくる作業要求は、現在のサービス・パフォーマンスを使用して、サービスを提供しているOracle RACのインスタンス全体で分散できます。

OCIクライアントを構成してロード・バランシング・アドバイザのFANイベントを受信する方法

Oracle RAC環境の場合、アプリケーションのセッション要求を均等に分散させるために、セッション・プールは、高速アプリケーション通知(FAN)イベントを介してOracle RACロード・バランシング・アドバイザから受信されるサービス・メトリックを使用します。次の例に示すとおり、アプリケーションがサービス時間に基づいてサービス・メトリックを受信できるようにするには、FAN、ロード・バランシング・アドバイザの目標(-rlbgoalパラメータ)および接続ロード・バランシングの目標(-clbgoalパラメータ)を、セッション・プールで使用されるサービスに構成していることを確認します。 

$ srvctl modify service -db crm -service ociapp.example.com -rlbgoal SERVICE_TIME
  -clbgoal SHORT -notification TRUE

関連項目

5.3.8 トランザクション・ガードを使用するためのOCIクライアントの構成

OCIは、FANメッセージおよびトランザクション・ガードをサポートしています。FANは、ノード、データベース、インスタンス、サービスおよびパブリック・ネットワーク・レベルでの停止をOCIベースのアプリケーションに迅速に通知するように設計されています。

障害の通知があると、アプリケーションはトランザクション・ガードを利用して、最後の処理中のトランザクションの結果を確実に判別できます。

トランザクション・ガードによって、ユーザーが不満を抱く不明なエラー、カスタマ・サポート・コールおよび機会損失のコストを削減します。トランザクション・ガードは、既知の結果に対する自社製のソリューションと比べて、より安全でパフォーマンスが良く、オーバーヘッドがより少なくなっています。

関連項目

5.3.9 ODP.NETクライアントを有効化してFAN高可用性イベントを受信する方法

ODP.NETの接続プールでは、ノード、サービスおよびサービス・メンバーが停止したことを示すFAN HA通知をサブスクライブできます。

DOWNイベントが発生すると、そのインスタンスに送られる接続プール内のセッションはOracle Databaseによって削除され、ODP.NETは無効になった接続を事前対応的に削除します。無効な接続が削除されたことで、接続合計数がMin Pool Sizeパラメータの値を下回った場合、ODP.NETは、既存のOracle RACインスタンスへの追加の接続を確立します。

Oracle Database 12c以上に接続する場合、ODP.NETは、Advanced Queuingではなく、Oracle Notification Serviceを使用します。

FAN高可用性イベントをサブスクライブすることによって、ODP.NET接続プールの高速接続フェイルオーバーを有効にします。高速接続フェイルオーバーを有効にするには、次の例に示すとおり、HA Events=trueおよびpooling=true (デフォルト値)を接続文字列に含めますが、ここで、user_nameはデータベース・ユーザーの名前、passwordはそのユーザーのパスワードです。 

con.ConnectionString =
   "User Id=user_name;Password=password;Data Source=odpnet;" +
   "Min Pool Size=10;Connection Lifetime=120;Connection Timeout=60;" +
   "HA Events=true;Incr Pool Size=5;Decr Pool Size=2";

関連項目

5.3.10 ODP.NETクライアントを有効化してFANロード・バランシング・アドバイザのイベントを受信する方法

Oracle Database 12c以上に接続する場合、ODP.NETは、Advanced Queuingではなく、Oracle Notification Serviceを使用します。

ODP.NETクライアントまたはアプリケーションを有効化して、FANロード・バランシング・アドバイザのイベントを受信するには、次の手順を実行します。

  1. 次の例に示すとおり、SRVCTLを使用してOracle Notification Serviceの通知を有効にし、実行時ロード・バランシングの目標を設定します。

    $ srvctl modify service -db crm -service odpapp.example.com
  -notification TRUE -clbgoal LONG -rlbgoal SERVICE_TIME

  2. Oracle Notification Service (ONS)をFANイベント(実行時ロード・バランシング・アドバイスなど)用に構成します。

  3. ConnectionStringのロード・バランシング属性にTRUEを設定して、ODP.NET接続プールでロード・バランシング・イベントを利用するように構成します(デフォルトはFALSE)。この処理は、接続時に実行できます。この処理は、接続プールを使用している場合、またはプーリング属性がTRUE(デフォルト)設定されている場合にのみ実行できます。

    次の例では、ロード・バランシングが有効になるようにConnectionStringを構成する方法を示します。user_nameはユーザー名、passwordはパスワードです。 

    con.ConnectionString =
  "User Id=user_name;Password=password;Data Source=odpapp;" +
  "Min Pool Size=10;Connection Lifetime=120;Connection Timeout=60;" +
  "Load Balancing=true;Incr Pool Size=5;Decr Pool Size=2";

注意:

ODP.NETでは、ノード起動時(UPイベント)の接続の再分散はサポートしていません。ただし、サーバー側でフェイルオーバーが有効になっている場合は、ODP.NETで、新しく使用可能になったインスタンスに接続を移行できます。

関連項目

5.3.11 トランザクション・ガードを使用するためのODP.NETクライアントの構成

ODP.NETは、FANメッセージおよびトランザクション・ガードをサポートしています。FANは、ノード、データベース、インスタンス、サービスおよびパブリック・ネットワーク・レベルでの停止をODP.NETベースのアプリケーションに迅速に通知するように設計されています。

障害の通知があると、アプリケーションはトランザクション・ガードを利用して、最後の処理中のトランザクションの結果を確実に判別できます。

トランザクション・ガードによって、ユーザーが不満を抱く不明なエラー、カスタマ・サポート・コールおよび機会損失のコストを削減します。トランザクション・ガードは、既知の結果に対する自社製のソリューションと比べて、より安全でパフォーマンスが良く、オーバーヘッドがより少なくなっています。

関連項目

5.4 Oracle RACの分散トランザクション処理

X/Open Distributed Transaction Processing(DTP)アーキテクチャは、複数のアプリケーション・プログラム(AP)が複数の異なるリソース・マネージャ(RM)から提供されるリソースを共有できるようにするための、標準のアーキテクチャまたはインタフェースを定義しています。APとRM間の作業を調整し、グローバル・トランザクションを実現します。

次の項では、Oracle RACがグローバル(XA)・トランザクションおよびDTP処理をサポートする方法について説明します。

5.4.1 XAトランザクションとOracle RACの概要

デフォルトでグローバル(XA)・トランザクションは、Oracle RACインスタンスにまたがることができ、Oracle XAライブラリを使用する任意のアプリケーションが、Oracle RAC環境を十分に利用してアプリケーションの可用性およびスケーラビリティを向上させるようにすることができます。

GTXnバックグラウンド・プロセスは、Oracle RAC環境でXAトランザクションをサポートしています。GLOBAL_TXN_PROCESSES初期化パラメータ(デフォルトで1に設定)は、各Oracle RACインスタンスのGTXnバックグラウンド・プロセスの初期数を指定します。クラスタ全体でこのパラメータのデフォルト値を使用し、複数のOracle RACインスタンス間にわたる分散トランザクションを可能にします。デフォルト値の使用により、Oracle RACインスタンス全体にわたって実行される作業単位は、リソースを共有し、単一のトランザクションとして機能します(つまり、作業単位は密結合となります)。また、クラスタ内の任意のノードへの2フェーズ・コミット要求の送信も可能となります。

Oracle RAC 11gリリース1 (11.1)より前では、Oracle RACで密結合を実現する方法として分散トランザクション処理(DTP)サービス、つまりカーディナリティ(1)によって、ロード・バランシングが有効かどうかに関係なく、すべての密結合ブランチが確実に同じインスタンスに配置されるサービスを使用していました。XAアプリケーションが同じトランザクション・ブランチで一時停止および再開を使用せず、かつ、ブランチにまたがるセーブポイントを発行しない場合、密結合されたXAトランザクションは、Oracle RACデータベースにデプロイするための特別なタイプのシングルトン・サービスを必要としません。トランザクション・ブランチが一時停止されたか再開されたかをアプリケーションが判断できない場合は、アプリケーションは、DTPサービスを、または、できればXAアフィニティを引き続き使用する必要があります。

同じXAブランチを一時停止または再開する場合、あるいはブランチにわたってセーブポイントを使用する場合、XAアフィニティ(同じXAトランザクションのすべてのブランチを同じOracle RACインスタンスに配置すること)が要件になります。様々なトランザクションのバランスを取ることができるため、はるかに優れたパフォーマンスももたらされます。XAアフィニティは、Oracle WebLogic Server Active GridLink for Oracle RAC、JDBC Universal Connection PoolおよびOracle Tuxedoで使用できます。

注意:

トランザクション処理モニターには、XAアフィニティまたはDTPサービスが引き続き必要になることがあります。これらを使用するアプリケーションが同じブランチの一時停止および再開を行ったり、セーブ・ポイントを使用したりするためです。

Oracle Services for Microsoft Transaction Server (OraMTS)などの外部のトランザクション・マネージャは、XAトランザクションを調整します。ただし、Oracleの内部トランザクション・マネージャが、分散SQLトランザクションを調整します。これらは、どちらもシングルトン・サービスまたは均一サービスを使用できます。シングルトン・サービスは、XAアフィニティを提供し、グローバル・トランザクションを利用したメンテナンスの際に排出できます。

関連項目

5.4.2 XAトランザクションのためのグローバル・トランザクションとXAアフィニティの使用

Oracle RACの分散トランザクション処理(DTP)を使用してアプリケーションのパフォーマンスを向上させるには、XAアフィニティを利用します。

XAアフィニティを使用すると、分散トランザクションのすべてのブランチをクラスタ内のシングル・インスタンスに割り当てることができます。XAアフィニティを実装するために、WebLogic Serverやユニバーサル接続プールなど、XAアフィニティを提供するアプリケーション・サーバーを使用できます。アプリケーション・サーバーにXAアフィニティがない場合は、Oracle RAC全体でシングルトン・サービスを使用することもできます。

Oracle RACデータベースの複数の接続にわたりロード・バランスを実行するアプリケーション・サーバー層の接続プールでは、XAアフィニティを使用して、1つのグローバル分散トランザクションのすべての密結合ブランチが、1つのOracle RACインスタンスのみで実行されるようにします。XAアフィニティを備えた接続プールを使用すると、XAを使用するサービスをOracle RACに広げられるようになります。これは、X/Open分散トランザクション処理やMicrosoft分散トランザクション・コーディネータなどのプロトコルを使用した分散トランザクション環境にも当てはまります。

分散トランザクションのパフォーマンスを向上させるには、サービスを使用してDTP環境を管理します。シングルトン・サービスは、Oracle RACデータベースの1つのOracle RACインスタンスで1つずつ実行されます。このサービスもメンテナンス目的の排出が可能であるため、従来のDTPサービスよりも優れた高可用性の特性があります。クラスタ全体でロード・バランスを実行するには、1つまたは2つの大規模アプリケーション・サーバーを使用するよりも、小規模アプリケーション・サーバーのグループをいくつか用意して、各グループ内でトランザクションを単一または一連のサービスに割り当てる方が効果的です。シングルトン・サービスを使用すると、サービスを通じて実行されるグローバル分散トランザクションは、単一のOracle RACインスタンスで実行する専用の密結合ブランチを持ちます。これには、次のような利点があります。

  • 密結合ブランチで相互に行った変更が必要である場合に、1つのOracle RACインスタンス内で変更をローカルに参照できます。

  • サービスの再配置とフェイルオーバーは、グローバル・トランザクションを使用することで完全にサポートされます。

  • Oracle Databaseでは、Oracle RACインスタンスより多くのシングルトン・サービスを使用することによって、Oracle RACデータベースのすべてのインスタンスのサービスで負荷を均等に分散できます。

注意:

アプリケーションが同一のXAブランチを一時停止して再開する場合は、DTPサービス属性またはXAアフィニティが必要になります。

5.4.3 Oracle RACのXAトランザクションによるサービスの使用

Oracle RACでXAを使用するほとんどのアプリケーションは、接続プールまたはトランザクション処理モニターによって提供されるXAアフィニティで、均一サービス(またはすべての優先サービス)を使用できます。

XAアフィニティを提供するために、アプリケーションでもシングルトン・サービスを使用できます。

シングルトン・サービスを使用しているときに、クラスタ内のすべてのインスタンスを利用するには、分散トランザクションをホストするOracle RACインスタンスごとに1つ以上のシングルトン・サービスを作成します。各アプリケーション・サーバーの別々のサービスを選択して、Oracle RACデータベース・インスタンス間でワークロードを均等に分散します。1つの分散トランザクションのすべてのブランチが1つのインスタンスで実行されるため、複数のシングルトン・サービスを介して、多数の分散トランザクション処理(DTP)トランザクションの負荷を均等に分散するために、すべてのインスタンスを利用できるようになり、その結果、アプリケーションのスループットを最大限にできます。

クラスタ・データベースのノードを追加または削除した場合は、最適なパフォーマンス・レベルを維持するために、サービスの確認と再配置が必要になることがあります。シングルトン・サービスを使用すると、現在の作業を完了できます。DTPサービスを使用すると、現在の作業は中断されます。

DTPサービスは、同一ブランチを一時停止して再開するXAアプリケーションにのみ使用する必要があります。DTPを使用しているときには、シングルトンの場合と同じアプローチを適用しますが、サービスの再配置時に作業を排出できなくなります。

5.4.4 XAアプリケーションのサービスの構成

分散トランザクション処理用の分散トランザクション処理(DTP)サービスを作成するには、次のステップを実行します。

  1. Oracle Enterprise ManagerまたはSRVCTLを使用して単一のサービスを作成します。

    管理者管理データベースの場合は、優先インスタンスとして1つのインスタンスのみを定義します。次の例に示すとおり、必要な数の使用可能なインスタンスを指定できます。 

    $ srvctl add service -db crm -service xa_01.example.com -preferred RAC01
  -available RAC02,RAC03

    ポリシー管理データベースの場合は、使用するサーバー・プールを指定して、サービスのカーディナリティをSINGLETONに設定します。次に例を示します。 

    $ srvctl add service -db crm -service xa_01.example.com -serverpool dtp_pool
  -cardinality SINGLETON

  2. サービスのDTPパラメータ(-dtp)をTRUEに設定します(デフォルト値はFALSEです)。Oracle Enterprise ManagerまたはSRVCTLを使用して、単一のサービスのDTPプロパティを変更できます。次の例では、SRVCTLを使用してxa_01.example.comサービスを変更する方法を示しています。 

    $ srvctl modify service -db crm -service xa_01.example.com -dtp TRUE

    注意:

    アプリケーションでDTPサービスを必要する場合は、-dtpパラメータを使用してください。それ以外の場合は、-dtpパラメータを指定していない前述の例を使用してください。

関連項目

5.4.5 管理者管理データベースのサービスの再配置

Oracle Real Application Clusters 11g リリース1 (11.1)以降では、グローバル・トランザクションとXAアフィニティが分散トランザクション処理(DTP)サービスの必要性に取ってかわります。

XAデプロイメントのほとんどは、ロード・バランシングと柔軟性が向上するように、DTP属性ではなくグローバル・トランザクションとXAアフィニティを使用するようになっています。

たとえば、XA_01など、DTPサービスを提供するインスタンスに障害が発生した場合、サービスは、その他のサービスと同じようにフェイルオーバーされます。セッションが存在するインスタンスは必ず1つのみであるという要件があるため、データベース・セッションの-f (強制停止)オプションが常に適用されます。

サービスが他のインスタンスに移行したら、使用可能なすべてのハードウェアで均等に負荷を再分散させるために、優先インスタンスにサービスを強制的に再配置する必要がある場合があります。GV$ACTIVE_SERVICESビューのデータを使用して、DTPサービスを再配置する必要があるかどうかを判断できます。

5.5 Oracle RACシャーディング

Oracle RACシャーディングは、表パーティションとOracle RACインスタンスの間にアフィニティを作成し、対応するパーティションを論理的に保持するインスタンスにパーティション化キーを指定するデータベース・リクエストをルーティングします。

Oracleでは、行のアフィニティをインスタンスで作成するデータベースで行の非結合行のサブセットに対して、各インスタンスがリクエストを常に取得するように、Oracle RACインスタンスにデータベース・リクエストをルーティングします。アフィニティにより、キャッシュ・ローカリティが改善され、ノード間の同期およびブロックのpingが低減されるため、Oracle RACの高いパフォーマンスおよびスケーラビリティが実現されます。

Oracle RACアフィニティのシャーディングでは、クライアントとサーバー側のサポートを使用して、Oracle Databaseのシャーディングに含まれているキーベースのルーティングを行います。Oracle接続プール(ユニバーサル接続プール、OCIなど)でのシャーディングのサポート用に実装されているものと同じAPIを使用して、データベースのシャーディング・キーを提供するアプリケーションは、シャーディングに対する実行と同じ方法で、キーベース・ルーティングを使用します。これにより、Oracle RACアフィニティが有効化されます。

シャーディング・キーの提供に必要なアプリケーションの変更は、アプリケーションのすべてのモジュールに影響を与える必要がありません。変更は、頻繁に実行されないデータベース・リクエストにのみ適用できます。接続文字列にシャーディング・キーを提供しないリクエストは、ロード・バランシング・ポリシーに基づいてルーティングされます。インスタンスに対してデータ・オブジェクトの明示的なマスターシップ割当てを行うため、キーのないリクエストはデータ・アフィニティに悪影響を及ぼしません。

注意:

Oracleでは、パーティション化された表にのみOracle RACアフィニティがサポートされます。データベース・スキーマを変更せずに、サポートされている方法を使用して表をパーティション化すると、この機能を有効にしてALTER SYSTEM ENABLE AFFINITYコマンドを実行できます。

アフィニティが有効なルーティングを利用するためにアプリケーションに変更を加える場合、独立した複数のデータベース間にデータが分散されているときは、シャーディングを利用することもできます。最大のスケーラビリティおよび障害の分離が必要な場合、後で分散シャーディングに移行できます。

関連項目

5.6 自動ワークロード・リポジトリ

自動ワークロード・リポジトリ(AWR)は、データベースのパフォーマンス統計値を収集、処理および保持します。

収集されたデータは、レポートとビューに表示できます。データベースでサービスを使用すると、AWRはサービス・レベルでメトリックを追跡します。

メトリックは、時間、トランザクション、データベース・コールなど、様々な単位に対して測定できます。たとえば、データベース・コール/秒はメトリックです。サーバーによって生成されるアラートは、ユーザー指定のしきい値を超えたり、必要なしきい値に達しない場合、これらのメトリックに基づいて発行されます。その後で、データベースまたはシステム管理者は、次のように応答できます。

  • Oracle Databaseリソース・マネージャを使用して、あるサービスのサービス・レベルの優先順位を他のサービスよりも高くする

  • オーバーロード状態になったプロセスを停止する

  • サービス・レベル要件を変更する

  • サービス品質の変更に応答するためにリカバリ例を実施する

AWRメトリックおよびパフォーマンス・アラートを使用すると、サービス・レベルが変更されても、継続的なサービスの可用性を維持できます。また、データベース・サービスによって提供されるサービスの品質を測定できます。

AWRによって、Oracle Clusterwareのワークロード管理フレームワークおよびデータベース・リソース・マネージャにおけるパフォーマンス・データ表現の永続性とグローバル性が保証されます。この情報によって、Oracle Databaseはサービス別にジョブ・クラスをスケジュールしたり、コンシューマ・グループに優先順位を割り当てることができます。必要に応じて、Oracle Enterprise ManagerまたはSRVCTLを使用して、手動でワークロードを再度均等に分散させることができます。一連のセッションを切断しても、サービスを続行させておくこともできます。

注意:

DBMS_SERVICEパッケージを、Oracle RACデータベースが使用するサービスに使用することはお薦めしません。SRVCTLまたはOracle Enterprise Managerを使用してOracle RAC用のデータベース・サービスを作成します。

関連項目

5.7 自動ワークロード・リポジトリを使用したサービスのパフォーマンスの測定

サービスによってパフォーマンス・チューニングに新たな局面が加わります。サービスにより、ワークロードの視覚化と測定が可能になり、リソース使用量と待機時間はアプリケーションに起因すると考えられるようになるためです。

すべてのセッションが匿名で共有されている多くのシステムでは、セッションおよびSQLを使用したチューニングのかわりに、サービスおよびSQLを使用したチューニングを実行します。

AWRでは、データベースで実行されているすべてのサービスと作業の応答時間、スループット、リソース使用量および待機イベントの情報など、パフォーマンス統計が保持されます。また、サービスのメトリック、統計、待機イベント、待機クラスおよびSQLレベルのトレースも保持されます。さらに、オプションとして、特定の統計を監視するためのモジュールをアプリケーションで定義して、これらの統計をカスタマイズできます。また、このモジュール内に、重要なビジネス・トランザクションで特定の統計値に応答して実行されるアクションを定義することもできます。

モジュールおよびアクションの監視を有効にするには、DBMS_MONITOR PL/SQLパッケージを使用します。たとえば、erpサービスを使用する接続の場合、次のコマンドを使用すると、payrollモジュールのexceptions payアクションを監視できます。 

EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(SERVICE_NAME => 'ERP', 
   MODULE_NAME=> 'PAYROLL', ACTION_NAME => 'EXCEPTIONS PAY');

erpサービスを使用する接続の場合、次のコマンドを使用すると、payrollモジュールのすべてのアクションを監視できます。 

EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(SERVICE_NAME => 'ERP', 
   MODULE_NAME=> 'PAYROLL', ACTION_NAME => NULL);

アプリケーション・モジュールとアクションの監視が有効化されたことを確認するには、DBA_ENABLED_AGGREGATIONSビューを使用します。

サービスによる統計の収集およびトレースは、Oracle RACデータベース全体を対象とします。また、Oracle RACデータベースと非クラスタのOracle Databaseのどちらの場合も、インスタンスの再起動やサービスの再配置が行われても統計の集計は失われません。

サービス名、モジュール名およびアクション名は、V$SESSION、V$ACTIVE_SESSION_HISTORYおよびV$SQLビューで確認できます。コール回数およびパフォーマンス統計は、V$SERVICE_STATS、V$SERVICE_EVENT、V$SERVICE_WAIT_CLASS、V$SERVICEMETRICおよびV$SERVICEMETRIC_HISTORYで確認できます。重要なトランザクションで統計の収集を有効にしている場合、V$SERV_MOD_ACT_STATSビューを使用すると、各データベース・インスタンスのそれぞれのサービス名、モジュール名およびアクション名に対して、コール速度を確認できます。

SQL*Plusスクリプトの次のサンプルを実行すると、5秒間隔でサービス品質の統計が収集されます。これらのサービス品質の統計を使用して、サービスの品質を監視したり、作業を割り当てたり、サービスをOracle RAC全体のインスタンス間で均等に分散できます。

SET PAGESIZE 60 COLSEP '|' NUMWIDTH 8 LINESIZE 132 VERIFY OFF FEEDBACK OFF
COLUMN service_name FORMAT A20 TRUNCATED HEADING 'Service'
COLUMN begin_time HEADING 'Begin Time' FORMAT A10
COLUMN end_time HEADING 'End Time' FORMAT A10
COLUMN instance_name HEADING 'Instance' FORMAT A10
COLUMN service_time HEADING 'Service Time|mSec/Call' FORMAT 999999999
COLUMN throughput HEADING 'Calls/sec'FORMAT 99.99 
BREAK ON service_name SKIP 1 
SELECT 
    service_name 
  , TO_CHAR(begin_time, 'HH:MI:SS') begin_time 
  , TO_CHAR(end_time, 'HH:MI:SS') end_time 
  , instance_name 
  , elapsedpercall  service_time
  ,  callspersec  throughput
FROM  
    gv$instance i     
  , gv$active_services s     
  , gv$servicemetric m 
WHERE s.inst_id = m.inst_id  
  AND s.name_hash = m.service_name_hash
  AND i.inst_id = m.inst_id
  AND m.group_id = 10
ORDER BY
   service_name
 , i.inst_id
 , begin_time ;

5.8 自動ワークロード・リポジトリ・サービスのしきい値とアラート

サービス・レベルのしきい値を使用すると、実際のサービス・レベルとサービスの必須レベルを比較できます。これによって、満足するサービス・レベルが提供されているかどうかを認識できます。最終的な目標は、基準を満たしたサービス・レベルを提供する、予測可能なシステムを構成することです。最小限のリソース使用量で可能なかぎり速く実行することは必要ではなく、必要なのは、サービスの品質を満たすことです。

AWRを使用すると、コールの応答時間(ELAPSED_TIME_PER_CALL)およびコールのCPU時間(CPU_TIME_PER_CALL)の2つのパフォーマンスしきい値を、サービスごとに明示的に指定できます。応答時間のしきい値は、各サービスの各ユーザー・コールの経過時間が特定の値を超えないようにすることを示すもので、コールのCPU時間のしきい値は、各サービスの各コールによるCPUの使用時間が特定の値を超えないようにすることを示すものです。応答時間は、ユーザーのためのコールの実行に支障を与える可能性があるすべての遅延および障害を反映する基本的な測定単位です。また、応答時間では、Oracle RACデータベースのノード間における、ノード別の処理能力の差異も確認できます。

Oracle RACデータベースの各インスタンスに、これらのしきい値を設定する必要があります。経過時間およびCPU時間は、サーバー側のコールの経過時間を移動平均法で算出した時間です。AWRは経過時間およびCPU時間を監視し、パフォーマンスがしきい値を超えた場合には、AWRアラートを発行します。これらのアラートに対してOracle Enterprise Managerのジョブを使用してアクションをスケジュールすることも、アラート受信時にプログラムによってアクションが発生するようにアクションをスケジュールすることもできます。アラートが発行された場合は、ジョブの優先順位を変更したり、オーバーロード状態になったプロセスを停止したり、サービスを再配置、起動または停止して応答します。これによって、需要量に変動が発生した場合でも、サービスの可用性を維持できます。

この項には次のトピックが含まれます:

5.8.1 サービスおよびしきい値のアラートの例

この例では、payrollサービスのしきい値を確認する必要があります。この情報は、AWRレポートを使用して取得できます。システムが最適な状態で稼働しているときに、いくつかの連続した時間間隔で実行したレポートの結果を比較する必要があります。たとえば、payrollアプリケーションがアクセスするサーバーで、毎週木曜日に使用率がピークに達する午後1時から午後5時までの間にAWRレポートを実行するとします。AWRレポートには、payrollサービスを含む各サーバーのコールについて、応答時間(経過データベース時間)およびCPUの使用時間(CPU時間)が含まれます。また、AWRレポートには、完了した作業のブレークダウンおよび応答時間に影響を与えている待機時間も記録されます。

DBMS_MONITORを使用して、payrollサービスのコールごとの経過時間に対する警告しきい値に0.5秒(500000マイクロ秒)を設定します。また、payrollサービスのコールごとの経過時間の重要な警告のしきい値を0.75秒(750000マイクロ秒)に設定します。

この例では、payrollサービスのしきい値を次のように追加します。 

EXECUTE DBMS_SERVER_ALERT.SET_THRESHOLD( 
METRICS_ID => DBMS_SERVER_ALERT.ELAPSED_TIME_PER_CALL 
, warning_operator => DBMS_SERVER_ALERT.OPERATOR_GE 
, warning_value => '500000' 
, critical_operator => DBMS_SERVER_ALERT.OPERATOR_GE 
, critical_value => '750000' 
, observation_period => 30 
, consecutive_occurrences => 5 
, instance_name => NULL 
, object_type => DBMS_SERVER_ALERT.OBJECT_TYPE_SERVICE 
, object_name => 'payroll');

次のSELECT文を使用すると、しきい値の構成がすべてのインスタンスに設定されていることを確認できます。 

SELECT METRICS_NAME, INSTANCE_NAME, WARNING_VALUE, CRITICAL_VALUE, 
OBSERVATION_PERIOD FROM dba_thresholds ;

5.8.2 サービス、モジュールおよびアクション監視の有効化

各サービス内の重要なモジュールおよびアクションに対するパフォーマンス・データのトレース機能を有効にできます。パフォーマンス統計は、V$SERV_MOD_ACT_STATSビューで参照できます。たとえば、次のように設定できます。

  • ERPサービスで、payrollモジュール内のexceptions payアクションを監視します。

  • ERPサービスで、payrollモジュール内のすべてのアクションを監視します。

  • HOT_BATCHサービスで、postingモジュール内のすべてのアクションを監視します。

次のコマンドは、サービスのモジュールとアクションの監視を有効化する方法を示します。

EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(service_name => 'erp', module_name=>
 'payroll', action_name => 'exceptions pay');
EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(service_name => 'erp', module_name=>
 'payroll');
EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(service_name => 'hot_batch', 
module_name =>'posting');

サービス、モジュールおよびアクションの監視が有効化されいてることを確認するには、次のSELECT文を使用します。 

COLUMN AGGREGATION_TYPE FORMAT A21 TRUNCATED HEADING 'AGGREGATION'
COLUMN PRIMARY_ID FORMAT A20 TRUNCATED HEADING 'SERVICE'
COLUMN QUALIFIER_ID1 FORMAT A20 TRUNCATED HEADING 'MODULE'
COLUMN QUALIFIER_ID2 FORMAT A20 TRUNCATED HEADING 'ACTION'
SELECT * FROM DBA_ENABLED_AGGREGATIONS ;

出力は、次のようなものです。 

AGGREGATION            SERVICE                MODULE        ACTION
------------           --------------------   ----------    -------------
SERVICE_MODULE_ACTION  erp                    payroll       exceptions pay
SERVICE_MODULE         erp                    payroll
SERVICE_MODULE         hot_batch              posting

5.9 Oracleサービスの使用方法

ワークロードまたはアプリケーションのグループを管理するために、特定のアプリケーションまたはアプリケーションの一部の操作に割り当てるサービスを定義できます。また、作業の種類ごとにサービスとしてグループ化することもできます。たとえば、オンライン・ユーザーはあるサービスを使用し、バッチ処理は別のサービスを使用し、レポートはまた別のサービスを使用してデータベースに接続することができます。

1つのサービスを共有するすべてのユーザーで、サービス・レベルの要件を同じにすることをお薦めします。サービスには個別の特性を定義できるため、各サービスはそれぞれ別々の作業単位にできます。サービスの使用時には、多数のオプションを使用できます。これらのオプションを実装する必要はありませんが、それらを使用すると、アプリケーションのパフォーマンスが最適化できます。

5.10 サービスのデプロイメント・オプション

この項では、次のサービスのデプロイメントについて説明します。

5.10.1 Oracle RACデータベースにおけるサービスの使用

サービスによって、位置の透過性がもたらされます。サービス名は複数のデータベース・インスタンスを識別することができ、インスタンスは複数のサービスに属することができます。複数のデータベース機能で、Oracle RACデータベース用のサービスを使用します。

この項には次のトピックが含まれます:

5.10.1.1 サービスのOracle Clusterwareリソース

サービスを定義すると、リソース・プロファイルは自動的に作成されます。リソース・ファイルには、Oracle Clusterwareによるサービスの管理方法と、PREFERREDインスタンスが停止した場合にサービスがフェイルオーバーされるインスタンスが定義されています。また、リソース・プロファイルでは、インスタンスおよびデータベースに対するサービスの依存性も定義します。この依存性の情報によって、データベースが停止した場合に、インスタンスおよびサービスが自動的に正しい順序で停止されます。

5.10.1.2 サービスのデータベース・リソース・マネージャ・コンシューマ・グループのマッピング

サービスはOracle Resource Managerと統合されており、リソース・マネージャでは、サービスを使用してインスタンスに接続するユーザーが使用するリソースを制限できます。Oracle Resource Managerでは、コンシューマ・グループをサービスにマッピングできるため、そのサービスを使用してインスタンスに接続しているユーザーは、指定されたコンシューマ・グループのメンバーになります。Oracle Resource Managerは、インスタンス・レベルで動作します。

5.10.1.3 AWRによるサービスごとのパフォーマンス監視

自動ワークロード・リポジトリ(AWR)によって生成されるメトリック・データは、様々なグループ(イベント、イベント・クラス、セッション、サービス、表領域メトリックなど)に編成されます。通常、Oracle Enterprise ManagerまたはAWRレポートを使用してAWRデータを表示します。

5.10.1.4 パラレル操作とサービス

デフォルトでは、Oracle RAC環境で、パラレルで実行されるSQL文はクラスタ内のすべてのノードで実行できます。このクロスノードまたはノード間パラレル実行を適切に実現するには、ノード間パラレル実行によってインターコネクト・トラフィックが増大する可能性があるため、Oracle RAC環境でのインターコネクトのサイズが適切である必要があります。ノード間パラレル実行を制限するには、初期化パラメータPARALLEL_FORCE_LOCALを使用してOracle RAC環境でパラレル実行を制御します。このパラメータをTRUEに設定すると、パラレル実行サーバーは、SQL文が開始されたのと同じOracle RACノードからのみ実行できます。

サービスを使用して、パラレルSQL操作に使用できるインスタンスの数を制限します。デフォルトのデータベース・サービスを使用すると、パラレルSQL操作は、使用可能なすべてのインスタンスで実行できます。それぞれが1つ以上のインスタンスを含むサービスを必要な数のみ作成できます。パラレルSQL操作が開始されると、パラレル実行サーバーは、最初のデータベース接続で使用された特定のサービスを提供するインスタンス上でのみ起動されます。

PARALLEL_INSTANCE_GROUPは、Oracle RACパラメータで、サービスとともに使用すると、パラレル問合せ操作を、限られた数のインスタンスに制限できます。パラレル問合せ操作を、限られた数のインスタンスに制限するには、PARALLEL_INSTANCE_GROUP初期化パラメータにサービスの名前を設定します。これは、パラレル・リカバリやGV$問合せの処理などの他のパラレル操作には影響しません。

5.10.1.5 Oracle StreamsおよびOracle RAC

Oracle StreamsはOracle RAC機能を利用します。

Oracle StreamsがOracle RAC環境で構成されている場合、各キュー表には所有するインスタンスがあります。キュー表をホストするインスタンスに障害が発生しても、Oracle RACデータベースの別のインスタンスがキュー表の所有インスタンスになるため、Oracle Streamsは継続して稼働できます。

また、Oracle RACデータベースでは、バッファ・キューごとにサービスが作成されます。インスタンスの起動や停止などのために所有権が切り替わる場合、このサービスは常に、宛先キューの所有者インスタンスで実行され、このキューの所有権に従います。このサービスは、キューからキューへの伝播で使用されます。

5.10.2 サービスの特性

データベースに新しいサービスを作成した場合は、サービスごとに自動ワークロード管理の特性を定義する必要があります。サービスの特性には、次のものが含まれます。

5.10.2.1 サービス名

各サービスにはサービス名があります。クライアントは、サービス名を使用して1つ以上のインスタンスに接続します。サービス名は、システム全体で一意である必要があります。

5.10.2.2 サービス・エディション

データベース・オブジェクトのエディションベースの再定義を使用すると、アプリケーションのオブジェクトが使用中であってもそれらのオブジェクトをアップグレードできます。データベース・サービスの作成時にそのエディション属性を設定したり、既存のサービスを変更してエディションを設定できます。サービス・エディションを設定すると、そのサービスを使用する接続は、このエディションを初期セッション・エディションとして使用します。サービスでエディション名が指定されていない場合、初期セッション・エディションはデータベースのデフォルト・エディションです。

次のように、SRVCTLを使用してサービス・エディションを設定できます。

$ srvctl modify service –db hr –s crmsrv –edition e2
5.10.2.3 サービス管理ポリシー

Oracle Clusterwareを使用してデータベースを管理する場合、-policyパラメータを指定してsrvctl add serviceコマンドを使用してサービスを追加するときに、個々のデータベース・サービス用に起動オプションを構成できます。

サービスの管理ポリシーをAUTOMATIC(デフォルト)に設定した場合は、SRVCTLを使用してデータベースを起動するとサービスが自動的に起動されます。管理ポリシーをMANUALに設定した場合、サービスは自動起動されず、SRVCTLを使用して手動で起動する必要があります。MANUALに設定しても、Oracle Clusterwareは、実行中のサービスを監視し、障害が発生すると再起動されます。Oracle RAC 11gリリース2(11.2)より前は、すべてのサービスが、MANUAL管理ポリシーで定義されているかのように動作していました。

CRSCTLを使用したOracle Clusterwareの停止および再起動は障害として扱われ、サービスが実行中の場合は再起動されます。

注意:

管理者管理データベースの自動サービスを使用する場合、計画的なデータベースの起動中に、優先インスタンスではなく最初のインスタンスでサービスが起動することがあります(開始されたインスタンスが優先サービスと使用可能なサービスを組み合せたリストに含まれている場合)。

関連項目

5.10.2.4 サービスのデータベース・ロール

目的の環境でOracle Data Guardを構成してある場合は、サービスの追加時または変更時に、SRVCTLを使用して該当するコマンドに-roleパラメータを指定することでサービスのロールを定義できます。

サービスにロールを指定すると、Oracle Clusterwareは、データベース・ロールがそのサービスに指定したロールに一致した場合にのみ自動的にサービスを起動します。有効なロールは、PRIMARY、PHYSICAL_STANDBY、LOGICAL_STANDBYおよびSNAPSHOT_STANDBYで、1つのサービスに複数のロールを指定できます。

注意:

サービス・ロールのみがサービスの自動開始を制御します。手動で開始するSRVCTLを使用することで、ロールが一致しない場合でもサービスは正常に実行されます。

REDO Apply (フィジカル・スタンバイ・データベース)は、ユーザーが構成できるすべてまたは一部のスタンバイ・インスタンス上で実行できます。別のスタンバイ・インスタンスを追加することで、必要に応じてREDO Applyのパフォーマンスをスケールできます。

クラスタ内の複数のデータベースが同じサービス名を提供すると、Oracle RACは、該当するすべてのデータベースにわたってそのサービスへの接続を均等に分散します。これはOracle Data Guardのスタンバイ・データベースおよびアクティブ・データベースに役に立ちますが、サービスへのクライアント接続を特定のデータベースに割り当てる必要がある場合、サービス名はクラスタ内で一意である(他のデータベースによって提供されない)必要があります。

5.10.2.5 インスタンスのプリファレンス

管理者管理データベースに対してサービスを定義する場合は、SRVCTLに-preferredパラメータを使用して、そのサービスを通常サポートするインスタンスを定義します。

このようなインスタンスを、優先インスタンスといいます。サービスの優先インスタンスが失敗した場合に備えて、-availableパラメータを指定してSRVCTLを使用し、サービスをサポートするその他のインスタンスを定義することもできます。このようなインスタンスを、使用可能インスタンスといいます。

優先インスタンスを指定する場合は、サービスが通常実行されるインスタンスの数を指定します。これは、サービスの最大カーディナリティです。Oracle Clusterwareは、サービスを構成したインスタンス数で常にサービスが実行されることを確認しようとします。その後は、インスタンス障害またはサービスの計画的な再配置のために、使用可能インスタンスでサービスが実行される場合があります。

インスタンスが失敗した場合、Oracle Clusterwareは優先リストおよび使用可能なリストを順序付けられたリストと解釈するため、リストに複数のインスタンスがあると、Oracle Clusterwareによってサービスがどの使用可能インスタンスに再配置されるかをある程度制御できます。ただし、計画済操作時は、サービスを現在提供していない、優先リストまたは使用可能リスト内のインスタンスにサービスを手動で転送できます。

Oracle Databaseでは、使用可能インスタンスに移動されたサービスは、優先インスタンスを再起動しても、優先インスタンスには戻りません。これには、次の理由があります。

  • サービスが、指定した数のインスタンスで実行されている。

  • 現在のインスタンスでサービスを維持することによって、より高度なサービス可用性が提供される。

  • サービスを最初の優先インスタンスに戻さないことで、2回目の機能停止が回避される。

ただし、FANコールアウトを使用して、優先インスタンスへのフェイルバックを簡単に自動化することもできます。

5.10.2.6 サーバー・プールの割当て

ポリシー管理データベースのサービスを定義する場合、-serverpoolパラメータを指定したSRVCTLを使用して、データベースがホストされているサーバー・プールにサービスを割り当てます。

サービスは、-cardinalityパラメータを使用して、UNIFORM (サーバー・プール内のすべてのインスタンスで実行)またはSINGLETON (サーバー・プール内の単一インスタンスでのみ実行)のいずれかとして定義できます。singletonサービスの場合、Oracle RACはそのサービスがアクティブなサーバー・プール内でインスタンスを選択します。そのインスタンスで障害が発生すると、サービスはサーバー・プール内の別のインスタンスにフェイルオーバーします。サービスは1つのサーバー・プールでのみ実行でき、すべてのサーバー・プールに少なくとも1つのサービスを含めることをお薦めします。

注意:

Oracle Database Quality of Service Management (Oracle Database QoS Management)では、サーバー・プールの最大サイズが1である場合、そのサーバー・プールのsingletonサービスを管理します。

5.10.2.7 ランタイム接続ロード・バランシングのロード・バランシング・アドバイザの目標

ランタイム接続ロード・バランシングを使用すると、アプリケーションは、ロード・バランシング・アドバイザ・イベントを使用して、ユーザーにより適切なサービスを提供できます。Oracle JDBC、Oracle Universal Connection Pool for Java、OCIセッション・プール、ODP.NETおよびOracle WebLogic Server Active GridLink for Oracle RACクライアントは、ロード・バランシング・アドバイザリ・イベントを利用するために自動的に統合されます。ロード・バランシング・アドバイザは、サービスに対してインスタンスで提供されている現在のサービス・レベルをクライアントに通知します。ロード・バランシング・アドバイザを有効にするには、サービスを作成または変更するときに、SRVCTLに-rlbgoalパラメータを使用します。

また、そのインスタンスに送るワークロードの推奨量を提示します。最適なサービス品質(単一のトランザクションが完了した効率)または最適なスループット(完了ジョブまたは長時間の問合せが完了した効率)のどちらに基づいてサービスに接続するかは、目標によって決定されます。

5.10.2.8 接続ロード・バランシングの目標

Oracle Net Servicesでは、接続ロード・バランシングにより、サービスをサポートしているすべてのインスタンスにユーザー接続を分散できます。

各サービスに対して、-clbgoalパラメータを指定したSRVCTLを使用して、接続時ロード・バランシングの目標を設定し、リスナーにロード・バランシングを使用させる方法を定義できます。接続は、リスナーにセッション数を使用するように指定するLONG (接続プールやSQL*FORMSなど)、またはリスナーに応答時間やスループットの統計を使用するように指定するSHORTに分類されます。

ロード・バランシング・アドバイザが有効化されていると(-rlbgoalパラメータがNONEに設定されていない)、接続ロード・バランシングはロード・バランシング・アドバイザを使用しようとします(SHORTまたはLONGのどちらに設定されているかは関係ありません)。ロード・バランシング・アドバイザがSHORTに設定されている場合は、サービスのGOODNESS値を使用して、すべての接続リクエストが1つのインスタンスに集中しないようにします。ロード・バランシング・アドバイザがLONGに設定されている場合は、run queue length (サービスが均一でない場合)、またはsession count (均一のサービス分散がある場合)を使用します。

5.10.2.9 分散トランザクション処理

Oracle XAアプリケーションには固有の要件があります。Oracleでは、Oracle RAC全体にわたるグローバル・トランザクションを使用できます。最適なパフォーマンスを得るには、ほとんどのトランザクションにXAアフィニティ(同一インスタンスのすべてのブランチ)を使用して、必要に応じてグローバル・トランザクションを使用します。接続プール(ユニバーサル接続プールやWebLogic Serverなど)でXAアフィニティを使用できます。SRVCTLを使用して作成したシングルトン・サービスを使用することもできます。さらに、SRVCTLを使用して分散トランザクション処理パラメータ(-dtp)をTRUEに設定します(同一のOracle XAブランチを一時停止および再開する場合)。ただし、これは計画メンテナンスのローリングを提供しないため、通常は使用しないでください。

5.10.3 デフォルトのサービス接続

Oracle RAC Databaseには、DB_UNIQUE_NAMEが設定されている場合はこれにより識別され、設定されていない場合はDB_NAMEまたはPDB_NAMEで識別されるOracle Databaseサービスが含まれます。このデフォルトのサービスは、Oracle RAC環境のすべてのインスタンスで常に使用可能です(制限モードのインスタンスを除く)。このサービスまたはサービスのプロパティは、変更できません。また、データベースでは、次の2つの内部サービスがサポートされています。

  • SYS$BACKGROUND(バックグラウンド・プロセスのみで使用されるサービス)

  • SYS$USERS(どのアプリケーション・サービスとも関連付けられていないユーザー・セッションのデフォルト・サービス)

これらのサービスはすべて、内部管理に使用されます。計画済停止やOracle Data Guardへのフェイルオーバーを実行するためにこれらの内部サービスを停止したり無効にすることはできません。これらのサービスをクライアント接続に使用しないでください。

注意:

明示的に管理できるのは、自分が作成するサービスにかぎられます。データベースの機能によって内部サービスが作成される場合、そのサービスはこの章の情報を使用して管理できません。

5.10.4 制限されたサービス登録

この機能により、デフォルトでローカルIPアドレスからのリスナー登録のみが許可され、登録要求がリスナーにより許可される一連のIPアドレスまたはサブネットを構成および動的に更新する機能が提供されます。

セキュリティはすべての企業で高い優先度を持ち、ネットワーク・セキュリティおよびデータベースへのアクセスの制御は、セキュリティ確保全体における不可欠な要素です。リスナーへのデータベース・インスタンスの登録は、要求元が有効なノードである場合にのみ成功します。ネットワーク管理者は、有効なノードおよび除外ノードのリストを指定したり、有効なノードの確認を無効にすることができます。有効なノードのリストでは、データベースに登録できるノードやサブネットを明示的にリストします。除外ノードのリストでは、データベースに登録できないノードを明示的にリストします。動的登録を制御することによって、Oracle RACデプロイメントの管理性およびセキュリティが向上します。

登録のための有効なノードの確認(VNCR)はデフォルトで有効になっています。デフォルトの構成では、登録リクエストはクラスタ内のノードからのみ可能です。登録リクエストはプライベート・サブネットにリダイレクトされ、クラスタ内のノードのみがプライベート・サブネットにアクセスできるためです。非SCANリスナーでは、ローカル・ノード上のインスタンスからの登録のみが受け入れられます。registration_invited_nodes_aliasパラメータをlistener.oraファイルで使用するか、次のようにSRVCTLを使用してSCANリスナーを変更することによって、リモート・ノード、または有効なノードのリスト上のSCANリスナーのサブネット外のノードを手動で含める必要があります。 

$ srvctl modify scan_listener -invitednodes node_list -invitedsubnets subnet_list

関連項目

5.11 サービスの管理

Oracle Enterprise ManagerおよびSRVCTLユーティリティを使用して、管理サービスを作成および管理できます。次の項では、これらのツールを使用して、サービスに関連するタスクを実行する方法について説明します。

この項には次のトピックが含まれます:

注意:

DBMS_SERVICEパッケージを使用して、サービスとサービス属性を作成または変更することもできますが、このパッケージを使用して行われた設定は、SRVCTLによって上書きされます。DBMS_SERVICEパッケージは、Oracle RACデータベースが使用するサービスで使用したり、Oracle Restartの使用時やOracle Clusterwareによる単一インスタンス・データベースの管理時に使用することはお薦めしません。

5.11.1 サービスの管理の概要

サービスを作成して管理する場合、データベースで実行する作業を管理しやすい単位に分割します。

サービスを使用する目的は、データベース・インフラストラクチャを最大限有効に利用することです。ビジネス要件に基づいて、サービスを作成およびデプロイできます。Oracle Databaseは各サービスのパフォーマンスを計測できます。DBMS_MONITORパッケージを使用すると、サービス内のアプリケーション・モジュールおよびモジュールの個別のアクションを両方定義して、これらのアクションのしきい値を監視できるようになり、これによってワークロードを管理して必要に応じて容量を供給することができます。

データベースに新しいサービスを作成した場合は、サービスごとに自動ワークロード管理の特性を定義する必要があります(「サービスの特性」を参照)。

関連項目:

OracleクラスタでOracle Database QoS Managementを使用している場合、データベース・サービスの構成方法の詳細は、『Oracle Database Quality of Service Managementユーザーズ・ガイド』を参照してください。

サービスの作成に加えて、次の作業を実行できます。

  • サービスの削除。作成したサービスは削除できます。ただし、Oracle Databaseで作成されたデフォルトのデータベース・サービスのプロパティは、削除したり、変更することはできません。

  • サービスのステータスの確認。サービスは、使用可能インスタンスごとに別々のロールが割り当てられる場合があります。多くのサービスを使用する複雑なデータベースでは、すべてのサービスの詳細を把握しておくことは困難な場合があります。そのため、インスタンスごとまたはサービスごとにステータスの確認が必要になる場合があります。たとえば、特定のインスタンス、または特定のインスタンスを実行するOracleホームに変更を加える前に、このインスタンスのサービスのステータスの確認が必要な場合があります。

  • データベースまたはインスタンスのサービスの起動および停止。インスタンスへのクライアント接続に使用するサービスは、事前に起動されている必要があります。たとえば、SRVCTLコマンドsrvctl stop database -db db_unique_nameを実行してデータベースを停止した場合(db_unique_nameは停止するデータベース名)、そのデータベースへのすべてサービスが停止されます。サービス管理ポリシーによっては、データベースの起動時にサービスを手動で再起動する必要がある場合があります。srvctl stop databaseおよびsrvctl stop serviceの両方のコマンドは、接続を強制的に切断する-forceオプションを受け入れます。計画済停止のセッションを排出する場合、-forceオプションは使用しません。

    注意:

    Oracle RACデータベースでOracle Database QoS Managementが有効になっている場合、サービスは、停止後に自動的に再起動されます。

  • サービスのコンシューマ・グループへのマッピング。サービスをリソース・マネージャのコンシューマ・グループにマッピングして、サービスがインスタンスで使用可能なリソースの量を制限することができます。コンシューマ・グループを作成し、サービスをこのグループにマッピングする必要があります。

  • データベースまたはインスタンスのサービスの有効化および無効化。デフォルトでは、障害が発生すると、Oracle Clusterwareはサービスの再起動を自動的に試みます。サービスを無効化すると、この動作を回避できます。サービスの無効化は、データベースまたはインスタンスのメンテナンスを実行する必要がある場合、たとえばアップグレードの実行中に接続要求の成功を回避する必要がある場合などに便利です。

  • 別のインスタンスへのサービスの再配置。たとえば、クラスタ・ノードを追加または削除した後に、あるインスタンスから別のインスタンスにサービスを移動して、ワークロードを再分散させることができます。

注意:

  • サービスを使用する場合は、SERVICE_NAMESパラメータに値を設定しないでください(作成したサービスおよびデフォルトのデータベース・サービスに対するこのパラメータの設定値はOracle Databaseによって制御されます)。この章で説明しているサービスの機能は、SERVICE_NAMESを設定した場合にOracle Databaseで使用可能な機能とは直接関係ありません。また、このパラメータに値を設定した場合、サービスの使用によって得られるメリットが失われてしまう可能性があります。

  • サービス・ステータス情報は、SRVCTLから、またはサービス関連データベース・ビュー(dba_servicesなど)から取得する必要があります。

  • DISPATCHERS初期化パラメータを使用してサービスを指定する場合は、SERVICE_NAMESパラメータ内のすべてのサービスが無効になり、管理できなくなります。(たとえば、SRVCTLコマンドでサービスを停止すると、サービスに接続しているユーザーは停止されません。)

関連項目

5.11.2 Oracle Enterprise Managerを使用したサービスの管理

「クラスタ管理データベース・サービス」ページは、サービスに関連するすべてのタスクを開始するためのマスター・ページです。

次のように、このページにアクセスします。

  1. Oracle Enterprise Managerで、クラスタ・データベースのホームページに移動します。

    関連項目:

    Oracle Enterprise Managerへのログインの詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

  2. 「可用性」メニューから、「クラスタ管理データベース・サービス」を選択して、「クラスタ管理データベース・サービス」ページを表示します。

  3. Oracle RACデータベースおよびホスト・オペレーティング・システムに対する資格証明を入力または確認し、「続行」をクリックして、「クラスタ管理データベース・サービス」ページを表示します。

「クラスタ管理データベース・サービス」ページで、ドリルダウンして次のタスクを実行できます。

  • クラスタのサービス・リストの表示

  • 現在、各サービスを実行しているインスタンスの表示

  • ポリシー管理環境でサービスを提供するサーバー・プールおよびノードの表示

  • 各サービスのステータスの表示

  • サービスの作成および編集

  • サービスの起動および停止

  • サービスの有効化および無効化

  • サービスのインスタンスレベルのタスクの実行

  • サービスの削除

注意:

クラスタ・データベースへアクセスするには、SYSDBA資格証明を所有している必要があります。「クラスタ管理データベース・サービス」では、SYSDBA以外での接続は許可されません。

関連項目

関連項目:

  • Oracle Enterprise Managerを使用したサービスの管理の詳細は、Oracle Enterprise Managerのオンライン・ヘルプを参照してください。

  • Oracle Enterprise Managerを使用したサービスの管理の詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。

5.11.3 SRVCTLを使用したサービスの管理

SRVCTLを使用してサービスを作成した場合、別のSRVCTLコマンドでそのサービスを起動する必要があります。

一方、後で手動でサービスを停止または再起動する必要がある場合もあります。さらに、自動的な再起動が実行されないようにサービスを無効化したり、サービスを手動で再配置したり、サービスに関するステータス情報を取得することもあります。次の項では、SRVCTLを使用して次の管理タスクを実行する方法について説明します。

5.11.3.1 SRVCTLを使用したサービスの作成

SRVCTLを使用してサービスを作成するには、コマンドラインでsrvctl add serviceコマンドを使用します。

関連項目

5.11.3.2 アプリケーション・コンティニュイティおよびトランザクション・ガードのサービスの作成

アプリケーション・コンティニュイティのサービスを構成するには、SRVCTLを使用してサービスを作成する場合、-failovertypeパラメータをTRANSACTIONに設定し、-commit_outcomeをTRUEに設定します。

アプリケーションでアプリケーション・コンティニュイティおよびトランザクション・ガードを使用する場合は、サービスを構成する必要があります。この項では、実装予定の機能に応じてこれらのアプリケーション・サービスを構成する方法について説明します。

アプリケーション・コンティニュイティのサービスの作成

また、アプリケーション・コンティニュイティおよびロード・バランシングのその他のサービス・パラメータに値を設定することもできます。

  • -replay_init_time: リプレイが開始できる時間を秒単位で指定します。リプレイが開始されるまでに許可する時間に基づいて値を選択することをお薦めします。デフォルト値は300秒です。

  • -retention: コミット結果情報がデータベース内に保持される時間(秒)を指定します。デフォルト値は86400 (1日)です。

  • -session_state: COMMITが実行され後にそのトランザクションの状態が変更された場合、セッションが失われている場合はトランザクションをリプレイしてその状態を再確立することはできません。アプリケーション・コンティニュイティを構成する場合、アプリケーションは、初期設定後のセッション状態が動的であるか静的であるか、および要求内の過去のCOMMIT操作を継続するのが適切であるかどうかに応じて分類されます。

    • 動的: (デフォルト)セッション状態の変更が初期化で完全にカプセル化されていない場合、およびフェイルオーバー時にコールバックで完全に取得できない場合、そのセッションは動的な状態です。要求内の最初のトランザクションがコミットされると、次の要求が開始されるまでフェイルオーバーは内部的に無効化されます。これは、ほとんどすべてのアプリケーションが要求に使用するデフォルト・モードです。

    • 静的: (要求での特殊設定) NLS設定やPL/SQLパッケージの状態など、すべてのセッション状態の変更を初期化コールバックで繰り返すことができる場合、そのセッションは静的な状態です。この設定は、セッション状態を変更しないデータベース診断アプリケーションのみに使用されます。コールバックによって再確立できない非トランザクション状態変更がリクエスト内にある場合は、STATICを指定しないでください。どの状態を指定すればよいかがわからない場合は、DYNAMICを使用します。

  • -failoverretry: 各接続試行に対する接続試行回数であり、推奨値は30です。

  • -failoverdelay: 各接続試行間の遅延(秒単位)であり、推奨値は10です。

  • -notification: FANは強く推奨されているため、この値をTRUEに設定して、OCIクライアントとODP.NetクライアントでFANを有効化します。

  • -clbgoal: 接続ロード・バランシングの場合、実行時ロード・バランシングの使用時はSHORTを使用します。

  • -rlbgoal: ランタイム・ロード・バランシングの場合は、SERVICE_TIMEに設定します。

ポリシー管理されたOracle RACデータベースに対してアプリケーション・コンティニュイティのサービスを作成するには、次のようなコマンドを使用しますが、racdbはOracle RACデータベースの名前を、app2は変更するサービスの名前を、そしてSvrpool1はサービスが提供されるサーバー・プールの名前を表します。 

$ srvctl add service -db racdb -service app2 -serverpool Srvpool1
  -failovertype TRANSACTION -commit_outcome TRUE -replay_init_time 1800
  -retention 86400 -notification TRUE -rlbgoal SERVICE_TIME -clbgoal SHORT
  -failoverretry 30 -failoverdelay 10

SRVCTLを使用してアプリケーション・コンティニュイティの既存のサービスを変更するには、次のようなコマンドを使用しますが、racdbは使用しているOracle RACデータベースの名前を、そしてapp1は変更するサービスの名前を表します。 

$ srvctl modify service -db racdb -service app1 -clbgoal SHORT
  -rlbgoal SERVICE_TIME -failoverretry 30 -failoverdelay 10
  -failovertype TRANSACTION -commit_outcome TRUE -replay_init_time 1800
  -retention 86400 -notification TRUE

トランザクション・ガードのサービスの作成

トランザクション・ガードは有効にするが、アプリケーション・コンティニュイティは有効にしない場合は、SRVCTLを使用してサービスを作成し、-commit_outcome TRUEのみを設定します。

SRVCTLを使用して、トランザクション・ガードを有効にするように既存のサービスを変更するには、次のようなコマンドを使用しますが、racdbは使用しているOracle RACデータベースの名前を、そしてapp2は変更するサービスの名前を表します。 

$ srvctl modify service -db racdb -service app2 -commit_outcome TRUE
  -retention 86400 -notification TRUE

前述の例では、-retentionパラメータは、履歴を保持する時間(秒単位)を指定しています。また、–notificationパラメータはTRUEに設定され、FANイベントを有効化しています。

トランザクション・ガードを使用するには、DBAは次のように権限を付与する必要があります。

GRANT EXECUTE ON DBMS_APP_CONT;
5.11.3.3 SRVCTLを使用したサービスの起動および停止

アプリケーションがサーバーを使用して接続するために、サービスを起動する必要があります。停止したサービスは、一時的に使用できなくなりますが、引き続き自動再起動およびフェイルオーバーの対象となっています。

サービスを起動または停止するには、コマンドラインで次のSRVCTL構文を入力します。 

$ srvctl start service -db db_unique_name [-service service_name_list]
    [-instance inst_name] [-startoption start_options]

$ srvctl stop service -db db_unique_name -service service_name_list
    [-instance inst_name] [-startoption start_options]
5.11.3.4 SRVCTLを使用したサービスの有効化および無効化

サービスを無効化にすると、Oracle Clusterwareは、そのサービスを自動起動、フェイルオーバーまたは再起動の対象とみなさなくなります。アプリケーション・メンテナンスを実行する場合は、そのメンテナンス操作が完了するまでサービスを無効化にすることで、Oracle Clusterwareが誤ってサービスを再起動しないようにできます。再び通常操作でサービスを使用できるようにするには、サービスを有効化します。

サービスを有効化および無効化するには、コマンドラインから次のSRVCTL構文を使用します。 

$ srvctl enable service -db db_unique_name -service service_name_list
    [-instance inst_name]
$ srvctl disable service -db db_unique_name -service service_name_list
    [-instance inst_name]
5.11.3.5 SRVCTLを使用したサービスの再配置

サービスを再配置するには、コマンドラインからsrvctl relocate serviceを実行します。このコマンドを使用するのは、サービスが使用可能インスタンスにフェイルオーバーしたが、そのインスタンスの再起動後に、優先インスタンスにサービスを移動させたい場合です。

次のコマンドを実行すると、crmサービスがインスタンスapps1からインスタンスapps3に再配置されます。 

$ srvctl relocate service -db apps -service crm -oldinst apps1 -newinst apps3

次のコマンドを実行すると、ノード構文を使用してcrmサービスがnode1からnode3に再配置されます。 

$ srvctl relocate service -db apps -service crm -currentnode node1
    -targetnode node3
5.11.3.6 SRVCTLを使用したサービス・ステータスの取得

サービスのステータスを取得するには、コマンドラインからsrvctl status serviceコマンドを実行します。たとえば、次のコマンドを実行すると、appsデータベースで実行中のサービスのステータスが戻されます。 

$ srvctl status service -db apps

Service erp is running on nodes: apps02,apps03
Service hr is running on nodes: apps02,apps03
Service sales is running on nodes: apps01,apps04
5.11.3.7 SRVCTLを使用したサービスの構成の取得

サービスの高可用性構成を取得するには、コマンドラインからsrvctl config serviceコマンドを実行します。たとえば、次のコマンドを実行すると、appsデータベースで実行中のerpサービスの構成が戻されます。 

$ srvctl config service -db apps -service erp

Service name: erp
Service is enabled
Server pool: pool1
Cardinality: 1
Disconnect: false
Service role: PRIMARY
Management policy: AUTOMATIC
DTP transaction: false
AQ HA notifications: true
Global: false
Commit Outcome: true
Failover type: TRANSACTION
Failover method: NONE
TAF failover retries: 30
TAF failover delay: 10
Connection Load Balancing Goal: LONG
Runtime Load Balancing Goal: SERVICE_TIME
TAF policy specification: NONE
Edition:
Pluggable database name:
Maximum lag time: ANY
SQL Translation Profile:
Retention: 86400 seconds
Replay Initiation Time: 1800 seconds
Session State Consistency: STATIC
Preferred instances: apps
Available instances:

5.12 グローバル・サービス

Oracle RACはデータベース・サービスをサポートし、単一クラスタ内のインスタンス間でのサービスレベル・ワークロード管理を有効にします。

グローバル・サービスでは、共有サービスを提供する一連のレプリケート・データベースに動的ロード・バランシング、フェイルオーバーおよびサービスの集中管理を提供します。この一連のデータベースには、Oracle Data Guard、Oracle GoldenGateまたはその他のレプリケーション・テクノロジによって相互接続されたOracle RACおよび非クラスタOracle Databaseが含まれる場合があります。

グローバル・サービスを作成および使用する場合は、次のワークロード管理機能を使用できます。

  • 優先データベースおよび使用可能なデータベースをグローバル・サービスに指定する機能

  • レプリケーション・ラグの処理

  • クライアントとサーバー間の地理的アフィニティ

  • 接続ロード・バランシング

  • ランタイム・ロード・バランシング

  • 内部データベース・サービス・フェイルオーバー

  • 高速接続フェイルオーバー

  • 接続時フェイルオーバー

  • アプリケーション・コンティニュイティ

  • トランザクション・ガード

  • 既存のクライアントとの下位互換性

注意:

SRVCTLを使用してOracle RACデータベース内のグローバル・サービスのインスタンス配置を管理できますが、GDSCTLを使用する場合は他のグローバル・サービス属性のみを管理できます。

関連項目

5.13 サービス指向バッファ・キャッシュ・アクセス

サービス指向バッファ・キャッシュ・アクセスでは、データが属するサービスによってデータを管理することでパフォーマンスが向上します。

サービスを経由したオブジェクトのアクセスは、徐々にデータベースにマップされて永続化されます。この情報は、パフォーマンス向上のために使用できます。サービスを通じてアクセスされるブロックは、サービスを実行しているインスタンス内にキャッシュされますが、それよりも、サービスを実行していない場所には情報がキャッシュされないということが重要になります。

この情報は、サービスの開始前に、キャッシュを事前ウォーミングする際にも使用できます。サービスの起動は、インスタンスの起動またはサービスの再配置のどちらかでトリガーされます。サービス指向バッファ・キャッシュ・アクセスは、そのサービスのユーザーに安定したパフォーマンスを提供します。これは、サービスのユーザーがアクセスするブロックが、新しく再配置されたインスタンスにキャッシュされるためです。

5.14 サービスへの接続: 例

次の例では、サービスを作成する方法を示し、次に異なるクライアント・メソッドを使用してこのサービスに接続するいくつかの例を示します。

この例では、ランタイム・ロード・バランシングで、サービスが次のように有効になっています。

  • サービス名: HR.example.com

    • CRMという名前のデータベース上で実行されています。

    • システムは4つのノードで構成されています。

  • -rlbgoalパラメータの値としてSERVICE_TIMEを指定します。

  • リスナーのSCANアドレスはrws3010104-scan.example.comです。

  • リスナー・ポートは1585です。

サービスのカーディナリティは2ですが、必要な場合は、任意のCRMデータベース・インスタンスによって提供できます。サービス構成は、次のとおりです。

  • 優先インスタンス: CRM1、CRM2

  • 使用可能なインスタンス: CRM3、CRM4

  • -clbgoalパラメータの値としてSHORTを指定します。

このサービスを使用するアプリケーションはアプリケーション・コンティニュイティを利用するため、-failovertypeおよび-commit_outcomeを設定する必要があります。デフォルトの保存パラメータを使用しますが、接続試行間に10秒の遅延を設定し、接続取得の失敗まで最大40回の再試行を設定します。

SRVCTLを使用したHRサービスの作成

次のように、SRVCTLを使用してHRサービスを作成します。

$ srvctl add service –db CRM –service HR.example.com –preferred CRM1,CRM2
  –available CRM3,CRM4 –clbgoal SHORT –failovertype TRANSACTION
  –commit_outcome TRUE –failoverdelay 10 –failoverretry 40

次のように、HR.example.comサービスを起動します。 

$ srvctl start service –db CRM –service HR.example.com

このサービスは、最大2つのインスタンス上で使用できるようになり、CRM1およびCRM2が優先インスタンスです。

JDBCアプリケーションからHRサービスへの接続

この例では、HRサービスに接続するアプリケーションは、JDBC thinドライバでJDBC Universal Connection Poolを使用するJDBCアプリケーションです。

この例では、URLは、データベース指定子にthinスタイルのサービス名形式を指定して構築されます。高速接続フェイルオーバーが有効化され、リモートOracle Notification Serviceが構成され、クラスタ上のOracle Notification Serviceデーモンはポート6200でリスニングします。

//import packages and register the driver
import java.sql.Connection;
import java.sql.SQLException;
import java.sql.Statement;
import oracle.ucp.jdbc.PoolDataSourceFactory;
import oracle.ucp.jdbc.PoolDataSource;

PoolDataSource  pds = PoolDataSourceFactory.getPoolDataSource();

//set the connection properties on the data source.
pds.setConnectionPoolName("FCFPool");
pds.setFastConnectionFailoverEnabled(true);
pds.setONSConfiguration("nodes=rws3010104-scan.example.com:6200");
pds.setConnectionFactoryClassName("oracle.jdbc.pool.OracleDataSource");
pds.setURL("jdbc:oracle:thin:@//rws3010104-scan.example.com:1585/HR.example.com");
pds.setUser("HR");
pds.setPassword("hr"); 
    
 
//Override any pool properties.
pds.setInitialPoolSize(5);
 
//Get a database connection from the datasource.
 
Connection conn = pds.getConnection();
 
// do some work
 
//return connection to pool
conn.close();
conn=null

関連項目


脚注の凡例

脚注1:

実行時接続ロード・バランシングは、基本的には作業リクエストをセッション・プール内で作業の処理に最も適切なセッションにルーティングする操作です。既存のセッション・プールからセッションを選択すると、有効になります。このため、ランタイム接続ロード・バランシングは、きわめて頻度の高いアクティビティです。