| Oracle® Database高可用性ベスト・プラクティス 12cリリース1 (12.1) E57730-02 |
|
 前 |
 次 |
この項では、Data Guard/Active Data Guardのロール移行が発生した後、障害が発生したプライマリ・データベースから新しいプライマリ・データベースにアプリケーションの接続を自動で移行するためのOracle Database 12cの構成ベスト・プラクティスについて説明します。この構成は、Real Application Clustersデータベースへのクライアントの接続にも適用されます。さらに、Oracle Database 12cの新機能であるアプリケーション・コンティニュイティとトランザクション・ガードに関するベスト・プラクティスについても説明します。
Data Guard構成でのクライアント・フェイルオーバーの自動化の概要は、Data Guardフェイルオーバーの一部として新しいプライマリ・データベースへのデータベース・サービスの再配置、TCPタイムアウトからクライアントを解放するための障害発生のクライアントへの通知、新しいプライマリ・データベースへのクライアントのリダイレクトとなります。
次の各項では、Data Guard構成でのOCIとJDBCの両アプリケーションに対するロールベースのデータベース・サービスの作成方法について説明します。その後の各項では、OCIおよびJDBCクライアントがFAN通知を受信して新しいプライマリ・データベースに再接続できるようにするための構成手順を詳しく説明します。
障害のタイプ
Oracle Databaseインスタンスの計画外の障害は、次のような一般的なカテゴリに分類されます。
Oracle RACデータベース内の個々のOracleインスタンスのクラッシュを引き起こす、サーバー障害またはその他の障害。可用性を維持するため、障害が発生したインスタンスに接続中のアプリケーション・クライアントには障害について迅速に通知し、Oracle RACデータベースの動作可能なインスタンスへの新規接続をすぐに確立する必要があります。
アプリケーション層およびデータベース層の両方を使用不可状態にする、完全サイト障害。可用性を維持するため、本番データベースの冗長アプリケーション層と同期コピーをホスティングするセカンダリ・サイトに、ユーザーをリダイレクトする必要があります。
プライマリ・データベース、単一インスタンス・データベース、またはOracle RACデータベース内の全ノードが使用不可になりますが、プライマリ・サイトのアプリケーション層は元のまま残される、部分サイト障害。
Oracle RACおよびOracle Data Guardでインスタンスとデータベースの高速フェイルオーバーおよびスイッチオーバーの効果を最大化するには、ベスト・プラクティスとして高速接続フェイルオーバーを構成します。高速接続フェイルオーバーを使用すると、データベース・サービスが使用不可能になった場合に、クライアント(中間層アプリケーションまたはデータベースに直接接続する任意のプログラム)を迅速かつシームレスに使用可能なデータベース・サービスにフェイルオーバーできます。
この章には、次の項目が含まれます。
|
関連項目:
|
OCI、JDBCおよびODP.Netアプリケーション・クライアントがFAN通知を受信して新しいプライマリ・データベースに短時間で再接続できるようにすることが可能です。高速接続フェイルオーバーを有効にする構成のベスト・プラクティスは、クライアント・タイプによって異なります。
|
関連項目:
|
前提条件:
ユニバーサル接続プール(UCP 12.1.0.2以降)が有効になっていること
アプリケーションがデータベースへの接続にサービス名を使用していること
JDBCが稼働しているノードでOracle Notification Service(ONS)が構成されており、使用可能であること
JDBCインスタンスが稼働しているJava仮想マシン(JVM)で、oracle.ons.oraclehomeがORACLE_HOMEを指すように設定されていること
高速接続フェイルオーバー(FCF)を有効にし、setONSConfigurationプロパティを使用して、プライマリとスタンバイの両クラスタに対するすべてのONSデーモンに接続するようにJDBCアプリケーションを構成します。setONSConfigurationプロパティは、プライマリおよびスタンバイのすべてのONSデーモンを指している必要があります。
pds.setONSConfiguration("nodes=adczatdb01:6200,adczatdb02:6200,slcc17adm01:6200,slcc17adm02:6200");
pds.setFastConnectionFailoverEnabled(true);
デフォルトでは、JDBCアプリケーションはsetONSConfigurationプロパティから3つのホストをランダムに選択し、その3つのONSデーモンへの接続を作成します。すべてのONSデーモンに対して接続を作成するように、このデフォルトを変更する必要があります。これを実行するには、JDBCアプリケーションの起動時に、次のプロパティを構成内のONSデーモンの合計数に設定します。
java -Doracle.ons.maxconnections=4
JDBCクライアントはoracle.net.ns.SQLnetDef.TCP_CONNTIMEOUT_STRプロパティを設定する必要があります。このプロパティによって、障害発生時にJDBCクライアントが迅速にADDRESS_LISTを横断できます。たとえば、クライアントが使用不能なホストに接続しようとすると、接続の試行はSQLnetDef.TCP_CONNTIMEOUT_STRプロパティによって指定された時間までに制限され、それを過ぎるとクライアントはADDRESS_LISTの次のホストに接続しようとします。接続が作成されるまで、この動作はADDRESS_LISTの各ホストに対して続きます。プロパティの値を3秒に設定すれば、ほとんどの環境では十分です。SQLnetDef.TCP_CONNTIMEOUT_STRプロパティをユニバーサル接続プールではなく、データソースに対して設定することが重要です。
Properties prop = new Properties(); prop.put(oracle.net.ns.SQLnetDef.TCP_CONNTIMEOUT_STR, ""+3000); // 3000ms pds.setConnectionProperties(prop);
SCANロード・バランシングから適切な動作を得られるようにthinForceDNSLoadBalancingプロパティを設定します。
// need to set oracle.jdbc.thinForceDNSLoadBalancing
prop.put("oracle.jdbc.thinForceDNSLoadBalancing","true");
JDBCクライアントを構成して、各サイトのSCANアドレスが順番に記載された、既存のサービスに接続するためのアドレス・リストを含む接続記述子を使用します。JDBCシック・クライアントを使用する場合、TAFとJDBC FCFの両方を構成しないでください。
次のURLをプライマリとスタンバイの両サイトで検索し、オーバーヘッドがほとんどない適切なサービスを探します。このURL構成は、推奨される方法です。
PoolDataSource pds = PoolDataSourceFactory.getPoolDataSource();
pds.setConnectionFactoryClassName("oracle.jdbc.pool.OracleDataSource"); pds.setUser("system");
pds.setPassword("oracle");
String dbURL =
"jdbc:oracle:thin:@" +
"(DESCRIPTION=" +
"(FAILOVER=on)" +
"(ADDRESS_LIST=" +
"(LOAD_BALANCE=on)" +
"(CONNECT_TIMEOUT=3)(RETRY_COUNT=3)" +
"(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521))"+ "(ADDRESS=(PROTOCOL=TCP)(HOST= stby-scan)(PORT=1521)))" +
"(CONNECT_DATA=(SERVICE_NAME=oltpworkload)))"
System.out.println("Url=" + dbURL);
pds.setURL(dbURL);
プライマリがこれまでにセカンダリ・サイトで稼働することは非常にまれで、可能なかぎり速く接続をつなぐ必要がある場合は、次のURLを使用する必要があります。
PoolDataSource pds = PoolDataSourceFactory.getPoolDataSource();
pds.setConnectionFactoryClassName("oracle.jdbc.pool.OracleDataSource"); pds.setUser("system");
pds.setPassword("oracle");
String dbURL =
"jdbc:oracle:thin:@" +
"(DESCRIPTION_LIST=" +
"(LOAD_BALANCE=off)" +
"(FAILOVER=on)" +
"(DESCRIPTION=" +
"(CONNECT_TIMEOUT=3)(RETRY_COUNT=3)" +
"(ADDRESS_LIST=" +
"(LOAD_BALANCE=on)" +
"(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))" +
"(CONNECT_DATA=(SERVICE_NAME=oltpworkload)))" +
"(DESCRIPTION=" +
"(ADDRESS_LIST=" +
"(LOAD_BALANCE=on)" +
"(ADDRESS=(PROTOCOL=TCP)(HOST= stby-scan)(PORT=1521)))" +
"(CONNECT_DATA=(SERVICE_NAME=oltpworkload))))";
System.out.println("Url=" + dbURL);
pds.setURL(dbURL);
スイッチオーバーまたはフェイルオーバーが発生した場合、前述のURLは、プライマリが現在稼働しているスタンバイSCANを使用する前に、強制的にすべての接続を古いプライマリSCANに通すので注意してください。
|
関連項目:
|
Oracle Database 12cでアプリケーション・コンティニュイティを使用して、Oracle RACインスタンス間またはData Guardのプライマリおよびスタンバイ・データベース全体で、ローリング方式で実行される計画メンテナンスの停止をマスキングします。また、アプリケーション・コンティニュイティは、Data Guardファスト・スタート・フェイルオーバー(自動データベース・フェイルオーバー)を使用して、Oracle RACインスタンスまたは最大可用性(データ損失ゼロのフェイルオーバー)で構成されたData Guardプライマリ・データベースの計画外停止をマスキングします。Data Guardのフェイルオーバーにアプリケーション・コンティニュイティを使用するには、ソースとターゲットの両データベースがOracle 12.1.0.2以降である必要があります。
アプリケーション・コンティニュイティが使用できる対象は、次のとおりです。
Oracle JDBC Replay Driver 12c以降。これは、Oracle Database 12cに装備されているアプリケーション・コンティニュイティ用のJDBCドライバ機能で、以後"リプレイ・ドライバ"と呼びます(将来のリリースに対するOCIサポートが予定されています)。
Oracle Universal Connection Pool、Oracle WebLogic Server 12c (12.1.2)以降およびサード・パーティのJava接続プールまたはスタンドアロンJavaアプリケーション(Oracle JDBC Replay Driver 12c以降を使用)。
プールされた接続インタフェースを使用する標準的なサード・パーティのJavaアプリケーション・サーバー(12.1.0.2以降、IBM WebSphere、Apache Tomcatなど)。
プールされたデータソースとしてユニバーサル接続プールをサポートする標準的なサード・パーティのJavaアプリケーション・サーバー(IBM WebSphere、Apache Tomcat、RedHat JBossなど)。
サード・パーティのJava接続プールまたはスタンドアロンJavaアプリケーション(Oracle JDBC Replay Driver 12c以降を使用し、独自のリクエスト境界を埋め込んでいる)。
アプリケーション・コンティニュイティでは、トランザクション・ガードを使用して最終トランザクションがコミットされたかどうかを確実に判断します。トランザクション・ガードを使用しないと、停止後に操作を再試行しようとするアプリケーションおよびユーザーが、トランザクションを重複してコミットしたり、不適切な順序でトランザクションをコミットすることによって、論理破損が発生することがあります。
次の各項では、構成に応じて、Oracle JDBC 12c Replay Driverを使用してアプリケーション・コンティニュイティを構成するオプションについて説明します。
|
関連項目:
|
UCP PoolDataSourceでOracle JDBC 12cリプレイ・データソースを接続ファクトリとして構成するには、次のようにします。
setConnectionFactoryClassName("oracle.jdbc.replay.OracleDataSourceImpl");
Oracle JDBC 12cリプレイ・データソースを構成するには、Oracle WebLogic Server管理コンソールを使用します。
プロパティ・ファイルまたはシンJDBCアプリケーションでOracle JDBC 12cリプレイ・データソースを構成するには、次のようにします。
replay datasource=oracle.jdbc.replay.OracleDataSourceImpl
データベースのREMOTE_LISTENER設定には、クライアント接続に使用されるすべてのURLに対するADDRESS_LISTのアドレスを含める必要があります。
URLでSCAN名を使用する場合、REMOTE_LISTENERSにSCAN名を含める必要があります。
URLでホストVIPのADDRESS_LISTを使用する場合、REMOTE_LISTENERSにすべてのSCAN VIPとすべてのホストVIPを含むADDRESS_LISTを含める必要があります。
URLにRETRY_COUNTパラメータとCONNECT_TIMEOUTパラメータを設定して、新しい受信接続を再試行できるようにします。この属性の詳しい説明は、このドキュメントで後述するJDBCアプリケーション構成に関する項を参照してください。次に例を示します。
"jdbc:oracle:thin:@" + "(DESCRIPTION=" + "(FAILOVER=on)" + "(ADDRESS_LIST=" + "(LOAD_BALANCE=on)" + "(CONNECT_TIMEOUT=3)(RETRY_COUNT=3)" + "(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521))"+ "(ADDRESS=(PROTOCOL=TCP)(HOST= stby-scan)(PORT=1521)))" + "(CONNECT_DATA=(SERVICE_NAME=oltpworkload)))"
アプリケーション・コンティニュイティを使用するように、SRVCTL/GDSCTLを使用してサービスの属性を設定します。
FAILOVER_TYPEをTRANSACTIONに設定してアプリケーション・コンティニュイティを有効にします。
COMMIT_OUTCOMEをTRUEに設定してトランザクション・ガードを有効にします(必須)。
次のサービスの属性を確認します。
REPLAY_INITIATION_TIMEOUT: リプレイが開始されなくなるまでの期間(秒)を設定します(例: 180、300、1800秒 - リプレイを取り消すためのオーバーライド)。このタイマーはbeginRequestに開始します(デフォルトは300秒)。
FAILOVER_RETRIES: リプレイの試行ごとの接続試行回数を設定します。(デフォルトは30回の試行、リプレイ・ドライバで適用)
FAILOVER_DELAY: 接続の試行間の遅延(秒)を設定します。(デフォルトは10秒、リプレイ・ドライバで適用)
AQ_HA_NOTIFICATIONS: TRUEに設定してFANを有効にします。(デフォルトはTRUE)
次に、アプリケーション・コンティニュイティのためのサービスの構成例を示します。
srvctl add service -db mts -service oltpworkload -role PRIMARY -notification TRUE -session_state dynamic -failovertype transaction -failovermethod basic -commit_outcome TRUE -failoverretry 30 -failoverdelay 10 -replay_init_time 900 -clbgoal SHORT -rlbgoal SERVICE_TIME -preferred mts1,mts2 -retention 3600 -verbose
必要なメモリー・リソースとCPUリソースがシステムにあることを確認します。
メモリー: コールがデータベース・リクエストの最後まで保持されるため、JDBCリプレイ・ドライバはベースJDBCドライバよりも多くのメモリーを使用します。保持されるコール数が少ない場合、リプレイ・ドライバのメモリー消費量はベース・ドライバと同程度になります。リクエストの最後で、コールはガベージ・コレクタに解放されます。この処理は、コールがクローズされると解放するベース・ドライバとは異なります。
良好なパフォーマンスを得るには、十分なメモリーがある場合、仮想マシン(VM)に4から8GB (以上)のメモリーを割り当てます。たとえば、4GBであれば- Xms4096mと設定します。
CPU: JDBCリプレイ・ドライバでは、プロキシ・オブジェクトの構築、キューの管理およびガベージ・コレクションに追加CPUをいくらか使用します。サーバーでは、検証の管理に追加CPUをいくらか使用します。CPUオーバーヘッドは赤で表示されます。
前提条件
Oracle Clusterwareを備え、設定および有効化されているOracle RAC環境またはOracle Restartを備えた単一ノード(非Oracle RAC)データベース
アプリケーションがスレッド・ライブラリとリンクされていること
OCI環境がOCI_EVENTSおよびOCI_THREADEDモードで作成されていること
OCI_EVENTSパラメータで環境を初期化して、OCIクライアントのFANを有効にします。次に例を示します。
OCIEnvCreate(...OCI_EVENTS...)
OCIクライアント・アプリケーションをスレッド・ライブラリlibthreadまたはlibpthreadにリンクします。
アプリケーションには、次の例で使用されているようなコードを使用して、イベントが発生したかを確認する機能が必要です。
void evtcallback_fn(ha_ctx, eventhp)
...
printf("HA Event received.\n");
if (OCIHandleAlloc( (dvoid *)envhp, (dvoid **)&errhp, (ub4) OCI_HTYPE_ERROR,
(size_t) 0, (dvoid **) 0))
return;
if (retcode = OCIAttrGet(eventhp, OCT_HTYPE_EVENT, (dvoid *)&srvhp, (ub4 *)0,
OCI_ATTR_HA_SRVFIRST, errhp))
checkerr (errhp, (sword)retcode;
else {
printf("found first server handle.\n");
/*get associated instance name */
if (retcode = OCIAttrGet(srvhp, OCI_HTYPE_SERVER, (dvoid *)&instname,
(ub4 *)&sizep, OCI_ATTR_INSTNAME, errhp))
checkerr (errhp, (sword)retcode);
else
printf("instance name is %s.\n", instname);
クライアントおよびアプリケーションでは、高可用性イベントが発生するたびに起動するコールバックを登録できます。次に例を示します。
/*Registering HA callback function */
if (checkerr(errhp, OCIAttrSet(envhp, (ub4) OCI_HTYPE_ENV,
(dvoid *)evtcallback_fn, (ub4) 0,
(ub4)OCI_ATTR_EVTCBK, errhp)))
{
printf("Failed to set register EVENT callback.\n");
return EX_FAILURE;
}
if (checkerr(errhp, OCIAttrSet(envhp, (ub4) OCI_HTYPE_ENV,
(dvoid *)evtctx, (ub4) 0,
(ub4)OCI_ATTR_EVTCTX, errhp)))
{
printf("Failed to set register EVENT callback context.\n");
return EX_FAILURE;
}
return EX_SUCCESS;
イベントのコールバックとコンテキストを登録した後、OCIは高可用性イベントが発生するたびに登録された関数を1回コールします。
OCIアプリケーションでデータベースへの接続に使用されるOracle Net別名を構成します。Oracle Net別名ではプライマリおよびスタンバイの両方のSCANホスト名を指定する必要があります。新規接続の作成で最高のパフォーマンスを得るには、Oracle Net別名でDESCRIPTION_LISTに対してLOAD_BALANCE=OFFを保持し、DESCRIPTIONsが整列されたリストで上から下に試行されるようにします。この構成では、2番目のDESCRIPTIONは、1番目のDESCRIPTIONに対するすべての接続が失敗した場合にのみ、試行されます。
SALES=
(DESCRIPTION_LIST=
(LOAD_BALANCE=off)
(FAILOVER=on)
(DESCRIPTION= (CONNECT_TIMEOUT=5)(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=3)
(ADDRESS_LIST=
(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=oltpworkload)))
(DESCRIPTION=
(CONNECT_TIMEOUT=5)(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=3)
(ADDRESS_LIST=
(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=stby-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=oltpworkload))))
前述のOracle Net別名を使用して新しい接続が作成される際、次のロジックが使用されます。
Oracle NetはDNSに問い合せてプライマリSCANを合計3つのIPアドレスに解決します。
Oracle Netはその3つのIPアドレスのいずれかをランダムに選択し、接続を作成しようとします。IPアドレスへの接続の試行が3秒(TRANSPORT_CONNECT_TIMEOUT)以内に応答しない場合、次のIPアドレスが試行されます。3つすべてのIPアドレスが合計4回(前述の例では、最初の試行 + RETRY_COUNT)試行されます。
プライマリ・サイトへの接続が失敗した場合、DNSに問い合せてスタンバイSCANを3つのアドレスに解決します。
同じシーケンスが、プライマリSCANと同様にスタンバイSCANに対して実行されます。
次に、前述の別名で使用されるOracle Netのパラメータに関する追加情報を示します。
LOAD_BALANCEは、DESCRIPTION_LISTに対してのみデフォルトでONです。このパラメータは、DESCRIPTION内のアドレス・リストに対してデフォルトでOFFです。SCANベースのアドレスに対してこれをONに設定すると、新しい接続がDNSによって解決された3つのSCANベースのIPアドレスのいずれかにランダムに割り当てられることを意味します。
RETRY_COUNTパラメータは、新しい接続の試行を終了するまでに、アドレス・リストを反復する回数を指定します。デフォルト値は0です。たとえば、SCANについてFAILOVER = onと指定し、このRETRY_COUNTパラメータの値を2に設定すると、接続の終了までに3つのSCAN IPアドレスが3回反復されること(つまり、3*3=9回の接続の試行)になります。
接続リクエストを初めて受信すると、最初にランダムに割り当てられたIPアドレスが、続いて残り2つのIPアドレスがそのリクエストを処理しようとします。(この動作は、FAILOVERパラメータによって制御されます。)
再試行が始まり、3つのIPアドレスのリストがもう2回試行されます。RETRY_COUNTは、グローバル・レベル(sqlnet.ora)ではなく、接続文字列のDESCRIPTIONレベルでのみサポートされます。
前提条件:
ネームスペース: Oracle.DataAccess.Client、アセンブリ: Oracle.DataAccess.dll。
Microsoft .NET Frameworkバージョン2.0以降。
10.1.3項「OCIクライアントでの高速接続フェイルオーバーの構成」の説明に従ってOracle Net別名を構成すること。
FAN高可用性イベントをサブスクライブすることによって、ODP.NET接続プールの高速接続フェイルオーバーを有効にします。高速接続フェイルオーバーを有効にするには、次の例に示すように、接続文字列に"HA Events=true"および"pooling=true"を含めます。ここでは、user_nameはデータベース・ユーザーの名前、passwordはそのユーザーのパスワードです。
con.ConnectionString = "User Id=user_name;Password=password;Data Source=sales;" + "Min Pool Size=10;Connection Lifetime=120;Connection Timeout=60;" + "HA Events=true;Incr Pool Size=5;Decr Pool Size=2";
ODP.NET接続プールでロード・バランシング・イベントを利用するために、ConnectionStringのロード・バランシング属性にTRUEを設定します(デフォルトはFALSE)。この処理は、接続時に実行できます。この処理は、接続プールを使用している場合、またはプーリング属性がTRUE(デフォルト)設定されている場合にのみ実行できます。
次の例に、ConnectionStringを構成してロード・バランシングを有効にする方法を示します。
con.ConnectionString = "User Id=user_name;Password=password;Data Source=odpapp;" + "Min Pool Size=10;Connection Lifetime=120;Connection Timeout=60;" + "Load Balancing=true;Incr Pool Size=5;Decr Pool Size=2";
10.2.1項「データベース・サービスの構成」の説明に従ってサービスを構成し、FANイベントとHAイベントを有効にします。
|
関連項目:
|
Oracle Database 12cは、Oracle Real Application Clusters (Oracle RAC)およびOracle Data Guardでアプリケーション・データの高い可用性を使用可能にするインフラストラクチャを備えています。データベース層で高速アプリケーション・フェイルオーバーを構成する必要があります。
上位レベルにおけるOracle RAC構成でのクライアント・フェイルオーバーの自動化には、新規インスタンスまたは動作可能インスタンスへのデータベース・サービスの再配置、TCPタイムアウトからクライアントを解放するための障害発生のクライアントへの通知、動作可能インスタンスへのクライアントのリダイレクトが含まれます(Oracle ClusterwareはFANメッセージをアプリケーションに送信します。アプリケーションはFANイベントに応答してすぐに処理を行います)。FANの詳細は、5.1.1項「クライアントの構成および移行の概要」を参照してください。
Oracle RACデータベース上のサービスについては、Oracle Enterprise ManagerまたはSRVCTLユーティリティが推奨されるサービス管理ツールです。単一のサービスをOracleデータベースの1つ以上のインスタンスに適用し、単一のインスタンスで複数のサービスをサポートできます。サービスを提供するインスタンスの数は、アプリケーションとは関係なくデータベース管理者によって管理されます。
サーバー側コールアウトは、Oracle Clusterwareを構成する高可用性フレームワークとの単純かつ強力な統合メカニズムを提供します。サーバー側コールアウトの使用によって、トラブル・チケットを記録するか、管理者にページングして障害を警告することができます。UPイベントでは、サービスおよびインスタンスが起動された場合に新しい接続を作成して、新しく使用可能になったリソースをアプリケーションでただちに使用できます。
|
関連項目:
|
次の各項目では、Oracle Data Guard環境を構成する方法について説明します。
|
関連項目: 次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパーの『高可用性Oracle Databaseでのクライアント・フェイルオーバーのベスト・プラクティス - Oracle Database 12c』を参照してください。 |
Oracle Data Guard構成では、プライマリ・データベースではプライマリ・アプリケーション・サービスを、スタンバイ・データベースではスタンバイ・アプリケーション・サービスのみを実行します。データベース・ロールを各サービスに割り当てることで、プライマリ・データベースおよびスタンバイ・データベース上のデータベース・サービスの起動を自動的に制御できます(ロールにはPRIMARY、PHYSICAL_STANDBY、LOGICAL_STANDBYおよびSNAPSHOT_STANDBYがあります)。
サービスの管理ポリシーがAUTOMATICであり、そのサービスに割り当てられているロールがデータベースの現行のロールに一致する場合、データベースを起動するとデータベース・サービスが自動的に起動されます。
|
関連項目:
|
Oracle Data Guardブローカを使用して構成を管理するように、Oracle Data Guardを構成することがベスト・プラクティスです。Oracle Data Guardブローカではクライアント・アプリケーションにFANイベントを送信することで、停止したデータベースへの接続がクリーン・アップされ、新規の本番データベースに再接続されます。
単一インスタンス(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の場合はアプリケーション・コード・ロジック)が開始されます。
新規プライマリおよび新規スタンバイがオープンされるに従って、個々のサービスが各ロールに対して開始され、再試行を実行するクライアントではサービスが使用可能であることが確認され、接続されます。
ロジカル・スタンバイ・スイッチオーバーの場合:
適切な再接続ロジックが構成されていることを確認します(詳細は、10.1項「クライアント・フェイルオーバーの自動化 - JDBC、OCIおよびODP.Net」および10.2項「Oracle RACデータベースのフェイルオーバーの構成」を参照してください)。たとえば、OCIアプリケーションの場合はTAFおよびRETRY_COUNTを構成し、JDBCアプリケーションの場合はコード再試行ロジックを構成します。
プライマリ・アプリケーションで使用されるサービスと、スタンバイ・データベースで有効になっている読取り専用アプリケーションを停止します。
プライマリ・アプリケーションおよび読取り専用アプリケーションのセッションを切断するか、停止します。
スイッチオーバーが完了したら、プライマリ・アプリケーションおよび読取り専用アプリケーションで使用されるサービスを再起動します。
終了されたセッションは、サービスが使用可能になると再試行メカニズムの一環として再接続します。
アプリケーションが停止している場合は、アプリケーションを再起動します。
アプリケーションが再試行を実行する場合、スイッチオーバー操作中の移行クライアントにFANは必要ありません。FANが必要なのはTCPタイムアウトからクライアントを解放する場合のみで、この状態は計画外の停止中のみ発生します。
多数の接続があるアプリケーションのフェイルオーバー・プロセスにより、ログイン・ストームが発生することがあります。ログイン・ストームとは、データベース・インスタンスへの接続数が急激に増加し、CPUリソースを消費しつくしてしまうことです。CPUリソースが枯渇すると、アプリケーション・タイムアウトとアプリケーション・レスポンス時間が増加する可能性が高くなります。
ログイン・ストームを制御する手順:
ログイン・ストームを制御する主要な方法は、Oracleリスナーの接続速度リミッタ機能を実装することです。この機能は、1秒に処理できる接続の数を制限します。接続速度を低下させることで、CPUリソースが利用可能な状態に維持され、システムが無反応になりません。
Oracle Databaseに共有サーバー運用を構成します。
接続速度リミッタを実装する他、一部のアプリケーションでは、Oracle Databaseに共有サーバー運用を構成することによって、ログイン・ストームを制御することができます。共有サーバーを使用すると、フェイルオーバー時間に作成する必要があるプロセスの数が大幅に減少します。
中間層接続プールの最大接続数を調整します。
ご使用のアプリケーションの中間層でそうした機能を利用できる場合、中間層接続プールの最大接続数を調整することによって接続数を制限してみます。
グローバル・データ・サービスにより、管理者は共通のサービスを提供するレプリケートされたデータベース全体でクライアント・ワークロードを自動的および透過的に管理できます。データベース・サービスは、1つ以上のデータベース・インスタンスをある単位にまとめて表現したものです。サービスを使用すれば、データベースのワークロードをグループ化し、特定の作業リクエストを適切なインスタンスにルーティングできます。グローバル・サービスはデータ・レプリケーションにより同期化された複数のデータベースにより提供されます。
グローバル・データ・サービスでは、共有サービスを提供する一連のレプリケート・データベースに動的ロード・バランシング、フェイルオーバーおよびサービスの集中管理を提供します。データベースのセットには、Oracle RACとOracle Data Guardを介して相互に関連するクラスタ以外のOracleデータベース、Oracle Multitenantの元で統合されたデータベース、Oracle GoldenGateまたはその他のレプリケーション技術を含めることができます。
グローバル・サービス管理のフレームワークは、次の既存のOracle Databaseテクノロジを中心に構築されます。
Oracle Real Application Clusters (Oracle RAC) - 1つのクラスタでの動的ロード・バランシングおよびワークロード管理を可能にします。
Oracle Active Data Guard - 読取り専用データベースの高いパフォーマンスのファームを可能にします。
Data Guard Broker - プライマリ・データベースと最大30のスタンバイ・データベースを含むData Guard構成の作成、管理および監視を可能にします。
Oracle GoldenGate - 複数のデータベース間のレプリケーション更新を可能にします。
Oracle GDSには、グローバルに分散されるか、同じデータ・センター内に配置されるレプリケートされたデータベース・セット用に次の主な機能が用意されています。
リージョンベースのワークロード・ルーティング
接続時ロード・バランシング
Oracle統合クライアント用のランタイム・ロード・バランシング・アドバイザの提供
内部データベース・サービス・フェイルオーバー
Active Data Guard用のレプリケーション・ラグに基づいたワークロード・ルーティング
Active Data Guard用のロールベースのグローバル・サービス
ワークロードの集中管理フレームワーク
グローバル・データ・サービス・フレームワークの構成の概要は、次のとおりです。
グローバル・サービス・マネージャのインストール。Global Data Servicesリージョンごとに最低1つのグローバル・サービス・マネージャをインストールする必要があります。グローバル・サービス・マネージャは、物理環境または仮想環境でホストできます。高可用性の点から、個別のホストで実行されているリージョンごとに複数(通常は3個)のグローバル・サービス・マネージャをインストールすることをお薦めします。
グローバル・データ・サービス・カタログの作成。カタログは12cデータベースに存在する必要がありますが、そのデータベースはGDS構成の外部にあることをお薦めします。GDSカタログは、RMANまたはOracle Enterprise Managerのカタログとともに共同ホストできます。Oracle Real Application Clusters (Oracle RAC)やOracle Data Guardなどの高可用性機能を使用して、Global Data Servicesカタログが停止しないようにすることをお薦めします。
カタログへのグローバル・サービス・マネージャの登録。
グローバル・サービス・プールの追加。GDSプールは、管理ドメインに属するグローバル・サービス・セットを提供するデータベースのサブセットです。これにより、サービス管理が簡略化され、各プールを異なる管理者が管理できるためにセキュリティが向上します。
グローバル・データ・サービス・リージョンの追加。リージョンとは、同じネットワーク近接度およびネットワーク待機時間を共有するデータベース・セットです。通常、リージョンはローカル・エリア・ネットワークに相当します。高可用性を実現するため、GDS構成の各リージョンには、バディ・リージョン(ローカル・リージョンのグローバル・サービス・マネージャが使用できなくなった場合にGDS構成への継続的なアクセスを提供できるグローバル・サービス・マネージャを含むリージョン)を指定する必要があります。
GDSプールへのデータベースの追加。Global Data Servicesプールに含めるには、データベースでサーバー・パラメータ・ファイル(SPFILE)が使用される必要があります。Oracle RACデータベースにはSCAN設定も必要です。
GDSプールへのサービスの追加。グローバル・サービス名は、GDSプール内で一意である必要があり、GDS構成内でも一意である必要があります。グローバル・サービスは、データベースに同じ名前のローカル・サービスまたはグローバル・サービスがすでに存在する場合、そのデータベースで作成できません。
|
関連項目:
|
クライアントがデータベースに接続する際、サービスを指定するOracle Net接続文字列を使用します。グローバル・サービスへの接続時に使用される接続文字列は、次のようにして一意にします。
サービス名パラメータは、グローバル・サービスを指定する必要があります。
複数のSCANアドレスを使用してグローバル・サービス・マネージャのエンドポイントを指します。
データベース・クライアントのリージョンは、接続データ・セクションで指定できます。
次の接続文字列を検討します。
(DESCRIPTION=
(FAILOVER=on)
(ADDRESS_LIST=
(LOAD_BALANCE=ON)
(ADDRESS=(host=sales-east1)(port=1522))
(ADDRESS=(host=sales-east2)(port=1522))
(ADDRESS=(host=sales-east3)(port=1522)))
(ADDRESS_LIST=
(LOAD_BALANCE=ON)
(ADDRESS=(host=sales-west1)(port=1522))
(ADDRESS=(host=sales-west2)(port=1522))
(ADDRESS=(host=sales-west3)(port=1522)))
(CONNECT_DATA=
(SERVICE_NAME=sales)
(REGION=east)))
クライアント側のロード・バランシングは、各リージョンのアドレス・リストでLOAD_BALANCEパラメータをONに設定することで、各リージョン内のグローバル・サービス・マネージャ全体で有効化されます。リージョン間の接続時フェイルオーバーは、FAILOVERパラメータをONに設定することで有効化されます。
