レベル3: 計画外および計画フェイルオーバーのアプリケーションからのマスクの構成

レベル1およびレベル2に基づいたアプリケーション・コンティニュイティは、アプリケーションからデータベースの割込みをマスクし、タイムアウトと停止を処理するためにお薦めします。

アプリケーションからのデータベースの割込みには、ドレインしないアプリケーション・ワークロードが含まれる場合があります(計画フェイルオーバー)。アプリケーション・コンティニュイティは、ACとTACの2つのモードで動作するように構成できるデータベース・サービスで有効になります。

アプリケーション・コンティニュイティ(AC)

アプリケーション・コンティニュイティは、JDBC Thinアプリケーション用のOracle Database 12.1以降、およびOracle Database 19以降のNode.jsやPythonなどのオープンソース・ドライバをサポートするOCIおよびODP.NETアプリケーション用のOracle Database 12.2.0.1から停止を非可視化します。

アプリケーション・コンティニュイティは、セッション状態およびトランザクション状態が含まれている既知のポイントからセッションを再構築およびリカバリし、割り込まれたすべての処理中の作業をリプレイします(すでにコミットされている作業はリプレイされません)。リプレイが完了すると、割込みの発生がなかったかのようにアプリケーションに結果が返されます。

アプリケーション・コンティニュイティは、Oracle接続プールを使用するOLTPアプリケーションにお薦めします。これは、アプリケーションがデータベースに接続するデータベース・サービスで有効にされます。

透過アプリケーション・コンティニュイティ(TAC)

Oracle Database 19c以降、透過的アプリケーション・コンティニュイティ(TAC)は、セッションとトランザクションの状態を自動的に追跡して記録します。これにより、リカバリ可能な停止の後にデータベース・セッションのリカバリと再構築が可能になります。これは、アプリケーションの知識やアプリケーションコードの変更に依存することなく、対象のアプリケーションでTACを有効にすることができます。

アプリケーションの透過性とフェイルオーバーは、アプリケーションがデータベースへのコールを発行するときのセッション状態の使用状況を取得して分類する状態追跡情報を利用することで実現されます。対象のサービスで、FAILOVERTYPEをAUTOに設定します。

Oracle接続プールを使用していない場合(SQL*PLUSなど)、またはアプリケーションに関する知識がない場合は、データベース・サービスでTACを有効にします。

ACおよびTACによる計画フェイルオーバー

計画フェイルオーバーは、セッションがリプレイ可能であり、ドレインが想定されていないとデータベースが判断した時点でOracle Databaseによって起動されるフェイルオーバーです。

計画フェイルオーバーは、ACまたはTACの使用時にデフォルトで有効になります。これは、FANや接続テストが構成されていないなど、その他のドレイン方法がアクティブでない状況を改善します。

計画フェイルオーバーでは、リプレイが有効な場合に、早期フェイルオーバーすることでメンテナンスを短縮できます。

たとえば、TACによる計画フェイルオーバーは、SQL*Plusで使用されるメンテナンス・ソリューションです。

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

リクエスト境界は、アプリケーション・コンティニュイティ(AC)の必須事項であり、透過的アプリケーション・コンティニュイティ(TAC)の推奨事項です。

ユニバーサル接続プール(UCP)やOCIセッション・プールなどのOracle接続プールを使用すると、アプリケーションの変更なしに適切なポイントで、リクエスト境界がセッションに自動的に埋め込まれます。アプリケーションは、リクエスト境界の終了を挿入するために作業単位(データベース・リクエスト)の完了時にOracle接続プールに接続を返却する必要があります。これは、ODP.Net管理対象外プロバイダ、WebLogic Active GridLinkおよびRedHatの使用時にも適用されます。

また、透過的アプリケーション・コンティニュイティ(TAC)は、リクエスト境界を検出します。Oracle Database 19cでは、このような境界を次の条件で検出します。

処理中のトランザクションが存在しない
カーソルが文キャッシュに戻されているか取り消されている(カーソルはトランザクション間でオープンしたままにしません)
リストア不可能なセッション状態が存在していない(PL/SQLグローバル、OJVM、移入された一時表)

サービスのFAILOVER_RESTOREの設定

フェイルオーバー時にセッション状態をリストアするために、データベース・サービスで属性FAILOVER_RESTOREを設定します。

アプリケーションは、データベース・セッション状態を変更するように記述できます(通常はALTER SESSIONコマンドを使用します)。フェイルオーバー後に作業をリプレイする場合は、そうした状態が存在している必要があります。

サービス構成で、アプリケーション・コンティニュイティにFAILOVER_RESTORE LEVEL1、TACにFAILOVER_RESTORE AUTOを使用します。アプリケーションのHAレベル1のステップに従うと、自動的にFAILOVER_RESTORE AUTOを設定するFAILVOERTYPE AUTOを使用するサービスが作成されます。

ウォレットの使用をお薦めします。ACおよびTACは、ウォレットを利用することで、すべての変更可能なデータベース・パラメータがFAILOVER_RESTOREによって自動的にリストアされるようにします。ウォレットは、ADB-DおよびADB-Sに対して有効化されていて、データベース・リンクに使用されるものと同じです。

リプレイ時の元の関数値のリストア

Oracle Database 19cでは、リプレイ時にSQLのSYSDATE、SYSTIMESTAMP、SYS_GUIDと、sequence.NEXTVAL, CURRENT_TIMESTAMPおよびLOCALTIMESTAMPの値が保持されます。

PL/SQLを使用している場合は、アプリケーション・ユーザーにはGRANT KEEPを使用し、順序所有者にはKEEP句を使用します。KEEP権限が付与されていると、再実行時に元の関数結果が適用されます。

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

副次的作用

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

リプレイの発生時には、副次的作用をリプレイするかどうかを選択できます。多くのアプリケーションでは、ジャーナルのエントリ、メールの送信、ファイル書込みなどの副次的作用の繰り返しが要求されます。アプリケーション・コンティニュイティの場合、副次的作用はリプレイされますが、プログラムで回避することもできます。それとは逆に、透過的アプリケーション・コンティニュイティでは副次的作用がリプレイされません。

JDBC構成

スタンドアロン方式でoracle.jdbc.replay.OracleDataSourceImplを使用するか、Java接続プール(UCPなど)またはWebLogic AGL Server接続プールの接続ファクトリ・クラスとして構成します。

UCPのAC/TACの有効化の詳細は、『Oracle Universal Connection Pool開発者ガイド』のアプリケーション・コンティニュイティのためのデータ・ソースの構成を参照してください。JDBCドライバのデータ・ソース・クラスoracle.JDBC.replay.OracleDataSourceImplは、UCPデータ・ソースPoolDataSourceImplの接続ファクトリ・クラスとして構成します。

正確なデータ・ソースおよび接続プールの構成は、常にサードパーティ接続プール、フレームワーク、アプリケーション・サーバー、コンテナなどの特定のベンダー製品に固有であることに注意してください。

モニタリング

アプリケーション・コンティニュイティでは、保護レベルをモニターするために統計を収集します。

そうした統計は自動ワークロード・リポジトリ(AWR)に保存され、自動ワークロード・リポジトリのレポートに使用できます。統計情報を確認して、保護されたコールの範囲、または保護されたコール数の減少や保護された時間の短縮について判断します。原因に関する詳細は、ACCHKユーティリティを使用します。