MAA/Data Guard 10g Release 2セットアップ・ガイド – RACプライマリのためのRACロジカル・スタンバイ作成

(1)

アップ・ガイド - RAC プライマリのた

めの RAC ロジカル・スタンバイ作成

Oracle Maximum Availability Architecture ホワイト・ペーパー

2006 年 5 月

Maximum

Availability

Architecture

(2)

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

ガイド - RAC プライマリのための

RAC ロジカル・スタンバイ作成

概要 ... 3

タスク 1: フィジカル・スタンバイ環境を準備... 4

タスク 2: フィジカル・スタンバイをロジカル・スタンバイに変換 ... 6

タスク 3: Data Guard構成を確認... 8

参照資料 ... 8

(3)

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

ガイド - RAC プライマリのための

RAC ロジカル・スタンバイ作成

概要

Oracle Maximum Availability Architecture (MAA)[1]は、オラクル社の実証済み高可用性テクノロジと推奨事項に基づいたOracleベスト・プラクティスの青写真です。 MAAの目的は、最適な高可用性アーキテクチャを設計する場合の複雑な仕組みを排除することです。

MAAシリーズの一部として公開されたこのホワイト・ペーパーでは、特にRACプライマリ・データベースのためのRACロジカル・スタンバイ・データベースの作成方法を説明します。このホワイト・ペーパーでは、既存のOracle Data Guard構成をRACロジカル・スタンバイ・データベースを持つRACプライマリ・データベースに変換します。既存のOracle Data Guard構成は、RACフィジカル・スタンバイ・データベースで構成されたRACプライマリ・データベースとします。RACフィジカル・スタンバイ・データベースで初期RACプライマリ・データベースを作成する手順は、ホワイト・ペーパー『MAA 10g Setup Guide: Creating a RAC Physical StandbyDatabase for a RAC Primary Database [2]』に説明されています。このホワイト・ペーパーで概説する手順は、SQL*Plusとsrvctlを使用し、Oracle Data Guardで 構成したOracle Database 10g Release 2 データベースに適用します。プライマリ・ データベースを停止する必要はありません。

このホワイト・ペーパーの例では、RAC プライマリ・データベースのデータベース固有名は CHICAGO です。2 つの RAC プライマリ・インスタンスのインスタンス名は、CHICAGO1（ノード chicago_host1 上）と CHICAGO2（ノード chicago_host2 上）です。RAC スタンバイ・データベースのデータベース固有名は BOSTON、2 つのスタンバイ・インスタンス名は、BOSTON1（ノード boston_host1 上）と BOSTON2（ノード boston_host2 上）です。このホワイト・ペーパーには、次のタスクが含まれます。 • タスク 1: フィジカル・スタンバイ環境を準備 • タスク 2: フィジカル・スタンバイをロジカル・スタンバイに変換

(4)

• プライマリ・データベースとスタンバイ・データベースはフラッシュ・リカバリ領域を使用します。 • 特に記述がないかぎり、すべてのストレージに対して Oracle Managed Files（OMF）を使用します。

タスク 1: フィジカル・スタンバイ環境を準備

1. Data Guard 構成が高い保護モードで稼働している場合、保護モードを Maximum Performance に変更して、スタンバイ・データベースの停止がプライマリ・データベースの運用に影響しないようにします。例として、プライマリ・データベースで次の操作を実行します。

SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;

2. フィジカル・スタンバイ・データベースでの REDO 適用を停止します。例として、スタンバイ・データベースで次の操作を実行します。 SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 3. プライマリ・データベースで、ロジカル・スタンバイ・ディクショナリを作成し、プライマリ・データベース上のカレント・ログを数回アーカイブして、ログ・ファイルがディクショナリとともにスタンバイに送ります。 SQL> EXECUTE DBMS_LOGSTDBY.BUILD; SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

4. Enterprise Manager Grid Control と Data Guard Broker を使用している場合、プライマリ・データベースとスタンバイ・データベースの両方で次のコマンドを発行することにより、ブローカをオフにします。

SQL> ALTER SYSTEM SET DG_BROKER_START=FALSE SCOPE=BOTH;

