第 1 章 Oracle Data Guard ソフトウェアによるデータ複製

この章では、Sun Cluster Geographic Edition 環境での Oracle Data Guard ソフトウェアを使用したデータ複製の構成方法について説明します。

この章の内容は次のとおりです。

• 「Oracle Data Guard 保護グループ内のデータの複製 (作業マップ)」

• 「Oracle Data Guard データ複製の概要」

• 「Oracle Data Guard ソフトウェアの初期構成」

このリリースの Sun Cluster Geographic Edition では、次の Oracle Data Guard データベースのスタンバイのタイプ がサポートされています。

• フィジカルスタンバイ

• ロジカルスタンバイ

Sun Cluster Geographic Edition ソフトウェアでは、Oracle Real Application Clusters (RAC) ソフトウェアを使用したデータ複製に Oracle Data Guard を使用できます。 Oracle Data Guard を使用してデータ複製を行うには、Oracle Data Guard のマニュアルを熟知する必要があります。Oracle Data Guard ソフトウェアおよび最新のパッチについては、Oracle Data Guard のマニュアル を参照してください。

データの複製中、主クラスタからのデータはバックアップクラスタまたはスタンバイクラスタにコピーされます。スタンバイクラスタは、主クラスタから地理的に離れた場所に配置できます。主クラスタとスタンバイクラスタ間の距離は、使用するデータ複製製品によってサポートされる距離によって異なります。

この章の手順の例では、プライマリデータベースとスタンバイデータベース間でデータを複製できるように Oracle Data Guard を構成する方法について説明します。

Oracle Data Guard 保護グループ内のデータの複製 (作業マップ)

次の表では、保護グループにおける Oracle Data Guard データ複製を構成する手順を要約します。

Oracle Data Guard データ複製の概要

この節では、Oracle Data Guard と Sun Cluster Geographic Edition の統合について概要を示します。また、Oracle Data Guard と Sun StorageTek^TM Availability Suite ソフトウェア Hitachi TrueCopy および EMC SRDF などのその他データ複製製品に対するサポートの違いについて示します。

Oracle Data Guard シャドウリソースグループ

保護グループに Oracle Data Guard ソフトウェアによって制御される Oracle Data Guard Broker 構成を追加できます。 Sun Cluster Geographic Edition ソフトウェアによって、各 Oracle Data Guard Broker 構成に対し シャドウ RAC サーバープロキシリソースグループ が作成されます。 シャドウリソースグループの名前の書式は次のとおりです。

ODGconfigurationname-rac-proxy-svr-shadow-rg

たとえば、Oracle Data Guard ソフトウェアによって制御される sales という名前の Oracle Data Guard Broker 構成に、sales という名前の シャドウ RAC サーバープロキシリソースグループ があるとします。 -rac-proxy-svr-shadow-rg。 ただし、構成名に 1 つ以上のピリオド (.) が含まれている場合、ピリオドが下線 (_) に変換された状態でリソースグループ名が作成されます。したがって、構成名 mysales.com は、mysales_com -rac-proxy-svr-shadow-rg という名前のシャドウリソースグループを含むことになります。

Sun Cluster ソフトウェアの制御下にある Oracle RAC データベースを管理および監視するよう作成した実際の RAC サーバープロキシリソースグループ の「シャドウ」が、シャドウ RAC サーバープロキシリソースグループ によって作成されます。

各シャドウリソースグループには単一のリソース SUNW.gds リソースがあります。このリソースの検証機能スクリプトによって、RAC サーバープロキシリソースグループ の状態が反映されます。 このリソースの名前の書式は次のとおりです。

ODGconfigurationname-rac-proxy-svr-shadow-rs

RAC サーバープロキシリソースグループ の詳細は、『Sun Cluster Data Service for Oracle RAC Guide for Solaris OS 』を参照してください。

その他の Sun Cluster Geographic Edition 複製ソフトウェアと違い、Oracle Data Guard ソフトウェアは Oracle RAC ソフトウェアの中心的な機能であるため、シャドウ RAC サーバープロキシリソースグループ が必要です。Oracle Data Guard を使用するには Oracle RAC ソフトウェアを実行中にし、データベースによってデータの複製が開始されている必要があります。

したがって、実際の RAC サーバープロキシリソースグループ を Sun Cluster Geographic Edition の制御下に置くことにより、スタンバイクラスタ上で Oracle RAC データベースを停止することになります。対照的に、シャドウ RAC サーバープロキシリソースグループ は Sun Cluster Geographic Edition の制御下に置くことができます。 この操作はデータ複製処理を妨げることなく実行できます。この操作を実行しても、アプリケーションリソースグループを管理する通常の Sun Cluster Geographic Edition 構造に構成を合わせることができます。

シャドウ RAC サーバープロキシリソースグループ の状態には、RAC サーバープロキシリソースグループ によって監視、制御されているデータベースが、主クラスタまたはスタンバイクラスタのどちらであるかが示されます。つまり、この状態は、データベースが主クラスタ上でオンラインであり、スタンバイクラスタ上では管理されていないことを表します。 さらに、シャドウ RAC サーバープロキシリソース の状態には、RAC サーバープロキシリソース の状態とデータベースがプライマリまたはスタンバイのどちらであるかが反映されます。

Oracle Data Guard 複製リソースグループ

Oracle Data Guard ソフトウェアを制御している Oracle Data Guard Broker 構成が保護グループに追加される場合、Sun Cluster Geographic Edition ソフトウェアによって、複製リソースグループ内の特定の Oracle Data Guard Broker 構成に対して特別な複製リソースが作成されます。これらの複製リソースグループを監視することにより、Sun Cluster Geographic Edition ソフトウェアは複製の全体的な状態を監視できます。各保護グループには、各 Oracle Data Guard Broker 構成の複製リソースを 1 つ持つ複製リソースグループが 1 つ作成されます。

