プライマリ・データベース内の表の行が一意に識別できることの確認 プライマリ・データベース内の表の行が一意に識別できることの確認 プライマリ・データベース内の表の行が一意に識別できることの確認 プライマリ・データベース内の表の行が一意に識別できることの確認

ロジカル・スタンバイ・データベースがプライマリ・データベースのバックアップ・コピーか ら作成されていても、ロジカル・スタンバイ・データベースの物理的な構成は、プライマリ・

データベースの構成とは異なります。そのため、プライマリ・データベースによって生成され たREDOレコードに含まれているROWIDは、ロジカル・スタンバイ・データベース内の対応 する行を識別するためには使用できません。

Oracleでは、ロジカル・スタンバイ・データベース内の変更された行をロジカルに識別するた

めに、主キーまたは一意索引サプリメンタル・ロギングを使用します。また、データベース全 体の主キーおよび一意索引サプリメンタル・ロギングが使用可能になると、各UPDATE文によ り、ロジカル・スタンバイ・データベース内の変更された行を一意に識別するために、REDO ログに必要な列の値が書き込まれます。

■ 表に主キーが定義されている場合、主キーは変更された行を識別するために、UPDATE文 の一部としてログに記録されます。

■ 主キーがない場合、一番短く、NULL値が許容されていない一意キーが、変更された行を 識別するために、UPDATE文の一部としてログに記録されます。

■ 主キーもNULL値が許容されていない一意キーもない場合、バインドされているサイズの すべての列が、変更された行を識別するために、UPDATE文の一部としてログに記録され ます。つまり、LONG、LOB、LONG ROW、オブジェクト型およびコレクション以外のすべ ての列が、ログに記録されます。

SQL Applyで、REDOデータの更新をロジカル・スタンバイ・データベースに効率的に適用で

きるように、適切で可能な場合には、必ずプライマリ・データベースの表に主キーまたは NULL値が許容されていない一意索引を追加することをお薦めします。

表 表 表

表 4-1 ロジカル・スタンバイ・データベースを作成するためのプライマリ・データベースの準備ロジカル・スタンバイ・データベースを作成するためのプライマリ・データベースの準備ロジカル・スタンバイ・データベースを作成するためのプライマリ・データベースの準備ロジカル・スタンバイ・データベースを作成するためのプライマリ・データベースの準備 参照先参照先

参照先参照先 タスクタスクタスクタスク

4.1.1項 表のデータ型および記憶域属性のサポートの判別

4.1.2項 プライマリ・データベース内の表の行が一意に識別できることの確認

ロジカル・スタンバイ・データベースの作成要件

ロジカル・スタンバイ・データベースの作成 4-3 ロジカル・スタンバイ・データベース内のレプリケートされている各表の行をSQL Applyに よって一意に識別できるかどうかを確認するには、次の手順を実行します。

手順手順

手順手順 1 プライマリ・データベース内の一意ロジカル識別子のない表を検索するプライマリ・データベース内の一意ロジカル識別子のない表を検索するプライマリ・データベース内の一意ロジカル識別子のない表を検索するプライマリ・データベース内の一意ロジカル識別子のない表を検索する

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_COLLUMN = 'Y'

手順 手順 手順

手順 2 無効化された無効化された無効化された無効化されたRELY主キー制約を追加する主キー制約を追加する主キー制約を追加する主キー制約を追加する

アプリケーションで、表内の行が一意であることが保証される場合は、表に無効化された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文を実行中に、全表スキャンが実行されます。

関連項目 関連項目 関連項目 関連項目:

■ DBA_LOGSTDBY_NOT_UNIQUEビューの詳細は、『Oracle Databaseリ ファレンス』を参照してください。

■ ALTER TABLE文の構文およびRELY制約の作成の詳細は、『Oracle

Database SQLリファレンス』を参照してください。

■ RELY制約およびロジカル・スタンバイ・データベース上でパフォーマン スを向上させるために行うことができる処理の詳細は、9-23ページの 9.6.1項「主キーRELY制約の作成」を参照してください。

ロジカル・スタンバイ・データベースの作成手順

4.2 ロジカル・スタンバイ・データベースの作成手順 ロジカル・スタンバイ・データベースの作成手順 ロジカル・スタンバイ・データベースの作成手順 ロジカル・スタンバイ・データベースの作成手順

この項では、ロジカル・スタンバイ・データベースの作成で実行するタスクについて説明しま す。

表4-2は、ロジカル・スタンバイ・データベースの作成で実行するタスクのチェックリストで、

各タスクを実行するデータベースを指定します。各タスクを詳細に説明している参照先の項も 記載されています。

4.2.1 フィジカル・スタンバイ・データベースの作成 フィジカル・スタンバイ・データベースの作成 フィジカル・スタンバイ・データベースの作成 フィジカル・スタンバイ・データベースの作成

ロジカル・スタンバイ・データベースを作成するには、次のように最初にフィジカル・スタン バイ・データベースを作成してから、ロジカル・スタンバイ・データベースへと推移させます。

第3章「フィジカル・スタンバイ・データベースの作成」の指示に従ってフィジカル・スタン バイ・データベースを作成します。

