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

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

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

• 計画外停止の管理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注意:

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

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

FANの重要性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  注意:

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

  /*+ CLIENT_CONNECTION_VALIDATION */ SELECT 1 FROM DUAL;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

パラメータ	説明
VERSION	イベント・レコードのバージョン。リリースの変更を識別するために使用されます。
database	サービスをサポートする一意のデータベース名。DB_UNIQUE_NAMEの初期化パラメータ値に該当し、これにより、DB_NAME初期化パラメータの値がデフォルトに設定されます。
instance	サービスをサポートするインスタンスの名前。
host	サービスをサポートしているノードまたは停止したノードの名前であり、Cluster Synchronization Services(CSS)で認識されるノード名と一致します。
service	サービス名。DBA_SERVICESでリストされているサービスの名前に一致し、適宜修飾されたドメインです。次の例を参照してください。 SERVICEMEMBER VERSION=1.0 service=swingbench database=orcl instance=orcl_2 host=dev_host1 status=up reason=USER card=1 timestamp=2018-05-29 17:26:37 timezone=-07:00 db_domain= SERVICEMEMBER VERSION=1.0 service=swingbench.example.com database=orcl instance=orcl1 host=dev_host1 status=up reason=USER card=2 timestamp=2018-05-03 17:29:28 timezone=-07:00 db_domain=example.com SERVICEMEMBER VERSION=1.0 service=swingbench.example.com database=orcl instance=orcl2 host=dev_host1 status=up reason=USER card=1 timestamp=2018-07-03 17:29:18 timezone=-07:00 db_domain=example.com
status	値は、UP、DOWN、NODEDOWN(これはNODEイベント・タイプにのみ適用される)、NOT_RESTARTINGおよびUNKNOWNです。 注意: ノードが停止している場合、ステータスはNODEDOWNです。他のイベント・タイプの場合はDOWNです。 STATUS=NODEDOWNおよびREASON=MEMBER_LEAVEの場合、ノードに障害が発生しており、ノードはクラスタの一部ではないか、ユーザーがノードを停止しています。 STATUS=NODEDOWNおよびREASON=PUBLIC_NW_DOWNの場合、ノードは起動していますが、障害またはユーザー・アクションによりパブリック・ネットワークが停止しているため、ノードは使用不可です。 複数のパブリック・ネットワークがOracle Clusterwareでサポートされています。FANイベントでは、この事実が反映されています。
reason	AUTOSTART、BOOT、DEPENDENCY、FAILURE、MEMBER_LEAVE、PUBLIC_NW_DOWN、USER。 注意: DATABASEおよびSERVICEイベント・タイプの場合のREASON=AUTOSTARTは、ノードの起動時に、AUTO_STARTリソース属性がリストアに設定されており、ノードの起動前にリソースがオフラインであったことを示します。 DATABASEおよびSERVICEイベント・タイプの場合のREASON=BOOTは、ノードの起動時に、リソースがノードの起動前からオンラインであったためリソースが起動したことを示します。 SRVCTLおよびOracle Enterprise Manager操作の場合、REASON=USERはそのような操作の計画済アクションを作業の排出として記述します。
card (カーディナリティ)	現在アクティブなサービス・メンバーの数。すべてのSERVICEMEMBER UPイベントに含まれます。 SERVICEMEMBER UPイベントの例を次に示します。 SERVICEMEMBER VERSION=1.0 service=swingbench.example.com database=orcl instance=orcl_2 host=dev_host3 status=up reason=USER card=1 timestamp=2018-07-12 14:46:46 timezone=-07:00 db_domain=example.com
incarn (インカーネーション)	NODEDOWNイベント用の新しいクラスタ・インカネーション。この値は、メンバーがクラスタに参加したり、クラスタから離脱するたびに変更されます。 NODEDOWNイベントの例を次に示します。 VERSION=1.0 event_type=NODE host=dev_host2 incarn=175615351 status=nodedown reason=member_leave timestamp=2019-10-24 05:55:06 timezone=+00:00
timestamp	Oracle Clusterwareに基づく、イベントが発生した時間。
timezone	GMT +/-hh:mmとして指定され、イベントが発生した、Oracle Clusterwareのタイム・ゾーン。
drain_timeout	サービスが排出される秒単位の時間。SERVICEMEMBERイベントで表示されます
vip_ips	停止したパブリック・ネットワーク上のVIP。NODEイベントの一部。 NODEDOWNイベントの例を次に示します。 NODE VERSION=2.0 host=my-exa status=nodedown reason=public_nw_down incarn=0 timestamp=2019-10-24 09:02:35 timezone=+00:00 vip_ips=10.1.1.94

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

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

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

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

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

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=1.0 host=sun880-2 incarn=23 status=nodedown reason=public_nw_down
timestamp=08-Oct-2012 04:02:14 timezone=-08:00 reported=Fri Oct 8 04:02:14 PDT 2012

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

