1. Real Application Clusters管理およびデプロイメント・ガイド
  2. アプリケーション・コンティニュイティの確保

6 アプリケーション・コンティニュイティの確保

アプリケーション・コンティニュイティは、データベース・セッションを使用不可にするリカバリ可能なエラーの後に、データベースに対するリクエストを中断することなく、迅速な方法でリプレイできるようにする機能です。そのため、ユーザーにとって停止は、単なるリクエストの処理の遅延にしか見えなくなります。

ACにはリクエスト境界が必要です。つまり、ACは、接続が流用されてプールに戻されるときにリクエスト境界を埋め込むOracleまたはサード・パーティのプールに依存します。一方、TACは指定されたリクエスト境界を使用し、独自の境界を作成します。TACでは、トランザクションがないときにリクエスト境界が自動的に拡張され、セッション状態はリストア可能であり、カーソルはクローズされます。

この章を使用するには、Oracle RACまたはOracle Active Data Guard (Oracle ADG)など、アプリケーション・コンティニュイティを使用するテクノロジまたは製品環境の主要な関連概念および技術をよく理解している必要があります。

関連項目:

Oracle Database高可用性概要およびベスト・プラクティスでは、アプリケーションに最適なアプリケーション・コンティニュイティ保護のレベルを選択および実装する方法について説明しています。

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

アプリケーション・コンティニュイティは、クライアントから認識されないように停止をマスクして、その他の方法では消失してしまう進行中のトランザクションをリカバリするために使用できます。

親トピック: アプリケーション・コンティニュイティの確保

アプリケーション・コンティニュイティについて

アプリケーション・コンティニュイティは、アプリケーション・ワークロードの高可用性を提供します。

アプリケーション・コンティニュイティは、データベース・セッション(すべての状態、カーソル、変数、および存在する場合は最後のトランザクションを含むフル・セッション)をリストアすることで、アプリケーションとユーザーから(リプレイが成功した場合に)リカバリ可能なOracle Databaseの停止の多くをマスクする高可用性機能です。アプリケーション・コンティニュイティは、計画外停止または計画済メンテナンス(タイムアウト、ネットワーク停止、インスタンス障害、修復、構成変更、パッチ適用など)が原因で使用不可になったデータベースおよびデータベース・インスタンスにアプリケーションがアクセスしようとする際に発生する問題に対処します。アプリケーション・コンティニュイティが使用されていない場合、データベースのリカバリによってアプリケーションおよびエンドユーザーに対して停止がマスクされません。このような場合、開発者およびユーザーは例外条件に対処する必要が生じ、ユーザーは資金の振替、タイムシート、注文、請求書の支払に何が起こったかわからないままになる可能性があります。コミットされていないデータの画面が消失し、ログインしなおしてデータの再入力が必要な場合もあります。最悪の場合、管理者は、大量のログインからリカバリするために中間層の再起動を迫られることになります。

アプリケーション・コンティニュイティを使用すると、データベース・インスタンスが使用不可になった場合、アプリケーション・コンティニュイティは正しい状態を使用してセッションおよび任意のオープン・トランザクションを再構築しようとします。トランザクションがコミットされていて、再送信する必要がない場合は、正常な戻りステータスがアプリケーションに戻されます。リプレイが成功した場合、重複のリスクなしにリクエストを安全に続行できます。アプリケーションですでに処理しており、決定したと思われるデータをリプレイによってリストアできない場合、データベースはリプレイを拒否し、アプリケーションは元のエラーを受け取ります。

クライアント要求には、トランザクション処理や非トランザクション処理が含まれる場合があります。Oracle Databaseでリプレイが成功すると、アプリケーションはデータベース・セッションが中断された時点から処理を続行できるため、ユーザーは資金のトランザクションの進行状況がわからない不安な状態に放置されることがなくなります。こうしたクライアント要求をリカバリすることで、アプリケーションがオンラインに戻ったときに、ログインのオーバーロードからのリカバリのために中間層サーバーを再起動する必要がなくなります。アプリケーション・コンティニュイティを使用すると、計画的な停止または計画外の停止の多くをマスクすることでエンド・ユーザーの使用感が向上します。アプリケーション開発者がリクエストをリカバリする必要はありません。

アプリケーション・コンティニュイティは、進行中のトランザクションおよびデータベース・セッション状態のリカバリを実行しながら、トランザクション・ガードによって実現されるトランザクションの冪等性を確保します。各データベース・セッションには論理トランザクションID (LTXID)がタグ付けられているため、データベースは、リプレイごとにトランザクションがコミットされたかどうかのみでなく、トランザクションがコミットされた場合は処理が完了まで実行されたかどうかも識別します。アプリケーション・コンティニュイティがリプレイしようとしている間、アプリケーションはリプレイを遅延処理として認識するか、元のトランザクションに対するコミット・レスポンスを受け取ります(最後のトランザクションが停止前に完了していた場合)。

アプリケーション・コンティニュイティは、Oracle RAC、Oracle Active Data GuardおよびDBMS_ROLLINGでサポートされています。これは、マルチテナント・アーキテクチャを使用しているOracle Databaseで(プラガブル・データベース・レベルでのフェイルオーバーによって)サポートされます。現在、Oracle GoldenGate、ロジカル・スタンバイ、サード・パーティのレプリケーション・ソリューション、またはDMLリダイレクト(Oracle Active Data Guardを使用する場合)ではサポートされません。

関連トピック

親トピック: アプリケーション・コンティニュイティの理解

アプリケーション・コンティニュイティの主な概念

この項では、アプリケーション・コンティニュイティを使用するために理解する必要があるいくつかの用語や概念について説明します。

次の用語は、この章全体を通じて使用されています。

データベース・リクエスト

データベース・リクエストとは、アプリケーションからデータベースに送信された作業のユニット(トランザクションなど)です。通常、リクエストは、1つのデータベース接続における1つのWebリクエストのSQLやPL/SQLなどのデータベース・コールに対応しています。リクエストは一般に、接続プールからデータベース接続をチェックアウトおよびチェックインするために実行されるコールによって区別されます。

リクエスト境界

リクエスト境界は、アプリケーションおよびアプリケーション・サーバーが接続プールからの接続を流用および返却する場所を示します。リクエスト境界はセッションが使用されていないことを示します。リクエスト境界がデータベースから認識できる場合、計画メンテナンスのための排出、ロード・バランシングおよび多重化などの機能をデータベース・レイヤーで分離できます。セッションは、上位のアプリケーション・レイヤーに中断が認識できない状態で再確立できます。

リカバリ可能なエラー

リカバリ可能なエラーとは、実行中のアプリケーション・セッション・ロジックとは関係なく、外部システムの障害が原因で発生するエラー(切断された接続や無効な接続など)です。リカバリ可能なエラーは、フォアグラウンド、ネットワーク、ノード、記憶域、データベースの計画済停止および計画外停止に続いて発生するエラーです。アプリケーションは、最後に発行された操作のステータスを把握しないままの状態で残される可能性があるエラー・コードを受信します。アプリケーション・コンティニュイティは、データベース・セッションを再確立し、リカバリ可能なエラーのクラスに対して保留されている作業を再発行します。

アプリケーション・コンティニュイティは、リカバリ不能なエラーが原因であるコール障害に続く作業は再発行しません。リプレイされないリカバリ不能なエラーの例には、無効なデータ値の発行があります。

コミット結果

トランザクションは、トランザクション表内のエントリを更新することによってコミットされます。Oracle Databaseは、この更新に対応するREDOログ・レコードを生成し、このREDOログ・レコードを書き出します。このREDOログ・レコードがディスク上のREDOログに書き出されると、トランザクションはデータベースでコミットされたとみなされます。クライアントの観点からは、REDOが書き込まれた後に生成されたOracleメッセージ(コミット結果と呼ばれます)をクライアントが受信した時点でトランザクションはコミットされたとみなされます。ただし、COMMITが発行されていた場合、クライアントまたはアプリケーションで受信されていないCOMMIT失敗のメッセージは取得できなくなります。

元の関数結果の復元

元の関数結果の復元は、コールされるたびに新しい値を取得できる非DETERMINISTICであるため、結果は頻繁に変化します。元の関数結果の復元を使用すると、結果がリプレイ時に変化することがあるため、リプレイの問題が発生します。キー値でしばしば使用されるsequence.NEXTVALおよびSYSDATEについて検討してください。主キーがこれらのファンクション・コールの値を使用して構築され、後で外部キーまたは他のバインドで使用される場合、リプレイ時に同じファンクション結果が戻される必要があります。

Oracle関数の元の結果を保持するためのサポートが、SYSDATE、SYSTIMESTAMP、SYS_GUID、sequence.NEXTVAL、CURRENT_TIMESTAMPおよびLOCALTIMESTAMPに提供されます。アイデンティティ順序は、SQLの所有順序でサポートされています。

アプリケーション・コンティニュイティは、SQLの元の値を自動的に保持します。PL/SQLを使用している場合は、アプリケーション・ユーザーにはKEEPを、順序所有者にはKEEP句を付与します。

セッション状態の一貫性

COMMIT文が処理された後、このトランザクションで状態が変更された場合、セッションが失われたときにトランザクションをリプレイしてこの状態を再確立することはできません。透過的アプリケーション・コンティニュイティは、リプレイの新しい開始ポイントを再確立するために、セッション状態の新しいチェックポイントを作成します。透過的アプリケーション・コンティニュイティを構成する場合は、AUTOに設定されたセッション状態の一貫性を使用します。

  • セッションの状態がリクエスト中に変更された場合、セッションは動的状態になります。アプリケーション・コンティニュイティを使用する場合、次のリクエストが開始されるまでフェイルオーバーは内部的に無効になります。

  • 透過的アプリケーション・コンティニュイティでは、セッション状態一貫性のサービス属性をAUTOに設定すると、状態が管理されます。セッション状態は、フェイルオーバー時に追跡および検証されます。無効化の後、セッション状態一貫性のサービス属性がAUTOに設定されると、可能なときにフェイルオーバーが自動的に再度有効になります。

  • セッション状態AUTOを使用して、アプリケーションの展開時にセッション状態を管理します。セッション状態AUTOはTACで使用できます。TACを使用する場合、フェイルオーバーまたはセッションの移行が成功するためには、クライアントとサーバーの両方の表示可能セッション状態が一致している必要があります。リクエストの開始時にリストアできないセッション状態がある場合、TACは要求の開始時に状態を確認できないため、有効になりません。ACCHKおよび保護統計を使用して、リクエストの最初にリストアできないセッション状態を報告します。RESET_STATEを使用して、Oracle Databaseによってリクエスト間でセッション状態を自動的に消去します。

  • ノート:

    SESSION_STATE_CONSISTENCY = STATICが指定されたサービス属性値FAILOVER_TYPE = TRANSACTIONは、サポートされているサービス属性の組合せではなくなりました。

ステートレス・アプリケーション

ステートレス・アプリケーションとは、あるリクエストでセッション状態(別のWebリクエストや同様の使用によるそのセッションの以前の使用で設定されたコンテキストやPL/SQL状態など)を使用しないアプリケーション・プログラムです。リクエストの処理に必要な状態は、URL、問合せ文字列パラメータ、本文またはヘッダーの一部としてであろうとなかろうと、リクエスト自体に含まれています。クラウド環境では、スケーラビリティおよび移植性のためにアプリケーションはステートレスであることが望ましいです。サーバーはセッション状態を維持、更新または通信する必要がないため、ステートレスであることによりスケーラビリティを向上させることができます。また、ロード・バランサは、ステートレス・システムのセッション・アフィニティを考慮する必要はありません。最新のJava Webアプリケーションのほとんどはステートレスです。サービス属性RESET_STATEは、セッション状態が後で再利用されるのを防ぐために、すべてのステートレス・アプリケーションに推奨されます。

親トピック: アプリケーション・コンティニュイティの理解

アプリケーション・コンティニュイティがアプリケーションで機能する仕組み

リカバリ可能なエラーが発生したときに、リプレイが有効化されていると、アプリケーション・コンティニュイティによってデータベース・セッションのリカバリが試行されます。

次に、アプリケーション・コンティニュイティの動作のしくみを図で示します。

図6-1 アプリケーション・コンティニュイティ

図6-1の説明が続きます
「図6-1 アプリケーション・コンティニュイティ」の説明
回復可能なエラーの後にデータベース・セッションのリカバリを試行するために、アプリケーション・コンティニュイティは次のステップを実行します。

ノート:

データベース・セッションのリカバリ・ステップは、計画外の停止と計画的な停止の両方に適用されますが、特定のステップは停止のタイプに応じて変化します。

  1. クライアント・アプリケーションが要求を発行します。この要求は、中間層(ユニバーサル接続プール(UCP)、ODP.NET、WebLogic Server、OCIセッション・プール、Tuxedo、またはUCPを使用するサード・パーティ・プールなど)に渡されてデータベースに転送されます。アプリケーションは、JDBCリプレイ・ドライバまたはODP.NET管理対象プロバイダ23aiを使用して直接データベースに要求を発行することもあります。

  2. 中間層またはOracleドライバ(JDBCリプレイ・ドライバ、OSIまたはODPM 23ai)。

  3. 計画済または計画外のDOWN高速アプリケーション通知(FAN)イベントまたはリカバリ可能なエラーが受信されます。ドライバは、終了したセッションを停止します。

  4. アプリケーション・コンティニュイティがリプレイを開始し、次を実行します。

    1. 終了した物理セッションを新しいクリーンなセッションに置き換えます。

    2. 進行中のトランザクションがオープンであった場合、その結果を確認するためにトランザクション・ガードを使用してリプレイを準備します。

    3. FAILOVER_RESTORE=LEVEL2、FAILOVER_RESTORE=LEVEL1またはFAILOVER_TYPE=AUTOの場合、アプリケーション・コンティニュイティでは初期セッション状態をリストアします。ウォレットをFAILOVER_RESTOREとともに使用して、変更可能なすべてのパラメータをリストアします。アプリケーション・コンティニュイティは、アプリケーションがコールバック時にFAILOVER_RESTOREで指定されていない初期セッション状態も設定している場合、ラベル・コールバックまたは初期コールバックを使用します

    4. トランザクション状態および非トランザクション状態をリカバリし、クライアント・ドライバによって確認されたデータおよびメッセージが、クライアントが確認して決定した可能性があったものと同じであることをステップごとに検証し、データベース・セッションを再構築します。

    5. リプレイが終了し、ランタイム・モードに戻ります。

    6. 最後にキューに入れられたコールを発行します。

      これは、停止が検出されたときに実行された最後のコールです。リプレイ時には、このコールのみがCOMMITを実行できます。セッションの再構築の途中でCOMMITが行われると、リプレイは終了します(自律型トランザクションは除く)。

  5. レスポンスがアプリケーションに戻されます。

    リプレイが成功した場合、アプリケーションは問題をマスクした状態で続行できます。失敗した場合、アプリケーションは元のエラーを処理する必要があります。

通信障害後のアプリケーション・コンティニュイティの動作は、関連するOracle製品およびテクノロジによって異なります。たとえば:

  • Oracle RACまたはOracle Active Data Guardファームを使用している場合、実行中の別のインスタンスで接続が再確立された後、アプリケーション・コンティニュイティはセッションを再構築し、最後のトランザクション(進行中のものがある場合)をリプレイしようとします。

  • Oracle Active Data Guardを使用し、スタンバイ・サイトにフェイルオーバーする場合、アプリケーション・コンティニュイティはフェイルオーバー・インスタンスに接続し、セッションを再構築し、最後のトランザクション(トランザクションが進行中であった場合)をリプレイしようとします。Oracle Active Data Guardスイッチオーバーまたはフェイルオーバーによってデータが失われた場合、アプリケーション・コンティニュイティはリプレイされません。

  • Oracle RACまたはOracle RAC One Nodeを使用していて、Oracle Active Data Guardは使用していない場合、停止が原因ですべてのパブリック・ネットワークが中断されるか、データベースまたはデータベース・セッションがしばらくの間停止すると、アプリケーション・コンティニュイティは、セッションを再構築し、接続がリストアされた後にデータベースに対して最後のトランザクション(トランザクションが進行中であった場合)をリプレイしようとします。

関連トピック

親トピック: アプリケーション・コンティニュイティの理解

Oracle Application Continuityおよび透過的アプリケーション・コンティニュイティのサポート

アプリケーション・コンティニュイティ(AC)のサポートは、多くのOracleアプリケーションに統合されています。

アプリケーション・コンティニュイティは、次のOracleテクノロジを使用した一般的な用途で使用できます。

  • Oracle JDBC Replay Driver 12c以降。これは、アプリケーション・コンティニュイティのためにOracle Database 12cで提供されるJDBCドライバ機能です。
  • Oracle Database 23ai JDBC統合データ・ソースでは、アプリケーション・コンティニュイティが有効になっている場合、リプレイは自動的に有効になります。リプレイ・ドライバを選択する必要はなくなりました。
  • Oracle Universal Connection Pool (UCP) 12c以上
  • Oracle WebLogic Server Active GridLink、またはUCPとOracle JDBC Replay Driver 19c以上を使用するサード・パーティJDBCアプリケーション・サーバー、またはJDBC統合データ・ソース。
  • Java接続プールまたはスタンドアロンJavaアプリケーション(Oracle JDBC Replay Driver 12c以降をリクエスト境界で使用)。
  • Oracle Call Interface (OCI) 12cリリース2 (12.2)以上を使用するアプリケーションおよび言語ドライバ(thickモードのPythonを含む)。
  • SQL*Plus 19c以降
  • ODP.NET管理対象外プロバイダ12cリリース2 (12.2)以上(12.2以降では"pooling=true"および"Application Continuity=true"をデフォルトとして設定)
  • Oracle Data Provider for .NET (ODP.NET)管理対象ドライバ23ai以降。

透過的アプリケーション・コンティニュイティ(TAC)は、次のOracleテクノロジとともに一般的な用途で使用できます:

  • Oracle JDBC Replay Driver 19c以降。これは、アプリケーション・コンティニュイティのためにOracle Database 19cで提供されるJDBCドライバ機能です。
  • Oracle Database 21c以降のJDBC統合データ・ソースでは、アプリケーション・コンティニュイティが有効になっている場合、リプレイは自動的に有効になります。リプレイ・ドライバを選択する必要はなくなりました。
  • Oracle JDBC Replay Driver 19c以上を使用したOracle Universal Connection Pool (UCP) 19c以上
  • Oracle WebLogic Server Active GridLink、またはUCPとOracle JDBC Replay Driver 19c以上を使用するサード・パーティJDBCアプリケーション・サーバー
  • Java接続プールまたはOracle JDBC Replay Driver 19c以上を使用したスタンドアロンJavaアプリケーション
  • Oracle Call Interface (OCI) 19c以上
  • thickモードのPython (python-oracledb)およびNode.js (node-oracledb)ドライバ
  • SQL*Plus 19.3以降
  • ODP.NETプール済、管理対象外ドライバ18c以上(12.2以降ではデフォルトとして"pooling=true"を設定)
  • OCI 19c以上を使用するOCIベースのアプリケーション
  • Oracle Data Provider for .NET (ODP.NET)管理対象ドライバ23ai以降

Javaのアプリケーション・コンティニュイティは、ユニバーサル接続プール、WebLogicデータ・ソース(非XAおよびXAデータ・ソースを含む)に埋め込まれています。また、JDBC Thinリプレイ・ドライバ単独(Apache TomcatやカスタムのJava接続プールなど、Oracle接続プールなしのJDBCリプレイ・ドライバ)で使用できます。OCIのアプリケーション・コンティニュイティは、SQL*Plus、OCI 12.2以上、ODP.NET管理対象外プロバイダ(thickモードのPythonを含む)、ODP.NET管理対象プロバイダ23ai以降、およびthickモードを使用している場合のPythonに埋め込まれています。ACとTACを使用すると、Oracle Database 21c以降ではJDBCアプリケーション、およびOracle Database 19c (19.3)以降ではOCIアプリケーションが自動的に有効になります。

接続プールまたはコンテナがOracle接続プールを使用しない場合、多くのサード・パーティのアプリケーションは、ユニバーサル接続プールによる接続プールの置換を完全にサポートしています。これには、IBM WebSphereとApache Tomcatが含まれます。独自のプーリングを実装するCアプリケーションでは、OCIRequestBeginおよびOCIRequestEndコールを使用できます。また、アプリケーションは独自のリクエスト境界を追加できます(Javaの場合のみ)。

リクエスト境界

Oracle Databaseリリース12.1.以降、リクエスト境界はOracle接続プールに埋め込まれています。リクエスト境界は、JDK9以降の標準であるサード・パーティ製Javaアプリケーション・サーバーにも埋め込まれています。Oracle接続プールを使用すると、各リプレイのサイズを定めるリクエスト境界がチェックアウト時およびチェックイン時に明示的にマークされます。サード・パーティの接続プールを使用するときは、UCPを使用するか(Javaの場合)、透過的アプリケーション・コンティニュイティを使用するか、リクエスト境界を追加するか、JDK9以降の標準であるサード・パーティ製Javaアプリケーション・サーバーを使用します。リクエスト境界は、透過的アプリケーション・コンティニュイティの使用時に状態追跡を使用して検出されます。このタイプのリクエスト境界は、暗黙的なリクエスト境界と呼ばれます。この機能は、Oracle Database 19c Javaリプレイ・ドライバと、オープン・ソースおよびODP.NET管理対象外プロバイダを含むOracle Database 19c OCIドライバ以降で使用できます。

ノート:

Oracle Database 18cのみ: Javaには初期beginRequestが必要になります。これは、最新バージョンのJavaリプレイ・ドライバを使用しているときには不要です。

関連トピック

親トピック: アプリケーション・コンティニュイティの理解

アプリケーション・コンティニュイティに関する制限および他の考慮事項

アプリケーション・コンティニュイティを使用するときには、次の制限事項と考慮事項に注意してください。

アプリケーション・コンティニュイティは、次のものに対してはサポートされません:
  • JDBC OCIドライバ(タイプ2)
  • OLE DB
  • ODBC
  • OCCI
  • C、COBOL、FORTRANなどのプリコンパイラ
  • XA
  • thinモードでのpython-oracledb
  • thinモードでのnode-oracledb

ノート:

これらの環境のアプリケーションで計画メンテナンスのサポートが必要な場合は、接続テストを使用した排出を検討してください。

ノート:

Oracle Data Provider for .NET (ODP.NET)、管理対象外のドライバはOracle Database 23aiで非推奨になりました。

ODP.NETは、Oracle DatabaseへのADO.NETベースのデータ・アクセスを提供します。Microsoft .NET Frameworkには、ODP.NET (管理対象ドライバ)およびODP.NET (管理対象外ドライバ)の2つのプライマリOracleデータ・アクセス・ドライバがあります。Oracle Database 23aiでは、ODP.NET (管理対象ドライバ)は、同じアプリケーション・プログラミング・インタフェースおよび構成設定を持つODP.NET (管理対象外ドライバ)で使用可能なすべての主要な機能をサポートします。管理対象外のODP.NETから管理対象のODP.NETへのコード移行は、既存の.NETアプリケーションの大部分に対して簡単です。Oracleでは、管理対象外の既存のODP.NETアプリケーションをODP.NET (管理対象ドライバ)に移行することをお薦めします。ODP.NET (管理対象外ドライバ)は、将来のリリースでサポートされなくなる可能性があります。

OCIおよびODP.NET管理対象外ドライバの場合、アプリケーション・コンティニュイティは、ADT、アドバンスト・キュー(AQ)および一部のLOB APIに対して機能しません。このような除外は、Javaには適用されません。

JDBCを使用するアプリケーションの場合、oracle.sqlの非推奨具象クラスOPAQUE、ANYDATAまたはSTRUCTはサポートされません。

アプリケーション・サーバー・レベルの文キャッシュが有効な場合(WebLogicやサードパーティのアプリケーション・サーバーの文キャッシュなど)、このキャッシュはリプレイの使用時に無効にする必要があります。かわりに、JDBC文キャッシュを構成します。このキャッシュはアプリケーション・コンティニュイティをサポートしていて、JDBCおよびOracle Databaseに向けて最適化されています(oracle.jdbc.implicitstatementcachesize=nnn)。

トランザクションのリプレイが発生する可能性がある場合は、次の制限事項に注意してください:

  • リクエストがALTER SYSTEM文またはALTER DATABASE文を発行すると、リプレイは無効になります。

  • リプレイは、セッションを再構築するのに安全でないとみなされているALTER SESSION文のリクエスト・レベルでは無効化されています。これにはSERIALIZABLEモードが含まれます。Oracle Database 23ai以降、イベントおよびCOMMIT IN PROCEDUREとGUARDの無効化および有効化に関する文がサポートされています。

    アプリケーション・レベルでの他のALTER SESSION文はリプレイでサポートされています。これらには、グローバリゼーション・サポート(NLS)設定の文、格納されているプライベートの概要、コンテナ(CDB/PDB)の設定、SQLトレースおよびPL/SQL警告が含まれます。

  • リプレイのターゲット・データベースは、ソース・データベースと同じデータベース・クラスタ(Oracle RAC、Oracle Data Guard、Oracle Active Data Guard、またはOracle Multitenant)に存在している必要があります。ビジネス・トランザクションの整合性を保護するため、ターゲットが別のデータベースになる場合、アプリケーション・コンティニュイティはリプレイを実行しません。ターゲット・データベースがソース・データベース(またはプラガブル・データベース)と同じであっても、データベースがフラッシュ・バックされていたり、メディア・リカバリによって不完全にリカバリされていたり、Oracle Data Guardによって以前の時点でオープンされていたりするなどでデータが失われている場合、アプリケーション・コンティニュイティはリプレイを実行しません。

  • ストリーム引数の場合、リプレイはベスト・エフォート・ベースです。たとえば、アプリケーションが物理アドレスを使用している場合、アドレスは停止によって失われると、再配置できなくなります。たとえば、JDBCストリーム・セッター(setBinaryStreamなど)によってリプレイが無効になります。

  • 現在、アプリケーション・コンティニュイティは、Oracle GoldenGate、ロジカル・スタンバイ、サード・パーティのレプリケーション・ソリューション、またはDMLリダイレクト(Oracle Active Data Guardを使用する場合)ではサポートされません。

  • リプレイはISOLATION_LEVEL=SERIALIZABLEをサポートしていません。

ノート:

データベースのクローンを作成するために、ディスク・イメージ(BCVなど)を分割する場合や、物理またはOracle Active Data Guardデータベースではないロジカル・スタンバイまたはロジカル・コピーを作成するために別のデータベースになるようにデータベースをクローニングする場合は、データベースを区別するためにnidユーティリティを使用してDBIDを変更する必要があります。

関連トピック

親トピック: アプリケーション・コンティニュイティの理解

様々なアプリケーションのアプリケーション・コンティニュイティ

透過的アプリケーション・コンティニュイティは、自動的に状態追跡システムによって追跡される3つの異なるグループに属するアプリケーションに対応しています。

親トピック: アプリケーション・コンティニュイティの理解

リクエスト境界があるコンテナを使用するアプリケーション

リクエスト境界があるコンテナを使用するアプリケーションでは、アプリケーション・コンティニュイティで明示的な境界間のリプレイを管理できます。

リクエスト境界はデータベース・リクエストの開始と終了をマークするタグです。Oracle Database 12cリリース2 (12.2.0.1)以降、リクエスト境界を埋め込んだ接続プールには、Oracle Universal Connection Pool、すべてのWebLogic Serverデータ・ソース、Tuxedo、Oracle Call Interface、ODP.NET Unmanaged Providerおよび標準のサード・パーティのアプリケーション・サーバーとスタンドアロンのJavaプールがあり、これらはJDBCドライバのPooledConnectionインタフェースおよびSQL*Plusを使用します。

