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)など、アプリケーション・コンティニュイティを使用するテクノロジまたは製品環境に関連する主な概念や技術をよく理解していることを前提としています。

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

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

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

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

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

関連トピック

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

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

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を検出することもできます。

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

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

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

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

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

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

FANイベントは、Oracle Notification Serviceとアドバンスト・キューイングを使用して発行され、後者は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を指定している場合、リスナーは、接続時ロードを均等に分散する際に、ロード・バランシング・アドバイザを使用します。ロード・バランシング・アドバイザが使用可能であった場合、リスナーで使用されるメトリックはさらに詳細に制御できます。

関連トピック

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

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

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

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

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

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

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

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

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

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

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

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

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

パラメータ 説明
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=2018-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=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=rwsbj10 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はそのような操作の計画済アクションを作業の排出として記述します。

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=2018-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-2018 14:49:32  timezone=-07:00
timestamp

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

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

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

表6-2 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')

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

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

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

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

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

高速アプリケーション通知(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停止イベントで、これらのイベントは、発生した場所にかかわらず、すべてのノードにポストされます。

関連トピック

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

計画外停止の管理

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

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

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

ノート:

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

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

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

関連トピック

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

計画メンテナンスの管理

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

  • ユーザーを妨害しない計画メンテナンスの管理
    FAN対応のOracleまたはOracle以外の接続プールにより制御された期間中のインスタンスから、またはOracle Database18c以降はデータベース自体で、データベース・セッションを排出することをお薦めします。
  • メンテナンスのためのサービスのグループの管理
    多くの企業が多数のサービスを実行しています。多数のサービスが単一のデータベースまたはインスタンスで提供されることも、多数のデータベースが同じノード上で実行する少数のサービスを提供することもあります。
  • 計画メンテナンスの前のサーバーの排出
    計画メンテナンスの前に、アプリケーションの動作が中断されないように、データベース・インスタンスでデータベースのセッションを排出またはフェイルオーバーします。Oracle Database 18c以降、データベース自体がセッションを排出します。

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

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

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

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

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

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

Oracle Database 18c以降、一部のアプリケーションが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

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

  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イベントにより、新しいインスタンスが使用可能で、次の要求境界でこのインスタンス上にセッションを作成できることが接続プールに通知されます。

関連トピック

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

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

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

個別のサービスごとにSRVCTLコマンドを実行する必要はなくなり、影響を受けるすべてのサービスのノード名、データベース名、プラガブル・データベース名、またはインスタンス名を指定することのみが必要になります。
  • たとえば、特定のノードで実行しているすべてのサービスを停止する場合は、次に示すコマンドを使用できます。
    $ 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を使用すると、プラガブル・データベースのサービスを管理できます。
  • サービスの再配置
    srvctl relocate serviceコマンドを使用すると、ターゲット宛先にサービスを再配置できます。インスタンス、ノードまたはデータベースが再配置の宛先になります。
  • サービスの停止
    srvctl stop serviceコマンドを使用すると、ノード上のすべてのサービス、データベースが提供するすべてのサービス、プラガブル・データベースが提供するすべてのサービス、またはインスタンス上や特定のサーバー・プール内で提供されるすべてのサービスを停止できます。

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

サービスの開始

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 | -serverpool pool_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コマンドには、停止するサービスのリスト(すべてのサービスのサブリスト)を指定することもできます。さらに、-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 –service "myFirstService,mySecondService,
  myThirdService" –drain_timeout 60 –stopoption IMMEDIATE

    ノート:

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

計画メンテナンスの前のサーバーの排出

計画メンテナンスの前に、アプリケーションの動作が中断されないように、データベース・インスタンスでデータベースのセッションを排出またはフェイルオーバーします。Oracle Database 18c以降、データベース自体がセッションを排出します。

計画メンテナンスの準備を行う場合は、サーバー・インフラストラクチャを使用しているサービスを停止または再配置する必要があります。サービスの再配置は計画済停止の前に一定期間にわたって行われ、各サービスに関連する作業の性質に基づいています。

計画メンテナンスのローリングの手順では、メンテナンスの前にサービスを別のデータベース・インスタンスに移動し、クライアント側ドライバ、接続プール、データベース・インスタンス自体および他のサブスクライバにメンテナンスが保留中であることと、排出する必要のあるもの(このサービスを使用する接続またはセッション)を通知します。排出が通知されると、高速アプリケーション通知(FAN)イベントが送信され、クライアント・プールは他の場所で説明されているように動作し、さらにデータベースでは接続を解放する安全な場所を検索し、必要に応じて接続を移行します。

サービスを移動または停止すると、FAN通知がトリガーされ、サブスクライブしているOracleドライバおよびOracle接続プールで受信されます。Oracle Database 18c以降では、FAN通知によってもサーバーでのセッションの排出がトリガーされます。そのサービスに対する新規の作業が、ただちにサービスの機能している別のインスタンスに送信されます。既存のセッションは、その作業の完了後に解放用にマークされます。作業が完了して接続が接続プールに戻されると、Oracleドライバまたは接続プールのいずれかがこれらのセッションを終了します。

データベースでのセッションの排出

OLTPアプリケーション、アプリケーション・サーバーおよびカスタム・アプリケーションがデータベース・セッションを流用および返却する専用の接続プールを持っている場合、データベース・セッションが流用されなければ、そのセッションの排出は安全です。Oracleサーバー・インフラストラクチャがセッションを閉じるのに最適なのは、アプリケーション・サーバーがその接続の妥当性をテストした時点です。流用および解放時に接続プール・マネージャが接続の妥当性をテストして、接続が有効はでないことが検出した場合、エラーはアプリケーションに返されません。

安全な場所とは、アプリケーションが中断されない場所です。接続プールの場合、これは流用(チェックイン)されていない接続を意味し、アプリケーションの場合、接続を流用または返却する時点において同様のことが当てはまります。この時点では、すべての作業が完了しているか、起動していないかのいずれかです。データベースでは、すべての状態がアプリケーションに対して透過的にリストアできる場合、接続をフェイルオーバーすることもできます。

Oracle Database 18c以降では、データベースはルールとヒューリスティックの拡張可能なセットを使用して、データベース・セッションを取り除くタイミングを検出します。排出が開始すると、データベース・セッションはルールが満たされるまでデータベースで継続します。ルールには次の内容が含まれています。

  • 標準アプリケーション・サーバーが妥当性をテストします

  • カスタムSQLが妥当性をテストします

  • リクエスト境界は有効になっており、アクティブなリクエストはありません

  • リクエスト境界は有効になっており、現在のリクエストは終了しています

  • セッションにはリカバリ可能なセッション状態が1つ以上あり、フェイルオーバー時にセッションを再作成できます

ノート:

Oracle Database 18c以降、接続を排出するには、「サーバーで排出するための接続テストの追加、無効化、有効化および削除」を参照してください。

たとえば、接続テストの場合、標準的な手順として、接続プールからの流用時、プールへの返却時およびバッチ・コミット時に、アプリケーション・サーバー、プールされたアプリケーション、ジョブ・スケジューラなどが接続をテストします。排出時に、データベースは接続テストを中断して接続を閉じ、テストの失敗ステータスを返します。接続テストを発行しているアプリケーション・レイヤーは、失敗の戻りステータスを処理する準備ができています。通常、さらにリクエストを発行して、別の接続を取得します。アプリケーションは中断されません。

すべてのセッションを排出できるわけではありません。接続がプールに戻っていないときや、FANが使用されていないときには排出できません。透過的アプリケーション・コンティニュイティまたはアプリケーション・コンティニュイティが有効化されている場合、サーバーは、アプリケーション・コンティニュイティがセッションをすばやくリカバリできるリクエスト境界を検出します。サーバーはセッションを中断する可能性がありますが、アプリケーション・コンティニュイティはこれを中断せずにリカバリします(Oracle RACクラスタの別のサーバーに対してなど)。

排出しないデータベース・セッションの場合、データベースはセッションを置換できるブレーク・ポイントを見つける必要があります。ブレーク・ポイントでは、状態が既知およびリカバリ可能である場合に、接続は透過的にフェイルオーバーできます。ブレーク・ポイントは、トランザクション境界、コールがリクエスト内で処理される前のリクエストの先頭(beginRequest)、およびリクエストが開始または終了していることを通知する監査コールなど、パターンである場合があります。ブレーク・ポイントは、状態がリストア可能であると認識されている場合にのみ適用されます。

接続をフェイルオーバーすると、アプリケーションによっては、アプリケーション・コンティニュイティ、透過的アプリケーション・コンティニュイティまたは透過的アプリケーション・フェイルオーバー(TAF)を有効にする必要があります。

ノート:

UCPまたはOCIセッション・プールなど、Oracle接続プールは継続的な可用性を実現し、ロード・バランシングなどを提供することで大きな利点を提供するため、これらの接続プールを使用することをお薦めします。

XAトランザクションを使用したセッションの排出

XAを使用する場合は、DBA_CONNECTION_TESTSでXA_START_NEWを有効にします。この接続テストは、XAトランザクションを使用しているアプリケーションでのサービスに対して有効にできます。

セッションが排出用にマークされ、XAトランザクションの最初のブランチがデータベース・インスタンスで受信されると、次のアクションが実行されます:
  1. データベース・サーバーによってセッションがクローズされます。
  2. XAER_RMFAILが返され、接続がR0状態に戻ります。
  3. クライアントでは、続行するにはxa_open()を再度実行する必要があります(これは想定されている動作です)。
これらのステップでは、進行中のXAトランザクションを完了でき、そのインスタンスでの新しいXAトランザクションは許可されません。

ノート:

  • Oracle Database 19cでXA_START_NEWを使用するには、バグ36785897用の個別パッチを適用します。
  • XAにXA_START_NEW排出メソッドを使用する場合は、このメソッドを他の排出メソッド(クライアント側接続テストや、XAを使用しているセッションでのFANなど)と混在させないでください。

XAおよびセッションレス・トランザクションの排出

前の項で説明したように、接続は、安全なポイントで(それらが排出期間中に流用(チェックイン)されていないときなど)フェイルオーバーされます。XAおよびセッションレス・トランザクションに対してはそれを実行できません。これらのタイプのトランザクションは、アプリケーション・コンティニュイティや透過的アプリケーション・コンティニュイティではサポートされておらず、セッションでそれらがアクティブなときにフェイルオーバーされません。このようなトランザクションは、排出タイムアウトの後に中断されます。

Oracle Database 23ai以降では、データベース・セッションをいつ取り除くかを検出する拡張可能な一連のルールおよびヒューリスティックが、XA用とセッションレス・トランザクション用という2つの新しいルールの追加によってさらに強化されています。

これらの新しいルールを有効にすると、流用(チェックイン)された接続で、排出期間中に既存のXAおよびセッションレス・トランザクションを再開できるようになります。ただし、新しいトランザクションを開始することはできません。これにより、現在のトランザクションを正常に終了するとともに新しいトランザクションの開始を禁止できるようになるため、トランザクション成功率が向上します。

事前定義された接続テストの有効化または無効化

デフォルトでは、事前定義された接続テストPING_TEST、ENDREQUEST_TEST、XA_START_TESTおよびSESSIONLESS_START_TESTは無効になっており、他の事前定義された接続テストはすべて有効になっています。特定のサービスに対してデフォルトで無効になっている事前定義済の接続テスト・ルールを有効にするには、次の手順に従います。
  1. CDBまたはPDBに対して接続テストを有効にするには、次のようなSQL文を使用します:
    SQL> execute dbms_app_cont_admin.enable_connection_test(connection_test_type => dbms_app_cont_admin.xa_start_test);
  2. 必要ないサービスに対する接続テストを選択的に無効にするには、次のようなSQL文を使用します:
    SQL> execute dbms_app_cont_admin.disable_connection_test(connection_test_type => dbms_app_cont_admin.xa_start_test, service_name => 'tkfojpm2');

サーバーで排出するための接続テストの追加、無効化、有効化および削除

サービス、プラガブル・データベースまたは非コンテナ・データベースにSQL接続テストを追加できます。

デフォルトでは、すべてのデータベース・サービスおよびプラガブル・データベース・サービスに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;');
  • XAトランザクションの開始のテストを有効にする場合は、次のようなSQL文を使用します:
    SQL> execute dbms_app_cont_admin.enable_connection_test(dbms_app_cont_admin.xa_start_test);
  • XAトランザクションの開始のテストを無効にする場合は、次のようなSQL文を使用します:
    SQL> execute dbms_app_cont_admin.disable_connection_test(dbms_app_cont_admin.xa_start_test);
  • セッションレス・トランザクションの開始のテストを有効にする場合は、次のようなSQL文を使用します:
    SQL> execute dbms_app_cont_admin.enable_connection_test(dbms_app_cont_admin.sessionless_start_test);
  • セッションレス・トランザクションの開始のテストを無効にする場合は、次のようなSQL文を使用します:
    SQL> execute dbms_app_cont_admin.disable_connection_test(dbms_app_cont_admin.sessionless_start_test);

すべてのアプリケーション・サーバーには各接続プールで接続の妥当性をテストする機能があり、これは構成プロパティまたは管理コンソールで設定されています。テストの目的は、使用できない接続をアプリケーションに渡さないようにすることと、使用できない接続を検出した場合に、プールへの解放時にこれを削除することです。

様々なアプリケーション・サーバーでテストの名前が類似しています。提供されているテストでは様々なアプローチを使用しており、最も一般的なものはSQL文です。Javaアプリケーション・サーバーで標準のJavaコールconnection.isValidを使用することをお薦めします。Oracle Database 18c以降、これらのテストを使用してデータベースを排出します。また、Oracle Database 18c以降、データベースは安全な排出ポイントのためにセッションを調査することにより、FANを使用しないでセッションを排出します。

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

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

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

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.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.enable_connection_test(dbms_app_cont.sql_test,'select 1 from dual');
アプリケーション・サーバーでは次を使用します。
Select 1 from dual;

Oracle Notification Services (ONS)の自動構成をサポートするために次に示すフォーマットの使用をお薦めします。これにより、FANイベントを受信できます(ONS経由)。

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

関連トピック

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

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

Oracle Databaseに付属するアプリケーション・コンティニュイティ機能により、データベースを使用するシステムおよびアプリケーションのフォルト・トレランスが向上します。

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

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

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

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

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

関連トピック

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

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

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

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

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

データベース・リクエストとは、アプリケーションからデータベースに送信された作業のユニット(トランザクションなど)です。一般に、リクエストは、単一のデータベース接続上の単一の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文が実行された後、このトランザクションで状態が変更された場合、セッションが失われたときにトランザクションをリプレイしてこの状態を再確立することはできません。アプリケーション・コンティニュイティの構成時には、初期設定後のセッション状態が静的と動的のどちらであるか(または自動的に決定されるようにAUTOを使用)、さらにリクエスト内のCOMMIT操作後の処理続行が正しいかどうかに応じて、アプリケーションは分類されます。

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

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

  • 透過的アプリケーション・コンティニュイティを使用すると、セッション状態の一貫性をAUTO設定することにより、状態が管理されます(これは透過的アプリケーション・コンティニュイティの必須設定です)。これらのセッション状態は、フェイルオーバー時に追跡および検証されます。事前設定された状態の外側にはさらに状態を追加できます。

親トピック: アプリケーション・コンティニュイティについて

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

データベースの計画メンテナンスおよび計画外停止が透過的な場合、アプリケーションでは継続的な可用性を実現します。

親トピック: アプリケーション・コンティニュイティについて

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

透過的アプリケーション・コンティニュイティは、Oracle Databaseリリース18cのOracle Real Application Clusters (Oracle RAC)に導入されたアプリケーション・コンティニュイティの機能モードであり、セッションおよびトランザクションの状態を透過的に追跡および記録して、リカバリ可能な停止後にデータベース・セッションをリカバリできるようにします。

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

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

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

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

透過的アプリケーション・コンティニュイティを使用すると、DBAはアプリケーションの知識がなくても次のことを実現できます。

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

  • セッションのリカバリ時にアプリケーション・レベルの副作用を認識して無効化する—通常の実行時に、透過的アプリケーション・コンティニュイティは副作用を検出します。副作用のタイプは、アプリケーションのロジックに関するものとデータベース・ハウスキーピングに関する内部的なもので区別されています。副作用を含む文を使用するアプリケーションの場合、文を実行しているときの取得は無効になっています。新しいリクエストが開始されると、取得は自動的に再度有効になります。

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

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

    Oracle RACリリース18cより前にはリクエスト限界がなく、下位のレイヤー(データベースやドライバなど)でアプリケーションおよびアプリケーション・サーバーがその接続を管理する方法を示す情報がありませんでした。ほぼすべてのアプリケーション・サーバーとエンタープライズ・アプリケーション、および適切なプラクティスを使用するカスタム開発は、最適なパフォーマンスを得るために、そのレイヤーに接続をキャッシュします。下位のレイヤーでは、接続を処理してバランスを取る方法がありません。下位のレイヤーではデータベースへのユーザー・コールしか表示できませんでした。

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

Java (Oracle Database 18c以降)、OCIおよびODP.NET Unmanaged Provider (Oracle Database 19cリリース19.3以降)で透過的アプリケーション・コンティニュイティを使用すると、アプリケーションのリソース使用率が少なくなりリカバリ時間が短縮されます。これは、状態に影響しない文が記録されず、それらが不要になったときにパージされ、リクエスト境界が自動的に拡張されるためです。

様々なアプリケーションの場合の透過的アプリケーション・コンティニュイティ

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

次のタイプの様々なアプリケーションがあります。

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

  • データベースに依存しない: アプリケーションでは接続の確立時に状態を設定します。非トランザクション・セッション状態を再度変更しません。変更することはごくまれです。これらのアプリケーションの場合、アプリケーション・コンティニュイティは暗黙的な境界を指定します。

  • ブラック・ボックス: 実行時にOracle専用の状態を使用しているか、状態を変更している(あるいはその両方の)アプリケーション。このカテゴリはさらに次のように分かれます。

    • 表示可能な境界のないOLTPなどの短いユーザー・コールが含まれたアプリケーション

    • DSS、レポートやウェアハウスなどの長いユーザー・コールが含まれたアプリケーション

リクエスト境界

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

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

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

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

  • Java用の透過的アプリケーション・コンティニュイティを使用する場合、最初のリクエスト境界のみが必要になります(Oracle Database 18cの場合のみ)。

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

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

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

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

データベースに依存しないアプリケーション(リクエスト境界のないアプリケーション)は単純な非トランザクション状態を設定し、Oracle固有の機能または順序のいずれも使用しません。これらのアプリケーションは、通常、接続が作成されたときに一度状態を設定します。その後、状態を再度変更することはありません。変更することはごくまれです。このカテゴリのプリケーションには、サーバー側のセッション状態を作成しない匿名のPL/SQLを使用するアプリケーションが含まれています。

JDBCアプリケーションに透過的アプリケーション・コンティニュイティを使用する場合、状態の分類を使用して、認証後にアプリケーション・コンティニュイティの記録を有効化および開始するポイント、および取得が無効化イベントによって無効化された後に記録を再度有効化するポイントを検出します。最初のリクエスト境界のみが必要ですが、存在するリクエスト境界が使用されます。リクエスト境界は、SQL*Plusの場合は必須ではありません。これらはODP.NET、OCIセッション・プール、Tuxedo、Oracle Universal Connection Pool用に埋め込まれています。

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

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

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

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

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

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

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

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

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

ノート:

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

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

  2. 中間層またはJDBCリプレイ・ドライバやOCIドライバが要求内の各コールを発行します。

  3. 計画済または計画外のDOWN高速アプリケーション通知(FAN)イベントまたはリカバリ可能なエラーが発生します。FANまたは高速接続フェイルオーバー(FCF)により、デッド状態の物理セッションが中断されます。

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

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

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

    3. FAILOVER_RESTORE=LEVEL1またはFAILOVER_TYPE=AUTOの場合、アプリケーション・コンティニュイティでは共通の初期セッション状態をリストアします。アプリケーション・コンティニュイティは、アプリケーションがコールバック時に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は使用していない場合、停止が原因ですべてのパブリック・ネットワークが中断されるか、データベースまたはデータベース・セッションがしばらくの間停止すると、アプリケーション・コンティニュイティは、セッションを再構築し、接続がリストアされた後にデータベースに対して最後のトランザクション(トランザクションが進行中であった場合)をリプレイしようとします。

  • 個別のサービスごとにSRVCTLコマンドを実行する必要はなくなり、影響を受けるすべてのサービスのノード名、データベース名、プラガブル・データベース名、またはインスタンス名を指定することのみが必要になります。

関連トピック

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

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

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

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

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

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

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

  • ODP.NET、管理対象外ドライバ12.2以降
  • OCIセッション・プール12.2以降
  • ユニバーサル接続プール12.1以降
  • Oracle WebLogic Server 12c
  • JDBC Thin Oracleリプレイ・ドライバ12.1以降
  • Java接続プールまたはスタンドアロンJavaアプリケーション(Oracle JDBC - Replay Driver 12c以降をリクエスト境界で使用)
  • SQL*Plus 19.3以降
  • ユニバーサル接続プールを使用したサード・パーティのJDBCアプリケーション・サーバー

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

  • Oracle Call Interface (OCI)およびOracle C++ Call Interface (OCCI)
  • ODP.NET、管理対象外ドライバ12.2以降
  • Oracle Tuxedo 19.3以降
  • OCIセッション・プール12.2以降
  • SQL*Plus 19.3以降
  • Oracle JDBC OCIドライバ(Thickドライバは一般に非推奨)

Javaのアプリケーション・コンティニュイティは、ユニバーサル接続プール、WebLogicデータ・ソース(非XAおよびXAデータ・ソースを含む)に埋め込まれています。また、JDBC Thinリプレイ・ドライバ単独(Apache TomcatやカスタムのJava接続プールなど、Oracle接続プールなしのJDBCリプレイ・ドライバ)で使用できます。OCIのアプリケーション・コンティニュイティは、SQL*Plus、OCIセッション・プール12.2以降、およびODP.NET Unmanaged Providerに埋め込まれています。透過的アプリケーション・コンティニュイティを使用すると、Oracle Database 18c以降ではJDBCアプリケーション、およびOracle Database 19c (19.3)以降ではOCIアプリケーションが自動的に有効になります。

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

リクエスト境界

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

ノート:

Oracle Database 18cのみ: Javaには初期beginRequestが必要になります。これは、最新バージョンのJavaリプレイ・ドライバを使用しているときには不要です。
アプリケーション・コンティニュイティ構成タスクの概要

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

アプリケーション・コンティニュイティのサポートは多くの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をOracle Database 18c以降のクライアントともに使用する場合、FAILOVER_RESTOREを使用して、必要な場合はTAFコールバックのみを追加します。ラベリングはランタイムとリプレイの両方で使用されます。

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

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

    • session_state_consistencyがAUTOに設定されている場合、透過的アプリケーション・コンティニュイティはセッション状態を監視し、処理を決定します。状態の使用状況が不明か、状態が将来変更されることがわかっている場合は、透過的アプリケーション・コンティニュイティを使用します。追加の事前設定された状態をリストアする必要がある場合があるため、事前設定されたセッション状態のリストを参照してください。

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

    • session_state_consistencyがSTATICに設定されている場合、アプリケーションは、初期設定後にセッション状態を変更しません。このモードは、PL/SQL状態を使用せずにトランザクションの途中でALTERを使用しない、データベースに依存しないアプリケーションの基本的なモードです。透過的アプリケーション・コンティニュイティは、session_state_consistencyをSTATICではなくAUTOに設定して使用します。AUTO設定により、セッション・ステートが静的であることが検証されます。

  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アプリケーションのアプリケーション・コンティニュイティが有効化されます。OCIセッション・プールを使用しないOCIベース・アプリケーション(SQL*Plusを含む)を使用する場合は、自動で境界が追加される透過的アプリケーション・コンティニュイティを使用します。

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

      カスタム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.replay.OracleDataSourceImpl、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の範囲内で接続するか、エラーを受信する必要があります。

  • Oracle Databaseリリース19c以降、高可用性機能があるため、簡易接続構文を使用できます。たとえば:

    primary-vip,secondary-vip:1521/sales.example.com?connect_timeout=90&transport_connect_timeout
=3&retry_count=30&retry_delay=3

例6-2 ONSの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には、必要に応じて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 = AUTO | LEVEL1: 透過的アプリケーション・コンティニュイティにFAILOVER_RESTORE=AUTOを、手動アプリケーション・コンティニュイティにFAILOVER_RESTORE=LEVEL1を使用します。リプレイの開始前に、接続プールに事前設定されているクライアント状態を自動的にリストアするには—AUTOCOMMIT状態(JavaおよびSQL*Plus用)、NLS状態およびTAGS (MODULE、ACTION、ECID、CLIENT_ID、CLIENT_INFO)状態を含む。

  • アプリケーション・コンティニュイティを使用してフェイルオーバーさせるデータベース・ユーザーに、アプリケーション・コンティニュイティ・パッケージの権限(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用として予約されています。

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

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

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

関連項目:

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

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

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

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

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

この項のトピックは、リクエストの開始時にのみ状態を設定するアプリケーションや、事前設定された状態で接続を使用することでパフォーマンスが向上するステートフル・アプリケーションに適用されます。

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

FAILOVER_RESTORE

FAILOVER_RESTOREをLEVEL1(手動アプリケーション・コンティニュイティの場合)またはAUTO(透過的アプリケーション・コンティニュイティの場合)に設定すると、リクエストのリプレイ前に一般的な状態の初期設定が自動的にリストアされます。

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

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

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

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

このトピックでは、FAILOVER_RESTOREがLEVEL1または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=AUTOではリストアされないセッション状態

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

  • NLS_COMP
  • CALL_COLLECT_TIME
  • CLIENT_INFO
FAILOVER_RESTORE拡張

Oracle Database 19.5およびOracleクライアント・ドライバ19.5以降では、アプリケーションが共通のクライアント側セッション状態以外のセッション状態を使用する場合、FAILOVER_RESTOREは、リクエストがリプレイされる前にALTER SESSIONで設定したすべてのセッション・パラメータをリストアします。

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

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

この機能を使用するには、FAILOVER_RESTOREをLEVEL1またはAUTOに設定して、ディクショナリ資格証明がシステムで暗号化されるようにする必要があります。

ディクショナリ資格証明の暗号化用にウォレットまたはキーストアを追加する方法は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用の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. ソフトウェア・キーストアを使用するようにデータベースを構成します。

    次のステップは、SYSKM権限を持つオペレータが実行する必要があります。オペレータ・ユーザーにロールSYSKMを付与します。

    1. 必要に応じて、ウォレットを格納するディレクトリを作成します。

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

    2. 静的な初期化パラメータWALLET_ROOTを変更します。
      パラメータの値は、ウォレットが格納されているディレクトリにする必要があります。
      ALTER SYSTEM SET WALLET_ROOT='/myOracleBase/admin/wallet/' SCOPE=spfile;
    3. 初期化パラメータTDE_CONFIGURATIONを変更して、ソフトウェア・キーストアを指定します。
      ALTER SYSTEM SET TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=FILE" SCOPE=BOTH SID='*'
    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はキーストアのパスワードです。パスワードの大文字と小文字は区別されます。キーストアのパスワードはデータベース・ユーザーのパスワードと同じ規則に従います。 

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

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

    
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "password" CONTAINER=all;
ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY IDENTIFIED BY "password" 
WITH BACKUP CONTAINER=all;

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

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

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

    ALTER DATABASE DICTIONARY ENCRYPT CREDENTIALS;

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

警告:

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

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

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

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

  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. 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_HOME\network\adminが使用されます。
    2. 必要に応じて、ウォレットを格納するディレクトリを作成します。

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

    3. SQLNET.ORAファイルを探して編集します。
      前述のサブステップで取得した場所を使用して、sqlnet.oraファイルを編集し、次のエントリを追加します。/myOracleWalletLocは、ウォレットを格納するために作成したディレクトリの完全パス名です。
      ENCRYPTION_WALLET_LOCATION =
  (SOURCE=
   (METHOD=FILE)
    (METHOD_DATA=
     (DIRECTORY=/myOracleWalletLoc)))
    4. 初期化パラメータTDE_CONFIGURATIONを変更して、ソフトウェア・キーストアを指定します。
      ALTER SYSTEM SET TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=FILE" SCOPE=BOTH SID='*'
  4. パスワードを使用してキーストアを作成します(まだキーストアが存在しない場合)。

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

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

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

    
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "password" CONTAINER=all;
ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY IDENTIFIED BY "password" 
WITH BACKUP CONTAINER=all;

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

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

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

    ALTER DATABASE DICTIONARY ENCRYPT CREDENTIALS;

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

警告:

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

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

このシナリオは、Oracle Database 18cより前のデータベースおよびクライアントに適用できますが、アプリケーションはプールからの接続を流用するときに、どのような状態も想定しません。また、初期状態を再確立するためにUCPやWebLogicラベルを使用します。

Oracle Database 18c以降のデータベースおよびクライアントでは、すべてのアプリケーションに対してFAILOVER_RESTOREをLEVEL1またはAUTOに設定することをお薦めします。

接続ラベリング

汎用プール機能である接続ラベリングを使用することをベスト・プラクティスとしてお薦めします。接続ラベリングが存在する場合、アプリケーション・コンティニュイティはこれを使用します。接続ラベリングが状態を再作成するため、FAILOVER_RESTOREをNONEに設定できます。

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

接続初期化コールバック

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

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

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

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

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

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

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

FAILOVER_RETRIES

正の整数ゼロ以上

30

FAILOVER_DELAY

秒数

10

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

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

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

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

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

ポリシー管理データベースの場合:
$ srvctl add service -db mydb -service TACSERVICE -serverpool ora.Srvpool -clbgoal SHORT
  -rlbgoal SERVICE_TIME -failovertype AUTO -failover_restore AUTO -commit_outcome TRUE --replay_init_time 600 
  -retention 86400 -notification TRUE -drain_timeout 300 -stopoption IMMEDIATE
管理者管理データベースの場合:
$ srvctl add service -db mydb -service TACSERVICE -pdb mypdb -preferred inst1 -available inst2 
  -failovertype 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 -serverpool ora.Srvpool -failovertype TRANSACTION 
  -failover_restore LEVEL1 -commit_outcome TRUE -session_state dynamic -replay_init_time 600 -retention 86400 
  -notification TRUE -drain_timeout 300 -stopoption IMMEDIATE

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

$ srvctl add service -db mydb -service ACSERVICE -pdb mypdb -preferred inst1 -available inst2 
  -failovertype TRANSACTION -failover_restore LEVEL1 -commit_outcome TRUE -session_state dynamic -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;
/
計画メンテナンスに対するアプリケーション・コンティニュイティの使用

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

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

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

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

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

    ノート:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

関連トピック

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

繰り返さない自律型トランザクション、外部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のいずれかを使用します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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;
リプレイなしのセッションの終了または切断

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

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

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

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

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

ノート:

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

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

表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;

    ノート:

    • Oracle Database 19c以降、順序のSQLに対して可変を保持するための付与は必要ありません。

    • 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権限を付与する必要があります。このセキュリティ制限により、ユーザーによって所有されていないコードに対するファンクション結果をリプレイのために保存およびリストアできるようになります。

アイデンティティ順序の場合、可変の保持は所有順序でサポートされます。SQLレベルでの可変の保持は、アイデンティティ順序に対して自動的に行われます。アイデンティティ順序のPL/SQLで可変を保持するには、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権限を付与する必要があります。

  • SYSDATEおよびSYSTIMESTAMPまたはSYSGUIDの可変を維持する権限を付与するには:
    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の可変を維持する権限を取り消すには、次のようにします。
    REVOKE [KEEP DATE TIME | KEEP SYSGUID]...[from USER]

親トピック: 可変値の管理

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

親トピック: 可変値の管理

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

これらの考慮事項は、可変関数に対する権限の付与および取消しに適用されます。

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

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

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

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

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

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

親トピック: 可変値の管理

保護レベルの統計

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

アプリケーション・コンティニュイティはシステム、セッション、およびサービスの統計を収集し、これにより、ユーザーは保護レベルを監視できるようになります。統計情報は、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)を使用します。

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

セッション状態一貫性

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

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

手動アプリケーション・コンティニュイティの場合、session_state_consistencyをDYNAMICまたはSTATICに設定できます。アプリケーションを十分確認し、アプリケーションが値設定を変更する必要がない場合、session_state_consistencyをDYNAMICまたはSTATICに設定します。

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

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

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

ノート:

長時間実行するステートレスのアプリケーションの場合、session_state_consistencyをAUTOまたはSTATICに設定します。ステートレスでないアプリケーションの場合、session_state_consistencyをSTATICに設定しないでください。手動アプリケーション・コンティニュイティを必要としない場合、session_state_consistencyをAUTOに設定することをお薦めします。

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

  • 自動的なセッション状態の一貫性
    session_state_consistencyをAUTOに設定した場合、リカバリ可能な停止の後にデータベース・セッションがリカバリできるように、透過的アプリケーション・コンティニュイティはセッションおよびトランザクションの状態を追跡および記録します。session_state_consistencyのAUTOへの設定は、透過的アプリケーション・コンティニュイティでのみ許容されます。
  • 動的なセッション状態の一貫性
    セッション状態の値がFAILOVER_RESTOREまたは初期化コールバックの追加で完全にリストアできない場合、セッションの状態は動的になります。
  • 静的なセッション状態の一貫性
    Staticモードは、長時間実行するステートレスのアプリケーションに使用します。ステートレスではないアプリケーションには、Staticモードを使用しないでください。

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

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

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

AUTOに設定すると、アプリケーションがユーザー・コールを発行するときに、状態追跡インフラストラクチャによりセッション状態の使用状況が分類されます。追跡されるセッション状態は監視および検証されます。

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

セッション状態の値が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. リクエストを終了し、リプレイを無効化します。

最後の文として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. リクエストを終了します。

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

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コールで無効化されます。

関連トピック

親トピック: セッション状態一貫性

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

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

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

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

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

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

ノート:

アプリケーション所有者として、繰り返す必要のない副作用が含まれるリクエストのリプレイを無効にすることを選択できます。副作用を無効にする最も簡単な方法は、透過的アプリケーション・コンティニュイティ(サービス属性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)のコールの発行など)を伴うアプリケーションの場合、アプリケーションが外部アクションのリプレイ(電子メールの再送信、監査、およびファイルの転送など)によって満たされるときに、アプリケーション・コンティニュイティは透過的になります。