複製リソースグループの名前の書式は次のとおりです。

ODGProtectiongroupName-odg-rep-rg。

複製リソースグループ内の複製リソースは、ローカルクラスタ上の Oracle Data Guard Broker 構成の複製状態を監視します。その結果は、Oracle Data Guard Broker ソフトウェアによって報告されます。

複製リソースの名前の書式は次のとおりです。

ODGBrokerConfigurationName-odg-rep-rs。

Oracle Data Guard では、保護グループがクラスタ内で有効化されているときに、データ複製リソースが有効です。 したがって、Oracle Data Guard では、保護グループが無効化されているクラスタ内では、データ複製の状態は unknown と表示されます。

Oracle Data Guard ソフトウェアの初期構成

この節では、Sun Cluster Geographic Edition 製品に Oracle Data Guard 複製の構成に必要な最初の手順について説明します。

このマニュアルには、dgmgrl など、Oracle ツールおよびコマンドの使用方法に関する情報を示す手順は、図のみに対応しています。使用している環境の必要に応じて、Oracle 関連資料を参照して、相応的な手順を決定します。

この節で例として示されている保護グループ sales-pg は、cluster-paris と cluster-newyork の 2 つの (パートナー) クラスタから成るパートナーシップ内に構成されています。Oracle RAC データベースは、各クラスタ上の個々の RAC サーバープロキシリソースグループ によって管理および監視されており、mysales_com -rac-proxy-svr-shadow-rg シャドウ RAC サーバープロキシリソースグループ によってそのシャドウが作成されます。 アプリケーションデータは mysales.com Oracle Data Guard Broker 構成の一部として、sales データベースに含まれ、Oracle Data Guard によって複製されます。

シャドウ RAC サーバープロキシリソースグループ、mysales_com-rac-proxy-svr-shadow-rg および Oracle Data Guard Broker 構成 mysales.com は cluster-paris クラスタと cluster-newyork クラスタの両方に存在します。 ただし、リソースグループがシャドウを作成する RAC サーバープロキシリソースグループ の名前は cluster-paris クラスタと cluster-newyork クラスタの両方で異なる可能性があります。 sales-pg 保護グループは、cluster-paris クラスタと cluster-newyork クラスタ間のデータ複製を管理することによって、アプリケーションデータを保護します。

この節では、次の内容について説明します。

• 「Oracle Data Guard Broker 構成」

• 「プライマリデータベースをセットアップする」

• 「プライマリデータベースのリスナーとネーミングサービスを構成する方法」

• 「スタンバイデータベースの準備方法」

• 「スタンバイデータベースリスナーとネーミングサービスの構成方法」

• 「スタンバイデータベースの起動およびリカバリ方法」

• 「構成が正しく動作することを検証する方法」

• 「構成を完了し、スタンバイデータベースを統合する方法」

• 「Oracle Data Guard Broker 構成を作成し、有効にする方法」

Oracle Data Guard Broker 構成

Oracle Data Guard Broker 構成を定義するには、次の情報を決定する必要があります。

• Oracle Data Guard Broker 構成の名前。たとえば、cluster-paris クラスタと cluster-newyork クラスタ間で複製される mysales.com。

• 複製に参加する固有のデータベース名。たとえば、sales (cluster-paris クラスタ上) および salesdr (cluster-newyork クラスタ上)。

• 次のデータベースの Oracle サービス名。たとえば、sales -svc (cluster-paris クラスタ上) および salesdr-svc (cluster-newyork クラスタ上)。これらの名前は tnsnames.ora ファイルに保持されています。このファイルは複製中の Oracle データベースをホストしているノードの ${ORACLE_HOME}/network/admin ディレクトリまたは Oracle ネーミングサービスディレクトリにあります。

• Oracle Data Guard Broker 構成のデータベースのスタンバイのタイプ。physical または logical を設定できます。

• Oracle Data Guard Broker 構成の複製モード。MaxPerformance、MaxAvailability、または MaxProtection を設定できます。

プライマリデータベースとスタンバイデータベースのペア間での Oracle Data Guard 複製を構成したあと、${ORACLE_HOME}/bin/dgmgrl コマンドを使用して Oracle Data Guard Broker 構成を作成できます。このコマンドを使用すると、以前に一覧表示された Oracle Data Guard Broker プロパティーを設定し、取得できます。

また、各クラスタ上の Oracle RAC データベースを管理する RAC サーバープロキシリソースグループ の名前を決定する必要があります。 これらの名前は、clsetup コマンドから実行される Data Service 構成ウィザードを使用するか、『Sun Cluster Data Service for Oracle RAC Guide for Solaris OS』の付録 D「Command-Line Alternatives」の手順に従って構成します。

次の表に示す Oracle Data Guard Broker 構成プロパティーのうち、Protection Mode プロパティーのみが Sun Cluster Geographic Edition を使用して変更できます。DelayMins、MaxFailure、MaxConnections、NetTimeout プロパティーなどの、構成内のその他の Oracle Data Guard Broker プロパティーは、Sun Cluster Geographic Edition ソフトウェアを使用して変更できません。これらのプロパティーを調整するには、手動で Oracle Data Guard Broker コマンドを使用する必要があります。または、SQL*Plus を使用して、spfile サーバーパラメータファイルまたは init${SID}.ora ファイルに保持されている適切なパラメータを手動で変更して、調整する必要があります。