Oracle Databaseがリクエスト境界を認識した場合、次のようになります。

  • データベースは、接続をアタッチおよび解放する際など、パフォーマンス・オーバーヘッドがなく、効率的にWebリクエストを処理できます。リクエスト内の複雑な状態を多重化、排出、リバランス、削減および許可できます。リクエスト境界を使用しない場合、データベースの下位のレイヤーは、Webリクエストを認識しません。そのため、データベースはOracleクライアントのアクション、高速接続フェイルオーバーなどのアドバイザ・メソッドとヒューリスティック、接続検証および状態のアドバイスに依存します。

  • リプレイの長さは初期状態に制限された後、リクエスト内のユーザー・コールはアプリケーション・コンティニュイティによってパージされるものより短くなります。リクエスト境界を使用すると、リプレイの長さを制御できます。また、計画メンテナンスでの排出場所(リクエストの終了時)および計画メンテナンスでのフェイルオーバーの場所(リクエストの開始時)を決定できます。

  • JavaおよびOracle Database 18cのみで透過的アプリケーション・コンティニュイティを使用する場合: Javaでは初期のbeginRequest (最初のリクエスト境界についてのみ)が必要です。これは、最新のバージョンでは不要です。

  • アプリケーション・コンティニュイティを使用する場合は、リプレイ・ドライバが安全な場所を検出して自動的にリクエスト境界を移動します。この機能は、FAILOVER_TYPEがAUTOに設定されている場合に使用できます。

  • リクエスト境界を設定する中間層コンテナを使用してデプロイされたアプリケーションは、データベース・サーバーが提供する透過性機能の完全なセットにアクセスできます。データベースはクライアントがリクエスト境界を設定するタイミングを検出し、境界を使用して排出、フェイルオーバー、集中およびスループットの測定のための安全な場所をマークします。

リクエスト境界により、アプリケーションはすべての複雑な非トランザクション・セッション状態をリクエスト内で使用できます。リクエスト境界の仕様では、これらの状態が境界を超えて依存しないことが必要です。

データベースに依存しないアプリケーション

データベースに依存しないアプリケーションでは、接続の確立時に状態を設定し、非トランザクション・セッションの状態を再度変更することはありません(ごくまれに変更します)。

データベースに依存しないアプリケーション(リクエスト境界のないアプリケーション)では、基本的な非トランザクション状態を設定します。このようなアプリケーションは、Oracle Database固有の機能や順序を使用しません。これらのアプリケーションの場合、アプリケーション・コンティニュイティは暗黙的な境界を指定します。これらのアプリケーションは通常、接続が作成されたときに一度状態を設定し、その後、状態を再度変更することはありません(ごくまれに変更します)。このカテゴリのアプリケーションには、サーバー側のセッション状態を作成しない匿名のPL/SQLを使用するアプリケーションが含まれます。

Oracle Database 19.3以降のリリースで透過的アプリケーション・コンティニュイティを使用する場合、明示的なリクエスト境界は必須ではありませんが、お薦めします。(Oracle Database 18cのみ: Javaには初期のbeginRequestが必要になります。)これにより、SQL*Plusとサード・パーティの接続プールのサポートが可能になります。明示的なリクエスト境界がある場合は、そのリクエスト境界が使用されます。アプリケーション・コンティニュイティには、明示的なリクエスト境界が引き続き必要です。使用していないときは、接続を接続プールに戻すことをお薦めします。

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

検出を使用してリクエスト境界を検出する単純なアプリケーションのアプリケーション・コンティニュイティのバージョン。

親トピック: アプリケーション・コンティニュイティの確保

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

Oracle Databaseでは、アプリケーション・コンティニュイティおよび透過的アプリケーション・コンティニュイティが、リカバリ可能な停止後にデータベース・セッションをリカバリできるように、セッションおよびトランザクションの状態を透過的に追跡および記録します。

透過的アプリケーション・コンティニュイティは、この情報を使用して基本的なアプリケーションの境界を検出します。ユーザー・データベース・セッションのリカバリは安全に実行され、DBAまたは開発者はアプリケーションについて理解したり、アプリケーション・コードを変更したりする必要がありません。アプリケーションがユーザー・コールを発行したときに、セッション状態の使用を分類する状態追跡インフラストラクチャを使用することにより、透過性を実現します。

FAILOVER_TYPE=AUTOの場合、透過的アプリケーション・コンティニュイティは有効になります。

アプリケーション・コンティニュイティまたは透過的アプリケーション・コンティニュイティを有効にすると、計画メンテナンス時および計画外停止が発生したときにアプリケーションを保護できます。計画メンテナンスの場合、安全な場所(接続テストまたは既知のリカバリ可能ポイントなど)に到達するデータベース・セッションは、データベースで排出されます。排出されないデータベース・セッションの場合、データベースはデータベース・セッションをフェイルオーバーするタイミングを決定し、透過的アプリケーション・コンティニュイティまたはアプリケーション・コンティニュイティをトリガーします。アプリケーション・コンティニュイティは、ユニバーサル接続プールを使用して、Javaベースのアプリケーション、OCIおよびODP.NETアプリケーション(SQL*Plus、すべてのOracle接続プール、Tuxedo、WebLogic Serverおよびサード・パーティのアプリケーション・サーバーを含む)の計画外停止が認識されないようにします。

Oracle Database 23ai以降、透過的アプリケーション・コンティニュイティ(TAC)には、再開可能カーソルと呼ばれる透過的アプリケーション・フェイルオーバー(TAF)スタイルのカーソルが含まれます。TACは、FETCHの基本的なSELECTカーソルをサポートします。トランザクション内ではなく、FETCHでSELECTカーソルをサポートするには、セッション状態の一貫性をAUTOに設定します。また、フェイルオーバーの高速化のために、データベースによってこれらのカーソルがフェイルオーバー時に再配置されます。TACは、トランザクション境界を超えてカーソルを開いたままにできるため、より高い保護を提供します。これにより、アプリケーションの計画外停止と計画メンテナンスのサポートが改善されます。TACは、より高い保護を提供し、より迅速なフェイルオーバーを実現するために、再有効化を迅速に行うことができます。

計画外停止の場合、透過的アプリケーション・コンティニュイティはリカバリ可能なエラー(通常、基盤となるソフトウェア、フォアグラウンド、ハードウェア、通信、ネットワークまたはストレージ・レイヤーに関連)が発生する停止に対して起動され、アプリケーションおよびユーザーにはほとんどの障害が認識されません。

TACは、SQLおよび基本的なALTER SESSION文を使用した基本的なアプリケーションをサポートします。透過的アプリケーション・コンティニュイティを使用すると、DBAはアプリケーションの知識がなくても次のことを実現できます。

  • 事前設定された状態のリストア—実行時に、透過的アプリケーション・コンティニュイティは、初期の事前設定されたセッション状態を記録し、さらに状態を監視し、監視対象の状態がフェイルオーバー時にセッション状態を逸脱したことを検出できるセッションの痕跡を記録します。フェイルオーバー時に、透過的アプリケーション・コンティニュイティは事前設定されたセッション状態をリプレイの開始前にリストアし、これらのセッション状態がリプレイの開始前の元の状態と完全に一致することを検証します。これは、アプリケーション・コンティニュイティおよびその他のメカニズム(ログオン・トリガー、ラベル、接続コールバックなど)の両方を使用してリストアされたセッション状態も対象となります。状態が事前設定された状態の外側にある場合は、ログオン・トリガー、コールバックまたはラベルを引き続き追加します。

  • セッションのリカバリ時にアプリケーション・レベルの副作用を認識して無効にします。透過的アプリケーション・コンティニュイティでは、クライアントからのトランザクションおよびセッションの状態を記録して(これをキャプチャと呼びます)、リプレイを有効にします。通常の実行時に、透過的アプリケーション・コンティニュイティでは、副作用、またはトランザクションの結果として発生するがトランザクション自体の一部ではない変更を検出します。副作用のタイプは、アプリケーションのロジックに関するものとデータベース・ハウスキーピングに関する内部的なもので区別されています。副作用を含む文を使用するアプリケーションの場合、文を実行しているときの取得は無効になっています。新しいリクエストが開始されると、取得は自動的に再度有効になります。

  • 所有関数の元の関数値の復元 — このような関数は、実行されるたびに新しい値を返すことができます。これらの関数SYSDATE、SYSTIMESTAMP、LOCAL_TIMESTAMP、CURRENT_TIMESTAMP、SYS_GUIDおよびsequence.NEXTVALの元の結果を保持するためのサポートが提供されています。元の値が保持されていない場合、および異なる値がリプレイ時にアプリケーションに返された場合、透過的アプリケーション・コンティニュイティはリプレイを拒否します。権限を使用して順序、日付および時間を保持します。アプリケーションが独自のスキーマを使用している場合、保持するための権限をロールに割り当てると、このロールをユーザーに付与できます。

  • リクエスト境界について理解する—リクエスト境界は、アプリケーションとアプリケーション・サーバーが接続プールから接続を流用して返却する場所を決定します。JDBC Thinドライバ(Oracle Database 18c以降)、OCIおよびODP.NET Unmanaged Provider (Oracle Database 19cリリース19.3以降)でアプリケーション・コンティニュイティを使用するアプリケーションの場合、DBAはリクエスト境界について知る必要はありませんが、リクエスト境界の使用時には透過的アプリケーション・コンティニュイティによってリクエスト境界が利用されます。ベスト・プラクティスとして、データベースでリクエスト境界を挿入できるチェックポイントを識別できるとは限らないため、アプリケーションでは明確に線引きされたリクエスト境界を使用します。

    透過的アプリケーション・コンティニュイティにより、サーバーおよびドライバはトランザクションとセッションの状態の使用状況を追跡しています。これにより、ドライバは暗黙的なリクエスト境界を検出できます。SSSカーソルのある暗黙的な境界の場合、オブジェクトはオープンされておらず、カーソルは文キャッシュに戻されている必要があり、トランザクションがアクティブでなく、セッションの状態は完全にリストア可能と認識されている必要があります。ドライバは、現在追跡されている情報を破棄してこの時点から再度追跡を開始するか、無効化イベントが発生している場合は追跡を再度有効にします。サーバーへの次回コール時にサーバーが検証され、必要に応じて、以前に明示的な境界が存在しなかったリクエスト境界が作成されます。

  • リストア不可能なセッション状態のより複雑なアプリケーションに対して透過的アプリケーション・コンティニュイティを使用するには、アプリケーション・コンティニュイティに使用するプールを使用し、RESET_STATEを設定して使用間のセッション状態を消去します。RESET_SATEは、プールされた使用から後の使用までセッション状態をリークしないアプリケーションに適しています。

親トピック: 透過的アプリケーション・コンティニュイティ

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

透過的アプリケーション・コンティニュイティ(TAC)は、デフォルトで安全に有効化できるアプリケーション・フェイルオーバー・ソリューションです。

TACは、計画イベントおよび計画外イベントに対して計画フェイルオーバーと呼ばれるフェイルオーバーを提供します。計画フェイルオーバーと計画外フェイルオーバーおよびOracle Maximum Availability Architecture (MAA)レベルの詳細は、『Oracle Database高可用性概要およびベスト・プラクティス』を参照してください。

フェイルオーバーの成功は遅延実行であり、アプリケーションにエラーは返されません。TACが同じ論理セッションを生成できない場合、TACはアプリケーションにエラーを返します。フェイルオーバー成功の正常性保証には、以下が含まれますが、これらに限定されません:
  • replay_initiation_timeoutの下のサービスに設定されたSLA内 - フェイルオーバーは、フェイルオーバーのタイムスタンプがreplay_initiation_timeout以下の場合に開始されます。この場合、replay_initiation_timeoutはリクエストの開始時に設定されています。
  • 同じデータベースのフォワード・イン・タイム - フェイルオーバーでは、ターゲット・データベースが正しいデータベース(DBIDまたはPDBID)内にあり、元のデータベースと同時に存在するか、または元のデータベースからのフォワード・イン・タイム(SCN祖先と呼ばれます)であるかが確認されます。
  • トランザクションの重複なし-フェイルオーバーでは、最後のリクエストがコミットされたか、およびコミットされたリクエストがクライアントにCOMMITTEDを返すかどうかが確認されます。
  • リプレイの開始時に元のセッションと同じセッション状態 - リプレイが必要な場合、FAILOVER_RESTOREを使用してセッション状態をリストアした後、かつ、リプレイする前に、セッション状態が確認され、これらが現在のリクエストの開始時に元のセッションと一致することが確認されます。
  • アプリケーションがすでに処理した結果と同じ結果 - カーソルが再配置され、その再配置の結果が以前と同じであるかどうかが確認されます。これはTAFと似ていますが、Oracle Database 23aiでの再配置がサーバー上で行われ、行がクライアントに返されなくなっている点が異なります。TACは、同じ結果の成功率を高めるために、順序、日付、時間およびGUIDの元の機能結果を保持します。
TACはアプリケーションに対してこれを自動的に実行し、成功の宣言が正しければこれを宣言します。これにより、アプリケーション開発者はビジネス機能に集中できるようになり、TACはフェイルオーバーを可能なかぎり最善の方法で処理できるようになります。

計画フェイルオーバーに関する詳細情報

TACを有効にすると、Oracle Databaseの計画フェイルオーバー・エンジンにより、フェイルオーバーを実行できる確実な場所が検索され、フェイルオーバーが開始されます。これにより、排出時間を制限し、セッションが中断されないようにすることを目標とします。これはTACとACの両方で自動的に行われますが、TACでは頻繁に発生します。

TACとACの違い(元)

ACにはリクエスト境界が必要です。つまり、ACは、接続が流用されてプールに戻されるときにリクエスト境界を埋め込むOracleまたはサード・パーティのプールに依存します。一方、TACは指定されたリクエスト境界を使用し、独自の境界を作成します。TACでは、トランザクションがないときにリクエスト境界が自動的に拡張され、セッション状態はリストア可能であり、カーソルはクローズされます。

ACは、TACと同じようにフェイルオーバーを成功させるための正確性を保証しますが、わずかな違いもあります。ACは、リプレイの開始時に、元のセッションと同じクライアントの表示可能セッション状態を強制します。ACは、デフォルトで電子メールを送信するなどの副作用をリプレイします。TACは、デフォルトとして副作用をリプレイしません。副作用のアクションは、Oracle Database 23aiでカスタマイズできます。

TACのリクエスト境界

TACは、次の場合に独自のリクエスト境界を作成します:
  • トランザクションがない。
  • セッション状態がリストア可能である(PL/SQLグローバル変数、一時表、OJVMおよびセッション期間LOBがない)
  • カーソルがOracle Database 23aiで再開可能であるか、クローズされている

次回使用のためのセッションのクリーン・アップ

サービス属性RESET_STATEは、各リクエストの最後にセッション状態およびカーソルをクリーン・アップして、これらの状態が後のリクエストにリークしないようにします。RESET_STATEを使用すると、作業内容が保存され、将来的に保証されます。つまり、アプリケーションに後で加えた変更もクリーン・アップされます。これにより、TACがリストア可能な状態でないことが原因でセッションをクリーン・アップできなかった場合に、TACを再有効化できます。

親トピック: 透過的アプリケーション・コンティニュイティ

Oracle Cloud環境での透過的アプリケーション・コンティニュイティの使用

透過的アプリケーション・コンティニュイティは、Oracle Autonomous Database DedicatedのOracle Cloud環境内のTPおよびTPURGENTサービスでデフォルトで有効化されており、Oracle Autonomous Database Serverlessで使用できます。

Oracle Cloud環境では、FAILOVER_RESTOREとウォレットを使用すると、初期状態を設定するためのコールバックの追加が不要になります。これは、12.2より前のOracle Databaseリリースの透過的アプリケーション・フェイルオーバー(TAF)とアプリケーション・コンティニュイティに必要なことでした。

自動的に透過的アプリケーション・コンティニュイティを有効化するために、2つの機能が連携します。

  • 計画済の停止の場合、トランザクションにとって安全な場所に到達したセッションはインスタンスから排出され、自動的に別のインスタンスにフェイルオーバーされます。排出しないセッションの場合、Oracle Databaseはセッションのフェイルオーバー先を決定し、セッションをフェイルオーバーするためにアプリケーション・コンティニュイティを起動します。
  • 計画外停止の場合、ユーザー・セッションは透過的アプリケーション・コンティニュイティによって残りのインスタンスに自動的に転送されます。ユーザーが停止を認識することはありません。そのためのアプリケーションの知識や変更は不要です。

サービスでのアプリケーション・コンティニュイティの有効化

サービスで指定されるサービス属性は、汎用パッケージDBMS_APP_CONT_ADMINを使用して変更できます。この手順を使用して、アプリケーション・コンティニュイティまたは透過的アプリケーション・コンティニュイティを有効にするか、フェイルオーバーを無効にします。新しいセッションでは、新しいフェイルオーバー・タイプが使用されます。これらのプロシージャを使用するには、PDBADMINユーザー権限が必要です。これらの例では、完全なサービス名を使用します。

  • dbms_app_cont_admin.enable_tac('TPURGENT')プロシージャを使用して、サービスの透過的アプリケーション・コンティニュイティを有効にします。
    SQL> execute dbms_app_cont_admin.enable_tac('TPURGENT');
  • dbms_app_cont_admin.enable_ac('TPURGENT')プロシージャを使用して、サービスのアプリケーション・コンティニュイティを有効にします。
    SQL> execute dbms_app_cont_admin.enable_ac('TPURGENT');
  • dbms_app_cont_admin.disable_failover('HIGH')プロシージャを使用して、サービスのフェイルオーバーを無効にします。
    SQL> execute dbms_app_cont_admin.disable_failover('HIGH');
  • dbms_app_cont_admin.acchk_setプロシージャを使用して、サービスに対してACCHKを有効にします:
    SQL> execute dbms_app_cont_admin.acchk_set(true);
  • dbms_app_cont_admin.acchk_set_filterプロシージャを使用して、サービスに対してACCHKフィルタを設定します:
    SQL> execute dbms_app_cont_admin.acchk_set_filter(DBMS_APP_CONT_ADMIN.SERVICE_FIL
TER, 'TPURGENT');
  • dbms_app_cont_admin.enable_reset_stateプロシージャを使用して、サービスに対してRESET STATEを有効にします:
    SQL> execute dbms_app_cont_admin.enable_reset_state('TPURGENT', 'LEVEL1');
  • dbms_app_cont_admin.set_drainingプロシージャを使用して、サービスに対して排出を構成します:
    SQL> execute dbms_app_cont_admin.set_draining('TPURGENT', 300, 'IMMEDIATE');

親トピック: 透過的アプリケーション・コンティニュイティ

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

アプリケーション・コンティニュイティ(AC)では、Oracleプールまたは透過的アプリケーション・コンティニュイティ(TAC)がリクエスト境界を検出できるアプリケーションを使用する必要があります。

親トピック: アプリケーション・コンティニュイティの確保

アプリケーション・コンティニュイティ構成タスクの概要

各種Oracleアプリケーションのアプリケーション・コンティニュイティ機能が自動的に使用されます(必要なサービス属性を設定した場合)。

アプリケーションの透過的リプレイを確実にするための主なアクションは次のとおりです。

  1. 必要なCPUおよびメモリー・リソースがあることを確認します。

    • CPU: アプリケーション・コンティニュイティは、クライアント側とサーバー側で管理され、動作のための最小限のCPUオーバーヘッドが必要になります。

      クライアントでは、プロキシ・オブジェクトの構築とガベージ・コレクション(GC)のためにCPUが使用されます。

      サーバーでは、CPUは検証のために使用されます。CPUオーバーヘッドは、検証がハードウェアによって補佐されている、現在のIntelおよびSPARCチップを使用したプラットフォームでは減少します。

    • メモリー: アプリケーション・コンティニュイティを使用している場合、呼出しがリクエストの最後まで保持されるため、リプレイ・ドライバにはベース・ドライバよりも多くのメモリーが必要です。リクエストの最後で、呼出しはガベージ・コレクタに解放されます。この処理は、クローズされた呼出しを解放するベース・ドライバによって異なります。

      リプレイ・ドライバのメモリー消費量は、リクエストごとのコール数によって異なります。この数が小さい場合、リプレイ・ドライバのメモリー消費量は少なくなり、ベース・ドライバと同程度になります。

      最良のパフォーマンスを得るには、クライアント側でパラメータ-Xmxと-Xmsの両方に同じ値を設定する必要があります。たとえば、十分なメモリーがある場合、仮想マシン(VM)に4から8GB (以上)を割り当てます。たとえば、4GBであれば-Xms4gと設定します。-Xmsパラメータがこれより低い値に設定されている場合、VMもオペレーティング・システムから低い値を使用するため、パフォーマンスが悪化する可能性があり、ガベージ・コレクション操作が増加します。

  2. 各リクエストに対してアプリケーションが接続プール(たとえば、WebLogic Server Pool、ユニバーサル接続プール、OCIセッション・プール、Oracle Tuxedoリクエストまたは各リクエストのODP.NET接続プール)から接続を流用して返却しているかどうか、またはリクエスト境界を識別するためにbeginRequestおよびendRequest APIをアプリケーション固有の接続プールに追加するかどうかを判別します(Javaの場合のみ)。

    注意:

    リクエスト境界以外の場所では、Java APIコールのbeginRequestおよびendRequestまたはOCI APIのOCIRequestBeginとOCIRequestEndは使用しないでください(接続プールの接続の流用と返却)。endRequestは、リクエストが完了していることと、現在はステートレスであることを示します。次のbeginRequestからリプレイが開始されます。前の状態がある場合は、FAILOVER_RESTOREまたはコールバックを使用して、その状態を再確立する必要があります。

  3. アプリケーション・コンティニュイティは、リクエスト内のすべての状態をリプレイします。アプリケーションが接続を公表する前に状態を設定する場合は、FAILOVER_RESTOREまたはコールバックが必要です。Oracle WebLogic Serverまたはユニバーサル接続プールの使用時には、FAILOVER_RESTORE、接続ラベリングまたはトリガーを使用します。Oracle Call Interface (OCI)セッション・プール、Oracle TuxedoまたはODP.NETをOracle Database 18c以降のクライアントとともに使用する場合、FAILOVER_RESTOREを使用して、必要な場合は透過的アプリケーション・フェイルオーバー(TAF)コールバックのみを追加します。ラベリングはランタイムとリプレイの両方で使用されます。データベース・テンプレートを使用するには、ウォレットでFAILOVER_RESTOREをAUTO、LEVEL1またはLEVEL2に設定することをお薦めします。

  4. アプリケーションがフェイルオーバー時にSYSDATE、SYSTIMESTAMPおよびSYS_GUIDとその順序を必要とするか、さらにこれらの元の値の維持構成を行う必要があるかどうかを判別します。

  5. session_state_consistency値のアプリケーション・スタイルを評価し、サービスに適した値を設定します。

    • session_state_consistencyがAUTOに設定されている場合、透過的アプリケーション・コンティニュイティはセッション状態を監視し、処理を決定します。状態の使用状況が不明か、状態が将来変更されることがわかっている場合は、透過的アプリケーション・コンティニュイティを使用します。Oracle Database 23aiテンプレートおよびウォレットを使用すると、変更可能なパラメータがリストアされます。.NETアプリケーションの場合、ODP.NET (管理対象ドライバ) 23ai以降、またはODP.NET (管理対象外プロバイダ)以降を使用します。

      セッション状態AUTOを使用して、アプリケーションの展開時にセッション状態を管理します。セッション状態AUTOはTACで使用できます。TACを使用する場合、フェイルオーバーまたはセッションの移行が成功するためには、クライアントとサーバーの両方の表示可能セッション状態が一致している必要があります。リクエストの開始時にリストアできないセッション状態がある場合、TACは要求の開始時に状態を確認できないため、有効になりません。ACCHKおよび保護統計を使用して、リクエストの最初にリストアできないセッション状態を検出します。RESET_STATEを使用して、Oracle Databaseによってリクエスト間でセッション状態を自動的に消去します。

    • session_state_consistencyがDYNAMICに設定されている場合、アプリケーションはリクエスト時に環境または設定を変更します。リプレイは、最初のCOMMITの後、次のリクエストの開始まで無効化されます。デフォルトのモードはDYNAMICであり、ほとんどのアプリケーションに適しています。

    ノート:

    SESSION_STATE_CONSISTENCY = STATICが指定されたサービス属性値FAILOVER_TYPE = TRANSACTIONは、サポートされているサービス属性の組合せではなくなりました。

  6. アプリケーションにリプレイが不要なリクエストがあるかどうかを調べます。

    たとえば、外部PL/SQLアクションを使用するリクエストに対して、リプレイを無効化する必要がある場合があります。

  7. 次の構成のガイドラインに従ってください。

    • Javaの場合は、Oracle Database 12cリリース1 (12.1.0.1)以降を使用します。OCIベースのアプリケーションの場合は、Oracle Database 12cリリース2 (12.2)以降を使用します。

    • .NETアプリケーションの場合、Oracle Database 12cリリース2 (12.2)以降に接続しているODP.NET (管理対象ドライバ) 23ai以降、またはODP.NET (管理対象外プロバイダ) 12.2以降を使用します。デフォルトでは、この構成でODP.NETアプリケーションのアプリケーション・コンティニュイティが有効化されます。OCIセッション・プールを使用しないOCIベース・アプリケーション(SQL*Plusを含む)を使用する場合は、自動で境界が追加される透過的アプリケーション・コンティニュイティを使用します。

      ノート:

      Oracle Data Provider for .NET (ODP.NET)、管理対象外のドライバはOracle Database 23aiで非推奨になりました。

    • カスタムJavaプールおよびスタンドアロンJavaアプリケーションは、JDBC Replayデータソースを直接使用することもできます。カスタムJavaプールとスタンドアロン・アプリケーションを使用する場合は、自動で境界が追加される透過的アプリケーション・コンティニュイティの使用をお薦めします。アプリケーションに、Java APIのbeginRequestとendRequestを追加することもできます。

    • アプリケーションがOracle接続プールからの接続の流用および戻しを行わない場合は、明示的にリクエスト境界をマークしてください。たとえば、カスタムJDBCプールなどのプールを使用する場合は、自動で境界が追加される透過的アプリケーション・コンティニュイティの使用をお薦めします。アプリケーションに、Java APIのbeginRequestとendRequestを追加することもできます。これらのAPIは、接続プールのないスタンドアロンJDBCアプリケーションに対しても使用できます。

    • エラーに対する高速な中断としてFANを有効化します。これは、フェイルオーバーが開始する前にTCP遅延の発生を排除するために不可欠です。12.2 FANはJDBCドライバおよびOCIドライバに組み込まれ、Javaではデフォルトでオンになっています。

    • 接続にはデータベース・サービスを使用します。SIDやインスタンス名、または管理サービス(DB_NAMEまたはDB_UNIQUE_NAME)は使用しないでください。

    • 新規着信接続に対する再試行およびこれらの再試行間の遅延を設定する接続文字列を使用します。

    • サービスに対して、アプリケーション・コンティニュイティの場合はFAILOVER_TYPEをTRANSACTIONに設定するか、透過的アプリケーション・コンティニュイティの場合はFAILOVER_TYPEをAUTOに設定します。COMMIT_OUTCOMEをTRUEに設定し、OCI FANに対してNOTIFICATIONをTRUE-に設定します。必要に応じて、使用に適した接続を探す場合は、GOALをSERVICE_TIMEに、CLB_GOALをLONGに設定します。

    • リクエスト境界および保護レベルの統計を使用してカバレッジのレベルを監視します。さらに詳細情報が必要な場合、アプリケーション・コンティニュイティ・チェック・カバレッジ(ORAchkユーティリティに付属)を使用すると、アプリケーション・コンティニュイティによって完全に保護されているリクエストの割合と、完全には保護されていないリクエストの場所が報告されます。このカバレッジ・チェックは、デプロイメントの前と、アプリケーションの変更後に使用します。開発者と管理者は、アプリケーション・リリースが基盤のインフラストラクチャの障害から、どの程度適切に保護されているかを認識できます。問題がある場合、アプリケーションのリリース前に、その問題を修正できます。または、カバレッジのレベルを考えて放棄します。