関連項目:

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

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

6.2 計画外停止の管理

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

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

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

注意:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

高速接続フェイルオーバーが構成されたFAN対応プール(OCIセッション・プール、Oracle Universal Connection Pool、Oracle WebLogic Server Active Gridlink for Oracle RAC、ODP.NETなど)を使用すると、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コマンドに、-forceフラグを使用します。-forceフラグは、srvctl relocate serviceまたはsrvctl stop serviceのどちらかを実行するときに、コマンドラインで-stopoptionパラメータを指定した場合に使用する必要があります。次に例を示します。

   $ srvctl relocate service –database mycdb01 –service myservice –drain_timeout 120
     –stopoption IMMEDIATE –oldinst mycdb01_01 -force

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

   注意:

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

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

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

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

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

   データベースの停止オプションとサーバーの停止オプションの相関は次のとおりです。

   • NORMAL=NONE
   • TRANSACTIONAL/TRANSACTIONAL LOCAL=TRANSACTIONAL
   • IMMEDIATE/ABORT=IMMEDIATE

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

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

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

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

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

個別のサービスごとに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停止オプションを使用して停止します。

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

• サービスの開始

• プラガブル・データベース・レベルの操作

• サービスの再配置

• サービスの停止

6.3.2.1 サービスの開始

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

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

次の各例では、サービスの開始方法を説明します。

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

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

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

  $ srvctl start service –db myRACDB

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

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

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

  $ srvctl start service –d myRACDB –node racnode01

6.3.2.2 プラガブル・データベース・レベルの操作

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パラメータはオプションです。プラガブル・データベース名を省略すると、コンテナ・データベース全体(このコンテナ内のすべてのプラガブル・データベース)が操作の対象になります。

6.3.2.3 サービスの再配置

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

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

  $ srvctl relocate service –database myRACCDB –oldinst RACCDB_01 –newinst RACCDB_03
    -drain_timeout 30 -force

  または

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

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

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

  $ srvctl relocate service –database myRACCDB –service "myService01,myService02"
    -drain_timeout 30 -force

  または

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

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

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

6.3.2.4 サービスの停止

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

srvctl stop serviceコマンドには、停止するサービスのリスト(すべてのサービスのサブリスト)を指定することもできます。さらに、-pqパラメータを指定することで、パラレル問合せサービスのみを停止するようにsrvctl stop serviceコマンドを制限することもできます。

次の各例では、サービスの停止方法を説明します。

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

  $ srvctl stop service –db myRACCDB01 –pdb myPDB01 –drain_timeout 15 –stopoption TRANSACTIONAL

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

  $ srvctl stop service –db myRACDB –drain_timeout 15 –stopoption IMMEDIATE

  データベースが提供する一部のサービスのみを停止するには:

  $ srvctl stop service –db myRACDB –service "myFirstService,mySecondService,
    myThirdService" –drain_timeout 60 –stopoption IMMEDIATE

  注意:

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

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

計画メンテナンスの前に、アプリケーションの動作が中断されないように、データベース・インスタンスでデータベースのセッションを排出またはフェイルオーバーします。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接続プールは継続的な可用性を実現し、ロード・バランシングなどを提供することで大きな利点を提供するため、これらの接続プールを使用することをお薦めします。

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

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

