透過的アプリケーション・フェイルオーバー

透過的アプリケーション フェイルオーバー オラクル ホワイト ペーパー 2006 年 6 月

透過的アプリケーション フェイルオーバー 概要... 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 結論... 16 透過的アプリケーション フェイルオーバー 2

透過的アプリケーション フェイルオーバー 概要 企業のデータベース システムへの依存度が高まるにつれ サービスの中断によって起こる混乱はますます深刻になります Oracle Database 10g には エンド ユーザーへの影響を最小限に抑えて システム障害からアプリケーションをリカバリする様々な可用性機能が実装されています 中断を最小限に抑えるということは リカバリ時間の短縮だけではなく フェイルオーバー時にユーザーに混乱を与えないことも意味します 透過的アプリケーション フェイルオーバー (TAF) では アプリケーションの状態を保持し 障害発生時に実行していた作業を再開し ほとんどの障害をエンド ユーザーから完全に見えないようにします TAF は それを活用するアプリケーションを開発するツールを提供するだけでなく トランザクションに影響を与える障害など すべての障害をエンド ユーザーから見えなくするツールも提供します フェイルオーバーの概念 フェイルオーバーにより クラスタ内の別のシステムにデータベースをリカバリできます 図 1 に 標準的なデータベース クラスタの構成を示します この図では クラスタは 2 つのシステムで構成されていますが より大きなクラスタを構築することもできます コールド フェイルオーバー構成の場合 一度にデータベースにマウントできるアクティブなインスタンスは 1 つのみです Oracle Real Application Clusters を使用すると 複数のインスタンスをデータベースにマウントでき 障害からのリカバリ処理時間が短縮されます マシン A マシン B クラスタ内のシステム A に障害が発生すると ユーザーを移行します マシン A マシン B 図 1: 2 つのシステム構成のクラスタ 透過的アプリケーション フェイルオーバー 3

TAF 機能自動再接続 あるインスタンスで発生した障害は 障害が発生しなかったインスタンスによって検出されます 障害が発生したインスタンスのワークロードをそのインスタンスが引き受け 障害が発生したインスタンスに接続されているクライアントは 障害が発生しなかったインスタンスに移行します この移行のメカニズムは クラスタ構成によって異なります 透過的アプリケーション フェイルオーバー機能は クライアント セッションとデータベースを自動的に再接続し エンド ユーザー アプリケーションの運用の中断を最小限に抑えます Oracle のクライアントは Oracle Call Interface(OCI) と呼ばれる API を介してデータベースと対話します OCI クライアントは 初めにクラスタ内のプライマリ サーバーに存在するリスナー プロセスに接続されます このリスナーは クライアントにサーバー プロセスとの接続機能を提供します このサーバー プロセスは プライマリ インスタンスと同じシステム上で実行されるか Real Application Clusters を使用している場合は 別のサーバーに常駐させ 別の Oracle インスタンスを使用します 障害が発生すると クライアント マシン上の OCI ライブラリによってエラー メッセージがインターセプトされ 透過的フェイルオーバー プロセスが開始されます OCI から別の接続が要求されると リスナーは 障害が発生しなかったシステムのサーバー プロセスにクライアントを接続します このリスナーが接続に失敗した場合 OCI ライブラリはクラスタ内の別のシステム上のバックアップ リスナーに接続します これは 障害発生時にバックアップ サービスを接続するための IP フェイルオーバーまたは Network Services 機能を使用します 別のサーバーへのフェイルオーバーには 遅延が伴うことがあります 接続が切断された場合 Oracle では フェイルオーバーが実行中であるため フェイルオーバーが完了するまで待機するようにユーザーに指示するコールバック関数を実行します ユーザーは この遅延がクライアント障害であるとみなすため クライアントを再起動することはありません クライアント アプリケーション開発者は このコールバック関数を OCI に登録できます この登録された関数は フェイルオーバー実行中にライブラリよりコールされます 新規接続が確立されアクティブ化されると クライアント アプリケーションからフェイルオーバーを見えなくするその他の操作が OCI によって実行されます パッケージおよびセッション状態のリストアデータベース サーバーは ステートレスなアプリケーションではありません 準備済みカーソル PL/SQL パッケージの状態 言語環境の設定など 各クライアント セッションの状態はデータベースに保持されます 準備済みカーソルは透過的に復元され パッケージおよびセッション状態は フェイルオーバー完了後に登録済みのコールバック関数によってリストアされます コールバック関数は ライブラリから渡されるパラメータを使用してコールのコンテキストを判断し 障害発生中に消失したすべてのパッケージ状態を回復します さらに この 透過的アプリケーション フェイルオーバー 4

