MAA / Data Guard 10gセットアップ・ガイド – RACプライマリに対するRACフィジカル・スタンバイの作成

(1)

MAA / Data Guard 10g セットアップ・ガ

イド - RAC プライマリに対する RAC

フィジカル・スタンバイの作成

Oracle の最大可用性アーキテクチャのホワイト・ペーパー

2006 年 5 月

Maximum

Availability

Architecture

(2)

MAA / Data Guard 10g セットアップ・ガイド -

RAC プライマリに対する RAC フィジカル・

スタンバイの作成

概要 ... 3

タスク 1: ファイルの収集とバックアップの実行... 4

タスク 2: スタンバイにおけるOracle Netの構成 ... 5

タスク 3: スタンバイ・インスタンスおよびデータベースの作成... 5

タスク 4: Data Guardに対するプライマリ・データベースの構成 ... 10

タスク 5: Data Guard構成の確認... 11

参照資料 ... 12

(3)

MAA / Data Guard 10g セットアップ・ガイド -

RAC プライマリに対する RAC フィジカル・

スタンバイの作成

概要

Oracle Maximum Availability Architecture (MAA) [1]は、オラクルの実証済高可用性テクノロジおよび推奨事項に基づいたオラクルのベストプラクティス計画です。 MAAの目的は、可用性の高い最適なアーキテクチャを簡単に設計することです。このホワイト・ペーパーは、MAA シリーズのホワイト・ペーパーの一部として発行され、RAC プライマリ・データベースに対する RAC フィジカル・スタンバイ・データベースの作成に焦点をあてています。このドキュメントでは、すでに RAC データベースが存在し、構成にスタンバイ・データベースを追加することで Data Guard を実装するものとします。最終的には、RAC スタンバイ・データベースを備えた RAC プライマリ・データベースを構成します。このドキュメントで概説す る手順では、SQL*Plus を使用し、Oracle Database 10g Release 1 と Oracle Database 10g Release 2 の両方に適用します。また、これらの 2 つのデータベースでは ASM/OMF を使用しており、スタンバイ・ホスト上にソフトウェアおよび ASM インスタンスがすでにインストール/作成済であることを前提とします。

このドキュメントで使用する例では、CHICAGO という一意の名前の RAC データベースがあります。2 つの RAC インスタンスのインスタンス名は、CHICAGO1 （ノード chicago_host1）と CHICAGO2（ノード chicago_host2）です。RAC スタン

バイ・データベースは BOSTON という一意の名前で、2 つのスタンバイ・インスタンス名は BOSTON1（ノード boston_host1）と BOSTON2（ノード boston_host2）です。このドキュメントでは、次のタスクを説明します。 • タスク 1: ファイルの収集とバックアップの実行 • タスク 2: スタンバイにおける Oracle Net の構成 • タスク 3: スタンバイ・インスタンスおよびデータベースの作成 • タスク 4: Data Guard に対するプライマリ・データベースの構成 • タスク 5: Data Guard 構成の確認このホワイト・ペーパーでは、次の条件が満たされているものとします。 • プライマリ RAC データベースがアーカイブ・モードである • プライマリ RAC データベースで ASM を使用している • スタンバイ RAC クラスタで ASM インスタンスが作成済である

(4)

• プライマリおよびスタンバイ・データベースでフラッシュ・リカバリ・エリアを使用している

• スタンバイ RAC ホストに既存の Oracle ソフトウェア・インストレーションがある

• すべてのストレージで Oracle Managed Files（OMF）を使用している

タスク 1: ファイルの収集とバックアップの実行

1. プライマリ・ノードでステージング・ディレクトリを作成します。例: [oracle@chicago_host1 oracle]$ mkdir -p /opt/oracle/stage

2. スタンバイ・ホストの一方で次のパスと同じパスを作成します。

[oracle@boston_host1 oracle]$ mkdir -p /opt/oracle/stage

3. プライマリ・ノードでプライマリ・データベースに接続し、ステージング・ディレクトリの SPFILE から PFILE を作成します。例:

