Oracle Cloud Infrastructureドキュメント

Autonomous Databaseでの継続的な可用性のためのクライアント構成

アプリケーション・コンティニュイティを有効にし、コーディングのベスト・プラクティスに従う場合、計画メンテナンス・アクティビティのアプリケーションを再起動する必要はありません。

親トピック: Autonomous Databaseでのアプリケーション・コンティニュイティの使用

アプリケーション・コンティニュイティを有効にしたデータベース・サービスを使用した接続

Oracleデータベース・サービスは、基礎となるAutonomous Databaseインフラストラクチャの透過性を提供します。

高可用性およびアプリケーション継続性操作は、Autonomous Database接続サービスの使用を前提としています。アプリケーション・コンティニュイティを取得するには、データベースへの接続時にデータベース・サービスを使用します。

Autonomous Databaseのデータベース・サービス名で説明されているように、Autonomous Databaseの事前定義済データベース・サービスの名前は、ワークロードによって異なります。

排出をサポートする推奨プラクティスの使用

Autonomous Databaseでは、計画メンテナンスがベスト・プラクティスに従っている場合、アプリケーション・サーバーを再起動する必要はありません。

計画メンテナンスの場合、メンテナンスを開始する前に現在の作業を完了する時間を提供することをお薦めします。Autonomous Databaseでは、これは自動的に発生し、次のガイドラインに従ってメンテナンス・アクティビティを開始する前に作業が排出されます:

  • Oracle接続プールまたはOracleドライバを使用したFAN
  • 接続のテスト

ドレイン用に割り当てられた時間内に完了しないリクエストに対して、選択したフェイルオーバー・ソリューションとドレインを組み合せて使用します。フェイルオーバー・ソリューションでは、割り当てられた時間に排出されなかったセッションのリカバリが試行されます。

接続プールへの接続の返却

アプリケーションは、リクエストごとに接続プールに接続を返す必要があります。ベスト・プラクティスは、接続が必要なときにのみ、アプリケーションが接続をチェックアウトすることです。接続をプールに返すかわりに保持しても、実行されません。したがって、アプリケーションは接続をチェックアウトし、作業が完了した直後にその接続をチェックインする必要があります。接続は、その後で別のスレッドで使用することも、再度必要になったときには同じスレッドで使用することもできます。接続プールへの接続のリターンは、FANを使用してドレインするか、接続テストを使用してドレインするかに関係なく、一般的な推奨事項です。

Oracle接続プールの使用

計画メンテナンスを非表示にするための推奨ソリューションは、FAN対応のOracle接続プールです。メンテナンスが進行して完了すると、セッションは移動およびリバランスされます。アプリケーションでOracleプールとFANが使用され、リクエストとリクエストの間にプールに接続が戻される場合、ユーザーに影響はありません。サポートされるOracleプールには、UCP、WebLogic GridLink、Tuxedo、OCIセッション・プール、およびODP.NET管理対象プロバイダと管理対象外プロバイダがあります。FANを使用するためにアプリケーションを変更する必要はなく、リクエスト間の接続がプールに戻されるようにする必要があります。

サード・パーティ接続プールでのUCPの使用

サード・パーティのJavaベースのアプリケーション・サーバーを使用している場合、ドレインとフェイルオーバーを達成する最も効果的な方法は、プールされたデータ・ソースをUCPで置き換えることです。このアプローチは、Oracle WebLogic Server、IBM WebSphere、IBM Liberty、Apache Tomcat、Red Hat WildFly (JBoss)、Spring、Hibernateなど、多くのアプリケーション・サーバーでサポートされています。

接続テストの使用

OracleプールをFANとともに使用できない場合、Autonomous Databaseまたは指定されたクライアント・ドライバによってセッションがドレインされます。サービスがメンテナンス中に再配置または停止された場合、またはAutonomous Data Guardを使用したスタンバイ・サイトへのスイッチオーバーがある場合、Oracle DatabaseとOracleクライアント・ドライバでは、次のルールに従って接続を解放するための安全な場所が検索されます。

  • 接続プールからの流用または戻り時の接続有効性に関する標準接続テスト
  • 接続の有効性に対するカスタムSQLテスト
  • リクエスト境界は有効になっており、現在のリクエストは終了しています