時点でコールバック関数によって ALTER SESSION コマンドを再実行することもできます このコマンドは 通常 クライアント アプリケーションがデータベースに最初に接続するときに実行されます この関数を使用して フェイルオーバーが完了したことや 何らかの理由でフェイルオーバーが正常に実行されなかったためにフェイルオーバーが実行できなかったことをユーザーに通知できます クライアント アプリケーションによって データベースとのセッションが複数確立されている場合 OCI ライブラリは セッションがフェイルオーバーされるたびにこの関数をコールします これも 目的の ALTER SESSION コマンドをこの関数に再実行させるためのコールです 図 2 に示すように TAF は障害の発生後 コールバック関数を使用してサーバー上のアプリケーションの状態を保持します 従来の IP フェイルオーバーの手法のみでは 状態はデータベースに保持されず 障害をクライアント アプリケーションから完全に見えなくすることはできません マシン A マシン B フェイルオーバー前 : 状態は クライアントとデータベースに保持される 手動による接続 自動再接続 マシン A マシン B マシン A マシン B TAF を使用しない場合 : クライアントは再接続できるが データベース上のアプリケーションの状態は失われる TAF を使用した場合 : データベース上のアプリケーションの状態は保持される 図 2: アプリケーションの状態の保持. 再開可能な問合せ TYPE パラメータを SELECT に設定して TAF を構成した場合 障害発生時にオープンしていたカーソルは障害の発生後 OCI ライブラリによって暗黙的にカレント行に戻されます 図 3 に示すように オープンしていたカーソルは再実行され 障害の発生前にアプリケーションに戻された行は破棄されます これにより アプリケーションはオープンしているカーソルから結果セットをフェッチし 次の行を取得します このとき ユーザーは 1 つの SELECT 文のみが結果セットを返したと解釈します Oracle の読取り一貫性機能により 2 回目以降の実行によって返される結果は 必ず元の SELECT 文から返された結果と同じになります アプリケーションから発行された問合せに ORDER BY 句が指定されていても 2 つの問合せの順序一貫性によって 同じ行が 2 回目以降の問合せの結果セットから 透過的アプリケーション フェイルオーバー 5

破棄されます 最終チェックとして OCI ライブラリでは破棄された行のチェッ クサムを計算し すでに返された破棄済みの行と比較します この時点で不一致が見つかると エラーが返されます クライアント 消失消失フェイルオーバー発生時に一部返された行 インスタンス 1 インスタンス 2 破棄破棄破棄破棄 残りの行を継続して返す 図 3: 透過的な問合せ セッションの移行透過的アプリケーション フェイルオーバーでは 管理者はインスタンス間でセッションを移行できます これは ロード バランシングやインスタンスまたはシステムのメンテナンスを準備する際に役立ちます 個別のセッション またはすべてのセッションを切断できます TAF によって これらのセッションは 別のインスタンスまたはスタンバイ データベースやレプリカ データベースで再確立されます システム メンテナンスの準備では すべてのセッションの移行が完了するとデータベースは停止します その後 管理者はメンテナンス作業を実行できます この移行作業は アクティブな更新トランザクションがすべて完了するまで延期することができます これにより フェイルオーバーはエンド ユーザーに対して透過的に機能します TAF の構成 TAF の構成は クライアントがデータベースの接続に使用する接続字列内に指定します 管理者は セッションを再確立し SELECT 文を再実行する セッションのみを再確立する 自動フェイルオーバーを実行する いずれかを接続文字列内に指定できます LDAP サーバーを使用して接続文字列の別名を指定すると 管理者は ネットワーク上のすべてのクライアントに対して TAF を簡単に設定できます 透過的アプリケーション フェイルオーバー 6

サポートされる構成透過的アプリケーション フェイルオーバーは 様々なシステム構成に実装できます 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 に含まれています 透過的アプリケーション フェイルオーバー 7