デフォルトでは、すべてのデータベース・サービスおよびプラガブル・データベース・サービスに4つのSQL接続テストが追加されています。したがって、アプリケーションが接続で次のSQL接続テストを使用している場合、これらを追加する必要はありません。

SELECT 1 FROM DUAL;
SELECT COUNT(*) FROM DUAL;
SELECT 1;
BEGIN NULL;END;

• サービスにサーバー側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;');

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

様々なアプリケーション・サーバーでテストの名前が類似しています。提供されているテストでは様々なアプローチを使用しており、最も一般的なものは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_session.enable_connection_test(dbms_session.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)))

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

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

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

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

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

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

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

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

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

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

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

リカバリ可能なエラー

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

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

コミット結果

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

可変関数

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

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

セッション状態の一貫性

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

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

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

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

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

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

Oracle RAC 18c以降、透過的アプリケーション・コンティニュイティはアプリケーション・コンティニュイティの機能モードであり、データベース・セッションがリカバリ可能な停止後にリカバリできるように、セッションおよびトランザクションの状態を透過的に追跡および記録します。これは安全に行われ、DBAにアプリケーションの知識もアプリケーション・コードの変更も必要ありません。アプリケーションがユーザー・コールを発行したときに、セッション状態の使用を分類する状態追跡インフラストラクチャを使用することにより、透過性を実現します。

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

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

• 事前設定された状態のリストア

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

• セッションのリカバリ時に、アプリケーションレベルの副作用を認識して無効にします。

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

• 所有されている関数の可変値を保持します。

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

• JDBCシン・ドライバを含むアプリケーション・コンティニュイティを使用するアプリケーションの場合(Oracle Database 18c以降)、DBAは最初のリクエスト境界を設定した後にリクエスト境界を設定する必要はありません。リクエスト境界を挿入できるチェックポイントを必ずしも識別できるわけではないため、リクエスト境界の使用をお薦めします。

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

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

Java (Oracle Database 18c以降)用の透過的アプリケーション・コンティニュイティを使用すると、状態に関係しない文は記録されないため、アプリケーションではリソース使用率が低くなり、リカバリが高速になります。または文は不要になるとパージされ、リクエスト境界は自動的に拡張されます。

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

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

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

透過的アプリケーション・コンティニュイティは、自動的に状態追跡システムによって追跡される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.5 アプリケーション・コンティニュイティの操作および使用

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

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

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

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

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

• 可変値の管理

• 保護レベルの統計

• セッション状態一貫性

6.5.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コマンドを実行する必要はなくなり、影響を受けるすべてのサービスのノード名、データベース名、プラガブル・データベース名、またはインスタンス名を指定することのみが必要になります。

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

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

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

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

• OCIセッション・プール

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

• WebLogic Server

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

• Oracle Tuxedo

• SQL*Plus

• ユニバーサル接続プールを使用したサード・パーティのJDBCアプリケーション・サーバー

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

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

アプリケーション・コンティニュイティのサポートは多くの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. inconsistency値のアプリケーション・スタイルを評価し、サービスに適した値を設定します。

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

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

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

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

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

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

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

   • .NETアプリケーションの場合は、Oracle Database 12c リリース2 (12.2)以降に接続しているODP.NET管理対象外ドライバ12.2以降を使用します。デフォルトでは、この構成でODP.NETアプリケーションのアプリケーション・コンティニュイティが有効化されます。

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

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

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

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

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

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

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

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

     GRANT EXECUTE ON DBMS_APP_CONT TO user_name;

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

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

関連項目:

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

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

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

• Oracle Application Continuityの構成

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

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

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

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

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

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

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

6.5.2.1 Oracle Application Continuityの構成

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

  これは、高可用性の接続を構成するための一般的な推奨事項です。高可用性機能がないEasy Connectは使用しないでください。

  次にTNSエントリの例を示しますこれは、ONS (FANのトランスポート・システム)が自動構成されるようにするための必須のTNSフォーマットです。アプリケーション・コンティニュイティでFANを使用して、高速の停止検出を提供することをお薦めします。

  alias =(DESCRIPTION =
       (CONNECT_TIMEOUT=120) (RETRY_COUNT=20)(RETRY_DELAY=3) (TRANSPORT_CONNECT_TIMEOUT=3)
        (ADDRESS_LIST =
              (LOAD_BALANCE=on)
              ( ADDRESS = (PROTOCOL = TCP)(HOST=primary-scan)(PORT=1521)))
        (ADDRESS_LIST =
              (LOAD_BALANCE=on)
              ( ADDRESS = (PROTOCOL = TCP)(HOST=secondary-scan)(PORT=1521)))
        (CONNECT_DATA=(SERVICE_NAME = gold-cloud)))

