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

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

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

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

アプリケーション・コンティニュイティを使用しない場合、次のような理由により、アプリケーションが停止を安全な方法でマスクすることはほとんど不可能です。

  • 入力したデータ、戻されたデータ、および変数がキャッシュされたまま、クライアントの状態が現時点のままになります。

  • COMMITが発行されていた場合、クライアントまたはアプリケーションで受信されていないCOMMIT失敗のメッセージは取得できなくなります。

  • ある時点でインダウト・トランザクションのステータスをチェックしても、その後でCOMMITしないという保証はありません。

  • アプリケーションが処理する必要がある非トランザクションのデータベース・セッションの状態が失われます。

  • リクエストが続行可能である場合、データベースおよびデータベース・セッションが正しい状態である必要があります。

その一方で、アプリケーション・コンティニュイティを使用すると、Oracle Database、Oracleドライバ、およびOracle接続プールのすべてが連携して、安全で信頼性の高い方法で多くの停止をマスクします。

アプリケーション・コンティニュイティは、マスク可能な停止のマスクを試行することにより、開発者の生産性を向上させます。ただし、次の場合は、従来どおりアプリケーションでエラー処理が行われる必要があります。

  • 無効な入力データなどのリカバリ不能なエラー。(アプリケーション・コンティニュイティはリカバリ可能なエラーにのみ適用されます。)

  • アプリケーションでの具象クラスの使用などの制限がリプレイ時に発生した場合や、リプレイによってクライアントの表示可能な状態を、クライアントが現時点までに決定した可能性のある状態にリストアできない場合にリカバリ可能なエラー。

Oracle Database 12cリリース1 (12.1.0.1)で導入されたアプリケーション・コンティニュイティにより、Oracleデータベースを使用するシステムおよびアプリケーションのフォルト・トレランスが強化されます。

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

この章の内容は次のとおりです。

6.1 高速アプリケーション通知

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

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

ここでは次の項目を含みます。

関連項目

6.1.1 高速アプリケーション通知の概要

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

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

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

注意:

FANは、Oracle Database 10g リリース2 (10.2)以降からサポートされています。

たとえば、Oracle接続プールは、FANを使用して、障害についての非常に高速な通知を受信し、障害後の接続を均等に分散します。障害が発生したコンポーネントが修復されると、接続を再度均等に分散します。そのために、インスタンスのサービスが起動されると、接続プールはFANイベントを使用して、そのリソースに作業を即座にルーティングします。インスタンスまたはノードのサービスが失敗すると、接続プールはFANイベントを使用して、リカバリのためにアプリケーションを即座に中断します。FANは、TCP/IPタイムアウトでアプリケーションがハングしないようにするために不可欠です。

FANの重要性

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

  • ソケットをクローズしないでノードが失敗した場合のTCP/IPタイムアウトの待機、およびそのIPアドレスが停止している間の後続のすべての接続の待機。

  • サービスが停止した場合の接続の試行。

  • サービス再開時に接続しない。

  • サーバーが停止したときのクライアントでの最後の結果の処理。

  • 最適でないノードで作業を実行しようとする。

ソケットをクローズしないでノードが失敗した場合、I/O待機(読取りまたは書込み)でブロックされたすべてのセッションはtcp_keepaliveを待機します。この待機ステータスは、ソケットで接続されているアプリケーションの場合の典型的な状況です。最後の結果を処理するセッションの状況はさらに悪く、次のデータが要求されるまで割り込みを受信しません。FANイベントを使用すると、TCPタイムアウトを待機しているアプリケーション、障害の発生後にクライアントで最後の結果を処理するという時間の浪費、および低速なノード、停止したノードまたは使用不能なノードで作業を実行するという無駄な時間が排除されます。

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

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

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

計画メンテナンスでアプリケーションがOCIまたはPro*使用している場合(およびOCIセッション・プールやTuxedoを使用していない場合)、アプリケーションはOCI_ATTR_SERVER_STATUSをチェックする必要があります。このチェックは、独自の接続プールにセッションが返されたときに追加します。また、アイドル接続に対しては定期的に、このチェックを追加します。

計画メンテナンスによるFANのDOWNイベント後、この属性はOCI_SERVER_NOT_CONNECTEDに設定されます。アプリケーションは、この切断ステータスを読み取ると接続を閉じます。セッションは、アクティブな作業の排出のために、アプリケーションが閉じるまで開かれたままになります。これにより、エラーの発生しないフェールオーバーを実現します。

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

  • Oracle統合クライアントを使用すると、プログラムを変更することなくアプリケーションでFANを使用できます。FANイベント用の統合クライアントには、Oracle JDBC Universal Connection Pool、ODP.NET接続プール、OCIセッション・プール、Oracle WebLogic Server Active Gridlink for Oracle RAC、OCIおよび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をプログラムで使用できます。

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

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

前述のリストで説明したように、ドライバでFAN対応機能を利用するには、次の事項が必要になります。

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

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

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

    注意:

    SQLヒントは、SQL文字列内でコメント以外の最初のトークンとして配置して、現在のドライバ・ベースのSQL解析が変更されないようにする必要があります。次に例を示します。
    /*+ CLIENT_CONNECTION_VALIDATION */ SELECT 1 FROM DUAL;

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

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

次の表は、より一般的ないくつかのアプリケーション・サーバーに利用可能な標準テストを示しています。

表6-1 一般的なアプリケーション・サーバーの標準テスト

アプリケーション・サーバー データベースへの接続テスト

Oracle WebLogicサーバー
用意されているテストは次のとおりです。

  • TestConnectionsonReserve:

    isUsable、isValid、またはPingDatabase

  • TestConnectionsOnCreate (SQL構文): 

    /*+ CLIENT_CONNECTION_VALIDATION */ Select 1 from dual;

Oracle WebLogic Server Active Gridlink
次のテストが埋め込まれています。
isUsable

IBM WebSphere
PreTest接続(SQL構文):
/*+ CLIENT_CONNECTION_VALIDATION */ Select user from dual;

RedHat JBoss
check-valid-connection-sql (SQL構文):
Select 1 from dual;

Apache Tomcat
2つのテストtestOnBorrowおよびtestOnReturnを利用できます。どちらも、データベースへの接続テストにSQL構文を使用します。
/*+ CLIENT_CONNECTION_VALIDATION */ Select 1 from dual;

FANの自動構成がサポートされるように、次に示すフォーマットの使用をお薦めします。

例6-1 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)))

FANコールアウトは、サーバー側スクリプトであるか、またはFANイベントが生成されると必ず実行される実行可能ファイルです。様々なことを行うためのコールアウトを設計および構築できます。次に例を示します。

  • ステータス情報のログへの記録

  • リソースの起動に失敗した場合に、DBAへの通知またはサポート・チケットの発行を行います。

  • サービスと同じ場所に配置する必要がある外部依存アプリケーションの自動的な起動

  • ノードの障害などによって、ポリシー管理データベースに使用できるインスタンスの数が減少した場合、リソース・プランを変更するか、またはサービスを停止します。

  • 必要に応じて、サービスを管理者管理データベースの優先インスタンスに自動的にフェイルバックします。

FANイベントは、Oracle Notification ServiceとOracle Streamsアドバンスト・キューイングを使用して発行され、後者はOracle Databaseの前のリリースとの下位互換性のために続行されます。発行メカニズムは、Oracle RACのインストール時に自動的に構成されます。Java JDBC Thin接続を使用している場合、データベース接続からデータベース・サーバーのOracle Notification Service構成を取得することで、クライアントは自動的にOracle Notification Serviceに対応するように構成されます。クライアント側でOracle Notification Serviceを構成する必要はありません。

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

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

