レベル2: 計画メンテナンスに向けたアプリケーションの準備の構成

アプリケーションHAレベル1: 基本的なアプリケーション高可用性に基づいたレベル2には、計画メンテナンス時のアプリケーションの影響を最小限に抑えるためのセッション・ドレインの構成が追加されます。

レベル1の実装後は、次のいずれかの選択肢から、対象のアプリケーションに適した計画メンテナンス・ソリューションを実装できます。計画操作は、サービスを再配置または停止する場合やスイッチオーバーする場合に、ユーザーの作業が正常に完了できるようにするために使用できます。

アプリケーションへの影響を回避するためにお薦めする方法は、Oracle RACローリング方式で作業をドレインすることです。通常、ドレインの実行には一定の期間が割り当てられています。ドレインの開始には、FANと統合されたOracle接続プールの使用をお薦めします。

ドレインできない場合は、メンテナンスを開始する前に作業をドレインする方法もあります。

Oracle接続プールを使用できない場合は、その他の選択肢を使用できます。

次のプラクティスを採用して、アプリケーション高可用性をレベル2に引き上げます。

• 推奨オプション: Oracle接続プールの使用 - Oracle接続プールを使用して、リクエスト間には接続をプールに戻します。

  または、サード・パーティの接続プールやリクエスト境界付きのプールを使用してUCPを構成します。

• 代替オプション: 接続テストの使用 - Oracle接続プールを使用できない場合は、接続テストを使用できます。

• 計画メンテナンスに対するサーバー側操作の利用

• メンテナンス期間中にワークロードに影響を与えることなく、あるインスタンスから別の使用可能なインスタンスに負荷を分散できるように、十分なノード容量が使用できることを確認してください。

推奨オプション: Oracle接続プールの使用

計画メンテナンスの管理にお薦めのソリューションは、FAN対応のOracle接続プールを使用することです。

Oracleプールは、ノードとサイトの間のドレイン、再接続、リバランスなどの完全なライフサイクル管理を提供します。メンテナンスが進行して完了すると(インスタンスまたはノードごと)、セッションはインスタンス間で移動およびリバランスされます。アプリケーションがOracleプールとFANを使用していて、リクエスト間に接続をプールに返却する場合は、ユーザーに影響はありません。

サポートされているOracleプールには、次のものがあります。

• ユニバーサル接続プール(UCP)
• WebLogic Active GridLink
• Tuxedo
• OCIセッション・プール
• ODP.NET管理対象および管理対象外プロバイダ
• Python用のOracleセッション・プール

これらのプールを使用する場合、リクエスト間に接続がプールに返却されるようにすること以外に、アプリケーションの変更は不要です。

ベスト・プラクティスは、アプリケーションが必要な間のみ接続を取得して、データベース・コールの完了後にすぐに接続をプールに返却することです。接続をプールに戻さずに保持すると、プールは使用可能なインスタンスにセッションを正常に移動できなくなり、リソースの使用が非効率的になるため、それ以外の場合に使用されるよりも多くの接続が必要になります。そのため、アプリケーションは接続を取得したら、その接続を作業の完了直後に返却する必要があります。接続は、その後で別のスレッドで使用することも、再度必要になったときには同じスレッドで使用することもできます。接続プールに接続を返却することは、ドレインの実装方法に関係なく、一般的な推奨事項です。

ノート:

接続の取得と返却のための構文は、プールの実装によって異なります。

たとえば、UCPでは、PoolDataSourceオブジェクトのgetConnection()メソッドを使用して接続を取得し、データベースでの作業の完了後にclose()メソッドを使用して接続を返却します。

Oracle接続プールは、接続が借用されるたびに接続を検証することで、その接続をエラーなしで使用できるようにします。

『Universal Connection Pool開発者ガイド』を参照してください

代替オプション: 接続テストの使用

Oracleプールを使用できない場合は、Oracleクライアント・ドライバ19cまたはOracle Database 19cによってセッションがドレインされます。

