| Oracle In-Memory Database Cacheユーザーズ・ガイド リリース11.2.1 B56054-01 |
|
 戻る |
 次へ |
この章では、予定されたメンテナンス中に使用されるSynchronous Local Data GuardまたはData Guardと連携するようにOracle In-Memory Database Cacheを構成する方法について説明します。内容は次のとおりです。
OracleMaximum Availability Architecture（MAA）は、実証済のOracle高可用性（HA）テクノロジおよび推奨事項に基づいたOracleベスト・プラクティスのブループリントです。 MAAの目的は、コストおよび複雑さを最小限に抑えて最適な高可用性アーキテクチャを実現することです。
MAAに準拠するために、Oracle In-Memory Database Cacheでは、独自のHA機能が備えられているのみでなく、Oracle Real Application Clusters（RAC）およびOracle Data Guardがサポートされている必要があります。 Oracle In-Memory Database Cacheでは、読取り専用キャッシュ・グループおよびAWTキャッシュ・グループでのキャッシュ表のアクティブ・スタンバイ・ペア・レプリケーションによって独自のHA機能が提供されています。Oracle In-Memory Database CacheおよびRACの詳細は、「RAC環境でのOracle In-Memory Database Cacheの使用」を参照してください。
Oracle Data Guardは、管理、監視および自動化のソフトウェア・インフラストラクチャを備えており、1つ以上の同期化されたスタンバイ・データベースを作成および保持して障害、災害、エラーおよび破損からデータを保護します。 計画停止または計画外停止のためプライマリ・データベースを使用できなくなった場合、Data Guardはスタンバイ・データベースをプライマリ・ロールに切り替えて、停止時間を最小限に抑え、データの損失を防ぐことができます。 Data Guardの詳細は、『Oracle Data Guard概要および管理』を参照してください。
Oracle In-Memory Database CacheのMAAフレームワークでは、明示的にロードされる読取り専用キャッシュ・グループおよびAWTキャッシュ・グループのキャッシュ表がサポートされます。 任意のキャッシュ・グループ・タイプの動的キャッシュ・グループ、SWTキャッシュ・グループおよびAUTOREFRESHキャッシュ・グループ属性を使用するユーザー管理キャッシュ・グループのキャッシュ表の場合、Oracle In-Memory Database Cacheではフェイルオーバーおよびスイッチオーバー中にOracle Databaseにアクセスできません。これは、フェイルオーバーおよびスイッチオーバーが完了するまで、キャッシュ・アプリケーションが待機する必要があるためです。
ただし、一般的に、予定されたメンテナンス時には、すべてのキャッシュ・グループ・タイプがSynchronous Local Data GuardまたはData Guardでサポートされます。
キャッシュされたOracle表のオブジェクトIDがプライマリ・データベースとスタンバイ・データベースで同じままであるかぎり、Oracle In-Memory Database Cacheは同期フィジカル・スタンバイのフェイルオーバーとスイッチオーバー、およびロジカル・スタンバイのスイッチオーバーと連携します。 Oracle表を削除してから再作成した場合、Oracle表に変更を加えた場合または切捨てフラッシュバック処理やオンライン・セグメント縮小を実行した場合は、オブジェクトIDが変更される可能性があります。
一時アップグレード中に、フィジカル・スタンバイ・データベースがロジカル・スタンバイ・データベースに変換されます。 スタンバイ・データベースがロジカルである間、ユーザーは、キャッシュされたOracle表のオブジェクトIDが変更されないようにする必要があります。 特に、キャッシュされた表に対しては、削除、再作成、切捨て、変更、フラッシュバック、オンライン・セグメント縮小は実行しないでください。
Oracle In-Memory Database Cacheでフェイルオーバーおよびスイッチオーバーを適切に実行するには、次の手順に従って、Oracleプライマリ・データベースおよびスタンバイ・データベースを構成します。
Oracle In-Memory Database Cacheデーモン・プロセスおよびアプリケーション・クライアントがフェイルオーバー・イベントおよびスイッチオーバー・イベントにより速く応答するように、Data Guard BrokerでData Guard構成を管理する必要があります。
Oracle RACデータベースを構成している場合は、Oracle Enterprise Managerの「クラスタ管理データベース・サービス」ページを使用して、Oracle In-Memory Database Cacheおよびそのクライアント・アプリケーションがOracleプライマリ・データベースに接続するために使用するデータベース・サービスを作成します。 データベース・サービスの作成の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』の自動ワークロード管理の概要に関する説明を参照してください。
手順2でデータベース・サービスを作成した場合は、DBMS_SERVICE PL/SQLパッケージのMODIFY_SERVICEファンクションを使用してそのサービスを変更します。aq_ha_notifications属性をTRUEに設定して、アドバンスト・キューイング（AQ）を介して高可用性通知を送信できるようにします。 サーバー側のTAF設定を構成するには、次の例に示すように、FAILOVER属性を設定します。
exec 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);
手順2でデータベース・サービスを作成しなかった場合は、DBMS_SERVICE PL/SQLパッケージのCREATE_SERVICEファンクションを使用してデータベース・サービスを作成し、高可用性通知を有効にして、サーバー側のTAF設定を構成します。
exec 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);
Data Guardスタンバイ・データベース（RACまたは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サービスへの接続を切断して、Oracle In-Memory Database 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;
オプションとして、Oracle In-Memory Database 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サービスを停止し、そのサービスに接続されているすべてのセッションを切断しておきます。 その後、ロジカル・スタンバイ・データベースでサービスを開始します。
この時点で、キャッシュ・アプリケーションによってスタンバイ・データベースへの再接続が試行されます。 スイッチオーバーが発生しても、プライマリ・データベースからスタンバイ・データベースに接続を移行するために待機する必要はありません。 このため、Oracle In-Memory Database Cacheおよびそのアプリケーションのパフォーマンスが影響を受けなくなります。
詳細は、ホワイト・ペーパー『Maximum Availability Architecture, Oracle Best Practices for High Availability』を参照してください。
FAN HAイベントの通知を受信して、障害が発生したOracleインスタンスへの再接続を回避するように、TimesTenを構成します。 Oracle In-Memory Database Cacheに付属のOracleクライアントを使用します。
すべてのプライマリ・ホストおよびスタンバイ・ホストを含むOracleネット・サービス名をADDRESS_LISTに作成します。例:
DBSERV = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = LOC1PRIMARY)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = LOC1STANDBY)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = LOC2PRIMARY)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = LOC2STANDBY)(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