6.1.2 計画外停止の管理

サービスは、管理者管理のOracle RACデータベースの1つ以上のインスタンスに割り当てるか、またはポリシー管理データベースのサーバー・プールに割り当てることができます。

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

FANイベントはOracle Databaseアーキテクチャ内の様々なレベルで発生し、前のOCIクライアントとの下位互換性のためにOracle Notification ServiceおよびOracle Streamsアドバンスト・キューイングを使用して発行されます。FANコールアウトは、FANイベントに応答してデータベース・サーバーで実行されるように記述することもできます。

注意:

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

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

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

関連項目

6.1.3 計画メンテナンスの管理

1つ以上のインスタンスまたはノードを隔離する必要がある修復、アップグレードおよび変更のために、Oracle RACでは、アプリケーション・ユーザーに対するサービスの中断の影響を最小限に抑えて、サービスを再配置、無効化および有効化するインタフェースを使用できます。

サービスを再配置する場合は、サービスが一時的に別のインスタンスで実行されるようにする必要があります。サービスを強制的に無効にすると、そのサービスはすべてのデータベース・インスタンスで停止され、使用できなくなります。無効化されたサービスは、自動的に再起動することはありません。サービスが停止または再配置された場合、計画済理由コード(通常はreason=user)でFANが発行されます。操作を完了したら、サービスを通常の操作に戻すか、またはサービスを有効にしてから、再起動することができます。サービスが再起動されると、FANはUPステータス・コードで発行されます。

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

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

この項には次のトピックが含まれます:

関連項目

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

Oracleソフトウェアのアップグレード、パッチの適用、ハードウェアの交換など、メンテナンスのためにデータベース・インスタンスを停止することが必要になる場合があります。

この項の手順を使用すると、ユーザーへの影響が最小限になり、要求は中断されません。

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

Oracle Universal Connection Poolを使用すると、セッションは-drain_timeoutパラメータの値に応じて段階的に排出されるため、ターゲット・インスタンス上の別の作業に与える影響は最小限に抑えられます。これにより、サービスが復帰したときの大量のログインも防止できます。

アプリケーション・コンティニュイティでは、割り当てられた排出時間内に完了しないリクエストにサービスを継続することで追加の対策を提供します。

高速接続フェイルオーバーが構成されたFAN対応プール(OCIセッション・プール、Oracle Universal Connection Pool、Oracle WebLogic Server Active Gridlink for Oracle RAC、ODP.NETなど)を使用すると、FANの計画DOWNイベントの受信後にリクエスト境界でセッションを排出できます。

発行済の作業はリクエストによって完了できるため、リクエストはトランザクションよりもはるかに重要です。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

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

  1. SRVCTLを使用してインスタンスのサービスを再配置します。また、均一のサービスまたはすべて優先されるサービスを使用している場合は、インスタンス上のサービスをシャットダウンします。前述の各SRVCTLコマンドに、-forceフラグを使用します。-forceフラグは、srvctl relocate serviceまたはsrvctl stop serviceのどちらかを実行するときに、コマンドラインで-stopoptionパラメータを指定した場合に使用する必要があります。次に例を示します。
    $ srvctl relocate service –database mycdb01 –service myservice –drain_timeout 120
  –stopoption IMMEDIATE –oldinst mycdb01_01 -force

    前述のコマンドは、mycdb01_01というインスタンスのmyservice01というサービスを、そのサービスを実行するように構成されたインスタンスに再配置します。Oracle Clusterwareは、このインスタンスを選択して(コマンドラインでターゲットを指定していない場合)、アクティブなセッションを排出するために2分間待機し(この例の場合)、その後でmycdb01_01に残っているセッションが強制的に切断されます。接続プールにより、要求境界で接続が自動的に解放されます。

  2. FAN計画済DOWNイベントにより、アイドル・セッションが接続プールからただちにクリアされ、次のチェックインで解放されるアクティブ・セッションがマークされます。これらのFANアクションにより、ユーザーの作業を妨げずにセッションがインスタンスから排出されます。

    他のインスタンスの既存の接続は使用可能なままで、必要な場合はこれらのインスタンスに新しい接続をオープンできます。

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

    • サービスには、停止オプションのNONE、TRANSACTIONAL、およびIMMEDIATEを指定できます

    • データベースには、停止オプションのNORMAL、TRANSACTIONAL、TRANSACTIONAL LOCAL、IMMEDIATE、およびABORTを指定できます

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

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

    アプリケーション・コンティニュイティによってセッションのリプレイが試行されないようにするには、SRVCTLコマンドラインで-noreplayフラグを指定します。

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

多くの企業が多数のサービスを実行しています。多数のサービスが単一のデータベースまたはインスタンスで提供されることも、多数のデータベースが同じノード上で実行する少数のサービスを提供することもあります。

個別のサービスごとにSRVCTLコマンドを実行する必要はなくなり、影響を受けるすべてのサービスのノード名、データベース名、プラガブル・データベース名、またはインスタンス名を指定することのみが必要になります。
  • たとえば、特定のノードで実行しているすべてのサービスを停止する場合は、次に示すコマンドを使用できます。
    $ srvctl stop service –node racnode01 –drain_timeout 60 –stopoption IMMEDIATE

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

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

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

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

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

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

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

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

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

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

この項には次のトピックが含まれます:

6.1.3.2.1 サービスの開始

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 –pdb myPDB01 –service "myFirstService,mySecondService,myThirdService"

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

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

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

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

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

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

    注意:

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

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

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

    または

    $ srvctl relocate service –database myRACCDB –pdb myPDB01 –currentnode racnode01
  –targetnode racnode02 -drain_timeout 30 -force –noreplay

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

  • ターゲット宛先を指定していない場合、Oracle Clusterwareは、指定されたデータベース、プラガブル・データベース、インスタンス、またはノードから、すべてのサービスまたは特定のサービスを再配置します。次に、例を示します。
    $ srvctl relocate service –database myRACCDB –service "myService01,myService02"
  -drain_timeout 30 -force

    または

    $ srvctl relocate service –database myRACCDB –pdb myPDB01 -drain_timeout 30
  -force –noreplay

    有効なターゲットが存在しない場合、サービスは元の場所に残され、セッションはアクティブのままになります。サービスを調べて、必要な場合はサービスを停止してください。

サービスを再配置すると、サービスは新しい場所で開始されてから、元の場所で停止されます。Oracle Clusterwareは、新しいインスタンスまたはプラガブル・データベースを依存性として開始できます。-drain_timeoutパラメータと-stopoptionパラメータが指定されていると、サービスの属性がオーバーライドされます。
6.1.3.2.4 サービスの停止

srvctl stop serviceコマンドを使用すると、ノード上のすべてのサービス、データベースが提供するすべてのサービス、プラガブル・データベースが提供するすべてのサービス、またはインスタンス上や特定のサーバー・プール内で提供されるすべてのサービスを停止できます。