SQL> CREATE PFILE='/opt/oracle/stage/initCHICAGO.ora' FROM SPFILE;

4. プライマリ・ノードで、プライマリ・データベースの RMAN バックアップを実行します。これにより、バックアップ・ピースがステージング・ディレクトリへ配置されます。例:

[oracle@chicago_host1 stage]$ rman target /

RMAN> BACKUP DEVICE TYPE DISK FORMAT '/opt/oracle/stage/%U' DATABASE PLUS ARCHIVELOG;

RMAN> BACKUP DEVICE TYPE DISK FORMAT '/opt/oracle/stage/%U' CURRENT CONTROLFILE FOR STANDBY;

5. listener.ora、tnsnames.ora および sqlnet.ora ファイルのコピーをステージング・ディレクトリへ配置します。例: [oracle@chicago_host1 oracle]$ cp $ORACLE_HOME/network/admin/*.ora /opt/oracle/stage 6. RAC プライマリ・ノードのステージング・ディレクトリの内容を、手順 2 でステージング・ディレクトリを作成したスタンバイ・ノードにコピーします。例:

[oracle@chicago_host1 oracle]$ scp /opt/oracle/stage/* \ oracle@boston_host1:/opt/oracle/stage

(5)

タスク 2: スタンバイにおける Oracle Net の構成

1. listener.ora、tnsnames.ora および sqlnet.ora ファイルを、スタンバイ・ホストのステージング・ディレクトリから、すべてのスタンバイ・ホストの $ORACLE_HOME/network/admin ディレクトリへコピーします。 2. listener.ora ファイルの各スタンバイ・ホストを修正して、ホストの VIP アドレスを含めます。 3. プライマリ RAC ノードやスタンバイ RAC ノードなど、各ノードの tnsnames.ora ファイルを修正して、プライマリとスタンバイのすべてのネット・サービス名を含めます。また、local_listener および remote_listener パラメータで使用している Oracle Net のエイリアスを修正して、各スタンバイ・ホストのリスナーを指すようにすることが必要です。この例では、各 tnsnames.ora ファイルに、次の表のネット・サービス名をすべて含めます。 tnsnames.ora ファイルのエントリ例 プライマリ・ネット・サービス名 スタンバイ・ネット・サービス名 CHICAGO = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = chicago_host1vip) (HOST = chicago_host2vip) (PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = CHICAGO) ) ) BOSTON = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = boston_host1vip) (HOST = boston_host2vip) (PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = BOSTON) ) ) 4. すべてのスタンバイ・ホスト上でスタンバイ・リスナーを開始します。

タスク 3: スタンバイ・インスタンスおよびデータベースの作成

1. REDO データを安全に送信するために、プライマリおよびスタンバイ・データベースでパスワード・ファイルを使用していること、および SYS ユーザーのパスワードがすべてのシステムで一致していることを確認してください。例: $ cd $ORACLE_HOME/dbs

$ orapwd file=orapwBOSTON password=oracle

パスワード・ファイルの名前と場所は、プラットフォームによって異なります。詳細は、『Oracle Database Administrator’s Guide』の「Creating and Maintaining a Password File」を参照してください。

2. すべてのスタンバイ・ホスト上のステージング・エリアから、プライマリ・データベース PFILE をすべてのスタンバイ・ホストの$ORACLE_HOME/dbs ディレクトリへコピーし、名前を変更します。例:

[oracle@boston_host1 stage]$ cp initCHICAGO1.ora $ORACLE_HOME/dbs/initBOSTON1.ora

(6)

3. プライマリ・ノードからコピーしたスタンバイの初期化パラメータ・ファイルを修正して、次の表に示すように Data Guard パラメータを含めます。初期化パラメータの修正 パラメータ カテゴリ 修正前 修正後 RAC パラメータ *.cluster_database=true *.db_unique_name=CHICAGO CHICAGO1.instance_name=CHICAGO1 CHICAGO2.instance_name=CHICAGO2 CHICAGO1.instance_number=1 CHICAGO2.instance_number=2 CHICAGO1.thread=1 CHICAGO2.thread=2 CHICAGO1.undo_tablespace=UNDOTBS1 CHICAGO2.undo_tablespace=UNDOTBS2 *.remote_listener=LISTENERS_CHICAGO CHICAGO1.LOCAL_LISTENER=LISTENER_CHICAGO_HO ST1 CHICAGO2.LOCAL_LISTENER=LISTENER_CHICAGO_HO ST2 *.cluster_database=true *.db_unique_name=BOSTON BOSTON1.instance_name=BOSTON1 BOSTON2.instance_name=BOSTON2 BOSTON1.instance_number=1 BOSTON2.instance_number=2 BOSTON1.thread=1 BOSTON2.thread=2 BOSTON1.undo_tablespace=UNDOTBS1 BOSTON2.undo_tablespace=UNDOTBS2 *.remote_listener=LISTENERS_BOSTON BOSTON1.LOCAL_LISTENER=LISTENER_BOSTON_HOST1 BOSTON2.LOCAL_LISTENER=LISTENER_BOSTON_HOST2 Data Guard パラメータ *.log_archive_config='dg_config= (BOSTON,CHICAGO)' *.log_archive_dest_2='service=CHICAGO valid_for=(online_logfiles,primary_role) db_unique_name=CHICAGO' *.db_file_name_convert='+DATA/CHICAGO/', '+DATA/BOSTON/','+RECOVERY/CHICAGO', '+RECOVERY/BOSTON' *.log_file_name_convert='+DATA/CHICAGO/', '+DATA/BOSTON/','+RECOVERY/CHICAGO', '+RECOVERY/BOSTON' *.standby_file_management=auto *.fal_server='CHICAGO' *.fal_client='BOSTON' *.service_names='BOSTON' その他の パラメータ *.background_dump_dest= /opt/oracle/admin/CHICAGO/bdump *.core_dump_dest= /opt/oracle/admin/CHICAGO/cdump *.user_dump_dest= /opt/oracle/admin/CHICAGO/udump *.audit_file_dest= /opt/oracle/admin/CHICAGO/adump *.db_recovery_dest=’+RECOVERY’ *.log_archive_dest_1 = 'LOCATION=+DATA/CHICAGO/' *.dispatchers=CHICAGOXDB *.background_dump_dest= /opt/oracle/admin/BOSTON/bdump *.core_dump_dest= /opt/oracle/admin/BOSTON/cdump *.user_dump_dest= /opt/oracle/admin/BOSTON/udump *.audit_file_dest= /opt/oracle/admin/BOSTON/adump *.db_recovery_dest=’+RECOVERY’ *.log_archive_dest_1= 'LOCATION=USE_DB_RECOVERY_FILE_DEST' *.dispatchers=BOSTONXDB

これらの初期化パラメータの詳細は、『Oracle Data Guard Concepts and Administration』の 13 章「Initialization Parameters」を参照してください。 初期化パラメータ・ファイルではなくSPFILEを使用している場合、SPFILEの管理については、『Oracle Database Administrator’s Guide』で「Managing Initialization Parameters Using a Server Parameter File」のセクションを参照してください。

(7)

4. スタンバイ・ホストの ASM インスタンスに接続し、スタンバイ・データベースの DB_UNIQUE_NAME と同じ名前のディレクトリを DATA ディスク・グループに作成します。例:

SQL> ALTER DISKGROUP data ADD DIRECTORY '+DATA/BOSTON';

5. スタンバイ・ホストのスタンバイ・データベースに、スタンバイを IDLE 状態で接続し、スタンバイ DATA ディスク・グループに SPFILE を作成します。 SQL> CREATE SPFILE='+DATA/BOSTON/spfileBOSTON.ora' FROM PFILE='?/dbs/initBOSTON.ora';

6. 各スタンバイ・ホストの$ORACLE_HOME/dbs ディレクトリで、SPFILE への ポインタを含む oracle_sid.ora という PFILE を作成します。例:

[oracle@boston_host1 oracle]$ cd $ORACLE_HOME/dbs [oracle@boston_host1 dbs]$ echo

"SPFILE='+DATA/BOSTON/spfileBOSTON.ora'" > initBOSTON1.ora

7. スタンバイの初期化パラメータ・ファイルを参照して、すべてのスタンバイ・ホスト上にダンプ・ディレクトリを作成します。例:

[oracle@boston_host1 oracle]$ mkdir -p $ORACLE_BASE/admin/BOSTON/bdump

[oracle@boston_host1 oracle]$ mkdir -p $ORACLE_BASE/admin/BOSTON/cdump

[oracle@boston_host1 oracle]$ mkdir -p $ORACLE_BASE/admin/BOSTON/udump

[oracle@boston_host1 oracle]$ mkdir -p $ORACLE_BASE/admin/BOSTON/adump 8. 各スタンバイ・ホストで、ORACLE_SID、ORACLE_HOME、PATH などの適切な環境変数を設定後、ステージングのディレクトリがあるスタンバイ・ホスト上で、コントロール・ファイルをマウントせずに、スタンバイ・データベース・インスタンスを開始します。 SQL> STARTUP NOMOUNT 9. スタンバイ・インスタンスを開始したスタンバイ・ホストから、プライマリ・データベースをスタンバイとして ASM ディスク・グループへ複製します。例: $ rman target sys/oracle@CHICAGO auxiliary /

RMAN> DUPLICATE TARGET DATABASE FOR STANDBY;

10. スタンバイ・データベースへ接続し、スタンバイ・ロールをサポートするためのスタンバイ REDO ログを作成します。スタンバイ REDO ログは、必ずプライマリ・データベースのオンライン・ログと同じサイズにします。推奨するスタンバイ REDO ログの数は次のとおりです。

(maximum # of logfiles +1) * maximum # of threads

この例では、各スレッドに対して 2 つのオンライン・ログ・ファイルを使用しています。このため、スタンバイ REDO ログの数は(2 + 1) * 2 = 6 であることが必要です。つまり、各スレッドに対して、もう 1 つスタンバイ REDO ログ・ファイルがあります。

(8)

SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 5 SIZE 10M,

GROUP 6 SIZE 10M, GROUP 7 SIZE 10M;

SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 GROUP 8 SIZE 10M, GROUP 9 SIZE 10M, GROUP 10 SIZE 10M; これらの文によって、各グループに対して 2 つのスタンバイ・ログ・メンバーが作成されます。各メンバーのサイズは 10MB です。1 つのメンバーは、初期化パラメータ DB_CREATE_FILE_DEST で指定されたディレクトリに作成され、他のメンバーは、初期化パラメータ DB_RECOVERY_FILE_DEST で指定されたディレクトリに作成されます。この例では、2 つのスレッドに 2 つの REDO ログ・グループがあると仮定しているため、次のグループは「グループ 5」になります。 V$LOG ビューに対し問合せを実行して、REDO ログのグループ番号と数を確認することができます。

SQL> SELECT * FROM V$LOG;

V$STANDBY_LOG ビューに対し問合せを実行して、前の文の結果を確認することができます。

SQL> SELECT * FROM V$STANDBY_LOG;

また、V$LOGFILE ビューに対し問合せを実行して、作成されたメンバーを表示することもできます。

SQL> SELECT * FROM V$LOGFILE;

詳細は、『Oracle Data Guard Concepts and Administration』の「Configure a Standby Redo Log」セクションを参照してください。

11. いずれか 1 つのスタンバイ・ホスト（指定した Redo Apply インスタンス）で、管理されたリカバリを開始し、スタンバイ・データベースでリアルタイムに適用します。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

12. いずれかのスタンバイ・クラスタで、Server Control（SRVCTL）ユーティリティ

を使用して、スタンバイ・データベースとデータベース・インスタンスを Oracle

Cluster Registry（OCR）に登録します。例: $ srvctl add database -d BOSTON –o /opt/oracle/product/10g_db_rac

$ srvctl add instance -d BOSTON -i BOSTON1 -n boston_host1 $ srvctl add instance -d BOSTON -i BOSTON2 -n boston_host2

これらのコマンドのオプションは、次のとおりです。

-d オプションは、データベースの一意の名前（DB_UNIQUE_NAME）を指定します。

(9)

-i オプションは、データベース・インスタンス名を指定します。

-n オプションは、インスタンスが実行されているノードを指定します。

-o オプションは、データベースの Oracle ホームを指定します。

ASM インスタンスを OCR に登録します。

$ srvctl add asm -n boston_host1 -i +ASM1 –o /opt/oracle/product/10g_db_rac –p

/opt/oracle/product/10g_db_rac/dbs/spfile+ASM1.ora

$ srvctl add asm -n boston_host2 -i +ASM2 -o /opt/oracle/product/10g_db_rac –p /opt/oracle/product/10g_db_rac/dbs/spfile+ASM2.ora これらのコマンドのオプションは、次のとおりです。 -i オプションは、ASM のインスタンス名を指定します。ASM インスタンスが+ASM1 という名前の場合、'+'を含めて指定します。crs_stat の出力では、リソース名に‘+’は含まれません。ただし、SRVCTL コマンドで ASM インスタンス名を指定する場合には、'+'を指定する必要があります。 -n オプションは、ASM インスタンスを実行しているノードの名前を指定します。 -o オプションは、ASM インスタンスの Oracle ホームを指定します。 -p オプションは、ASM インスタンスが SPFILE を使用している場合、 SPFILE の完全修飾ファイル名を指定します。$ORACLE_HOME/dbs ディレクトリの PFILE を使用している場合には、このオプションは必要ありません。次のコマンドは、データベース・インスタンスと ASM インスタンス間の依存関係を設定します。ASM インスタンス名の場合、ここでも ASM インスタンス名に‘+’を指定する必要があります。

$ srvctl modify instance –d BOSTON –i BOSTON1 –s +ASM1

$ srvctl modify instance –d BOSTON –i BOSTON2 –s +ASM2

$ srvctl enable asm -n boston_host1 -i +ASM1

$ srvctl enable asm -n boston_host2 -i +ASM2

これらのコマンドのオプションは、次のとおりです。

-d オプションは、データベースの一意の名前（DB_UNIQUE_NAME）を指定します。

-i オプションは、データベース・インスタンス名を指定します。

(10)

次のコマンドは、OCR のスタンドポイントから、-n オプションで指定したノードに定義された、すべての ASM インスタンスを開始します。ASM インスタンスがすでに実行されている場合、crs_stat の出力でステータスが OFFLINE から ONLINE に変わります。

$ srvctl start asm –n boston_host1

$ srvctl start asm –n boston_host2

同じノード上で複数の ASM インスタンスを実行中に特定の ASM インスタンスを開始する場合、次の例のように、-i オプションを使用して ASM インスタンス名を指定します。

$ srvctl start asm –n boston_host1 –i +ASM1

タスク 4: Data Guard に対するプライマリ・データベースの構成

1. プライマリ・データベースの初期化パラメータを構成して、プライマリ・ロールとスタンバイ・ロールの両方をサポートします。 *.log_archive_config='dg_config=(BOSTON,CHICAGO)' *.log_archive_dest_2='service=BOSTON valid_for=(online_logfiles,primary_role) db_unique_name=BOSTON' *.db_file_name_convert='+DATA/BOSTON/',’+DATA/CHICAGO/', ’+RECOVERY/BOSTON’,’+RECOVERY/CHICAGO’ *.log_file_name_convert='+DATA/BOSTON/',’+DATA/CHICAGO/', ’+RECOVERY/BOSTON’,’+RECOVERY/CHICAGO’ *.standby_file_management=auto *.fal_server='BOSTON' *.fal_client='CHICAGO' *.service_names=CHICAGO

これらの初期化パラメータの詳細は、『Oracle Data Guard Concepts and Administration』の 13 章「Initialization Parameters」を参照してください。 初期化パラメータ・ファイルではなくSPFILEを使用している場合、SPFILEの管理については、『Oracle Database Administrator’s Guide』の「Managing Initialization Parameters Using a Server Parameter File」セクションを参照してください。前述のパラメータはすべて、スタンバイ・ロール・パラメータ log_file_name_convert と db_file_name_convert を除き、動的に修正することができます。次にロールを変更したときにパラメータが有効になるよう、パラメータを“scope=spfile”に設定することをお薦めします。 2. プライマリ・データベース上で REDO ログを作成して、スタンバイ・ロールをサポートします。スタンバイ REDO ログは、必ずプライマリ・データベースのオンライン・ログと同じサイズにします。スタンバイ REDO ログの数は、各スレッドに対するオンライン REDO ログの数より 1 多くします。この例では、各スレッドに対して 2 つのオンライン REDO ログがあるため、各スレッ

(11)

SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 5 SIZE 10M,

GROUP 6 SIZE 10M, GROUP 7 SIZE 10M;

SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 GROUP 8 SIZE 10M, GROUP 9 SIZE 10M, GROUP 10 SIZE 10M; これらの文によって、各グループに対して 2 つのスタンバイ・ログ・メンバーが作成されます。各メンバーのサイズは 10MB です。1 つのメンバーは、初期化パラメータ DB_CREATE_FILE_DEST で指定されたディレクトリに作成され、他のメンバーは、初期化パラメータ DB_RECOVERY_FILE_DEST で指定されたディレクトリに作成されます。この例では、2 つのスレッドに 2 つの REDO ログ・グループがあると仮定しているため、次のグループは「グループ 5」になります。 V$LOG ビューに対し問合せを実行して、REDO ログのグループ番号と数を確認することができます。

SQL> SELECT * FROM V$LOG;

V$STANDBY_LOG ビューに対し問合せを実行して、前の文の結果を確認することができます。

SQL> SELECT * FROM V$STANDBY_LOG;

また、V$LOGFILE ビューに対し問合せを実行して、作成されたメンバーを表示することもできます。

SQL> SELECT * FROM V$LOGFILE;

詳細は、『Oracle Data Guard Concepts and Administration』の「Configure a Standby Redo Log」セクションを参照してください。

タスク 5: Data Guard 構成の確認

1. スタンバイ・データベースで V$ARCHIVED_LOG ビューに対し問合せを実行して、アーカイブされた REDO ログで既存のファイルを確認します。例: SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME

FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

2. プライマリ・データベースで次の SQL 文を発行してログ・スイッチを強制実行し、現行のオンライン REDO ログ・ファイル・グループをアーカイブします。

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

3. スタンバイ・データベースで V$ARCHIVED_LOG ビューに対し問合せを実行して、REDO データが受信されたこと、およびスタンバイ・データベース上でアーカイブされたことを確認します。

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

(12)

参照資料

1. OTNのOracle Maximum Availability ArchitectureのWebサイト（http://otn.oracle.co.jp/products/availability/htdocs/maa.html）

(13)

MAA / Data Guard 10g セットアップ・ガイド - RAC プライマリに対する RAC フィジカル・スタンバイの作成 2006 年 5 月著者: Mike Smith 寄稿者: Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問合せ窓口: 電話: +1.650.506.7000 ファックス: +1.650.506.7200 www.oracle.com Copyright © 2006, Oracle. 無断転載を禁ず。この文書はあくまで参考資料であり、掲載されている情報は予告なしに変更されることがあります。オラクル社は、本ドキュメントの無謬性を保証しません。また、本ドキュメントは、法律で明示的または暗黙的に記載されているかどうかに関係なく、商品性または特定の目的に対する適合性に関する暗黙の保証や条件を含む一切の保証または条件に制約されません。オラクル社は、本書の内容に関していかなる保証もいたしません。また、本書により、契約上の直接的および間接的義務も発生しません。本書は、事前の書面による承諾を得ることなく、電子的または物理的に、いかなる形式や方法によっても再生または伝送することはできません。

Oracle、JD Edwards、PeopleSoft は、Oracle Corporation および関連会社の登録商標です。他の製品名は、それぞれの所有者の商標です。