関連トピック

親トピック: アプリケーション・コンティニュイティの構成

高可用性およびアプリケーション・コンティニュイティに対応する接続の構成

高可用性のアプリケーションに使用する接続を構成する際の一般的な推奨事項を示します。

Javaを使用している場合は、oracle.jdbc.datasource.impl.OracleDataSource、oracle.jdbc.replay.OracleConnectionPoolDataSourceImplまたはoracle.jdbc.replay.driver.OracleXADataSourceImplデータ・ソースを使用して、JDBC接続を取得する必要があります。これらのデータ・ソースは、すべてのOracle JDBCデータソース(oracle.jdbc.pool.OracleDataSourceなど)のプロパティおよび構成パラメータをすべてサポートしています。

OCIベースのアプリケーション(SQL*Plus、ODP.NET、OCIドライバ12.2以降など)は、アプリケーション・コンティニュイティをサポートしています。

接続URLの使用時には次の点に注意する必要があります。

  • データベースのREMOTE_LISTENER設定がクライアントのADDRESS_LISTのアドレスと一致しない場合、接続は行われず、「サービスが見つかりません」と表示されます。このため、データベースのREMOTE_LISTENER設定はクライアントのADDRESS_LIST内のアドレスと一致する必要があります。

    • 接続文字列がSCAN名を使用する場合は、REMOTE_LISTENERにSCAN名を設定する必要があります。
    • 接続文字列がホストVIPのADDRESS_LISTを使用する場合は、REMOTE_LISTENERにすべてのSCAN VIPとすべてのホストVIPを含むアドレス・リストを設定する必要があります

    ノート:

    場所に依存しないSCANを使用すると、ノードの追加時や削除時または別のノードで実行するためのデータベースの変更時に、クライアントを再構成する必要がなくなります。

  • 接続文字列にRETRY_COUNT、RETRY_DELAY、CONNECT_TIMEOUTおよびTRANSPORT_CONNECT_TIMEOUTパラメータを設定します。これらの設定により、ランタイム時、リプレイ時、および計画済停止の作業排出時に新規接続の取得効率が向上します。

    CONNECT_TIMEOUTは、sqlnet.oraファイル内のSQLNET.OUTBOUND_CONNECT_TIMEOUTパラメータと等価であり、完全接続に適用されます。TRANSPORT_CONNECT_TIMEOUTパラメータは、アドレスごとに適用されます。

  • CONNECT_TIMEOUTを上限値に設定して、過剰なログインを防止します。低い値にすると、アプリケーションにログインできます。(RETRY_COUNT+1)*RETRY_DELAYまたはCONNECT_TIMEOUTは、レスポンス時間のSLAよりも大きな値に設定しないでください。アプリケーションは、レスポンス時間のSLAの範囲内で接続するか、エラーを受信する必要があります。

  • 高可用性デプロイメントにEasy*Connectを使用することはお薦めしません。

例6-1 高可用性のための推奨されるTNSエントリ

次に、Transparent Network Substrate (TNSエントリ)の例を示します。これは、Oracle Notification Service (ONS)を自動構成する際に必須のTNS書式です。ONSは、高速アプリケーション通知(FAN)に使用されるトランスポート・システムです。アプリケーション・コンティニュイティでFANを使用して、高速の停止検出を提供することをお薦めします。

myAlias=(DESCRIPTION= 
   (CONNECT_TIMEOUT=90)(RETRY_COUNT=30)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)
   (ADDRESS_LIST=
      (LOAD_BALANCE=ON)
      (ADDRESS=(PROTOCOL=TCP)(HOST=RAC-scan)(PORT=1521)))
   (ADDRESS_LIST=
      (LOAD_BALANCE=ON)
      (ADDRESS=(PROTOCOL=TCP)(HOST=DG-Scan)(PORT=1521)))
   (CONNECT_DATA=(SERVICE_NAME=service_name)))

関連トピック

親トピック: アプリケーション・コンティニュイティの構成

アプリケーション・コンティニュイティのためのOracle Databaseの構成

アプリケーション・コンティニュイティを使用するには、システムが正しく構成されていることを確認する必要があります。

アプリケーション・コンティニュイティを使用するには、Oracle Database構成に次が含まれている必要があります。

  • Oracle Real Application Clusters (Oracle RAC)、Oracle RAC One Node、Oracle Data GuardまたはOracle Active Data Guardを使用している場合、Oracle Database 12c以降のプールおよびドライバと通信するためにOracle Notification Service (ONS)とともに高速アプリケーション通知(FAN)が構成されていることを確認します。

  • リプレイおよびロード・バランシングにサービスのサービス属性を設定します。たとえば、次を設定します。

    • FAILOVER_TYPE = AUTO | TRANSACTION: 透過的アプリケーション・コンティニュイティの場合はFAILOVER_TYPE=AUTOを、アプリケーション・コンティニュイティの場合はFAILOVER_TYPE=TRANSACTIONを使用します。この属性は、リプレイ・ドライバおよびアプリケーション・コンティニュイティのリプレイ機能を有効にします。Oracleドライバは、データベース・セッション中に発行されたすべてのリプレイ可能な文を追跡します。すべての文がリプレイ可能で、進行中のトランザクションがコミットしなかったか、セッションが対話中の場合、Oracleでは計画済または計画外のデータベース停止の後にコミットしていない作業をリプレイします。このモードでは、追加のアプリケーション・ステップを使用しないで自動的にトランザクション状態および非トランザクション状態を再確立します。

    • REPLAY_INITIATION_TIMEOUT = n: リプレイが開始できるようになるまでの期間(秒数)を設定する場合。たとえば、nの値を300に設定できます。

    • FAILOVER_RETRIES = 3: リプレイごとに接続の再試行回数を指定する場合Oracleでは、サービスではなくtnsnames.oraファイルでretry_countを設定することをお薦めします。

    • FAILOVER_DELAY = 3: 接続の再試行間の遅延時間を秒単位で設定する場合Oracleでは、サービスではなくtnsnames.oraファイルでretry_countを設定することをお薦めします。

    • COMMIT_OUTCOME = TRUE: トランザクション・ガードを使用している場合、COMMIT_OUTCOMEサービス・パラメータにより、COMMITが実行されて停止が発生した後にトランザクション・コミット結果にアクセスできるかどうかが決まります。Oracle Database 23ai以降、COMMIT_OUTCOMEのデフォルトはネイティブ・トランザクション・ガードの使用に設定されています。ネイティブ・トランザクション・ガードは、COMMITの前にXIDをドライバに送信できる場合に常に使用されます。Oracle Databaseでは常にCOMMITアクションが永続的になりますが、トランザクション・ガードではCOMMITの結果が永続的になります。

    • FAILOVER_RESTORE = AUTO | LEVEL1 | LEVEL2: 透過的アプリケーション・コンティニュイティの場合はFAILOVER_RESTORE=AUTOまたはFAILOVER_RESTORE=LEVEL1を、アプリケーション・コンティニュイティの場合はFAILOVER_RESTORE=LEVEL1 | LEVEL2を使用します。リプレイ開始前に接続プールまたはドライバに事前設定されたクライアント状態が自動的にリストアされます(NLS状態、TAGS (MODULE、ACTION、ECID、CLIENT_ID、CLIENT_INFO)状態、およびウォレットでFAILOVER_RESTORE=LEVEL1 | LEVEL2を使用するすべてのサーバー変更可能なセッション状態など)。

注意:

DB_NAMEまたはDB_UNIQUE_NAMEに対応するデータベース・サービスは使用しないでください。また、高可用性のデフォルト・データベース・サービスも使用しないでください。このサービスは有効化および無効化できず、Oracle RACで再配置することもOracle Data Guardに切り替えることもできないためです。このサービスは、Oracle Enterprise Manager Cloud Control (Cloud Control)およびDBA用として予約されています。

親トピック: アプリケーション・コンティニュイティの構成

アプリケーション・コンティニュイティのリプレイ前の初期状態の確立

リプレイの開始時に、アプリケーション・コンティニュイティは初期セッション状態をリストアします。

この項のトピックでは、リプレイ前にセッション状態を正常にリストアするようにサービスおよびデータベースを構成する方法について説明します。

  • アプリケーション・コンティニュイティの初期状態の確認
    リストアされるセッション状態について学習します。
  • FAILOVER_RESTORE
    FAILOVER_RESTOREをLEVEL1 (旧バージョンの19cのACの場合)、LEVEL2 (データベース・テンプレートを使用するACの場合)、またはLEVEL1またはAUTO (TACの場合)に設定すると、リクエストをリプレイする前に変更可能なすべてのパラメータが自動的にリストアされます。
  • FAILOVER_RESTOREでリストアされる状態
    FAILOVER_RESTOREがLEVEL1、LEVEL2またはAUTO(ウォレットの有無にかかわらず)に設定されている場合、次のセッション状態がリストアされます。
  • データベース・テンプレートを使用したフルFAILOVER_RESTORE
    Oracle Database 23aiでは、データベース・テンプレートがサポートされています。データベース・テンプレートが、データベース・セッションを記述する値を含む一連のセッション状態です。
  • データベース・テンプレートを使用したFAILOVER_RESTORE
    Oracle Database 23ai以降、アプリケーション・コンティニュイティはデータベース・テンプレートを使用してセッション状態のチェックポイント、リプレイの開始時のセッション状態のリストア、および計画メンテナンス中のセッション移行のサポートを実行します。
  • FAILOVER_RESTORE用のWALLET_ROOTを使用したキーストアの構成
    次のステップを使用し、FAILOVER_RESTOREで使用するためのソフトウェア・キーストア(ウォレット)と透過的データ暗号化(TDE)を使用してディクショナリ資格証明の暗号化を構成します。
  • FAILOVER_RESTORE用のSQLNET.ORAを使用したキーストアの構成
    次のステップを使用し、FAILOVER_RESTOREで使用するためのウォレットの場所を指すためにSQLNET.ORAを使用してディクショナリ資格証明の暗号化を構成します。
  • FAILOVER_RESTORE = NONEおよびコールバックなし
    FAILOVER_RESTORE = NONEは、フェイルオーバー時にセッション状態をリストアしません。
  • 接続ラベリング
    セッションのプロキシなど、より複雑な状態をリストアする場合を除き、接続ラベリングは必要ありません。
  • 接続初期化コールバック
    接続初期化コールバックは、SYS_CONTEXTなどのセッション状態およびパスワードで保護されたロールをリストアする必要がある場合にのみ使用します。ウォレットを使用したFAILOVER_RESTOREは、変更可能なすべてのパラメータをリストアします。

親トピック: アプリケーション・コンティニュイティの構成

アプリケーション・コンティニュイティの初期状態の確認

リストアされたセッション状態について学習します。

アプリケーションで接続が使用できるようになる前にアプリケーションによって接続の初期状態が設定される場合、アプリケーション・コンティニュイティはリプレイの開始前にこの初期状態を確立する必要があります。この項のトピックに示す一般的な状態では、FAILOVER_RESTOREによって状態がリストアされます。ただし、一般的な状態について説明しているトピックを確認する必要があります。アプリケーションで事前設定される状態が示されおらず、アプリケーションで初期状態が必要な場合は、別のコールバックを追加する必要があります。

次に、事前設定が可能な状態の例を示します。

  • PL/SQLパッケージの状態
  • NLS設定
  • オプティマイザ設定

リクエスト時に、アプリケーション・コンティニュイティはリクエストの状態全体を再確立します。この前提条件は、アプリケーション・コンティニュイティがリプレイを開始する前の初期状態のためのものです。

必要とされるすべての状態がFAILOVER_RESTOREによってリストアされる場合、コールバックは不要です。これは、ほとんどすべてのアプリケーションに当てはまります。

関連項目:

各リリースでリストアされるパラメータが増えるため、ご使用のプラットフォーム用の『Oracle Databaseリリース・ノート』を参照してください

親トピック: アプリケーション・コンティニュイティのリプレイ前の初期状態の確立

FAILOVER_RESTORE

FAILOVER_RESTOREをLEVEL1 (旧バージョンの19cのACの場合)、LEVEL2 (データベース・テンプレートを使用するACの場合)、またはLEVEL1またはAUTO (TACの場合)に設定すると、リクエストをリプレイする前に変更可能なすべてのパラメータが自動的にリストアされます。

FAILOVER_RESTOREは、サービスの設定です。Oracle Database 12.2以降で使用可能なFAILOVER_RESTOREにより、クライアント側のアプリケーションに使用可能なすべてのセッション・ステートが自動的にリストアされます。

すべてのアプリケーションでFAILOVER_RESTOREをLEVEL2、LEVEL1またはAUTOに設定することをお薦めします。

リストアされるクライアント側のセッション状態については、「FAILOVER_RESTOREによってリストアされる状態」を参照してください。

FAILOVER_RESTOREによってリストアされる状態

FAILOVER_RESTOREがLEVEL1、LEVEL2またはAUTO(ウォレットの有無にかかわらず)に設定されている場合、次のセッション状態がリストアされます。

リストアされるセッション状態

  • NLS_CALENDAR
  • NLS_CURRENCY
  • NLS_DATE_FORMAT
  • NLS_DATE_LANGUAGE
  • NLS_DUAL_CURRENCY
  • NLS_ISO_CURRENCY
  • NLS_LANGUAGE
  • NLS_LENGTH_SEMANTICS
  • NLS_NCHAR_CONV_EXCP
  • NLS_NUMERIC_CHARACTER
  • NLS_SORT
  • NLS_TERRITORY
  • NLS_TIME_FORMAT
  • NLS_TIME_TZ_FORMAT
  • TIME_ZONE
  • NLS_TIMESTAMP_FORMAT
  • NLS_TIMESTAMP_TZ_FORMAT
  • CURRENT_SCHEMA
  • MODULE
  • ACTION
  • CLIENT_ID
  • AUTOCOMMIT状態(JavaおよびSQL*Plusの場合)
  • CONTAINER (PDB)およびSERVICE
  • ROLES (引き続きコールバックを必要とするセキュア・ロールは除く)
  • ROW_ARCHIVAL
  • EDITION
  • ERROR_ON_OVERLAP_TIME
  • SQL_TRANSLATION_PROFILE
  • CLIENT_INFO(JDBC)
データベース・テンプレートを使用したフルFAILOVER_RESTORE

Oracle Database 23aiでは、データベース・テンプレートがサポートされています。データベース・テンプレートが、データベース・セッションを記述する値を含む一連のセッション状態です。

データベース・テンプレートは、セッションの状態が変更されると、データベースによって自動的に作成または割り当てられます。TACおよびACは、テンプレートを使用して、リプレイ時にセッション状態を復元します。

データベース・テンプレートを使用すると、セッション状態が自動的にリストアおよび検証され、クライアントが使用するメモリーが少なくなるため、計画メンテナンスおよび計画外停止中に大きなサブセットのセッションがフェイルオーバーします。データベース・テンプレートはTACに対してデフォルトで有効であり、ACにはFAILOVER_RESTORE=LEVEL2 を使用することをお薦めします。

フェイルオーバー時に、FAILOVER_RESTOREは、セッションで変更されたセッション・パラメータをリストアします。リストアされるセッション・パラメータには、セッションで設定されたoptimizer_capture_sql_plan_baselinesやcreate_stored_outlinesなどがあります。

セッション・パラメータのリストアにログオン・トリガー、接続ラベルまたはコールバックをすでに使用している場合は、それらを引き続き使用できます。ラベルとコールバックは、拡張FAILOVER_RESTOREの有無にかかわらず完全にサポートされています。拡張FAILOVER_RESTOREの使用には、アプリケーションの変更に合わせた更新の必要がないという利点があります。

この機能を使用するには、FAILOVER_RESTOREをLEVEL2またはAUTOに設定して、ディクショナリ資格証明がシステムで暗号化されるようにする必要があります。ACおよびTACに対してFAILOVER_RESTOREをLEVEL1に設定することもできます。これにより、ウォレットの使用時に変更可能なすべてのセッション・パラメータもリストアされます。

ディクショナリ資格証明の暗号化用にウォレットまたはキーストアを追加する方法は2つあります。

ノート:

FAILOVER_RESTOREのキーストアを構成するには、次のいずれかの方法を使用する必要があります。

  • 推奨: WALLET_ROOTデータベース・インスタンス初期化パラメータを使用して、ウォレットの場所を指定します。ウォレットの場所に初期化パラメータを使用すると、Oracle Real Application Clusters (Oracle RAC)とOracle Data Guardの間の一貫性が確保されます。この方法には、データベースのローリング再起動が必要です。

  • ウォレットの場所を指すように、データベース・サーバーのTNS_ADMINディレクトリ内にあるsqlnet.oraファイルを変更します。この方法ではデータベースの再起動は必要ありません。ただし、Microsoft Windowsオペレーティング・システムでデータベースを実行している場合は再起動が必要です。すべてのORACLE_HOMEディレクトリでsqlnet.oraファイルの一貫性が保たれていることを確認する必要があります。また、データベースのアップグレードを実行するときには、sqlnet.oraに追加のメンテナンスが必要になる場合もあります。

データベース・テンプレートを使用したFAILOVER_RESTORE

Oracle Database 23ai以降、アプリケーション・コンティニュイティはデータベース・テンプレートを使用してセッション状態のチェックポイント、リプレイの開始時のセッション状態のリストア、および計画メンテナンス中のセッション移行のサポートを実行します。

データベース・テンプレートは、アプリケーション・コンティニュイティ・リプレイの開始時にサーバー側およびクライアントで表示されるセッション状態をリストアし、アプリケーション・コンティニュイティの保護を向上させます。この機能を使用するには、透過的アプリケーション・コンティニュイティの場合はFAILOVER_RESTORE=AUTOを設定するか、アプリケーション・コンティニュイティの場合はFAILOVER_RESTORE=LEVEL2を設定します。

FAILOVER_RESTOREをデータベース・テンプレートとともに使用すると、より広範なセッション状態のアプリケーションでカバレッジが向上し、クライアント・メモリー使用率が低下します。これにより、計画メンテナンス中により多くのセッションを移行でき、アプリケーション・コンティニュイティによる保護がより高いため、計画外停止中により多くのフェイルオーバーが迅速に正常終了します。

アプリケーション・コンティニュイティのデータベース・テンプレートにより、排出期間中に排出する境界に達していないサーバー側のセッション状態を含むセッションの移行が保証され、計画外停止に対するアプリケーション・コンティニュイティの保護が向上します。アプリケーション・コンティニュイティのデータベース・テンプレートを使用すると、計画メンテナンスおよびロード・バランシングのために、セキュアなセッション状態および大規模なセッション状態を使用してセッションを移行できます。

この機能を有効にするには、FAILOVER_RESTOREをLEVEL2またはAUTOに設定する必要があります。Oracle Database 19cのリストア機能を保持するには、アプリケーション・コンティニュイティと透過的アプリケーション・コンティニュイティの両方についてFAILOVER_RESTOREをLEVEL1に設定します。フェイルオーバー時にすべてのセッション状態をリストアするには、TDEウォレットを使用するなど、データベースで暗号化が有効になっている必要があります。

FAILOVER_RESTORE用のWALLET_ROOTを使用したキーストアの構成

次のステップを使用して、FAILOVER_RESTOREで使用するためのソフトウェア・キーストア(ウォレット)と透過的データ暗号化(TDE)を使用してディクショナリ資格証明の暗号化を構成します。

  1. Oracle Autonomous Databaseを使用している場合は、ここに示すステップを実行する必要はありません。
    Oracle Autonomous Databaseの場合、すでにソフトウェア・キーストアが存在していて、ディクショナリ資格証明が暗号化されています。
  2. Oracle Autonomous Databaseを使用していない場合は、すでにシステムがディクショナリ資格証明の暗号化を強制するように構成されているかどうかを確認します。
    1. 次のSQL問合せを使用して、ウォレット(キーストア)が存在していることを確認します。
      SELECT con_id, wrl_type, status , wallet_type FROM V$ENCRYPTION_WALLET
ORDER BY con_id;
    CON_ID WRL_TYPE     STATUS   WALLET_TYPE
---------- ------------ -------- -----------
         0 FILE         OPEN     PASSWORD

      このSQL問合せで行が戻されない場合は、ウォレット(キーストア)が存在していません。

    2. 次のSQL問合せを使用して、ディクショナリ資格証明が暗号化されていることを確認します。
      SQL> SELECT enforcement FROM DICTIONARY_CREDENTIALS_ENCRYPT;
ENFORCEMENT
---------------
ENABLED

      このSQL問合せでDISABLEDが返される場合、ディクショナリは暗号化されません。

    ウォレットと暗号化したディクショナリ資格証明の準備が完了していると、サービスの属性を設定することで拡張FAILOVER_RESTOREを使用できます。この手順の以降のステップを完了する必要はありません。

    既存のウォレットがない場合やディクショナリ資格証明の暗号化を有効にする必要がある場合は、次のステップに進みます。

  3. ソフトウェア・キーストアを使用するようにデータベースを構成します。
    1. 必要に応じて、ウォレットを格納するディレクトリを作成します。

      選択した場所はOracle RACノード間で共有して、Oracle Data Guardサイトにレプリケートする必要があります。Oracle RACの場合、ディレクトリは共有記憶域上にあることが必要です。

    2. 初期化パラメータWALLET_ROOTを変更します。
      パラメータの値は、ウォレットが格納されているディレクトリにする必要があります。
      SQL> CONNECT / AS SYSDBA
SQL> ALTER SYSTEM SET WALLET_ROOT='/myOracleBase/admin/wallet/' SCOPE=spfile;

      wallet_root='/myOracleBase/admin/wallet/'を追加して、すべてのRACノードでinit.oraファイルを使用してWALLET_ROOT初期化パラメータを変更することもできます。

      Oracle Database 23ai以降、パラメータENCRYPTION_WALLET_LOCATIONはサポートされていません。

      TDEウォレットを格納および取得するには、WALLET_ROOT構造(Oracle Database 18cで導入)を使用します。

      ノート:

      透過的データ暗号化(TDE)が有効になっているが、WALLET_ROOTが構成されていない場合、Oracle Database 23aiへのアップグレードはブロックされます。TDEを使用したデータベースのアップグレードに対するこのブロックは、アップグレード後にデータベースをオープンできない可能性を回避することです。
    3. 初期化パラメータTDE_CONFIGURATIONを変更して、ソフトウェア・キーストアを指定します。
      SQL> CONNECT / AS SYSDBA
SQL> ALTER SYSTEM SET TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=FILE" SCOPE=BOTH SID='*'

      TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=FILE"を追加して、すべてのRACノードでinit.oraファイルを使用してTDE_CONFIGURATION初期化パラメータを変更することもできます。

    4. データベース・インスタンスのローリング再起動を実行し、新しい初期化パラメータをアクティブ化します。

      たとえば、orclという名前の2ノード・クラスタ・データベースがあり、インスタンス名がorcl1とorcl2の場合は、次のコマンドを使用して、データベースが完全に停止しないように各インスタンスを個別に停止および再起動します。 

      $ srvctl stop instance -db orcl -instance orcl1 -drain_timeout 600 -stopoption IMMEDIATE
$ srvctl start instance -db orcl -instance orcl1
 
$ srvctl stop instance -db orcl -instance orcl2 -drain_timeout 600 -stopoption IMMEDIATE
$ srvctl start instance -db orcl -instance orcl2

      ノート:

      フリート・パッチ適用およびプロビジョニングを使用すると、このプロセスが自動化されます。また、パッチ・アップグレード時にパラメータを変更する場合は、かわりに使用できます。
    5. インスタンスの再起動後に、パラメータが正しい値に設定されていることを確認します。
      SQL> SHOW PARAMETER WALLET_ROOT;
SQL> SHOW PARAMETER TDE_CONFIGURATION;
  4. パスワードを使用してキーストアを作成します(まだキーストアが存在しない場合)。

    次の例では、passwordはキーストアのパスワードです。パスワードの大文字と小文字は区別されます。キーストアのパスワードはデータベース・ユーザーのパスワードと同じ規則に従います。 

    SQL> CONNECT / AS SYSKM 
SQL> ADMINISTER KEY MANAGEMENT CREATE KEYSTORE IDENTIFIED BY "password";
  5. キーストアを開いて、暗号化キーを設定します。

    データベースがOracle Multitenantデータベースとして構成されている場合は、CONTAINER=all句を使用して、各PDBにキーストアと暗号化キーを設定する必要があります。次の例では、passwordはキーストアのパスワードです。 

    SQL> CONNECT / AS SYSKM
SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "password" CONTAINER=all;
SQL> ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY IDENTIFIED BY "password" 
SQL> WITH BACKUP CONTAINER=all;

    データベースがOracle Multitenantデータベースとして構成されていない場合は、次のSQLコマンドを使用します。passwordは、キーストアのパスワードです。 

    SQL> CONNECT / AS SYSKM
SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "password";
SQL> ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY IDENTIFIED BY "password" WITH BACKUP;
  6. データベース・ディクショナリ資格証明を暗号化します。

    SYSKMロールを持つ演算子を使用して、コンテナ・データベース(CDB)ルートと各PDBから次のSQLコマンドを実行します。 

    SQL> CONNECT / AS SYSKM
SQL> ALTER DATABASE DICTIONARY ENCRYPT CREDENTIALS;

情報の暗号化と復号化は、フェイルオーバーのリストア中にサーバーで自動的に実行されます。

警告:

ソフトウェア・キーストアとウォレットの場所をバックアップするようお薦めします。TDEソフトウェア・キーストアまたはWALLET_ROOTの場所を失わないようにしてください。そうしたときに、アプリケーション・コンティニュイティまたは透過的アプリケーション・コンティニュイティの場合、新しいキーストアは作成できますが、暗号化したディクショナリ資格証明は再インスタンス化が必要になります。ウォレット・キーに不一致があると、フェイルオーバーは成功しません。

FAILOVER_RESTORE用のSQLNET.ORAを使用したキーストアの構成

次のステップを使用して、FAILOVER_RESTOREで使用するためのウォレットの場所を指すためにSQLNET.ORAを使用してディクショナリ資格証明の暗号化を構成します。

ノート:

SQLNET.ORAよりもFAILOVER_RESTOREにWALLET_ROOTを使用してキーストアを構成することをお薦めします。

この方法ではデータベースの再起動は必要ありません。ただし、Microsoft Windowsオペレーティング・システムでデータベースを実行している場合は再起動が必要です。すべてのORACLE_HOMEディレクトリでsqlnet.oraファイルの一貫性が保たれていることを確認する必要があります。

  1. Oracle Autonomous Databaseを使用している場合は、ここに示すステップを実行する必要はありません。
    Oracle Autonomous Databaseの場合、すでにソフトウェア・キーストアが存在していて、ディクショナリ資格証明が暗号化されています。
  2. Oracle Autonomous Databaseを使用していない場合は、すでにシステムがディクショナリ資格証明の暗号化を強制するように構成されているかどうかを確認します。
    1. 次のSQL問合せを使用して、ウォレットが存在していることを確認します。
      SQL> SELECT con_id, wrl_type, status , wallet_type FROM V$ENCRYPTION_WALLET