Sun Cluster Geographic Edition ソフトウェアでは、スイッチオーバーとテイクオーバー操作中の Oracle Data Guard Broker 構成の役割の変更を修正します。

Oracle Data Guard Broker 構成の詳細は、Oracle Data Guard Broker のマニュアル を参照してください。

プライマリデータベースをセットアップする

次の手順では、主クラスタは cluster-paris (phys-paris-1 ノードと phys-paris-2 ノード) およびスタンバイクラスタは cluster-newyork (phys-newyork-1 と phys-newyork-2) という名前になっています。サフィックス -crs が Oracle Clusterware の仮想 IP ホスト名に追加されます。

cluster-paris 上のプライマリデータベースは sales で、sales1 および sales2 というインスタンスを持っています。 cluster-newyork 上のスタンバイデータベースは salesdr で、salesdr1 および salesdr2 というインスタンスを持っています。各データベースと各インスタンスのネットサービス名には、サフィックス -svc が追加されます。たとえば、sales-svc または sales1 -svc のようになります。

始める前に

Oracle ユーザー .profile または .cshrc ファイルを編集し、正しい Oracle SID 、ORACLE_HOME、および PATH 環境変数がローカルの Oracle RAC データベースインスタンスに対して設定されていることを確認します。 特に指定がない限り、必要な操作は、保護されたデータベースインスタンスをホストする主クラスタ内のノードからコマンドを実行するだけです。

1. すべての主ノードおよびスタンバイノード上で Oracle Clusterware によって使用される Oracle 仮想 IP アドレスが解決できることを確認します。

   phys-paris-1# getent hosts phys-paris-1-crs 10.11.112.41 phys-paris-1-crs …

2. 主クラスタ上にデータベースを作成します。

   Oracle Database Configuration Assistant (dbca) または SQL*Plus ユーティリティーのいずれかを使用します。

3. プライマリデータベースに対する Oracle パスワードファイルが存在することを確認します。

   oracle (phys-paris-1)$ cd ${ORACLE_HOME}/dbs oracle (phys-paris-1)$ ls -l orapwsales1 lrwxrwxrwx 1 oracle oinstall 25 November 2 02:06 orapwsales1 -> /oradata/SALES/orapwsales

   Oracle Data Guard では、主クラスタとスタンバイクラスタに参加するすべてのノードで、パスワードファイルを一致させる必要があります。

   パスワードファイルがない場合は、以下の手順に従って作成します。

   oracle (phys-paris-1)$ orapwd file=${ORACLE_HOME}/dbs/orapwsales1 \ password=sysdba_password

   その後、このファイルを共有ストレージ上の任意の場所に移動し、各ノードからのシンボリックリンクを作成できます。各ノード上でのローカル SID を反映するよう、ファイル名を変更します。その後、このファイルをスタンバイクラスタ (cluster-newyork) にコピーします。

4. sqlplus コマンドを使用して、データベースがロギングモードで動作していることを確認します。

   oracle (phys-paris-1)$ sqlplus '/ as sysdba' SQL> alter database force logging; Database altered.

5. Oracle Data Guard Broker 構成ファイルの場所を構成します。

   次のように sqlplus コマンドを実行し、これら 2 つのファイル名を構成に従った名前に置き換えます。これらのファイルが、すべての cluster-paris から見ることができる共有ストレージに置かれていることを確認します。

   oracle (phys-paris-1)$ sqlplus '/ as sysdba' SQL> alter system set dg_broker_config_file1='/oradata/SALES/dr1sales.dat' 2 scope=both sid='*'; System altered. SQL> alter system set dg_broker_config_file2='/oradata/SALES/dr2sales.dat' 2 scope=both sid='*'; System altered.

6. すべてのデータベースインスタンスをシャットダウンします。

7. プライマリデータベース上で、単一のデータベースインスタンスをマウントし、Oracle データベースのフラッシュバック機能を有効にします。

   oracle (phys-paris-1)$ sqlplus '/ as sysdba' SQL> startup mount; ORACLE instance started. Total System Global Area 532676608 bytes Fixed Size 2031416 bytes Variable Size 276824264 bytes Database Buffers 247463936 bytes Redo Buffers 6356992 bytes Database mounted. System altered. SQL> alter database archivelog; Database altered. SQL> alter database flashback on; Database altered. SQL> alter database open; Database altered.

8. もう一方のデータベースインスタンスを再起動します。

9. データベースのスタンバイ REDO ログを作成します。

   構成によっては、多数の REDO ログを追加しなければならない場合があります。これらのログの名前、数、およびサイズは多くの要因によって決まります。要因には、OFA (Oiptimal Flexible Architecture) を使用するかどうか、オンライン REDO ログの数、これらのログのサイズなどがあります。次の例では、OFA のネーミングスキームが使用されている状況で、50 MB の REDO ログファイルを 1 つ構成する方法を示します。デフォルトでは、通常 2 ノードの Oracle RAC データベースには、6 つのログファイルを追加する必要があります。

   oracle (phys-paris-1)$ sqlplus '/ as sysdba' SQL> alter database add standby logfile size 50m; Database altered.

