| Oracle® Database開発ガイド 12c リリース1 (12.1) B71295-06 |
|
 前 |
 次 |
アプリケーション・コンティニュイティは、データベース・セッションを使用不可にするリカバリ可能なエラーの後に、データベースに対するリクエストを中断せず、迅速な方法でリプレイできるようにする機能です。リクエストには、トランザクション処理や非トランザクション処理が含まれる場合があります。リプレイが成功した後、アプリケーションはデータベース・セッションが中断された地点から処理を続行できるため、資金の振替や航空券の予約などに何が起こったかわからない不安な状態にユーザーを陥れることもなく、ログオン・ストームからリカバリするために中間層マシンを再起動する必要もなくなります。アプリケーション・コンティニュイティを使用すると、計画済停止または計画外停止の多くをマスクすることによってエンドユーザーの実績が重ねられ、アプリケーション開発者がリクエストをリカバリする必要性もなくなります。
アプリケーション・コンティニュイティを使用しない場合、次のような理由により、アプリケーションが停止を安全な方法でマスクすることはほとんど不可能です。
入力したデータ、戻されたデータ、および変数がキャッシュされたまま、クライアントの状態が現時点のままになります。
COMMITが発行された場合、COMMITメッセージが永続でなくなります。
紛失したリクエストに対するチェックが保証されないため、チェック後にCOMMITが実行されません。
アプリケーションが処理する必要がある非トランザクション・データベース・セッションの状態が失われます。
リクエストが続行可能である場合、データベースおよびデータベース・セッションが正しい状態である必要があります。
ただし、アプリケーション・コンティニュイティによってこの処理がアプリケーション開発者に代わって実行され、停止の多くが安全な方法でマスクされます。
アプリケーション・コンティニュイティは、マスク可能な停止のマスクを試行することにより、開発者の生産性を向上させます。ただし、次の場合は、従来どおりアプリケーションでエラー処理が行われる必要があります。
無効な入力データなどのリカバリ不能なエラー。(アプリケーション・コンティニュイティはリカバリ可能なエラーにのみ適用されます。)
アプリケーションでの具象クラスの使用などの制限(26.4項「アプリケーション・コンティニュイティに関する制限および他の考慮事項」を参照)がリプレイ時に発生した場合や、リプレイによってクライアントの表示可能な状態を、クライアントが現時点までに決定したと思われる状態にリストアできない場合にリカバリ可能なエラー。
Oracle Database 12cリリース1 (12.1.0.1)で導入されたアプリケーション・コンティニュイティにより、Oracleデータベースを使用するシステムおよびアプリケーションのフォルト・トレランスが強化されます。
現在、この章の目的上、アプリケーション・コンティニュイティという用語と、Java用のアプリケーション・コンティニュイティという名前の機能は同義です。
この章では、Oracle WebLogic Server、Oracle RACまたはOracle Active Data Guard (Oracle ADG)など、アプリケーション・コンティニュイティを使用するテクノロジまたは製品環境に関連する主な概念や技術をよく理解していることを前提としています。
内容は次のとおりです。
アプリケーション・コンティニュイティは、データベース・セッション(すべての状態、カーソル、変数、および存在する場合は最後のトランザクションを含むフル・セッション)をリストアすることにより、アプリケーションおよびユーザーからリカバリ可能なデータベースの停止の多くをマスクしようとします(リプレイが成功した場合)。
アプリケーション・コンティニュイティは、計画外停止または計画済停止(タイムアウト、ネットワーク停止、インスタンス障害、修復、構成変更、パッチ適用など)が原因で使用不可になったデータベースおよびデータベース・セッションにアプリケーションがアクセスしようとする際に発生する問題に対処します。アプリケーション・コンティニュイティが使用されていない場合、データベースのリカバリによってアプリケーションおよびエンドユーザーに対して停止がマスクされません。このような場合、開発者およびエンドユーザーは例外条件に対処する必要が生じ、エンドユーザーは資金の振替、タイムシート、注文、請求書の支払などに何が起こったかわからないままになる可能性があります。コミットされていないデータの画面が消失し、ログインしなおしてデータの再入力が必要な場合もあります。最悪の場合、ログイン・ストームからリカバリするために管理者が中間層を再起動せざるを得ない可能性があります。
アプリケーション・コンティニュイティを使用すると、データベース・セッションが使用不可になった場合、アプリケーション・コンティニュイティは正しい状態を使用してセッションおよび任意のオープン・トランザクションを再構築しようとします。トランザクションが成功し、再実行する必要がない場合は、正常に戻ったステータスをアプリケーションに戻す必要があります。リプレイが成功した場合、重複のリスクなく、リクエストを安全に続行できます。アプリケーションですでに処理しており、決定したと思われるデータをリプレイによってリストアできない場合、データベースはリプレイを拒否し、アプリケーションは元のエラーを受け取ります。
アプリケーション・コンティニュイティは、進行中のトランザクションおよびデータベース・セッション状態のリカバリを実行しながら、トランザクション・ガードによって実現されるトランザクションの冪等性を確保します。各データベース・セッションには論理トランザクションID (LTXID)がタグ付けられているため、データベースは、リプレイごとにトランザクションがコミットされたかどうかのみでなく、トランザクションがコミットされた場合は処理が完了まで実行されたかどうかも識別します。アプリケーション・コンティニュイティがリプレイしようとしている間、アプリケーションはリプレイを遅延実行として認識するか、元のトランザクションに対するコミット・レスポンスを受け取ります(最後のトランザクションが停止前に完了していた場合)。
アプリケーション・コンティニュイティは、Oracle Real Application Clusters (Oracle RAC)、Data Guard、Active Data GuardおよびWebLogic Serverと、JDBCシン・ドライバまたはユニバーサル接続プールとの組合せに対してサポートされています。これは、統合されていないデータベースと統合されたデータベースの両方についてサポートされます(PDBレベルでの統合されたデータベースのフェイルオーバーを含む)。(現在、Golden Gate、ロジカル・スタンバイ、またはDMLリダイレクト(Active Data Guardを使用する場合)に対してはサポートされていません。)アプリケーション・コンティニュイティは、多くのOracleテクノロジのユーザーにメリットをもたらすOracle Databaseの機能とみなすことができます。
内容は次のとおりです。
|
参照: Oracle RACでのトランザクション・ガードおよびアプリケーション・コンティニュイティの詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください |
この項では、アプリケーション・コンティニュイティを使用するために理解する必要があるいくつかの用語や概念について説明します。これらの用語はこの章を通じて使用します。
リクエスト
リクエストは、アプリケーションから発行される作業ユニットです。一般的には、これは、単一のデータベース接続上の単一のWebリクエストのSQLとPL/SQL、および他のデータベース・コールに相当し、通常、接続プールのデータベース接続をチェックアウトおよびチェックインするために実行されるコールによって区別されます。リカバリ可能なエラーの場合、アプリケーション・コンティニュイティは、データベース・セッションの対話状態を再確立し、リクエストを繰り返します。
リカバリ可能なエラー
リカバリ可能なエラーは、実行されているアプリケーション・セッション・ロジックとは関係なく、外部システム障害が原因で発生するエラーです。リカバリ可能なエラーは、フォアグラウンド、ネットワーク、ノード、記憶域、データベースの計画済停止および計画外停止に続いて発生するエラーです。アプリケーションは、最後に発行された操作のステータスを把握しないままの状態で残される可能性があるエラー・コードを受信します。アプリケーション・コンティニュイティは、データベース・セッションを再確立し、リカバリ可能なエラーのクラスに対して保留されている作業を再発行します。
アプリケーション・コンティニュイティは、リカバリ不能なエラーが原因であるコール障害に続く作業は再発行しません。リプレイされないリカバリ不能なエラーの例には、無効なデータ値の発行があります。
コミット結果
トランザクションは、トランザクション表内のエントリを更新することによってコミットされます。Oracle Databaseは、この更新に対応するREDOログ・レコードを生成し、このREDOログ・レコードを書き出します。このREDOログ・レコードがディスク上のREDOログに書き出されると、トランザクションはデータベースでコミットされたとみなされます。クライアントの観点からは、REDOが書き込まれた後に生成されたOracleメッセージ(コミット結果と呼ばれます)をクライアントが受信した時点でトランザクションはコミットされたとみなされます。ただし、コミット・メッセージは永続ではありません。(トランザクション・ガード (第25章を参照)は、失われている場合に入手可能なコミット結果を取得します。)
可変オブジェクト
可変オブジェクトは、コールされるたびに新しい値を取得できる非DETERMINISTICファンクションです。このため結果は頻繁に変化します。可変オブジェクトを使用すると、結果がリプレイ時に変化することがあるため、リプレイの問題が発生します。キー値でしばしば使用されるsequence.NEXTVALおよびSYSDATEについて検討してください。主キーがこれらのファンクション・コールの値を使用して構築され、後で外部キーまたは他のバインドで使用される場合、リプレイ時に同じファンクション結果が戻される必要があります。
アプリケーション・コンティニュイティは、付与されているOracleファンクション・コールに対してリプレイ時に可変オブジェクト値の置換を提供することにより、不透明バインド変数の一貫性を実現します。不変のデータベース・ファンクション(sequence.NEXTVAL、SYSDATE、SYSTIMESTAMPおよびSYSGUIDを含む)がコールに使用される場合、ファンクションの実行から戻される元の値が保存され、リプレイ時に再適用されます。
セッション状態の一貫性
COMMIT文が実行された後、このトランザクションで状態が変更された場合、セッションが失われたときにトランザクションをリプレイしてこの状態を再確立することはできません。アプリケーション・コンティニュイティの構成時には、初期設定後のセッション状態が静的と動的のどちらであるか、さらにリクエスト内のCOMMIT操作後の処理続行が正しいかどうかに応じて、アプリケーションは分類されます。
セッション状態の変更が初期化によって完全にカプセル化されておらず、フェイルオーバー時にコールバックに完全に取り込むことができない場合、セッションの状態は動的です。最初のトランザクションが完了した後、フェイルオーバーは次のリクエストが開始されるまでは内部的に無効化されます。
セッション状態の変更(NLS設定やPL/SQLパッケージ状態など)がすべて初期化の一環として行われ、フェイルオーバー時にコールバックにカプセル化できる場合、セッションの状態は静的です。
この項では、アプリケーション・コンティニュイティの動作、およびアプリケーション・コンティニュイティをアプリケーションで使用する方法について説明します。
内容は次のとおりです。
リカバリ可能なエラーが発生したときに、リプレイが有効である場合、データベース・セッションのリカバリが試行されます。アプリケーション・コンティニュイティは、図26-1に示すように、主な手順を実行します。主な手順は計画外停止と計画済停止の両方に適用されますが、特定の手順は停止のタイプによって異なります。(たとえば、26.2.2.6項「計画済停止に対するアプリケーション・コンティニュイティの使用」で説明するように、計画済停止の場合、さらなる最適化が可能です。)
図26-1に例を示します。
クライアント・アプリケーションがリクエストを発行し、これがJDBCリプレイ・ドライバを使用して中間層(JDBC Thinドライバ、ユニバーサル接続プール、WebLogic Serverまたはサード・パーティ・プールなど)に渡されるかデータベースに直接渡されます。
JDBCリプレイ・ドライバがリクエスト内の各コールを発行します。
FAN計画外停止または計画済停止による中断またはリカバリ可能なエラーが発生します。FAN/FCFがデッド状態の物理セッションを中断します。
アプリケーション・コンティニュイティがリプレイを開始し、次を実行します。
後でリプレイ中またはリプレイ後にエラーが発生する場合に備えて、デッド状態の物理セッションを新しいクリーン・セッションに置き換え、FANを書き換えます。
トランザクション・ガードを使用して進行中のトランザクションがオープンであった場合の結果を確認することにより、リプレイを準備します。
必要に応じて、初期状態に対するラベリング・コールバックまたは再接続コールバックを使用してコールバックします。
トランザクション状態および非トランザクション状態をリカバリし、クライアント・ドライバによって確認されたデータおよびメッセージが、クライアントが確認して決定した可能性があったものと同じであることを手順ごとに検証し、データベース・セッションを再構築します。
リプレイを終了し、ランタイム・モードに戻ります。
最後にキューに入れられたコールを発行します。
これは、停止が検出されたときに実行された最後のコールです。リプレイ時には、このコールのみがCOMMITを実行できます。セッションの再構築の途中でCOMMITが行われると、リプレイは中断されます(自律型トランザクションは除く)。
レスポンスがアプリケーションに戻されます。
リプレイが成功した場合、アプリケーションは問題をマスクした状態で続行できます。失敗した場合、アプリケーションは元のエラーを処理する必要があります。
通信障害後のアプリケーション・コンティニュイティの動作は、関連するOracle製品およびテクノロジによって異なります。次に例を示します。
Oracle Real Application ClustersまたはActive Data Guardファームを使用している場合、実行中の別のインスタンスで接続インスタンスが再確立された後、アプリケーション・コンティニュイティはセッションを再構築し、最後のトランザクション(進行中のものがある場合)をリプレイしようとします。
Oracle Data Guardを使用し、スタンバイ・サイトにフェイルオーバーする場合、アプリケーション・コンティニュイティはフェイルオーバー・インスタンスに接続し、セッションを再構築し、最後のトランザクション(トランザクションが進行中であった場合)をリプレイしようとします。(Data Guardスイッチオーバーおよびフェイルオーバーによってデータが失われ、これがラグが承認されたActive Data Guardリーダー・ファームでない場合、アプリケーション・コンティニュイティはリプレイしません。)
Oracle RACまたはOracle RAC Oneを使用しており、Data Guardは使用していない場合、停止が原因ですべてのパブリック・ネットワークが中断されるか、データベースまたはデータベース・セッションがしばらくの間停止すると、アプリケーション・コンティニュイティは、セッションを再構築し、接続がリストアされた後にデータベースに対して最後のトランザクション(トランザクションが進行中であった場合)をリプレイしようとします。
Java用のアプリケーション・コンティニュイティは、次のOracleテクノロジを使用した一般的な用途で使用できます。
JDBC Thin Oracleリプレイ・ドライバ
Universal Connection Pool
WebLogic Server
WebLogic Server 12.1.2以降、WebLogic Serverアプリケーションはアプリケーション・コンティニュイティを使用できるようになりました。アクティブなGridLinkデータ・ソースによって、ユーザーはアプリケーション・コンティニュイティを利用しやすくなりました。
Java用のアプリケーション・コンティニュイティの主なメリットの1つに、アプリケーションの変更がほとんどないか一切ない場合にOracleスタックを使用する際に多くの停止をマスクできる機能があります。アプリケーションは、Java用のアプリケーション・コンティニュイティとともにリリースする前にリプレイに適していることを検証およびテストする必要があります。なんらかのアクションを実行する必要がある場合、ほとんどのケースでは、コア・アプリケーションのソース・コードの変更は必要なく、構成を変更したり、任意のコード・モジュールのリプレイを無効化するコールバックを指定することが必要になります。
Java用のアプリケーション・コンティニュイティ・ソリューションは、Oracle Universal Connection Pool (UCP)およびOracle WebLogic Serverと汎用データ・ソースに埋め込まれています。Oracle接続プールを使用する場合、リクエスト境界は、各リプレイのサイズを定めるチェックアウトおよびチェックイン時に暗黙的にマークされます。ただし、Oracle JDBC Thinとともにサード・パーティの接続プールを使用しているか、UCPまたはWebLogic Serverを使用しているが接続をプールに戻さない場合、Java用のアプリケーション・コンティニュイティのメリットを享受するためのアクションの実行が必要な場合があります。
アプリケーション・コンティニュイティのサポートは多くのOracleアプリケーションに統合されているため、アプリケーション・コンティニュイティに関連するサービス属性を設定する場合、それらのアプリケーションの機能は自動的に使用されます。ただし、独自のアプリケーションの場合は、この項で説明する手順も実行する必要があります。
アプリケーションを自動的に継続できるようにするための主なアクションは、次のとおりです。
アプリケーションがOracle JDBCの具象クラスを使用するかどうか判別します。アプリケーション・コンティニュイティを使用するには、非推奨の具象クラスを置換する必要があります。非推奨の具象クラスの詳細(アプリケーションがこれらを使用する場合に実行するアクションを含む)は、My Oracle Supportノート1364193.1 (https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1364193.1)を参照してください。
必要なCPUおよびメモリー・リソースがあることを確認します。
CPU: アプリケーション・コンティニュイティは、クライアント側とサーバー側で管理され、作動するために追加のCPUが必要です。
クライアントでは、プロキシ・オブジェクトの構築とガベージ・コレクション(GC)のためにCPUが使用されます。
サーバーでは、CPUは検証のために使用されます。CPUオーバーヘッドは、検証がハードウェアによって補佐されている、現在のIntelおよびSparcチップを使用したプラットフォームでは減少します。
メモリー: 呼出しがリクエストの最後まで保持されるため、リプレイ・ドライバにはベース・ドライバよりも多くのメモリーが必要です。リクエストの最後で、呼出しはガベージ・コレクタに解放されます。この処理は、クローズされた呼出しを解放するベース・ドライバによって異なります。
リプレイ・ドライバのメモリー消費量は、リクエストごとのコール数によって異なります。この数が小さい場合、リプレイ・ドライバのメモリー消費量は少なくなり、ベース・ドライバと同程度になります。
最良のパフォーマンスを実現するには、サーバー上で-Xmxおよび-Xmsパラメータの両方に対して同じ値を設定する必要があります。たとえば、十分なメモリーがある場合、仮想マシン(VM)に4から8GB (以上)を割り当てます。たとえば、4GBであれば-Xms4gと設定します。-Xmsパラメータがこれより低い値に設定されている場合、VMもオペレーティング・システムから低い値を使用するため、パフォーマンスが悪化する可能性があり、ガベージ・コレクション操作が増加します。
各リクエストに対してアプリケーションがWebLogic Server PoolまたはUniversal Connection Poolから接続を流用してから返しているかどうか、またはリクエスト境界を識別するためにbeginRequestおよびendRequest APIをアプリケーション固有の接続プールに追加するかどうかを判別します。
(beginRequestおよびendRequestはリクエスト境界以外の場所では使用しないでください(チェックイン)。endRequestは、リクエストが完了しており現在はステートレスであることを示します。次のbeginRequestからリプレイが開始されます。前の状態が存在する場合、これをコールバックで再確立する必要があります。)
接続の初期化に、オプションのコールバックを使用するかどうかを判別します。Oracle WebLogic ServerまたはUniversal Connection Poolの使用時は、接続ラベリングが推奨されます。ラベリングはランタイムとリプレイの両方で使用されます。
アプリケーションがフェイルオーバー時にSYSDATE、SYSTIMESTAMPおよびSYS_GUIDとその順序を必要とするか、さらにこれらの元の値の維持構成を行う必要があるかどうかを判別します(26.2.3項「可変オブジェクトとアプリケーション・コンティニュイティ」を参照)。
session_state_consistency値のアプリケーション・スタイルを評価し、サービスに適した値を設定します。
session_state_consistencyがDynamicである場合、アプリケーションは、リクエスト時に環境または設定を変更します。リプレイは、最初のCOMMITの後、リプレイAPIの最後がコールされるまで無効化されます。デフォルトのモードはDynamicであり、ほとんどのアプリケーションに適しています。
session_state_consistencyがStaticである場合、アプリケーションは、初期設定後にセッション状態を変更しません。このモードは、PL/SQL状態を使用せずにトランザクションの途中でALTERを使用しない、データベースに依存しないアプリケーションの基本的なモードです。このモードは静的アプリケーションに対してのみ、慎重に使用してください。
詳細は、26.2.4項「セッション状態の一貫性」および26.2.4.2項「静的なセッション状態の一貫性」を参照してください。
コード・パスに対してリプレイを明示的に無効にする必要があるかどうかを判別します。
たとえば、外部PL/SQLアクションを使用してリクエストに対してリプレイを無効化する必要がある場合があります(26.2.2.8項「Java用のアプリケーション・コンティニュイティでのリプレイの無効化」を参照)。
次の構成のガイドラインに従ってください。
Oracle Database 12cリリース1 (12.1.0.1)以降を使用します。
JDBC Replayデータソースに対して構成されたユニバーサル接続プール12.1 (以上)またはWebLogic Server 12.1.2 (以上)を使用します。または、サード・パーティ・アプリケーション(サード・パーティJDBCプールなど)の場合はJDBCリプレイ・ドライバを使用します。
カスタムJavaプールおよびスタンドアロンJavaアプリケーションは、JDBC Replayデータソースを直接使用できます。カスタムJavaプールおよびスタンドアロン・アプリケーションを使用する場合、beginRequestおよびendRequestコールを追加します。
アプリケーションがOracle接続プールからの接続の流用および戻しを行わない場合は、明示的にリクエスト境界をマークしてください。たとえば、カスタムJDBCプール、WebSphere、TomCat、JBOSSまたは他のプールを使用する場合、beginRequestをチェックアウト時にコールし、endRequestをチェックイン時にコールします。これらのAPIは、接続プールのないスタンドアロンJDBCアプリケーションに対しても使用できます。
WebLogicデータソースまたはUCPまたはサード・パーティ・プールからFAN/FCFを使用した単一プールを使用します。
データベース・サービスを使用して接続します。SIDまたはインスタンス名は使用しません。
新規着信接続に対する再試行およびこれらの再試行間の遅延を設定する接続文字列を使用します。
サービスについて、FAILOVER_TYPEをTRANSACTION、COMMIT_OUTCOMEをTRUE,、およびNotificationをTRUEに設定します。必要に応じて、使用に適した接続を探す場合は、GOALをSERVICE_TIME、およびCLB_GoalをShortに設定します。
内容は次のとおりです。
|
参照:
|
アプリケーション・コンティニュイティは、標準JDBCを使用するJ2EEアプリケーションおよびOracle接続プール(UCPまたはWLS)を使用するJ2EEアプリケーションに対して透過的です(自動的に実行されます)。外部アクション(自律型トランザクション、またはUTL_HTTPを使用したSOAコールを発行するトランザクションの使用など)のあるアプリケーションの場合、障害後にこれらの外部アクションがリプレイされるときにアプリケーションの正確性が保持されている場合、アプリケーション・コンティニュイティは透過的のままです。
アプリケーション・コンティニュイティが透過的ではない他のシナリオの場合、次のようなインフラストラクチャの変更が必要な可能性があります。
接続プールまたはコンテナがOracle接続プールを使用しない場合、アプリケーションはアプリケーション・コンティニュイティAPIを使用してリクエスト境界をマークする必要があります。リクエスト境界は、コールの保持に使用するメモリーを再利用したり、リプレイ不能な操作の後に記録を再開するポイントを確立するために必要です。
繰り返す必要のないリクエストがアプリケーションにある場合、アプリケーションはこれらのリクエストのリプレイを無効にするAPIを明示的に呼び出すことができます。このようなコールは、アプリケーション・コードの1つまたは複数の部分に分離される可能性があります。
oracle.jdbc.replay.OracleDataSourceImplデータソースを使用してJDBC接続を取得する必要があります。このデータソースは、すべてのOracle JDBCデータソース(oracle.jdbc.pool.OracleDataSourceなど)のプロパティおよび構成パラメータをすべてサポートしています。
接続URLの使用時には次の点に注意する必要があります。
データベースのREMOTE_LISTENER設定がクライアントのADDRESS_LISTのアドレスと一致しない場合、接続は行われず、「サービスが見つかりません」と表示されます。このため、データベースのREMOTE_LISTENER設定はクライアントのADDRESS_LIST内のアドレスと一致する必要があります。
REMOTE_LISTENERがSCAN名に設定されている場合、ADDRESS_LISTはSCAN VIPを使用する必要があります。
接続文字列がSCAN名を使用する場合、REMOTE_LISTENERSにSCAN名を設定する必要があります。
接続文字列がホストVIPのADDRESS_LISTを使用する場合、REMOTE_LISTENERSにすべてのSCAN VIPとすべてのホストVIPを含むアドレス・リストを設定する必要があります。
|
注意: SCANを使用する目的は、場所に依存しないことにあります。ノードが追加または削除された場合や、データベースが別のノードで稼働するよう変更された場合、クライアントを再構成する必要がありません。 |
接続文字列にRETRY_COUNT、CONNECT_TIMEOUTおよびTRANSPORT_CONNECT_TIMEOUTパラメータを設定します。Oracle Database 11gリリース2 (11.2.0.2)以降にJDBC Thinドライバ接続を構成する場合、この作業を実行することをお薦めします。これらの設定により、ランタイム時、リプレイ時、および計画済停止の作業排出時に新規接続の取得効率が向上します。
CONNECT_TIMEOUTは、sqlnet.oraファイル内のSQLNET.OUTBOUND_CONNECT_TIMEOUTパラメータと等価であり、完全接続に適用されます。TRANSPORT_CONNECT_TIMEOUTパラメータはADDRESSパラメータによって判断されます。サービスがフェイルオーバーまたは再起動に対して登録されていない場合、SCANを使用する際に再試行が重要になります。(簡易接続の使用はお薦めしません。これは、簡易接続はRETRY_COUNT、CONNECT_TIMEOUTおよびTRANSPORT_CONNECT_TIMEOUTパラメータをサポートしていないためです。)
接続文字列がホストVIPを使用する場合、REMOTE_LISTENERSはホストVIPを含む必要があります。接続文字列がSCAN名を使用する場合、REMOTE_LISTENERSはSCAN名に設定するか、SCAN VIPとホストVIPを含む必要があります。つまり、REMOTE_LISTENERSにSCAN名を設定する必要があるのは、クライアントが接続文字列でホストVIPを使用しない場合です。使用する場合は、REMOTE_LISTENERSには、すべてのSCAN VIPとすべてのホストVIPのADDRESS_LISTを設定する必要があります。
|
参照:
|
Java用のアプリケーション・コンティニュイティを使用するには、Oracle Database構成に次が含まれている必要があります。
Oracle Real Application Clusters (Oracle RAC)、Oracle RAC One、Oracle Data GuardまたはOracle Active Data Guardを使用している場合、Oracle WebLogic ServerまたはUniversal Connection Pool (UCP)と通信するためにOracle Notification System (ONS)とともにFANが構成されていることを確認します
リプレイおよびロード・バランシングに必要なプロパティをサービスに設定します。たとえば、次を設定します。
FAILOVER_TYPE = TRANSACTION: アプリケーション・コンティニュイティを使用します
REPLAY_INITIATION_TIMEOUT = n: リプレイを開始できる期間(秒)を設定します(nには、必要に応じて60、300、900、1800などを指定できます)。
FAILOVER_RETRIES = 30: リプレイごとに接続の再試行回数を指定します
FAILOVER_DELAY = 10: 接続の再試行間の遅延時間を秒単位で設定します
GOAL = SERVICE_TIME: Oracle RACまたはOracle GDS (Global Data Services)を使用している場合、これが推奨設定です
CLB_GOAL = SHORT: Oracle RACまたはOracle GDSを使用している場合、これが推奨設定です
データベース・サービス(つまり、DB_NAMEまたはDB_UNIQUE_NAMEに対応するデフォルトのサービス)は使用しないでください。高可用性を実現するために、データベース・サービスは使用しないことをお薦めします。このサービスは有効化および無効化できず、また、Oracle RACで再配置したりOracle Data Guardに切り替えることができません。このサービスは、Oracle Enterprise Manager Cloud Control (Cloud Control)およびDBA用として予約されています。
非トランザクション・セッション状態(NTSS)は、データベース・トランザクションの外部に存在し、リカバリによって保護されないデータベース・セッションの状態です。ステートフル・リクエストを使用するアプリケーションの場合、非トランザクション状態は、セッションがアプリケーション・コンティニュイティによって再構築される際に再確立されます。
リクエストの開始時のみ状態を設定するアプリケーションや、事前設定された状態で接続を使用することからパフォーマンス上のメリットを得るステートフル・アプリケーションの場合、次のコールバック・オプションの1つを選択します。
このシナリオの場合、アプリケーションは各リクエスト時に独自の状態を構築します。
接続ラベリングは、パフォーマンスに優れることから推奨される汎用プール機能です。接続ラベリングが存在する場合、アプリケーション・コンティニュイティはこれを使用します。
このシナリオは、Universal Connection Pool (UCP)およびOracle WebLogic Serverに適用できます。接続に事前設定された状態を活用するようアプリケーションを変更できます。接続ラベリングAPIにより、接続の一致状況が判別され、接続が流用される際にコールバックを使用してギャップが移入されます。
|
参照: 『Oracle Universal Connection Pool for JDBC開発者ガイド』 |
このシナリオの場合、リプレイ・ドライバがアプリケーション・コールバックを使用して、ランタイムおよびリプレイ時にセッションの初期状態を設定します。JDBCリプレイ・ドライバには、oracle.jdbc.replay.OracleDataSourceインタフェースで接続初期化コールバックを登録および登録解除するために、オプションの接続初期化コールバックのインタフェースおよびメソッドが用意されています。
接続初期化コールバックは、登録されると、リカバリ可能なエラーの後に成功した再接続ごとに実行されます。アプリケーションは、初期化アクションがフェイルオーバー前の元の接続時のものと同じであることを確認する必要があります。コールバックの起動に失敗した場合、リプレイはその接続で無効化されます。接続初期化コールバックを使用するのは、アプリケーションが接続ラベリング実装していない場合のみにしてください。
デフォルトでは、JDBCリプレイ・ドライバは、フェイルオーバーを開始する際に、サービスが使用可能なインスタンスで進行中の作業をリカバリしようとします。作業をリカバリするために、ドライバはインスタンスとの良好な接続を確立する必要があります。サービスが再配置および発行される前にデータベースまたはインスタンスを再起動する必要がある場合、再接続に時間がかかる場合があります。したがって、サービスが別のインスタンスまたはデータベースから利用可能になるまでに、フェイルオーバーを遅延させる必要があります。
再接続を管理するには、FAILOVER_RETRIESおよびFAILOVER_DELAYパラメータを使用する必要があります。これらのパラメータは計画済停止と連動して使用すると効果があります。たとえば、サービスが数分間使用不可になる可能性がある停止の場合などです。FAILOVER_DELAYおよびFAILOVER_RETRIESパラメータを設定する場合は、REPLAY_INITIAITION_TIMEOUTパラメータの値を最初に確認します。このパラメータのデフォルト値は900秒です。FAILOVER_DELAYパラメータの値を大きくすると、リプレイが取り消される可能性があります。
| パラメータ名 | 使用可能な値 | デフォルト値 |
|---|---|---|
FAILOVER_RETRIES |
正の整数ゼロ以上 | 30 |
FAILOVER_DELAY |
秒単位の時間 | 10 |
次の例は、様々なフェイルオーバー・シナリオを示します。
Oracle RACまたはOracle RAC Oneを使用している場合、SRVCTLコマンドを使用して次の方法でサービスを作成および変更します。
ポリシー管理型のデータベースの場合
srvctl add service -db codedb -service GOLD -serverpool ora.Srvpool -clbgoal SHORT -rlbgoal SERVICE_TIME -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 -failoverretry 30 -failoverdelay 10 -commit_outcome TRUE -failovertype TRANSACTION -replay_init_time 1800 -retention 86400 -notification TRUE
単一インスタンス・データベースを使用している場合、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('commit_outcome'):='true';
params('aq_ha_notifications'):='true';
dbms_service.modify_service('[your service]',params);
end;
/
計画済停止の場合、推奨されるアプローチは、完了していないリクエストについてアプリケーション・コンティニュイティと連携し、Oracle接続プールからリクエストを排出する方法です。パッチが適用されたソフトウェアにスイッチオーバーするには、インスタンスを停止する必要があります。完了する必要があるリカバリが最小限である場合、この方法が最も影響の少ない方法です。
手順は、次のとおりです。
FAN対応プール(OCI、UCP、WebLogic ServerまたはODP.Net)を使用します。
FAN計画イベントの場合、リクエスト境界で排出します。
srvctl relocateを使用して、セッションを中断せずにインスタンスからサービスを再配置するか(-forceフラグなし)、同一のサービスの場合はインスタンスでsrvctl stop serviceを使用します(-forceフラグなし)。
Oracle RAC Oneの場合、relocate databaseを使用します(-forceフラグなし)。
FAN計画イベントはアイドル・セッションを即時にクリアして、アクティブ・セッションをチェックイン時(リクエストの最後)に解放するとマーク付けします。これによって作業を妨げずにセッションがインスタンスから排出されます。
一部のセッションがチェックインしておらず、インスタンスを停止する時間になったら、インスタンスを停止(中断)します。
アプリケーション・コンティニュイティが有効なプール(UCPおよびWLS)、およびJDBC Thinリプレイ・ドライバにbeginRequest/endRequestを追加するプールの場合、アプリケーション・コンティニュイティはその残っているセッションをリカバリしようとします。
インスタンスおよびサービスを再起動します。
実行時ロード・バランシング(がもし有効な場合)では、次のリクエスト境界でリストアされたインスタンスにセッションを戻して均衡化します。
故意の選択、エラーまたは見落としが原因でアプリケーション・コンティニュイティが無効な場合があります。アプリケーション・コンティニュイティは、起動されていない場合や無効化されている場合は有効ではありません。無効化されている場合、endRequestコールを介して無効のままにされます。
サービス・プロパティFAILOVER_TYPEの値がTRANSACTIONに設定されていない場合、アプリケーション・コンティニュイティは起動されません。計画済停止の場合、FAILOVER_TYPEの値を事前にTRANSACTIONに設定します。この設定が新規接続に適用され、既存の接続は元のサービス値のままになります。
次のいずれかに該当する場合、アプリケーション・コンティニュイティは無効になります。
アプリケーション・コンティニュイティに対して制限されている文をアプリケーションが実行します(たとえば、Oracle JDBC具象クラスを使用する場合)。
disableReplayを使用してアプリケーション・コンティニュイティが明示的に無効化されます(26.2.2.8項を参照)。
サービス・パラメータsession_state_consistencyがDynamic (デフォルト)に設定されているときにCOMMIT文が発行されます。
次のbeginRequestが発行されるまでendRequest文が発行されます。
セッションが中断または切断され、NOREPLAYキーワードが指定されます(26.2.2.9項を参照)。
リクエストがALTER SYSTEM文またはALTER DATABASE文を発行します。
デフォルトでは、JDBCリプレイ・ドライバは次のリカバリ可能なエラーをリプレイします。繰り返す必要のないリクエストがアプリケーションにある場合、アプリケーションはこれらのリクエストのリプレイを無効にするAPIを明示的に呼び出すことができます。たとえば、アプリケーションがUTL_SMTPを使用するときにメッセージを繰り返す必要がない場合、無効化する必要があるリクエストに対してdisableReplay APIが効果的です。他のすべてのリクエストは引き続きリプレイされます。
外部アクション(自律型トランザクション、またはUTL_HTTPを使用したSOAコールを発行するトランザクションの使用など)の場合、障害後にこれらの外部アクションがリプレイされるときにアプリケーションの正確性が保持されている場合、アプリケーション・コンティニュイティは透過的のままです。
リプレイに対してアプリケーションを構成する前に検討する必要があるシナリオは、次のとおりです。
自律型トランザクション、外部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]を押すと、フォアグラウンドまたはコンポーネントが失敗します。メイン・トランザクションがロールバックし、その間に副作用が適用されることがあります。(副作用の詳細は、26.3項「アプリケーション・コンティニュイティの潜在的な副作用」を参照してください。)
アプリケーション開発者は、外部アクションに対してリプレイを許可するかどうかを決断する必要があります。この例には、UTL_HTTPを使用したSOAコールの発行、UTL_SMTPを使用したメッセージの送信、またはUTL_URLを使用したWebサイトへのアクセスなどがあります。このような外部アクションのリプレイを回避する必要がある場合は、disableReplay APIを使用します。
COMMIT、ROLLBACKまたはセッションの喪失まで維持される揮発エンティティを使用して、アプリケーションが独立セッションを同期する場合、リプレイ用にアプリケーションを構成しないでください。たとえば、アプリケーションが、複数のデータソースに接続されている複数のセッションを同期化することがあります(同期化されない場合、これらのセッションはデータベース・ロックなどのリソースを使用して相互に依存しています)。アプリケーションでこれらのセッションのみがシリアライズされ、いずれかのセッションが失敗する可能性があることが認識されている場合、このような同期が許容されることがあります。ただし、1つのデータソースによって保持されているロックまたは他の高揮発リソースが、他の接続から同一または別個のデータソースのデータに対する排他的アクセスを実現することをアプリケーションが想定している場合、この想定はリプレイ時に否定される可能性があります。
リプレイ中、ドライバは、ロックまたは他の高揮発リソースを保持している1つのセッションにこれらのセッションが依存していることを認識していません。また、リソース(セマフォ、デバイスまたはソケットなどの)を使用するパイプ、バッファ・キュー、ストアド・プロシージャを使用して、失敗によって失われる同期を実行することもできます。
アプリケーションが実行ロジックの一部として中間層で実時間を使用する場合は、リプレイ用にアプリケーションを構成しないでください。JDBCリプレイ・ドライバは、中間層の時刻ロジックは繰り返さず、このロジックの一部として実行されるデータベース・コールを使用します。たとえば、中間層の時間を使用するアプリケーションが明示的にこれを使用していなければ、時間T1で実行された文が時間T2で再実行されていないと想定することがあります。
アプリケーションがROWIDをキャッシュする場合、データベースが変更されているためにROWIDへのアクセスが無効になることがあります。ROWIDが表内の一意の行を特定しても、次のような状況ではROWIDの値が変更されることがあります。
基礎となる表が再編成されます。
表で索引が作成されます。
基礎となる表がパーティション化されます。
基礎となる表が移行されます。
基礎となる表がEXP/IMP/DULを使用してエクスポートおよびインポートされます。
基礎となる表がGolden Gate、ロジカル・スタンバイまたは他のレプリケーション・テクノロジを使用して再構築されます。
基礎となる表のデータベースがフラッシュバックまたはリストアされます。
一般的に、アプリケーションがROWIDを後で使用するために格納することは好ましくありません。これは、対応する行が存在しなかったり完全に異なるデータが含まれる可能性があるためです。
SYSCONTEXTオプションは、各国語サポート(NLS)設定、ISDBA、CLIENT_IDENTIFIER、MODULEおよびACTIONなどのロケーション非依存セットと、物理ロケータを使用するロケーション依存セットで構成されています。通常、アプリケーションではテスト環境を除いて、物理識別子を使用しません。物理ロケータがメインライン・コードで使用されている場合、リプレイによって不一致が検出され、拒否されます。ただし、コールバックで物理的なロケータを使用することは許容されます。
例
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
ローカル・インスタンスで(1つのセッションのみではなく)すべてのセッションを中断し、セッションがリプレイされないようにする場合、DBMS_SERVICE.DISCONNECT_SESSION PL/SQLプロシージャを使用し、disconnect_optionパラメータに対してNOREPLAYを指定することもできます。
|
参照:
|
リクエストがリプレイされると、可変オブジェクトのデフォルトおよび目的の処理が変化する可能性があります。可変オブジェクトは、コールされるたびに新しい値を取得できる非DETERMINISTICファンクションです。可変オブジェクトの使用例には、SYSTIMESTAMPファンクションに対するコールがあります。アプリケーション・コンティニュイティを使用するクライアント・アプリケーションは、リクエストのリプレイ時に可変ファンクションの元の値を保持するかどうかを決定できます。
可変オブジェクト値を保持するためのサポートは現在、SYSDATE、SYSTIMESTAMP、SYS_GUIDおよびsequence.NEXTVALに対して提供されています。元の値が保持されておらず、これらの可変オブジェクトの別の値がクライアントに戻される場合、クライアントが認識する値が異なるため、リプレイは拒否されます。アプリケーションが元の値を使用できる場合、所有されている順序に対してはKEEP句を使用し、他のユーザーに対してはGRANT KEEPを使用して、可変オブジェクトを構成してください。(ほとんどのアプリケーションでは、バインド変数の一貫性を維持するために、リプレイ時に順序値を保持する必要があります。)
|
注意: SYS_GUID値の保持は、シリアル実行計画に対してのみサポートされています。パラレル問合せを使用する場合、アプリケーション・コンティニュイティは、SYS_GUIDの元の値をリストアできません。 |
表26-1は、リプレイ時の可変オブジェクトの処理の例を製品別に示しています。(実際の実装は特定の製品およびリリースによって異なります。)
表26-1 リプレイ時の可変オブジェクトの処理の製品別の例
| 可変オブジェクト | 製品1 | 製品2 | 製品3 |
|---|---|---|---|
|
|
元 |
元 |
現行 |
|
順序 |
元 |
元 |
(該当なし) |
|
|
元 |
(該当なし) |
(該当なし) |
|
LOBアクセス |
不一致時に失敗 |
(該当なし) |
(該当なし) |
アプリケーション・コンティニュイティがリプレイ時に元のファンクション結果を保持および使用できるようにするには、次のようにします。
アプリケーションを実行するデータベース・ユーザーに、KEEP DATE TIMEおよびKEEP SYSGUID権限を付与し、値を保持する順序ごとにKEEP SEQUENCEオブジェクト権限を付与できます。次に例を示します。
grant KEEP DATE TIME to user2; grant KEEP SYSGUID to user2; grant KEEP SEQUENCE on sales.seq1 to user2;
|
注意: GRANT ALL ON <object>には、KEEP DATE TIMEおよびKEEP SYSGUID権限とKEEP SEQUENCEオブジェクト権限は含まれません(つまり、これらによって提供されるアクセスは承認しません)。 |
可変オブジェクト・サポートに関連する権限はアプリケーション・ユーザーに対してのみ付与し、各アプリケーション・ユーザーに対して必要な権限のみを付与します。
リプレイを有効化するアプリケーションを実行するデータベース・ユーザーには、DBA権限を付与しないでください。
アプリケーション内の順序には、KEEP属性を使用できます。この属性は、順序所有者に対してsequence.NEXTVALの元の値を保持することにより、リプレイ時にキーが一致するようにします。ほとんどのアプリケーションでは、リプレイ時に順序値を保持する必要があります。次の例では、順序に対してKEEP属性を設定しています(この場合は、文を実行するユーザーが所有する順序ですが、他の場合はGRANT KEEP SEQUENCEを使用してください)。
SQL> CREATE SEQUENCE my_seq KEEP; SQL> -- Or, if the sequence already exists but without KEEP: SQL> ALTER SEQUENCE my_seq KEEP;
|
注意: ALTER SEQUENCE ... KEEP/NOKEEPの指定は、順序の所有者に適用されます。これは、KEEP SEQUENCEオブジェクト権限を持つ他のユーザー(所有者ではありません)には影響しません。すべてのユーザーにNOKEEPを指定する場合、これらのユーザーにKEEP SEQUENCEオブジェクト権限を付与しない(または、すでに付与されている場合はそれを取り消さない)ようにしてください。 |
リプレイ時にファンクション結果(名前付きファンクションの場合)を保持するには、ファンクションを起動するユーザーにDBAがKEEP権限を付与する必要があります。このセキュリティ制限により、ユーザーによって所有されていないコードに対するファンクション結果をリプレイのために保存およびリストアできるようになります。
可変オブジェクトに対する権限を付与する場合は、次の考慮事項が追加適用されます。
可変オブジェクト値に対するKEEP権限がユーザーに付与されている場合、SYS_GUID、SYSDATEおよびSYSTIMESTAMPファンクションがコールされるときにオブジェクトが可変アクセス権を継承します。
順序オブジェクトで可変値に対するKEEP権限が取り消されると、このオブジェクトを使用するSQLまたはPL/SQLブロックでは、この順序に対する可変コレクションまたはアプリケーションは許可されません。
付与された権限がランタイムとフェイルオーバーの間に取り消されると、収集された可変値はリプレイに適用されません。
ランタイムとフェイルオーバーの間に新しい権限が付与されると、可変値は収集されず、これら値はリプレイに適用されません。
|
参照: ALTER SEQUENCEおよびGRANT文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください |
セッション状態一貫性は、リクエスト中に非トランザクション状態がどのように変化するかを示します。セッション状態の例としては、NLS設定、オプティマイザのプリファレンス、イベントの設定、PL/SQLグローバル変数、一時表、アドバンスト・キュー、LOBおよび結果キャッシュがあります。リクエストの開始後に非トランザクション値が変更された場合、デフォルト値のDynamicを使用します。
COMMITが実行された後、このトランザクションで状態が変更された場合、セッションが失われたときにトランザクションをリプレイしてこの状態を再確立することはできません。初期設定後のセッション状態が静的と動的のどちらであるか、さらにCOMMIT操作後の処理続行が正しいかどうかに応じて、アプリケーションを分類できます。
Dynamicモードはほとんどすべてのアプリケーションに適しています。確信がない場合は、Dynamicモードを使用します。ユーザーがアプリケーションを変更できる場合は、Dynamicモードを使用する必要があります。
内容は次のとおりです。
セッション状態の変更が初期化によって完全にカプセル化されておらず、フェイルオーバー時にコールバックに完全に取り込むことができない場合、セッションの状態は動的です。最初のトランザクションが完了した後、フェイルオーバーは次のリクエストが開始されるまでは内部的に無効化されます。Dynamicセッション状態一貫性モードでは、状態の変更はリクエスト時に行われ、リプレイはbeginRequestに対するコールで有効化されます。
トランザクションの実行時に非トランザクション・セッション状態が変更される場合、セッション状態一貫性モードをDynamicに設定します。ランタイム時に変更される可能性がある非トランザクション・セッション状態の例には、ALTER SESSION、PL/SQLグローバル変数、SYS_CONTEXTおよび一時表のコンテンツがあります。アプリケーションがトランザクション以外の状態をトランザクション内で変更し、それをコミットする場合、この状態はリプレイできないため、状態の設定をDynamicに設定する必要があります。アプリケーション・コンティニュイティに対してDynamicモードを使用する場合、次のリクエストが開始されるまではCOMMIT時にリプレイは無効です。デフォルト値はDynamicです。
図26-2は、セッション状態一貫性モードがDynamicである場合、リクエスト時に非トランザクション・セッション状態(NTSS)が変更されることを示しています。
図26-2に示すように、リプレイ(つまり、アプリケーション・コンティニュイティ)はbeginRequestコールで有効化され、COMMITまたはendRequestコールで無効化されます。(制限されたコールの使用により、アプリケーション・コンティニュイティも無効化されますが、これはこの図には示されていません。)また、図26-2には、トランザクションなし、最後の文としてCOMMITを使用したトランザクション、およびCOMMIT文が埋め込まれたトランザクションという3つのアプリケーション・シナリオのステップ・ロジックも示されています。
トランザクションなしのリクエストの場合、ロジックは次のようになります。
チェックアウトします。
リプレイは、endRequest、制限付きコール、および明示的なdisableReplayコールで無効化されます。
リクエストを開始し、リプレイを有効化します。
1つ以上のSELECT文、および場合によっては他のPL/SQL文を発行します。
(ギャップによって示された他のアクション。)
チェックインします。
リクエストを終了し、リプレイを無効化します。
最後の文としてCOMMITが使用されたトランザクションのリクエストの場合、ロジックは次のようになります。
チェックアウトします。
リプレイは、COMMIT時、endRequest、制限付きコール、および明示的なdisableReplayコールで無効化されます。
リクエストを開始し、リプレイを有効化します。
1つ以上のSELECT文、および場合によっては他のPL/SQL文を発行します。
トランザクションが開始されます。
(ギャップによって示された他のアクション。)
コミット(リプレイを無効化)します。
チェックインします。
リクエストを終了します。
COMMIT文が埋め込まれたトランザクションのリクエストの場合、ロジックは次のようになります。
チェックアウトします。
リプレイは、COMMIT時、endRequest、制限付きコール、および明示的なdisableReplayコールで無効化されます。
リクエストを開始し、リプレイを有効化します。
1つ以上のSELECT文、および場合によっては他のPL/SQL文を発行します。
トランザクションが開始されます。
(ギャップによって示された他のアクション。)
コミット(リプレイを無効化)します。
(ギャップによって示された他のアクション。ギャップではアプリケーションがアプリケーション・コンティニュイティの対象になりません。)
チェックインします。
リクエストを終了します。
NLS設定、SYS_CONTEXT、PL/SQL変数、およびオプティマイザ・プリファレンスなどのすべての非トランザクション状態の変更がリクエストごとに1回の初期化の一環として設定され、このセッション状態がトランザクション中に変更されない場合、セッション状態一貫性モードをStaticに設定します。これらの設定は、UCPラベリングなどを使用した接続の確立時、またはプールからの各チェックアウト時に、接続ごとに1回確立できます。これらの設定は、リプレイのコールバックで繰り返す必要があります。アプリケーション・コンティニュイティに対してStaticモードを使用する場合、トランザクションのフェイルオーバーはリクエストの最初のトランザクションの後も続行されます。
アプリケーションが使用するコールがリクエストの非トランザクション状態を変更する場合には、静的モードはサポートされません。このようなコールの具体的な例を次に示します。
PL/SQLサブプログラム
SYS_CONTEXT
ヒント
DDL操作
自動コミット
ALTER SESSION
ALTER SYSTEM
静的モードは慎重に指定してください。静的モードを使用するのは、アプリケーションがトランザクション内でNTSS (非トランザクション・セッション状態)を変更しない場合のみにしてください。セッション状態一貫性モードをStaticとして宣言することは、リクエスト内の最初のCOMMITの後に続行しても安全であることを示します。動的モードはほとんどのアプリケーションに適しています。ユーザーがアプリケーションを変更またはカスタマイズできる場合は、静的モードを使用しないでください。
図26-3は、セッション状態一貫性モードがStaticである場合、リクエスト時にNTSS (非トランザクション・セッション状態)が一定である(つまり、変更されない)ことを示しています。
図26-3に示すように、リプレイ(つまり、アプリケーション・コンティニュイティ)はbeginRequestコールで有効化され、制限付きコール、またはdisableReplayまたはendRequestコールで無効化されます。また、図26-3には、トランザクションがない、最後の文としてCOMMITが毎回使用された1つ以上のトランザクション、およびCOMMIT文を使用したトランザクションの後にアプリケーション・コンティニュイティを無効化する制限付きコールを使用したトランザクションが続く、という3つのアプリケーション・シナリオのステップ・ロジックも示されています。
トランザクションなしのリクエストの場合、ロジックは次のようになります。
チェックアウトします。
リプレイは、endRequest、制限付きコール、および明示的なdisableReplayコールで無効化されます。
リクエストを開始し、リプレイを有効化します。
1つ以上のSELECT文、および場合によっては他のPL/SQL文を発行します。
(ギャップによって示された他のアクション。)
チェックインします。
リクエストを終了し、リプレイを無効化します。
(最後の文としてCOMMITが毎回使用された)1つ以上のトランザクションのリクエストの場合、ロジックは次のようになります。
チェックアウトします。
リプレイは、COMMIT時、endRequest、制限付きコール、および明示的なdisableReplayコールで無効化されます。
リクエストを開始し、リプレイを有効化します。
1つ以上のSELECT文、および場合によっては他のPL/SQL文を発行します。
トランザクションが開始されます。
トランザクションがコミットされます。
トランザクションがパージされます。
(追加トランザクションごとに、手順4から7が実行されます。)
(ギャップによって示された他のアクション。)
チェックインします。
リクエストを終了します。
COMMIT文の後に制限付きコールを使用したトランザクションが続くリクエストの場合、ロジックは次のようになります。
チェックアウトします。
リプレイは、COMMIT時、endRequest、制限付きコール、および明示的なdisableReplayコールで無効化されます。
リクエストを開始し、リプレイを有効化します。
1つ以上のSELECT文、および場合によっては他のPL/SQL文を発行します。
トランザクションが開始されます。
トランザクションがコミットされます。
トランザクションがパージされます。
2番目のトランザクションが開始されます。
トランザクションが制限付きのコールを発行し、これによってアプリケーション・コンティニュイティが無効化されます。
トランザクションがパージされます。
(ギャップによって示された他のアクション。)
チェックインします。
リクエストを終了します。
セッションが再構築されると、すべての状態が再構築されます。これには、副作用を残す文の再実行も含まれます。レポートの作成や監査の完了など、これらの副作用こそが求められる作業である場合もあります。ただし、状態を構築するためにリプレイされるアクションには、リプレイの影響に対応したりこの影響を軽減するためのアクションが必要なものもあります。
アプリケーション・コンティニュイティは、データベース状態をリストアするためにPL/SQLを時間の経過順にリプレイします。これは、ユーザーによる発行が遅延されたものとしてセッションを再構築する上で役立ちます。ほとんどのアプリケーションは、レポートの作成や監査の完了など、発行が繰り返されたものとして完全な状態を再構築することを必要とします。ただし、状態を構築するためにリプレイされるアクションには、リプレイの影響に対応したりこの影響を軽減するためのアクションが必要なものもあります。一部のアプリケーションでは、繰り返す必要のないコールが含まれるリクエストに対してdisableReplay APIの使用を選択します。
リクエストがメッセージング・メカニズム(UTL_SMTP、UTL_HTTPまたはUTL_FILEなど)を使用した外部アクションを持つ場合は、リプレイする必要があるかどうかを確認するためにリクエストをレビューする必要があります。
副作用があるアクションの例は、次のとおりです。
自律型トランザクション(6.8項「自律型トランザクション」で説明するように、他のトランザクションからコールできる独立トランザクション)
DBMS_ALERTコール(電子メールまたは他の通知)
DBMS_FILE_TRANSFERコール(ファイルのコピー)
DBMS_PIPEおよびRPCコール(外部ソース向け)
UTL_FILEコール(テキスト・ファイルの作成)
UTL_HTTPコール(HTTPコールアウトの実行)
UTL_MAILコール(電子メールの送信)
UTL_SMTPコール(SMTPメッセージの送信)
UTL_TCPコール(TCPメッセージの送信)
UTL_URLコール(URLへのアクセス)
Java用のアプリケーション・コンティニュイティには、次の制限および他の考慮事項が適用されます。
JDBC Thin接続に対してのみ適用されます(JDBC OCIはサポートされません)。
JDBCを使用するアプリケーションの場合、oracle.sqlの非推奨具象クラスBLOB、CLOB、BFILE、OPAQUE、ARRAY、STRUCTまたはORADATAはサポートされません。(My Oracle Supportノート1364193.1Oracle新規JDBCインタフェース: https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1364193.1を参照)
JDBCストリーム引数の場合、リプレイはベスト・エフォート・ベースです。たとえば、アプリケーションが物理アドレスを使用している場合、アドレスは停止によって失われると、再配置できなくなります。たとえば、JDBCストリーム・セッター(setBinaryStreamなど)によってリプレイが無効になります。
リプレイのターゲット・データベースのデータベースID、プラガブル・データベースID、祖先および子孫は、ソース・データベースと同じである必要があります。
ターゲットが別のデータベースである場合、またはターゲットが同じデータベースまたは同じプラガブル・データベースであるがデータが失われたデータベース(フラッシュバックされた、メディア・リカバリによって不完全にリカバリされた、以前にOracle Data Guardによってオープンされた場合など)である場合、アプリケーション・コンティニュイティはリプレイしません。
アプリケーション・サーバー・レベルの文キャッシュが有効な場合(例: WebLogicまたはサードパーティのアプリケーション・サーバー文キャッシュ)、リプレイの使用時はこれを無効にする必要があります。かわりに、JDBC文キャッシュを構成します。これはJDBCおよびOracle向けに最適化され、アプリケーション・コンティニュイティもサポートしているため、パフォーマンスがより向上します。oracle.jdbc.implicitstatementcachesize=nnnを使用します。
Oracle XAを使用して開発されたアプリケーションの場合、リプレイはサポートされません。
リクエストがALTER SYSTEM文またはALTER DATABASE文を発行すると、リプレイは無効になります。
リプレイは、セッションを再構築するのに安全でないとみなされているALTER SESSION文のリクエスト・レベルでは無効化されています。これには、分離レベルおよびサポート・レベルのイベントを設定する文が含まれ、COMMIT IN PROCEDUREおよびGUARDを有効化および無効化します。
ただし、アプリケーション・レベルでのALTER SESSION文がリプレイでサポートされています。これらには、グローバリゼーション・サポート(NLS)設定の文、格納されているプライベートの概要、コンテナ(CDB/PDB)の設定、SQLトレースおよびPL/SQL警告が含まれます。
別のデータベースに対する読取り/書込みデータベース・リンクを使用してActive Data Guardを使用している場合、リプレイはサポートされません。
リプレイはパラレル問合せコールの失敗に対して、これが文レベルの失敗であるときに適用されません。たとえば、インスタンスまたはノードの失敗あるいはメモリーの問題において発生したコール失敗に対するORA-12805エラー(「パラレル問合せサーバーが突然停止しました。」)の後に、リプレイは行われません。
|
注意: ディスク・イメージ(BCVなど)を分割するか、別のデータベースになるようにデータベースをクローニングすることによってデータベースのクローンを作成し、物理またはActive Data Guardデータベースではないロジカル・スタンバイまたはロジカル・コピーを作成する場合、nidを使用してDBIDを変更し、データベースを区別する必要があります。nidプログラムの使用の詳細は、次のMy Oracle Supportノートを参照してください: NIDを使用したDBIDおよびDBNAMEの変更方法(ドキュメントID 224266.1)およびNIDを使用したOracle RAC DatabaseのDBNAMEおよびDBIDの変更(ドキュメントID 464922.1)。 |