ORDER BY con_id;
    CON_ID WRL_TYPE     STATUS   WALLET_TYPE
---------- ------------ -------- -----------
         0 FILE         OPEN     PASSWORD

      このSQL問合せで行が戻されない場合は、ウォレット(キーストア)が存在していません。

    2. 次のSQL問合せを使用して、ディクショナリ資格証明が暗号化されていることを確認します。
      SQL> SELECT enforcement FROM DICTIONARY_CREDENTIALS_ENCRYPT;
ENFORCEMENT
---------------
ENABLED

      このSQL問合せでDISABLEDが返される場合、ディクショナリは暗号化されません。

    ウォレットと暗号化したディクショナリ資格証明の準備が完了していると、サービスの属性を設定することで拡張FAILOVER_RESTOREを使用できます。この手順の以降のステップを完了する必要はありません。

    既存のウォレットがない場合やディクショナリ資格証明の暗号化を有効にする必要がある場合は、次のステップに進みます。

  3. ウォレットを使用するようにデータベースを構成します。
    1. TNS_ADMIN環境変数を表示して、データベースで使用されるネットワーク構成ファイルの場所を探します。

      • LinuxおよびUNIXシステムでは、Oracleホーム・ソフトウェア所有者として、TNS_ADMIN環境変数の現在の設定を表示します。 

        $ env | grep TNS_ADMIN

      • Microsoft Windowsシステムでは、環境変数とレジストリ(パスComputer\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_HOME_NAME)の両方でTNS_ADMINの値セットを確認します。

      TNS_ADMIN変数が設定されない場合、Oracle Net構成ファイルには、デフォルトの場所である$ORACLE_BASE_HOME/network/adminが読取り専用のOracleホームとともに使用されます。
    2. 必要に応じて、ウォレットを格納するディレクトリを作成します。

      選択した場所はOracle RACノード間で共有して、Oracle Data Guardサイトにレプリケートする必要があります。Oracle RACの場合、ディレクトリは共有記憶域上にあることが必要です。

    3. 初期化パラメータTDE_CONFIGURATIONを変更して、ソフトウェア・キーストアを指定します。
      SQL> CONNECT / AS SYSDBA
SQL> ALTER SYSTEM SET TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=FILE" SCOPE=BOTH SID='*'
  4. パスワードを使用してキーストアを作成します(まだキーストアが存在しない場合)。

    次の例のmyOracleWalletLocは、ウォレット(またはキーストア)を格納するために作成したディレクトリのフルパス名です。passwordは、キーストアのパスワードです。パスワードの大文字と小文字は区別されます。キーストアのパスワードはデータベース・ユーザーのパスワードと同じ規則に従います。 

    SQL> CONNECT / AS SYSKM 
SQL> ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/myOracleWalletLoc' IDENTIFIED BY "password";
  5. キーストアを開いて、暗号化キーを設定します。

    データベースがOracle Multitenantデータベースとして構成されている場合は、CONTAINER=all句を使用して、各PDBにキーストアと暗号化キーを設定する必要があります。次の例では、passwordはキーストアのパスワードです。 

    SQL> CONNECT / AS SYSKM
SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "password" CONTAINER=all;
SQL> ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY IDENTIFIED BY "password" WITH BACKUP CONTAINER=all;

    データベースがOracle Multitenantデータベースとして構成されていない場合は、次のSQLコマンドを使用します。passwordは、キーストアのパスワードです。 

    SQL> CONNECT / AS SYSKM
SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "password";
SQL> ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY IDENTIFIED BY "password" WITH BACKUP;
  6. データベース・ディクショナリ資格証明を暗号化します。

    SYSKMロールを持つ演算子を使用して、コンテナ・データベース(CDB)ルートと各PDBから次のSQLコマンドを実行します。 

    SQL> CONNECT / AS SYSKM
SQL> ALTER DATABASE DICTIONARY ENCRYPT CREDENTIALS;

情報の暗号化と復号化は、フェイルオーバーのリストア中にサーバーで自動的に実行されます。

注意:

ウォレットの場所は、バックアップすることをお薦めします。ウォレットまたは場所は失われないようにしてください。そうしたときに、アプリケーション・コンティニュイティまたは透過的アプリケーション・コンティニュイティの場合、新しいウォレットは作成できますが、暗号化したディクショナリ資格証明は再インスタンス化が必要になります。

ウォレット・キーに不一致があると、フェイルオーバーは成功しません。

FAILOVER_RESTORE = NONEおよびコールバックなし

FAILOVER_RESTORE = NONEは、フェイルオーバー時にセッション状態をリストアしません。

すべてのアプリケーションでFAILOVER_RESTOREをLEVEL2、LEVEL1またはAUTOに設定することをお薦めします。

接続ラベリング

セッションのプロキシなど、より複雑な状態をリストアする場合を除き、接続ラベリングは必要ありません。

このシナリオは、Universal Connection Pool (UCP)およびOracle WebLogic Serverに適用できます。接続ラベリングAPIは、セキュアなセッション状態(SYS_CONTEXTおよびパスワードで保護されたロール)を照合するために必要です。また、ドライバ側でフェイルオーバーを報告する場合にも役立ちます。接続が流用されると、接続ラべリングによりコールバックを使用してギャップが移入されます。

接続初期化コールバック

接続初期化コールバックは、SYS_CONTEXTなどのセッション状態およびパスワードで保護されたロールをリストアする必要がある場合にのみ使用します。ウォレットを使用したFAILOVER_RESTOREは、変更可能なすべてのパラメータをリストアします。

リプレイ・ドライバがアプリケーション・コールバックを使用して実行時およびリプレイ時にセッションの初期状態を設定する場合、コールバック・インタフェースは、ドライバがJava Database Connectivity (JDBC)ドライバであるかOracle Call Interface (OCI)ドライバであるかによって異なります。

このシナリオでは、JDBCでもOCIでも、ドライバはアプリケーション・コールバックを使用して、実行時およびリプレイ中にセッションの初期状態を設定します。JDBCリプレイ・ドライバでは、oracle.jdbc.replay.OracleDataSourceインタフェースで接続初期化コールバックを登録および登録解除するために、接続初期化コールバックのインタフェースおよびメソッドがドライバに用意されています。OCIおよびOracle Data Provider for .NET (ODP.NET)では、透過的アプリケーション・フェイルオーバー(TAF)コールバックを登録します。

登録されると、接続がプールから流用されるたびに、またリカバリ可能なエラー後に再接続が成功するたびに、初期化コールバックが実行されます。(これは、JDBC/UCP初期化コールバックの場合に当てはまり、TAFに対しても同様にする必要があります。)ランタイムとリプレイの両方で同じコールバックを使用すると、セッションが最初に確立されたときと同じ初期化がリプレイ時に確立されます。アプリケーションは、初期化アクションがフェイルオーバー前の元の接続時のものと同じであることを確認する必要があります。コールバックの起動が失敗した場合、リプレイはその接続で無効になります。接続初期化コールバックは、アプリケーションにUCPとWebLogic接続ラベリングが実装されていないため、FAILOVER_RESTORE=AUTOまたはFAILOVER_RESTORE=LEVEL1 (透過的アプリケーション・コンティニュイティの場合)またはFAILOVER_RESTORE=LEVEL2 (手動アプリケーション・コンティニュイティの場合)の設定では自動的に状態がリストアできない場合にのみ使用します。

アプリケーション・コンティニュイティの潜在的な副作用

サービス属性FAILOVER_TYPEをTRANSACTIONに設定してアプリケーション・コンティニュイティを使用する場合、副作用を実行する文がリプレイされます。

FAILOVER_TYPEサービス属性をAUTOに設定して透過的アプリケーション・コンティニュイティを使用する場合、副作用が検出されるとリプレイは無効になります。リプレイは、次に検出された境界または明示的な境界で再有効化されます。

ノート:

アプリケーション所有者として、繰り返す必要のない副作用が含まれるリクエストのリプレイを無効にすることを選択できます。副作用を無効にする最も簡単な方法は、透過的アプリケーション・コンティニュイティ(サービス属性FAILOVER_TYPEをAUTOに設定)を使用することです。これにより、副作用が無効になります。

アプリケーション・コンティニュイティは、データベース状態をリストアするためにPL/SQLを時間の経過順にリプレイします。これは、ユーザーによる発行が遅延されたものとしてセッションを再構築する上で役立ちます。ほとんどのアプリケーションは、レポートの作成や監査の完了など、発行が繰り返されたものとして完全な状態を再構築することを必要とします。ただし、状態を構築するためにリプレイされるアクションには、リプレイの影響に対応したりこの影響を軽減するためのアクションが必要なものもあります。一部のアプリケーションでは、繰り返す必要のないコールが含まれるリクエストのリプレイを無効化することを選択します。

副作用があるアクションの例は、次のとおりです。

  • DBMS_ALERTコール(電子メールまたは他の通知)

  • DBMS_FILE_TRANSFERコール(ファイルのコピー)

  • DBMS_PIPEおよびRPCコール(外部ソース向け)

  • UTL_FILEコール(テキスト・ファイルの作成)

  • UTL_HTTPコール(HTTPコールアウトの実行)

  • UTL_MAILコール(電子メールの送信)

  • UTL_SMTPコール(SMTPメッセージの送信)

  • UTL_TCPコール(TCPメッセージの送信)

  • UTL_URLコール(URLへのアクセス)

外部アクション(自律型トランザクションやUTL_HTTPによるサービス指向アプリケーション(SOA)のコールの発行など)を伴うアプリケーションの場合、アプリケーションが外部アクションのリプレイ(電子メールの再送信、監査、およびファイルの転送など)によって満たされるときに、アプリケーション・コンティニュイティは透過的になります。

23aiに対する副作用の許可および禁止

APPLY_REPLAY_RULEを使用して、副作用を許可または禁止します。

リプレイ可能なインタフェースの副作用ユースケース

次のユースケースでは、リプレイ可能なインタフェースの副作用の様々なシナリオについて説明します:

  • TACで副作用を許可するには、次のインタフェースを使用します:
    begin 
insert into emp_tab values (''Alan'', 10); 
DBMS_APP_CONT.APPLY_REPLAY_RULE(REPLAYABLE => TRUE, TARGETS => DBMS_APP_CONT.AUTONOMOUS_TRANSACTIONS);       
do_my_autonomous_txn;
commit;
end
  • ACで副作用を禁止するには、次のインタフェースを使用します:
    begin 
insert into emp_tab values (''Alan'', 10); 
DBMS_APP_CONT.APPLY_REPLAY_RULE(REPLAYABLE => FALSE, TARGETS => DBMS_APP_CONT.AUTONOMOUS_TRANSACTIONS);       
do_my_autonomous_txn;
commit;
end
  • TACのリプレイ可能なインタフェース関数をラップするには、次の文を使用します:
    create [or replace] procedure mark_replayable  as 
    begin
        DBMS_APP_CONT.APPLY_REPLAY_RULE(REPLAYABLE => TRUE, TARGETS => DBMS_APP_CONT.AUTONOMOUS_TRANSACTIONS,
        SCOPE => DBMS_APP_CONT.SCOPE_PARENT); 
        end mark_replayable;

    begin
        insert into emp_tab values (''Alan'', 10);
        mark_replayable;
        do_my_autonomous_txn; 
        commit; 
    end

関連トピック

親トピック: アプリケーション・コンティニュイティの構成

アプリケーション・コンティニュイティの操作および使用の管理

アプリケーション・コンティニュイティの使用を管理する方法とアプリケーションで使用する方法を学習します。

親トピック: アプリケーション・コンティニュイティの確保

計画メンテナンスに対するアプリケーション・コンティニュイティの使用

計画メンテナンスの場合、完了していないリクエストについてアプリケーション・コンティニュイティと組み合せて、Oracle接続プールからリクエストを排出することをお薦めします。

これは、完了する必要があるリカバリが最小限である場合、最も影響の少ない手順です。パッチが適用されたソフトウェアにスイッチオーバーするには、インスタンスを停止する必要があります。

  1. FAN対応プール(OCI、UCP、WebLogic Server、ODP.NET管理ドライバ、管理対象外ドライバなど)を使用します。

    FAN計画イベントの場合、リクエスト境界で排出します。

    ノート:

    • ODP.NET管理ドライバは、アプリケーション・コンティニュイティをサポートしていません。
    • Oracle Data Provider for .NET (ODP.NET)、管理対象外のドライバはOracle Database 23aiで非推奨になりました。

  2. srvctl relocate serviceコマンドを使用して、セッションを中断することなくインスタンスのサービスを再配置します。または、均一サービスの場合、インスタンスでsrvctl stop serviceコマンドを使用します(-forceパラメータは使用しないでください)。

    FANの計画イベントはアイドル・セッションを即時にクリアして、アクティブ・セッションをチェックイン時(リクエストの最後)に解放するとマーク付けします。これによって作業を妨げずにセッションがインスタンスから排出されます。

  3. 一部のセッションがチェックインしておらず、インスタンスを停止する時間になったら、インスタンスを停止(終了)します。

    アプリケーション・コンティニュイティが有効なプール(UCP、WebLogic、Tuxedo、ODP.NET、およびOCI)、およびbeginRequest/endRequestを追加するJavaプールの場合、アプリケーション・コンティニュイティは、そうした残っているセッションをリカバリしようとします。

  4. インスタンスおよびサービスを再起動します。

    実行時ロード・バランシング(がもし有効な場合)では、次のリクエスト境界でリストアされたインスタンスにセッションを戻して均衡化します。

関連トピック

親トピック: アプリケーション・コンティニュイティの操作および使用の管理

元の関数結果のリストアの管理

元の機能結果のリストアを管理するには、特定の権限を付与する必要があります。

親トピック: アプリケーション・コンティニュイティの操作および使用の管理

元のOracle関数値とアプリケーション・コンティニュイティのリストア

リクエストがリプレイされると、元のOracle関数値のリストアのデフォルトの処理と必要な処理が異なる場合があります。

デフォルトでは、SQLの場合、受信した元の値は順序に対してリストアされます。これは、アプリケーションが所有する値です。元のOracle関数値をリストアするPL/SQL、DATEおよびTIME、SYSGUIDの場合、KEEP句をスキーマの一部として付与する必要があります。

現在、SYSDATE、SYSTIMESTAMP、LOCALTIMESTAMP、CURRENT_TIMESTAMP、SYS_GUIDおよびsequence.NEXTVALに対して、元のOracle関数値のリストアがサポートされています。元の値が保持されておらず、これらのオブジェクトの別の値がクライアントに戻されると、クライアントが認識する値が異なるため、リプレイは拒否されます。アプリケーションが元の値を使用できる場合、所有されている順序にはKEEP句を使用し、他のユーザーにはGRANT KEEPを使用して、元のOracle関数値のリストアを構成します。(ほとんどのアプリケーションでは、バインド変数の一貫性を維持するために、リプレイ時に順序値を保持する必要があります。)

ノート:

SYS_GUID値の保持は、シリアル処理計画に対してのみサポートされています。パラレル問合せを使用する場合、アプリケーション・コンティニュイティは、SYS_GUIDの元の値をリストアできません。

次の表に、リプレイ時の元のOracle関数値のリストアの処理の例を製品別に示します。(実際の実装は特定の製品およびリリースによって異なります。)

表6-1 リプレイ中の元のOracle関数値のリストアの製品別の処理の例

関数 製品1 製品2 製品3

SYSDATE、SYSTIMESTAMP

オリジナル

オリジナル

現行

順序NEXTVALおよびCURRVAL

オリジナル

オリジナル

(該当なし)

SYS_GUID

オリジナル

(該当なし)

(該当なし)

アプリケーション・コンティニュイティがリプレイ時に元のファンクション結果を保持および使用できるようにするには:

  • アプリケーションを実行するデータベース・ユーザーに、KEEP DATE TIMEおよびKEEP SYSGUID権限を付与し、値を保持する順序ごとにKEEP SEQUENCEオブジェクト権限を付与できます。たとえば: 

    GRANT KEEP DATE TIME TO user2;
GRANT KEEP SYSGUID TO user2;
GRANT KEEP SEQUENCE ON sales.seq1 TO user2;

    ノート:

    • Oracle Database 19c以降、順序のSQLに対して元のOracle関数値をリストアするための付与は必要ありません。

    • GRANT ALL ON objectには、KEEP DATE TIMEおよびKEEP SYSGUID権限とKEEP SEQUENCEオブジェクト権限は含まれません(つまり、これらによって提供されるアクセスは承認しません)。

    • 元のOracle関数値のリストアのサポートに関連する権限はアプリケーション・ユーザーに対してのみ付与し、各アプリケーション・ユーザーに対して必要な権限のみを付与します。

    • リプレイを有効化するアプリケーションを実行するデータベース・ユーザーには、DBA権限を付与しないでください。

  • アプリケーション内の順序には、KEEP属性を使用できます。この属性は、順序所有者に対してsequence.NEXTVALの元の値を保持することにより、リプレイ時にキーが一致するようにします。ほとんどのアプリケーションでは、リプレイ時に順序値を保持する必要があります。次の例では、順序に対してKEEP属性を設定しています(この場合は、文を実行するユーザーが所有する順序ですが、他の場合はGRANT KEEP SEQUENCEを使用してください)。 

    SQL> CREATE SEQUENCE my_seq KEEP;
SQL> -- Or, if the sequence already exists but without KEEP:
SQL> ALTER SEQUENCE my_seq KEEP;

    ノート:

    ALTER SEQUENCE ... KEEP/NOKEEPの指定は、順序の所有者に適用されます。これは、KEEP SEQUENCEオブジェクト権限を持つ他のユーザー(所有者ではありません)には影響しません。すべてのユーザーにKEEPを指定する場合、これらのユーザーにKEEP SEQUENCEオブジェクト権限を付与する(または、すでに権限が付与されている場合はそれを取り消す)ようにしてください。

  • リプレイ時にファンクション結果(名前付きファンクションの場合)を保持するには、ファンクションを起動するユーザーにDBAがKEEP権限を付与する必要があります。このセキュリティ制限により、ユーザーによって所有されていないコードに対するファンクション結果をリプレイのために保存およびリストアできるようになります。

アイデンティティ順序の場合、元のOracle関数値のリストアは、所有順序でサポートされています。SQLレベルでの元のOracle関数値のリストアは、アイデンティティ順序に対して自動的に行われます。アイデンティティ順序用にPL/SQLで元のOracle関数値をリストアするには、KEEP句を使用します。プロシージャと表の定義は次のとおりです。 

create table tab_identity_mine( id NUMBER GENERATED ALWAYS AS IDENTITY keep, content varchar2(50));

プロシージャを作成するには、次の文を使用します:

insert_identity(cnt in varchar2,newid out number) as 
begin 
insert into tab_identity_mine(content) values(cnt) returning id into newid;
end insert_identity;
KEEP権限の確認

リプレイ時に機能結果を保持するために必要なKEEP権限があることを確認する必要があります。

  • SYSDATEおよびSYSGUIDを保持する権限をチェックするには、次のようにします。
    SELECT * FROM USER_SYS_PRIVS WHERE PRIVILEGE LIKE '%KEEP%';

    次のような出力が表示されます。 

    USERNAME   PRIVILEGE        ADM   COM   INH
--------   --------------   ---   ---   ---
SOE1       KEEP SYSGUID     NO    NO    NO
SOE1       KEEP DATE TIME   NO    NO    NO
  • SEQUENCESを保持する権限を確認するには、次のようにします。
    SELECT SEQUENCE_NAME, KEEP_VALUE FROM USER_SEQUENCES;

    次のような出力が表示されます。 

    SEQUENCE_NAME   KEEP_VALUE
-------------   ----------
SEQ_PERSON      N      
SEQ_PLSQL       N
SEQ_PRODUCTS    Y
SEQ_PRODUCT_ID  Y

    前述の例のKEEP_VALUEは、YまたはNです。

    ノート:

    すべての順序の付与に対して、SELECT SEQUENCE_NAME, KEEP_VALUE FROM ALL_SEQUENCES;文を実行します。
元のOracle関数値をリストアするための保持権限の付与および取消し

リプレイで関数の結果を保持するには、関数を呼び出すユーザーにKEEP権限を付与する必要があります。

  • SYSDATEおよびSYSTIMESTAMPまたはSYSGUIDの元のOracle関数値のリストアを保持するための権限を付与するには:
    GRANT [KEEP DATE TIME | KEEP SYSGUID]...[to USER]

    たとえば、次のように、元の日付でOracle E-Business Suiteを使用できます。

    GRANT KEEP DATE TIME, KEEP SYSGUID to [custom user];
GRANT KEEP DATE TIME, KEEP SYSGUID to [apps user];
  • SYSDATEおよびSYSTIMESTAMPまたはSYSGUIDの元のOracle関数値のリストアを保持するための権限を取り消すには:
    REVOKE [KEEP DATE TIME | KEEP SYSGUID]...[from USER]
Oracle順序の元のOracle関数値のリストアを保持するための権限の付与

キーが一致するようにリプレイでsequence.nextvalの元の値を維持するには、順序に対する権限を付与する必要があります。

  • 順序の所有者としての権限を付与するには:
    CREATE SEQUENCE [sequence object] [KEEP|NOKEEP];
ALTER SEQUENCE [sequence object] [KEEP|NOKEEP];
  • 順序を使用するその他のユーザーに対して権限の付与および取消しを行うには:
    GRANT KEEP SEQUENCE on sequence.object to [myUser|role];
REVOKE KEEP SEQUENCE on sequence.object from [myUser|role];

    たとえば、次のように、元の順序値でOracle E-Business Suiteを使用できます。

    GRANT KEEP SEQUENCE on sequence.object to apps-user;
REVOKE KEEP SEQUENCE on sequence.object from my-user ;

    たとえば、アイデンティティ順序の場合は、表のcreateまたはalter文でKEEP句を使用します。 

    CREATE TABLE tab_identity_mine(id NUMBER GENERATED ALWAYS AS IDENTITY keep, 
content varchar2(50));
元のOracle関数値のリストアに関する権限付与のルール

これらの考慮事項は、元のOracle関数値のリストアに関する権限の付与および取消しに適用されます。

  • ユーザーにオブジェクトに対するすべてを付与した場合、元のOracle関数値のリストアは除外されます。元のOracle関数値をリストアするには、明示的な付与が必要です。SYS、AUDSYS、GSMUSER、SYSTEMなど、Oracle Databaseによって提供または作成されるユーザーへの元のOracle関数値のリストアの権限付与はサポートされていません。

  • DBAロールには、元のOracle関数値のリストアの権限が含まれます。

  • ユーザーに元のOracle関数値のリストアの権限が付与されている場合、その関数が(SYS_GUID、SYSDATEおよびSYSTIMESTAMPで)コールされると、オブジェクトは元のOracle関数値アクセスのリストアを継承します。

  • 順序オブジェクトで元のOracle関数値のリストアの保持が取り消された場合、そのオブジェクトを使用するSQLまたはPL/SQLコマンドでは、その順序に対する元のOracle関数値コレクションまたはアプリケーションのリストアは許可されません。

  • ランタイムおよびフェイルオーバー間で権限が取り消されると、収集された元のOracle関数値のリストアは適用されません。

  • ランタイムおよびフェイルオーバー間で権限が付与されると、元のOracle関数値のリストアは収集されず、したがって何も適用されません。

保護レベルの統計

リクエスト境界および保護レベルの統計を使用してカバレッジのレベルを監視します。

アプリケーション・コンティニュイティはシステム、セッション、およびサービスの統計を収集し、これにより、ユーザーは保護レベルを監視できるようになります。統計情報は、V$SESSTAT、V$SYSSTATで入手でき、サービス統計が有効になっている場合は、V$SERVICE_STATSでも入手できます。たとえば、V$SESSTATを問い合せてV$STATNAMEと結合した場合は、次のような出力が表示されます。 

NAME                                                             VALUE
---------------------------------------------------------------- ----------
cumulative begin requests                                               731
cumulative end requests                                                 739
cumulative user calls in requests                                      7285
cumulative user calls protected by Application Continuity              7228
cumulative time in requests                                      2665167909

これらの統計は自動ワークロード・リポジトリ(AWR)に保存され、AWRレポートで使用できます。統計には、次の情報が含まれます。

  • 完了リクエスト/秒
  • リクエストでのユーザー・コール
  • 保護されたユーザー・コール

AWRレポートの出力は、次のようになります。

Statistic                                Total    per Second    per Trans
---------------------------------------- -------- ------------- ---------
cumulative requests                       177,406          49.2       5.0
cumulative user calls in request          493,329         136.8      13.8
cumulative user calls protected           493,329         136.8      13.8

保護レベルの統計を有効にするには、(_request_boundaries = 3)を使用します。

親トピック: アプリケーション・コンティニュイティの操作および使用の管理

セッション状態一貫性

セッション状態一貫性は、リクエスト中に非トランザクション状態がどのように変化するかを示します。

  • セッション状態一貫性について
    セッション状態一貫性を確保するために、透過的アプリケーション・コンティニュイティで使用可能なサービス・パラメータsession_stateをAUTOに設定することをお薦めします。
  • 自動的なセッション状態の一貫性
    サービス・パラメータsession_stateをAUTOに設定した場合、透過的アプリケーション・コンティニュイティでは、リカバリ可能な停止の後にデータベース・セッションがリカバリできるようにセッションおよびトランザクションの状態を追跡および記録します。
  • 動的なセッション状態一貫性
    アプリケーション・コンティニュイティでは、動的なセッション状態一貫性が使用されます。セッション状態の整合性としてAUTOを使用すると、セッション状態はTACの場合と同様に追跡されます。

親トピック: アプリケーション・コンティニュイティの操作および使用の管理

セッション状態一貫性について

セッション状態一貫性を確保するために、透過的アプリケーション・コンティニュイティで使用可能なサービス・パラメータsession_stateをAUTOに設定することをお薦めします。

透過的アプリケーション・コンティニュイティでは、セッション状態を追跡および管理します。透過的アプリケーション・コンティニュイティを使用することを選択した場合、セッション状態の一貫性を確保するために何かを行う必要はありません。

アプリケーション・コンティニュイティの場合、session_stateをDYNAMICに設定できます。session_stateをDYNAMICに設定するのは、アプリケーションを十分に理解し、アプリケーションが設定された値を変更しないと想定される場合のみです。

セッション状態の例としては、NLS設定(グローバリゼーション・サポート)、オプティマイザのプリファレンス、イベントの設定、PL/SQLグローバル変数、一時表、アドバンスト・キュー、ラージ・オブジェクト(LOB)、結果キャッシュがあります。コミットされたトランザクションで非トランザクション値が変更される場合は、デフォルト値DYNAMICを使用します。

COMMITの実行後にDYNAMICモードを使用すると、そのトランザクションで状態が変更された場合、セッションが失われたときに、その状態を再確立するためのトランザクションのリプレイができなくなります。初期設定後のセッション状態が動的であるかどうか、さらにCOMMIT操作後の処理続行が正しいかどうかに応じて、アプリケーションを分類できます。

AUTOモードはほとんどすべてのアプリケーションに適しています。顧客またはユーザーがアプリケーションを変更できる場合は、AUTOまたはDYNAMICモードを使用する必要があります。AUTOモードは、DYNAMICモードの新しいバージョンであり、可能な場合は自動的に再度有効になる追加機能を備えています。

ノート:

長時間実行するステートレス・アプリケーションの場合、session_stateをAUTOに設定します。アプリケーション・コンティニュイティを必要としない場合、session_stateをAUTOに設定することをお薦めします。
自動的なセッション状態の一貫性

