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

レベル1とレベル2に基づいたレベル3で提供される機能は、データベースの中断、停止、タイムアウトが発生しても、また、アプリケーション・ワークロードがドレインされないときでもアプリケーションの継続的な可用性を実現するためにお薦めしています。

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

アプリケーション・コンティニュイティ(AC)により、JavaベースのThinアプリケーションの場合はOracle Database 12.1以降で、Node.jsやPythonなどのオープンソース・ドライバをサポートしているOCIおよびODP.NETベースのアプリケーションの場合はOracle Database 12.2.0.1以降で、また、Oracle Database 19以降で、計画外停止がユーザーに認識されることがなくなります。

アプリケーション・コンティニュイティは、セッション状態およびトランザクション状態を含む既知のポイントからセッションをリカバリすることによって、セッションを再作成します。アプリケーション・コンティニュイティは、処理中のすべての作業を再作成します。フェイルオーバーが発生した場合、アプリケーションは実行時間がわずかに遅延しますがそのまま続行されます。

アプリケーション・コンティニュイティの標準モードは、Oracle接続プール、またはリクエスト境界を使用するサード・パーティ接続プールを使用した、OLTPアプリケーション用です。

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

Oracle Database 19c以降では、透過的アプリケーション・コンティニュイティ(TAC)により、透過的にセッションおよびトランザクションの状態が追跡され記録されます。それにより、データベース・セッションを、リカバリ可能な停止の後にリカバリできるようになります。アプリケーションの知識やアプリケーション・コードの変更の必要なくこれが実行され、デフォルトで、アプリケーションに対して透過的アプリケーション・コンティニュイティが有効になります。

アプリケーションの透過性とフェイルオーバーは、アプリケーションがユーザー・コールを発行するときのセッション状態の使用状況を取得して分類する状態追跡情報を使用することによって実現されます。

ACを選択するかTACを選択するか

Oracle接続プール(またはRedHat JBOSS EAP)を使用するOLTPアプリケーションがある場合は、アプリケーション・コンティニュイティと透過的アプリケーション・コンティニュイティのどちらかを選択できます。

どの機能を使用するかを決めるために、それぞれを使用してアプリケーションを実行し、アプリケーション・コンティニュイティによって保護されている累積ユーザー・コール数の値が高いほうを選択できます。

Oracle接続プールを使用していない場合(SQL*Plus 19cやSQLcl 23と同様)、またはアプリケーションに関する知識がない場合は、TACを使用します。

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

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

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

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

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

関連項目:

AC用とTAC用のサービスの構成

COMMIT_OUTCOME = TRUEの設定

トランザクションCOMMITが実行された後に、COMMITの結果にアクセスできるかどうかを指定します。COMMITが永続的であることはデータベースによって保証されますが、この設定によって、COMMITの結果も永続的であることが保証されます。アプリケーションでは、停止後にこの機能を使用して、最後に実行されたコミットのステータスを調べて、その結果を確認できます。

FAILOVER_TYPEの設定

TACを使用する場合は、FAILOVER_TYPEをAUTOに設定します。

または、アプリケーション・コンティニュイティを使用するには、データベース・サービス属性FAILOVER_TYPEをTRANSACTIONに設定します。

FAILOVER_RESTOREの設定

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

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

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

関連項目:

データベースのウォレットの詳細な設定方法は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』のFAILOVER_RESTOREのキーストアの構成を参照してください。

例

TACの場合のサービス構成の例:

$ srvctl add service -db mydb -service my_service -pdb mypdb
 –preferred inst1 -available inst2 -commit_outcome TRUE -failovertype AUTO
 -failover_restore AUTO -notification TRUE -drain_timeout 300 -stopoption IMMEDIATE
 -role PRIMARY

ACの場合のサービス構成の例:

$ srvctl add service -db mydb -service my_service -pdb mypdb –preferred inst1
 -available inst2 -commit_outcome TRUE -failovertype TRANSACTION
 -failover_restore LEVEL1 -notification TRUE -drain_timeout 300 -stopoption IMMEDIATE
 -role PRIMARY

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

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

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

副次的作用

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

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

Oracle 23ai以降では、どのようにリプレイで副次的作用に対応するかについて、ルールを設定するためのPL/SQLプロシージャがあります。「DBMS_APP_CONTサブプログラムの要約」でDBMS_APP_CONTのREPLAY関連プロシージャを参照してください。

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

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構成

JDBC構成で次のものが使用されていることを確認してください:

  • スタンドアロンJDBC用の推奨されているJDBCデータ・ソース。つまり、それをJava接続プール(UCPなど)かWebLogic AGL Server接続プール用、またはRedHat JBOSS EAP用の接続ファクトリ・クラスとして構成します。

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

    19c.x.x.x以前のドライバの場合は、oracle.jdbc.replay.OracleDataSourceImplを使用します

    21ai.x.x.x以降のドライバの場合は、oracle.jdbc.datasource.impl.OracleDataSourceを使用します

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

  • アプリケーション・サーバーの文キャッシュのかわりにJDBCドライバの文キャッシュ。

    これにより、文がクローズされたことをドライバで認識できるようになり、リクエストの最後にメモリーを解放できるようになります。JDBCの文キャッシュを使用するには、接続プロパティoracle.jdbc.implicitStatementCacheSize (OracleConnection.CONNECTION_PROPERTY_IMPLICIT_STATEMENT_CACHE_SIZE)を使用します。キャッシュ・サイズの値は、open_cursorsの数と一致します。たとえば:

    oracle.jdbc.implicitStatementCacheSize=nnn。ここでのnnnは、通常は10から100までであり、アプリケーションで保持されるオープン・カーソルの数と同じです。

モニタリング

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

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

AC保護の分析にデータベース統計を使用する方法の詳細は、「保護レベルの統計」を参照してください。