Autonomous Databaseでの接続テストの使用

Autonomous Databaseの接続テストを追加、削除、有効化または無効化できます。

ビューDBA_CONNECTION_TESTSを使用して、使用可能な接続テストを表示します。

たとえば:

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;

接続プールまたはアプリケーション・サーバーのデータベースで有効化されているものと同じ接続テストを構成します。また、接続テスト失敗時のプールのフラッシュおよび破棄を、最大プール・サイズまたはMAXINTの2倍以上に構成します。

シンJavaドライバでの接続テストの使用

ドライバに対してローカルで、UCPの完全なFANサポートを使用できない接続テストを使用する場合:

  • validate-on-borrow=trueの有効化
  • Javaシステム・プロパティの設定:
    • -Doracle.jdbc.fanEnabled=true
    • -Doracle.jdbc.defaultConnectionValidation=SOCKET

次に、次のいずれかのテストを使用します。

  • java.sql.Connection.isValid(int timeout)
  • oracle.jdbc.OracleConnection.pingDatabase()
  • oracle.jdbc.OracleConnection.pingDatabase(int timeout)
  • テストSQLの開始時のHINT:
    • /*+ CLIENT_CONNECTION_VALIDATION */

OCIドライバでの接続テストの使用

OCIドライバを直接使用する場合は、OCI_ATTR_SERVER_STATUSを使用します。これは、コード変更がある唯一のメソッドです。対象のコードでは、接続の借入時または返却時にサーバー・ハンドルをチェックし、セッションが切断されているかどうかを確認します。メンテナンス中、OCI_ATTR_SERVER_STATUSの値はOCI_SERVER_NOT_CONNECTEDに設定されます。OCIセッション・プールを使用しているときには、この接続チェックが自動的に実施されます。

次のコード・サンプルでは、OCI_ATTR_SERVER_STATUSの使用方法を示します。 