サービス・パラメータsession_stateをAUTOに設定した場合、透過的アプリケーション・コンティニュイティでは、リカバリ可能な停止の後にデータベース・セッションがリカバリできるようにセッションおよびトランザクションの状態を追跡および記録します。

session_stateをAUTOに設定することは、透過的アプリケーション・コンティニュイティで唯一許容される値です。AUTOに設定すると、アプリケーションがユーザー・コールを発行するときに、状態追跡インフラストラクチャによりセッション状態の使用状況が分類されます。追跡されるセッション状態は監視および検証されます。

ノート:

session_stateをAUTOに設定する場合は、failovertypeもAUTOに設定する必要があります。
リプレイ(つまり、透過的アプリケーション・コンティニュイティ)は、(通常のソースであるOracleプールからの、またはOCIまたはJDBCのthin APIによって追加される)明示的な開始リクエストで有効化され、リクエスト(たいていはプールに戻る)または制限付きコールの最後にCOMMITで無効になります。透過的アプリケーション・コンティニュイティでは、リクエスト内の無効化後にセッション状態が記述可能になると、リプレイが自動的に再有効化されます。次に、3つのアプリケーション・シナリオのステップ・ロジックを示します。

  • トランザクションなし

  • 最後の文としてCOMMITが使用されたトランザクション

  • COMMIT文が埋め込まれたトランザクション

ノート:

セッション状態セットが次のリクエストにリークしないようにする場合は、RESET_STATEを有効にします。これにより、PL/SQLの使用時にTACが次のリクエストで有効になります。

トランザクションなしのリクエストの場合、論理的なステップは次のようになります。

  1. 接続プールからチェックアウトします。

  2. リクエストを開始し、リプレイを有効化します。

  3. 1つ以上のSELECT文、および場合によっては他のPL/SQL文を発行します。

  4. その他のアクションを実行します。

  5. チェックインします。

  6. リクエストを終了します。

最後の文としてCOMMITが使用されたトランザクションのリクエストの場合、論理的なステップは次のようになります。

  1. 接続プールからチェックアウトします。

  2. リクエストを開始し、リプレイを有効化します。

  3. 1つ以上のSELECT文、および場合によっては他のPL/SQL文を発行します。

  4. トランザクションが開始されます。

  5. その他のアクションを実行します。

  6. コミット(リプレイを無効化)します。

  7. チェックインします。

  8. リクエストを終了します。

COMMIT文が埋め込まれたトランザクションのリクエストの場合、論理的なステップは次のようになります。

  1. 接続プールからチェックアウトします。

  2. リクエストを開始し、リプレイを有効化します。

  3. 1つ以上のSELECT文、および場合によっては他のPL/SQL文を発行します。

  4. トランザクションが開始されます。

  5. その他のアクションを実行します。

  6. コミット(リプレイを無効化)します。

  7. 次のPL/SQL文。可能な場合は透過的アプリケーション・コンティニュイティを再度有効にします。

  8. チェックインします。

  9. リクエストを終了します。

動的なセッション状態の一貫性

アプリケーション・コンティニュイティでは、動的なセッション状態一貫性が使用されます。セッション状態の整合性としてAUTOを使用すると、セッション状態はTACの場合と同様に追跡されます。

リプレイ(つまり、アプリケーション・コンティニュイティ)はbeginRequestコールで有効化され、COMMIT時(endRequestコール)または制限付きのコール時に無効化されます。次に、3つのアプリケーション・シナリオのステップ・ロジックを示します。

  • トランザクションなし

  • 最後の文としてCOMMITが使用されたトランザクション

  • COMMIT文が埋め込まれたトランザクション

トランザクションなしのリクエストの場合、論理的なステップは次のようになります。

  1. 接続プールからチェックアウトします。

  2. リクエストを開始し、リプレイを有効化します。

  3. 1つ以上のSELECT文、および場合によっては他のPL/SQL文を発行します。

  4. その他のアクションを実行します。

  5. チェックインします。

  6. リクエストを終了し、リプレイを無効化します。

最後の文としてCOMMITが使用されたトランザクションのリクエストの場合、論理的なステップは次のようになります。

  1. 接続プールからチェックアウトします。

  2. リクエストを開始し、リプレイを有効化します。

  3. 1つ以上のSELECT文、および場合によっては他のPL/SQL文を発行します。

  4. トランザクションが開始されます。

  5. その他のアクションを実行します。

  6. コミット(リプレイを無効化)します。

  7. チェックインします。

  8. リクエストを終了します。

COMMIT文が埋め込まれたトランザクションのリクエストの場合、論理的なステップは次のようになります。

  1. 接続プールからチェックアウトします。

  2. リクエストを開始し、リプレイを有効化します。

  3. 1つ以上のSELECT文、および場合によっては他のPL/SQL文を発行します。

  4. トランザクションが開始されます。

  5. その他のアクションを実行します。

  6. コミット(リプレイを無効化)します。

  7. その他のアクション。この間、アプリケーションはアプリケーション・コンティニュイティでカバーされません。

  8. チェックインします。

  9. リクエストを終了します。

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

アプリケーション・コンティニュイティが構成されたら、統計を使用してアプリケーション・コンティニュイティの使用状況を検証し、アプリケーション・コンティニュイティがユーザー・ワークロードをどの程度適切に保護しているかを確認できます。

V$SESSTATSおよびV$SYSSTATビューから次の統計を読み取ることができます:
  • 累積開始リクエスト
  • 累積終了リクエスト
  • リクエスト内の累積ユーザー・コール
  • アプリケーション・コンティニュイティで保護される累積ユーザー・コール
  • リクエストの累積時間
次の統計は、V$SESSTATSビューからのみ読み取ることができます:
  • リクエストの累積DB時間
  • リクエスト内で保護される累積DB時間
  • アプリケーション・コンティニュイティによって成功したリプレイ
  • アプリケーション・コンティニュイティによって拒否されたリプレイ

次の例は、アクティブ・セッションごとにアプリケーション・コンティニュイティ統計値を読み取る方法を示しています。

SQL> SELECT sn.name, s.value FROM V$SESSTAT s, V$STATNAME sn WHERE sn.statistic# = s.statistic# AND sn.name in(
    'cumulative begin requests','cumulative end requests','cumulative user calls in requests','cumulative user calls protected by Application
    Continuity','cumulative time in requests');

次の例は、V$SYSSTATビューからアプリケーション・コンティニュイティ統計を読み取る方法を示しています。 

SQL> SELECT name, value FROM V$SYSSTAT WHERE name in ('cumulative begin requests','cumulative end requests',
    'cumulative user calls in requests','cumulative user calls protected by Application Continuity','cumulative time in requests',
    'cumulative DB time in requests','cumulative DB time protected in requests','successful replays by Application Continuity',
    'rejected replays by Application Continuity');

親トピック: アプリケーション・コンティニュイティの操作および使用の管理

アプリケーション・コンティニュイティ保護チェック

アプリケーション・コンティニュイティ保護チェック(ACCHK)機能は、アプリケーション・コンティニュイティによるアプリケーションの保護を説明するアプリケーション・コンティニュイティのカバレッジ・レポートおよびビューを生成します。

親トピック: アプリケーション・コンティニュイティの操作および使用の管理

アプリケーション・コンティニュイティ保護チェックについて

アプリケーション・コンティニュイティ保護チェック(ACCHK)ユーティリティは、アプリケーション・コンティニュイティを使用するアプリケーションの保護ガイダンスを提供します。

ACCHKは、アプリケーション・コンティニュイティを使用する各アプリケーションの保護レベルに関するガイダンスを提供し、必要に応じて保護を向上させるために役立ちます。ACCHKでは、アプリケーション・コンティニュイティのトレースを使用してワークロードのカバレッジを収集し、リクエストに従って詳細情報を提供します。データベース・ワークロードを実行する前に、アプリケーション・コンティニュイティのトレースを有効にしてカバレッジを収集する必要があります。ACCHKは、失敗したフェイルオーバーの診断も提供します。

データベース・ビューおよびPL/SQLベースのレポートには、フェイルオーバーに対するアプリケーションの保護レベルが表示されます。アプリケーションが完全には保護されていない場合、ACCHKはそのアプリケーションを識別し、アプリケーションが完全に保護されていない理由を検出して、保護を強化する方法を示します。

保護されたアプリケーションの場合、ACCHKは、アプリケーションのどの操作が保護されていて、アプリケーションのどの操作が保護されていないかも報告します。アプリケーション・コンティニュイティによって保護されていないアプリケーションの操作または構成がある場合は、構成を変更して保護のカバレッジを増やすことができます。ACCHKは、ワークロードのカバレッジ文およびパーセンテージ値を含むレポートを生成します。ACCHKレポートには、実行された操作の数、完全に保護された操作の数および完全には保護されなかった操作の数も表示されます。

アプリケーション・コンティニュイティ保護チェックの有効化および無効化

アプリケーション・コンティニュイティを使用するアプリケーションのアプリケーション・コンティニュイティ保護チェック(ACCHK)機能を手動で有効または無効にできます。

アプリケーション・コンティニュイティ保護チェックはデフォルトでは有効化されていません。ACCHKを有効または無効にし、アプリケーションの保護レベルを確認するレポートを生成するには、次の手順に従います。
  1. ACCHK_READロールを使用して、アプリケーション・コンティニュイティ保護チェック・レポートおよびビューを実行するユーザーに読取りアクセス権を付与します。
    GRANT ACCHK_READ TO USER;
  2. dbms_app_cont_admin.acchk_set(true)プロシージャを使用して、アプリケーションのアプリケーション・コンティニュイティのトレースを有効にします。
    SQL> execute dbms_app_cont_admin.acchk_set(true);

    デフォルトでは、ACCHKは600秒後に自動的に無効になります。より小さい数値を指定すると、自動無効化時間を短縮できます。たとえば、300秒後にACCHKを無効にするには、dbms_app_cont_admin.acchk_set(true,300)プロシージャを使用します。

    dbms_app_cont_admin.acchk_set(true)プロシージャは、接続しているデータベース・レベルでアプリケーション・コンティニュイティのトレースを有効にします。CDBレベルで接続している場合、CDBに対してトレースが有効になり、PDBレベルで接続している場合、PDBに対してトレースが有効になります。

    ノート:

    COMPATIBLEパラメータを19c以上に設定します。以前にCOMPATIBLEパラメータが低い値に設定されていた場合、COMPATIBLEパラメータの更新後に初めてプロシージャを実行したときに、acchk_setプロシージャによってACCHKビューおよびロールが作成されます。
  3. dbms_app_cont_admin.acchk_set(false)プロシージャを使用して、アプリケーションの新しいセッションのアプリケーション・コンティニュイティのトレースを無効にします。
    SQL> execute dbms_app_cont_admin.acchk_set(false);

    ノート:

    • 時間が経過すると、現在のセッションのトレースが無効になります。
    • トレースは、Oracle Real Application (Oracle RAC)クラスタ全体に対してデフォルトで有効になっています。
アプリケーション・コンティニュイティ保護チェック・レポートの生成

アプリケーション・コンティニュイティ保護チェック(ACCHK)レポートを生成して、保護レベルのガイダンス、不完全な保護の理由、および保護レベルを上げる方法を取得します。

ACCHKユーティリティは、AUXのACCHK表を使用してアプリケーション・コンティニュイティ・カバレッジをレポートする後処理ツールです。ワークロードを実行してレポートを生成する前に、アプリケーション・コンティニュイティのトレースおよびアプリケーション・コンティニュイティ保護チェックを有効にします。

読取り専用モードの場合、トレースでイベントおよび統計を記録できます。ACCHK_REPORTのパラメータ・ソースを使用して、レポートを表示するためのプロシージャを使用する入力を決定します。表またはトレースから選択できます。データベースが読取り専用モードの場合は、このパラメータをDBMS_APP_CONT_REPORT.FROM_TRACESに設定します。

  1. アプリケーションのACCHKおよびトレースを有効にした後、一連のデータベース・オプションを実行します。
    ACCHKは、アプリケーション・コンティニュイティ・セッションのレポートのみを生成します。
  2. dbms_app_cont_report.acchk_reportプロシージャを使用して、アプリケーション・コンティニュイティ保護チェック・レポートを生成します。
    SQL> SET LINESIZE 350;
SQL> SET SERVEROUTPUT ON FORMAT WRAPPED;
SQL> execute dbms_app_cont_report.acchk_report;
    レポートのタイプは、FULL、WARNINGまたはSUMMARYから指定できます。たとえば:
    SQL> SET LINESIZE 350;
SQL> SET SERVEROUTPUT ON FORMAT WRAPPED;
SQL> execute dbms_app_cont_report.acchk_report(dbms_app_cont_report.FULL);
SQL> execute dbms_app_cont_report.acchk_report(dbms_app_cont_report.WARNING);
SQL> execute dbms_app_cont_report.acchk_report(dbms_app_cont_report.SUMMARY);

    デフォルトのレポート・タイプはSUMMARYです。

  3. レポートを分析し、完全には保護されていないアプリケーションの保護レベルを上げます。たとえば、サマリー・レポートは次のようになります。
    --------------------------------------
------------ ACCHK Report ------------
--------------------------------------
CON_ID SERVICE       FAILOVER PROTECTED_ PROTECTED_ REQUESTS AVG_CALLS/ PROTECTED_    AVG_TIME/  PROTECTED_TIME/ EVENT_  ERROR_ PROGRAM   MODULE            ACTION    SQL_ CALL      TOTAL
                              CALLS %    TIME %              REQUEST    CALLS/REQUEST REQUEST MS REQUEST MS      TYPE    CODE                                         ID                
------ ------------- -------- ---------- ---------- -------- ---------- ------------- ---------- --------------- ------- ------ --------- ----------------- –-------- ---- --------- –-----
3      srv_tacr_pdb1 AUTO     98.734     98.432     117      9.453      9.333         2279.751   2244.014        DISABLE 41409  JDBC Thin AddCustNewOrder   Action-20      COMMIT    1     
                                                                                                                                Client                                                     
3      srv_tacr_pdb1 AUTO     98.734     98.432     117      9.453      9.333         2279.751   2244.014        REPLAY_ 41412  JDBC Thin InsertNewChecksum Action-1       SQL/PLSQL 1     
                                                                                                                 FAILED         Client                                     Execu           
End of report.
次の例は、ACCHKビューを使用してACCHKレポートから詳細情報を問い合せる方法を示します。

例6-2 DBA_ACCHK_EVENTSビューの使用

この例の最後の行は、srv_tacr_pdb1サービスを使用しているアプリケーションにアプリケーション・コンティニュイティの失敗の原因となったイベントがあることを示しています。 

SQL> SELECT * FROM DBA_ACCHK_EVENTS ORDER BY TIMESTAMP;
INST_ID CON_ID TIMESTAMP        SESSION_ID SERIAL# SERVICE_NAME  PROGRAM  MODULE            ACTION    SQL_ID CALL_NAME EVENT_TYPE ERROR_CODE
------- ------ ---------------- ---------- ------- ------------- -------  ----------------- --------- ------ --------- ---------- ----------
2       3    21-SEP-20          9598       1644    srv_tacr_pdb1 JDBC     AddCustNewOrder   Action-36        COMMIT    DISABLE    41409
             06.54.18.191 PM                                     Thin                                         
             -07:00                                              Client                                                        
2       3    21-SEP-20          1703       61265   srv_tacr_pdb1 JDBC     InsertNewChecksum  Action-1        SQL/PLSQL REPLAY_    41412
             06.51.07.624 PM                                     Thin                                        Execution FAILED 
             -07:00                                               Client

例6-3 DBA_ACCHK_EVENTS_SUMMARYビューの使用

この例の最後の行は、srv_tacr_pdb1サービスを使用しているアプリケーションにアプリケーション・コンティニュイティの失敗の原因となったイベントがあることを示しています。 

SQL> SELECT * FROM DBA_ACCHK_EVENTS_SUMMARY ORDER BY SERVICE_NAME;
INST_ID CON_ID SERVICE_NAME  FAILOVER_TYPE FAILOVER_RESTORE RESET_STATE PROGRAM MODULE            ACTION    SQL_ID CALL_NAME EVENT_TYPE ERROR_CODE FREQUENCY
------- ------ ------------- ------------- ---------------- ----------- ------- ----------------- --------- ------ --------- ---------- ---------- ----------
2       3      srv_tacr_pdb1 AUTO          AUTO             LEVEL1      JDBC    AddCustNewOrder   Action-20        COMMIT    DISABLE    41409      1
                                                                        Thin                                       Execution    
                                                                        Client                               
2       3      srv_tacr_pdb1 AUTO          AUTO             LEVEL1      JDBC    InsertNewChecksum Action-1         SQL/PLSQL REPLAY_    41412      1
                                                                        Thin                                       Execution FAILED    
                                                                        Client

例6-4 DBA_ACCHK_STATISTICSビューの使用

この例では、最初の行は、srv_tacr_pdb1サービスを使用しているアプリケーションに、JDBCからの11個の暗黙的なリクエストとアプリケーション内の31個のコールがあることを示しています。これらのリクエストの30個のコールは保護されています。 

SQL> SELECT * FROM DBA_ACCHK_STATISTICS ORDER BY TIMESTAMP;
INST_ID CON_ID TIMESTAMP        SESSION_ID SERIAL# STAT_TYPE  SERVICE_NAME  FAILOVER_ FAILOVER_ RESET_ PROGRAM  BEGIN_   END_     USER_CALLS_ PROTECTED_CALLS_ TIME_IN_ TIME_PROTECTED_
                                                                            TYPE      RESTORE   STATE           REQUESTS REQUESTS IN_REQUESTS IN_REQUESTS      REQUESTS IN_REQUEST
------- ------ ---------------- ---------- ------- ---------- ------------- --------- --------- ------ -------  -------- -------- ----------- ---------------- -------- --------------- 
2       3      21-SEP-20        5653       54237   SESSION_   srv_tacr_pdb1 AUTO      AUTO      LEVEL1 JDBC     11       11       31          30               13316750 12415247
               06.54.25.321 PM                     STATISTICS                                          Thin                                                              
               -07:00                                                                                  Client                                                    
2       3      21-SEP-20        11291      26560   SESSION_   srv_tacr_pdb1 AUTO      AUTO      LEVEL1 JDBC     3        3        50          49               13094072 13068259
               06.54.24.915 PM                     STATISTICS                                          Thin
               -07:00                                                                                  Client

例6-5 DBA_ACCHK_STATISTICS_SUMMARYビューの使用

この例では、srv_tacr_pdb1サービスを使用しているアプリケーションに144個の暗黙的なリクエストがあり、これらのリクエストで99.5688328パーセントのコールがアプリケーション・コンティニュイティまたは透過的アプリケーション・コンティニュイティによって保護されています。 

SQL> SELECT * FROM DBA_ACCHK_STATISTICS_SUMMARY ORDER BY SERVICE_NAME;
INST_ID CON_ID SERVICE_NAME  FAILOVER_ FAILOVER_ RESET_ TOTAL_   PROTECTED_CALLS_ PROTECTED_TIME_ AVG_USER_CALLS_ AVG_PROTECTED_    AVG_TIME_   AVG_TIME_
                             TYPE      RESTORE   STATE  REQUESTS PERCENT          PERCENT         IN_REQUESTS     CALLS_IN_REQUESTS IN_REQUESTS PROTECTED_IN_REQUESTS
------- ------ ------------- --------- --------- ------ -------- ---------------- --------------- --------------- ----------------- ----------- –--------------------
2       3      srv_tacr_pdb1 AUTO      AUTO      LEVEL1 144       99.5688328       99.0130288      22.5486111      22.4513889         3078654.35  3048268.92
統計およびイベントのフィルタリング

ACCHKは、サービス、モジュール、プログラムまたはマシン名を介してデータをフィルタリングすることで、統計およびイベントを収集できます。

単一のサービス・フィルタまたは複数のサービス・フィルタを提供する場合、ACCHKは指定されたサービスに関連する統計およびイベントのみを記録します。この機能は、単一または複数のモジュール・フィルタのみに単一または複数のプログラム・フィルタのみを指定する場合にも適用されます。サービス、プログラム、モジュールおよびマシンと一致する統計およびイベントのみを記録するために、ACCHKのサービス、プログラム、モジュールおよびマシンのフィルタを提供します。

DBMS_APP_CONT_ADMINパッケージには、データをフィルタリングするために次のプロシージャが含まれています:
  • ACCHK_SET_FILTER
  • ACCHK_CLEAR_FILTER
  • ACCHK_SHOW_FILTERS

ノート:

ACCHK_SET_FILTERを使用してフィルタを追加した後、ACCHK_SET(TRUE)を実行してフィルタをロードする必要があります。フィルタを追加またはクリアしても、ACCHK_SET(TRUE)を実行しない場合、その特定のフィルタは更新されません。

フィルタ存続期間

  • フィルタは累積されます。
  • ACCHK_CLEAR_FILTERプロシージャは、プロシージャの実行方法に応じて1つまたはすべてのフィルタをクリアします。
ACCHK収集情報のクリーン・アップ

ACCHKレポートが生成され、ACCHKビューから収集されたデータが分析された後、ACCHKによって収集された情報をパージできます。

ACCHKによって収集された情報のパージはオプションです。既存のACCHK情報をパージした後、収集された新しいデータを使用して新しいACCHKプロセスを開始できます。

次の文を使用して、以前に収集されたすべてのACCHK情報をパージします:

SQL> execute dbms_app_cont_admin.acchk_purge(purge_all => TRUE);

アプリケーション・コンティニュイティでの再接続の遅延

アプリケーション・コンティニュイティまたは透過的アプリケーション・コンティニュイティを使用して再接続を管理するためのパラメータの設定方法について学習し、シングル・インスタンス・データベースおよびOracle Real Application Clusters (Oracle RAC)データベースの例を確認します。

親トピック: アプリケーション・コンティニュイティの操作および使用の管理

アプリケーション・コンティニュイティに対するサービスの準備が整うまで待機する方法の理解

計画および計画外の停止を管理するには、アプリケーション・コンティニュイティの管理に使用するパラメータについて学習します。

デフォルトでは、アプリケーション・コンティニュイティがフェイルオーバーを開始した場合、ドライバが、サービスを利用できるインスタンスで実行中の作業のリカバリを試みます。作業をリカバリするために、ドライバはインスタンスとの良好な接続を確立する必要があります。サービスが再配置および発行される前にデータベースまたはインスタンスを再起動する必要がある場合、再接続に時間がかかる場合があります。このため、サービスが別のインスタンスまたはデータベースから使用可能になるまでに、フェイルオーバーを遅延させる必要があります。

接続および再接続を管理するには、TNSまたはURLでRETRY_COUNTおよびRETRY_DELAYパラメータを使用する必要があります。これらのTNSパラメータは計画済停止と連動して使用すると効果があります。たとえば、サービスが数秒間使用不可になる可能性がある停止の場合などです。RETRY_COUNTおよびRETRY_DELAYパラメータを設定する場合は、まずREPLAY_INITIATION_TIMEOUTパラメータの値を確認します。RETRY_DELAYパラメータの値が高い場合、リプレイが取り消されることがあります。

パラメータ名 使用可能な値 デフォルト値

RETRY_COUNT

正の整数ゼロ以上

30

RETRY_DELAY

時間(秒、ミリ秒またはセンチ秒)

3
アプリケーション・コンティニュイティを使用するOracle RACのサービスの作成

透過的アプリケーション・コンティニュイティまたはアプリケーション・コンティニュイティを利用するサービスをOracle RACで作成できます。

ノート:

ポリシー管理データベース・デプロイメント・オプションは、Oracle Database 23aiでサポートされなくなりました。

次のように、透過的アプリケーション・コンティニュイティを使用するサービスを作成できます。

$ srvctl add service -db mydb -service TACSERVICE -pdb mypdb –preferred inst1 -available inst2 
  -failovertype AUTO -session_state AUTO -failover_restore AUTO -commit_outcome TRUE -replay_init_time 600 
  -retention 86400 -notification TRUE -drain_timeout 300 -stopoption IMMEDIATE -role PRIMARY

次のように、アプリケーション・コンティニュイティを使用するサービスを作成できます。

$ srvctl add service -db mydb -service ACSERVICE -pdb mypdb -preferred inst1 -available inst2 
  -failovertype TRANSACTION -session_state DYNAMIC -failover_restore LEVEL1 -commit_outcome TRUE  -replay_init_time 600 
  -retention 86400 - notification TRUE -drain_timeout 300 -stopoption IMMEDIATE -role PRIMARY
単一インスタンスのデータベースのサービスがアプリケーション・コンティニュイティを使用するように変更する方法

単一インスタンス・データベースを使用している場合は、次に示すようにDBMS_SERVICEパッケージを使用してサービスを変更します。

アプリケーション・コンティニュイティ:
DECLARE
params dbms_service.svc_parameter_array;
BEGIN
params('FAILOVER_TYPE'):='TRANSACTION';
params('REPLAY_INITIATION_TIMEOUT'):=1800;
params('RETENTION_TIMEOUT'):=86400;
params('FAILOVER_DELAY'):=10;
params('FAILOVER_RETRIES'):=30;
params('FAILOVER_RESTORE'):='LEVEL1';
params('commit_outcome'):='true';
params('aq_ha_notifications'):='true';
dbms_service.modify_service('[your service]',params);
END;
/
透過的アプリケーション・コンティニュイティ:
DECLARE
params dbms_service.svc_parameter_array;
BEGIN
params('FAILOVER_TYPE'):='AUTO';
params('REPLAY_INITIATION_TIMEOUT'):=1800;
params('RETENTION_TIMEOUT'):=86400;
params('FAILOVER_DELAY'):=10;
params('FAILOVER_RETRIES'):=30;
params('FAILOVER_RESTORE'):='AUTO';
params('commit_outcome'):='true';
params('aq_ha_notifications'):='true';
dbms_service.modify_service('[your service]',params);
END;
/

アプリケーション・コンティニュイティなしでの実行

無効化コールが発行されたために、アプリケーション・コンティニュイティが有効でない場合もあります。

アプリケーション・コンティニュイティは、起動されていない場合や無効化されている場合は有効ではありません。無効化されている場合、endRequestコールを介して無効のままにされます。

サービス・プロパティFAILOVER_TYPEの値がTRANSACTIONまたはAUTOに設定されていない場合、アプリケーション・コンティニュイティは起動されません。計画メンテナンスの場合、FAILOVER_TYPEの値を事前にTRANSACTIONまたはAUTOに設定します。この設定が新しい接続に適用され、既存の接続は元のサービス値のままになります。

アプリケーション・コンティニュイティは、次のいずれかが発生したときには、現在のリクエストに対して無効化されます。

  • アプリケーション・コンティニュイティが制限されている文をアプリケーションが実行する(たとえば、ALTER SYSTEM)。

  • disableReplayを使用してアプリケーション・コンティニュイティが明示的に無効化されます。

  • サービス・パラメータsession_state_consistencyがDynamic (透過的アプリケーション・コンティニュイティを使用しない場合はデフォルト)に設定されているときにCOMMIT文が発行されます。

  • 次のbeginRequestが発行されるまでendRequest文が発行されます。

  • セッションが終了または切断され、NOREPLAYキーワードが指定されます。

関連トピック

親トピック: アプリケーション・コンティニュイティの操作および使用の管理

アプリケーション・コンティニュイティにおけるリプレイの無効化

アプリケーションでリプレイを無効にする方法と、リプレイを無効にするための特定のルールおよびガイドラインについて学習します。

この項で説明されているルールは一般的なものです。これらは、アプリケーション・コンティニュイティおよびTAF (リリース12.2以降)が含まれていて、作業をリプレイするアプリケーションのすべてに適用されます。

親トピック: アプリケーション・コンティニュイティの操作および使用の管理