10. Oracle ログのアーカイブ先を構成します。

    構成によっては、Oracle ログのアーカイブ先のパラメータを 1 つ以上変更または追加しなければならない場合があります。これらのパラメータには、チューニング可能なプロパティーが数多くあります。詳細については、Oracle のマニュアルを参照してください。次の例では、ログのアーカイブ先が 2 つ設定されています。1 つはローカルクラスタ用、もう 1 つはスタンバイクラスタ用で、OFA のネーミングが使用されています。

    oracle (phys-paris-1)$ sqlplus '/ as sysdba' SQL> alter system set log_archive_dest_1='location=use_db_recovery_file_dest 2 arch mandatory valid_for=(all_logfiles,all_roles) 3 db_unique_name=sales' scope=both sid='*'; System altered. SQL> alter system set log_archive_dest_2='service=salesdr-svc 2 lgwr sync affirm valid_for=(online_logfiles,primary_role) 3 db_unique_name=salesdr' scope=both sid='*'; System altered. SQL> alter system set log_archive_dest_10='location=use_db_recovery_file_dest' 2 scope=both sid='*'; System altered. SQL> alter system set standby_file_management='AUTO' scope=both sid='*'; System altered.

11. FAL (Fetch Archive Log) パラメータを構成します。

    失われているアーカイブ REDO ログを取得するサーバー上の場所と、REDO ログの送信先となるクライアント上の場所をデータベースに認識させるには、FAL システムプロパティーを設定する必要があります。これらのプロパティーでは、ソースデータベースと宛先データベースのネットサービス名が使用されます。 次の sqlplus コマンドを実行して、構成に従った正しい値にパラメータを設定します。

    oracle (phys-paris-1)$ sqlplus '/ as sysdba' SQL> alter system set fal_server='salesdr-svc' scope=both sid='*'; System altered. SQL> alter system set fal_client='sales-svc' scope=both sid='*'; System altered.

プライマリデータベースのリスナーとネーミングサービスを構成する方法

1. Oracle Data Guard の静的リスナーを作成します。

   ---

   注 –

   すべての cluster-paris ノード上で、この手順を実行します。

   ---

   Oracle Data Guard では、静的リスナーを構成する必要があります。 次の例では、${ORACLE_HOME}=/oracle/oracle/product/10.2.0/db_1 を使用し、静的リスナーのエントリを追加する ${ORACLE_HOME}/network/admin/listener.ora ファイル内の場所を示します。SID_LIST_LISTENER_PHYS-PARIS-1 および (SID_NAME = sales1) 行はノードによって異なり、(GLOBAL_DBNAME=sales_DGMGRL) は cluster-newyork によって異なります。その後、これらのエントリを cluster-newyork ノード上で追加します。

   oracle (phys-paris-1)$ cat ${ORACLE_HOME}/network/admin/listener.ora SID_LIST_LISTENER_PHYS-PARIS-1 = (SID_LIST = (SID_DESC = (SID_NAME = PLSExtProc) (ORACLE_HOME = /oracle/oracle/product/10.2.0/db_1) (PROGRAM = extproc) ) (SID_DESC = (SID_NAME = sales1) (GLOBAL_DBNAME=sales_DGMGRL) (ORACLE_HOME = /oracle/oracle/product/10.2.0/db_1) ) ) oracle (phys-paris-1)$

2. リスナーを再起動します。

   静的なエントリを有効にするには、Oracle リスナープロセスを cluster-paris の各ノード上で再起動します。

   oracle (phys-paris-1)$ lsnrctl stop LISTENER_PHYS_PHYS-PARIS-1 LSNRCTL for Solaris: Version 10.2.0.3.0 - Production on 29-OCT-2008 02:04:56 Copyright (c) 1991, 2006, Oracle. All rights reserved. Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)) The command completed successfully oracle$ lsnrctl start LISTENER_PHYS_PHYS-PARIS-1 LSNRCTL for Solaris: Version 10.2.0.3.0 - Production on 29-OCT-2008 02:05:04 Copyright (c) 1991, 2006, Oracle. All rights reserved. Starting /oracle/oracle/product/10.2.0/db_1/bin/tnslsnr: please wait... TNSLSNR for Solaris: Version 10.2.0.3.0 - Production … Services Summary... Service "PLSExtProc" has 1 instance(s). Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service... Service "sales" has 2 instance(s). Instance "sales1", status READY, has 2 handler(s) for this service... Instance "sales2", status READY, has 1 handler(s) for this service... Service "salesXDB" has 2 instance(s). Instance "sales1", status READY, has 1 handler(s) for this service... Instance "sales2", status READY, has 1 handler(s) for this service... Service "sales_DGB" has 2 instance(s). Instance "sales1", status READY, has 2 handler(s) for this service... Instance "sales2", status READY, has 1 handler(s) for this service... Service "sales_DGMGRL" has 1 instance(s). Instance "sales1", status UNKNOWN, has 1 handler(s) for this service... Service "sales_XPT" has 2 instance(s). Instance "sales1", status READY, has 2 handler(s) for this service... Instance "sales2", status READY, has 1 handler(s) for this service... The command completed successfully

3. すべてのデータベースインスタンスに対するネットサービスのネーミングエントリを確認します。

   使用しているネーミングメソッド (tnsnames.ora またはディレクトリサービス) で、すべての Oracle データベースインスタンスのエントリが定義されていることを確認します。次の例では、cluster-paris クラスタのみに使用するエントリの種類を示します。また、pfile パラメータファイルを変更するときに、あとで作成するスタンバイ (salesdr) データベースインスタンスのエントリを追加します。この例では、sales データベースが、リスナー (データベースの service_names 初期化パラメータを参照) を使用して、動的に sales のサービス名を登録します。

   oracle (phys-paris-1)$ cat ${ORACLE_HOME}/network/admin/tnsnames.ora SALES1-SVC = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = phys-paris-1-crs)(PORT = 1521) (SEND_BUF_SIZE = 65535)(RECV_BUF_SIZE = 65535)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = sales) (INSTANCE_NAME = sales1) ) ) SALES2-SVC = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = phys-paris-2-crs)(PORT = 1521) (SEND_BUF_SIZE = 65535)(RECV_BUF_SIZE = 65535)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = sales) (INSTANCE_NAME = sales2) ) ) SALES-SVC = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = phys-paris-1-crs)(PORT = 1521) (SEND_BUF_SIZE = 65535)(RECV_BUF_SIZE = 65535)) (ADDRESS = (PROTOCOL = TCP)(HOST = phys-paris-2-crs)(PORT = 1521) (SEND_BUF_SIZE = 65535)(RECV_BUF_SIZE = 65535)) (LOAD_BALANCE = yes) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = sales) ) ) LISTENERS_SALES = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = phys-paris-1-crs)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = phys-paris-2-crs)(PORT = 1521)) )