srvctl stop serviceコマンドには、停止するサービスのリスト(すべてのサービスのサブリスト)を指定することもできます。さらに、-pqパラメータを指定することで、パラレル問合せサービスのみを停止するようにsrvctl stop serviceコマンドを制限することもできます。
次の各例では、サービスの停止方法を説明します。
  • 単一のプラガブル・データベースが提供するサービスをすべて停止するには:
    $ 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 –pdb myPDB01 –service "myFirstService,mySecondService,
  myThirdService" –drain_timeout 60 –stopoption IMMEDIATE

    注意:

    SRVCTLコマンドライン・パラメータの–wait YESを使用すると、–stopoptionパラメータは排出タイムアウト間隔を経過するまで実施されなくなります(この間隔の完了前に、すべてのセッションが終了していても実施されません)。

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

この項では、FANイベントでコールアウト・プログラムに配信される情報について説明します。

FANイベントのタイプは、次の例でリスト表示されます。表6-2では、各イベント・パラメータの名前と値のペアについて説明します。次の例に示すとおり、コールアウトを介してFAN情報を受信した場合、イベント・タイプは常に最初のエントリです。 

SERVICEMEMBER VERSION=1.0
   service=test.company.com database=ractest
   instance=ractest11 host=ractest1_host0343_1 status=up reason=FAILURE
   timestamp=2012-02-01 22:06:02 timezone=-07:00 db_domain=company.com

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

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

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

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

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

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

関連項目: ロード・バランシング・イベントの詳細は、表5-1を参照してください。

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

パラメータ 説明
VERSION

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

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

instance

サービスをサポートしているインスタンスの名前であり、ORACLE_SIDの値と一致します。

host

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

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

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

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

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

値は、UP、DOWN、NODEDOWN(これはNODEイベント・タイプにのみ適用される)、NOT_RESTARTING、PRECONN_UP、PRECONN_DOWNおよび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はそのような操作の計画済アクションを作業の排出として記述します。

cardinality

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

次は、SERVICEMEMBER UPイベントの例です。 

SERVICEMEMBER VERSION=1.0 service=swingbench.example.com
database=orcl instance=orcl_2 host=mjkbj09 status=up
reason=USER card=1 timestamp=2012-07-12 14:46:46  timezone=-07:00 db_domain=example.com
incarnation

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

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

NODE VERSION=1.0 host=stru09 incarn=175615351 status=down
reason=member_leave timestamp=27-Jul-2010 14:49:32  timezone=-07:00
timestamp

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

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

表6-3に示すように、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')

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

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

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

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 &

前述の例では、次のような出力が生成されます。

NODE VERSION=1.0 host=sun880-2 incarn=23 status=nodedown reason=public_nw_down
timestamp=08-Oct-2012 04:02:14 timezone=-08:00 reported=Fri Oct 8 04:02:14 PDT 2012

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

関連項目:

コールアウトおよびイベントの詳細は、表6-2を参照してください

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

関連項目

6.2 アプリケーション・コンティニュイティの概要

アプリケーション・コンティニュイティは、データベース・セッション(すべての状態、カーソル、変数、および存在する場合は最後のトランザクションを含むフル・セッション)をリストアすることで、アプリケーションとユーザーからリカバリ可能なデータベースの停止の多くをマスクします(リプレイが成功した場合)。

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

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

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

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

関連項目

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

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

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

リクエスト

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

リカバリ可能なエラー

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

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

コミット結果

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

可変関数

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

アプリケーション・コンティニュイティは、付与されているOracleファンクション・コールに対してリプレイ時に可変オブジェクト値の置換を提供することにより、不透明バインド変数の一貫性を実現します。不変のデータベース・ファンクション( sequence.NEXTVAL、SYSDATE、SYSTIMESTAMPおよびSYSGUIDを含む)がコールに使用される場合、ファンクションの実行から戻される元の値が保存され、リプレイ時に再適用されます。

セッション状態一貫性

COMMIT文が実行された後、このトランザクションで状態が変更された場合、セッションが失われたときにトランザクションをリプレイしてこの状態を再確立することはできません。アプリケーション・コンティニュイティの構成時には、初期設定後のセッション状態が静的と動的のどちらであるか、さらにリクエスト内のCOMMIT操作後の処理続行が正しいかどうかに応じて、アプリケーションは分類されます。

  • セッション状態の変更が初期化によって不完全にカプセル化されていて、フェイルオーバー時にFAILOVER_RESTOREまたはコールバックで完全に取り込むことができない場合、セッションの状態は動的です。最初のトランザクションが完了した後、フェイルオーバーは次のリクエストが開始されるまでは内部的に無効化されます。セッション状態は、リクエストの過程で変化することがあります。

  • セッション状態の変更(NLS設定やPL/SQLパッケージ状態など)がすべて初期化の一環として行われ、フェイルオーバー時にFAILOVER_RESTOREまたはコールバックでカプセル化できる場合、セッションの状態は静的です。静的アプリケーションとは、アプリケーション・コンティニュイティの前に透過アプリケーション・フェイルオーバー(TAF)を使用できるアプリケーションのことです。セッション状態は、リクエストの過程で変化しません。

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

この項では、アプリケーション・コンティニュイティの動作、およびアプリケーション・コンティニュイティをアプリケーションで使用する方法について説明します。

この項には次のトピックが含まれます:

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

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

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

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

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

注意:

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

  1. クライアント・アプリケーションがリクエストを発行し、これが中間層(ユニバーサル接続プール(UCP)、ODP.NET、WebLogic Server、OCIセッション・プール、Tuxedo、JDBCおよびOCIドライバ、またはUCPを使用するサード・パーティ・プールなど)に渡されるか、またはJDBCリプレイ・ドライバまたはOCIドライバを使用してデータベースに直接渡されます。

  2. JDBCリプレイ・ドライバまたはOCIドライバがリクエスト内の各コールを発行します。

  3. FAN計画外停止または計画済停止による中断またはリカバリ可能なエラーが発生します。FAN/FCFがデッド状態の物理セッションを中断します。

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

    1. デッド状態の物理セッションを新しいクリーンなセッションに置き換えます。

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

    3. FAILOVER_RESTORE=LEVEL1は、共通の初期セッション状態をリストアします。アプリケーション・コンティニュイティは、アプリケーションがFAILOVER_RESTOREで指定されていない初期セッション状態も設定している場合、ラベリング・コールバックまたは再接続コールバックを使用します。

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

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

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

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

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

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

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

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

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

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

関連項目

6.3.2 アプリケーション・コンティニュイティの使用のアクション

アプリケーション・コンティニュイティは、Oracle統合スタックを使用しているときに、アプリケーションの変更なしに(またはわずかな変更で)停止をマスクします。

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

  • ODP.NET管理対象外ドライバ

  • OCIセッション・プール

  • ユニバーサル接続プール

  • WebLogic Server

  • JDBC Thin Oracleリプレイ・ドライバ

  • Oracle Tuxedo

  • SQL*Plus

Javaのアプリケーション・コンティニュイティは、ユニバーサル接続プール、WebLogicデータ・ソース(非XAおよびXAデータ・ソースを含む)に埋め込まれています。また、JDBC Thinリプレイ・ドライバ単独(Apache TomcatやカスタムのJava接続プールなど、Oracle接続プールなしのJDBCリプレイ・ドライバ)で使用できます。OCIのアプリケーション・コンティニュイティは、SQL*Plus、OCIセッション・プールに埋め込まれています。非XAデータ・ソースのOracle Tuxedo、およびODP.NET管理対象外プロバイダ。

アプリケーション・コンティニュイティは、Oracle接続プールに埋め込まれています。Oracle接続プールを使用すると、各リプレイのサイズを定めるリクエスト境界がチェックアウト時およびチェックイン時に暗黙的にマークされます。サード・パーティの接続プールの使用時には、UCPを使用します(Javaの場合)。それ以外の場合は、JDK9標準に含まれているリクエスト境界を追加できます。

