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

機械翻訳について

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

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

アプリケーション・コンティニュイティを有効にしたデータベース・サービスを使用した接続
排出をサポートする推奨プラクティスを使用
Autonomous Databaseでは、計画メンテナンスがベスト・プラクティスに従う場合、アプリケーション・サーバーを再起動する必要はありません。
アプリケーション・コンティニュイティの使用ステップ
アプリケーション・コンティニュイティを使用するには、次のステップを実行します:
継続的な可用性のための開発者のベスト・プラクティス
次のベスト・プラクティスに従って、Autonomous Databaseで継続的な可用性をコーディングします。

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

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

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

Autonomous Database接続サービスを使用すると、高可用性およびアプリケーションの継続性が予測されます。アプリケーションの継続性を得るには、データベースに接続するときにデータベース・サービスを使用します。

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

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

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

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

計画メンテナンスの場合、推奨されるアプローチは、メンテナンスの開始前に現在の作業が完了するまでの時間を提供することです。 Autonomous Databaseでは、次のガイドラインに従うと、メンテナンス・アクティビティを開始する前に自動的に行われ、作業がドレインされます:

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

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

接続プールへの接続を返す

アプリケーションは、各リクエストの接続プールへの接続を返す必要があります。アプリケーションは、必要な時間だけ接続をチェックアウトすることをお薦めします。接続をプールに戻すのではなく保持することは実行されません。したがって、アプリケーションは接続をチェックアウトし、その接続をただちにチェックインして作業を完了する必要があります。接続は、後で他のスレッドや必要に応じてスレッドで使用できるようになります。 FANを使用してドレインするか、ドレインする接続テストかに関係なく、接続プールへの接続を返すことは一般的な推奨事項です。

Oracle接続プールの使用

計画メンテナンスの非表示には、FANを認識したOracle接続プールを使用することをお薦めします。メンテナンスが進み、完了すると、セッションが移動され、リバランスされます。アプリケーションでFANによるOracleプールが使用されていて、リクエストとリクエストの間にプールに接続が戻される場合、ユーザーへの影響はありません。サポートされる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の接続テストを追加、削除、有効化または無効化できます。
Thin Javaドライバを使用した接続テストの使用
OCIドライバでの接続テストの使用

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

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;

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

親トピック: 排出をサポートする推奨プラクティスを使用

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のデータベース・サービスのApplication ContinuityまたはTransparent Application Continuity (TAC)を有効にして構成します。詳細については、「Autonomous Databaseでのアプリケーション・コンティニュイティの構成」を参照してください。
Oracleでは、最新のクライアント・ドライバを使用することを強くお薦めします。 Oracle Database 19cクライアント・ドライバ以降は、Application Continuity (AC)およびTransparent Application Continuity (TAC)のフル・サポートを提供します。サポートされている次のいずれかのクライアント・ドライバを使用します:
- Oracle JDBC Replay Driver 19c以降。これは、アプリケーション・コンティニュイティのためにOracle Database 19cで提供されるJDBCドライバ機能です。
- Oracle JDBC Replay Driver 19c以上を使用したOracle Universal Connection Pool (UCP) 19c以上
- Active GridLinkを使用したOracle Weblogic Server 12c、またはOracle JDBCリプレイ・ドライバ19c以降でUCPを使用するサードパーティJDBCアプリケーション・サーバー
- Java接続プールまたはOracle JDBC Replay Driver 19c以上を使用したスタンドアロンJavaアプリケーション
- Oracle Call Interface Session Pool 19cまたはlater.SQL*Plus 19c (19.8)以降
- ODP.NET プール済、管理対象外ドライバ19c以上("Pooling=true"デフォルト(12.2以降)
- 19c以降のOCIドライバを使用しているOracle Call Interfaceベースのアプリケーション

接続プールへの接続を返す

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

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

また、Transparent Application Continuityは、プールが使用されていない場合、またはリプレイが無効な場合、リクエストの境界を検出します。境界を検出する条件は、次のとおりです:

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

アプリケーションで使用されるノートブックの有効化

可変関数とは、実行されるたびに新しい値を戻すことができる関数です。可変関数の元の結果を保持するためのサポートは、SYSDATE, SYSTIMESTAMP, SYS_GUIDおよび順序に対して提供されます。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の送信やファイルの転送などの外部コールが含まれる場合、これは副作用と呼ばれます。

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

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

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

次のベスト・プラクティスに従って、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に埋め込むことはせず、成功時および自動コミットの回避

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

アプリケーションが最上位コミットを使用している場合、Transparent Application Continuity (TAC)、Application Continuity (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を使用するには、次をチェックします:

FANは常にSQL*Plusに対して有効です。 ONSエンドポイントを自動構成する推奨接続文字列を使用します。
SQL*plusを使用する場合、データベースへのラウンドトリップを最小化するためのキー : https://blogs.oracle.com/opal/sqlplus-12201-adds-new-performance-features
SQL*Plusは、Oracle Database 19cで始まるTACでサポートされています。最適な結果を得るには、大きな配列を設定します。たとえば(set arraysize 1000)。復元不可能なセッション状態が発生するため、サーバーの出力を有効にしないでください。

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