スタンバイデータベースの準備方法

1. プライマリデータベースのバックアップを作成します。

   次の例では、Oracle RMAN (Recovery Manager) ユーティリティーを使用して、スタンバイ cluster-newyork クラスタ上に、復元可能なプライマリデータベースのコピーを作成する方法を示します。また、この例では、スタンバイデータベースのコントロールファイルを作成する別の手順が不要になる方法について説明します。この手順を完了するためのオプションについては、Oracle のマニュアルを参照してください。

   oracle (phys-paris-1)$ rman RMAN> connect target sys/DBA_password@sales-svc; RMAN> connect auxiliary /; RMAN> backup device type disk tag 'mybkup' database include current 2> controlfile for standby; RMAN> backup device type disk tag 'mybkup' archivelog all not backed up;

2. スタンバイシステムにバックアップファイルをコピーします。

   cluster-newyork クラスタ上に適切なディレクトリ階層を作成し、このクラスタにデータベースのバックアップをコピーします。この例で使用されているファイルの実際の場所は、データベースを構成したときに選択した場所によって異なります。

   oracle (phys-newyork-1)$ mkdir -p $ORACLE_BASE/admin/salesdr oracle (phys-newyork-1)$ cd $ORACLE_BASE/admin/salesdr oracle (phys-newyork-1)$ mkdir adump bdump cdump dpdump hdump pfile udump Make the directory for the database backup oracle (phys-newyork-1)$ mkdir -p /oradata/flash_recovery_area/SALES/backupset/date Copy over the files oracle (phys-newyork-1)$ cd /oradata/flash_recovery_area/SALES/backupset/date oracle (phys-newyork-1)$ scp oracle@phys-paris-1:`pwd`/\* . Make the base directory for new database files oracle (phys-newyork-1)$ mkdir -p /oradata/SALESDR

3. pfile パラメータファイルを作成します。

   スタンバイ (salesdr) データベース用の適切なサーバー初期化ファイルを作成します。 このファイルの最も簡単な作成方法は、プライマリデータベース用のパラメータをコピーし、変更することです。次の例では、pfile パラメータファイルを作成する方法を示します。

   oracle (phys-paris-1)$ sqlplus '/ as sysdba' SQL> CREATE PFILE='/tmp/initpfile_for_salesdr.ora' FROM SPFILE; File created. SQL> quit

4. pfile パラメータファイルの変更

   次の例のように、主クラスタに固有のすべてのエントリをスタンバイクラスタに合うエントリに変更します。 Oracle SID によってプレフィックスが付けられているエントリ sales1 または sales2 を変更し、スタンバイデータベースのインスタンスの SID 名 (salesdr1 および salesdr2) を使用できるようにします。構成によっては、さらに変更しなければならない場合があります。

   ---

   注 –

   db_name パラメータは変更しないください。このパラメータは両方のクラスタ上で、sales という名前のままにしておく必要があります。

   ---

   You created these directories previously
   *.audit_file_dest='/oracle/oracle/product/10.2.0/db_1/admin/salesdr/adump'
   *.background_dump_dest='/oracle/oracle/product/10.2.0/db_1/admin/salesdr/bdump'
   *.user_dump_dest='/oracle/oracle/product/10.2.0/db_1/admin/salesdr/udump'
   *.core_dump_dest='/oracle/oracle/product/10.2.0/db_1/admin/salesdr/cdump'
   
   Remove the following entry
   *.control_files='...list primary control files...'
   
   Add this entry
   *.db_unique_name='salesdr'
   
   *.dg_broker_config_file1='/oradata/SALESDR/dr1salesdr.dat'
   *.dg_broker_config_file2='/oradata/SALESDR/dr2salesdr.dat'
   
   *.dispatchers='(PROTOCOL=TCP) (SERVICE=salesdrXDB)'
   
   Switch the client and server entries around, as shown in the following entries
   *.fal_client='salesdr-svc'
   *.fal_server='sales-svc'
   
   *.remote_listener='LISTENERS_SALESDR'
   
   Switch the log archive destinations
   *.log_archive_dest_1='location=use_db_recovery_file_dest arch
   mandatory valid_for=(all_logfiles,all_roles) db_unique_name=salesdr'
   *.log_archive_dest_2='service=sales-svc lgwr sync affirm 
   valid_for=(online_logfiles,primary_role) db_unique_name=sales'

5. pfile パラメータファイルをスタンバイシステムにコピーします。