FAILOVER_MODE パラメータ FAILOVER_MODE パラメータは 接続ディスクリプタの CONNECT_DATA 部分 に含める必要があります 次のパラメータを FAILOVER_MODE に含めることが できます tnsnames.ora ファイル パラメータ 説明 TYPE( 必須 ) METHOD BACKUP RETRIES DELAY フェイルオーバーのタイプを指定します Oracle Call Interface (OCI) アプリケーションでは デフォルトで次の 3 種類の Net8 フェイルオーバー機能が使用できます SESSION: セッションをフェイルオーバーします つまり ユーザーの接続が失われた場合 バックアップ インスタンスにそのユーザーの新しいセッションが自動的に作成されます このフェイルオーバーのタイプでは SELECT のリカバリは試行しません SELECT: カーソルをオープンしているユーザーは 障害発生後もカーソルを継続的にフェッチできます ただし このモードでは通常の SELECT 処理で クライアント側にオーバーヘッドが発生します NONE: フェイルオーバー機能を使用しないデフォルト設定です フェイルオーバーの発生を防ぐために 明示的に指定することもできます プライマリ ノードからバックアップ ノードへのフェイルオーバーの処理時間を設定します BASIC: フェイルオーバー時に接続を確立します このオプションの場合 フェイルオーバーが発生するまで バックアップ サーバーに負荷はほとんどかかりません PRECONNECT: 接続を事前に確立します フェイルオーバーの処理時間を短縮します ただし バックアップ インスタンスは サポート対象のすべてのインスタンスからの接続をサポートする必要があります バックアップ接続の別のネット サービス名を指定します BASIC メソッドには BACKUP を指定することを強くお薦めします このパラメータを指定しないと 接続に失敗したインスタンスに対して再接続が最初に試行され クライアントが再接続されるまでにさらに時間がかかる可能性があります LOAD_BALANCING が ON の場合 BACKUP を指定することはできません 接続の試行回数を指定します DELAY が指定されている場合 RETRIES はデフォルトで 5 回に設定されます この設定は 障害発生後の再接続のみで 初回の接続試行には影響しません コールバックが登録されている場合 このパラメータは無視されます 接続に失敗後 次の接続を試行するまでの待機時間を秒数で指定します RETRIES が指定されている場合 DELAY はデフォルトで 1 秒に設定されます コールバックが登録されている場合 このパラメータは無視されます 接続時フェイルオーバーおよびクライアント ロード バランシングを行う TAF の実装 TAF は 接続時フェイルオーバーおよびクライアント ロード バランシングを複数のアドレスに組込み実装することができます 次の例では Net8 は sales1-server または sales2-server のリスナー アドレスにランダムに接続します 接続後 インスタンスに障害が発生すると Net8 は他のノードのリスナーにフェイルオーバーし 処理中であった SELECT 文の処理を再開します 透過的アプリケーション フェイルオーバー 8

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 文の処理を再開します 透過的アプリケーション フェイルオーバー 9

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 エラーが発生した場合 ロールバック後にトランザクションの再試行が必要です すでに様々なアプリケーションで 同じロールバック / リトライ手法を使用して データベースから報 透過的アプリケーション フェイルオーバー 10

告されるデッドロック エラーを処理しています アプリケーションが TAF で報告されるエラーに対応するために デッドロック エラーに関する現行のプログラム ロジックを修正することができます 現行のプログラム ロジックに デッドロック エラーに対応するものがない場合 たとえば 単にエラーを報告しデータベース接続をクローズするアプリケーションの場合は 同様の基本的な手法を使用して TAF エラーに対処するのも 1 つの方法です 用語アクティブなトランザクション非アクティブなトランザクションアクティブな接続非アクティブな接続. 説明 1 つ以上のデータベース更新が実行されました データベース更新は実行されませんでした COMMIT または ROLLBACK を実行して 1 つ前のアクティブなトランザクションを完了後に 問合せが行われた可能性があります 障害発生時に クライアント / サーバー データベースの相互作用がアクティブ状態です 障害発生時に クライアント / サーバー データベースの相互作用はアクティブ状態になっておらず クライアントとサーバーがアイドル状態です 障害発生時に 接続でアクティブなトランザクションが存在する場合 : トランザクションがロールバックされます 次の情報に関するエラーが報告されます アクティブな接続を対象とした現在のデータベースの相互作用 非アクティブな接続を対象とした次のデータベースの相互作用 アプリケーションは 後続のデータベース相互作用が正常に実行される前に ROLLBACK 文を発行する必要があります 障害発生時に 接続で非アクティブなトランザクションが存在する場合 : Oracle Net の構成パラメータによっては エラーの報告は必要ありません アプリケーションは 通常の方法でデータベース更新を実行し 新規のアクティブなトランザクションを開始できます ネットワークシステムのクラッシュまたはネットワーク障害が発生した場合 接続先のネットワークは障害を迅速に識別する以外に対応する方法がありません Real Application Clusters とともに Oracle Database 10g Release 2 を使用する場合 クライアントは FAN イベントをサブスクライブし ( 次を参照 ) 障害発生通知を受け取ることができます ただし 使用するデータベースおよびクライアントが Release 10.2 以降でない場合 タイムアウトの期限が切れるため クライアント自身が障害を識別する必要があります タイムアウトは 障害発生時のクライアントの状態によって異なります クライアントの状態には次の状態があります 透過的アプリケーション フェイルオーバー 11