19cに対する副作用の許可および禁止

TACの場合は、デフォルトで、リプレイが副作用に対して無効になっています。DBMS_APP_CONT_ADMIN.SET_REPLAY_RULESまたはDBMS_APP_CONT.APPLY_REPLAY_RULEを使用して副作用を許可または禁止します。

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

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

  • TACでサービス全体に対して副作用を許可するには、次のインタフェースを使用します:
    SQL> execute DBMS_APP_CONT_ADMIN.SET_REPLAY_RULES('Service_name',TRUE,dbms_app_cont.side_effects); 
PL/SQL procedure successfully completed.

SQL> execute DBMS_APP_CONT_ADMIN.CHECK_REPLAY_RULES('Service_name'); 
PL/SQL procedure successfully completed. 
ResultSet #1 
TARGETS                     REPLAY
-----------------------     --------------------------------
PL/SQL Side Effects         enabled
Autonomous Transactions     disabled
Database Links              disabled
  • TACで副作用を許可するには、次のインタフェースを使用します:
    begin 
insert into file_tab values (1,'file1.txt');
DBMS_APP_CONT.APPLY_REPLAY_RULE(REPLAYABLE => TRUE, TARGETS => DBMS_APP_CONT.SIDE_EFFECTS);
DBMS_FILE_TRANSFER.COPY_FILE(source_directory_object=>'SOURCEDIR', source_file_name=>'file1.txt', destination_directory_object=>'DGROUP', destination_file_name=>'file1.txt');
commit;
end
  • ACで副作用を禁止するには、次のインタフェースを使用します:
    begin 