アプリケーション・コンティニュイティにおけるリプレイの有効化および無効化の理解

リプレイはリカバリ可能なエラーの後に実行されますが、リプレイを無効にできます。

繰り返す必要のないリクエストがアプリケーションにある場合、アプリケーションはアプリケーション・コンティニュイティが有効になっていないサービスへの接続を取得するか、これらのリクエストのリプレイを無効にするAPIを明示的に呼び出すことができます。透過的アプリケーション・コンティニュイティを使用する場合、副作用は自動的に検出され、無効化されます。アプリケーションを理解したり、副作用を含むリクエストを無効にする必要はありません。

アプリケーション・コンティニュイティを使用する場合、すべてのコールがリプレイされます。たとえば、アプリケーションがUTL_SMTPを使用しているためにメッセージを繰り返す必要がない場合は、アプリケーションでは別のサービスへの接続を使用するか、disableReplay API (Javaの場合)またはOCIRequestDisableReplay API (Oracle Call Interface (OCI)の場合)を使用できます。他のすべてのリクエストは引き続きリプレイされます。

外部アクション(自律型トランザクション、またはUTL_HTTPを使用したSOAコールを発行するトランザクションの使用など)の場合、障害後にこれらの外部アクションがリプレイされるときにアプリケーションの正確性が保持されている場合、アプリケーション・コンティニュイティは透過的のままです。

繰り返さない自律型トランザクション、外部PL/SQLまたはJavaアクションをアプリケーションがコールする場合

自律型トランザクション、外部PL/SQLコールおよびJavaコールアウトには、メイン・トランザクションとは異なる副作用がある場合があり、これらの副作用は、リプレイされないよう指定しないかぎりリプレイされます。

メイン・トランザクションとは別の副作用の例を次に示します。

  • 外部表への書込み、電子メールの送信、PL/SQLからのセッションの分岐(UTL_HTTP、UTL_URL、UTL_FILE、UTL_FILE_TRANSFER、UTL_SMPT、UTL_TCP、UTL_MAIL, DBMS_PIPEまたはDBMS_ALERTへのコールを含む)
  • 外部表への書込み、電子メールの送信、Javaからのセッションの分岐(Process proc = rt.exec(command);の形式でのシェル・スクリプトの実行を含む)、ファイルの転送および外部URLへのアクセス

このようなアクションの結果、永続的な副作用が残ります。PL/SQLメッセージングおよびJavaコールアウトの結果、永続的な結果が残される可能性があります。たとえば、ユーザーがコミットせずに作業を途中で止めた場合、セッションがタイムアウトした場合、またはユーザーが[Ctrl] + [C]コマンドを発行した場合、フォアグラウンドまたはコンポーネントは失敗します。その結果、メイン・トランザクションがロールバックされる一方、副作用が適用されている場合があります。

アプリケーション開発者は、外部アクションに対してリプレイを許可するかどうかを決定します。例として、UTL_HTTPを使用したSOAコールの発行、UTL_SMTPを使用したメッセージの送信、またはUTL_URLを使用したWebサイトへのアクセスがあります。この種の外部処理をリプレイしない場合は、アプリケーション・コンティニュイティなしで接続を使用するか、無効になっているリプレイAPIのいずれかを使用します。

アプリケーションが独立したセッションを同期する場合

COMMIT、ROLLBACK、またはセッション喪失まで保持される揮発エンティティを使用してアプリケーションが独立セッションと同期する場合、リプレイ用にアプリケーションを構成しないでください。

たとえば、複数のデータ・ソースに接続されている複数のセッションをアプリケーションで同期する場合(それ以外の場合、これらのセッションはデータベース・ロックなどのリソースを使用して相互に依存します)、この同期は、アプリケーションがこれらのセッションのみをシリアライズ化し、いずれかのセッションが失敗する可能性があることを認識している場合に許容されます。ただし、あるデータ・ソースによって保持されているロックまたは他の揮発リソースが、他の接続から同じまたは別のデータ・ソースのデータに対する排他的アクセスを意味するとアプリケーションが想定している場合、この想定はリプレイ時に無効になる可能性があります。

リプレイ中、セッションがロックまたは他の揮発リソースを維持している別のセッションに依存していることは、クライアント・ドライバでは認識されていません。障害によって失われた同期を実装するために、リソース(セマフォ、デバイス、ソケットなど)を使用しているパイプ、バッファ・キューまたはストアド・プロシージャを使用することもできます。

アプリケーションが処理ロジックで中間層の時刻を使用する場合

アプリケーションが処理ロジックの一部として中間層で実時間を使用する場合は、リプレイ用にアプリケーションを構成しないでください。

クライアント・ドライバは中間層の時間ロジックを繰り返しませんが、かわりにこのロジックの一部として実行されるデータベース・コールを使用します。たとえば、中間層の時間を使用するアプリケーションが、明示的にこれを使用していない場合は、時間T1で処理された文が時間T2で再処理されていないと想定することがあります。

ROWIDが変更されないことをアプリケーションが前提としている場合

アプリケーションがROWID値をキャッシュする場合、データベースが変更されているためにこれらのROWID値へのアクセスが無効になることがあります。

ROWIDによって表内の行が一意に特定されても、次のような状況ではROWIDの値が変更されることがあります。

  • 基礎となる表が再編成されます。

  • 表で索引が作成されます。

  • 基礎となる表がパーティション化されます。

  • 基礎となる表が移行されます。

  • 基礎となる表が、EXP/IMP/DULを使用してエクスポートおよびインポートされます。

  • 基礎となる表が、Oracle GoldenGateまたはその他のレプリケーション・テクノロジを使用して再構築されます。

  • 基礎となる表のデータベースがフラッシュバックまたはリストアされます。

一般に、将来の使用のためにアプリケーションがROWID値を保存することはお薦めできません。これは、対応する行が存在しないことや、まったく異なるデータを含んでいることがあるためです。ROWID値の使用がアプリケーション・コンティニュイティの使用を妨げることはありません。リプレイは拒否できます。

ロケーション値が変更されないことをアプリケーションが前提としている場合

物理的な識別子を使用するアプリケーションがある場合は、ここでガイドラインおよび例を確認して問題を回避します。

SYSCONTEXTオプションは、次の2つのセットで構成されます。

  • 各国語サポート(NLS)設定、ISDBA、CLIENT_IDENTIFIER、MODULE、ACTIONなどのロケーションに依存しないセット
  • 物理ロケータを使用する、ロケーションに依存するセット

通常、アプリケーションはテスト環境を除いて物理的な識別子を使用しません。物理ロケータがメインライン・コードで使用されている場合、リプレイによって不一致が検出され、拒否されます。ただし、リクエスト間(beginRequestの前)またはコールバックでは物理ロケータを使用してもかまいません。QAの一般的な問題は、テスト・アプリケーションがV$INSTANCEを選択するように変更することです。V$INSTANCEは変更可能なため、このチェックはコールバックにのみ配置するか、インスタンスをデータベースからではなくクライアントでローカルに選択します。

物理的な識別子の使用例 

select 
    sys_context('USERENV','DB_NAME') 
    ,sys_context('USERENV','HOST') 
    ,sys_context('USERENV','INSTANCE') 
    ,sys_context('USERENV','IP_ADDRESS') 
    ,sys_context('USERENV','ISDBA')  
    ,sys_context('USERENV','SESSIONID') 
    ,sys_context('USERENV','TERMINAL') 
    ,sys_context('USERENV','SID') 
from dual;

リプレイなしのセッションの終了または切断

DBAがALTER SYSTEM KILL SESSIONまたはALTER SYSTEM DISCONNECT SESSION文を使用してセッションの終了または切断を行ったときに、リプレイを無効にする方法を学習します。

アプリケーション・コンティニュイティが構成されている場合、DBAがALTER SYSTEM KILL SESSIONまたはALTER SYSTEM DISCONNECT SESSION文を使用してセッションを終了または切断すると、デフォルトではアプリケーション・コンティニュイティがセッションをリカバリしようとします。ただし、セッションをリプレイしない場合は、NOREPLAYキーワードを使用します。たとえば: 


alter system kill session 'sid, serial#, @inst' noreplay;

alter system disconnect session 'sid, serial#, @inst' noreplay

$ srvctl stop service -db orcl -instance orcl2 –drain_timeout 60 -stopoption immediate -force -noreplay

$ srvctl stop service -db orcl -node myode3 –noreplay -drain_timeout 60 -stopoption immediate -force

$ srvctl stop instance -node mynode3 -drain_timeout 60 -stopoption immediate -force –noreplay

ローカル・インスタンスで実行している(1つのセッションのみではなく)すべてのセッションを終了して、それらのセッションがリプレイされないようにする場合は、DBMS_SERVICE.DISCONNECT_SESSION PL/SQLプロシージャを使用して、disconnect_optionパラメータにNOREPLAYを指定することもできます。

関連トピック

親トピック: アプリケーション・コンティニュイティの操作および使用の管理

高速アプリケーション通知(FAN)

Oracle RAC高可用性フレームワークは、データベースとそのサービスを監視し、高速アプリケーション通知(FAN)イベント通知を送信します。

Oracle Databaseでは、最も高いサービス可用性の保持に焦点を当てています。Oracle Real Application Clusters (Oracle RAC)のサービスは、1つ以上のインスタンス間でロードを共有しながら、継続的に使用できるように設計されています。Oracle RACの高可用性フレームワークでは、Oracle Clusterwareとリソース・プロファイルを使用して、サービスの可用性を維持します。Oracle Clusterwareは、ビジネス・ルールとサービス属性に従って、サービスをリカバリするか、サービスを均等に分散します。

  • 高速アプリケーション通知(FAN)の概要
    FANは、データベース、ノードおよびネットワークに関連する停止後に、クライアントの即時割込みを実現します。
  • 高速アプリケーション通知の使用の重要性
    高速アプリケーション通知(FAN)イベントを使用すると、TCPタイムアウトを待機しているアプリケーション、障害の発生後にクライアントで最後の結果を処理するという時間の浪費、および低速なノード、一時停止したノードまたは終了したノードで作業を実行するという無駄な時間が排除されます。
  • Oracle DatabaseおよびApplicationsでのFANの使用方法
    高速アプリケーション通知(FAN)は、TCP/IPタイムアウトでアプリケーションが応答を停止しないようにするために不可欠です。
  • FANを使用するための要件
    Oracle Real Application Clusters (Oracle RAC)データベースに接続するクライアント・ドライバで、FAN対応機能を利用するために実行が必要なことについて説明します。
  • FANコールアウト
    高速アプリケーション通知(FAN)コールアウトは、サーバー側スクリプトであるか、またはFANイベントが生成されると必ず実行される実行可能ファイルです。
  • 高速アプリケーション通知の高可用性イベント
    高速アプリケーション通知(FAN)イベントがコールアウト・プログラムに情報を配信する方法について説明します。
  • 高可用性イベントのサブスクリプション
    サービスに関するアプリケーションを監視および通知するために、Oracle Real Application Clusters (Oracle RAC)ではOracle RAC Fast Application Notification (FAN)を使用します。
  • 高速アプリケーション通知のコールアウトの使用
    高速アプリケーション通知(FAN)コールアウトは、高可用性イベントが発生したときにOracle RACで即座に実行されるサーバー側のプログラム・ファイルです。

親トピック: アプリケーション・コンティニュイティの確保

高速アプリケーション通知(FAN)の概要

FANは、データベース、ノードおよびネットワークに関連する停止後に、クライアントの即時割込みを実現します。

FANは、障害直後のTCP/IPタイムアウトからクライアントを解放するために欠かせないものです。FANは、リソースが使用可能になると即座にクライアントに通知して、クライアントが計画メンテナンス中の停止を認識しないようにデータベース・セッションの排出を開始します。また、FANには構成レベルの情報とサービス・レベルの情報の通知も含まれています。この情報には、サービス・ステータスの変化が含まれます。

Oracleクライアント・ドライバおよびOracle Real Application Clusters (Oracle RAC)接続プールは、FANイベントに応答し、ただちに処理します。FANのUPイベントとDOWNイベントは、サービス、データベース、インスタンス、ネットワークおよびノードに適用されます。

関連トピック

親トピック: 高速アプリケーション通知(FAN)

高速アプリケーション通知の使用の重要性

高速アプリケーション通知(FAN)イベントを使用すると、TCPタイムアウトを待機しているアプリケーション、障害の発生後にクライアントで最後の結果を処理するという時間の浪費、および低速なノード、一時停止したノードまたは終了したノードで作業を実行するという無駄な時間が排除されます。

アプリケーションは、次のような重要な局面で時間を浪費する可能性があります。

  • ソケットをクローズしないでノードが失敗した場合のTCP/IPタイムアウトの待機、およびそのIPアドレスが停止している間の後続のすべての接続の待機。
  • サービスが停止した場合の接続の試行。
  • サービス再開時に接続しない。
  • サーバーが停止したときのクライアントでの最後の結果の処理。
  • 最適でないノードでの作業の試行。

ソケットをクローズしないでノードが失敗した場合、I/O待機(読取りまたは書込み)でブロックされたすべてのセッションはtcp_keepaliveを待機します。この待機ステータスは、ソケットで接続されているアプリケーションの場合の典型的な状況です。最後の結果を処理するセッションの状況はさらに悪く、次のデータが要求されるまで割り込みを受信しません。

親トピック: 高速アプリケーション通知(FAN)

Oracle DatabaseおよびApplicationsでのFANの使用方法

高速アプリケーション通知(FAN)は、TCP/IPタイムアウトでアプリケーションが応答を停止しないようにするために不可欠です。

FANイベントは、Oracle Database 12.2以降のOracle通知サービスを使用して発行されます。アドバンスト・キューイングは、古いOracle Call Interface (OCI)アプリケーション(12.2より前のOCIドライバ)の場合にのみFANイベントに使用されます。発行メカニズムは、Oracle RACのインストール時に自動的に構成されます。クライアントがFANイベントを受信できるようにするには、それぞれのクライアントに特定の設定が必要です。

  • OCIクライアントの場合は、サーバーでサービス属性notificationを設定する必要があります。たとえば、srvctl modify service -db EMEA -service GOLD -notification TRUEのようにします。また、OCIクライアントの場合は、oraaccess.xml構成ファイルでeventsをTRUEに設定する必要もあります。
  • ODP .Netクライアントの場合は、接続文字列のoraaccess.xmlでHA eventsをTRUEに設定する必要があります。
  • ユニバーサル接続プール・クライアントの場合、プロパティ・ファイルでプール・プロパティの高速接続フェイルオーバーをtrueに設定します(setFastConnectionFailoverEnabled(true))。

すべてのクライアントはONSの自動構成を使用してイベントを受信できるようになりますが、そうしたイベントに反応するようにクライアントを設定する必要はあります。

Oracle Net Servicesリスナーおよびグローバル・データ・サービス(GDS)は、FANイベントと統合されていることによって、リスナーおよびGDSは、障害が発生したインスタンスによって提供されているサービスを即座に登録解除でき、また、障害が発生したインスタンスに対する誤った接続リクエストの送信を回避できます。

Oracle接続プールは、FANを使用して、障害についての非常に高速な通知を受信し、障害後の接続を均等に分散します。障害が発生したコンポーネントが修復されると、接続を再度均等に分散します。そのために、Oracle Databaseインスタンスに接続するサービスが開始されると、接続プールはFANイベントを使用してそのリソースに作業を即座にルーティングします。データベース・インスタンスまたはノードのサービスが失敗すると、接続プールはFANイベントを使用して、リカバリのためにアプリケーションを即座に中断します。

クラスタの構成が変更されて、クラスタ内で状態の変更が発生した場合、Oracle Real Application Clusters (Oracle RAC)の高可用性フレームワークは、ただちにFANイベントを発行します。アプリケーションは、データベースに対するタイムアウトおよび問題の検出を待たずに、FANイベントを受信して即時に対応できます。FANを使用すると、インフライト・トランザクションがただちに終了し、インスタンスの失敗時にクライアントに通知されます。

また、FANは、 ロード・バランシング・アドバイザ・イベントも発行します。アプリケーションでFANのロード・バランシング・アドバイザ・イベントを使用して、現在、クラスタ内で最適なサービス品質を提供しているインスタンスに作業要求を割り当てることができます。

データベース・サービスの接続ロード・バランシングの目標にCLB_GOAL_LONGを指定している場合、リスナーは接続ロードを分散するときにロード・バランシング・アドバイザを使用します。ロード・バランシング・アドバイザが使用可能であった場合、リスナーで使用されるメトリックはさらに詳細に制御できます。

FANイベントは、次の方法で利用できます。

  • Oracle統合クライアントを使用すると、アプリケーションでFANを使用できます。FANイベント用の統合クライアントには、Oracle JDBC Universal Connection Pool、ODP.NET接続プール、OCIセッション・プール、Oracle WebLogic Server Active Gridlink for Oracle RAC、OCI、JDBC-thinおよびODP.NET管理クライアントと管理対象外クライアントがあります。FANの高可用性イベントを活用するには、統合OracleクライアントがOracle Database 10gリリース2 (10.2)以上である必要があります。プール・クライアントは、ロード・バランシング・アドバイザFANイベントを活用することもできます。

  • サード・パーティ製アプリケーション・コンテナ(Apache TomcatやWebSphereなどのコンテナ)は、デフォルトのプールのかわりにユニバーサル接続プール使用することで提供される組込みのFANサポートを使用するように構成できます。ユニバーサル接続プールは、Apache TomcatやWebSphereなどのサード・パーティ製Javaアプリケーション・サーバーの接続プールとして動作保証されています。

  • サード・パーティ製アプリケーション・サーバーまたはカスタム・アプリケーションで使用中のサード・パーティ製接続プールからのgetまたはreleaseの接続を標準インタフェースを使用してテストするために、OracleドライバのFAN対応機能を使用します。

    • このソリューションは、標準のTNS接続文字列の使用と、アプリケーションのCLASSPATHでons.jarファイルとsimpleFAN.jarファイルが使用できるようにすることで、標準のJavaアプリケーションに適用されます。

    • OCI/OCCIドライバの場合、OCI_ATTR_SERVER_STATUSサーバー・コンテキスト・ハンドル属性はFANイベントに依存し、接続がFANイベントの影響を受けている場合には、OCI_SERVER_NOT_CONNECTEDを返します。

  • サーバー側のコールアウトを使用して、データベース層にFANを実装できます。

  • JDBCおよびOracle RAC FANアプリケーション・プログラミング・インタフェース(API)を使用するか、OCIおよびODP.NETとともにコールバックを使用してFANイベントをサブスクライブし、イベントの受信時にイベント処理アクションを実行することで、アプリケーションはFANをプログラムで使用できます。

計画メンテナンスの際にアプリケーションがOCIまたはPro*プリコンパイラを使用している(OCIセッション・プールまたはTuxedoを使用していない)場合、アプリケーションはOCI_ATTR_SERVER_STATUSをチェックする必要があります。このチェックは、独自の接続プールにセッションが返されたときに追加します。また、アイドル接続に対しては定期的に、このチェックを追加します。計画メンテナンスによるFANのDOWNイベント後、この属性はOCI_SERVER_NOT_CONNECTEDに設定されます。アプリケーションは、この切断ステータスを読み取ると接続を閉じます。セッションは、アクティブな作業の排出のために、アプリケーションが閉じるまで開かれたままになります。これにより、エラーの発生しないフェールオーバーを実現します。

前述のリストの最初の項目に示されている統合クライアントのいずれかを使用すると、DOWNイベントの場合、FAN対応クライアントが失敗したインスタンスまたはノードへの接続をそれらが再使用される前に終了するため、アプリケーションの停止が最小限になります。アクティブな作業は、完了できるようになり、残りのインスタンスがある場合は、進行中の作業のためにサービスの継続が維持されます。インスタンスまたはサービスの停止時にアクティブなセッションは停止され、アプリケーション・ユーザーに即座に通知されます。未完了のトランザクションは、アプリケーション・コンティニュイティによって保護されます(有効化されている場合)。接続を要求しているアプリケーション・ユーザーは、使用可能インスタンスにのみ割り当てられます。

UPイベントでは、データベース・サービスおよびインスタンスが起動されている場合、アプリケーションが追加のハードウェア・リソースまたは追加容量を即時に利用できるように、新しい接続が作成されます。

親トピック: 高速アプリケーション通知(FAN)

FANを使用するための要件

Oracle Real Application Clusters (Oracle RAC)データベースに接続するクライアント・ドライバで、FAN対応機能を利用するために実行が必要なことを学習します。

Oracle Database 12cリリース2 (12.2)以降のリリースのクライアント・ドライバはFAN対応であり、FANはデフォルトで有効になっています。これは、JDBC Thinドライバ(12.2.0.1以降)およびOracle Data Provider for Net (ODP.NET)ドライバについても当てはまります。クライアント・ドライバは、計画および計画外のFANイベントを検出して、アプリケーションの下でアクションを実行できます。

ドライバでFAN対応機能を利用するには、次が必要になります。

  • Java Thinドライバの場合、リリース12.2以降のFANは、CLASSPATHにons.jarファイルとsimpleFAN.jarファイルを配置して、推奨されるTNSフォーマットを使用すると自動的に有効になります。推奨されるTNSフォーマットを使用して、自動的にONSを構成します。また、Java Thinドライバでは、計画イベントと計画外イベントの両方でFANがサポートされます。計画外停止の場合、FAN割込みが即時に発生します。計画メンテナンスの場合、Javaアプリケーション・サーバーまたはカスタム・プールを構成して、サード・パーティ製接続プールからのgetまたはreleaseの接続をテストするために標準インタフェースを使用します。たとえば、アプリケーション・サーバーに応じて、TestConnectionsOnReserve、TestOnBorrowまたはPreTest接続をテストします。

    このアプローチでは、計画メンテナンス中にFANイベントが受信されると、この時点ではアプリケーションにデータベースへの接続がないため、高速接続フェイルオーバー(FCF)がセッションを閉じて(セッションがテストされている場合)、新しい接続の再試行が可能になります。接続テストには、isValid、isClosed、isUsableまたはPingDatabaseが使用できます。

  • SQLコマンドの実行時、データベースは接続を排出します(次回の計画メンテナンスで影響を受ける場合)。接続プール、データソース、およびカスタマ・アプリケーション(プログラムの場合)のすべては、SQLコマンドの実行時に発生する回復可能なエラー(多くの場合、物理接続を閉じるエラー)を管理できるようにしておく必要があります。

  • サード・パーティのJavaアプリケーション・サーバーとJavaアプリケーションは、接続プールの開発時にPooledConnection標準インタフェースを使用できます。

  • Oracle Call Interface (OCI)およびOracle C++ Call Interface (OCCI)ドライバの11.2.0.3リリース以降、OCI_ATTR_SERVER_STATUSサーバー・コンテキスト・ハンドル属性がOCI_SERVER_NOT_CONNECTEDを返すときには、アプリケーションは接続を終了する必要があります。計画メンテナンスの場合は作業が排出されます。ドライバの12.2.0.1以降のリリースでは、計画DOWNイベントを受信したときに、OCISessionReleaseおよびOCIRequestEndを検出することもできます。

親トピック: 高速アプリケーション通知(FAN)

FANコールアウト

高速アプリケーション通知(FAN)コールアウトは、サーバー側スクリプトであるか、またはFANイベントが生成されると必ず実行される実行可能ファイルです。

次に示すように、様々な目的のコールアウトを設計して作成できます。

  • ステータス情報のログへの記録
  • リソースの起動に失敗した場合に、DBAへの通知またはサポート・チケットの発行を行います。
  • サービスと同じ場所に配置する必要がある外部依存アプリケーションの自動的な起動
  • ノードの障害などによって、データベースに使用できるインスタンスの数が減少した場合、サービスを停止
  • -failbackパラメータが十分でない場合、優先インスタンスへのサービスのフェイルバックを自動化

親トピック: 高速アプリケーション通知(FAN)

高速アプリケーション通知の高可用性イベント

高速アプリケーション通知(FAN)イベントがコールアウト・プログラムに情報を配信する方法を学習します。

次の例に示すように、コールアウトを介してFAN情報を受信した場合は、FANイベント・タイプが常に最初のエントリとして表示されます。

#service UP when the service starts
SERVICEMEMBER VERSION=1.0 
   service=HRPDB1.example.com database=ractest 
   instance=ractest2 host=prod_host01_1 status=up reason=BOOT 
   card=1 timestamp=2019-10-24 09:11:51 timezone=+00:00 
   db_domain=example.com 
SERVICE VERSION=1.0
   service=HRPDB1.example.com database=ractest instance=ractest2 
   host=prod_host01_1 status=up reason=BOOT 
   timestamp=2019-10-24 09:11:51 timezone=+00:00 
   db_domain=example.com

#service DOWN 
SERVICEMEMBER VERSION=1.0 service=HRPDB1.example.com database=ractest
   instance=ractest2 host=prod_host01_1 status=down reason=USER 
   timestamp=2019-10-25 17:59:43 timezone=+00:00 db_domain=example.com 
   drain_timeout=120  
SERVICE VERSION=1.0 service=HRPDB1.example.com database=ractest 
   instance=ractest2 host=prod_host01_1 status=down reason=FAILURE 
   timestamp=2019-10-24 21:25:57 timezone=+00:00 db_domain=example.com

通常、前述の例は1行として表示される点に注意してください。

FANイベントのタイプは、次のとおりです。

  • DATABASE
  • INSTANCE
  • NODE
  • SERVICE
  • SERVICEMEMBER
  • SERVICEMETRICS

DATABASEとINSTANCEタイプは、デフォルト・データベース・サービスをDB_UNIQUE_NAMEとしてリストします。

NODEイベントを除くすべてのイベントにdb_domainフィールドが含まれています。

SERVICEMETRICSタイプのイベントは、ロード・バランシング・アドバイザのイベントです。

次の表では、イベント・パラメータの名前/値ペアについて説明し、ロード・バランシング・イベントに関する詳細を示します。

表6-2 イベント・パラメータの名前/値のペアと説明

パラメータ 説明
VERSION

イベント・レコードのバージョン。リリースの変更を識別するために使用されます。
database

サービスをサポートする一意のデータベース名。DB_UNIQUE_NAMEの初期化パラメータ値に該当し、これにより、DB_NAME初期化パラメータの値がデフォルトに設定されます。

instance

サービスをサポートするインスタンスの名前。
host

サービスをサポートしているノードまたは停止したノードの名前であり、Cluster Synchronization Services(CSS)で認識されるノード名と一致します。
service

サービス名。DBA_SERVICESでリストされているサービスの名前に一致し、適宜修飾されたドメインです。次の例を参照してください。 

SERVICEMEMBER VERSION=1.0 service=swingbench
 database=orcl instance=orcl_2 host=dev_host1 status=up
 reason=USER card=1 timestamp=2018-05-29 17:26:37
 timezone=-07:00 db_domain=

SERVICEMEMBER VERSION=1.0 service=swingbench.example.com
 database=orcl instance=orcl1 host=dev_host1 status=up
 reason=USER card=2 timestamp=2018-05-03 17:29:28
 timezone=-07:00 db_domain=example.com

SERVICEMEMBER VERSION=1.0 service=swingbench.example.com
 database=orcl instance=orcl2 host=dev_host1 status=up
 reason=USER card=1 timestamp=2018-07-03 17:29:18
 timezone=-07:00 db_domain=example.com
status

値は、UP、DOWN、NODEDOWN(これはNODEイベント・タイプにのみ適用される)、NOT_RESTARTINGおよびUNKNOWNです。

