| Oracle® TimesTen Application-Tier Database Cacheユーザーズ・ガイド 11g リリース2 (11.2.2) B66442-07 |
|
 前 |
 次 |
この章では、予定されたメンテナンス中に使用される同期Data GuardまたはData Guardと連携するようにTimesTen Application-Tier Database Cache (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 Application-Tier Database Cacheの使用」を参照してください。
Oracle Data Guardは、管理、監視および自動化のソフトウェア・インフラストラクチャを備えており、1つ以上の同期化されたスタンバイ・データベースを作成および保持して障害、災害、エラーおよび破損からデータを保護します。計画停止または計画外停止のためプライマリ・データベースを使用できなくなった場合、Data Guardはスタンバイ・データベースをプライマリ・ロールに切り替えて、停止時間を最小限に抑え、データの損失を防ぐことができます。Data Guardの詳細は、『Oracle Data Guard概要および管理』を参照してください。
TimesTen CacheのMAAフレームワークでは、明示的にロードされる読取り専用キャッシュ・グループおよびAWTキャッシュ・グループのキャッシュ表がサポートされます。任意のキャッシュ・グループ・タイプの動的キャッシュ・グループ、SWTキャッシュ・グループおよびAUTOREFRESHキャッシュ・グループ属性を使用するユーザー管理キャッシュ・グループのキャッシュ表の場合、キャッシュ・アプリケーションがフェイルオーバーおよびスイッチオーバーが完了するまで待機する必要があるため、TimesTen Cacheではフェイルオーバーおよびスイッチオーバー中にOracle Databaseにアクセスできません。
ただし、一般的に、予定されたメンテナンス時には、すべてのキャッシュ・グループ・タイプが同期Data GuardまたはData Guardでサポートされます。
キャッシュされたOracle Database表のオブジェクトIDがプライマリ・データベースとスタンバイ・データベースで同じままであるかぎり、TimesTen Cacheは同期フィジカル・スタンバイのフェイルオーバーとスイッチオーバー、およびロジカル・スタンバイのスイッチオーバーと連携します。Oracle表を削除してから再作成した場合、Oracle表に変更を加えた場合または切捨てフラッシュバック処理やオンライン・セグメント縮小を実行した場合は、オブジェクトIDが変更される可能性があります。
一時アップグレード中に、フィジカル・スタンバイ・データベースがロジカル・スタンバイ・データベースに変換されます。スタンバイ・データベースがロジカルである間、ユーザーは、キャッシュされたOracle Database表のオブジェクトIDが変更されないようにする必要があります。特に、キャッシュされた表に対しては、削除、再作成、切捨て、変更、フラッシュバック、オンライン・セグメント縮小は実行しないでください。
TimesTen Cacheでフェイルオーバーおよびスイッチオーバーを適切に実行するには、次の手順を使用して、Oracleプライマリ・データベースおよびスタンバイ・データベースを構成します。
TimesTen Cacheデーモン・プロセスおよびアプリケーション・クライアントがフェイルオーバー・イベントおよびスイッチオーバー・イベントにより速く応答するように、Data Guard BrokerでData Guard構成を管理する必要があります。
Oracle RACデータベースを構成している場合は、Oracle Enterprise Managerの「Cluster Managed Database Services」ページを使用して、TimesTen Cacheおよびそのクライアント・アプリケーションがOracleプライマリ・データベースに接続するために使用するデータベース・サービスを作成します。データベース・サービスの作成の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』の自動ワークロード管理の概要に関する説明を参照してください。
手順2でデータベース・サービスを作成した場合は、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