アプリケーション・コンティニュイティのサポートは多くのOracleアプリケーションに統合されているため、アプリケーション・コンティニュイティに関連するサービス属性を設定する場合、それらのアプリケーションの機能は自動的に使用されます。すべてのアプリケーションについて、この章で説明する手順に従います。

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

  1. Javaを使用している場合のみ、アプリケーションがOracle JDBCの具象クラスを使用するかどうか判別します。アプリケーション・コンティニュイティを使用するには、非推奨の具象クラスを置換する必要があります。

    ORAchkユーティリティに-acchkパラメータを使用して、アプリケーションに具象クラスがあるかどうかを確認します。リプレイされてはならないものがある場合は、アプリケーション・コンティニュイティのない接続を使用します。(ほとんどのアプリケーションがリプレイ可能です)。

    関連項目:

    ORAchkの詳細は、Oracle Autonomous Health Frameworkユーザーズ・ガイドを参照してください

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

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

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

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

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

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

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

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

    重要:

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

  4. アプリケーション・コンティニュイティは、ご使用の状態、リクエスト内のすべての状態をリプレイします。アプリケーションが接続を公表する前に状態を設定する場合は、FAILOVER_RESTOREまたはコールバックが必要です。Oracle WebLogic Serverまたはユニバーサル接続プールの使用時には、FAILOVER_RESTOREまたは接続ラベリングを使用します。OCIセッション・プール、Oracle TuxedoまたはODP.NETの使用時には、FAILOVER_RESTOREを使用して、必要な場合はTAFコールバックのみを追加します。ラベリングはランタイムとリプレイの両方で使用されます。

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

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

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

    • session_state_consistencyがStaticである場合、アプリケーションは、初期設定後にセッション状態を変更しません。このモードは、PL/SQL状態を使用せずにトランザクションの途中でALTERを使用しない、データベースに依存しないアプリケーションの基本的なモードです。このモードは静的アプリケーションに対してのみ、慎重に使用してください。

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

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

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

    • 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管理対象外ドライバ12.2以降を使用します。デフォルトでは、この構成でODP.NETアプリケーションのアプリケーション・コンティニュイティが有効化されます。

    • Javaベースのアプリケーションでは、JDBC Replayデータソースに対して構成されたユニバーサル接続プール12.1 (以上)またはWebLogic Server 12.1.2 (以上)を使用します。または、サード・パーティ・アプリケーション(サード・パーティJDBCプールなど)の場合はJDBCリプレイ・ドライバを使用します。IBM WebSphere、Apache TomcatおよびRedHat Springの場合は、プールされたデータ・ソースとしてUCPを使用することが最も効果的なソリューションになります。

      カスタムJavaプールおよびスタンドアロンJavaアプリケーションは、JDBC Replayデータソースを直接使用することもできます。カスタムJavaプールおよびスタンドアロン・アプリケーションを使用する場合、beginRequestおよびendRequestコールを追加します。

    • アプリケーションがOracle接続プールからの接続の流用および戻しを行わない場合は、明示的にリクエスト境界をマークしてください。たとえば、カスタムJDBCプールまたは他のプールを使用する場合、beginRequestをチェックアウト時にコールし、endRequestをチェックイン時にコールします。これらのAPIは、接続プールのないスタンドアロンJDBCアプリケーションに対しても使用できます。

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

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

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

      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)))

    • サービスについて、FAILOVER_TYPEをTRANSACTION、COMMIT_OUTCOMEをTRUE,、およびNotificationをTRUEに設定します。必要に応じて、使用に適した接続を探す場合は、GOALをSERVICE_TIME、およびCLB_GoalをShortに設定します。

    • アプリケーション・コンティニュイティを使用するデータベース・ユーザーに、トランザクション・ガード・パッケージの権限(DBMS_APP_CONT)を付与します。次に例を示します。
      GRANT EXECUTE ON DBMS_APP_CONT TO user_name;

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

関連項目:

  • .NETアプリケーション開発の詳細は、Oracle Data Provider for .NET開発者ガイドfor Microsoft Windowsを参照してください。

  • Java用のアプリケーション・コンティニュイティが含まれるアプリケーションの開発の詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。

この項には次のトピックが含まれます:

関連項目

6.3.2.1 アプリケーション・コンティニュイティが透過的になるケース

アプリケーション・コンティニュイティは、ODP.NETアプリケーション、OCIアプリケーション、Tuxedoアプリケーションに対して透過的(アプリケーション・コードの変更が不要)になります。また、標準JDBC、Oracle接続プール(UCP、OCI、またはODP)、およびSQL*Plusを使用するJ2EEアプリケーションに対しても透過的になります。外部アクション(自律型トランザクションやSOAコールを発行するためのUTL_HTTPの使用など)を伴うアプリケーションの場合、アプリケーションが外部アクションのリプレイ(電子メールの再送信、監査、およびファイルの転送など)によって満たされるときに、アプリケーション・コンティニュイティは透過的になります。

アプリケーション・コンティニュイティが透過的にならない、Oracleプール以外のサード・パーティ製Javaコンテナなどの場合は、次に示すインフラストラクチャの変更が必要になることがあります。

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

  • 繰り返す必要のないリクエストがアプリケーションにある場合、アプリケーションはこれらのリクエストのリプレイを無効にするAPIを明示的に呼び出すことができます。このための最も簡単な方法は、FAILOVER_TYPEがTRANSACTIONに設定されていないサービスへの接続を使用することです。このようなコールは、アプリケーション・コードの1つまたは複数の部分に分離される可能性があります。

6.3.2.2 Oracle Application Continuityの構成

Javaを使用している場合は、oracle.jdbc.replay.OracleDataSourceImplデータ・ソースを使用してJDBC接続を取得する必要があります。

このデータソースは、すべてのOracle JDBCデータソース(oracle.jdbc.pool.OracleDataSourceなど)のプロパティおよび構成パラメータをすべてサポートしています。

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

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

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

    • REMOTE_LISTENERがSCAN名に設定されている場合、ADDRESS_LISTはSCAN VIPを使用する必要があります。

    • 接続文字列がSCAN名を使用する場合は、REMOTE_LISTENERSにSCAN名を設定する必要があります。

    • 接続文字列がホストVIPのADDRESS_LISTを使用する場合は、REMOTE_LISTENERSにすべての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は使用しないでください。

    接続文字列がホストVIPを使用する場合、REMOTE_LISTENERSはホストVIPを含む必要があります。接続文字列がSCAN名を使用する場合、REMOTE_LISTENERSはSCAN名に設定するか、SCAN VIPとホストVIPを含める必要があります。つまり、REMOTE_LISTENERSにSCAN名を設定する必要があるのは、クライアントが接続文字列でホストVIPを使用しない場合です。使用する場合は、REMOTE_LISTENERSには、すべてのSCAN VIPとすべてのホストVIPのADDRESS_LISTを設定する必要があります。

    次にTNSエントリの例を示しますこれは、ONS (FANのトランスポート・システム)が自動構成されるようにするための必須のTNSフォーマットです。FANは、即時検出を実現するために、アプリケーション・コンティニュイティに推奨されます。

    alias =(DESCRIPTION =
     (CONNECT_TIMEOUT=120) (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)))