insert into file_tab values (1,'file1.txt');
DBMS_APP_CONT.APPLY_REPLAY_RULE(REPLAYABLE => FALSE, TARGETS => DBMS_APP_CONT.SIDE_EFFECTS);
DBMS_FILE_TRANSFER.COPY_FILE(source_directory_object=>'SOURCEDIR', source_file_name=>'file1.txt', destination_directory_object=>'DGROUP', destination_file_name=>'file1.txt');
commit;
end
  • TACのリプレイ可能なインタフェース関数をラップするには、次の文を使用します:
    create or replace procedure mark_replayable as 
begin
DBMS_APP_CONT.APPLY_REPLAY_RULE(REPLAYABLE => TRUE, TARGETS => DBMS_APP_CONT.SIDE_EFFECTS, SCOPE => DBMS_APP_CONT.SCOPE_PARENT);
end mark_replayable;

begin 
insert into file_tab values (1,'file1.txt');
mark_replayable;
DBMS_FILE_TRANSFER.COPY_FILE(source_directory_object=>'SOURCEDIR', source_file_name=>'file1.txt', destination_directory_object=>'DGROUP', destination_file_name=>'file1.txt');
commit;
end

リプレイ可能なインタフェースの自律型トランザクションのユース・ケース

TACでは、自律型トランザクションおよびDBリンクのリプレイもデフォルトで無効になっています。DBMS_APP_CONT_ADMIN.SET_REPLAY_RULESまたはDBMS_APP_CONT.APPLY_REPLAY_RULEを使用して自律型トランザクションおよびDBリンクを許可または禁止します。

  • TACでサービス全体に対して自律型トランザクションを許可するには、次のインタフェースを使用します:
    SQL> execute DBMS_APP_CONT_ADMIN.SET_REPLAY_RULES('Service_name',TRUE,dbms_app_cont.autonomous_transactions);