ノート:

  • ノードが停止している場合、ステータスはNODEDOWNです。他のイベント・タイプの場合はDOWNです。

  • STATUS=NODEDOWNおよびREASON=MEMBER_LEAVEの場合、ノードに障害が発生しており、ノードはクラスタの一部ではないか、ユーザーがノードを停止しています。

  • STATUS=NODEDOWNおよびREASON=PUBLIC_NW_DOWNの場合、ノードは起動していますが、障害またはユーザー・アクションによりパブリック・ネットワークが停止しているため、ノードは使用不可です。

  • 複数のパブリック・ネットワークがOracle Clusterwareでサポートされています。FANイベントでは、この事実が反映されています。
reason

AUTOSTART、BOOT、DEPENDENCY、FAILURE、MEMBER_LEAVE、PUBLIC_NW_DOWN、USER。

ノート:

  • DATABASEおよびSERVICEイベント・タイプの場合のREASON=AUTOSTARTは、ノードの起動時に、AUTO_STARTリソース属性がリストアに設定されており、ノードの起動前にリソースがオフラインであったことを示します。

  • DATABASEおよびSERVICEイベント・タイプの場合のREASON=BOOTは、ノードの起動時に、リソースがノードの起動前からオンラインであったためリソースが起動したことを示します。

  • SRVCTLおよびOracle Enterprise Manager操作の場合、REASON=USERはそのような操作の計画済アクションを作業の排出として記述します。

card (カーディナリティ)

現在アクティブなサービス・メンバーの数。すべてのSERVICEMEMBER UPイベントに含まれます。

SERVICEMEMBER UPイベントの例を次に示します。 

SERVICEMEMBER VERSION=1.0 service=swingbench.example.com
database=orcl instance=orcl_2 host=dev_host3 status=up reason=USER card=1
timestamp=2018-07-12 14:46:46  timezone=-07:00 db_domain=example.com
incarn (インカーネーション)

NODEDOWNイベント用の新しいクラスタ・インカネーション。この値は、メンバーがクラスタに参加したり、クラスタから離脱するたびに変更されます。

NODEDOWNイベントの例を次に示します。 

VERSION=1.0 event_type=NODE host=dev_host2 incarn=175615351 status=nodedown
reason=member_leave timestamp=2019-10-24 05:55:06 timezone=+00:00
timestamp

Oracle Clusterwareに基づく、イベントが発生した時間。
timezone

GMT +/-hh:mmとして指定され、イベントが発生した、Oracle Clusterwareのタイム・ゾーン。
drain_timeout

サービスが排出される秒単位の時間。SERVICEMEMBERイベントで表示されます

vip_ips

停止したパブリック・ネットワーク上のVIP。NODEイベントの一部。

NODEDOWNイベントの例を次に示します。 

NODE VERSION=2.0 host=my-exa status=nodedown reason=public_nw_down 
incarn=0 timestamp=2019-10-24 09:02:35 timezone=+00:00 vip_ips=10.1.1.94

次の表に示すように、FANイベント・レコード・パラメータのいくつかには、デフォルトのネームスペースUSERENVを使用しているSYS_CONTEXT関数によって戻される値に対応する値があります。

表6-3 FANパラメータおよび該当するセッション情報

FANパラメータ 該当するセッション情報
SERVICE sys_context('userenv', 'service_name')
DATABASE_UNIQUE_NAME sys_context('userenv', 'db_unique_name')
INSTANCE sys_context('userenv', 'instance_name')
CLUSTER_NODE_NAME sys_context('userenv', 'server_host')

親トピック: 高速アプリケーション通知(FAN)

高可用性イベントのサブスクリプション

サービスに関するアプリケーションを監視および通知するために、Oracle Real Application Clusters (Oracle RAC)ではOracle RAC Fast Application Notification (FAN)を使用します。

Oracle RACは、FANを使用して、構成の変更や、サービスで使用可能な各インスタンスが提供している現在のサービス・レベルをアプリケーションに通知します。Oracle Call Interface (OCI)クライアントまたはODP.NETクライアントを使用してFANイベントを受信している場合は、-notificationパラメータを指定してSRVCTLを使用して、そのクライアントが使用するサービスを有効にして、アラート通知キューにアクセスする必要があります。

親トピック: 高速アプリケーション通知(FAN)

高速アプリケーション通知のコールアウトの使用

高速アプリケーション通知(FAN)コールアウトは、高可用性イベントが発生したときにOracle RACで即座に実行されるサーバー側のプログラム・ファイルです。

FANコールアウトを使用すると、クラスタ構成でイベントが発生した場合に、次のようなアクティビティを自動的に実行できます。

  • 障害追跡チケットのオープン
  • ページャへのメッセージの送信
  • 電子メールの送信
  • サーバー側のアプリケーションの起動および停止
  • 発生時の各イベントのロギングによるアップタイム・ログのメンテナンス
  • 優先度の高いサービスがオンラインになった場合の優先度の低いサービスの再配置

FANコールアウトを使用するには、Oracle Clusterwareを実行しているすべてのノードのGrid_home/racg/usrcoディレクトリにプログラム・ファイルを配置します。プログラム・ファイルは、別のプログラムからオプションの引数でコールされた場合、スタンドアロンで実行可能である必要があります。次に、Grid_home/racg/usrcoディレクトリに配置されている、callout.shという名前のシェル・スクリプトの例を示します。 

#! /bin/bash
FAN_LOGFILE= [your_path_name]/admin/log/'hostname'_uptime'.log
echo $* "reported="'date' >> $FAN_LOGFILE &

前述の例では、FANイベントが生成されるたびに、シェル・スクリプトの$FAN_LOGFILEによって示されるログ・ファイルに次のようなエントリを追加します。 

NODE VERSION=2.0 host=my-exa status=nodedown reason=public_nw_down 
incarn=0 timestamp=2019-10-24  09:02:35 timezone=+00:00 vip_ips=10.1.1.94

FANイベント・レコードの内容は、データベースにログオンしているユーザーの現行のセッションに一致します。また、Oracle Call Interface (OCI)接続ハンドルと記述子属性(OCIAttrGet()を使用)を使用すると、ユーザー環境(USERENV)情報も使用できます。この情報を使用すると、FANイベントのデータに該当するセッションでアクションを実行できます。

通常、イベントはそれが発生したノード上のユーザー・コールアウトにポストされるだけです。たとえば、node1のデータベースが停止した場合、コールアウトはnode1のみにポストされます。唯一の例外は、ノード停止とVIP停止イベントで、これらのイベントは、発生した場所にかかわらず、すべてのノードにポストされます。

関連トピック

親トピック: 高速アプリケーション通知(FAN)

計画外停止の構成

管理者管理Oracle RACデータベース内の1つ以上のインスタンスにサービスを割り当て、停止が認識されないようにできます。

ノート:

ポリシー管理データベース・デプロイメント・オプションは、Oracle Database 23aiでサポートされなくなりました。

アプリケーション開発者にとってデータベース・セッション(インスタンス、ノード、ストレージやネットワークなどに関連するコンポーネント)の停止をマスキングすることは複雑なタスクです。その結果として、エラーやタイムアウトはエンド・ユーザーにさらされることが多く、ユーザーの不満、生産性や機会の喪失につながります。FANとアプリケーション・コンティニュイティは連携して、停止後に影響を受けるデータベース・セッションの進行中の作業をリカバリすることで、ユーザーとアプリケーションから停止をマスクします。アプリケーション・コンティニュイティは、このリカバリをアプリケーションの下で実行するため、アプリケーションは停止をリクエストの処理のわずかな遅延として認識するようになります。

Oracle Real Application Clusters (Oracle RAC)で停止が検出されると、Oracle Clusterwareは、障害が発生したコンポーネントを隔離して、依存コンポーネントをリカバリします。サービスの場合、障害が発生したコンポーネントがインスタンスであった場合、Oracle Clusterwareはサービスのカーディナリティを維持しようとします。サービス定義によりフェイルオーバーが許可され、カーディナリティを維持するためにフェイルオーバーが必要な場合は、フェイルオーバーが発生します。

高速アプリケーション通知(FAN)イベントは、Oracle Databaseアーキテクチャ内の様々なレベルで発生する可能性があります。旧リリースのOracle Call Interface (OCI)クライアントとの下位互換性を提供するために、Oracle Notification ServiceやOracle Advanced Queuingを使用して発行されます。FANコールアウトは、FANイベントに応答してデータベース・サーバーで実行されるように記述することもできます。

ノート:

Oracle RACのコールアウトの実行では、順序は保証されません。コールアウトは非同期で実行され、スケジュールは変動します。

障害ノードのサービスが停止すると、残りのノードからFANが発行されます。Oracle RAC環境内でサービスを提供するインスタンスの位置および数は、アプリケーションに対して透過的です。再起動およびリカバリは自動的に実行され、データベースのみでなく、リスナーやOracle Automatic Storage Management (Oracle ASM)プロセスなどのサブシステムも再起動されます。FANコールアウトを使用して、障害管理システムに障害を報告して、修復ジョブを起動できます。

関連トピック

親トピック: アプリケーション・コンティニュイティの確保

計画メンテナンスの管理

アプリケーション・ユーザーに対するサービス中断を最小限に抑えるために、Oracle Real Application Clusters (Oracle RAC)には、サービスを再配置、無効および有効にするインタフェースが用意されています。

親トピック: アプリケーション・コンティニュイティの確保

計画メンテナンスの管理について

修復、アップグレードおよび変更の場合は、サービスを停止または再配置する前にセッションを排出します。

サービスを再配置する場合は、サービスが別のインスタンスで実行される必要があることを示します。サービスが停止または再配置された場合、計画済理由コード(通常はreason=user)でFANが発行されます。操作を完了したら、サービスを通常の操作に戻すか、またはサービスを有効にしてから、再起動することができます。サービスが再起動されると、FANはUPステータス・コードで発行されます。

データベースを手動で停止すると、依存性のために、そのデータベースのすべてのサービスも自動的に停止されます。データベースを手動で再起したときにサービスが自動的に起動するようにする場合は、サービスの管理ポリシーをautomaticに設定する必要があります。データベースの1つのインスタンスのみをシャットダウンして、サービスの提供が継続されるようにするには、srvctl relocate serviceを使用してサービスを再配置するか、-failoverオプションを指定したsrvctl stop instanceを使用してインスタンスを停止します。これにより、サービスはフェイルオーバー・ポリシーに従って自動的にフェイルオーバーできるようになります。

どちらの場合も、サービスの下で実行している作業をリクエスト境界で排出することをお薦めします。排出間隔は、サービスの属性として指定されています。また、SRVCTLコマンドラインで排出間隔を指定することもできます。

関連トピック

親トピック: 計画メンテナンスの管理

ユーザーを妨害しない計画メンテナンス

FAN対応のOracleまたはOracle以外の接続プールにより制御された期間中のインスタンスから、またはOracle Database18c以降はデータベース自体で、データベース・セッションを排出することをお薦めします。

データベース・セッションの排出は、アプリケーションを中断せずに作業を移行する最も安全な方法です。排出が接続テスト時およびリクエスト境界の外で発生した場合、これは100%適切です。既存の作業が完了すると、アプリケーションは中断せずに続行し、新しい作業が別のインスタンスで同じサービス機能のセッションを取得します。その結果、アプリケーションにはエラーが返されず、データベース・セッションの状態が不正になるリスクがありません。接続テストの場合、コール元は受信するリターン・コードが正しくても正しくなくても、結果を処理する準備ができているので、接続テストの検査が広範囲に適用可能で非常に強力なソリューションになります。

サービス属性の-drain_timeoutと-stopoptionでは排出期間を制御し、この期間の経過後に完了していないセッションをサービスで管理する方法を制御します。完了後にプールにチェックインするリクエストまたは完了後に閉じるリクエストは、計画メンテナンスの影響を受けない新しい場所に転送できます。

アプリケーション・コンティニュイティでは、割り当てられた排出時間内に完了しないリクエストにサービスを継続することで追加の対策を提供します。FAN対応のプールを使用すると、FANが計画したDOWNイベントの受信後に、セッションはリクエスト境界で排出できるようになります。

すべてのアプリケーションがOracle接続プールを使用するわけではなく、すべてのアプリケーションがFANを認識しているわけでもないため、データベースでは計画メンテナンス中にセッションを検査し、アプリケーションが中断されないようにセッションを停止する安全な場所を探します。サービスを停止した後、データベースは接続を閉じることができる安全な場所を検索します。接続が閉じると、データベースではセッションをクリーンアップします。

安全な場所でセッションを停止すると、アプリケーションは必要な状態で新規接続を開くことができます。セッションの排出では、各セッションに関係する作業が発生する場合があります。セッションを即座に閉じる必要はありませんが、可能であれば、排出のタイムアウト期間が経過する前にアプリケーションにエラーが表示されない安全な場所で閉じる必要があります。

発行済の作業はリクエストによって完了できるため、リクエストはトランザクションよりもはるかに重要です。Oracle Universal Connection Poolは、リクエストの排出の際に排出タイムアウトを使用して段階的な排出を実行します。元のセッションを一度に解放するのではなく、期間全体で徐々に解放することで、排出されるインスタンスのログインのオーバーロードを回避します。段階的な排出には、ターゲット・インスタンスで実行中の別の作業を妨害しないという利点があります。

DRAIN_TIMEOUTとSTOP_OPTIONは、サービスを追加するとき、または作成後のサービスを変更するときに定義できるサービスの属性です。これらの属性は、SRVCTLを使用して指定することもできます。このようにすると、サーバーで定義されているものよりも優先されます。次に示すSRVCTLコマンドを使用すると、-drain_timeoutパラメータと-stopoptionパラメータを指定できます。

  • srvctl add service

  • srvctl modify service

  • srvctl relocate service

  • srvctl stop service

  • srvctl stop database

  • srvctl stop instance

  • srvctl stop pdb

  • srvctl relocate pdb

ユーザーを妨害することなく計画メンテナンスを管理するには:

  1. SRVCTLを使用してシングルトン・サービス、またはすべてのノードで実行中でないサービスを再配置します。前述の各SRVCTLコマンド(addとmodifyを除く)に、-forceフラグを使用します。-forceフラグは、srvctl relocate serviceまたはsrvctl stop serviceのどちらかを実行するときに、コマンドラインで-stopoptionパラメータを指定した場合に使用する必要があります。たとえば:
    $ srvctl relocate service –db mycdb01 –service myservice –drain_timeout 120
  –stopoption IMMEDIATE –oldinst mycdb01_01 -force
    前述のコマンドは、mycdb01_01というインスタンスのmyservice01というサービスを、そのサービスを実行するように構成されたインスタンスに再配置します。Oracle Clusterwareは、このインスタンスを選択して(コマンドラインでターゲットを指定していない場合)、アクティブなセッションを排出するために2分間待機し(この例の場合)、その後でmycdb01_01に残っているセッションが強制的に切断されます。接続プールにより、要求境界で接続が自動的に解放されます。

    ノート:

    再配置するサービスが現在すべてのノードで実行中の均一サービスである場合、前述のコマンドはエラーを返し、サービスがすべてのインスタンスで起動していなければ、均一サービスの場合に前述のコマンド例は成功します。
  2. FAN計画済DOWNイベントにより、アイドル・セッションが接続プールからただちにクリアされ、次のチェックインで解放されるアクティブ・セッションがマークされます。これらのFANアクションにより、ユーザーの作業を妨げずにセッションがインスタンスから排出されます。

    他のインスタンスの既存の接続は使用可能なままで、必要な場合はこれらのインスタンスに新しい接続をオープンできます。排出するセッションには、データベースによってマークも付けられます。データベースは、接続テストと安全なフェイルオーバー先(Oracle Database 19c以降の場合)を探します。透過的アプリケーション・コンティニュイティでの暗黙的な接続境界は、このような場所です。

  3. どの場合でも、すべてのセッションが接続をプールにチェックインするわけではありません。ベスト・プラクティスとして、タイムアウト期間を設定して(-drain_timeoutパラメータで設定)、その後で、残っているクライアント接続を削除するためにインスタンスがシャットダウンされるようにするか、サービスが停止されるようにすることをお薦めします。
    排出間隔の経過後、-stopoptionパラメータが実施されます。このパラメータは、サービスまたはデータベースに対して次のように定義できます。

    • サービスを停止する場合(srvctl stop service)、-stopoptionパラメータを使用すると停止オプションのTRANSACTIONALまたはIMMEDIATEのいずれかを指定できます

    • データベースを停止する場合(srvctl stop database)、-stopoptionパラメータを使用すると停止オプションのNORMAL、TRANSACTIONAL、IMMEDIATE、ABORTのいずれかを指定できます

    データベースの停止オプションとサーバーの停止オプションの相関は次のとおりです。
    • NORMAL=NONE
    • TRANSACTIONAL/TRANSACTIONAL LOCAL=TRANSACTIONAL
    • IMMEDIATE/ABORT=IMMEDIATE

    アプリケーション・コンティニュイティを使用するように構成されたサービスの場合、ユーザーとアプリケーションから停止をマスクするために、終了された後で残っているセッションのリカバリが試行されます。

  4. メンテナンスが完了後に、元のノードでインスタンスとサービスを再起動します。
  5. サービスのFAN UPイベントにより、新しいインスタンスが使用可能で、次の要求境界でこのインスタンス上にセッションを作成できることが接続プールに通知されます。

関連トピック

親トピック: 計画メンテナンスの管理

メンテナンスのためのサービスのグループの管理

Oracle Real Application Clusters (Oracle RAC)では、SRVCTLを使用してクラスタ内のサービスのグループを管理できます。

  • サービスのグループの停止例
    SRVCTLを使用して、ノード名、データベース名、プラガブル・データベース名またはインスタンス名でサービスを停止する方法を示します。
  • サービスの開始
    srvctl start serviceコマンドを使用して、ノード上のすべてのサービス、データベースによって提供されるすべてのサービス、またはプラガブル・データベースによって提供されるすべてのサービスを起動できます。
  • プラガブル・データベース・レベルの操作
    SRVCTLを使用すると、プラガブル・データベースのサービスを管理できます。
  • サービスの再配置
    srvctl relocate serviceコマンドを使用すると、ターゲット宛先にサービスを再配置できます。インスタンス、ノードまたはデータベースが再配置の宛先になります。
  • サービスの停止
    srvctl stop serviceコマンドを使用して、ノード上のすべてのサービス、データベースによって提供されるすべてのサービス、またはプラガブル・データベースによって提供されるすべてのサービスを停止できます。

親トピック: 計画メンテナンスの管理

サービスのグループの停止例

SRVCTLを使用して、ノード名、データベース名、プラガブル・データベース名またはインスタンス名でサービスを停止する方法を示します。

多くの企業が多数のサービスを実行しています。多数のサービスが単一のデータベースまたはインスタンスで提供されることも、多数のデータベースが同じノード上で実行する少数のサービスを提供することもあります。個別のサービスごとにSRVCTLコマンドを実行する必要はなくなり、影響を受けるすべてのサービスのノード名、データベース名、プラガブル・データベース名またはインスタンス名を指定することのみが必要になります。

たとえば、racnode01というノードで実行しているすべてのサービスを停止する場合は、次にコマンドを使用できます。 

$ srvctl stop service –node racnode01 –drain_timeout 60 –stopoption IMMEDIATE

このコマンドでは、60秒の排出間隔を割り当てて、racnode01で実行しているすべてのサービスを停止します。60秒後に、残っているセッションは即座に停止されます。この60秒の排出タイムアウト間隔は、あらゆるサービスの属性設定をオーバーライドします。

このコマンドは、次の例に示すように、ノード上のデータベースを停止する場合にも適しています。
$ srvctl stop instance 	-node racnode01 -drain_timeout 60 –stopoption TRANSACTIONAL LOCAL -failover –force
-failoverパラメータを指定すると、次のようになります。

  • すべてのサービスは、指定した排出タイムアウト間隔と停止オプションを考慮して再配置されます(可能な場合)。

  • フェイルオーバーできないサービスは、指定された停止オプションを使用して停止されます。

  • 排出タイムアウト間隔の経過まで待機するか、ターゲットのサービスのセッションがすべて削除されるまで待機します(どちらか早いほう)。

  • すべてのインスタンスは、停止オプションの指定に従って停止します。

–stopoption TRANSACTIONAL LOCALパラメータを指定すると、次のようになります。

  • 残っているサービスは、指定された排出タイムアウト間隔と停止オプションに従って停止します。

  • 排出タイムアウト間隔の経過まで待機するか、ターゲットのサービスのセッションがすべて削除されるまで待機します(どちらか早いほう)。

  • インスタンスは、TRANSACTIONAL LOCAL停止オプションを使用して停止します。

サービスの開始

srvctl start serviceコマンドを使用して、ノード上のすべてのサービス、データベースによって提供されるすべてのサービス、またはプラガブル・データベースによって提供されるすべてのサービスを起動できます。

サービスを開始するには、srvctl start serviceコマンドに、開始するサービスのリスト(すべてのサービスのサブセット)を指定することもできます。さらに、特定のノードで開始できるすべてのサービスに対して、データベース・オプションとともにノード制限を指定することもできます。srvctl start serviceコマンドは、-pqパラメータを指定することで、パラレル問合せサービスのみを開始するように制限できます。
次の各例では、サービスの開始方法を説明します。

単一のプラガブル・データベースが提供するサービスをすべて開始するには:

$ srvctl start service –db myRACCDB01 –pdb myPDB01 –startoption OPEN

特定のデータベースと、そのプラガブル・データベースのサービスをすべて開始するには:

$ srvctl start service –db myRACDB

関連付けられたプラガブル・データベースの有無にかかわらず、特定のデータベースのサービスのリストを開始するには:

$ srvctl start service –db myRACDB –service "myFirstService,mySecondService,myThirdService"

特定のノードで実行可能なデータベースのサービスをすべて開始するには:

$ srvctl start service –d myRACDB –node racnode01
プラガブル・データベース・レベルの操作

SRVCTLを使用すると、プラガブル・データベースのサービスを管理できます。

すべてのインスタンスまたは単一のインスタンスに対して、プラガブル・データベースのサービスをすべて開始するには:
$ srvctl start service -db db_name -pdb pdb_name [-instance instance_name]

すべてのインスタンスまたは単一のインスタンスに対して、プラガブル・データベースのサービスをすべて停止するには:

$ srvctl stop service -db db_name -pdb pdb_name [-node node_name | -instance 
   inst_name] [-stopoption stop_option] [-drain_timeout timeout]
   [-force [-noreplay]]

ノート:

-pdb pdb_nameパラメータはオプションです。プラガブル・データベース名を省略すると、コンテナ・データベース全体(このコンテナ内のすべてのプラガブル・データベース)が操作の対象になります。
サービスの再配置

srvctl relocate serviceコマンドを使用すると、ターゲット宛先にサービスを再配置できます。インスタンス、ノードまたはデータベースが再配置の宛先になります。

次のコマンド例では、すべてのサービスが、名前付きデータベース、プラガブル・データベース、インスタンス、またはノードから再配置されます。サービスは、サービス構成で定義されているとおりに、そのサービスをターゲットがサポートできる場合にのみ再配置されます。再配置できないサービスは、元の場所に残されます。再配置されていないサービスに対する配置エラーが記録されます。それ以外は、すでに新しいターゲットで実行されています。再配置に失敗したサービスは、そのサービスの元の場所で実行を続け、セッションはアクティブのままになります。

$ srvctl relocate service –db myRACCDB –oldinst RACCDB_01 –newinst RACCDB_03
  -drain_timeout 30 -stopoption immediate

または

$ srvctl relocate service –db myRACCDB –pdb myPDB01 –currentnode racnode01
  –targetnode racnode02 -drain_timeout 30 -stopoption immediate

再配置操作は、新しい場所でサービスを開始してから、既存の場所でサービスを停止します。

ターゲット宛先を指定していない場合、Oracle Clusterwareは、指定されたデータベース、プラガブル・データベース、インスタンス、またはノードから、すべてのサービスまたは特定のサービスを再配置します。次に、例を示します。

$ srvctl relocate service –db myRACCDB –service "myService01,myService02"
  -drain_timeout 30 -stopoption immediate

または

$ srvctl relocate service –db myRACCDB –pdb myPDB01 -drain_timeout 30
  -stopoption transactional

有効なターゲットが存在しない場合、サービスは元の場所に残され、セッションはアクティブのままになります。サービスを調べて、必要な場合はサービスを停止してください。

サービスを再配置すると、サービスは新しい場所で開始されてから、元の場所で停止されます。Oracle Clusterwareは、新しいインスタンスまたはプラガブル・データベースを依存性として開始できます。-drain_timeoutパラメータと-stopoptionパラメータが指定されていると、サービスの属性がオーバーライドされます。

サービスの停止

srvctl stop serviceコマンドを使用して、ノード上のすべてのサービス、データベースによって提供されるすべてのサービス、またはプラガブル・データベースによって提供されるすべてのサービスを停止できます。

サービスのサブセットを停止する際は、srvctl stop serviceコマンドに停止するサービスのリスト(すべてのサービスのサブセット)を指定することもできます。また、srvctl stop serviceコマンドは、-pqパラメータを指定することで、パラレル問合せサービスのみを停止するように制限できます。

単一のプラガブル・データベースが提供するサービスをすべて停止するには:

$ srvctl stop service –db myRACCDB01 –pdb myPDB01 –drain_timeout 15 –stopoption TRANSACTIONAL

特定のデータベースと、そのプラガブル・データベースのサービスをすべて停止するには:

$ srvctl stop service –db myRACDB –drain_timeout 15 –stopoption IMMEDIATE

データベースが提供する一部のサービスのみを停止するには:

$ srvctl stop service –db myRACDB –service "myFirstService,mySecondService,
  myThirdService" –drain_timeout 60 –stopoption IMMEDIATE

ノート:

–wait YES SRVCTLコマンドライン・パラメータを使用すると、–stopoptionパラメータは排出タイムアウト間隔を経過するまで、この間隔の完了前にすべてのセッションが終了していても、実施されません。

計画メンテナンスの前のサーバーの排出

計画メンテナンスの前に、アプリケーションの動作が中断されないように、データベース・インスタンスでデータベースのセッションを排出するかフェイルオーバーします。

計画メンテナンスの準備を行う場合は、サーバー・インフラストラクチャを使用しているサービスを停止または再配置する必要があります。サービスの再配置は計画済停止の前に一定期間にわたって行われ、各サービスに関連する作業の性質に基づいています。

計画メンテナンスのローリングの手順では、メンテナンスの前にサービスを別のデータベース・インスタンスに移動し、クライアント側ドライバ、接続プール、データベース・インスタンス自体および他のサブスクライバにメンテナンスが保留中であることと、排出する必要のあるもの(このサービスを使用する接続またはセッション)を通知します。排出が通知されると、高速アプリケーション通知(FAN)イベントが送信され、クライアント・プールは他の場所で説明されているように動作し、さらにデータベースでは接続を解放する安全な場所を検索し、必要に応じて接続を移行します。

サービスを移動または停止すると、FAN通知がトリガーされ、サブスクライブしているOracleドライバおよびOracle接続プールで受信されます。FAN通知は、サーバーでのセッション排出もトリガーします。そのサービスに対する新規の作業が、ただちにサービスの機能している別のインスタンスに送信されます。既存のセッションは、その作業の完了後に解放用にマークされます。作業が完了して接続が接続プールに戻されると、Oracleドライバまたは接続プールのいずれかがこれらのセッションを終了します。

データベースでのセッションの排出

OLTPアプリケーション、アプリケーション・サーバーおよびカスタム・アプリケーションがデータベース・セッションを流用および返却する専用の接続プールを持っている場合、データベース・セッションが流用されなければ、そのセッションの排出は安全です。Oracleサーバー・インフラストラクチャがセッションを閉じるのに最適なのは、アプリケーション・サーバーがその接続の妥当性をテストした時点です。流用および解放時に接続プール・マネージャが接続の妥当性をテストして、接続が有効はでないことが検出した場合、エラーはアプリケーションに返されません。

