| Oracle® TimesTen Application-Tier Database Cacheユーザーズ・ガイド リリース18.1 E98634-04 |
|
 前 |
 次 |
この章では、同期または非同期のData Guardと連携するようにTimesTen Cacheを構成する方法について説明します。内容は次のとおりです。
Oracle最大可用性アーキテクチャ(MAA)は、Oracle Databaseのベスト・プラクティスのブループリントであり、実績のあるOracle Database高可用性(HA)テクノロジと推奨事項を基礎としています。MAAの目的は、コストおよび複雑さを最小限に抑えて最適な高可用性アーキテクチャを実現することです。
MAAに準拠するために、TimesTen Cacheでは、独自のHA機能が備えられているのみでなく、Oracle Real Application Clusters (Oracle RAC)およびOracle Data Guardがサポートされている必要があります。TimesTen Cacheでは、読取り専用キャッシュ・グループおよびAWTキャッシュ・グループでのキャッシュ表のアクティブ・スタンバイ・ペア・レプリケーションによって独自のHA機能が提供されています。TimesTen CacheおよびOracle RACの詳細は、Oracle RAC環境でのTimesTen Cacheの使用を参照してください。
Oracle Data Guardは、管理、監視および自動化のソフトウェア・インフラストラクチャを備えており、1つ以上の同期化されたスタンバイOracleデータベースを作成および保持して障害、災害、エラーおよび破損からデータを保護します。計画停止または計画外停止のためプライマリOracleデータベースを使用できなくなった場合、Data GuardはスタンバイOracleデータベースをプライマリ・ロールに切り替えて、停止時間を最小限に抑え、データの損失を防ぐことができます。Data Guardの詳細は、『Oracle Data Guard概要および管理』を参照してください。
TimesTen CacheのMAAフレームワークでは、明示的にロードされる読取り専用キャッシュ・グループおよびAWTキャッシュ・グループのキャッシュ表がサポートされます。任意のキャッシュ・グループ・タイプの動的キャッシュ・グループ、SWTキャッシュ・グループおよびAUTOREFRESHキャッシュ・グループ属性を使用するユーザー管理キャッシュ・グループのキャッシュ表の場合、キャッシュ・アプリケーションがフェイルオーバーおよびスイッチオーバーが完了するまで待機する必要があるため、TimesTen Cacheではフェイルオーバーおよびスイッチオーバー中にOracle Databaseにアクセスできません。
ただし、一般的に、予定されたメンテナンス時には、すべてのキャッシュ・グループ・タイプが同期Data GuardまたはData Guardでサポートされます。
非同期REDO転送モードのOracle Active Data Guardから読取り専用キャッシュ・グループに表をキャッシュできます。読取り専用キャッシュ・グループは、アクティブ・スタンバイ・ペアのレプリケーション・スキーム内でレプリケートされます。Active Data Guard構成には、単一のフィジカル・スタンバイOracleデータベースへの非同期転送を介して通信するプライマリOracleデータベースが含まれます。図10-1に示すように、プライマリOracleデータベースはプライマリ・サイトに配置されますが、スタンバイOracleデータベースは障害時リカバリ・サイトに配置されます。
TimesTenでは、プライマリ・サイトの読取り専用キャッシュ・グループはプライマリOracleデータベースから自動リフレッシュされます。ただし、変更がスタンバイOracleデータベースに正常にレプリケートされるのは、自動リフレッシュされるトランザクションのみです。アクティブ・マスターにリフレッシュされると、すべての変更は、標準のTimesTenレプリケーション・プロセスを使用してTimesTenスタンバイ・マスターと読取り専用サブスクライバに伝播されます。
最適なフェイルオーバーとリカバリ・アクションのためには、読取り専用サブスクライバをスタンバイOracleデータベースと同じ障害時リカバリ・サイトに配置する必要があります。この読取り専用サブスクライバは、ttRepAdmin -duplicate -activeDataGuardユーティリティ・オプションを指定して作成します。これにより、スタンバイ・マスター・データベースの場合と同様に、読取り専用キャッシュ・グループがサブスクライバに直接レプリケートされます。つまり、サブスクライバへのレプリケート時にキャッシュ・グループが表に変換されるのではなく、キャッシュ・グループそのものが読取り専用サブスクライバにレプリケートされます。これにより、プライマリ・サイトに障害が発生した場合に、リカバリおよびフェイルオーバーのオプションが提供されます。詳細は、非同期Active Data Guardを使用している場合の障害後のリカバリを参照してください。
次の各項では、レプリケートされた読取り専用キャッシュ・グループを使用する際の非同期Active Data Guardの環境について詳しく説明します。
プライマリおよびスタンバイのOracleデータベースを使用してActive Data Guardを作成および構成する場合は、TimesTenキャッシュ環境をサポートするために必ず構成で次の処理を行います。
フラッシュバック問合せを使用するように、プライマリとスタンバイの両方のOracleデータベースを構成します。詳細は、Oracle Database 2日でデータベース管理者のリカバリ設定の構成を参照してください。
TimesTen Cacheデーモン・プロセスおよびアプリケーション・クライアントがフェイルオーバー・イベントおよびスイッチオーバー・イベントにより速く応答するように、Data Guard BrokerでData Guard構成を管理する必要があります。詳細は、Data Guard Brokerガイドを参照してください。
Oracle Databaseサービスを2つ作成し、一方はプライマリOracle Databaseを指し、他方はフィジカル・スタンバイOracle Databaseを指すようにします。詳細は、2つのOracle Databaseサービスの作成を参照してください。
Oracle Cluster内のプライマリとスタンバイの両方のOracleデータベースでサポート・データベース・サービスを作成し、一方はプライマリOracle Databaseを指し、他方はフィジカル・スタンバイOracle Databaseを指すようにします。これらは、ロールベースのサービスまたはシステム・トリガーのいずれかを介して作成できます。
各サービスにデータベース・ロールを割り当てることで、プライマリとスタンバイの両方のOracleデータベースでOracleデータベース・サービスの起動を自動的に制御できます。Oracleデータベース・ポリシーがAUTOMATICに設定されている場合およびサービス・ロールがデータベースの現行のロールに一致する場合、Oracleデータベースが起動すると、Oracleデータベース・サービスは自動的に開始します。この場合、Oracleデータベースのロールは、Active Data Guard構成の一部として、プライマリ・ロールまたはスタンバイ・ロールのいずれかに含まれます。
Data Guard構成内のすべてのOracleデータベースについて、srvctlユーティリティを使用してサービスを同一の構成にします。次の例では、プライマリとスタンバイの両方のOracleデータベースでまったく同じに作成された2つのサービスを示します。srvctlユーティリティの詳細は、Oracle Database管理者ガイドのsrvctl add serviceを参照してください。
次のステップでは、プライマリOracleデータベースがオースティンにあり、スタンバイOracleデータベースがヒューストンにある場合に、primaryroleおよびstandbyroleデータベース・サービスをプライマリとスタンバイの両方のOracleデータベースに追加しています。
プライマリOracleデータベースで、primaryroleデータベース・サービスを追加します。このOracleデータベースがプライマリとして機能している間、このサービスは開始します。
srvctl add service -d Austin -s primaryrole -r ssa1,ssa2,ssa3, ssa4 -l PRIMARY -q TRUE -e SESSION -m BASIC -w 10 -z 150
プライマリOracleデータベースで、standbyroleデータベース・サービスを追加します。このサービスは、このOracleデータベースがスタンバイ・ロールに切り替わり、スタンバイOracleデータベースでリアルタイム・レポートを提供する場合にのみ開始します。
srvctl add service -d Austin -s standbyrole -r ssa1,ssa2,ssa3, ssa4 -l PHYSICAL_STANDBY -q TRUE -e SESSION -m BASIC -w 10 -z 150
スタンバイOracleデータベースで、primaryroleデータベース・サービスを追加します。このサービスは、このOracleデータベースがプライマリ・ロールに切り替った場合にのみ開始します。
srvctl add service -d Houston -s primaryrole -r ssb1,ssb2,ssb3, ssb4 -l PRIMARY -q TRUE -e SESSION -m BASIC -w 10 -z 150
スタンバイOracleデータベースで、standbyroleデータベース・サービスを追加します。このOracleデータベースがスタンバイとして機能している間、このサービスは開始し、スタンバイOracleデータベースでリアルタイム・レポートを提供します。
srvctl add service -d Houston -s standbyrole -r ssb1,ssb2,ssb3, ssb4 -l PHYSICAL_STANDBY -q TRUE -e SESSION -m BASIC -w 10 -z 150
プライマリOracleデータベースで次のSQL文を実行し、サービス定義がフィジカル・スタンバイOracleデータベースに送信され適用されるようにします。
EXECUTE DBMS_SERVICE.CREATE_SERVICE('standbyrole', 'standbyrole', NULL,
NULL, TRUE, 'BASIC', 'SESSION', 150, 10, NULL);
適切なtnsnames.oraファイルで接続の別名を追加して、プライマリとスタンバイのOracleデータベースを識別し、それぞれのデータベース・サービス名を指定します。
primaryinstance=
(DESCRIPTION_LIST=
(LOAD_BALANCE=off)
(FAILOVER=on)
(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=myhost1)(PORT=1521)))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=primaryrole)))
(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=myhost2)(PORT=1521)))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=primaryrole))))
standbyinstance=
(DESCRIPTION_LIST=
(LOAD_BALANCE=off)
(FAILOVER=on)
(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=myhost1)(PORT=1521)))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=standbyrole)))
(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=myhost2)(PORT=1521)))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=standbyrole))))
プライマリOracleデータベースで、primaryroleデータベース・サービスを開始します。
srvctl start service -d Austin -s primaryrole
スタンバイOracleデータベースで、standbyroleデータベース・サービスを開始します。
srvctl start service -d Houston -s standbyrole
次のステップを実行し、トリガーを使用してプライマリOracleデータベースでprimaryroleおよびstandbyroleデータベース・サービスを作成します。作成後、これらはスタンバイOracleデータベースにレプリケートされます。
プライマリOracleデータベースでprimaryroleおよびstandbyroleデータベース・サービスを作成します。
exec DBMS_SERVICE.CREATE_SERVICE( service_name => 'primaryrole', network_name => 'primaryrole', aq_ha_notifications => true, failover_method => 'BASIC', failover_type => 'SELECT', failover_retries => 180, failover_delay => 1 ); exec DBMS_SERVICE.CREATE_SERVICE( service_name => 'standbyrole', network_name => 'standbyrole', aq_ha_notifications => true, failover_method => 'BASIC', failover_type => 'SELECT', failover_retries => 180, failover_delay => 1 );
プライマリOracleデータベースで、データベース起動時のためのprimaryroleおよびstandbyroleトリガーを作成します。
CREATE OR REPLACE TRIGGER manage_OCIService
after startup on database
DECLARE
role VARCHAR(30);
BEGIN
SELECT DATABASE_ROLE INTO role FROM V$DATABASE;
IF role = 'PRIMARY' THEN
BEGIN
DBMS_SERVICE.START_SERVICE('primaryrole');
EXCEPTION
WHEN OTHERS THEN
NULL;
END;
BEGIN
DBMS_SERVICE.STOP_SERVICE('standbyrole');
EXCEPTION
WHEN OTHERS THEN
NULL;
END;
ELSE
BEGIN
DBMS_SERVICE.STOP_SERVICE('primaryrole');
EXCEPTION
WHEN OTHERS THEN
NULL;
END;
BEGIN
DBMS_SERVICE.START_SERVICE('standbyrole');
EXCEPTION
WHEN OTHERS THEN
NULL;
END;
END IF;
END;
プライマリOracleデータベースで、データベースのロールが変更されたときに実行する次のトリガーを作成します。
CREATE OR REPLACE TRIGGER manage_OCIService2
AFTER DB_ROLE_CHANGE ON DATABASE
DECLARE
role VARCHAR(30);
BEGIN
SELECT DATABASE_ROLE INTO role FROM V$DATABASE;
IF role = 'PRIMARY' THEN
BEGIN
DBMS_SERVICE.START_SERVICE('primaryrole');
EXCEPTION
WHEN OTHERS THEN
NULL;
END;
BEGIN
DBMS_SERVICE.STOP_SERVICE('standbyrole');
EXCEPTION
WHEN OTHERS THEN
NULL;
END;
ELSE
BEGIN
DBMS_SERVICE.STOP_SERVICE('primaryrole');
EXCEPTION
WHEN OTHERS THEN
NULL;
END;
BEGIN
DBMS_SERVICE.START_SERVICE('standbyrole');
EXCEPTION
WHEN OTHERS THEN
NULL;
END;
END IF;
END;
適切なtnsnames.oraファイルで接続の別名を追加して、プライマリとスタンバイのOracleデータベースを識別し、それぞれのデータベース・サービス名を指定します。
primaryinstance=
(DESCRIPTION_LIST=
(LOAD_BALANCE=off)
(FAILOVER=on)
(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=myhost1)(PORT=1521)))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=primaryrole)))
(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=myhost2)(PORT=1521)))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=primaryrole))))
standbyinstance=
(DESCRIPTION_LIST=
(LOAD_BALANCE=off)
(FAILOVER=on)
(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=myhost1)(PORT=1521)))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=standbyrole)))
(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=myhost2)(PORT=1521)))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=standbyrole))))
両方のOracleデータベースを再起動して、トリガーが適切なデータベース・サービスを開始および停止できるようにします。あるいは、Oracleデータベースをどちらも再起動しない場合は、次のようにして各Oracleデータベースで適切なデータベース・サービスを開始および停止できます。
プライマリOracleデータベースの場合:
exec DBMS_SERVICE.START_SERVICE('primaryrole');
exec DBMS_SERVICE.STOP_SERVICE('standbyrole');
スタンバイOracleデータベースの場合:
exec DBMS_SERVICE.STOP_SERVICE('primaryrole');
exec DBMS_SERVICE.START_SERVICE('standbyrole');
非同期REDO転送モードのActive Data Guardでは、レプリケートされた読取り専用キャッシュ・グループのみが含まれるアクティブ・スタンバイ・ペアのレプリケーション・スキームがサポートされています。アクティブ・スタンバイ・ペアを作成する前に、レプリケートされた読取り専用キャッシュ・グループをすべて作成する必要があります。アクティブ・スタンバイ・ペアを作成する際はレプリケートされた読取り専用キャッシュ・グループを除外することができず、作成後のアクティブ・スタンバイ・ペアには別のレプリケートされた読取り専用キャッシュ・グループを追加することができません。
レプリケートされた読取り専用キャッシュ・グループをサポートするようにアクティブ・スタンバイ・ペアを作成および構成する場合、次の手順を実行して非同期Active Data Guardをサポートします。
アクティブ・スタンバイ・ペアを作成する場合は、アクティブ・マスターとスタンバイ・マスターの両方を物理的に同じサイト内に保持することをお薦めします。これらは同じサイト内の異なるホスト上に配置できます。
障害時リカバリに読取り専用サブスクライバが必要な場合は、スタンバイOracleデータベースと同じ障害時リカバリ・サイトで読取り専用サブスクライバを追加し、そのサブスクライバをキャッシュ・グループに対して有効にすることができます。Active Data Guardの使用時に作成する必要があるサブスクライバは、ttRepAdmin -duplicate -activeDataGuardオプションを設定した複製操作を使用して作成されます。
-activeDataGuardオプションは、Active Data Guard環境のみのためのオプションで、これを使用するとサブスクライバは、スタンバイ・マスターの場合と同様に、レプリケートされた読取り専用キャッシュ・グループをそのままの状態に保つことができます。サブスクライバはこのようなキャッシュ・グループを保持するため、ttRepAdminユーティリティ・コマンドラインにキャッシュ・ユーザー名およびキャッシュ・ユーザー・パスワードを指定する必要があります。
|
ノート: あるいは、ttRepDuplicateExArg.flagsにTT_REPDUP_ADGフラグを設定して、ttRepDuplicateEx C関数を使用できます。 |
次の例では、-activeDataGuardオプション、キャッシュ・ユーザー名およびキャッシュ・ユーザー・パスワードを指定してスタンバイ・マスターから複製し、障害時リカバリ・サイトで読取り専用サブスクライバを作成します。
ttRepAdmin -duplicate -from master2 -host node1 -uid cacheuser -pwd timesten -cacheuid cacheuser -cachepwd oracle -activeDataGuard adgsubscriber
プライマリOracleデータベースでキャッシュ環境を作成します。これらのステップはいずれもスタンバイOracleデータベースで実行する必要はありません。
プライマリOracleデータベースで、SYS.DBMS_FLASHBACKパッケージのEXECUTE権限をキャッシュ管理ユーザーに付与します。この権限は、TimesTen Classic 18.1リリースの時点では、initCacheAdminSchema.sqlスクリプトとgrantCacheAdminPrivileges.sqlスクリプトの一部として付与されます。
Oracle DatabaseからデータをキャッシュするTimesTenデータベースの場合と同様に、同じ接続属性を構成します。さらに、スタンバイOracleデータベースからのトランザクションの監視も行っているため、スタンバイOracleデータベース・インスタンスのOracle Netサービス名を使用してStandbyNetServiceName接続属性を構成します。
Microsoft Windowsシステムの場合、Oracle Databaseインスタンスのネット・サービス名は、「TimesTen ODBC Setup」ダイアログ・ボックスにある「TimesTen Cache」タブの「Oracle Net Service Name」フィールドで指定します。スタンバイOracleデータベース・インスタンスは、同じページの「Standby Oracle Net Service Name」フィールドで指定します。
アクティブ・マスターでStandbyNetServiceName ODBC.INI属性を構成して、フィジカル・スタンバイOracleデータベースのネット・サービス名を構成します。
[cachedb] DataStore=/myDb/cachedb PermSize=256 TempSize=256 PLSQL=0 DatabaseCharacterSet=WE8DEC OracleNetServiceName=primaryinstance StandbyNetServiceName=standbyinstance
次の各項では、プライマリOracleデータベースで障害が発生する場合、スタンバイOracleデータベースで障害が発生する場合、あるいはプライマリ・サイト全体で障害が発生して、プライマリOracleデータベースのみならずアクティブ・マスターとスタンバイ・マスターも停止する場合の対処方法について説明します。
Active Data Guard構成のスタンバイOracleデータベースで障害が発生すると、キャッシュ・エージェントは、次のいずれかの方法でスタンバイOracleデータベースへの接続を再試行します。
タイムアウトが設定されている場合、キャッシュ・エージェントはttCacheADGStandbyTimeoutSet組込みプロシージャで指定された時間だけ待機します。スタンバイOracleデータベースがこの期間の経過後もリカバリされていない場合、キャッシュ・エージェントは、FAILED引数を指定してttCacheADGStandbyStateSet組込みプロシージャをコールしてスタンバイOracleデータベースの状態を設定し、プライマリOracleデータベースのみを使用して自動リフレッシュを進めます。
ttCacheADGStandbyTimeoutSet組込みプロシージャを使用してタイムアウトが設定されていない場合(デフォルト値は0)、キャッシュ・エージェントは、スタンバイOracleデータベースで待機し続けます(ただし、FAILED引数を指定してttCacheADGStandbyStateSet組込みプロシージャをコールして、スタンバイOracleデータベースがリカバリされていないことをキャッシュ・エージェントに通知した場合を除く)。
スタンバイOracleデータベースの状態がFAILEDに設定されると、キャッシュ・エージェントは、ON引数を指定してttCacheADGStandbyStateSet組込みプロシージャをコールしてスタンバイOracleデータベースの状態がリセットされるまで、プライマリOracleデータベースのみを使用して自動リフレッシュを再開します。スタンバイOracleデータベースが最終的にリカバリされた場合でも、その状態がONにリセットされるまで、キャッシュ・エージェントはスタンバイOracleデータベースがアクティブであることを認識しません。
スタンバイOracleデータベースの状態がONに設定されると、キャッシュ・エージェントは一時停止し、スタンバイOracleデータベースがプライマリOracleデータベースに追いつくまで待機します。その後、キャッシュ・エージェントは、スタンバイOracleデータベースに正常にレプリケートされたトランザクションに対して、プライマリOracleデータベースからの自動リフレッシュを再開します。
元のActive Data Guard構成をリストアするには、アクティブ・スタンバイ・ペアを削除してからキャッシュ・グループをロードします。
詳細は、Oracle TimesTen In-Memory DatabaseリファレンスのttCacheADGStandbyTimeoutSetおよびttCacheADGStandbyStateSetを参照してください。
プライマリOracleデータベースで障害が発生すると、Data GuardはスタンバイOracleデータベースに切り替え、TimesTenキャッシュ・エージェントは自動リフレッシュを新しいプライマリOracleデータベースに切り替えます。
プライマリOracleデータベースの他にアクティブ・マスター・データベースとスタンバイ・マスター・データベースも配置されているサイト全体で障害が発生した場合、スタンバイOracleデータベースがプライマリOracleデータベースになります。その後、障害時リカバリ・サイトがプライマリTimesTenデータベースになることを必要とする場合もあります。したがって、この時点の障害時リカバリ・サイトでは、スタンバイOracleデータベースが唯一のOracleデータベースであり、読取り専用サブスクライバはOracleデータベースにデータをキャッシュする単一のTimesTenデータベースになります。
次のようにして、キャッシュされた表を使用してサブスクライバを単一のTimesTenデータベースに変換します。
障害時リカバリ・サイトのTimesTenデータベースでアクティブ・スタンバイ・ペアを削除します。
障害時リカバリ・サイトで既存の読取り専用キャッシュ・グループを変更して、自動リフレッシュ状態をオンに設定します。
その後、障害時リカバリ・サイトのTimesTenデータベースのキャッシュ表で、新しいプライマリOracleデータベースから更新を受信します。
プライマリ・サイトをリカバリし、環境を元の状態に再構築するプロセスは、次のとおりです。
障害時リカバリ・サイトで新しいアクティブ・スタンバイ・ペアを作成します。
障害時リカバリ・サイトで既存の読取り専用キャッシュ・グループを変更して、自動リフレッシュ状態をオフに設定し、プライマリOracleデータベースからの以後の更新を停止します。
リカバリされたプライマリ・サイトでADG対応読取り専用サブスクライバを作成します。
アクティブ・スタンバイ・ペアがプライマリ・サイトのリカバリ後も引き続き存在している場合は、プライマリ・サイトのADG対応読取り専用サブスクライバでそのペアを削除します。
Active Data GuardのOracleデータベースを切り替えます。この時点で、アプリケーションは障害時リカバリ・サイトのプライマリOracleデータベースを更新しています。ただし、プライマリ・サイトのOracleデータベースをリカバリしたら、そのデータベースを再度プライマリとして引き継ぎ、障害時リカバリ・サイトのOracleデータベースをセカンダリとする必要があります。
TimesTenデータベースは、プライマリ・サイトのOracleデータベースから更新を受信し始めます。
プライマリ・サイトで新しいアクティブ・スタンバイ・ペアを作成します。
障害時リカバリ・サイトで新しいADG対応読取り専用サブスクライバを作成します。
キャッシュされたOracle Database表のオブジェクトIDがプライマリOracleデータベースとスタンバイOracleデータベースで同じままであるかぎり、TimesTen Cacheは同期フィジカル・スタンバイのフェイルオーバーとスイッチオーバー、およびロジカル・スタンバイのスイッチオーバーと連携します。Oracle表を削除してから再作成した場合、Oracle表に変更を加えた場合または切捨てフラッシュバック処理やオンライン・セグメント縮小を実行した場合は、オブジェクトIDが変更される可能性があります。
一時アップグレード中に、フィジカル・スタンバイOracleデータベースがロジカル・スタンバイOracleデータベースに変換されます。スタンバイOracleデータベースがロジカルである間、キャッシュされたOracle Database表のオブジェクトIDが変更されないようにする必要があります。特に、キャッシュされた表に対しては、削除、再作成、切捨て、変更、フラッシュバック、オンライン・セグメント縮小は実行しないでください。
TimesTen Cacheでフェイルオーバーおよびスイッチオーバーを適切に実行するには、次のステップを使用して、プライマリOracleデータベースおよびスタンバイOracleデータベースを構成します。
TimesTen Cacheデーモン・プロセスおよびアプリケーション・クライアントがフェイルオーバー・イベントおよびスイッチオーバー・イベントにより速く応答するように、Data Guard BrokerでData Guard構成を管理する必要があります。
Oracle RACデータベースを構成している場合は、Oracle Enterprise Managerの「Cluster Managed Database Services」ページを使用して、TimesTen Cacheおよびそのクライアント・アプリケーションがOracleプライマリ・データベースに接続するために使用するOracleデータベース・サービスを作成します。データベース・サービスの作成の詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドの動的データベース・サービスによるワークロード管理を参照してください。
ステップ2でOracleデータベース・サービスを作成した場合は、DBMS_SERVICE PL/SQLパッケージのMODIFY_SERVICEファンクションを使用し、aq_ha_notifications属性をTRUEに設定することによって、アドバンスト・キューイング(AQ)を介して高可用性通知を送信できるようにそのサービスを変更します。サーバー側のTAF設定を構成するには、次の例に示すように、フェイルオーバー属性を設定します。
BEGIN DBMS_SERVICE.MODIFY_SERVICE (service_name => 'DBSERV', goal => DBMS_SERVICE.GOAL_NONE, dtp => false, aq_ha_notifications => true, failover_method => 'BASIC', failover_type => 'SELECT', failover_retries => 180, failover_delay => 1); END;
ステップ2でデータベース・サービスを作成しなかった場合は、DBMS_SERVICE PL/SQLパッケージのCREATE_SERVICEファンクションを使用してデータベース・サービスを作成し、高可用性通知を有効にして、サーバー側のTAF設定を構成します。
BEGIN DBMS_SERVICE.CREATE_SERVICE (service_name => 'DBSERV', network_name => 'DBSERV', goal => DBMS_SERVICE.GOAL_NONE, dtp => false, aq_ha_notifications => true, failover_method => 'BASIC', failover_type => 'SELECT', failover_retries => 180, failover_delay => 1); END;
Data Guardスタンバイ・データベース(Oracle RACまたはOracle RAC以外)がプライマリ・ロールに切り替わった後、データベース・サービスをそのデータベースに再配置するためにトリガーを2つ作成します。1つ目のトリガーは、システム起動イベントで起動され、DBSERVサービスを開始します。
CREATE OR REPLACE TRIGGER manage_service
AFTER STARTUP ON DATABASE
DECLARE
role VARCHAR(30);
BEGIN
SELECT database_role INTO role FROM v$database;
IF role = 'PRIMARY' THEN
dbms_service.start_service('DBSERV');
END IF;
END;
2つ目のトリガーは、フェイルオーバーおよびスイッチオーバー時にデータベース・ロールが変更されてスタンバイ・データベースが開いたままになったときに起動されます。このトリガーは、古いプライマリ・データベースから新しいプライマリ・データベースにDBSERVサービスを再配置し、古いプライマリ・データベース上のDBSERVサービスへの接続を切断して、TimesTen Cacheおよびそのクライアント・アプリケーションが新しいプライマリ・データベースに再接続できるようにします。
CREATE OR REPLACE TRIGGER relocate_service
AFTER DB_ROLE_CHANGE ON DATABASE
DECLARE
role VARCHAR(30);
BEGIN
SELECT database_role INTO role FROM v$database;
IF role = 'PRIMARY' THEN
dbms_service.start_service('DBSERV');
ELSE
dbms_service.stop_service('DBSERV');
dbms_lock.sleep(2);
FOR x IN (SELECT s.sid, s.serial#
FROM v$session s, v$process p
WHERE s.service_name='DBSERV' AND s.paddr=p.addr)
LOOP
BEGIN
EXECUTE IMMEDIATE
'ALTER SYSTEM DISCONNECT SESSION
''' || x.sid || ','|| x.serial# || ''' IMMEDIATE';
EXCEPTION WHEN OTHERS THEN
BEGIN
DBMS_OUTPUT.PUT_LINE(DBMS_UTILITY.FORMAT_ERROR_STACK);
END;
END;
END LOOP;
END IF;
END;
オプションとして、TimesTen Cacheアプリケーションに及ぼすパフォーマンスの影響を軽減し、フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースのスイッチオーバー中の停止時間を最小限に抑えるために、フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースへのData Guardスイッチオーバーを開始する直前に、次のプロシージャを実行します。
DECLARE
role varchar(30);
BEGIN
SELECT database_role INTO role FROM v$database;
IF role = 'PRIMARY' THEN
dbms_service.stop_service('DBSERV');
dbms_lock.sleep(2);
FOR x IN (SELECT s.sid, s.serial#
FROM v$session s, v$process p
WHERE s.service_name='DBSERV' AND s.paddr=p.addr)
LOOP
BEGIN
EXECUTE IMMEDIATE
'ALTER SYSTEM DISCONNECT SESSION
''' || x.sid || ',' || x.serial# || ''' IMMEDIATE';
EXCEPTION WHEN OTHERS THEN
BEGIN
DBMS_OUTPUT.PUT_LINE(DBMS_UTILITY.FORMAT_ERROR_STACK);
END;
END;
END LOOP;
ELSE
dbms_service.start_service('DBSERV');
END IF;
END;
このプロシージャは、スイッチオーバー・プロセスの直前に、まずフィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースで実行し、次にプライマリ・データベースで実行します。フィジカル・スタンバイ・データベースへのスイッチオーバーにこのプロシージャを実行するには、そのフィジカル・スタンバイ・データベースでActive Data Guardを有効にしておく必要があります。
ロジカル・スタンバイ・データベースへのスイッチオーバーを実行するには、プライマリ・データベースでTimesTen用のOracle Databaseサービスを停止し、そのサービスに接続されているすべてのセッションを切断しておきます。その後、ロジカル・スタンバイ・データベースでサービスを開始します。
この時点で、キャッシュ・アプリケーションによってスタンバイ・データベースへの再接続が試行されます。スイッチオーバーが発生しても、プライマリ・データベースからスタンバイ・データベースに接続を移行するために待機する必要はありません。このため、TimesTen Cacheおよびそのアプリケーションのパフォーマンスが影響を受けなくなります。
詳細は、ホワイト・ペーパー『Maximum Availability Architecture, Oracle Best Practices for High Availability』を参照してください。
FAN HAイベントの通知を受信して、障害が発生したOracle Databaseインスタンスへの再接続を回避するように、TimesTenを構成します。TimesTen Cacheに付属のOracleクライアントを使用します。
すべてのプライマリ・ホストおよびスタンバイ・ホストを含むOracleネット・サービス名をADDRESS_LISTに作成します。例:
DBSERV = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = PRIMARYDB)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = STANDBYDB)(PORT = 1521)) (LOAD_BALANCE = yes) ) (CONNECT_DATA= (SERVICE_NAME=DBSERV)) )
クライアントのsqlnet.oraファイルで、障害発生時にクライアントが迅速にアドレス・リストを横断できるようにSQLNET.OUTBOUND_CONNECT_TIMEOUTパラメータを設定します。たとえば、使用できなくなったホストへの接続をクライアントが試行すると、その接続試行はSQLNET.OUTBOUND_CONNECT_TIMEOUTパラメータに指定した時間に制限され、その時間が経過すると、クライアントはアドレス・リストの次のホストへの接続を試行します。接続が確立されるまで、アドレス・リストの各ホストに対して接続試行が継続されます。
ほとんどの環境では、SQLNET.OUTBOUND_CONNECT_TIMEOUTパラメータの値を3秒に設定すれば十分です。たとえば、sqlnet.oraファイルに次のエントリを追加します。
SQLNET.OUTBOUND_CONNECT_TIMEOUT=3