ブローカをオフにした状態で、各データベースの Data Guard 構成ファイルを削除します（これらのファイルの位置は、データベース初期化パラメータ DG_BROKER_CONFIG_FILE1 および DG_BROKER_CONFIG_FILE2 により指定されています）。次に、Grid Control が監視するデータベース・ターゲットのリストからプライマリ・データベースとスタンバイ・データベースを削除します。

(5)

5. Oracle Database 10g の場合、フラッシュ・リカバリ領域は、ロジカル・スタンバイ・データベースのスタンバイ・アーカイブ・ログ宛先としてサポートされていません。ただし、スタンバイ・アーカイブ・ログ宛先のためにフラッシュ・リカバリ領域のディスク・グループ内にディレクトリを作成できます。スタンバイ・ホスト上の ASM インスタンスに接続し、データ・ディスク・グループまたはフラッシュ・リカバリ領域ディスク・グループで、スタンバイ・アーカイブ・ログ・ファイルを保管するためのディレクトリを作成します。次に、例を示します。

SQL> ALTER DISKGROUP data ADD DIRECTORY ‘+RECO/BOSTON/ARC’;

その後、プライマリ・ホスト上の ASM インスタンスに接続し、同様のディレクトリを作成して、次回ロール移行時に、現在のプライマリ・データベースがロジカル・スタンバイとして機能するようにします。

SQL> ALTER DISKGROUP data ADD DIRECTORY ‘+RECO/CHICAGO/ARC’;

6. ロジカル・スタンバイ構成に適するように、各データベースでパラメータを構成します。Data Guard Broker がすでに有効化されている場合、 LOG_ARCHIVE_DEST_10 がブローカにより自動的に定義され、フラッシュ・リカバリ領域が指定されます。この後の SQL コマンドは、この宛先の設定を解除し、ロジカル・スタンバイ構成として適切な宛先を定義します。

スタンバイ・データベースでは次の文を実行します。

SQL> ALTER SYSTEM SET STANDBY_ARCHIVE_DEST='+RECO/BOSTON/ARC/’ 2 SCOPE=BOTH SID='*';

SQL> ALTER SYSTEM SET

2 LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST 3 VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)

4 DB_UNIQUE_NAME=BOSTON' SCOPE=BOTH;

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_1=ENABLE

2 SCOPE=BOTH;

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=CHICAGO 2 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) LGWR SYNC AFFIRM 3 DB_UNIQUE_NAME=CHICAGO' SCOPE=BOTH;

2 SCOPE=BOTH;

2 LOG_ARCHIVE_DEST_3='LOCATION=+RECO/BOSTON/ARC/ 3 VALID_FOR=(STANDBY_LOGFILES, STANDBY_ROLE) 4 DB_UNIQUE_NAME=BOSTON' SCOPE=BOTH;

(6)

プライマリ・データベースでは次の文を実行します。

SQL> ALTER SYSTEM SET STANDBY_ARCHIVE_DEST=’+RECO/CHICAGO/ARC/’ 2 SCOPE=BOTH SID='*';

2 LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST 3 VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)

4 DB_UNIQUE_NAME=CHICAGO' SCOPE=BOTH;

2 SCOPE=BOTH;

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=BOSTON 2 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) LGWR SYNC AFFIRM 3 DB_UNIQUE_NAME=BOSTON' SCOPE=BOTH;

2 SCOPE=BOTH;

2 LOG_ARCHIVE_DEST_3='LOCATION=+RECO/CHICAGO/ARC/ 3 VALID_FOR=(STANDBY_LOGFILES, STANDBY_ROLE) 4 DB_UNIQUE_NAME=CHICAGO' SCOPE=BOTH;

2 SCOPE=BOTH;

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_10='' SCOPE=BOTH; SQL> ALTER SYSTEM SET PARALLEL_MAX_SERVERS=9 SCOPE=BOTH;

タスク 2: フィジカル・スタンバイをロジカル・スタンバイに変

換

1. 1 組のクラスタ・データベースを除くすべてのスタンバイ・インスタンスを停止し、false にしてから、マウント排他モードで単一インスタンスとしてスタンバイ・データベースを開始します。

SQL> ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=SPFILE;

SQL> SHUTDOWN ABORT;

SQL> STARTUP MOUNT EXCLUSIVE;

