透過的アプリケーション・フェイル
オーバー
オラクル・ホワイト・ペーパー
透過的アプリケーション・フェイルオーバー
概要 ... 3
フェイルオーバーの概念 ... 3
TAF機能 ... 4
自動再接続... 4
パッケージおよびセッション状態のリストア ... 4
再開可能な問合せ... 5
セッションの移行... 6
TAFの構成 ... 6
サポートされる構成... 7
3 層環境... 7
透過的アプリケーション・フェイルオーバーの構成... 7
FAILOVER_MODEパラメータ... 8
接続時フェイルオーバーおよびクライアント・ロード・バランシング
を行うTAFの実装... 8
接続の再試行... 9
接続の事前確立... 9
検証... 10
特別な考慮事項 ... 10
トランザクション... 10
ネットワーク... 11
セッション状態... 13
TAFエラー・コード... 14
TAF以外のエラー・コード... 14
サーバー（シャドウ）プロセス障害 ... 15
Fast Application Notification... 15
Fast Connection Failover ... 16
透過的アプリケーション・フェイルオーバー
概要
企業のデータベース・システムへの依存度が高まるにつれ、サービスの中断によっ て起こる混乱はますます深刻になります。Oracle Database 10g には、エンド・ユー ザーへの影響を最小限に抑えて、システム障害からアプリケーションをリカバリ する様々な可用性機能が実装されています。中断を最小限に抑えるということは、 リカバリ時間の短縮だけではなく、フェイルオーバー時にユーザーに混乱を与え ないことも意味します。透過的アプリケーション・フェイルオーバー（TAF）で は、アプリケーションの状態を保持し、障害発生時に実行していた作業を再開し、 ほとんどの障害をエンド・ユーザーから完全に見えないようにします。TAF は、 それを活用するアプリケーションを開発するツールを提供するだけでなく、トラ ンザクションに影響を与える障害など、すべての障害をエンド・ユーザーから見 えなくするツールも提供します。フェイルオーバーの概念
フェイルオーバーにより、クラスタ内の別のシステムにデータベースをリカバリ できます。図 1 に、標準的なデータベース・クラスタの構成を示します。この図 では、クラスタは 2 つのシステムで構成されていますが、より大きなクラスタを 構築することもできます。コールド・フェイルオーバー構成の場合、一度にデー タベースにマウントできるアクティブなインスタンスは 1 つのみです。Oracle Real Application Clusters を使用すると、複数のインスタンスをデータベースにマウント でき、障害からのリカバリ処理時間が短縮されます。 クラスタ内のシス テム A に障害が発 生すると、ユーザー を移行します。 マシン A マシン B マシン B マシン A 図 1: 2 つのシステム構成のクラスタあるインスタンスで発生した障害は、障害が発生しなかったインスタンスによっ て検出されます。障害が発生したインスタンスのワークロードをそのインスタン スが引き受け、障害が発生したインスタンスに接続されているクライアントは、 障害が発生しなかったインスタンスに移行します。この移行のメカニズムは、ク ラスタ構成によって異なります。透過的アプリケーション・フェイルオーバー機 能は、クライアント・セッションとデータベースを自動的に再接続し、エンド・ ユーザー・アプリケーションの運用の中断を最小限に抑えます。
TAF 機能
自動再接続
Oracle のクライアントは、Oracle® Call Interface（OCI）と呼ばれる API を介して データベースと対話します。OCI クライアントは、初めにクラスタ内のプライマ リ・サーバーに存在するリスナー・プロセスに接続されます。このリスナーは、 クライアントにサーバー・プロセスとの接続機能を提供します。このサーバー・ プロセスは、プライマリ・インスタンスと同じシステム上で実行されるか、Real Application Clusters を使用している場合は、別のサーバーに常駐させ、別の Oracle インスタンスを使用します。障害が発生すると、クライアント・マシン上の OCI ライブラリによってエラー・メッセージがインターセプトされ、透過的フェイル オーバー・プロセスが開始されます。OCI から別の接続が要求されると、リスナー は、障害が発生しなかったシステムのサーバー・プロセスにクライアントを接続 します。 このリスナーが接続に失敗した場合、OCI ライブラリはクラスタ内の別のシステ ム上のバックアップ・リスナーに接続します。これは、障害発生時にバックアッ プ・サービスを接続するための IP フェイルオーバーまたは Network Services 機能 を使用します。 別のサーバーへのフェイルオーバーには、遅延が伴うことがあります。接続が切 断された場合、Oracle では、フェイルオーバーが実行中であるため、フェイルオー バーが完了するまで待機するようにユーザーに指示するコールバック関数を実行 します。ユーザーは、この遅延がクライアント障害であるとみなすため、クライ アントを再起動することはありません。クライアント・アプリケーション開発者 は、このコールバック関数を OCI に登録できます。この登録された関数は、フェ イルオーバー実行中にライブラリよりコールされます。 新規接続が確立されアクティブ化されると、クライアント・アプリケーションか らフェイルオーバーを見えなくするその他の操作が OCI によって実行されます。
パッケージおよびセッション状態のリストア
データベース・サーバーは、ステートレスなアプリケーションではありません。 準備済みカーソル、PL/SQL™パッケージの状態、言語環境の設定など、各クライ アント・セッションの状態はデータベースに保持されます。準備済みカーソルは 透過的に復元され、パッケージおよびセッション状態は、フェイルオーバー完了 後に登録済みのコールバック関数によってリストアされます。コールバック関数 は、ライブラリから渡されるパラメータを使用してコールのコンテキストを判断 し、障害発生中に消失したすべてのパッケージ状態を回復します。さらに、この時点でコールバック関数によって ALTER SESSION コマンドを再実行することも できます。このコマンドは、通常、クライアント・アプリケーションがデータベー スに最初に接続するときに実行されます。この関数を使用して、フェイルオーバー が完了したことや、何らかの理由でフェイルオーバーが正常に実行されなかった ためにフェイルオーバーが実行できなかったことをユーザーに通知できます。ク ライアント・アプリケーションによって、データベースとのセッションが複数確 立されている場合、OCI ライブラリは、セッションがフェイルオーバーされるた びにこの関数をコールします。これも、目的の ALTER SESSION コマンドをこの 関数に再実行させるためのコールです。 図 2 に示すように、TAF は障害の発生後、コールバック関数を使用してサーバー 上のアプリケーションの状態を保持します。従来の IP フェイルオーバーの手法の みでは、状態はデータベースに保持されず、障害をクライアント・アプリケーショ ンから完全に見えなくすることはできません。 フェイルオーバー前: 状態は、クライアントとデータ ベースに保持される マシン B マシン A 自動再接続 手動による接 続 マシン B マシン B マシン A マシン A 図 2: アプリケーションの状態の保持. TAF を使用しない場合: クライアントは再接続できるが、データ ベース上のアプリケーションの状態は失わ れる TAF を使用した場合: データベース上のアプリケーションの 状態は保持される
再開可能な問合せ
TYPE パラメータを SELECT に設定して TAF を構成した場合、障害発生時にオー プンしていたカーソルは障害の発生後、OCI ライブラリによって暗黙的にカレン ト行に戻されます。図 3 に示すように、オープンしていたカーソルは再実行され、 障害の発生前にアプリケーションに戻された行は破棄されます。これにより、ア プリケーションはオープンしているカーソルから結果セットをフェッチし、次の 行を取得します。このとき、ユーザーは、1 つの SELECT 文のみが結果セットを 返したと解釈します。Oracle の読取り一貫性機能により、2 回目以降の実行によっ て返される結果は、必ず元の SELECT 文から返された結果と同じになります。ア プリケーションから発行された問合せに ORDER BY 句が指定されていても、2 つ の問合せの順序一貫性によって、同じ行が 2 回目以降の問合せの結果セットから
破棄されます。最終チェックとして、OCI ライブラリでは破棄された行のチェッ クサムを計算し、すでに返された破棄済みの行と比較します。この時点で不一致 が見つかると、エラーが返されます。 クライアント 破棄 破棄 破棄 破棄 インスタン ス 2 インスタン ス 1 消失 消失 フェイルオーバー発生時 に一部返された行 残りの行を継続して返す 図 3: 透過的な問合せ
セッションの移行
透過的アプリケーション・フェイルオーバーでは、管理者はインスタンス間でセッ ションを移行できます。これは、ロード・バランシングやインスタンスまたはシ ステムのメンテナンスを準備する際に役立ちます。個別のセッション、またはす べてのセッションを切断できます。TAF によって、これらのセッションは、別の インスタンスまたはスタンバイ・データベースやレプリカ・データベースで再確 立されます。システム・メンテナンスの準備では、すべてのセッションの移行が 完了するとデータベースは停止します。その後、管理者はメンテナンス作業を実 行できます。この移行作業は、アクティブな更新トランザクションがすべて完了 するまで延期することができます。これにより、フェイルオーバーはエンド・ユー ザーに対して透過的に機能します。TAF の構成
TAF の構成は、クライアントがデータベースの接続に使用する接続字列内に指定 します。管理者は、セッションを再確立し SELECT 文を再実行する、セッション のみを再確立する、自動フェイルオーバーを実行する、いずれかを接続文字列内 に指定できます。LDAP サーバーを使用して接続文字列の別名を指定すると、管 理者は、ネットワーク上のすべてのクライアントに対して TAF を簡単に設定でき ます。サポートされる構成
透過的アプリケーション・フェイルオーバーは、様々なシステム構成に実装でき ます。Oracle では、障害発生時に再接続先となる別のインスタンスのみが必要で す。通常、このインスタンスはただちに使用できますが、必須ではありません。 TAF は、単一システムでも使用できます。単一システムの場合、すべての修復が 完了すると同じシステムで別のインスタンスが再起動されます。また、TAF は Real Application Clusters や Oracle Fail Safe（コールド・フェイルオーバー）など、すべ てのクラスタ・フェイルオーバー技術に対応します。TAF は、リモートでレプリ ケートされるデータベースまたはスタンバイ・データベースでも使用できます。 基盤となるデータベースが同一でない場合でも一貫性を確保するために、Oracle では、チェックサムを使用して破棄された行がすでに返された行と同じであるこ とを検証します。同一でない場合はエラーを返します。TAF を使用するクライアント・アプリケーションは、Oracle Call Interface バージョ ン 8 を使用するように作成する必要があります。SQL*Plus®、ODBC ドライバお よび JDBC ドライバ、Oracle の.NET プロバイダ、Pro*C™ Precompiler のいずれも、 Oracle Call Interface バージョン 8 を使用し TAF をサポートする予定です。Oracle Call Interface バージョン 8 を使用するように作成すると、いずれのサード・パー ティ製アプリケーションでも TAF を使用できます。
3 層環境
ここまでに、2 層環境における TAF の使用について説明しましたが、TAF は、3 層階層、すなわちアプリケーション・サーバーまたはトランザクション・モニター がデータベース・サーバーとクライアント間に存在する構成でも使用できます。 障害が発生した場合、TAF は、アプリケーション・サーバーとデータベース・サー バー間の接続を透過的にフェイルオーバーし、データベース・サーバー上のすべ てのパッケージおよびセッション状態を復元します。次に障害発生時に処理して いたすべての問合せを再実行します。TAF を使用すると、開発者は環境内の別の 層に対してデータベース・サーバーの障害を完全にマスクする複数層ソリュー ションを構築できます。透過的アプリケーション・フェイルオーバーの構成
TAF では、FAILOVER_MODE パラメータを含むネット・サービス名を手動で構 成する必要があります。このパラメータは、接続ディスクリプタの CONNECT_DATA に含まれています。FAILOVER_MODE パラメータ
FAILOVER_MODE パラメータは、接続ディスクリプタの CONNECT_DATA 部分 に含める必要があります。次のパラメータを FAILOVER_MODE に含めることが できます。 tnsnames.ora ファイル・パラメータ 説明TYPE（必須） フェイルオーバーのタイプを指定します。Oracle Call Interface （OCI）アプリケーションでは、デフォルトで次の 3 種類の Net8 フェ イルオーバー機能が使用できます。 SESSION: セッションをフェイルオーバーします。つまり、ユー ザーの接続が失われた場合、バックアップ・インスタンスにその ユーザーの新しいセッションが自動的に作成されます。このフェイ ルオーバーのタイプでは、SELECT のリカバリは試行しません。 SELECT: カーソルをオープンしているユーザーは、障害発生後も カーソルを継続的にフェッチできます。ただし、このモードでは通 常の SELECT 処理で、クライアント側にオーバーヘッドが発生し ます。 NONE: フェイルオーバー機能を使用しないデフォルト設定です。 フェイルオーバーの発生を防ぐために、明示的に指定することもで きます。 METHOD プライマリ・ノードからバックアップ・ノードへのフェイルオー バーの処理時間を設定します。 BASIC: フェイルオーバー時に接続を確立します。このオプション の場合、フェイルオーバーが発生するまで、バックアップ・サー バーに負荷はほとんどかかりません。 PRECONNECT: 接続を事前に確立します。フェイルオーバーの処 理時間を短縮します。ただし、バックアップ・インスタンスは、 サポート対象のすべてのインスタンスからの接続をサポートする 必要があります。 BACKUP バックアップ接続の別のネット・サービス名を指定します。BASIC メソッドには BACKUP を指定することを強くお薦めします。この パラメータを指定しないと、接続に失敗したインスタンスに対し て再接続が最初に試行され、クライアントが再接続されるまでに さらに時間がかかる可能性があります。LOAD_BALANCING が ON の場合、BACKUP を指定することはできません。 RETRIES 接続の試行回数を指定します。DELAY が指定されている場合、 RETRIES はデフォルトで 5 回に設定されます。この設定は、障害 発生後の再接続のみで、初回の接続試行には影響しません。コー ルバックが登録されている場合、このパラメータは無視されます。 DELAY 接続に失敗後、次の接続を試行するまでの待機時間を秒数で指定 します。RETRIES が指定されている場合、DELAY はデフォルト で 1 秒に設定されます。コールバックが登録されている場合、こ のパラメータは無視されます。
接続時フェイルオーバーおよびクライアント・ロード・バランシング
を行う TAF の実装
TAF は、接続時フェイルオーバーおよびクライアント・ロード・バランシングを 複数のアドレスに組込み実装することができます。次の例では、Net8 は sales1-server または sales2-server のリスナー・アドレスにランダムに接続します。 接続後、インスタンスに障害が発生すると、Net8 は他のノードのリスナーにフェ イルオーバーし、処理中であった SELECT 文の処理を再開します。sales.us.acme.com= (description= (load_balance=on) (failover=on) (address= (protocol=tcp) (host=sales1-server) (port=1521)) (address= (protocol=tcp) (host=sales2-server) (port=1521)) (connect_data= (service_name=sales.us.acme.com) (failover_mode= (type=select) (method=basic))))
接続の再試行
TAF には、最初の再接続の試行に失敗した場合、RETRIES パラメータおよび DELAY パラメータを使用してフェイルオーバー時に自動的に接続を再試行する 機能もあります。次の例では、Net Services は接続に失敗後、sales1-server のリス ナーへの接続を試行します。接続の試行が失敗した場合、Net Services は 15 秒後 に再度接続を試行します。Net Services は最大 20 回まで接続を試行します。DELAY および RETRIES は、障害発生後の再接続の試行に対してのみ影響します。初回の 接続試行または初回の事前接続試行には影響を与えません。コールバックが登録 されている場合、DELAY および RETRIES は無視されます。その場合、コールバッ クが適切な試行回数および待機時間を判断します。 sales.us.acme.com= (description= (address= (protocol=tcp) (host=sales1-server) (port=1521)) (connect_data= (service_name=sales.us.acme.com) (failover_mode= (type=select) (method=basic) (retries=20) (delay=15))))接続の事前確立
バックアップ接続は事前に確立できます。最初の接続およびバックアップ接続は、 明示的に指定する必要があります。次の例では、Net Services は、sales1-server の リスナーに接続します。接続後 sales1-server に障害が発生すると、Net Services は sales2-server にフェイルオーバーし、処理中であった SELECT 文の処理を再開しま す。sales.acme.com= (description= (address= (protocol=tcp) (host=sales1-server) (port=1521)) (connect_data= (service_name=sales.us.acme.com) (instance_name=sales1) (failover_mode= (backup=sales2.acme.com) (type=select) (method=preconnect)))) sales2.acme.com= (description= (address= (protocol=tcp) (host=sales2-server) (port=1521)) (connect_data= (service_name=sales.us.acme.com) (instance_name=sales2)))
検証
V$SESSION ビューの FAILOVER_TYPE 列、FAILOVER_METHOD 列および FAILED_OVER 列に対して問合せを実行し、TAF が正しく構成されていることを 確認できます。
特別な考慮事項
TAF を使用する場合、考慮が必要な事項がいくつかあります。次にこれらの考慮 事項について説明します。トランザクション
障害発生時、アクティブな更新トランザクション（UPDATE、INSERT、DELETE） を持つセッションは、自動的に新しいセッションに再接続されますが、コミット されていないトランザクションは、リカバリ中にロールバックされます。Oracle は、ロールバックの発行が必要なことを通知するエラー・メッセージをアプリケー ションに返します。このアプリケーションに障害を認識する機能がある場合は、 ロールバックを自動的に発行し、トランザクションを再発行し、エンド・ユーザー から障害を完全に見えなくすることができます。障害を認識する機能がない場合、 ユーザーはロールバックを開始しトランザクションを再発行する必要があります。 実際には、ロールバックはリカバリ中に自動的に実行されます。Oracle の場合、 明示的なロールバック文があれば、トランザクションがロールバックされたこと をアプリケーションまたはユーザーに確実に認識させることができます。 障害を完全に見えなくするアプリケーションでは、TAF エラーが発生した場合、 ロールバック後にトランザクションの再試行が必要です。すでに様々なアプリ ケーションで、同じロールバック/リトライ手法を使用して、データベースから報告されるデッドロック・エラーを処理しています。アプリケーションが TAF で報 告されるエラーに対応するために、デッドロック・エラーに関する現行のプログ ラム・ロジックを修正することができます。 現行のプログラム・ロジックに、デッドロック・エラーに対応するものがない場 合、たとえば、単にエラーを報告しデータベース接続をクローズするアプリケー ションの場合は、同様の基本的な手法を使用して TAF エラーに対処するのも 1 つ の方法です。 用語 説明 アクティブな トランザクション 1 つ以上のデータベース更新が実行されました。 非アクティブな トランザクション データベース更新は実行されませんでした。COMMIT または ROLLBACK を実行して 1 つ前のアクティブなトランザクショ ンを完了後に、問合せが行われた可能性があります。 アクティブな接続 障害発生時に、クライアント/サーバー・データベースの相互 作用がアクティブ状態です。 非アクティブな接続. 障害発生時に、クライアント/サーバー・データベースの相互 作用はアクティブ状態になっておらず、クライアントとサー バーがアイドル状態です。 障害発生時に、接続でアクティブなトランザクションが存在する場合: • トランザクションがロールバックされます。 • 次の情報に関するエラーが報告されます。 ° アクティブな接続を対象とした現在のデータベースの相互作用 ° 非アクティブな接続を対象とした次のデータベースの相互作用 • アプリケーションは、後続のデータベース相互作用が正常に実行される 前に、ROLLBACK 文を発行する必要があります。 障害発生時に、接続で非アクティブなトランザクションが存在する場合: • Oracle Net の構成パラメータによっては、エラーの報告は必要ありません。 • アプリケーションは、通常の方法でデータベース更新を実行し、新規の アクティブなトランザクションを開始できます。
ネットワーク
システムのクラッシュまたはネットワーク障害が発生した場合、接続先のネット ワークは障害を迅速に識別する以外に対応する方法がありません。RealApplication Clusters とともに Oracle Database 10g Release 2 を使用する場合、クライ アントは FAN イベントをサブスクライブし（次を参照）、障害発生通知を受け取 ることができます。ただし、使用するデータベースおよびクライアントが Release 10.2 以降でない場合、タイムアウトの期限が切れるため、クライアント自身が障 害を識別する必要があります。タイムアウトは、障害発生時のクライアントの状 態によって異なります。クライアントの状態には次の状態があります。
• Disconnected: 現在、クライアントは、障害が発生したノードに接続され ていない状態。
• Connected/with interrupt: 停止状態になったノードにクライアントが接 続されている状態。障害発生時、ソケットはクローズされます。クライ アントに対し割込みが送信され、接続がクローズされます。
• Connected/no interrupt/not waiting: 停止状態になったノードにクライア ントが接続されている状態。ただし、read()または write()の呼出しが戻る のを待っていません。停止状態になったノードでは、ソケットをクロー ズできない状態（カーネル・パニックなど）になります。次回、セッショ ンがインスタンスと通信する場合は、そのインスタンスが使用不可であ ることを検出してから、通信を試行します。 • Connected/no interrupt/waiting: 停止状態になったノードにクライアント が接続され、read()または write()の呼出しが戻るのを待っている状態。停 止状態になったノードでは、ソケットをクローズできない状態（カーネ ル・パニックなど）になります。障害が発生したことを検出するまで、 セッションは待機し、バックアップ・インスタンスとの接続を試行しま す。 次の表に、各シナリオの動作を説明します。デフォルト値は、HP に対する値です。 障害発生時の クライアントの状態 動作 遅延に影響を与える TCP パラメータ デフォルト（HP） Disconnected クライアントは、障害が発生したノードの IP アドレスを使用してノードへの接続を 試行する場合、tcp_ip_abort_cinterval に設 定されている値を超えるまで、接続が正常 に実行されるのを待ちます。その後、クラ イアントは接続に失敗しますが、 （TNSnames に指定されているように）バッ クアップとの接続を試行します。 tcp_ip_abort_cinterval 75 秒 Connected/with interrupt クライアントは、ただちに切断され、再接 続可能な状態になります。注意 1 を参照。該当なし 該当なし Connected/no interrupt/idle 接続の試行直後、クライアントはタイムア ウト時間が経過するまで待ち、その後、接 続が失敗した状態になります。書込み操作 の場合は、tcp_ip_abort_interval で設定され ているタイムアウト時間の経過後、接続が 失敗した状態になります。読取り操作の場 合は、tcp_keepalive_interval で設定されて いるタイムアウトの経過後、接続が失敗し た状態になります。注意 1 を参照。 tcp_ip_abort_interval (write) tcp_keepalive_interval (read) 10 分（書込み）、 2 時間（読取り） Connected/no interrupt/waiting クライアントは、tcp_keepalive_interval に 対する応答を待ってから接続が失敗した 状態になります。注意 1 を参照。 tcp_keepalive_interval 2 時間 注意 1: 接続失敗後、クライアントは再接続が可能な状態になります。TAF のバッ クアップが指定されている場合、クライアントは遅延時間を発生させず に自動的にバックアップに接続されます。TAF のバックアップが指定さ れていない場合、Disconnected シナリオに説明したように、クライアント
は接続に失敗したノードとの再接続を試行し、tcp_ip_abort_cinterval に設 定されている遅延が発生します。ここでは、Net Services は、複数のアド レスに対して同じ順序で接続を試行するように構成されていることが前 提です。クライアントのロード・バランシングが使用されている場合、 ランダムに選択されるアドレスに応じて、クライアントは、接続に失敗 したノードではなく、バックアップ・ノードへの接続を試行する場合も あります。 遅延を減らす 1 つの有効な方法は、接続に失敗したサーバーの IP アドレスを障害 が発生していないサーバーに移動します。これにより、新しい接続の遅延が減少 します。また、アイドル状態になっている既存の接続を中断することもできます。 RAC とコールド・フェイルオーバー・クラスタを併用する場合は、障害発生後に 移動可能な仮想 IP を使用してデータベースへ接続することをお薦めします。これ は、Oracle Database 10g Release 1 から Oracle Clusterware に固有機能として組み込 まれています。そのため、主要なすべてのプラットフォームで使用できます。 Net Services のみを使用してフェイルオーバー機能を提供する場合、フェイルオー バー時間を短縮するために、前述のパラメータのチューニングが必要な場合もあ ります。ただし、これはネットワーク・トラフィックのパフォーマンスに影響を 与えたり、フェイルオーバーが正常に実行されない可能性があります。次にチュー ニングに対する提案事項を示します。 • 接続時間フェイルオーバーを最適化するために TCP 接続中断時間 （tcp_ip_abort_cinterval）を短くする。この最適化は、仮想 IP 機能を持つ システムの場合、通常不要です。 • サーバーからの応答を待つクライアントに対しフェイルオーバーを最適 化するために、TCP keepalive をチューニングする。 ° 接続ディスクリプタの DESCRIPTION 句に“(ENABLE=BROKEN)”パ ラメータを指定して、keepalive を有効にする。 ° keepalive 時間（tcp_keepalive_interval）をデフォルト値（2 時間）から データベースのフェイルオーバー時間の最近似値に変更する（例: 20 秒から 1 分）。
セッション状態
TAF では、接続フェイルオーバー後に、データベースのセッション状態を再構成 しません。 • アクティブなトランザクションによって実行されたすべてのデータベー ス変更のロールバックとロックのすべての解除。 • PL/SQL セッション状態の消失。 • ALTER SESSION コマンドの効果の消失。 コールバック関数は、フェイルオーバー時にトリガーされるように登録できます。 この関数によって、一部の消失した状態を再作成できます。TAF エラー・コード
TAF から出力されるエラー・コードの範囲は、ORA-25400～ORA-25425 です。 既存の接続で障害の発生後にエラー・コードが出力された場合、TAF は接続をフェ イルオーバーできません。その場合、アプリケーションは接続が消失したと推測 します。したがって、ロールバック/リトライ・メカニズムは使用できません。 TAF より実際に出力が予想されるエラー・コードは、次のとおりです。 エラー・コード エラー･メッセージ 注記 ORA-25401 フェッチを継続できませ ん。 通常、アクティブなトランザクションのな いアクティブな接続に対する問合せを 行った Oracle Net の TYPE が、SESSION に設定されている場合に出力されます。 ORA-25402 トランザクションをロー ルバックする必要があり ます。 最も一般的なエラー・コード。ROLLBACK が実行されるまで、後続のすべてのデータ ベース相互作用について報告されます。 ORA-25405 トランザクションのス テータスが不明です。 COMMIT 操作時間は短いため、このコー ドが出力されることはほとんどありませ ん。 ORA-25408 呼出しを安全に再実行で きません。 アクティブなトランザクションを作成す る初回のデータベース更新のみに出力さ れます。 ORA-25425 ロールバック中に接続が 失われました。 障害発生時、またはフェイルオーバー後 （ただし他のデータベースの相互作用が行 われる前）に ROLLBACK 操作が実行され る可能性は低いため、このコードが出力さ れることはほとんどありません。TAF 以外のエラー・コード
TAF が新しい接続を確立できない場合は、前述したエラー・メッセージ以外のメッ セージが出力されます。これらのエラー・コードは、TAF エラーではありません が、通常は、Oracle データベースとの接続の初回の試行時に報告されるエラーと 同じです。 TAF が新しい接続を確立できないと考えられる理由は、次のとおりです。 • Oracle Net の TAF 構成パラメータの制限（例: コールド・フェイルオーバー・クラスタの RETRIES パラメータや DELAY パラメータの設定不良） • ターゲット・データベースのインスタンスは適切な Oracle Net リスナーに
登録されているが、可用性に制限があるか、または起動中か停止中。 • ターゲット・データベースのインスタンスも使用できない。
Oracle Net の TAF 構成パラメータに構文エラーがある場合、TAF は新しい接続を 確立できないように見えることもあります。
その場合、アプリケーションは接続が消失したと推測します。したがって、ロー ルバック/リトライ・メカニズムは使用できません。
発生する可能性が高いエラー条件を次に示します。ただし、サイト固有の構成上 の問題に関連した Oracle Net のエラーは含まれていません。 エラー・コード エラー･メッセージ ORA-01012 ログオンされていません。 ORA-01033 Oracle の初期化またはシャットダウン中です。 ORA-01034 Oracle は使用できません。 ORA-01089 即時シャットダウン処理中 - 操作はできません。 ORA-03113 通信チャネルで end-of-file が検出されました ORA-03114 Oracle に接続されていません。 ORA-12203 TNS: 接続先に接続できません。 ORA-12500 TNS: リスナーが専用サーバー・プロセスの起動に失敗しました。 ORA-12571 TNS: パケット・ライターに障害が発生しました。
ORA-12153 TNS: 接続されていません。（TAF ではなく FAN が有効になって いる場合に返されるエラー）
サーバー（シャドウ）プロセス障害
TAF は、インスタンスの障害からの保護を目的として設計されています。インス タンスの障害には、クライアント・プロセスに対応する専用サーバー・プロセス が正常に実行されない、インスタンスが正常に実行されていない、TAF が正常に 実行されなかったプロセスに関連付けられたクライアントをフェイルオーバーし ない、というケースがあります。これらの状態が発生することはほとんどありま せんが、接続に伴ったセッション状態と関連する場合があります。また、フェイ ルオーバーによって再度同じ状態になり、別の障害が発生する可能性もあります。 通常、サーバー・プロセスは、TAF をテストするために意図的に中断されます。 インスタンス全体を停止せずに TAF 構成をテストする場合は、ALTER SYSTEM DISCONNECT SESSION コマンドを使用します。TAF は、このコマンドが発行さ れると、削除された接続をリカバリします。Fast Application Notification
Fast Application Notification（FAN）は、Oracle Database 10g の Real Application Clusters （RAC）とともに Oracle Cluster Ready Services（CRS）によって実装される高可用
性フレームワークの一部として実装されます。
FAN によって、基盤となる TCP/IP スタックのエラー検出、処理特性およびレポー ト特性への依存性が排除されます。FAN は、データベースおよび RAC のインス タンスの状態の変更をアプリケーションに通知する、優れたメカニズムも提供し ます。
Oracle Database 10g Release 2（10.2）以降、OCI クライアント・アプリケーション は FAN イベントをサポートします。すなわち、すべてのクライアント・アプリケー ションがこれらのイベントをサブスクライブし、障害が発生した場合、イベント で通知を受信します。これにより、前述したネットワークのタイムアウトにより クライアントで発生するフェイルオーバーが遅延しません。CRS は、タイムアウ
ト時間が経過するのを待たずにクライアントを中断し、TAF を強制的に再接続し ます。
FAN イベントをサブスクライブするには、クライアントをマルチ・スレッド化し、 10.2 以降の Oracle クライアントとリンクする必要があります。
Fast Connection Failover
Fast Connection Failover（FCF）では、Oracle Application Server 10g に組み込まれて いる FAN がパッケージとして実装されています。障害が発生した場合、FCF は FAN イベントに基づいて動作し、失効した接続を削除し、SQL 例外としてアプリ ケーションに通知を渡します。通知を受け取ると、アプリケーションは接続を再 試行し、トランザクションを再実行します。FCF は、OCI や TAF には依存せず、 JDBC 接続プールと連動します。このため、FCF は、Thin JDBC ドライバおよび Thick (OCI) JDBC ドライバの両方で使用できます。TAF および FCF を同じアプリ ケーションで使用することはお薦めしません。
結論
透過的アプリケーション・フェイルオーバーは、障害をクライアント・アプリケー ションから見えなくすることで、アプリケーションの可用性を向上させる強力な ツールです。TAF の最大の利点は、障害に伴う混乱を防ぎ、バックアップ・イン スタンスとの接続を自動的に再確立し、中断された時点から問合せを継続して実 行できることです。TAF は、単一システム、クラスタおよび各地に分散したシス テムなど、様々な構成で機能します。TAF では、エンド・ユーザーがシステム間 を移動する時も混乱しません。そのため、管理者はメンテナンスおよびロード・ バランシング作業を実行できます。TAF および Oracle Database 10g のその他の高 可用性機能によって、クリティカルなデータへの常時アクセスが保証されます。透過的アプリケーション・フェイルオーバー 2006 年 6 月 著者: Bob Thome 寄稿者: Mike Hallas Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問合せ窓口: 電話: +1.650.506.7000 ファックス: +1.650.506.7200 www.oracle.com Copyright © 2006, Oracle. 無断転載を禁ず。 この文書はあくまで参考資料であり、掲載されている情報は予告なしに変更されることがあります。 オラクル社は、本ドキュメントの無謬性を保証しません。また、本ドキュメントは、法律で明示的または暗黙的に記載 されているかどうかに関係なく、商品性または特定の目的に対する適合性に関する暗黙の保証や条件を含む一切の保証 または条件に制約されません。オラクル社は、本書の内容に関していかなる保証もいたしません。また、本書により、 契約上の直接的および間接的義務も発生しません。本書は、事前の書面による承諾を得ることなく、電子的または物理 的に、いかなる形式や方法によっても再生または伝送することはできません。
Oracle、JD Edwards、PeopleSoft は、Oracle Corporation および関連会社の登録商標です。他の製品名は、それぞれの 所有者の商標です。