Disconnected: 現在 クライアントは 障害が発生したノードに接続されていない状態 Connected/with interrupt: 停止状態になったノードにクライアントが接続されている状態 障害発生時 ソケットはクローズされます クライアントに対し割込みが送信され 接続がクローズされます Connected/no interrupt/not waiting: 停止状態になったノードにクライアントが接続されている状態 ただし read() または write() の呼出しが戻るのを待っていません 停止状態になったノードでは ソケットをクローズできない状態 ( カーネル パニックなど ) になります 次回 セッションがインスタンスと通信する場合は そのインスタンスが使用不可であることを検出してから 通信を試行します Connected/no interrupt/waiting: 停止状態になったノードにクライアントが接続され read() または write() の呼出しが戻るのを待っている状態 停止状態になったノードでは ソケットをクローズできない状態 ( カーネル パニックなど ) になります 障害が発生したことを検出するまで セッションは待機し バックアップ インスタンスとの接続を試行します 次の表に 各シナリオの動作を説明します デフォルト値は HP に対する値です 障害発生時のクライアントの状態 動作 遅延に影響を与える TCP パラメータ デフォルト (HP) クライアントは 障害が発生したノードの IP アドレスを使用してノードへの接続を 試行する場合 tcp_ip_abort_cinterval に設 Disconnected 定されている値を超えるまで 接続が正常に実行されるのを待ちます その後 クライアントは接続に失敗しますが (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 シナリオに説明したように クライアント 透過的アプリケーション フェイルオーバー 12

は接続に失敗したノードとの再接続を試行し 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 コマンドの効果の消失 コールバック関数は フェイルオーバー時にトリガーされるように登録できます この関数によって 一部の消失した状態を再作成できます 透過的アプリケーション フェイルオーバー 13

TAF エラー コード TAF から出力されるエラー コードの範囲は ORA-25400~ORA-25425 です 既存の接続で障害の発生後にエラー コードが出力された場合 TAF は接続をフェイルオーバーできません その場合 アプリケーションは接続が消失したと推測します したがって ロールバック / リトライ メカニズムは使用できません TAF より実際に出力が予想されるエラー コードは 次のとおりです エラー コードエラー メッセージ注記 ORA-25401 ORA-25402 ORA-25405 ORA-25408 ORA-25425 フェッチを継続できません トランザクションをロールバックする必要があります トランザクションのステータスが不明です 呼出しを安全に再実行できません ロールバック中に接続が失われました 通常 アクティブなトランザクションのないアクティブな接続に対する問合せを行った Oracle Net の TYPE が SESSION に設定されている場合に出力されます 最も一般的なエラー コード ROLLBACK が実行されるまで 後続のすべてのデータベース相互作用について報告されます COMMIT 操作時間は短いため このコードが出力されることはほとんどありません アクティブなトランザクションを作成する初回のデータベース更新のみに出力されます 障害発生時 またはフェイルオーバー後 ( ただし他のデータベースの相互作用が行われる前 ) に ROLLBACK 操作が実行される可能性は低いため このコードが出力されることはほとんどありません TAF 以外のエラー コード TAF が新しい接続を確立できない場合は 前述したエラー メッセージ以外のメッセージが出力されます これらのエラー コードは TAF エラーではありませんが 通常は Oracle データベースとの接続の初回の試行時に報告されるエラーと同じです TAF が新しい接続を確立できないと考えられる理由は 次のとおりです Oracle Net の TAF 構成パラメータの制限 ( 例 : コールド フェイルオーバー クラスタの RETRIES パラメータや DELAY パラメータの設定不良 ) ターゲット データベースのインスタンスは適切な Oracle Net リスナーに登録されているが 可用性に制限があるか または起動中か停止中 ターゲット データベースのインスタンスも使用できない Oracle Net の TAF 構成パラメータに構文エラーがある場合 TAF は新しい接続を確立できないように見えることもあります その場合 アプリケーションは接続が消失したと推測します したがって ロールバック / リトライ メカニズムは使用できません 透過的アプリケーション フェイルオーバー 14

発生する可能性が高いエラー条件を次に示します ただし サイト固有の構成上の問題に関連した Oracle Net のエラーは含まれていません エラー コード ORA-01012 ORA-01033 ORA-01034 ORA-01089 ORA-03113 ORA-03114 ORA-12203 ORA-12500 ORA-12571 ORA-12153 エラー メッセージログオンされていません Oracle の初期化またはシャットダウン中です Oracle は使用できません 即時シャットダウン処理中 - 操作はできません 通信チャネルで end-of-file が検出されました Oracle に接続されていません TNS: 接続先に接続できません TNS: リスナーが専用サーバー プロセスの起動に失敗しました TNS: パケット ライターに障害が発生しました 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 は タイムアウ 透過的アプリケーション フェイルオーバー 15

ト時間が経過するのを待たずにクライアントを中断し 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 のその他の高可用性機能によって クリティカルなデータへの常時アクセスが保証されます 透過的アプリケーション フェイルオーバー 16

透過的アプリケーション フェイルオーバー 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 および関連会社の登録商標です 他の製品名は それぞれの所有者の商標です