6. スタンバイデータベースを起動し、pfile パラメータファイルを spfile サーバーパラメータファイルに変換します。

   1. Oracle ユーザーとして、cluster-newyork ノードの 1 つにログインし、pfile パラメータファイルを spfile サーバーパラメータファイルに変換します。

      oracle (phys-newyork-1)$ ORACLE_SID=salesdr1 export ORACLE_SID oracle (phys-newyork-1)$ sqlplus '/ as sysdba' SQL> startup nomount pfile='/tmp/initpfile_for_salesdr.ora'; SQL> create spfile='/oradata/SALESDR/spfilesalesdr.ora' 2> from pfile='/tmp/initpfile_for_salesdr.ora'; SQL> shutdown

   2. ${ORACLE_HOME}/dbs/initsalesdr1.ora ファイルをすべての cluster-newyork ノードに作成し、そのファイルに次のエントリを挿入します。

      oracle (phys-newyork-1) cat ${ORACLE_HOME}/dbs/initsalesdr1.ora SPFILE='/oradata/SALESDR/spfilesalesdr.ora'

   3. 1 つのノード上のみでデータベースを起動し、バックアップされたプライマリデータベースを復元する準備をします。

      oracle (phys-newyork-1) sqlplus '/ as sysdba' You are now starting from the spfile SQL> startup nomount ORACLE instance started. Total System Global Area 532676608 bytes Fixed Size 2031416 bytes Variable Size 289407176 bytes Database Buffers 234881024 bytes Redo Buffers 6356992 bytes

7. プライマリデータベースに対する Oracle パスワードファイルを、スタンバイデータベースで使用するためにコピーします。

   cluster-paris クラスタ上で作成した Oracle パスワードファイルをコピーし、cluster-newyork クラスタ上の共有ストレージにそのファイルを配置します。各 cluster-newyork ノードからのこのファイルへのリンクを作成し、もう一度シンボリックリンクの名前を変更して、ローカルスタンバイノード上の Oracle SID を反映します。

スタンバイデータベースリスナーとネーミングサービスの構成方法

1. Oracle Data Guard の静的リスナーを作成します。

   ---

   注 –

   すべての cluster-newyork ノード上で、この手順を実行します。

   ---

   Oracle Data Guard では、静的リスナーを構成する必要があります。 次の例では、${ORACLE_HOME}=/oracle/oracle/product/10.2.0/db_1 を使用し、静的リスナーのエントリを追加する ${ORACLE_HOME}/network/admin/listener.ora ファイル内の場所を示します。SID_LIST_LISTENER_PHYS-NEWYORK-1 および (SID_NAME = salesdr1) 行はノードによって異なり、(GLOBAL_DBNAME=salesdr_DGMGRL) は cluster-paris によって異なります。

   oracle (phys-newyork-1)$ cat ${ORACLE_HOME}/network/admin/listener.ora SID_LIST_LISTENER_PHYS-NEWYORK-1 = (SID_LIST = (SID_DESC = (SID_NAME = PLSExtProc) (ORACLE_HOME = /oracle/oracle/product/10.2.0/db_1) (PROGRAM = extproc) ) (SID_DESC = (SID_NAME = salesdr1) (GLOBAL_DBNAME=salesdr_DGMGRL) (ORACLE_HOME = /oracle/oracle/product/10.2.0/db_1) ) ) oracle (phys-newyork-1)$

2. リスナーを再起動します。

   静的なエントリを有効にするには、Oracle リスナープロセスを cluster-newyork の各ノード上で再起動します。

   oracle (phys-newyork-1)$ lsnrctl stop LISTENER_PHYS_PHYS-NEWYORK-1 LSNRCTL for Solaris: Version 10.2.0.3.0 - Production on 29-OCT-2008 02:04:56 Copyright (c) 1991, 2006, Oracle. All rights reserved. Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)) The command completed successfully oracle$ lsnrctl start LISTENER_PHYS_PHYS-NEWYORK-1 LSNRCTL for Solaris: Version 10.2.0.3.0 - Production on 29-OCT-2008 02:05:04 Copyright (c) 1991, 2006, Oracle. All rights reserved. Starting /oracle/oracle/product/10.2.0/db_1/bin/tnslsnr: please wait... TNSLSNR for Solaris: Version 10.2.0.3.0 - Production … Services Summary... Service "PLSExtProc" has 1 instance(s). Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service... Service "salesdr" has 2 instance(s). Instance "salesdr1", status READY, has 2 handler(s) for this service... Instance "salesdr2", status READY, has 1 handler(s) for this service... Service "salesdrXDB" has 2 instance(s). Instance "salesdr1", status READY, has 1 handler(s) for this service... Instance "salesdr2", status READY, has 1 handler(s) for this service... Service "salesdr_DGB" has 2 instance(s). Instance "salesdr1", status READY, has 2 handler(s) for this service... Instance "salesdr2", status READY, has 1 handler(s) for this service... Service "salesdr_DGMGRL" has 1 instance(s). Instance "salesdr1", status UNKNOWN, has 1 handler(s) for this service... Service "salesdr_XPT" has 2 instance(s). Instance "salesdr1", status READY, has 2 handler(s) for this service... Instance "salesdr2", status READY, has 1 handler(s) for this service... The command completed successfully