6.5.2.2 アプリケーション・コンティニュイティのための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用として予約されています。

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

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

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

関連項目:

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

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

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

• NLS設定

• オプティマイザ設定

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

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

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

• FAILOVER_RESTORE = LEVEL1またはAUTO

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

• 接続ラベリング

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

6.5.2.3.1 FAILOVER_RESTORE = LEVEL1またはAUTO

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

すべてのアプリケーションで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)

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

• NLS_COMP

• CALL_COLLECT_TIME

• CLIENT_INFO

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

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

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

6.5.2.3.3 接続ラベリング

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

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

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

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

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

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

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

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

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

パラメータ名	使用可能な値	デフォルト値
FAILOVER_RETRIES	正の整数ゼロ以上	30
FAILOVER_DELAY	秒数	10

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

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

• 単一インスタンスのデータベースのサービスがアプリケーション・コンティニュイティを使用するように変更する方法

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

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

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

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

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

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

$ srvctl add service -db codedb -service GOLD -preferred serv1 -available serv2 -clbgoal SHORT
  -rlbgoal SERVICE_TIME -failover_restore AUTO -failoverretry 30 -failoverdelay 10
  -commit_outcome TRUE -failovertype AUTO -replay_init_time 1800 -retention 86400
  -notification TRUE

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

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

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

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

$ srvctl add service -db codedb -service GOLD -preferred serv1 -available serv2  -clbgoal SHORT 
  -rlbgoal SERVICE_TIME -failover_restore LEVEL1 -failoverretry 30 -failoverdelay 10 -commit_outcome TRUE
  -failovertype TRANSACTION -replay_init_time 1800 -retention 86400 -notification TRUE

6.5.2.4.2 単一インスタンスのデータベースのサービスがアプリケーション・コンティニュイティを使用するように変更する方法

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

手動アプリケーション・コンティニュイティの場合:

DECLARE
params dbms_service.svc_parameter_array;
BEGIN
params('FAILOVER_TYPE'):='TRANSACTION';
params('REPLAY_INITIATION_TIMEOUT'):=1800;
params('RETENTION_TIMEOUT'):=86400;
params('FAILOVER_DELAY'):=10;
params('FAILOVER_RETRIES'):=30;
params('FAILOVER_RESTORE'):='LEVEL1';
params('commit_outcome'):='true';
params('aq_ha_notifications'):='true';
dbms_service.modify_service('[your service]',params);
END;
/

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

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

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

計画メンテナンスの場合、推奨されるアプローチは、完了していないリクエストについてアプリケーション・コンティニュイティと連携し、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. インスタンスおよびサービスを再起動します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

メイン・トランザクションとは異なる副作用の例には、外部表への書込み、電子メールの送信、PL/SQL (UTL_HTTP、UTL_URL、UTL_FILE、UTL_FILE_TRANSFER、UTL_SMPT、UTL_TCP、UTL_MAIL、DBMS_PIPEまたはDBMS_ALERTへのコールを含む)またはJava (フォームProcess proc = rt.exec(command);でのシェル・スクリプトの実行を含む)からのセッションの分岐、ファイルの転送、および外部URLへのアクセスなどがあります。このようなアクションの結果、永続的な副作用が残ります。PL/SQLメッセージングおよびJavaコールアウトの結果、永続的な結果が残される可能性があります。たとえば、ユーザーがコミットせずに作業の途中で席を離れてセッションがタイムアウトするか、ユーザーが[Ctrl]を押しながら[C]を押すと、フォアグラウンドまたはコンポーネントが失敗します。メイン・トランザクションがロールバックし、その間に副作用が適用されることがあります。(副作用の詳細は、「アプリケーション・コンティニュイティの潜在的な副作用」を参照してください。)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