安全な場所とは、アプリケーションが中断されない場所です。接続プールの場合、これは流用(チェックイン)されていない接続を意味し、アプリケーションの場合、接続を流用または返却する時点において同様のことが当てはまります。この時点では、すべての作業が完了しているか、起動していないかのいずれかです。データベースでは、すべての状態がアプリケーションに対して透過的にリストアできる場合、接続をフェイルオーバーすることもできます。

Oracle Database 18c以降では、データベースはルールとヒューリスティックの拡張可能なセットを使用して、データベース・セッションを取り除くタイミングを検出します。排出が開始すると、データベース・セッションはルールが満たされるまでデータベースで継続します。ルールには次の内容が含まれています。
  • 標準アプリケーション・サーバーが妥当性をテストします
  • カスタムSQLが妥当性をテストします
  • リクエスト境界は有効になっており、アクティブなリクエストはありません
  • リクエスト境界は有効になっており、現在のリクエストは終了しています
  • セッションにはリカバリ可能なセッション状態が1つ以上あり、フェイルオーバー時にセッションを再作成できます

たとえば、接続テストの場合、標準的な手順として、接続プールからの流用時、プールへの返却時およびバッチ・コミット時に、アプリケーション・サーバー、プールされたアプリケーション、ジョブ・スケジューラなどが接続をテストします。排出時に、データベースは接続テストを中断して接続を閉じ、テストの失敗ステータスを返します。接続テストを発行しているアプリケーション・レイヤーは、失敗の戻りステータスを処理する準備ができています。通常、さらにリクエストを発行して、別の接続を取得します。アプリケーションは中断されません。

すべてのセッションを排出できるわけではありません。接続がプールに戻っていないときや、FANが使用されていないときには排出できません。透過的アプリケーション・コンティニュイティまたはアプリケーション・コンティニュイティが有効化されている場合、サーバーは、アプリケーション・コンティニュイティがセッションをすばやくリカバリできるリクエスト境界を検出します。サーバーはセッションを中断する可能性がありますが、アプリケーション・コンティニュイティはこれを中断せずにリカバリします(Oracle RACクラスタの別のサーバーに対してなど)。

排出しないデータベース・セッションの場合、データベースはセッションの置き換えが可能なブレーク・ポイントを見つける必要があります。ブレーク・ポイントでは、状態が既知およびリカバリ可能である場合に、接続は透過的にフェイルオーバーできます。ブレーク・ポイントは、トランザクション境界、コールがリクエスト内で処理される前のリクエストの先頭(beginRequest)、およびリクエストが開始または終了していることを通知する監査コールなど、パターンである場合があります。ブレーク・ポイントは、状態がリストア可能であると認識されている場合にのみ適用されます。Oracle Database 21c以降、データベース・ソフトウェアによってセッションのフェイルオーバー先が決定され、セッションをフェイルオーバーするためにアプリケーション・コンティニュイティが起動されます。

接続をフェイルオーバーすると、アプリケーションによっては、アプリケーション・コンティニュイティ、透過的アプリケーション・コンティニュイティまたは透過的アプリケーション・フェイルオーバー(TAF)を有効にする必要があります。

サーバーで排出するための接続テストの追加、無効化、有効化および削除

サービス、プラガブル・データベースにSQL接続テストを追加できます。PDBに新しい接続テストを追加するには、ALTER SESSION SET CONTAINERを使用してPDBに切り替えます。

デフォルトでは、すべてのデータベース・サービスおよびプラガブル・データベース・サービスに4つのSQL接続テストが追加されています。したがって、アプリケーションが接続で次のSQL接続テストを使用している場合、これらを追加する必要はありません。
SELECT 1 FROM DUAL;
SELECT COUNT(*) FROM DUAL;
SELECT 1;
BEGIN NULL;END

ノート:

  • 接続テストの使用時には、接続テストの結果はそのセッションのみに当てはまります。接続テストを使用して、インスタンスに関する全般的な決定を下すことや、テスト適用対象のセッション以外を停止することを決断しないでください。接続テストの失敗時にプールをフラッシュおよび破棄するための接続プール・プロパティを無効にします。これは、Oracle WebLogic Serverのデータ・ソースにとって重要です。
  • 外部モニターの場合、そのモニター内で使用されるSQLの前に、モニター内で使用されるSQLのヒント/*+ MONITOR */を付けて、モニターで排出されないようにすることをお薦めします。
  • サービスにサーバー側SQL接続テストを追加するには、次のようなSQL文を使用します。
    SQL> execute dbms_app_cont_admin.add_sql_connection_test('select dummy from dual','sw_orcl');
    プラガブル・データベースにサーバー側SQL接続テストを追加するには、次のようなSQL文を使用します。
    SQL> execute dbms_app_cont_admin.add_sql_connection_test('begin null;end;');

    SQL接続テストを追加すると、デフォルトでこれが有効になります。

  • SQL接続テストが不要な場合またはこれを使用していない場合、プラガブル・データベースにログオンして、次のようなSQL文を使用することにより、SQL接続テストを無効にできます。
    SQL> execute dbms_app_cont_admin.disable_connection_test(dbms_app_cont_admin.sql_test,'select dummy from dual');

    デフォルトではpingテストおよび終了リクエスト・テストは無効になっていますが、これらを有効にした後に無効にする場合、次のSQL文のいずれかを使用できます。

    pingテストを無効にする場合、次のようなSQL文を使用します。
    SQL> execute dbms_app_cont_admin.disable_connection_test(dbms_app_cont_admin.ping_test);
    終了リクエスト・テストを無効にする場合、次のようなSQL文を使用します。
    SQL> execute dbms_app_cont_admin.disable_connection_test(dbms_app_cont_admin.endrequest_test);
  • プラガブル・データベースにログオンして次のようなSQL文を使用することにより、SQL接続テストを無効にした後これを有効にできます。
    SQL> execute dbms_app_cont_admin.enable_connection_test(dbms_app_cont_admin.sql_test,'select dummy from dual');

    無効になっている場合、次のSQL文のいずれかを使用してpingテストおよび終了リクエスト・テストを有効にすることもできます。

    isValid、isUsable、OCIpingまたはconnection.statusなどのpingを使用するすべてのテストを実行する場合、次のようなSQL文を使用します。
    SQL> execute dbms_app_cont_admin.enable_connection_test(dbms_app_cont_admin.ping_test);
    リクエストの終了時に排出を有効にする場合、次のようなSQL文を使用します。
    SQL> execute dbms_app_cont_admin.enable_connection_test(dbms_app_cont_admin.endrequest_test);
    リクエストの終了時に排出を無効にする場合、次のようなSQL文を使用します。
    SQL> execute dbms_app_cont_admin.disable_connection_test(dbms_app_cont_admin.endrequest_test);
  • SQL接続テストが不要な場合、プラガブル・データベースにログオンして、次のようなSQL文を実行すると、SQL接続テストを削除できます。
    SQL> execute dbms_app_cont_admin.delete_sql_connection_test('select dummy from dual','sw_orcl');
SQL> execute dbms_app_cont_admin.delete_sql_connection_test('begin null;end;');

  • 特定のPDBに属するサービスのルールを変更する場合は、そのPDBに切り替えてルールを変更します。たとえば、eBusiness Suiteの場合は次のようになります。

    SQL> alter session set container=’VISPRD’;
SQL> execute dbms_app_cont_admin.add_sql_connection_test('Begin null; End ;');
SQL> executedbms_app_cont_admin.add_sql_connection_test('Begin null; End ;', ‘VISPRD’);

すべてのアプリケーション・サーバーには各接続プールで接続の妥当性をテストする機能があり、これは構成プロパティまたは管理コンソールで設定されています。テストの目的は、使用できない接続をアプリケーションに渡さないようにすることと、使用できない接続を検出した場合に、プールへの解放時にこれを削除することです。

様々なアプリケーション・サーバーでテストの名前が類似しています。提供されているテストでは様々なアプローチを使用しており、最も一般的なものはSQL文です。Javaアプリケーション・サーバーで標準のJavaコールconnection.isValidを使用することをお薦めします。Oracle Database 18c以降、これらのテストを使用してデータベースを排出します。また、Oracle Database 18c以降、データベースは安全な排出ポイントのためにセッションを調査することにより、FANを使用しないでセッションを排出します。

次の表は、より一般的ないくつかのアプリケーション・サーバーに利用可能な標準接続テストを示しています。

表6-4 一般的なアプリケーション・サーバーの標準接続テスト

アプリケーション・サーバー データベースへの接続テスト

Oracle WebLogicサーバー
用意されているテストは次のとおりです。 
  • dbms_app_cont_admin.enable_connection_test(dbms_app_cont_admin.sql_test,'select 1 from dual');

  • TestConnectionsonReserve:

    isUsable、isValid、またはPingDatabase

  • サーバーの排出場合、TestConnectionsOnCreate (SQL構文) : 

    Select 1 from dual;

Oracle WebLogic Server Active Gridlink
次のテストが埋め込まれています。
isUsable

IBM WebSphere

 
dbms_app_cont_admin.enable_connection_test(dbms_app_cont_admin.sql_test,'select 1 from dual');

サーバーの排出のために接続を事前テストします(SQL構文)。

Select 1 from dual;

RedHat JBoss
check-valid-connection-sql (SQL構文):
dbms_app_cont_admin.enable_connection_test(dbms_app_cont_admin.sql_test,'select 1 from
      dual');

Apache Tomcat
2つのテストtestOnBorrowおよびtestOnReturnを利用できます。どちらも、データベースへの接続テストにSQL構文を使用します。
dbms_app_cont_admin.enable_connection_test(dbms_app_cont_admin.sql_test,'select 1 from dual');
アプリケーション・サーバーでは次を使用します。
Select 1 from dual;

Oracle Notification Services (ONS)の自動構成をサポートするために次に示すフォーマットの使用をお薦めします。これにより、FANイベントを受信できます(ONS経由)。

例6-6 FANの自動構成

alias =(DESCRIPTION =
 (CONNECT_TIMEOUT=90)(RETRY_COUNT=20)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3) 
   (ADDRESS_LIST =
   (LOAD_BALANCE=on)
   ( ADDRESS = (PROTOCOL = TCP)(HOST=primary-scan)(PORT=1521)))
   (ADDRESS_LIST =
   (LOAD_BALANCE=on)
   ( ADDRESS = (PROTOCOL = TCP)(HOST=secondary-scan)(PORT=1521)))
  (CONNECT_DATA=(SERVICE_NAME = gold-cloud)))

関連トピック

親トピック: 計画メンテナンスの管理

アプリケーション・コンティニュイティでの計画フェイルオーバー

計画フェイルオーバーは、アプリケーション・コンティニュイティを使用してセッションがリプレイ可能であり、セッションの排出が予測されないことがデータベースで認識された時点でOracle Databaseによって起動されるフェイルオーバーです。

計画フェイルオーバーは、指定された排出のタイムアウト期間内に完了することが予想されない、バッチ操作および長時間実行される操作の計画メンテナンス中にセッションを再配置するために使用される自動ソリューションです。セッションの移行は、ALTER SYSTEM DISCONNECT SESSION文でも使用されます。

計画的フェイルオーバーは、排出の開始時にアクティブ化されます。ルール・エンジンが、計画的フェイルオーバーを起動するタイミングを決定します。

  • データベースでは、リクエストの率とサイズに関する統計が保持され、アプリケーション・コンティニュイティなどのフェイルオーバー機能が有効な場合、リプレイのコールに対する保護レベルの統計およびリカバリが必要なセッション状態も保持されます。

  • データベースでは、セッションで透過的アプリケーション・コンティニュイティまたはアプリケーション・コンティニュイティがいつ有効になるか、セッション状態が追跡およびリカバリ可能かどうか、およびフェイルオーバーが有効になるタイミング(ドレイン・タイムアウトの期限が切れる前にフェイルオーバーが無効になる可能性が高い場合)が認識されます。

  • データベースでは、セッションで排出が予想されないこと、セッションがリカバリされる可能性があることおよびリプレイが必要な場合に実行する必要があるリプレイの量を認識します。

  • 高速アプリケーション通知が有効になっているかどうかがデータベースで認識されます。

  • データベースでは、透過的アプリケーション・コンティニュイティのリクエスト境界が検出されたことが認識されます。

フェイルオーバーされたセッションの詳細を確認できるように、データベースによってフェイルオーバーされたセッションはアラート・ログにマークされます。

計画フェイルオーバーを使用するには、次のステップを実行します。

  1. アプリケーション・コンティニュイティまたは透過的アプリケーション・コンティニュイティを有効にします。

  2. サービスのサービス属性-drain_timeoutおよび-stopoptionを設定します。

  3. メンテナンス中に、サービスを再配置または停止して排出します。Data Guardの場合、Data Guard Brokerでスイッチオーバー待機を使用できます。

親トピック: 計画メンテナンスの管理

クライアント・フェイルオーバーを向上させるためのトランザクション・ガード

トランザクション・ガードは、アプリケーションがリカバリ可能なエラーに続くCOMMIT_OUTCOMEを特定するために使用できる開発者機能です。

親トピック: アプリケーション・コンティニュイティの確保

トランザクション・ガードについて

トランザクション・ガードには、自動的かつ透過的に基準化された方法で冪等性を達成するためにアプリケーションで使用される、完全統合ツールが用意されています。

トランザクション・ガードでは、論理トランザクションID (LTXID)を使用して、重複したトランザクションの送信を回避します。この機能は、トランザクションの冪等性と呼ばれます。LTXIDはコミット時に継続され、ロールバックの後に再使用されます。通常の実行中、LTXIDは、各データベース・トランザクションについてクライアントおよびサーバーの両方で自動的にセッションで保持されます。コミット時に、LTXIDはトランザクションのコミットの一環として継続され、次に使用するLTXIDがクライアントに返されます。

ノート:

アプリケーション・コンティニュイティでは、通常のアプリケーションの場合のみ停止が保護されます。AC対応サービスによる管理タスクはサポートされていないため、それらを回避する必要があります。

最後の送信がコミットされたことまたはこれからコミットされること、あるいは最後の送信の実行が完了していないことを認識できない場合、アプリケーションには問題があります。これらの送信状態を認識できないアプリケーションでは、再送信するユーザーや独自のリプレイを使用するアプリケーションが重複するリクエストを発行したり、データベースにすでにコミットされている変更を繰り返したり、その他の形式の論理破損が発生する原因となる可能性があります。トランザクション・ガードを使用すると、この問題を解決できます。

アプリケーション・コンティニュイティは、自動的にトランザクション・ガードを有効化して使用しますが、トランザクション・ガードは個別に有効化することもできます。アプリケーションがアプリケーション・レベルのリプレイを実装している場合は、冪等性を実現するためにアプリケーションをトランザクション・ガードと統合する必要があります。

XAトランザクション用のトランザクション・ガード

トランザクション・ガードは、XAベースのトランザクションもサポートします。これは、XAを使用してワンフレーズのコミットを使用する場合のOracle WebLogic Server、Oracle Tuxedo、およびMicroSoft Transaction Server (Oracle ODP.NETを通じてOracle Databaseに公開)などのトランザクション・マネージャのオプションです。

関連トピック

親トピック: クライアント・フェイルオーバーを向上させるためのトランザクション・ガード

データベース・ネイティブ・トランザクション・ガード

データベース・ネイティブ・トランザクション・ガードは、データベース・トランザクションID (DB XID)を使用して1回かぎり処理されるように、既存のトランザクション・ガード・プロトコルを強化します。

サーバー側のトランザクションは、データベース・トランザクション識別子またはDB XIDによって識別されます。各DB XIDのコミットの一環としてLTXID_TRANS表のLTXIDを保持すると、通常のトランザクション操作でオーバーヘッドが発生します。トランザクション・ガードに必要な追加作業は、ユーザー・トランザクションによって行われた作業と比較して重要ではないため、パフォーマンスおよびREDO生成に関するこのオーバーヘッドは、トランザクションが小さい場合にCPUオーバーヘッドで認識できます。

ノート:

アプリケーション・コンティニュイティを使用する場合、データベース・ネイティブ・トランザクション・ガードがデフォルト・オプションです。

DB XIDは、ローカルUNDOがあるプラガブル・データベース(PDB)内で一意であり、データベース内のトランザクションを一意に識別します。DB XIDを使用すると、個別の表で永続性が必要ないため、REDO生成やパフォーマンスのオーバーヘッドは発生しません。FORCE_OUTCOMEプロシージャは、個別の表のLTXIDの永続性に依存するのではなく、DB XIDを利用します。

データベース・ネイティブ・トランザクション・ガードは、LTXID_TRANS表への追加の書込みを回避することで、トランザクション・ガード機能を低オーバーヘッドで提供します。この機能は、クライアント側のAPIには影響せず、管理上の変更は必要ありません。

デフォルトでは、COMMIT_OUTCOMEがTRUEに設定されている場合、COMMIT_OUTCOME_FAST_PATHサービス・パラメータはTRUEに設定されます。データベース・ネイティブ・トランザクション・ガードを無効にするには、COMMIT_OUTCOME_FAST_PATHサービス・パラメータをFALSEに設定します。

親トピック: クライアント・フェイルオーバーを向上させるためのトランザクション・ガード

主要データベース・バージョンのアップグレード中のトランザクション・ガードのサポート

Oracle Database 23ai以降、トランザクション・ガードはDBMS_ROLLING操作中に動作し、DBMS_ROLLINGによって一時ロジカル・スタンバイに発行されるスイッチオーバー中の継続的なアプリケーション機能を確保します。

トランザクション・ガードは、エラーまたは停止が発生したときに現在の処理中トランザクションのコミット結果を返します。アプリケーションは、トランザクション・ガードAPIをエラー処理手順に組み込んで、停止後に処理中の作業が失われたり重複して発行されずに作業が続行されるようにします。トランザクション・ガードにより、停止後にトランザクションが再処理(リプレイ)されたときにコミットが複数回行われないように、べき等性サポートが提供されます。

トランザクション・ガードは、DBMS_ROLLINGスイッチオーバー操作中に、一時ロジカル・スタンバイへの継続的なアプリケーション操作を保証します。トランザクション・ガードは、スイッチオーバー停止中の処理中セッションのトランザクションの最終コミット結果を使用して、リプレイ時のトランザクションの重複発行からアプリケーションを保護します。

トランザクション・ガードは、論理トランザクション識別子(LTXID)をデータベース・トランザクションにマップするLTXID_TRANSというトランザクション履歴表を維持します。停止後にフェイルオーバーが成功するには、プライマリ・データベースからLTXID_TRANSへの変更を最初にレプリケートし、一時ロジカル・スタンバイに適用する必要があります。DBMS_ROLLINGプロシージャでサプリメンタル・ロギングを有効にすると、トランザクション・ガードはSQLを使用して、CDBおよびPDBレベルでのLTXID_TRANSの追加取得を許可します。取得プロセスはLTXID_TRANS表をレプリケートし、適用プロセスは、コミットされたユーザー・トランザクションとともにロジカル・スタンバイのLTXID_TRANS表を読み取って再作成します。

DBMS_ROLLINGプロシージャのサポートの一環として、トランザクション・ガードは次の機能を実行します。

  • プライマリ・データベースがDBMS_ROLLINGモードの場合(データベースのアップグレードが開始された場合)に追跡します

  • サプリメンタル・ロギングが使用中であることを確認します

  • サプリメンタル・ロギング・モード中に実行時に主キー(PK)のREDOベクトルを記録します

  • LTXIDレプリケーションを実行する前に、現在のすべての更新が終了してロジカル・スタンバイにレプリケートするまで待機します

  • LTXID_TRANS表をレプリケートし、各PDBの一時ロジカル・スタンバイにREDOを適用します

  • 正常なLTXIDレプリケーションについてフェイルオーバーが認識するメカニズムを提供します

  • 停止後にリプレイの処理中セッションに対して最終コミット結果を強制します

  • 追加取得および適用プロセス中に新しいユーザーを処理し、適用によって、ターゲット・データベースで一致しないログインUID(ユーザーID)が作成されないことを確認します

親トピック: クライアント・フェイルオーバーを向上させるためのトランザクション・ガード

トランザクション・ガードの構成チェックリスト

トランザクション・ガードのサービスを構成する前に、この構成チェックリストを使用することをお薦めします。

トランザクション・ガードのサービスを構成する前に、このリストの各チェックを完了します。

  • 次のように、GET_LTXID_OUTCOMEを呼び出すアプリケーション・ユーザーに権限を付与します。 

    GRANT EXECUTE ON DBMS_APP_CONT to user_name;

    ノート:

    アプリケーション・コンティニュイティを使用する場合は、この文を実行しないでください。

  • 最適なパフォーマンスを実現するためにトランザクション履歴表を特定および定義します。

    トランザクション履歴表(LTXID_HIST)は、Oracle Databaseの作成時またはアップグレード時にデフォルトでSYSAUX表領域に作成されます。最後のパーティションの記憶域を使用して、インスタンスの追加時に新しいパーティションが追加されます。トランザクション履歴表の場所がパフォーマンス上最適でない場合は、別の表領域に移動して、そこでパーティションを作成できます。たとえば、次の文により、FastPaceという名前の表領域にトランザクション履歴表を移動します。 

    ALTER TABLE LTXID_TRANS move partition LTXID_TRANS_1 tablespace FastPace
   storage ( initial 10G next 10G minextents 1 maxextents 121 );

  • COMMIT_OUTCOMEおよびRETENTION_TIMEOUTサービス・パラメータの値を設定します。

  • Oracle Real Application Clusters (Oracle RAC)、Oracle Data GuardまたはOracle Active Data Guardを使用している場合は、停止の迅速な通知を取得するために、高速アプリケーション通知(FAN)を使用することをお薦めします。

親トピック: クライアント・フェイルオーバーを向上させるためのトランザクション・ガード

トランザクション・ガードのサービスの構成

トランザクション・ガードを使用するようにサービスを構成するには、必要なサービス・パラメータを確認して設定します。

次のパラメータを確認して設定します。

  • COMMIT_OUTCOME: COMMIT_OUTCOMEサービス・パラメータをTRUEに設定します。

    COMMIT_OUTCOMEサービス・パラメータにより、COMMITが実行されて停止が発生した後に、トランザクションのコミット結果にアクセスできるかどうかが決まります。Oracle DatabaseではCOMMITが常に永続的になりますが、トランザクション・ガードではCOMMITの結果が永続的になります。アプリケーションでは、コミットのこの永続性を使用して、停止前に実行された最後のトランザクションのステータスを強制適用します。

  • RETENTION_TIMEOUT: RETENTION_TIMEOUTサービス・パラメータをCOMMIT_OUTCOMEとともに使用します。RETENTION_TIMEOUTサービス・パラメータにより、COMMIT結果が保持される時間(秒)が決まります。ほとんどのインストールではデフォルト値を使用することをお薦めします。

次の例では、SRVCTLコマンドにより、salesという名前のサービスがトランザクション・ガード用に構成されます。 

$ srvctl add service -db crm -service sales -preferred crm_1,crm_2
  -available crm_3,crm_4 -commit_outcome TRUE -retention 86400
  -notification TRUE

srvctl modify serviceコマンドを使用して、既存のサービスをトランザクション・ガード用に構成するように変更することもできます。

ノート:

デフォルト・データベース・サービス(db_nameまたはdb_unique_nameの値に名前が設定されているサービス)は使用しないでください。デフォルト・サービスは、管理目的に使用されるものであり、ユーザー作成のサービスと同じプロパティを備えていません。

関連トピック

親トピック: クライアント・フェイルオーバーを向上させるためのトランザクション・ガード

DBMS_ROLLINGを使用したメジャー・データベース・バージョン・アップグレード中のアプリケーション・コンティニュイティ

Oracle Database 23ai以降、DBMS_ROLLINGを使用してアプリケーション・コンティニュイティを使用する場合、主要なデータベース・バージョンのアップグレードおよびデータベース再構築中に、アプリケーション・コンティニュイティおよびデータベース・セッションの排出がサポートされます。

これは、非ローリング・パッチを適用するための戦略的アプローチです。この機能では、ある主要なリリースから別の主要なリリースへのアップグレードもサポートされます。Oracle Database 19cからOracle Database 23aiへの主要なリリース・アップグレードの場合、Oracle Autonomous Database Dedicatedのみでサポートされています。

アプリケーション・コンティニュイティを使用する場合、アプリケーションはDBMS_ROLLING中に継続的に使用できます。つまり、アプリケーションはデータベースのアップグレード・プロセスを続行できます。

DBMS_ROLLINGでのアプリケーション・コンティニュイティのサポートにより、データベースの様々な主要バージョンにわたるデータベース・セッションの透過的なフェイルオーバーが可能になり、データベースのメジャー・アップグレードおよび再構築中に中断が最小限に抑えられます。この機能により、データベース・セッションがデータベースの異なる論理バージョンにリアルタイムで再配置されます。この場合、データの観点では同じデータベースですが、異なる主要バージョンまたは主要データベースの再構築になります。

この機能により、新しい論理データベースへの移行期間中(スイッチオーバーと呼ばれる)にアプリケーションのフェイルオーバーが提供されます。新しいデータベースへの移行は計画メンテナンス操作ですが、アプリケーションでは、新しい論理データベースへのスイッチオーバー・ステップの発生時期は認識されません。インフラストラクチャがスイッチオーバーを監視し、数秒から数分でスイッチオーバーを実行できるほどデータベース間のラグが十分に小さくなると、スイッチオーバーを自動的に開始します。

データベース・セッションは新しいプライマリ・データベースにフェイルオーバーするため、アプリケーションの動作は維持されます。フェイルオーバーにより、中断が最小限に抑えられるため、主要なアップグレードおよび主要な再構築時のビジネス継続性が実現されます。この機能では、DBMS_ROLLINGを使用する際に、Oracleアプリケーション・コンティニュイティのサポートをロジカル・スタンバイと統合します。

親トピック: アプリケーション・コンティニュイティの確保

データベース・セッション状態のリセット

RESET_STATEサービス属性をLEVEL1またはLEVEL2に設定した場合、リクエストでのアプリケーションによって設定されたセッション状態は、データベースに対するリクエストの終了時にクリアされます。

ノート:

Oracle Database 23ai以降、RESET_STATEはアプリケーション・コンティニュイティ機能に依存しません。

RESET_STATEは非常に重要なデータベース機能で、開発者は、リクエスト境界を持つ接続プールにセッションが返されたときに、セッション状態がクリーンであることに依存できます。これは、リクエスト境界が追加されたOracle接続プールまたはカスタム接続プールです。RESET_STATEをLEVEL1に設定して、リクエスト内のリストア不可能なセッション状態をクリアします。

リクエストでセッション状態を設定すると、セッションは使用されたままになり、つまりセッション状態がクリアされていない場合、そのセッションの次の使用時にその状態が確認されます。たとえば、アプリケーションが接続を流用して接続プールに返却すると、そのセッションの次の使用時に、その前に使用していたセッション状態を確認できます。RESET_STATEを指定しない場合、または RESET_STATEがNONEに設定されている場合、アプリケーション開発者は、再利用のために接続をプールに戻す前に、カーソルを取り消し、設定されているセッション状態をクリアする必要があります。

また、RESET_STATEサービス・プロパティを使用すると、次のリクエストの開始時にセッション状態がクリーンになるため、透過的アプリケーション・コンティニュイティを使用するときの保護が強化されます。

親トピック: アプリケーション・コンティニュイティの確保