PL/SQL procedure successfully completed.

SQL> execute DBMS_APP_CONT_ADMIN.CHECK_REPLAY_RULES('Service_name'); 
PL/SQL procedure successfully completed. 
ResultSet #1 
TARGETS                     REPLAY
-----------------------     --------------------------------
PL/SQL Side Effects         disabled
Autonomous Transactions     enabled
Database Links              disabled
  • TACで自律型トランザクションを許可するには、次のインタフェースを使用します:
    create or replace procedure log_update(description VARCHAR2) as 
    PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN 
    INSERT INTO update_history VALUES (description, sysdate);
    COMMIT;
END log_update;  

begin 
DBMS_APP_CONT.APPLY_REPLAY_RULE(REPLAYABLE => TRUE, TARGETS => DBMS_APP_CONT.AUTONOMOUS_TRANSACTIONS);
insert into emp_tab('Andy', 100);
log_update('ID updated for user Andy');
commit;
end
  • ACで自律型トランザクションを禁止するには、次のインタフェースを使用します:
    create or replace procedure log_update(description VARCHAR2) as
    PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
    INSERT INTO update_history VALUES (description, sysdate); 
    COMMIT; 
END log_update;  

begin 
DBMS_APP_CONT.APPLY_REPLAY_RULE(REPLAYABLE => FALSE, TARGETS => DBMS_APP_CONT.AUTONOMOUS_TRANSACTIONS);
insert into emp_tab('Andy', 100);
log_update('ID updated for user Andy');
commit;
end
  • TACでサービス全体に対してDBリンクを許可するには、次のインタフェースを使用します:
    SQL> execute DBMS_APP_CONT_ADMIN.SET_REPLAY_RULES('Service_name',TRUE,dbms_app_cont.database_links); 