6.3.2.3 アプリケーション・コンティニュイティのための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 System (ONS)とともにFANが構成されていることを確認します。

  • リプレイおよびロード・バランシングに必要なプロパティをサービスに設定します。たとえば、次を設定します。

    • FAILOVER_TYPE = TRANSACTION: アプリケーション・コンティニュイティを使用する場合

    • REPLAY_INITIATION_TIMEOUT = n: リプレイの開始を許可するまでの期間(秒数)を設定する場合(nには、必要に応じて60、300、900、1800などを指定できます)。

    • FAILOVER_RETRIES = 30: リプレイごとに接続の再試行回数を指定する場合

    • FAILOVER_DELAY = 10: 接続の再試行間の遅延時間を秒単位で設定する場合

    • GOAL = SERVICE_TIME: Oracle RACまたはOracle Global Data Servicesを使用する場合の推奨設定です

    • CLB_GOAL = SHORT: Oracle RACまたはOracle Global Data Servicesを使用する場合の推奨設定です

    • COMMIT_OUTCOME = TRUE: トランザクション・ガードを使用する場合

    • FAILOVER_RESTORE = LEVEL1: 接続プールを使用する前にアプリケーションに事前設定されていた状態を自動的にリストアします。これには、AUTOCOMMIT状態(JavaおよびSQL*Plusの場合)、NLSの状態、およびTAGS (モジュール、アクション、クライアントID、ESID)の状態が含まれます。

  • アプリケーション・コンティニュイティを使用するデータベース・ユーザーに、トランザクション・ガード・パッケージの権限(DBMS_APP_CONT)を付与します。次に例を示します。
    GRANT EXECUTE ON DBMS_APP_CONT TO user_name;

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

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

一部のアプリケーションは、接続を使用できるようにするために、まず、初期状態を設定します。

アプリケーション・コンティニュイティは、この初期状態をリプレイの開始前に確立する必要があります。このようなアプリケーションの場合は、FAILOVER_RESTOREによって、ここに示した一般的な状態をリストアします。ここに示されていない状態をアプリケーションが事前設定していて、そのアプリケーションが初期状態を必要とする場合は、別のコールバックを追加する必要があります。

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

  • PL/SQLパッケージの状態

  • NLS設定

  • オプティマイザ設定

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

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

リクエストの開始時のみ状態を設定するアプリケーションや、事前設定された状態で接続を使用することからパフォーマンス上のメリットを得るステートフル・アプリケーションの場合、次のオプションの1つを選択します。

6.3.2.4.1 FAILOVER_RESTORE = LEVEL1

FAILOVER_RESTOREをLEVEL1に設定すると、リクエストのリプレイ前に一般的な状態の初期設定が自動的にリストアされます。

次の状態がリストアされます。

  • 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 (OCI, ODP.NET 12201)

  • NLS_TIMESTAMP_FORMAT

  • NLS_TIMESTAMP_TZ_FORMAT

  • CURRENT_SCHEMA

  • MODULE

  • ACTION

  • CLIENT_ID

  • ECONTEXT_ID

  • ECONTEXT_SEQ

  • DB_OP

  • AUTOCOMMIT状態(JavaおよびSQL*Plusの場合)

  • CONTAINER (PDB)およびSERVICE (OCIおよびODP.NETの場合)

次のものはTHINドライバではサポートされていません。そのため、自動リストア・オプションから除外されます。

  • NLS_COMP

  • CALL_COLLECT_TIME

  • CLIENT_INFO

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

このシナリオでは、アプリケーションはプールからの接続を流用するときに、どのような状態も想定しません。また、初期状態を再確立するためにUCPやWebLogicラベルを使用します。

6.3.2.4.3 接続ラベリング

接続ラベリングは、パフォーマンスに優れることから推奨される汎用プール機能です。接続ラベリングが存在する場合、アプリケーション・コンティニュイティはこれを使用します。接続ラベリングが状態を再作成するため、FAILOVER_RESTOREをNONEに設定できます。

このシナリオは、Universal Connection Pool (UCP)およびOracle WebLogic Serverに適用できます。接続に事前設定された状態を活用するようアプリケーションを変更できます。接続ラベリングAPIにより、接続の一致状況が判別され、接続が流用される際にコールバックを使用してギャップが移入されます。

6.3.2.4.4 接続初期化コールバック

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

接続初期化コールバックは、登録されると、リカバリ可能なエラーの後に成功した再接続ごとに実行されます。アプリケーションは、初期化アクションがフェイルオーバー前の元の接続時のものと同じであることを確認する必要があります。コールバックの起動が失敗した場合、リプレイはその接続で無効になります。接続初期化コールバックは、アプリケーションにUCPとWebLogic接続ラベリングが実装されていないため、FAILOVER_RESTORE=LEVEL1の設定では自動的に状態がリストアできない場合にのみ使用します。

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

デフォルトでは、アプリケーション・コンティニュイティがフェイルオーバーを開始した場合、ドライバが、サービスを利用できるインスタンスで実行中の作業のリカバリを試みます。

作業をリカバリするために、ドライバはインスタンスとの良好な接続を確立する必要があります。サービスが再配置および発行される前にデータベースまたはインスタンスを再起動する必要がある場合、再接続に時間がかかる場合があります。したがって、サービスが別のインスタンスまたはデータベースから利用可能になるまでに、フェイルオーバーを遅延させる必要があります。

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

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

FAILOVER_RETRIES

正の整数ゼロ以上

30

FAILOVER_DELAY

秒数

3

次の例は、様々なフェイルオーバー・シナリオを示します。

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

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

Oracle RACまたはOracle RAC One Nodeを使用している場合は、次に示すようにSRVCTLを使用してサービスを作成します。

ポリシー管理データベースの場合:

$ srvctl add service -db codedb -service GOLD -serverpool ora.Srvpool -clbgoal SHORT -rlbgoal SERVICE_TIME
  -failover_restore LEVEL1 -failoverretry 30 -failoverdelay 10 -commit_outcome TRUE -failovertype TRANSACTION
  -replay_init_time 1800 -retention 86400 -notification TRUE

管理者管理データベースの場合:

$ srvctl add service -db codedb -service GOLD -preferred serv1 -available serv2  -clbgoal SHORT 
  -rlbgoal SERVICE_TIME -failover_restore LEVEL1 -failoverretry 30 -failoverdelay 10 -commit_outcome TRUE
  -failovertype TRANSACTION -replay_init_time 1800 -retention 86400 -notification TRUE
6.3.2.5.2 単一インスタンスのデータベースのサービスがアプリケーション・コンティニュイティを使用するように変更する方法

単一インスタンス・データベースを使用している場合は、次に示すように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;
/
6.3.2.6 SQL*Plusによるアプリケーション・コンティニュイティの使用

SQL*Plusアプリケーションには、-acフラグを使用します。

-acフラグは、セッション状態に標準のDynamicモードを使用し、COMMIT時に無効化します。Staticモードは、静的アプリケーションにのみ使用できます。
  • 次に示すように、-acフラグを使用します。
    sqlplus –ac user/password@ACservice
6.3.2.7 計画メンテナンスに対するアプリケーション・コンティニュイティの使用

計画メンテナンスの場合、推奨されるアプローチは、完了していないリクエストについてアプリケーション・コンティニュイティと連携し、Oracle接続プールからリクエストを排出する方法です。パッチが適用されたソフトウェアにスイッチオーバーするには、インスタンスを停止する必要があります。