3. すべてのデータベースインスタンスに対するネットサービスのネーミングエントリを確認します。

   使用しているネーミングメソッド (tnsnames.ora またはディレクトリサービス) で、すべての Oracle データベースインスタンスのエントリが定義されていることを確認します。次の例では、cluster-newyork クラスタのみに使用するエントリの種類を示します。この例では、salesdr データベースが、リスナー (データベース service_names 初期化パラメータを参照) を使用して、動的に salesdr のサービス名を登録します。

   oracle (phys-newyork-1)$ cat ${ORACLE_HOME}/network/admin/tnsnames.ora SALESDR1-SVC = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = phys-newyork-1-crs)(PORT = 1521) (SEND_BUF_SIZE = 65535)(RECV_BUF_SIZE = 65535)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = salesdr) (INSTANCE_NAME = salesdr1) ) ) SALESDR2-SVC = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = phys-newyork-2>-crs)(PORT = 1521) (SEND_BUF_SIZE = 65535)(RECV_BUF_SIZE = 65535)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = salesdr) (INSTANCE_NAME = salesdr2) ) ) SALESDR-SVC = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = phys-newyork-1-crs)(PORT = 1521) (SEND_BUF_SIZE = 65535)(RECV_BUF_SIZE = 65535)) (ADDRESS = (PROTOCOL = TCP)(HOST = phys-newyork-2-crs)(PORT = 1521) (SEND_BUF_SIZE = 65535)(RECV_BUF_SIZE = 65535)) (LOAD_BALANCE = yes) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = salesdr) ) ) LISTENERS_SALESDR = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = phys-newyork-1-crs)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = phys-newyork-2-crs)(PORT = 1521)) )

4. スタンバイリスナー listener.ora ファイルおよび tnsnames.ora ファイルに正しいエントリが設定されていることを確認し、リスナープロセスを再起動します。

   これらのファイルに静的 Oracle Data Guard リスナーのエントリ、およびプライマリデータベースとスタンバイクラスタサービスのエントリが設定されていることを確認します。 Oracle ディレクトリネーミングサービスの検索を使用していない場合は、tnsnames.ora ファイルにこれらのエントリを設定する必要があります。

   oracle (phys-newyork-1)$ lsnrctl stop LISTENER_PHYS-NEWYORK-1 LSNRCTL for Solaris: Version 10.2.0.3.0 - Production on 29-OCT-2008 02:04:56 Copyright (c) 1991, 2006, Oracle. All rights reserved. Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)) The command completed successfully oracle$ lsnrctl start LISTENER_PHYS-NEWYORK-1 LSNRCTL for Solaris: Version 10.2.0.3.0 - Production on 29-OCT-2008 02:05:04 Copyright (c) 1991, 2006, Oracle. All rights reserved. Starting /oracle/oracle/product/10.2.0/db_1/bin/tnslsnr: please wait... TNSLSNR for Solaris: Version 10.2.0.3.0 - Production … Services Summary... Service "PLSExtProc" has 1 instance(s). Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service... Service "salesdr_DGMGRL" has 1 instance(s). Instance "salesdr1", status UNKNOWN, has 1 handler(s) for this service... The command completed successfully

スタンバイデータベースの起動およびリカバリ方法

1. データベースのバックアップを復元します。

   cluster-newyork クラスタ上で作業を続行しながら、プライマリデータベースのバックアップからスタンバイデータベースにデータを復元できます。 次の例では、Oracle RMAN (Recovery Manager) ユーティリティーを使用する方法を示します。

   oracle (phys-newyork-1) rman RMAN> connect target sys/oracle@sales-svc; RMAN> connect auxiliary /; RMAN> duplicate target database for standby nofilenamecheck; …

2. スタンバイ REDO ログをスタンバイデータベースに追加します。

   満たす必要のある正確な条件は、構成によって異なります。主クラスタの場合と同じ手順を実行します。

3. スタンバイデータベース上でフラッシュバックを有効にします。

   oracle (phys-newyork-1)$ sqlplus '/ as sysdba' SQL> alter database flashback on; Datbase altered. SQL> shutdown immediate; SQL> startup mount; ORACLE instance started. …

4. スタンバイデータベースを回復します。

   oracle (phys-newyork-1) sqlplus '/ as sysdba' SQL> alter database recover managed standby database using current logfile disconnect;

構成が正しく動作することを検証する方法

1. ログファイルの送信が動作していることを確認します。

   SQL> プロンプトが表示されているときに、cluster-paris クラスタ上の 1 つのデータベースインスタンスにログインし、2 つのログスイッチを実行します。

   oracle (phys-paris-1)$ sqlplus '/ as sysdba' SQL> alter system switch logfile; SQL> alter system switch logfile;

2. ログのアーカイブを妨げた可能性がある問題が記録されているかどうか、${ORACLE_HOME}/admin/sales/bdump/alert_sales1.log を確認します。

   エラーがある場合は、修正します。この処理には時間がかかる場合があります。次のコマンドを使用して、ネットワークの接続が正しいことを確認できます。

   oracle (phys-paris-1)$ tnsping salesdr-svc oracle (phys-newyork-1)$ tnsping sales-svc

構成を完了し、スタンバイデータベースを統合する方法

1. Oracle Clusterware を使用して新しいデータベースとインスタンスを登録します。

   Oracle Clusterware の制御下にスタンバイデータベースを置き、Oracle Clusterware の起動時にマウントするようスタンバイデータベースを構成します。

   oracle (phys-newyork-1)$ srvctl add database -d salesdr \ -r PHYSICAL_STANDBY -o $ORACLE_HOME -s mount; oracle (phys-newyork-1)$ srvctl add instance -d salesdr \ -i salesdr1 -n $phys-newyork-1; oracle (phys-newyork-1)$ srvctl add instance -d salesdr \ -i salesdr2 -n $phys-newyork-2;

2. Sun Cluster Oracle RAC の管理容易性リソースを構成します。

   Sun Cluster とスタンバイデータベースを統合します。 clsetup ユーティリティから使用可能な Data Service 構成ウィザードまたはブラウザベースの Sun Cluster Manager を使用できます。スタンバイデータベースを統合すると、フェイルオーバーまたはテイクオーバーの実行が必要な場合、スタンバイデータベースをプライマリデータベースのように管理できます。

   ---

   注 –

   作成したリソースグループおよびリソースグループは Sun Cluster Geographic Edition Oracle Data Guard 統合によって使用されます。

   ---

