この章ではロジカル・スタンバイ・データベースの作成手順を説明します。この章の内容は次のとおりです。
関連項目:
|
ロジカル・スタンバイ・データベースを作成する前に、プライマリ・データベースが正しく構成されていることを確認する必要があります。表4-1は、ロジカル・スタンバイ・データベースを作成するための準備としてプライマリ・データベースで実行するタスクのチェックリストです。
ロジカル・スタンバイ・データベースでは、スタンバイREDOログ(SRL)をプライマリ・データベースから受信したREDOに使用しますが、スタンバイ・データベースに変更を適用するため、オンラインREDOログ(ORL)にも書き込みます。そのため、ロジカル・スタンバイ・データベースには、SRLおよびORLを同時にアーカイブするために追加のARC
nプロセスが必要になることがあります。さらに、ORLのアーカイブはSRLのアーカイブに優先するため、ワークロードが非常に高いときは、ロジカル・スタンバイにより多くのSRLが必要になる可能性があります。
ロジカル・スタンバイ・データベースを設定する前に、ロジカル・スタンバイ・データベースが、プライマリ・データベースのデータ型と表を保持できることを確認する必要があります。データ型および記憶域タイプに関する考慮事項の詳細リストは、付録Cを参照してください。
ロジカル・スタンバイ・データベースがプライマリ・データベースのバックアップ・コピーから作成されていても、ロジカル・スタンバイ・データベースの物理的な構成は、プライマリ・データベースの構成とは異なります。そのため、プライマリ・データベースによって生成されたREDOレコードに含まれているROWIDは、ロジカル・スタンバイ・データベース内の対応する行を識別するためには使用できません。
Oracleでは、ロジカル・スタンバイ・データベース内の変更された行を論理的に識別するために、主キーまたは一意制約/索引サプリメンタル・ロギングを使用します。また、データベース全体の主キーおよび一意制約/索引サプリメンタル・ロギングが使用可能になると、各UPDATE
文により、ロジカル・スタンバイ・データベース内の変更された行を一意に識別するために、REDOログに必要な列の値が書き込まれます。
表に主キーが定義されている場合、その主キーが、変更された行を識別するためにUPDATE
文の一部として変更された列とともにログに記録されます。
主キーがない場合は、一番短く、NULL値が許容されていない一意制約/索引が、変更された行を識別するためにUPDATE
文の一部として変更された列とともにログに記録されます。
主キーもNULL値が許容されていない一意制約/索引もない場合、バインドされているサイズのすべての列が、変更された行を識別するために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
制約を作成するには、ALTER TABLE
文をRELY DISABLE
句と一緒に使用します。次の例では、無効化された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は、ロジカル・スタンバイ・データベースの作成で実行するタスクのチェックリストで、各タスクを実行するデータベースを指定します。各タスクを詳細に説明している参照先の項も記載されています。
表4-2 ロジカル・スタンバイ・データベースの作成
参照先 | タスク | データベース |
---|---|---|
|
|
プライマリ |
|
フィジカル・スタンバイ・データベースでのREDO Applyの停止 |
スタンバイ |
|
ロジカル・スタンバイ・データベースをサポートするためのプライマリ・データベースの準備 |
プライマリ |
|
|
スタンバイ |
|
|
スタンバイ |
|
ロジカル・スタンバイ・データベースが正しく実行されているかどうかの確認 |
スタンバイ |
ロジカル・スタンバイ・データベースを作成するには、次のように最初にフィジカル・スタンバイ・データベースを作成してから、ロジカル・スタンバイ・データベースへと推移させます。第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
宛先をプライマリ・データベースに含めます。このパラメータは、プライマリ・データベースがロジカル・スタンバイ・ロールに推移したときにのみ有効になります。
例4-1 プライマリ・データベース: ロジカル・スタンバイ・ロールの初期化パラメータ
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に示した変更後の初期化パラメータで定義されるアーカイブ・プロセスを示します。
シカゴのデータベースがプライマリ・ロールで稼働している場合 | シカゴのデータベースがロジカル・スタンバイ・ロールで稼働している場合 | |
---|---|---|
LOG_ARCHIVE_DEST_1 |
/arch1/chicago/ 内のローカル・アーカイブREDOログ・ファイルにローカル・オンラインREDOログ・ファイルからプライマリ・データベースによって生成されたREDOデータをアーカイブするよう指示。 |
/arch1/chicago/ 内のローカル・アーカイブREDOログ・ファイルにローカル・オンラインREDOログ・ファイルからロジカル・スタンバイ・データベースによって生成されたREDOデータをアーカイブするよう指示。 |
LOG_ARCHIVE_DEST_3 |
無視。LOG_ARCHIVE_DEST_3 は、chicago がスタンバイ・ロールで稼働している場合にのみ有効。 |
/arch2/chicago/ 内のローカル・アーカイブREDOログ・ファイルにスタンバイREDOログ・ファイルからのREDOデータをアーカイブするよう指示。 |
LogMinerディクショナリは、SQL ApplyのLogMinerコンポーネントによってREDOでの変更が適切に解釈できるように、REDOデータに構築される必要があります。LogMinerディクショナリの構築の一部として、主キーおよび一意制約/索引列を記録するサプリメンタル・ロギングが自動的に設定されます。サプリメンタル・ロギング情報により、各更新に、文によって変更された各行を論理的に識別するための十分な情報が含まれていることが保証されます。
LogMinerディクショナリを構築するには、次の文を発行します。
SQL> EXECUTE DBMS_LOGSTDBY.BUILD;
DBMS_LOGSTDBY.BUILD
プロシージャでは、既存のトランザクションがすべて完了するのを待機します。プライマリ・データベースで長時間実行されているトランザクションは、このコマンドの適時性に影響を与えます。
注意: Oracle Database 11gリリース2 (11.2)以降を使用して作成されたデータベースでは、サプリメンタル・ロギング情報はすべての既存のフィジカル・スタンバイ・データベースに自動的に伝播されます。ただし、それより前のリリースのデータベースの場合や、それより前のリリースを使用してデータベースを作成してから11.2にアップグレードした場合、サプリメンタル・ロギングがプライマリ・データベースで有効化されているときは、それがフィジカル・スタンバイでも有効化されているかどうかを確認する必要があります。それがフィジカル・スタンバイで有効化されていない場合、スイッチオーバーまたはフェイルオーバーを実行する前に、すべての既存のフィジカル・スタンバイ・データベースでサプリメンタル・ロギングを有効化する必要があります。これを行うには、各フィジカル・スタンバイで次のSQLコマンドを発行します。SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE INDEX) COLUMNS; これを行わないと、スイッチオーバーやフェイルオーバーがいずれかのフィジカル・スタンバイ・データベースに実行された場合に、同じData Guard構成に含まれるロジカル・スタンバイを使用できなくなります。スイッチオーバーやフェイルオーバーがすでに発生しており、サプリメンタル・ロギングが有効化されていない場合、すべてのロジカル・スタンバイ・データベースを再作成する必要があります。 |
関連項目:
|
この項では、ロジカル・スタンバイ・データベースに推移するために、フィジカル・スタンバイ・データベースを準備する方法について説明します。この付録には、次の項があります。
REDOログには、フィジカル・スタンバイ・データベースをロジカル・スタンバイ・データベースに変換するために必要な情報が含まれています。
注意: Oracle RACフィジカル・スタンバイ・データベースがある場合、1つのインスタンス以外はすべて停止して、CLUSTER_DATABASE をFALSE に設定し、次のようにしてスタンバイ・データベースをMOUNT EXCLUSIVE モードで単一インスタンスとして起動します。
SQL> ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=SPFILE; SQL> SHUTDOWN ABORT; SQL> STARTUP MOUNT EXCLUSIVE; |
ロジカル・スタンバイ・データベースへの変換準備が完了するまで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
文を発行します。
注意: Oracle Database 11g以前のリリースでは、ロジカル・スタンバイ・データベースをオープンする前に新しいパスワード・ファイルを作成する必要がありました。現在は、その必要はありません。ロジカル・スタンバイ・データベースに新しいパスワード・ファイルを作成すると、REDO転送サービスが正常に機能しなくなります。 |
注意: Oracle RACフィジカル・スタンバイ・データベースで開始した場合、次のようにCLUSTER_DATABASE の設定をTRUE に戻します。
SQL> ALTER SYSTEM SET CLUSTER_DATABASE=TRUE SCOPE=SPFILE; |
ロジカル・スタンバイ・データベース上でインスタンスをシャットダウンし、STARTUP MOUNT
文を発行してデータベースの起動とマウントを行います。データベースは開かないでください。作成手順の後半まで閉じておき、ユーザー・アクセスは行わないでください。次に例を示します。
SQL> SHUTDOWN; SQL> STARTUP MOUNT;
LOG_ARCHIVE_DEST_
n
パラメータを変更する必要があります。これは、フィジカル・スタンバイ・データベースとは異なり、ロジカル・スタンバイ・データベースはREDOデータを生成するオープン・データベースであり、複数のログ・ファイル(オンラインREDOログ・ファイル、アーカイブREDOログ・ファイルおよびスタンバイREDOログ・ファイル)があるためです。次のものに対しては、別なローカル宛先を指定することをお薦めします。
ロジカル・スタンバイ・データベースで生成されたREDOデータを格納するアーカイブREDOログ・ファイル。例4-2では、LOG_ARCHIVE_DEST_1=LOCATION=/arch1/boston
宛先として構成されています。
プライマリ・データベースから受信したREDOデータを格納するアーカイブREDOログ・ファイル。例4-2では、LOG_ARCHIVE_DEST_3=LOCATION=/arch2/boston
宛先として構成されています。
例4-2に、ロジカル・スタンバイ・データベース用に変更された初期化パラメータを示します。各パラメータは、ボストンのロジカル・スタンバイ・データベースがプライマリ・データベース・ロールまたはスタンバイ・データベース・ロールで実行されている場合に有効です。
例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
注意: データベースの互換性を11.1以降に設定した場合、高速リカバリ領域を使用してリモート・アーカイブ・ログを格納することができます。そのためには、次のパラメータを設定する必要があります(すでにDB_RECOVERY_FILE_DEST およびDB_RECOVERY_FILE_DEST_SIZE パラメータが設定されているとします)。
LOG_ARCHIVE_DEST_1= 'LOCATION=USE_DB_RECOVERY_FILE_DEST DB_UNIQUE_NAME=boston' 高速リカバリ領域を使用しているため、 |
次の表に、例4-2に示した初期化パラメータで定義されるアーカイブ・プロセスを示します。
ボストンのデータベースがプライマリ・ロールで稼働している場合 | ボストンのデータベースがロジカル・スタンバイ・ロールで稼働している場合 | |
---|---|---|
LOG_ARCHIVE_DEST_1 |
/arch1/boston/ 内のローカル・アーカイブREDOログ・ファイルにローカル・オンラインREDOログ・ファイルからプライマリ・データベースによって生成されたREDOデータをアーカイブするよう指示。 |
/arch1/boston/ 内のローカル・アーカイブREDOログ・ファイルにローカル・オンラインREDOログ・ファイルからロジカル・スタンバイ・データベースによって生成されたREDOデータをアーカイブするよう指示。 |
LOG_ARCHIVE_DEST_2 |
リモート・ロジカル・スタンバイ・データベースchicago にREDOデータを転送するよう指示。 |
無視。LOG_ARCHIVE_DEST_2 は、boston がプライマリ・ロールで稼働している場合にのみ有効。 |
LOG_ARCHIVE_DEST_3 |
無視。LOG_ARCHIVE_DEST_3 は、boston がスタンバイ・ロールで稼働している場合にのみ有効。 |
/arch2/boston/ 内のローカル・アーカイブREDOログ・ファイルにプライマリ・データベースから受信したREDOデータをアーカイブするよう指示。 |
注意: DB_FILE_NAME_CONVERT 初期化パラメータは、フィジカル・スタンバイ・データベースがロジカル・スタンバイ・データベースに変換された後は考慮されません。必要な場合は、スキップ・ハンドラを登録し、プライマリ・データベースのデータファイルのパス名をスタンバイ・データファイルのパス名に変換することで、実行対象のかわりとなるDDL文字列をSQL Applyに提供します。SKIP プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_LOGSTDBY パッケージを参照してください。 |
新規ロジカル・スタンバイ・データベースをオープンするには、次の文を発行し、RESETLOGS
オプションを使用してオープンする必要があります。
SQL> ALTER DATABASE OPEN RESETLOGS;
注意: Oracle RACフィジカル・スタンバイ・データベースで開始した場合、その他のすべてのスタンバイ・インスタンスをこの時点で開始できます。 |
注意: ロジカル・スタンバイ・データベースをプライマリ・データベースと同じコンピュータ・システム上に配置している場合、SQL Applyを初めて開始する前に次のSQL文を発行し、SQL Applyがプライマリ・データベースで実行されるファイル操作をスキップするようにする必要があります。この文の発行が必要な理由は、SQL Applyはプライマリ・データベースと同じディレクトリ構造にアクセスできるので、特定のファイル固有の操作を再実行しようとした場合に、プライマリ・データベースに属するデータファイルが破損する可能性があるためです。SQL> EXECUTE DBMS_LOGSTDBY.SKIP('ALTER TABLESPACE'); フィジカル・データベースをプライマリ・データベースと同じシステム上に配置する際に設定した |
データベースがオープンされるのはこれが初回であるため、データベースのグローバル名は、新しいDB_NAME
初期化パラメータと一致するように自動的に調整されます。
注意: Oracle Databaseソフトウェアのローリング・アップグレードを実行するために、ロジカル・スタンバイ・データベースを作成する場合、初めてSQL Applyを開始する前に、ロジカル・スタンバイ・データベースでDBMS_LOGSTDBY PL/SQLプロシージャを使用して、プライマリ・データベースで実行されておりロジカル・スタンバイ・データベースではサポートされないトランザクションに関する情報を取得することをお薦めします。次のプロシージャを実行して情報を取得し、DBA_LOGSTDBY_EVENTS 表にイベントとして記録します。
EXEC DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED', DBMS_LOGSTDBY.MAX_EVENTS); EXEC DBMS_LOGSTDBY.APPLY_SET('RECORD_UNSUPPORTED_OPERATIONS', 'TRUE'); 関連項目:
|
次の文を発行して、ロジカル・スタンバイ・データベースに対するREDOデータの適用を開始します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
注意: フィジカル・スタンバイ・データベースからロジカル・スタンバイ・データベースへの変換は、次のように2段階で行われます。
|
この時点で、ロジカル・スタンバイ・データベースが実行中であり、最大パフォーマンス・レベルのデータ保護を提供できます。次のリストに、ロジカル・スタンバイ・データベースに対して実行できるその他の準備について説明します。
データ保護モードのアップグレード
Data Guard構成は、最初は最大パフォーマンス・モード(デフォルト)で設定されます。
フラッシュバック・データベースの有効化
フラッシュバック・データベースにより、フェイルオーバー後のプライマリ・データベースの再作成の必要がなくなります。フラッシュバック・データベースでは、データファイルをバックアップからリストアしたりREDOデータを広範囲に適用する必要がないため、従来のPoint-in-Timeリカバリよりもはるかに高速でデータベースを過去の最新時点の状態に戻すことができます。フラッシュバック・データベースは、プライマリ・データベースまたはスタンバイ・データベース、あるいはその両方で有効化できます。Data Guard環境でのフラッシュバック・データベースの使用例は、13.2項「フラッシュバック・データベースを使用した障害が発生したプライマリのスタンバイ・データベースへの変換」および13.3項「Open Resetlogs文の発行後のフラッシュバック・データベースの使用」を参照してください。データベースのフラッシュバックの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』も参照してください。