Oracle Data Guard 概要および管理 11gリリース1(11.1) E05755-03 |
|
この章では、ロジカル・スタンバイ・データベースを作成する手順について説明します。この章は、次の主な項目で構成されています。
ロジカル・スタンバイ・データベースを作成する前に、プライマリ・データベースが正しく構成されていることを最初に確認する必要があります。表4-1は、ロジカル・スタンバイ・データベースを作成するための準備としてプライマリ・データベースで実行するタスクのチェックリストです。
参照先 | タスク |
---|---|
ロジカル・スタンバイ・データベースでは、スタンバイREDOログ(SRL)をプライマリ・データベースから受信したREDOに使用しますが、スタンバイ・データベースに変更を適用するため、オンラインREDOログ(ORL)にも書き込みます。そのため、ロジカル・スタンバイ・データベースには、SRLおよびORLを同時にアーカイブするために追加のARC
nプロセスが必要になることがあります。さらに、ORLのアーカイブはSRLのアーカイブに優先するため、ワークロードが非常に高いときは、ロジカル・スタンバイにより多くのSRLが必要になる可能性があります。
ロジカル・スタンバイ・データベースを設定する前に、ロジカル・スタンバイ・データベースが、プライマリ・データベースのデータ型と表を保持できることを確認する必要があります。データ型および記憶域タイプに関する考慮事項の詳細リストは、付録Cを参照してください。
ロジカル・スタンバイ・データベースがプライマリ・データベースのバックアップ・コピーから作成されていても、ロジカル・スタンバイ・データベースの物理的な構成は、プライマリ・データベースの構成とは異なります。そのため、プライマリ・データベースによって生成されたREDOレコードに含まれているROWIDは、ロジカル・スタンバイ・データベース内の対応する行を識別するためには使用できません。
Oracleでは、ロジカル・スタンバイ・データベース内の変更された行を論理的に識別するために、主キーまたは一意制約/索引サプリメンタル・ロギングを使用します。また、データベース全体の主キーおよび一意制約/索引サプリメンタル・ロギングが使用可能になると、各UPDATE
文により、ロジカル・スタンバイ・データベース内の変更された行を一意に識別するために、REDOログに必要な列の値が書き込まれます。
UPDATE
文の一部として変更された列とともにログに記録されます。
UPDATE
文の一部として変更された列とともにログに記録されます。
UPDATE
文の一部としてログに記録されます。つまり、LONG
、LOB
、LONG RAW
、オブジェクト型およびコレクション以外のすべての列が、ログに記録されます。
SQL Applyで、REDOデータの更新をロジカル・スタンバイ・データベースに効率的に適用できるように、適切で可能な場合には、必ずプライマリ・データベースの表に主キーまたはNULL値が許容されていない一意索引を追加することをお薦めします。
ロジカル・スタンバイ・データベース内のレプリケートされている各表の行をSQL Applyによって一意に識別できるかどうかを確認するには、次の手順を実行します。
SQL Applyで一意に識別できない可能性がある表のリストを表示するには、DBA_LOGSTDBY_NOT_UNIQUE
ビューを問い合せます。次に例を示します。
SQL> SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_NOT_UNIQUE 2> WHERE (OWNER, TABLE_NAME) NOT IN 3> (SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED) 4> AND BAD_COLUMN = 'Y'
アプリケーションで、表内の行が一意であることが保証される場合は、表に無効化されたRELY
主キー制約を作成できます。これによって、プライマリ・データベースでの主キーのメンテナンスに関するオーバーヘッドを回避できます。
無効化されたRELY
制約をプライマリ・データベース表に作成するには、RELY DISABLE
句を指定してALTER TABLE
文を使用します。次の例では、無効化されたRELY
制約がmytab
という表に作成されます。各行は、id
列とname
列を使用して一意に識別されます。
SQL> ALTER TABLE mytab ADD PRIMARY KEY (id, name) RELY DISABLE;
RELY
制約を指定すると、システムでは行が一意であると仮定されます。システムには情報に依存するように指示を出しますが、表が変更されるたびに検証は行わないため、表内の各行を一意に識別するRELY
制約が無効化されている場合は、十分に注意して列を選択する必要があります。このような一意性が存在しない場合、SQL Applyによる表のメンテナンスが正しく行われません。
SQL Applyのパフォーマンスを改善するには、ロジカル・スタンバイ・データベースで行を識別するために一意制約/索引を列に追加します。追加できない場合は、SQL Applyによって表上でUPDATE
またはDELETE
文を実行中に、全表スキャンが実行されます。
関連項目
|
この項では、ロジカル・スタンバイ・データベースの作成で実行するタスクについて説明します。
表4-2は、ロジカル・スタンバイ・データベースの作成で実行するタスクのチェックリストで、各タスクを実行するデータベースを指定します。各タスクを詳細に説明している参照先の項も記載されています。
参照先 | タスク | データベース |
---|---|---|
プライマリ |
||
スタンバイ |
||
プライマリ |
||
スタンバイ |
||
スタンバイ |
||
スタンバイ |
ロジカル・スタンバイ・データベースを作成するには、次のように最初にフィジカル・スタンバイ・データベースを作成してから、ロジカル・スタンバイ・データベースへと推移させます。第3章「フィジカル・スタンバイ・データベースの作成」の指示に従ってフィジカル・スタンバイ・データベースを作成します。
ロジカル・スタンバイ・データベースに変換する前に、実行時間に関係なく、新規フィジカル・スタンバイ・データベースでREDO Applyを実行できます。ただし、ロジカル・スタンバイ・データベースに変換する前に、フィジカル・スタンバイ・データベースでREDO Applyを停止する必要があります。REDO Applyの停止は、LogMinerディクショナリを含むREDOの後に変更が適用されることを避けるために必要です(4.2.3.2項「REDOデータでのディクショナリの構築」を参照)。
REDO Applyを停止するには、フィジカル・スタンバイ・データベースで次の文を発行します。データベースが複数のインスタンスから構成されるOracle RACデータベースの場合、この文を発行する前に、1つを残してすべてのOracle RACインスタンスを停止する必要があります。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
この項は、次の項目で構成されています。
3.1.4項「プライマリ・データベースの初期化パラメータの設定」では、プライマリ・データベースがフィジカル・スタンバイ・ロールに推移する場合に有効になるように、複数のスタンバイ・ロールの初期化パラメータを設定しました。
プライマリ・データベースをロジカル・スタンバイ・ロールに推移させる場合は、ロールの推移後にパラメータを変更しなくてもよいように、例4-1に太字で示すパラメータを変更する必要もあります。
LOG_ARCHIVE_DEST_1
宛先のVALID_FOR
属性を、スタンバイREDOログからではなく、オンラインREDOログからのみREDOデータをアーカイブするように変更します。
LOG_ARCHIVE_DEST_3
宛先をプライマリ・データベースに含めます。このパラメータは、プライマリ・データベースがロジカル・スタンバイ・ロールに推移したときにのみ有効になります。LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/chicago/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/chicago/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_STATE_3=ENABLE
これらの初期化パラメータを動的に設定するには、SQL ALTER SYSTEM SET
文を使用し、変更が即時に有効になってデータベースを停止して再起動した後も存続するようにSCOPE=BOTH
句を指定します。
次の表に、例4-1に示した変更後の初期化パラメータで定義されるアーカイブ・プロセスを示します。
LogMinerディクショナリは、SQL ApplyのLogMinerコンポーネントによってREDOでの変更が適切に解釈できるように、REDOデータに構築される必要があります。LogMinerディクショナリの構築の一部として、主キーおよび一意制約/索引列を記録するサプリメンタル・ロギングが自動的に設定されます。サプリメンタル・ロギング情報により、各更新に、文によって変更された各行を論理的に識別するための十分な情報が含まれていることが保証されます。
LogMinerディクショナリを構築するには、次の文を発行します。
SQL> EXECUTE DBMS_LOGSTDBY.BUILD;
DBMS_LOGSTDBY.BUILD
プロシージャでは、既存のトランザクションがすべて完了するのを待機します。プライマリ・データベースで長時間実行されているトランザクションは、このコマンドの適時性に影響を与えます。
この項では、ロジカル・スタンバイ・データベースに推移するために、フィジカル・スタンバイ・データベースを準備する方法について説明します。この章は、次の項目で構成されています。
REDOログには、フィジカル・スタンバイ・データベースをロジカル・スタンバイ・データベースに変換するために必要な情報が含まれています。
ロジカル・スタンバイ・データベースへの変換準備が完了するまでREDOデータをフィジカル・スタンバイ・データベースに適用し続けるには、次のSQL文を発行します。
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name;
db_nameには、新しいロジカル・スタンバイ・データベースを識別するデータベース名を指定します。この文の発行時にサーバー・パラメータ・ファイル(spfile)を使用している場合、データベースは、新しいロジカル・スタンバイ・データベースに関する適切な情報でこのファイルを更新します。spfileを使用していない場合は、データベースの停止後にDB_NAME
パラメータの名前を設定するよう求めるメッセージが発行されます。
この文では、ログ・ファイル内にLogMinerディクショナリが見つかるまで、REDOデータを適用しながら待機します。4.2.3.2項「REDOデータでのディクショナリの構築」で生成されたREDOがスタンバイ・データベースに推移されるのにかかる時間と、適用する必要のあるREDOデータの量にもよりますが、この作業には数分かかります。プライマリ・データベースでディクショナリ構築が正常に実行されるまで、このコマンドは完了しません。SQL文を取り消すには、別のSQLセッションからALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
文を発行します。
ロジカル・スタンバイ・データベースで、インスタンスを停止し、STARTUP MOUNT
文を発行してデータベースを起動およびマウントします。データベースをオープンしないでください。後続の作成プロセスまで、データベースはユーザー・アクセスに対してクローズの状態のままにしておく必要があります。次に例を示します。
SQL> SHUTDOWN; SQL> STARTUP MOUNT;
LOG_ARCHIVE_DEST_
n
パラメータを変更する必要があります。これは、フィジカル・スタンバイ・データベースとは異なり、ロジカル・スタンバイ・データベースはREDOデータを生成するオープン・データベースであり、複数のログ・ファイル(オンラインREDOログ・ファイル、アーカイブREDOログ・ファイルおよびスタンバイREDOログ・ファイル)があるためです。次のものに対し、別々のローカル宛先を指定することをお薦めします。
LOG_ARCHIVE_DEST_1=LOCATION=/arch1/boston
宛先として構成されています。
LOG_ARCHIVE_DEST_3=LOCATION=/arch2/boston
宛先として構成されています。
例4-2に、ロジカル・スタンバイ・データベース用に変更された初期化パラメータを示します。各パラメータは、ボストンのロジカル・スタンバイ・データベースがプライマリ・データベース・ロールまたはスタンバイ・データベース・ロールで実行されている場合に有効です。
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/boston/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_2= 'SERVICE=chicago ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/boston/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_STATE_3=ENABLE
次の表に、例4-2に示した初期化パラメータで定義されるアーカイブ・プロセスを示します。
新規ロジカル・スタンバイ・データベースをオープンするには、次の文を発行し、RESETLOGS
オプションを使用してオープンする必要があります。
SQL> ALTER DATABASE OPEN RESETLOGS;
データベースがオープンされるのはこれが初回であるため、データベースのグローバル名は、新しいDB_NAME
初期化パラメータと一致するように自動的に調整されます。
次の文を発行して、ロジカル・スタンバイ・データベースに対するREDOデータの適用を開始します。次に例を示します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
ロジカル・スタンバイ・データベースが適切に実行されていることを検証するには、次の項を参照してください。
この時点で、ロジカル・スタンバイ・データベースが実行中であり、最大パフォーマンス・レベルのデータ保護を提供できます。次のリストに、ロジカル・スタンバイ・データベースに対して実行できるその他の準備について説明します。
Data Guard構成は、最初は最大パフォーマンス・モード(デフォルト)で設定されます。
フラッシュバック・データベースにより、フェイルオーバー後のプライマリ・データベースの再作成の必要がなくなります。フラッシュバック・データベースでは、データファイルをバックアップからリストアしたりREDOデータを広範囲に適用する必要がないため、従来のPoint-in-Timeリカバリよりもはるかに高速でデータベースを過去の最新時点の状態に戻すことができます。フラッシュバック・データベースは、プライマリ・データベースまたはスタンバイ・データベース、あるいはその両方で有効化できます。Data Guard環境でのフラッシュバック・データベースの使用例は、13.2項「フラッシュバック・データベースを使用した障害が発生したプライマリのスタンバイ・データベースへの変換」、および13.3項「Open Resetlogs文の発行後のフラッシュバック・データベースの使用」を参照してください。また、フラッシュバック・データベースの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
|
![]() Copyright © 1999, 2008 Oracle Corporation. All Rights Reserved. |
|