サービスが再配置または停止された場合や、Oracle Data Guardによるスタンバイ・サイトへのスイッチオーバーがある場合、Oracle DatabaseとOracleクライアント・ドライバは、次の項目に応じて接続を解放するための安全な場所を検索するように通知されます。

• 接続の有効性に対する標準接続テスト(JDBCのisValid()など)
• 接続の有効性に対するカスタムSQLテスト

カスタム・バッチ・アプリケーションの場合は、バッチ間の接続をテストします。接続テストが失敗したときには、別の接続を作成するか借用します。

サードパーティ接続プールの場合は、ベンダーが提供する接続テストを有効にします。接続テストが失敗すると、サード・パーティのプールは接続をクローズして、別の接続を借用できるようになります。

ノート:

• 接続テストの使用時には、接続テストの結果はそのセッションのみに当てはまります。接続テストを使用して、インスタンスに関する全般的な決定を下すことや、テスト適用対象のセッション以外を停止することを決断しないでください。

• Oracle WebLogic Serverデータ・ソースを使用しているときは、接続テスト失敗時にプールをフラッシュおよび破棄するための接続プール・プロパティを無効にします。

• モニターは、インスタンスのヘルスについて決定を下す機能です。FANおよび実行時ロード・バランシングの使用時は、このようなモニターは必要なくなり、正しくない決定に影響されることがありません。モニターが必要な場合は、そのモニターでのSQLをアプリケーションの排出のための接続テストだと誤解しないでください。このような誤解が起こらないようにするためのいくつかの方法を次に示します。

  • dbms_app_cont_adminパッケージを使用して、モニターの固有のヘルス問合せを無効にします。

    dbms_app_cont_admin.disable_connection_test(dbms_app_cont_admin.sql_test,'SELECT COUNT(1) FROM DUAL’);

    ここでは、モニターによって使用される問合せ'SELECT COUNT(1) FROM DUAL'は接続テストとはみなされません。この問合せを使用する接続テストがある場合、それらは無効になり、別の問合せが必要になります。

  • モニターの問合せにコメントを埋め込んで、登録されている接続テストとそれを区別します。

    SELECT /* My Health monitor query */ COUNT(1) monitor FROM DUAL

JDBC Thinドライバでの標準接続テストの使用

Oracle以外のプールでは、JDBC Thinドライバで接続テストを使用するために、次のステップを実行します。

1. プールで接続テストを有効にして(実装はサードパーティ・プールによって異なります)、テストjava.sql.Connection.isValid(int timeout)を使用します
2. Javaシステムのプロパティを設定します

   • -Doracle.jdbc.fanEnabled=true

   • -Doracle.jdbc.defaultConnectionValidation=SOCKET (Oracle Database 19cでは、isValid()コールはクライアントに対してローカルであり、データベースへのトリップは不要です)

OCIドライバでドレインするためのOCI接続テストの使用

Oracle Call Interface (OCI)セッション・プールを使用しているときには、この接続チェックが自動的に実施されます。OCIドライバを直接使用しているときには、OCI_ATTR_SERVER_STATUSを使用します。これは、コード変更がある唯一のメソッドです。

対象のコードでは、接続の借入時または返却時にサーバー・ハンドルをチェックし、セッションが切断されているかどうかを確認します。サービスが停止または再配置されているときに、値OCI_ATTR_SERVER_STATUSはOCI_SERVER_NOT_CONNECTEDに設定されます。

次のコード例は、OCI_ATTR_SERVER_STATUSの使用方法を示しています。

ub4 serverStatus = 0
OCIAttrGet((dvoid *)srvhp, OCI_HTYPE_SERVER,
   (dvoid *)&serverStatus, (ub4 *)0, OCI_ATTR_SERVER_STATUS, errhp);
if (serverStatus == OCI_SERVER_NORMAL)
printf("Connection is up.\n");
else if (serverStatus == OCI_SERVER_NOT_CONNECTED)
 printf("Connection is down.\n");
/* Close connection and get a new one */

Oracle Databaseでドレインするための接続テストの使用

Oracle Database 19cでは、セッションのドレインが可能です。メンテナンス中に接続テストを実行すると、データベースがセッションを閉じて、アプリケーション・サーバーが接続を閉じます。

ビューDBA_CONNECTION_TESTSを使用して、有効になっている接続テストとルールを確認します。SQLベースの接続テストを使用している場合は、接続プールまたはアプリケーション・サーバーのデータベースで有効にされているものと同じSQL (同じ文)を使用します。

追加の接続テストが必要な場合は、サービス、プラガブル・データベース、または非コンテナ・データベースの接続テストを追加、削除、有効化、または無効化できます。

たとえば:

SQL> EXECUTE
 dbms_app_cont_admin.add_sql_connection_test('SELECT COUNT(1) FROM DUAL');

SQL> EXECUTE
 dbms_app_cont_admin.enable_connection_test(dbms_app_cont_admin.sql_test,
   'SELECT COUNT(1) FROM DUAL');

SQL> SELECT * FROM DBA_CONNECTION_TESTS

PL/SQLベースのワークロードをドレインするためのUSERENV関数の使用

関数USERENVは、セッションがドレイン・モードであるかどうかを確認するために使用します。たとえば、この関数を使用して、レコードを処理する長時間実行のPL/SQLループの場合に接続を停止するタイミングと新しい接続を取得するタイミングを判断します。

SQL> select SYS_CONTEXT('USERENV', 'DRAIN_STATUS') from dual ;

SYS_CONTEXT('USERENV','DRAIN_STATUS')

-------------------------------------------------------------------------------

DRAINING

SQL> select SYS_CONTEXT('USERENV', 'DRAIN_STATUS') from dual ;

SYS_CONTEXT('USERENV','DRAIN_STATUS')

-------------------------------------------------------------------------------

NONE

計画メンテナンスに対するサーバー側操作の利用

計画メンテナンスの接続を管理するために、サーバー側操作が必要になります。

Oracle Databaseに接続されているサービスは、接続テストとドレインに許可する時間を指定するドレイン・タイムアウト、およびドレイン・タイムアウトの経過後に適用されるstopoption (通常はIMMEDIATE)で構成されます。SRVCTLによって管理されるstop、relocateおよびswitchoverコマンドには、サービスに設定された値を必要に応じてオーバーライドするためのdrain_timeoutおよびstopoptionスイッチが含まれます。

サービスの構成時には、そのサービスがメンテナンス操作中に自動的に使用されるように、適用可能な必須のドレイン・タイムアウトを指定することをお薦めします。

メンテナンス・コマンドは、「サーバー側の計画メンテナンスのコマンド例」の例で説明したコマンドに類似しています。こうしたコマンドは、ドレインの開始に使用できます。追加のオプションは、My Oracle Support (MOS)のノート: Doc ID 1593712.1の説明に従って必要に応じて含めます。Oracleツールのフリート・パッチ適用およびプロビジョニング(FPP)なども、これらのコマンドを使用します。

Oracle Clusterwareは、サービスの実行に必要な現在実行されていないインスタンスを起動できます。再配置できないサービスや再配置が不要なサービスは停止されます。シングルトン・サービスが、その他に使用可能なインスタンスなしで定義されていると、完全な停止時間が発生する可能性があり、これは予期される動作です。優先インスタンスと少なくとも1つの使用可能なインスタンスを常に定義することをお薦めします。

メンテナンスが完了してインスタンスが再起動されると、Oracle Clusterwareサービス属性によってサービスが終了する場所が自動的に決定されるため、追加のSRVCTLアクションは必要ありません。

関連項目:

『Oracle Real Application Clusters管理およびデプロイメント・ガイド』の計画メンテナンス前のサーバーのドレイン