PL/SQL procedure successfully completed.

SQL> execute DBMS_APP_CONT_ADMIN.CHECK_REPLAY_RULES('Service_name'); 
PL/SQL procedure successfully completed. 
ResultSet #1 
TARGETS                     REPLAY
-----------------------     --------------------------------
PL/SQL Side Effects         disabled
Autonomous Transactions     disabled
Database Links              enabled
  • TACで現在のコード・ブロックに対してDBリンクを許可するには、次のインタフェースを使用します:
    create database link dblink connect to scott identified by tiger using 'dblink_service';
begin
DBMS_APP_CONT.APPLY_REPLAY_RULE(REPLAYABLE => TRUE, TARGETS => DBMS_APP_CONT.DATABASE_LINKS);
select emp_id,emp_name from emp@dblink_servie;
commit;
end
  • ACで現在のコード・ブロックに対してDBリンクを禁止するには、次のインタフェースを使用します:
    create database link dblink connect to scott identified by tiger using 'dblink_service';
begin
DBMS_APP_CONT.APPLY_REPLAY_RULE(REPLAYABLE => FALSE, TARGETS => DBMS_APP_CONT.DATABASE_LINKS);
select emp_id,emp_name from emp@dblink_service;
commit;
end

関連トピック

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

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

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

アプリケーション・コンティニュイティは次のものを除外します。
  • JDBC OCIドライバ(タイプ2)
  • ODP.NET管理対象ドライバ
  • OLE DB
  • ODBC
  • OCCI
  • Pro*プリコンパイラ(Proc*C、Pro*COBOL、Pro*FORTRANなど)