3. Oracle Data Guard をプライマリデータベースとスタンバイデータベースの両方で有効にします。

   次の手順は、各クラスタ (cluster-paris および cluster-newyork) 内の 1 つのノードでのみ実行する必要があります。

   oracle (phys-newyork-1)$ sqlplus '/ as sysdba' SQL> alter system set dg_broker_start=true scope=both sid='*'; SQL> quit oracle (phys-paris-1)$ sqlplus '/ as sysdba' SQL> alter system set dg_broker_start=true scope=both sid='*'; SQL> quit

Oracle Data Guard Broker 構成を作成し、有効にする方法

Oracle Data Guard を Sun Cluster Geographic Edition で使用するには、Oracle Data Guard Broker 構成を作成する必要があります。

次の手順では、Oracle Data Guard Broker 構成は mysales.com という名前です。 salesdr データベースは、sales データベースの physical コピーです。

1. プライマリデータベースの Oracle Data Guard Broker 構成を作成します。

   dgmgrl コマンドを使用して、Oracle Data Guard Broker 構成を作成します。作成する Oracle Data Guard Broker 構成の名前、プライマリデータベースの名前、および接続で使用するネットサービスの名前が必要です。 この構成を Sun Cluster Geographic Edition に指定するときに、これらのプロパティーが必要になります。

   oracle (phys-paris-1)$ dgmgrl sys/sysdba_password@sales-svc DGMGRL> create configuration mysales.com as primary DGMGRL> database is sales connect identifier is sales-svc;

   Oracle Data Guard Broker に接続するときにエラーが見つかった場合は、${ORACLE_HOME}/admin/sales/bdump/alert_ prim_sid.log ファイルを確認します。 この構成が作成済みかどうかは、次のコマンドを使用して確認できます。

   oracle (phys-paris-1)$ dgmgrl sys/sysdba_password@sales-svc DGMGRL> show configuration; Configuration Name: mysales.com Enabled: NO Protection Mode: MaxPerformance Fast-Start Failover: DISABLED Databases: sales - Primary database Current status for "mysales.com": DISABLED

2. Oracle Data Guard Broker 構成にスタンバイデータベースを追加します。

   スタンバイデータベースの名前、接続で使用するネットサービスの名前、およびスタンバイのタイプ (physical または logical) が必要です。

   oracle (phys-paris-1)$ dgmgrl sys/sysdba_password@sales-svc DGMGRL> add database salesdr as connect identifier is salesdr-svc maintained as physical;

3. スタンバイデータベースの Apply インスタンスを構成します。

   スタンバイデータベースが複数インスタンスの Oracle RAC データベースでもある場合、送信されたアーカイブ REDO ログを適用したいインスタンスを指定できます。 構成を有効にする前に、次のコマンドを実行します。

   oracle$ dgmgrl sys/sysdba_password@sales-svc DGMGRL> edit database salesdr set property PreferredApplyInstance='salesdr1';

4. Oracle Data Guard Broker 構成が正しく動作していることを確認するには、構成を有効にします。

   oracle (phys-paris-1)$ dgmgrl sys/sysdba_password@sales-svc DGMGRL> enable configuration;

   すべての手順を正常に実行した場合は、次のコマンドを使用して構成の状態を確認できます。

   oracle$ dgmgrl sys/sysdba_password@sales-svc DGMGRL> show configuration; Configuration Name: mysales.com Enabled: YES Protection Mode: MaxPerformance Fast-Start Failover: DISABLED Databases: sales - Primary database salesdr - フィジカルスタンバイ database Current status for "mysales.com": SUCCESS

5. Oracle Data Guard Broker 構成がスイッチオーバーできることを確認します。

   Oracle Data Guard Broker 構成を Sun Cluster Geographic Edition に追加する前に、プライマリデータベースからスタンバイデータベースへのスイッチオーバーを実行できることと、元に戻せることを確認する必要があります。 スイッチオーバーを実行できない場合は、Sun Cluster Geographic Edition ではこの操作も実行できません。

   oracle (phys-paris-1)$ dgmgrl sys/sysdba_password@sales-svcDGMGRL> switchover to salesdr Performing switchover NOW, please wait... Operation requires shutdown of instance "sales1" on database "sales" Shutting down instance "sales1"... ORA-01109: database not open Database dismounted. ORACLE instance shut down. Operation requires shutdown of instance "salesdr1" on database "salesdr" Shutting down instance "salesdr1"... ORA-01109: database not open Database dismounted. ORACLE instance shut down. Operation requires startup of instance "sales1" on database "sales" Starting instance "sales1"... ORACLE instance started. Database mounted. Operation requires startup of instance "salesdr1" on database "salesdr" Starting instance "salesdr1"... ORACLE instance started. Database mounted. Switchover succeeded, new primary is "salesdr" DGMGRL switchover to sales; Performing switchover NOW, please wait... Operation requires shutdown of instance "salesdr1" on database "salesdr" Shutting down instance "salesdr1"... ORA-01109: database not open Database dismounted. ORACLE instance shut down. Operation requires shutdown of instance "sales1" on database "sales" Shutting down instance "sales1"... ORA-01109: database not open Database dismounted. ORACLE instance shut down. Operation requires startup of instance "salesdr1" on database "salesdr" Starting instance "salesdr1"... ORACLE instance started. Database mounted. Operation requires startup of instance "sales1" on database "sales" Starting instance "sales1"... ORACLE instance started. Database mounted. Switchover succeeded, new primary is "sales"