4.2.2 フィジカル・スタンバイ・データベースでの フィジカル・スタンバイ・データベースでの フィジカル・スタンバイ・データベースでの フィジカル・スタンバイ・データベースでの REDO Apply の停止 の停止 の停止 の停止

ロジカル・スタンバイ・データベースに変換する前に、実行時間に関係なく、新規フィジカ ル・スタンバイ・データベースでREDO Applyを実行できます。ただし、ロジカル・スタンバ イ・データベースに変換する前に、フィジカル・スタンバイ・データベースでREDO Applyを 停止する必要があります。 REDO Applyの停止は、LogMinerディクショナリを含むREDOの 後に変更が適用されることを避けるために必要です（4-6ページの4.2.3.2項「REDOデータで のディクショナリの構築」で説明）。

REDO Applyを停止するには、フィジカル・スタンバイ・データベースで次の文を発行します。

データベースが複数のインスタンスから構成されるRACデータベースの場合、この文を発行す る前に、最初にインスタンスの数を1に削減する必要があります。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

表表

表表 4-2 ロジカル・スタンバイ・データベースの作成ロジカル・スタンバイ・データベースの作成ロジカル・スタンバイ・データベースの作成ロジカル・スタンバイ・データベースの作成 参照先

参照先 参照先

参照先 タスクタスクタスクタスク データベースデータベースデータベースデータベース

4.2.1項 フィジカル・スタンバイ・データベースの作成 プライマリ

4.2.2項 フィジカル・スタンバイ・データベースでのREDO Applyの停止 スタンバイ

4.2.3項 ロジカル・スタンバイ・データベースをサポートするためのプライマリ・デー

タベースの準備

プライマリ

4.2.4項 ロジカル・スタンバイ・データベースへの推移 スタンバイ

4.2.5項 ロジカル・スタンバイ・データベースのオープン スタンバイ

4.2.6項 ロジカル・スタンバイ・データベースが正しく実行されているかどうかの確認 スタンバイ

ロジカル・スタンバイ・データベースの作成手順

ロジカル・スタンバイ・データベースの作成 4-5

4.2.3 ロジカル・スタンバイ・データベースをサポートするためのプライマリ・ ロジカル・スタンバイ・データベースをサポートするためのプライマリ・ ロジカル・スタンバイ・データベースをサポートするためのプライマリ・ ロジカル・スタンバイ・データベースをサポートするためのプライマリ・

データベースの準備 データベースの準備 データベースの準備 データベースの準備

この項は、次の項目で構成されています。

■ ロールの推移のためのプライマリ・データベースの準備

■ REDOデータでのディクショナリの構築

4.2.3.1 ロールの推移のためのプライマリ・データベースの準備 ロールの推移のためのプライマリ・データベースの準備 ロールの推移のためのプライマリ・データベースの準備 ロールの推移のためのプライマリ・データベースの準備

3-5ページの3.1.4項「プライマリ・データベースの初期化パラメータの設定」では、プライマ

リ・データベースがフィジカル・スタンバイ・ロールに推移する場合に有効になるように、複 数のスタンバイ・ロールの初期化パラメータを設定しました。プライマリ・データベースをロ ジカル・スタンバイ・ロールに推移させる場合は、ロールの推移後にパラメータを変更せずに すむように、プライマリ・データベースに例4-1に示すLOG_ARCHIVE_DEST_3宛先を含める 必要があります。このパラメータは、プライマリ・データベースがスタンバイ・ロールに推移 したときにのみ有効になります。

例 例 例

例 4-1 プライマリ・データベースプライマリ・データベースプライマリ・データベースプライマリ・データベース: ロジカル・スタンバイ・ロールの初期化パラメータロジカル・スタンバイ・ロールの初期化パラメータロジカル・スタンバイ・ロールの初期化パラメータロジカル・スタンバイ・ロールの初期化パラメータ LOG_ARCHIVE_DEST_3=

'LOCATION=/arch2/chicago/

VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=chicago'

LOG_ARCHIVE_DEST_STATE_3=ENABLE

LOG_ARCHIVE_DEST_3パラメータを動的に設定するには、SQL ALTER SYSTEM SET文を使 用し、変更が即時に有効になってデータベースを停止して再起動した後も存続するように SCOPE=BOTH句を指定します。

次の表に、例4-1に示した初期化パラメータで定義されるアーカイブ・プロセスを示します。

シカゴのデータベースがプライマリ・

シカゴのデータベースがプライマリ・

シカゴのデータベースがプライマリ・

シカゴのデータベースがプライマリ・

ロールで稼働している場合 ロールで稼働している場合 ロールで稼働している場合 ロールで稼働している場合

シカゴのデータベースがロジカル・

シカゴのデータベースがロジカル・

シカゴのデータベースがロジカル・

シカゴのデータベースがロジカル・

スタンバイ・ロールで稼働している場合 スタンバイ・ロールで稼働している場合 スタンバイ・ロールで稼働している場合 スタンバイ・ロールで稼働している場合 LOG_ARCHIVE_DEST_3 無視。LOG_ARCHIVE_DEST_3は、

chicagoがスタンバイ・ロールで稼働し

ている場合にのみ有効。

/arch2/chicago/内のローカル・アーカイブ REDOログ・ファイルにプライマリ・データ ベースから受信したREDOデータをアーカイブ。