ノート:

計画メンテナンスにこれらのリソースが必要な場合、XAまたはTAF Plusを使用するときは、いずれかの接続テストを使用して排出することを検討してください。

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

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

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

トランザクションのリプレイが発生する可能性があるときに、次の制限事項が関連する点に注意してください。

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

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

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

  • リプレイは、セッションを再構築するのに安全でないとみなされているALTER SESSION文のリクエスト・レベルでは無効化されています。これには、サポート・レベルのイベントを設定する文が含まれ、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 Active Data Guardを使用している場合、リプレイはサポートされません。これはトランザクション・ガードのセキュリティ制限です。

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

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

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

ノート:

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

関連トピック

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

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

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

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

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

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は、トランザクション・ガードを使用した冪等性を持つリプレイを実現できます。

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

関連トピック

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

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

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

  • 次のように、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サービス・パラメータの値を設定します。

  • Oracle RAC、Oracle Data GuardまたはOracle Active Data Guardを使用している場合は、停止を迅速に通知するためにFANを使用することをお薦めします。

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

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

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

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

関連トピック

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

透過的アプリケーション・フェイルオーバーによるOCIクライアントのフェイルオーバー

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

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

TAFでは、フェイルオーバーが完了すると問合せは再開できますが、INSERT、UPDATE、DELETEなどの他のトランザクションの場合、アプリケーションで、失敗したトランザクションをロールバックして再度送信する必要があります。FAILOVER_RESTOREをLEVEL1またはAUTOに設定しなかった場合は、フェイルオーバーの発生後、セッションのカスタマイズ、つまり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は自動的に一般的な状態をリストアします。これにより、ほとんどのアプリケーションでコールバックの必要がなくなります。