完了する必要があるリカバリが最小限である場合、この方法が最も影響の少ない方法です。

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

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

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

    注意:

    ODP.NET管理ドライバは、アプリケーション・コンティニュイティをサポートしていません。

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

    • Oracle RAC One Nodeの場合は、-forceパラメータを指定したsrvctl relocate databaseコマンドを使用します。

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

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

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

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

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

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

故意の選択、エラーまたは見落としが原因でアプリケーション・コンティニュイティが無効な場合があります。

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

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

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

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

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

  • サービス・パラメータsession_state_consistencyがDynamic (デフォルト)に設定されているときにCOMMIT文が発行されます。

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

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

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

デフォルトでは、リプレイはリカバリ可能なエラーの後に実行されます。

繰り返す必要のないリクエストがアプリケーションにある場合、アプリケーションはアプリケーション・コンティニュイティが有効化されていないサービスへの接続を取得するか、これらのリクエストのリプレイを無効にするAPIを明示的に呼び出すことができます。たとえば、アプリケーションがUTL_SMTPを使用しているためにメッセージを繰り返す必要がない場合は、別のサービスへの接続を使用するか、disableReplay API (Javaの場合)またはOCIRequestDisableReplay API (OCIの場合)を使用します。他のすべてのリクエストは引き続きリプレイされます。

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

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

6.3.2.9.1 繰り返さない自律型トランザクション、外部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サイトへのアクセスなどがあります。そのような外部アクションがリプレイを必要としない場合、ACのない接続を使用するか、リプレイを無効化するAPIのいずれかを使用します。

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

COMMIT、ROLLBACKまたはセッションの喪失まで維持される揮発エンティティを使用して、アプリケーションが独立セッションを同期する場合、リプレイ用にアプリケーションを構成しないでください。たとえば、アプリケーションが、複数のデータソースに接続されている複数のセッションを同期化することがあります(同期化されない場合、これらのセッションはデータベース・ロックなどのリソースを使用して相互に依存しています)。アプリケーションでこれらのセッションのみがシリアライズされ、いずれかのセッションが失敗する可能性があることが認識されている場合、このような同期が許容されることがあります。ただし、1つのデータソースによって保持されているロックまたは他の高揮発リソースが、他の接続から同一または別個のデータソースのデータに対する排他的アクセスを実現することをアプリケーションが想定している場合、この想定はリプレイ時に否定される可能性があります。

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

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

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

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

アプリケーションがROWIDをキャッシュする場合、データベースが変更されているためにROWIDへのアクセスが無効になることがあります。ROWIDが表内の一意の行を特定しても、次のような状況ではROWIDの値が変更されることがあります。

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

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

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

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

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

  • 基礎となる表がGolden Gate、ロジカル・スタンバイまたは他のレプリケーション・テクノロジを使用して再構築されます。

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

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

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