2. SQL*Plus から、ALTER DATABASE RECOVER TO LOGICAL STANDBY コマンドを発行します。次に、例を示します。

SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY boston;

3. クラスタ・データベースを true に設定し、データベースをマウント状態にします。マウント状態から open resetlogs を実行します。

SQL> ALTER SYSTEM SET CLUSTER_DATABASE=TRUE SCOPE=SPFILE SQL> STARTUP MOUNT FORCE;

SQL> ALTER DATABASE OPEN RESETLOGS;

(7)

6. プライマリ・データベースで、カレント・ログをアーカイブし、新しいロジカル・スタンバイへの REDO の送信を開始します。

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

7. Enterprise Manager Grid Control と Data Guard Broker を使用して構成を管理する場合、Enterprise Manager Grid Control を使用して次の手順を実行します。

a. Targets Databases ページから、プライマリ・データベースとスタンバ

イ・データベースのターゲットを手動で検出し構成したうえで、再追加します。

b. Setup ページから、新しいターゲットに対して Management Pack Access を有効化します。

c. Preferred Credentials ページから、新しいターゲットに対して優先接続情報を設定します。

d. プライマリ・データベース・ページから、Data Guard Setup and Manage ページに移動し、Add Standby Database ウィザードを呼び出します。既存スタンバイ・データベースを追加するオプションを使用します（ロジカル・スタンバイを初めて構成に追加する際、警告 ORA-16825、 ORA-16824、ORA-16821 または ORA-16810 が発行される場合があります）。ロジカル・スタンバイ・データベース・ディクショナリがロードを終了し、初期エラーがすべてクリアされるまで待ちます（数分）。 EM GC を使用し、ログ適用サービスを監視します。必要に応じ適用サービスを再起動して、エラーをクリアします。 e. DGMGRL コマンドライン・インタフェースを使用して、 locallisteneraddress パラメータが各データベース・インスタンスについて正しく検出されていることを確認します。次に、例を示します。 DGMGRL> show instance boston1 locallisteneraddress

LocalListenerAddress =

'(ADDRESS=(PROTOCOL=TCP)(HOST=boston2_host- vip)(PORT=1521))'

DGMGRL> edit instance boston1 set property locallisteneraddress= '(ADDRESS=(PROTOCOL=TCP)(HOST=boston1_host- vip)(PORT=1521))'

(8)

タスク 3: Data Guard 構成を確認

1. SQL*Plus を使用して Data Guard 構成を管理している場合、『Data Guard 概要および管理』マニュアルの 4.2.6 項を参照して、ロジカル・スタンバイ・データベースが正しく構成されているか確認してください。通常、プライマリ・データベースに対して行った変更が受理され、スタンバイ・データベースで適用されたことを確認します。

2. Enterprise Manager Grid Control と Oracle Data Guard Broker を使用している場合、Data Guard のプライマリ・データベース・ページに移動し、「Verify」をクリックします。検出された問題を修正します。推奨されたスタンバイ REDO ログ・ファイルをすべてデータベースに追加後、ORA-16826 エラーとなった場合、EM GC を使用してログ適用サービスをリセットすることでエラーをクリアし、リアルタイム適用を有効化します。GUI により表示されるステータス情報は、実際の構成ステータスより数分遅れる場合があります。 3. ロジカル・スタンバイが健全であり、ログが正しく受理され適用されたら、スタンバイ REDO ログを追加し、保護モードを変更し、ファスト・スタート・フェイルオーバーを有効にするなどして、新しいロジカル・スタンバイ構成を本番で使用できるように準備します。

参照資料

1. OTN上のOracle Maximum Availability ArchitectureのWebsite

http://otn.oracle.co.jp/products/availability/htdocs/maa.html

2. 以下は英語のドキュメントです。

http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10g_RACPri maryRACPhysicalStandby.pdf

(9)

MAA/Data Guard 10g Release 2 セットアップ・ガイド – RAC プライマリのための RAC ロジカル・スタンバイ作成 2006 年 5 月

著者: Laurence Clarke, Michael T. 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. 無断転載を禁ず。この文書はあくまで参考資料であり、掲載されている情報は予告なしに変更されることがあります。