関連トピック

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

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

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

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

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

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

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

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

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

関連トピック

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

Oracle Database 19c用のACCHKビューおよびロールの作成

Oracle Database 19cでアプリケーション・コンティニュイティ保護チェック(ACCHK)を初めて使用する前に、PDBでACCHKビューおよびロールを手動で作成する必要があります。

  1. SQL*Plusを使用して、Oracleプラガブル・データベース(PDB)に接続します。
  2. dbms_app_cont_admin.acchk_viewsプロシージャを使用して、PDB用のアプリケーション・コンティニュイティ保護チェック・ビューおよびロールを作成します。
    SQL> execute dbms_app_cont_admin.acchk_views;

    前述のプロシージャにより、ACCHKで使用されるビューおよびロールが作成されます。ビューおよびロールがすでに存在する場合でも、このプロシージャを安全に繰り返すことができます。

    ノート:

    COMPATIBLEパラメータを12.2.0以上に設定します。以前にCOMPATIBLEパラメータが低い値に設定されていた場合、COMPATIBLEパラメータの更新後に初めてプロシージャを実行すると、acchk_viewsプロシージャによって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パラメータを12.2.0以上に設定します。以前に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ユーティリティは、事前に生成されたデータベース・トレースを使用してアプリケーション・コンティニュイティ・カバレッジをレポートする後処理ツールです。ワークロードを実行してレポートを生成する前に、アプリケーション・コンティニュイティのトレースおよびアプリケーション・コンティニュイティ保護チェックを有効にします。
  1. アプリケーションのACCHKおよびトレースを有効にした後、一連のデータベース・オプションを実行します。
    ACCHKは、アプリケーション・コンティニュイティ・セッションのレポートのみを生成します。
  2. dbms_app_cont_report.acchk_reportプロシージャを使用して、アプリケーション・コンティニュイティ保護チェック・レポートを生成します。
    SQL> SET SERVEROUTPUT ON FORMAT WRAPPED;
SQL> execute dbms_app_cont_report.acchk_report;
    レポートのタイプは、FULL、WARNINGまたはSUMMARYから指定できます。たとえば:
    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-3 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-4 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-5 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-6 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
次の統計を使用して、アプリケーションの保護を監視することもできます。
  • cumulative begin requests
  • cumulative end requests
  • cumulative time in requests
  • cumulative user calls in requests
  • cumulative user calls protected by Application Continuity
  • cumulative DB time in requests
  • cumulative DB time protected in requests

関連トピック

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