SYSCONTEXTオプションは、各国語サポート(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;
6.3.2.10 リプレイなしのセッションの終了または切断

アプリケーション・コンティニュイティが構成されている場合、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を指定することもできます。

6.3.3 可変関数とアプリケーション・コンティニュイティ

リクエストがリプレイされると、可変オブジェクトのデフォルトおよび目的の処理が変化する可能性があります。

可変関数は、コールされるたびに新しい値を取得できる非DETERMINISTIC関数です。可変関数の使用例には、SYSTIMESTAMP関数に対するコールがあります。アプリケーション・コンティニュイティを使用するクライアント・アプリケーションは、リクエストのリプレイ時に可変ファンクションの元の値を保持するかどうかを決定できます。

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

注意:

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

表6-4は、リプレイ時の可変関数の処理の例を製品別に示しています。(実際の実装は特定の製品およびリリースによって異なります。)

表6-4 リプレイ時の可変オブジェクトの処理の製品別の例

可変関数 製品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;

    注意:

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

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

    • リプレイを有効化するアプリケーションを実行するデータベース・ユーザーには、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オブジェクト権限を持つ他のユーザー(所有者ではありません)には影響しません。すべてのユーザーにNOKEEPを指定する場合、これらのユーザーにKEEP SEQUENCEオブジェクト権限を付与しない(または、すでに権限が付与されている場合はそれを取り消さない)ようにしてください。

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

可変関数に対する権限を付与する場合は、次の追加の考慮事項が適用されます。

  • 可変関数の値に対するKEEP権限がユーザーに付与されている場合、SYS_GUID、SYSDATEおよびSYSTIMESTAMP関数がコールされるときにオブジェクトが可変アクセス権を継承します。

  • 順序オブジェクトで可変値に対するKEEP権限が取り消されると、このオブジェクトを使用するSQLまたはPL/SQLブロックでは、この順序に対する可変コレクションまたはアプリケーションは許可されません。

  • 付与された権限がランタイムとフェイルオーバーの間に取り消されると、収集された可変値はリプレイに適用されません。

  • ランタイムとフェイルオーバーの間に新しい権限が付与されると、可変値は収集されず、これら値はリプレイに適用されません。

関連項目

6.3.4 可変値の管理

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

インタフェースの付与または取消し

Oracle日付およびSYS_GUIDの可変を維持するための権限を付与および取り消すには、次の手順を実行します。 

GRANT [KEEP DATE_TIME | KEEP SYS_GUID]...[to USER]
REVOKE [KEEP DATE_TIME | KEEP SYS_GUID]...[from USER]

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

GRANT KEEP DATE_TIME, KEEP SYS_GUID to [custom user];
GRANT KEEP DATE_TIME, KEEP SYS_GUID to [apps user];

Oracle順序の可変を維持するための権限の付与

順序の所有者に権限を付与するには、次の手順を実行します。

CREATE SEQUENCE [sequence object] [KEEP|NOKEEP];
ALTER SEQUENCE [sequence object] [KEEP|NOKEEP];

前述のコマンドでは、リプレイのためにsequence.nextvalの元の値を保持したため、キーが一致しました。

順序を使用するその他のユーザーに関して権限の付与および取消しを行うには、次の手順を実行します。

GRANT KEEP SEQUENCES...[to USER] on [sequence object];
REVOKE KEEP SEQUENCES...[from USER] on [sequence object];

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

GRANT KEEP SEQUENCES to [apps user] on [sequence object];
GRANT KEEP SEQUENCES to [custom user] on [sequence object];

可変に対する権限のルール

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

  • DBAロールには、可変権限が含まれます。

  • ユーザーに可変が付与されている場合、(SYS_GUID、SYSDATEおよびSYSTIMESTAMPで)可変関数が呼び出されたときに、オブジェクトは可変アクセスを継承します。

  • 順序オブジェクトに対する可変の維持が取り消されると、そのオブジェクトを使用するSQLまたはPL/SQLコマンドは、その順序の可変コレクションまたはアプリケーションを許可しません。

  • ランタイムおよびフェイルオーバー間で権限が取り消されると、収集された可変は適用されません。

  • ランタイムおよびフェイルオーバー間で権限が付与されると、可変は収集されず、したがって何も適用されません。

6.3.5 セッション状態一貫性

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

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

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

Dynamicモードはほとんどすべてのアプリケーションに適しています。不明な場合は、Dynamicモードを使用してください。ユーザーがアプリケーションを変更できる場合は、Dynamicモードを使用する必要があります。

この項には次のトピックが含まれます:

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

セッション状態の値がFAILOVER_RESTOREまたは初期化コールバックの追加で完全にリストアできない場合、セッションの状態は動的になります。

最初のトランザクションが完了した後、フェイルオーバーは次のリクエストが開始されるまでは内部的に無効化されます。Dynamicセッション状態一貫性モードでは、リクエスト中に状態の変更が行われ、次のリクエストの開始時点でリプレイが有効化されます。

トランザクションの実行時に非トランザクション・セッション状態が変更される場合、セッション状態一貫性モードをDynamicに設定します。ランタイム時に変更される可能性がある非トランザクション・セッション状態の例には、ALTER SESSION、PL/SQLグローバル変数、SYS_CONTEXTおよび一時表のコンテンツがあります。アプリケーションがトランザクション以外の状態をトランザクション内で変更し、それをコミットする場合、この状態はリプレイできないため、状態の設定をDynamicに設定する必要があります。アプリケーション・コンティニュイティに対してDynamicモードを使用する場合、次のリクエストが開始されるまではCOMMIT時にリプレイは無効です。デフォルト値はDynamicです。

セッション状態一貫性モードがDynamicのときには、リクエスト中に非トランザクションのセッション状態(NTSS)が変更されます。

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

  • トランザクションなし

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

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

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

  1. チェックアウトします。

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

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

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

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

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

リプレイは、endRequest、制限付きコール、および明示的なdisableReplayまたはOCIRequestDisableReplayコールで無効化されます。

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

  1. チェックアウトします。

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

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

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

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

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

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

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

リプレイは、endRequest、制限付きコール、および明示的なdisableReplayまたはOCIRequestDisableReplayコールで無効化されます。

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

  1. チェックアウトします。

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

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

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

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

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

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

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

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

リプレイは、endRequest、制限付きコール、および明示的なdisableReplayまたはOCIRequestDisableReplayコールで無効化されます。

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

Staticモードは、長時間実行するステートレスのアプリケーションに使用します。ステートレスではないアプリケーションには、Staticモードを使用しないでください。

NLS設定、SYS_CONTEXT、PL/SQL変数、およびオプティマイザ・プリファレンスなどのすべての非トランザクション状態の変更がリクエストごとに1回の初期化の一環として設定され、このセッション状態がトランザクション中に変更されない場合にのみ、セッション状態一貫性モードをStaticに設定します。これらの設定は、FAILOVER_RESTORE=LEVEL1、コールバック、またはラベルなどを使用した接続の確立時、またはプールからの各チェックアウト時に、接続ごとに1回確立できます。

アプリケーション・コンティニュイティに対してStaticモードを使用する場合、トランザクションのフェイルオーバーはリクエストの最初のトランザクションの後も続行されます。これは、beginRequestを1回設定して、バッチ・ジョブや長いレポートなど、長時間の処理操作を実行するアプリケーションに役立ちます。

静的モードは、トランザクションで非トランザクション状態を変更する呼出しを使用するアプリケーションではサポートされません。このようなコールの具体的な例を次に示します。

  • PL/SQLサブプログラム

  • SYS_CONTEXT

  • ALTER SESSION

静的モードは慎重に指定してください。静的モードは、アプリケーションがトランザクション内で非トランザクションのセッション状態を変更しない場合にのみ使用します。セッション状態一貫性モードをStaticとして宣言することは、リクエスト内の最初のCOMMITの後に続行しても安全であることを示します。動的モードはほとんどのアプリケーションに適しています。ユーザーがアプリケーションを変更またはカスタマイズできる場合は、静的モードを使用しないでください。

セッション状態一貫性モードがStaticのときに、リクエスト中の非トランザクションのセッション状態は一定に保たれます(つまり、変更されません)。

リプレイ(つまり、アプリケーション・コンティニュイティ)はbeginRequestコールで有効化され、制限付きコール、disableReplayまたはOCIRequestDisableReplayコール、またはendRequestコールで無効化されます。

次に、3つのアプリケーション・シナリオのステップ・ロジックを示します。

  • トランザクションなし

  • 最後の文としてCOMMITが最後に使用される1つ以上のトランザクション

  • アプリケーション・コンティニュイティを無効化する制限付きコールを使用したトランザクションが続くCOMMIT文を使用したトランザクション

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

  1. チェックアウトします。

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

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

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

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

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

リプレイは、endRequest、制限付きコール、および明示的なdisableReplayまたはOCIRequestDisableReplayコールで無効化されます。

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

  1. チェックアウトします。

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

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

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

  5. トランザクションがコミットされます。

  6. トランザクションがパージされます。

    (追加トランザクションごとに、手順4から6が実行されます。)

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

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

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

リプレイは、endRequest、制限付きコール、および明示的なdisableReplayまたはOCIRequestDisableReplayコールで無効化されます。

制限付きコールを使用したトランザクションが続くCOMMIT文を使用したトランザクションのリクエストの場合、論理的なステップは次のようになります。

  1. チェックアウトします。

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

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

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

  5. トランザクションがコミットされます。

  6. トランザクションがパージされます。

  7. 2番目のトランザクションが開始されます。

  8. トランザクションが制限付きのコールを発行し、これによってアプリケーション・コンティニュイティが無効化されます。

  9. トランザクションがパージされます。

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

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

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

リプレイは、endRequest、制限付きコール、および明示的なdisableReplayまたはOCIRequestDisableReplayコールで無効化されます。

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

セッションが再構築されるときに、すべての状態が再構築されますが、これには副作用が残されたままの文の再実行も含まれます。

レポートの作成や監査の完了など、これらの副作用こそが求められる作業である場合もあります。

アプリケーション・コンティニュイティは、データベース状態をリストアするために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へのアクセス)

関連項目

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

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

  • アプリケーション・コンティニュイティは次のものを除外します。

    • JDBC OCIドライバ(タイプ2)

    • ODP.NET管理対象ドライバ

    • OLE DB

    • ODBC

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

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

  • リプレイのターゲット・データベースは、ソース・データベースと同じデータベース・クラスタ(Oracle RAC、Oracle Data Guard、Oracle Active Data Guard、またはOracle Multitenant)に存在している必要があります。

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

  • Oracle Database 12c リリース2 (12.2.0.1)のOCIおよびODP.NETの場合、OCIドライバのアプリケーション・コンティニュイティは、ADT、拡張キュー、動的バインド、および一部のLOB APIを除外します。このような除外は、Javaには適用されません。

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

  • Oracle Database 12リリース2 (12.2)以降、JavaおよびODP.NET管理対象外ドライバのXAデータ・ソースでリプレイがサポートされています。リプレイは、ローカル・トランザクションをサポートします。リプレイは2フェーズが使用されると、サイレントに使用不可にします。これにより、アプリケーション・コンティニュイティは、プロモート可能なXAおよびXAデータ・ソースを使用するアプリケーションとXAを使用しないほとんどのアプリケーションで最適に動作するようになります。

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

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

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

  • プライマリ・データベースに戻る読取り/書込みデータベース・リンクを使用してOracle Active Data Guardを使用している場合、リプレイはサポートされません。これはトランザクション・ガードのセキュリティ制限です。

  • リプレイはパラレル問合せコールの失敗に対して、これが文レベルの失敗であるときに適用されません。たとえば、インスタンスやノードの障害またはメモリーの問題で発生したコール失敗に対するORA-12805:parallel query server died unexpectedlyの後には、リプレイは行われません。

  • Javaの場合にのみ、リプレイはDRCPをサポートしません。専用サーバーと共有サーバーはサポートされます。

  • リクエストは2PC XAを使用します。Oracle Database 12c リリース2 (12.2)以降、アプリケーション・コンティニュイティはプロモート可能なXAでサポートされ、XAが使用されていないときにXAデータ・ソースを使用します。

