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

Size: px

Start display at page:

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

きみおあみおか
5 years ago
Views:

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

2 透過的アプリケーションフェイルオーバー概要... 3 フェイルオーバーの概念... 3 TAF 機能... 4 自動再接続... 4 パッケージおよびセッション状態のリストア... 4 再開可能な問合せ... 5 セッションの移行... 6 TAF の構成... 6 サポートされる構成層環境... 7 透過的アプリケーションフェイルオーバーの構成... 7 FAILOVER_MODE パラメータ... 8 接続時フェイルオーバーおよびクライアントロードバランシングを行う TAF の実装... 8 接続の再試行... 9 接続の事前確立... 9 検証特別な考慮事項トランザクションネットワークセッション状態 TAF エラーコード TAF 以外のエラーコードサーバー ( シャドウ ) プロセス障害 Fast Application Notification Fast Connection Failover 結論透過的アプリケーションフェイルオーバー 2

透過的アプリケーションフェイルオーバー概要企業のデータベースシステムへの依存度が高まるにつれサービスの中断によって起こる混乱はますます深刻になります Oracle Database 10g にはエンドユーザーへの影響を最小限に抑えてシステム障害からアプリケーションをリカバリする様々な可用性機能が実装されています中断を最小限に抑えるということはリカバリ時間の短縮だけではなく

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

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

5 時点でコールバック関数によって 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 の構成は

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

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

8 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

9 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

10 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

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

12 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

13 は接続に失敗したノードとの再接続を試行し 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

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

15 発生する可能性が高いエラー条件を次に示しますただしサイト固有の構成上の問題に関連した Oracle Net のエラーは含まれていませんエラーコード ORA ORA ORA ORA ORA ORA ORA ORA ORA ORA エラーメッセージログオンされていません 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

16 ト時間が経過するのを待たずにクライアントを中断し 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

17 透過的アプリケーションフェイルオーバー 2006 年 6 月著者 : Bob Thome 寄稿者 : Mike Hallas Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. 海外からのお問合せ窓口 : 電話 : ファックス : Copyright 2006, Oracle. 無断転載を禁ずこの文書はあくまで参考資料であり掲載されている情報は予告なしに変更されることがありますオラクル社は本ドキュメントの無謬性を保証しませんまた本ドキュメントは法律で明示的または暗黙的に記載されているかどうかに関係なく商品性または特定の目的に対する適合性に関する暗黙の保証や条件を含む一切の保証または条件に制約されませんオラクル社は本書の内容に関していかなる保証もいたしませんまた本書により契約上の直接的および間接的義務も発生しません本書は事前の書面による承諾を得ることなく電子的または物理的にいかなる形式や方法によっても再生または伝送することはできません Oracle JD Edwards PeopleSoft は Oracle Corporation および関連会社の登録商標です他の製品名はそれぞれの所有者の商標です

Oracle DatabaseとIPv6 Statement of Direction

Oracle DatabaseとIPv6 Statement of Direction Oracle ホワイトペーパー 2017 年 10 月 Oracle Database と IPv6 Statement of Direction 免責事項下記事項は弊社の一般的な製品の方向性に関する概要を説明するものですまた情報提供を唯一の目的とするものでありいかなる契約にも組み込むことはできませんマテリアルやコード機能の提供をコミットメント ( 確約 ) するものではなく購買を決定する際の判断材料になさらないで下さい