| Oracle Database高可用性ベスト・プラクティス 11gリリース2(11.2) B65088-05 |
|
 前 |
 次 |
この章で説明する手順では、クライアント・バージョンおよびデータベース・バージョンが11.2.0.1以上であることを前提としています。リリース11.2.0.1には、11.1.0.7以下のリリースと比較して次のような機能が用意されています。
ロールベースのサービス
FAN ONSイベントをJDBCクライアントに送信するData Guardブローカ
SCANアドレスのサポート
以前のバージョンには前述の機能がありませんが、手動構成で同様の結果を導くことが可能です。たとえば、次のようになります。
データベース・ロールに基づくサービスの停止および起動を管理するトリガーを作成します。
フェイルオーバーが発生した後で、外部ONSパブリッシャを利用してFANイベントを送信します。
プライマリになる可能性のあるすべてのホストが含まれる、Oracle Net別名の作成。
11.2.0.1より前のリリースを構成する手順は、次のWebサイトのMAAホワイト・ペーパー『可用性の高いOracle Databaseのためのクライアント・フェイルオーバーのベスト・プラクティス: Oracle Database 10gリリース2』を参照してください。
http://www.oracle.com/goto/maa
障害のタイプ
Oracle Databaseインスタンスの計画外の障害は一般的なカテゴリに分類されます。
Oracle RACデータベース内の個々のOracleインスタンスのクラッシュを引き起こす、サーバー障害またはその他の障害。可用性を維持するため、障害が発生したインスタンスに接続中のアプリケーション・クライアントには障害について迅速に通知し、Oracle RACデータベースの動作可能なインスタンスへの新規接続をすぐに確立する必要があります。
アプリケーション層およびデータベース層の両方を使用不可状態にする、完全サイト障害。可用性を維持するため、本番データベースの冗長アプリケーション層と同期コピーをホスティングするセカンダリ・サイトに、ユーザーをリダイレクトする必要があります。
プライマリ・データベース、単一インスタンス・データベース、またはOracle RACデータベース内の全ノードが使用不可になりますが、プライマリ・サイトのアプリケーション層は元のまま残される、部分サイト障害。
Oracle RACおよびOracle Data Guardでインスタンスとデータベースの高速フェイルオーバーおよびスイッチオーバーの効果を最大化するには、ベスト・プラクティスとして高速接続フェイルオーバーを構成します。高速接続フェイルオーバーを使用すると、データベース・サービスが使用不可能になった場合に、クライアント(中間層アプリケーションまたはデータベースに直接接続する任意のプログラム)を迅速かつシームレスに使用可能なデータベース・サービスにフェイルオーバーできます。
この章には、次の項目が含まれます。
|
関連項目:
|
高速接続フェイルオーバーを有効にする構成のベスト・プラクティスは、クライアントのタイプ(JDBCまたはOCI)によって異なります。
JDBCクライアントでの高速接続フェイルオーバー
JDBCクライアントでは、次のベスト・プラクティスに従います。
JDBCクライアントで高速接続フェイルオーバーを有効化するため、DataSourceプロパティのFastConnectionFailoverEnabledをTRUEに設定します。
JDBCクライアントを構成して、各サイトのSCANアドレスが順番に記載された、既存のサービスに接続するためのアドレス・リストを含む接続記述子を使用します。
JDBCクライアントはoracle.net.ns.SQLnetDef.TCP_CONNTIMEOUT_STRプロパティを設定する必要があります。このプロパティによって、障害発生時にJDBCクライアントが迅速にADDRESS_LISTを横断できます。
Oracle Notification Service(ONS)デーモンがクライアントで必要とされることのないように、JDBCクライアントでリモートONSサブスクリプションを構成します。
デフォルトでJDBCアプリケーションはsetONSConfigurationプロパティから3つのホストをランダムに選択し、その3つのONSデーモンへの接続を作成します。このデフォルトを変更して、接続がすべてのONSデーモンに対して行われるようにします。これを実行するには、JDBCアプリケーションの起動時に、次のプロパティを構成内のONSデーモンの合計数に設定します。
java - oracle.ons.maxconnections=4
|
関連項目:
|
OCIクライアントでの高速接続フェイルオーバー
OCIクライアントでは、次のベスト・プラクティスに従います。
OCIクライアントで高速アプリケーション通知(FAN)を有効化するため、OCI_EVENTSパラメータで環境を初期化します。
OCIクライアント・アプリケーションをスレッド・ライブラリにリンクします。
AQ_HA_NOTIFICATIONSパラメータをTRUEに設定し、サービスで透過的アプリケーション・フェイルオーバー(TAF)属性を構成します。
OCIアプリケーションでデータベースへの接続に使用されるOracle Net別名を構成します。Oracle Net別名ではプライマリおよびスタンバイの両方のSCANホスト名を指定する必要があります。新規接続の作成で最高のパフォーマンスを得るには、Oracle Net別名でDESCRIPTION_LISTに対してLOAD_BALANCE=OFFを保持し、DESCRIPTIONsが整列されたリストで上から下に試行されるようにします。この構成では、2番目のDESCRIPTIONは、1番目のDESCRIPTIONに対するすべての接続が失敗した場合にのみ、試行されます。
|
関連項目:
|
Oracle Database 11gは、Oracle Real Application Clusters (Oracle RAC)およびOracle Data Guardにおけるアプリケーション・データの高度な可用性を可能にするインフラストラクチャを備えています。データベース層で高速アプリケーション・フェイルオーバーを構成する必要があります。
上位レベルにおけるOracle RAC構成でのクライアント・フェイルオーバーの自動化には、新規インスタンスまたは動作可能インスタンスへのデータベース・サービスの再配置、TCPタイムアウトからクライアントを解放するための障害発生のクライアントへの通知、動作可能インスタンスへのクライアントのリダイレクトが含まれます(Oracle ClusterwareはFANメッセージをアプリケーションに送信します。アプリケーションはFANイベントに応答してすぐに処理を行います)。FANの詳細は、6.1.1項「クライアントの構成および移行の概要」を参照してください。
Oracle RACデータベース上のサービスについては、Oracle Enterprise ManagerまたはSRVCTLユーティリティが推奨されるサービス管理ツールです。単一のサービスをOracleデータベースの1つ以上のインスタンスに適用し、単一のインスタンスで複数のサービスをサポートできます。サービスを提供するインスタンスの数は、アプリケーションとは関係なくDBAによって管理されます。
サーバー側コールアウトは、Oracle Clusterwareを構成する高可用性フレームワークとの単純かつ強力な統合メカニズムを提供します。サーバー側コールアウトの使用によって、トラブル・チケットを記録するか、管理者にページングして障害を警告することができます。UPイベントでは、サービスおよびインスタンスが起動された場合に新しい接続を作成して、新しく使用可能になったリソースをアプリケーションでただちに使用できます。
|
関連項目:
|
Oracle Data Guard環境を構成するには、次の作業を実行します。
|
関連項目: 次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『Data Guard 11gリリース2のクライアント・フェイルオーバーのベスト・プラクティス』を参照してください。 |
Oracle Data Guard構成では、プライマリ・データベースではプライマリ・アプリケーション・サービスを、スタンバイ・データベースではスタンバイ・アプリケーション・サービスのみを実行します。Data Guard 11gリリース2以降では、データベース・ロールを各サービスに割り当てることで、プライマリ・データベースおよびスタンバイ・データベース上のデータベース・サービスの起動を自動的に制御できます(ロールにはPRIMARY、PHYSICAL_STANDBY、LOGICAL_STANDBYおよびSNAPSHOT_STANDBYが含まれます)。
サービスの管理ポリシーがAUTOMATICであり、そのサービスに割り当てられているロールがデータベースの現行のロールに一致する場合、データベースを起動するとデータベース・サービスが自動的に起動されます。
|
関連項目:
|
Oracle Data Guardブローカを使用して構成を管理するように、Oracle Data Guardを構成することがベスト・プラクティスです。Oracle Data Guardブローカではクライアント・アプリケーションにFANイベントを送信することで、停止したデータベースへの接続がクリーン・アップされ、新規の本番データベースに再接続されます。FANの詳細は、6.1.1項「クライアントの構成および移行の概要」を参照してください。
単一インスタンス(Oracle Restartを使用)とOracle RACデータベースの両方に対して、Oracle Clusterwareがインストールされ、プライマリ・サイトおよびスタンバイ・サイトでアクティブになっている必要があります。Oracle Data GuardブローカはOracle Clusterwareと連動して、Data Guardフェイルオーバーの発生後、ロールベースのサービスを新規プライマリ・データベースへ適切にフェイルオーバーします。詳細は、次を参照してください。
Oracle Data Guardでは、スイッチオーバーという用語は、プライマリ・データベースとスタンバイ・データベースでロールがスイッチされる計画済イベントを表し、通常は計画済メンテナンスの実行中の停止時間を最小限に抑えることが目的です。計画外のフェイルオーバーに対応するための構成ベスト・プラクティスは、計画済スイッチオーバーのほとんどの要件にも対応しますが、ロジカル・スタンバイ・データベースに適用されるいくつかの追加的な手動手順は例外です(SQL Apply)。
|
注意: Oracle Active Data Guardを使用するスイッチオーバーに関するその他の考慮事項はありません。 |
次の手順は、Oracle Data Guard 11gリリース2における追加的な手動のスイッチオーバー手順です。
プライマリ・データベースがスタンバイ・データベースに変換されます。これによってすべてのセッションが切断され、データベースがマウント状態にされます。Oracle Data Guardブローカがあらゆる読取り/書込みサービスを停止します。
クライアント・セッションがORA-3113を受け取り、再試行ロジック(OCIの場合はTAF、JDBCの場合はアプリケーション・コード・ロジック)が開始されます。
スタンバイ・データベースがプライマリ・データベースに変換され、存在するすべてのセッションが切断されます。Oracle Data Guardブローカが読取り専用サービスを停止します。
読取り専用接続がORA-3113を受け取り、再試行ロジック(OCIの場合はTAF、JDBCの場合はアプリケーション・コード・ロジック)が開始されます。
新規プライマリおよび新規スタンバイがオープンされるに従って、個々のサービスが各ロールに対して開始され、再試行を実行するクライアントではサービスが使用可能であることが確認され、接続されます。
ロジカル・スタンバイ・スイッチオーバーの場合:
適切な再接続ロジックが構成されていることを確認します(詳細は、11.1項「JDBCとOCIクライアントへのフェイルオーバーの構成」と11.2項「Oracle RACデータベースのフェイルオーバーの構成」を参照してください)。たとえば、OCIアプリケーションの場合はTAFおよびRETRY_COUNTを構成し、JDBCアプリケーションの場合はコード再試行ロジックを構成します。
プライマリ・アプリケーションで使用されるサービスと、スタンバイ・データベースで有効になっている読取り専用アプリケーションを停止します。
プライマリ・アプリケーションおよび読取り専用アプリケーションのセッションを切断するか、停止します。
スイッチオーバーが完了したら、プライマリ・アプリケーションおよび読取り専用アプリケーションで使用されるサービスを再起動します。
終了されたセッションは、サービスが使用可能になると再試行メカニズムの一環として再接続します。
アプリケーションが停止している場合は、アプリケーションを再起動します。
アプリケーションが再試行を実行する場合、スイッチオーバー操作中の移行クライアントにFANは必要ありません。FANが必要なのはTCPタイムアウトからクライアントを解放する場合のみで、この状態は計画外の停止中のみ発生します。
多数の接続があるアプリケーションのフェイルオーバー・プロセスにより、ログイン・ストームが発生することがあります。ログイン・ストームとは、データベース・インスタンスへの接続数が急激に増加し、CPUリソースを消費しつくしてしまうことです。CPUリソースが枯渇すると、アプリケーション・タイムアウトとアプリケーション・レスポンス時間が増加する可能性が高くなります。
ログイン・ストームを制御する手順:
ログイン・ストームを制御する主要な方法は、Oracleリスナーの接続速度リミッタ機能を実装することです。この機能は、1秒に処理できる接続の数を制限します。接続速度を低下させることで、CPUリソースが利用可能な状態に維持され、システムが無反応になりません。
Oracle Databaseに共有サーバー運用を構成します。
接続速度リミッタを実装する他、一部のアプリケーションでは、Oracle Databaseに共有サーバー運用を構成することによって、ログイン・ストームを制御することができます。共有サーバーを使用すると、フェイルオーバー時間に作成する必要があるプロセスの数が大幅に減少します。
中間層接続プールの最大接続数を調整します。
ご使用のアプリケーションの中間層でそうした機能を利用できる場合、中間層接続プールの最大接続数を調整することによって接続数を制限してみます。
現在、PeopleSoft EnterpriseとOracle WebLogic ServerがFANイベントをサポートしています。
PeopleSoft PeopleToolsリリース8.50.09以上がFANをサポートしています。これによって、PeopleSoftアプリケーションではデータベース接続が切断された場合、データベース接続をOracle RACクラスタ内の動作可能インスタンス、またはOracle Data Guard構成内の新規プライマリ・データベースに自動的にフェイルオーバーできます。Oracle RACインスタンス障害、プライマリ・データベース障害、またはOracle Databaseの停止や再起動の場合、PeopleSoftサーバーおよびクライアントは引き続き稼働し、ユーザーが再度ログインする必要はありません。
Oracle WebLogic Server 10.3.4では、Oracle RACクラスタのサポートのために単一のデータ・ソース実装が導入されています。これはFANイベントに応答して、高速接続フェイルオーバー(FCF)、ランタイム接続ロード・バランシング(RCLB)、およびOracle RACインスタンスのすみやかな停止を提供します。XAアフィニティがグローバル・トランザクションIDレベルでサポートされています。この新機能はWebLogic Active GridLink for Oracle RACと呼ばれ、Oracle WebLogic Server内のGridLinkデータ・ソースとして実装されます。
FANイベントをサポートしないアプリケーションについては、Oracleの多数のアプリケーション(たとえば、SiebelやOracle E-Business Suite)が該当し、この項で説明されているすべての手順は最速のクライアント・フェイルオーバーのために完了する必要があります。このようなケースでFANイベントを使用できない場合でも、タイムアウトやアプリケーション再試行を使用することで、効率的なフェイルオーバーのためにアプリケーションを構成できます。
詳細は、次のWebサイトのMAAホワイト・ペーパー『可用性の高いOracle Databaseのためのクライアント・フェイルオーバーのベスト・プラクティス: Oracle Database 11gリリース2』を参照してください。