注意:

ディスク・イメージ(BCVなど)を分割するか、別のデータベースになるようにデータベースをクローニングすることによってデータベースのクローンを作成し、物理またはOracle Active Data Guardデータベースではないロジカル・スタンバイまたはロジカル・コピーを作成する場合は、nidを使用してDBIDを変更し、データベースを区別する必要があります。nidプログラムの使用の詳細は、次のMy Oracle Supportノートを参照してください: NIDを使用したDBIDおよびDBNAMEの変更方法(ドキュメントID 224266.1)およびNIDを使用したOracle RAC DatabaseのDBNAMEおよびDBIDの変更(ドキュメントID 464922.1)。

関連項目

6.6 クライアント・フェイルオーバーを向上させるためのトランザクション・ガード

トランザクション・ガードは、アプリケーション・コンティニュイティがリプレイするトランザクションが複数回適用されないようにします。

最後の送信がコミットされたこと、これからコミットされること、または実行が完了しなかったことを認識できないと、アプリケーションで問題となります。これは、再送信するユーザーや独自のリプレイを使用するアプリケーションが重複した要求を発行したり、データベースにすでにコミットされた変更内容が繰り返されたり、その他の形式の論理破損が発生する原因となる可能性があります。トランザクション・ガードを使用すると、この問題を解決できます。

アプリケーション・コンティニュイティは、自動的にトランザクション・ガードを有効化して使用しますが、トランザクション・ガードは個別に有効化することもできます。アプリケーションがアプリケーション・レベルのリプレイを実装している場合は、冪等性を実現するためにアプリケーションをトランザクション・ガードと統合する必要があります。

Oracle Database 12cでは、トランザクション・ガードによって、自動的かつ透過的に基準化された方法で冪等性を達成するために、アプリケーションで使用される新たな完全統合ツールが提供されます。トランザクション・ガードでは、論理トランザクションID (LTXID)を使用して、重複したトランザクションの送信を回避します。これは、トランザクションの冪等性と呼ばれます。LTXIDはコミット時に継続され、ロールバックの後に再使用されます。通常の実行中、LTXIDは、各データベース・トランザクションについてクライアントおよびサーバーの両方で自動的にセッションで保持されます。コミット時に、LTXIDはトランザクションのコミットの一環として継続され、次に使用するLTXIDがクライアントに返されます。

XAトランザクション用のトランザクション・ガード

トランザクション・ガードは、XAベースのトランザクションもサポートします。これは、Oracle WebLogic Server、Oracle Tuxedo、およびMicroSoft Transaction Server (Oracle ODP.NETを通じてOracle Databaseに公開されます)などのトランザクション・マネージャのオプションです。

XAトランザクションのトランザクション・ガード・サポートは、Oracle WebLogic ServerでのXAトランザクションのリカバリ可能な停止の後の安全なリプレイを実現します。XAサポートの追加により、Oracle WebLogic Serverは、トランザクション・ガードを使用した冪等性を持つリプレイを実現できます。

この項には次のトピックが含まれます:

関連項目

6.6.1 トランザクション・ガードの構成チェックリスト

トランザクション・ガードのサービスを構成する前に、次の構成チェックリストを使用します。

  • 次のように、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 RAC、Oracle Data GuardまたはOracle Active Data Guardを使用している場合は、停止を迅速に通知するためにFANを使用することをお薦めします。

6.6.2 トランザクション・ガードのサービスの構成

トランザクション・ガードを使用するようにサービスを構成するには、次のサービス・パラメータを設定します。

  • -commit_outcome: -commit_outcomeサービス・パラメータをTRUEに設定します。このサービス・パラメータにより、COMMITが実行されて停止が発生した後に、トランザクションのコミット結果 にアクセスできるかどうかが決定されます。Oracle DatabaseではCOMMITは常に永続的ですが、トランザクション・ガードでは、COMMITの結果が永続的になり、アプリケーションでは、それを使用して、停止の前に実行された最後のトランザクションのステータスを強制適用します。

  • -retention: -retentionサービス・パラメータを-commit_outcomeとともに使用します。このサービス・パラメータにより、COMMIT結果が保持される時間(秒数)が決定されます。ほとんどのインストールではデフォルト値を使用することをお薦めします。

次のSRVCTLコマンドにより、salesという名前のポリシー管理サービスをトランザクション・ガードに構成します。 

$ srvctl add service -db crm -service sales -serverpool spool_1
  -commit_outcome TRUE -retention 86400 -notification TRUE

次の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の値に名前が設定されているサービス)は使用しないでください。デフォルト・サービスは、管理目的に使用されるものであり、ユーザー作成のサービスと同じプロパティを備えていません。

関連項目

6.7 TAFによるOCIクライアントのフェイルオーバー

Oracle Net Servicesによってインスタンスへの接続が確立されると、クライアントが接続をクローズするか、インスタンスが停止するか、または障害が発生するまで、接続はオープン状態のまま維持されます。

接続に透過的アプリケーション・フェイルオーバー(TAF)を構成すると、インスタンスで障害が発生した場合、Oracle Databaseは障害が発生していないインスタンスでセッションをリプレイします。

TAFでは、フェイルオーバーが完了すると問合せは再開できますが、INSERT、UPDATE、DELETEなどの他のトランザクションの場合、アプリケーションで、失敗したトランザクションをロールバックして再度送信する必要があります。また、フェイルオーバーが発生したら、セッションのすべてのカスタマイズ(ALTER SESSION文)を再度実行する必要があります。ただし、TAFでは、ワークロードが変化しても、通常処理の間は接続が移動されません。

サービスはTAFのデプロイメントを簡素化します。サービスのTAFポリシーを定義でき、このサービスを使用するすべての接続によって、自動的にTAFが有効になります。これには、クライアント側の変更は必要ありません。サービスのTAF設定は、クライアントの接続定義内のTAF設定よりも優先されます。

-failovermethodおよび-failovertypeパラメータを定義して、サービスのすべてのユーザー用のTAFポリシーを定義できます。-failoverretryおよび-failoverdelayパラメータをそれぞれ使用して、失敗したセッションによるサービスへの再接続試行回数、および再接続の試行間での待機時間を設定して、TAFポリシーをさらに詳しく定義できます。

サービスのTAFポリシーを定義するには、次の例に示すようにSRVCTLを使用しますが、ここで、サービス名はtafconn.example.com、データベース名はCRMです。 

$ srvctl modify service -db crm -service tafconn.example.com -failovermethod BASIC
  -failovertype SELECT -failoverretry 10 -failoverdelay 30

TAFが有効なOCIアプリケーションでは、高速接続フェイルオーバーのためにFAN高可用性イベントを使用します。

トランザクション・ガードとFAILOVER_RESTOREをサポートするTAF

トランザクション・ガードを使用すると、開発者向けのエラーがTAFによって管理されます。TAFとトランザクション・ガードの両方を使用すると、開発者はTAFエラーを使用して、コミットされていないトランザクションをロール・バックして安全に再送信することも、そのトランザクションを返すこともできるようになります(TAFエラー・コードORA-25402、ORA-25408、ORA-25405の場合)。

FAILOVER_RESTOREを使用していると、TAFは自動的に一般的な状態をリストアします。これにより、ほとんどのアプリケーションでコールバックの必要がなくなります。

関連項目