例

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

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

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

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

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

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

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

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

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

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

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

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

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

注意:

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

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

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

可変関数	製品1	製品2	製品3
SYSDATE、SYSTIMESTAMP	オリジナル	オリジナル	現行
順序NEXTVALおよびCURRVAL	オリジナル	オリジナル	(該当なし)
SYS_GUID	オリジナル	(該当なし)	(該当なし)

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

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

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

  注意:

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

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

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

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

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

  注意:

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

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

6.5.4 可変値の管理

可変値を管理するには、特定の権限を付与する必要があります。

6.5.4.1 可変に対する権限の維持の付与および取消し

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

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

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

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

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

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

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

• 順序の所有者としての権限を付与するには、次のようにします。

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

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

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

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

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

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

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

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

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

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

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

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

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

6.5.5 保護レベルの統計

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

アプリケーション・コンティニュイティはシステム、セッション、およびサービスの統計を収集し、これにより、ユーザーは保護レベルを監視できるようになります。統計情報は、V$SESSTAT、V$SYSSTATで使用可能です。サービス統計が有効になっている場合、V$SERVICE_STATSでも使用可能です。これらの統計は自動ワークロード・リポジトリに保存され、自動ワークロード・リポジトリ・レポートで使用できます。統計には、次の情報が含まれます。

• 完了リクエスト/秒

• リクエストでのユーザー・コール

• 保護されたユーザー・コール

出力は、次のようなものです。

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)を使用します。

6.5.6 セッション状態の一貫性

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

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に設定することをお薦めします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• PL/SQLサブプログラム

• SYS_CONTEXT

• ALTER SESSION

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

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

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

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

• トランザクションなし

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)のコールの発行など)を伴うアプリケーションの場合、アプリケーションが外部アクションのリプレイ(電子メールの再送信、監査、およびファイルの転送など)によって満たされるときに、アプリケーション・コンティニュイティは透過的になります。

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

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

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

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

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

  • OLE DB

  • ODBC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注意:

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

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

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

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

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

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

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

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

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

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

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

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

• 次のように、GET_LTXID_OUTCOMEを呼び出すアプリケーション・ユーザーに権限を付与します。

  GRANT EXECUTE ON DBMS_APP_CONT to user_name;
  

  注意:

  アプリケーション・コンティニュイティを使用する場合は、この文を実行しないでください。

• 最適なパフォーマンスを実現するためにトランザクション履歴表を特定および定義します。

  トランザクション履歴表(LTXID_HIST)は、Oracle Databaseの作成時またはアップグレード時にデフォルトでSYSAUX表領域に作成されます。最後のパーティションの記憶域を使用して、インスタンスの追加時に新しいパーティションが追加されます。トランザクション履歴表の場所がパフォーマンス上最適でない場合は、別の表領域に移動して、そこでパーティションを作成できます。たとえば、次の文により、FastPaceという名前の表領域にトランザクション履歴表を移動します。

  ALTER TABLE LTXID_TRANS move partition LTXID_TRANS_1 tablespace FastPace
     storage ( initial 10G next 10G minextents 1 maxextents 121 );
  

• -commit_outcomeおよび-retentionサービス・パラメータの値を設定します。

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

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

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

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

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

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

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

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

$ srvctl add service -db crm -service sales -preferred crm_1,crm_2
  -available crm_3,crm_4 -commit_outcome TRUE -retention 86400
  -notification TRUE

srvctl modify serviceコマンドを使用して、既存のサービスをトランザクション・ガード用に構成するように変更することもできます。

注意:

デフォルト・データベース・サービス(db_nameまたはdb_unique_nameの値に名前が設定されているサービス)は使用しないでください。デフォルト・サービスは、管理目的に使用されるものであり、ユーザー作成のサービスと同じプロパティを備えていません。

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

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

接続に透過的アプリケーション・フェイルオーバー(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は自動的に一般的な状態をリストアします。これにより、ほとんどのアプリケーションでコールバックの必要がなくなります。