Oracle Cloud Infrastructureドキュメント

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

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

親トピック: Autonomous Databaseでのアプリケーション・継続性の使用

Application Continuityが有効なデータベース・サービスを使用した接続

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など、多くのアプリケーション・サーバーでサポートされています。

接続テストの使用

FANでOracleプールを使用できない場合は、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倍以上に構成します。

Thin 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 with Active GridLink、またはUCP with Oracle JDBC Replay Driver 19c以降を使用したサード・パーティJDBCアプリケーション・サーバー

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

    • Oracle Call Interface Session Pool 19c以降。SQL*Plus 19c (19.8)以降

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

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

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

アプリケーションは、リクエストごとにOracle接続プールに接続を返す必要があります。アプリケーション使用のベスト・プラクティスは、必要な時間だけ接続をチェックアウト(借入)し、現在のアクションの完了時にプールにチェックインすることです。これは、実行時やメンテナンスおよびフェイルオーバー・イベント中に作業をリバランスするために、実行時に最高のアプリケーション・パフォーマンスを得るために重要です。この演習はドレインでも重要です。

ユニバーサル接続プール(UCP)やOCIセッション・プールなどのOracle接続プールまたはODP.Net管理対象外プロバイダを使用する場合、または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;

副作用

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

影響は外部アクションであり、ロールバックされません。リプレイが発生すると、副作用をリプレイするかどうかを選択できます。多くのアプリケーションでは、重複実行しても問題はないため、仕訳入力やメール送信などの副作用を繰り返すことを選択します。Application Continuityの場合、リクエストまたはユーザー・コールがリプレイに対して明示的に無効にされていないかぎり、副作用がリプレイされます。逆に、透過アプリケーション・コンティニュイティはデフォルトでオンになっているため、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を使用することです。

COMMITをPL/SQLに埋め込まないこととCOMMIT on SuccessおよびAutocommitを回避すること

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

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

問合せでのORDER BYの使用

アプリケーション・継続性により、アプリケーションがリプレイ時に同じデータを認識することが保証されます。同じデータをリストアできない場合、アプリケーション・コンティニュイティはリプレイを受け入れません。SELECTでORDER BYまたはGROUP BYを使用すると、順序が維持されます。Autonomous Databaseでは、問合せオプティマイザは頻繁に同じアクセス・パスを使用するため、結果の同じ順序に役立ちます。Application Continuityは、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でサポートされています。最適な結果を得るには、大きい配列サイズを設定します。たとえば、set arraysize 1000です。リストア不可能なセッション状態が発生するため、サーバー出力は有効にしないでください。