ub4 serverStatus = 0OCIAttrGet((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");

アプリケーション・コンティニュイティを使用するためのステップ

アプリケーション・コンティニュイティを使用するには、次のステップを実行します。

  • 前提条件として、Autonomous Database上のデータベース・サービスのアプリケーション・コンティニュイティまたは透過的アプリケーション・コンティニュイティ(TAC)を有効にして構成します。詳細は、Autonomous Databaseでのアプリケーション・コンティニュイティの構成を参照してください。

  • 最新のクライアント・ドライバを使用することをお薦めします。Oracle Database 19cクライアント・ドライバ以降では、アプリケーション・コンティニュイティ(AC)および透過的アプリケーション・コンティニュイティ(TAC)に対する完全なサポートが提供されます。次のサポートされているクライアントドライバのいずれかを使用します。

    • Oracle JDBC Replay Driver 19c以降。これは、Oracle Database 19cに付属する、アプリケーション・コンティニュイティのためのJDBCドライバ機能です

    • Oracle Universal Connection Pool (UCP) 19c以降とOracle JDBC Replay Driver 19c以降

    • Oracle Weblogic Server 12c、Active GridLink、またはUCPおよびOracle JDBC Replay Driver 19c以降を使用するサード・パーティJDBCアプリケーション・サーバー。

    • Oracle JDBC Replay Driver 19c以降を使用したJava接続プールまたはスタンドアロンJavaアプリケーション

    • Oracle Call Interfaceセッション・プール19c以降。SQL*Plus 19c (19.8)以降

    • プールされたODP.NET管理対象外ドライバ19c以降(12.2以降ではPooling=trueがデフォルト)。

    • 19c以降のOCIドライバを使用したOracle Call Interfaceベースのアプリケーション

接続プールへの接続の返却

アプリケーションは、リクエストごとにOracle接続プールに接続を返す必要があります。アプリケーション使用のベスト・プラクティスは、必要な時間のみ接続をチェック・アウトし、現在の処理が完了したらプールにチェックインすることです。これは、実行時のアプリケーション・パフォーマンス、実行時の作業のリバランス、メンテナンスおよびフェイルオーバー・イベント中の作業に最適です。この方法は、排水にも重要です。

ユニバーサル接続プール(UCP)やOCIセッション・プール、ODP.Net管理対象外プロバイダなど、Oracle接続プールを使用する場合、またはWebLogic Active GridLinkを使用する場合、この演習では、アプリケーション・コンティニュイティが取得を再開および終了するための安全な場所を識別するために使用するリクエスト境界を埋め込みます。これは、アプリケーション・コンティニュイティに必要であり、透過的アプリケーション・コンティニュイティに推奨されます。

また、透過的アプリケーション・コンティニュイティは、プールが使用されていないか、リプレイが無効になっている場合にリクエスト境界を検出します。境界を検出するための条件は次のとおりです。

  • 開いているトランザクションがありません
  • カーソルは文キャッシュに戻されるか、取り消されます。
  • 復元不可能なセッション状態は存在しません(この文書のリクエスト間のクリーンセッション状態を参照)

アプリケーションで使用される可変値の使用の有効化

可変関数は、実行されるたびに新しい値を返す可能性のある関数です。可変関数の元の結果を保持するためのサポートが、SYSDATE、SYSTIMESTAMP、SYS_GUID、およびsequence.NEXTVALに提供されます。元の値が保持されていない場合、および異なる値がリプレイ時にアプリケーションに返された場合、リプレイは拒否されます。

PL/SQLの可変要素が必要な場合は、必要に応じてGRANT KEEPを発行します。

たとえば:

SQL> GRANT KEEP DATE TIME to adb_user;
SQL> GRANT KEEP SYSGUID to adb_user;
SQL> GRANT KEEP SEQUENCE mySequence to adb_user on mysequence.myobject;

サイド・エフェクト

データベース・リクエストにMAILの送信やファイルの転送などの外部コールが含まれている場合、これは副作用と呼ばれます。

副作用は外部作用であり、ロールバックされません。リプレイの発生時には、副次的作用をリプレイするかどうかを選択できます。多くのアプリケーションでは、仕訳入力やメールの重複実行などの副作用を繰り返すことを選択しているため、問題はありません。アプリケーション・コンティニュイティの場合、リクエストまたはユーザー・コールがリプレイに対して明示的に無効にされていないかぎり、副作用がリプレイされます。逆に、透過的アプリケーション・コンティニュイティがデフォルトでオンになっているため、TACは副作用を再生しません。取得は無効になり、TACによって作成された次の暗黙的境界で再度有効になります。

継続的な可用性のための開発者のベストプラクティス

Autonomous Databaseで継続的な可用性を確保するために、次のベスト・プラクティスに従ってコードを作成します。

接続プールへの接続の返却

最も重要な開発者の演習は、各リクエストの最後に接続プールに接続を戻すことです。これは、実行時の最適なアプリケーション・パフォーマンス、作業の排出、実行時およびメンテナンス中の作業のリバランス、およびフェイルオーバー・イベントのハンドリングに重要です。一部のアプリケーションでは、接続を保持するとパフォーマンスが向上するという誤った考えがあります。接続を保持しても、実行もスケーリングも行われません。

リクエスト間のクリーン・セッション状態

データベース・リクエスト間のセッション状態をクリーンアップすることをお薦めします。

アプリケーションが接続プールへの接続を戻す場合、FETCHステータスのカーソル、およびそのセッションに設定されたセッション状態は、クリアするためのアクションが実行されないかぎり、そのまま維持されます。アプリケーションで状態を設定している場合は、カーソルを文キャッシュに戻し、アプリケーション関連のセッション状態をクリアして、後でそのデータベース・セッションを再利用するための漏洩を防ぐことをお薦めします。セッション状態を消去すると、TACが境界を検出できます。

Oracle Database 23aiを使用してリクエスト間の状態を自動的に消去するには、サービス属性RESET_STATE=LEVEL1を設定します。これを行うと、後で接続プールを使用することにより、状態がリークし、カーソルからフェッチされるのを防ぎます。

Oracle Database 19cを使用している場合は、DBMS_SESSION.RESET_PACKAGEを使用してPL/SQLグローバル変数をクリアし、TRUNCATEを使用して一時表をクリアし、SYS_CONTEXT.CLEAR_CONTEXTを使用してコンテキストをクリアし、カーソルを文キャッシュに戻して取り消します。

アプリケーションがREST、APEX、マイクロサービス、ほとんどのWebアプリケーションなどのステートレスである場合、RESET_STATEを使用することがベスト・プラクティスです。

PL/SQLにCOMMITを埋め込まず、成功時のコミットおよび自動コミットを回避

最上位のコミット(OCOMMIT、COMMIT()またはOCITransCommit)を使用することをお薦めします。アプリケーションで、PL/SQLまたはAUTOCOMMITまたはCOMMIT ON SUCCESSに埋め込まれたCOMMITを使用している場合、停止またはタイムアウトの後にリカバリできないことがあります。PL/SQLは再挿入されません。PL/SQLのコミットが実行されると、そのPL/SQLブロックは再送信できません。アプリケーションでは、データが読み取られた可能性があるため、正しくないコミットの選択を解除するか、バッチでチェックポイントおよび再起動方法を使用する必要があります。AUTOCOMMITまたはCOMMIT ON SUCCESSを使用すると、出力が失われます。

アプリケーションでトップレベル・コミットを使用している場合は、透過的アプリケーション・コンティニュイティ(TAC)、アプリケーション・コンティニュイティ(AC)およびTAF Select Plusが完全にサポートされます。アプリケーションでPLSQLまたはAUTOCOMMITまたはCOMMIT ON SUCCESSに埋め込まれたCOMMITを使用している場合は、COMMITを含むコールが完了まで実行されなかった場合に、リプレイできないことがあります。

問合せでのORDER BYまたはGROUP BYの使用

アプリケーション・コンティニュイティにより、アプリケーションはリプレイ時に同じデータを参照できます。同じデータをリストアできない場合、アプリケーション・コンティニュイティはリプレイを受け入れません。SELECTがORDER BYを使用する場合、またはGROUP BYの順序が保持されます。Autonomous Databaseでは、問合せオプティマイザは多くの場合、同じアクセス・パスを使用します。これは、結果と同じ順序で役立ちます。また、アプリケーション・コンティニュイティは、AS OF句を使用して、AS OFが許可されている同じ問合せ結果を返します。

SQL*Plusに関する考慮事項

SQL*Plusは、多くの場合、試してみるためのツールとして使用されます。もちろん、SQL*Plusは、本番環境で使用される実際のアプリケーションを反映していないため、実際のアプリケーション・テスト・スイートを使用してフェイルオーバー計画をテストし、保護を測定することをお薦めします。SQL*Plusはプールされたアプリケーションではないため、明示的なリクエスト境界はありません。一部のアプリケーションでは、レポートなどにSQL*Plusが使用されます。フェイルオーバーでSQL*Plusを使用するには、次を確認します。

  1. FANは、常にSQL*Plusに対して有効です。ONSエンドポイントを自動構成する推奨接続文字列を使用します。

  2. SQL*plusを使用する場合、キーはデータベースへのラウンドトリップを最小化することです: https://blogs.oracle.com/opal/sqlplus-12201-adds-new-performance-features

  3. SQL*Plusは、Oracle Database 19c以降のTACでサポートされています。最適な結果を得るには、大きな配列サイズを設定します。たとえば(配列サイズ1000を設定)。サーバー出力を有効にすると、リストア不可能なセッション状態が発生するため、使用しないでください。