| Oracle® Databaseアドバンスト・レプリケーション 11g リリース2 (11.2) B72089-02 |
|
 前 |
 次 |
レプリケーション環境の計画を開始する前に、これまでの章で説明したレプリケーションの概念およびアーキテクチャについて理解することが重要です。この章では、レプリケーションの概念およびアーキテクチャについて理解していることを前提に、レプリケーション環境の計画に関する重要な考慮事項について説明します。
この章には、次の項が含まれます。
次の項では、レプリケーション環境で使用する表に関する考慮事項について説明します。
各レプリケート表には、可能なかぎり主キーを設定します。主キーを設定できない場合、各レプリケート表に、表の各行の一意の識別子として使用できる列のセットが含まれている必要があります。レプリケーション環境で使用する表に主キーまたは一意の列のセットがない場合は、レプリケート表を必要に応じて修正します。さらに、マスター表またはマスター・マテリアライズド・ビューに基づいて主キー・マテリアライズド・ビューを作成する場合は、そのマスターに主キーを設定する必要があります。
外部キー参照制約を持つ表をレプリケートする場合は、親表で更新および削除が許可されていない場合を除き、常に外部キー列に索引を付けて、これらの索引をレプリケートすることをお薦めします。索引は自動的にはレプリケートされません。索引をレプリケートするには、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースまたはDBMS_REPCATパッケージ内のCREATE_MASTER_REPOBJECTプロシージャを使用して、索引を付けた表を含むマスター・グループに索引を追加します。
アドバンスト・レプリケーションでは、次のデータ型の列を持つ表およびマテリアライズド・ビューのレプリケーションをサポートしています。
VARCHAR2
NVARCHAR2
NUMBER
DATE
TIMESTAMP
TIME WITH TIME ZONE
TIMESTAMP LOCAL TIME ZONE
INTERVAL YEAR TO MONTH
INTERVAL DAY TO SECOND
RAW
ROWID
CHAR
NCHAR
BASICFILE記憶域を持つCLOB
BASICFILE記憶域を持つNCLOB
BASICFILE記憶域を持つBLOB
CLOBとして格納されているXMLType
型継承または型進化を使用していないユーザー定義型
型継承または型進化を使用していない、オラクル社が提供する型
ピース単位の更新と追加がこれらのLOB列に適用されると、マルチマスター・レプリケーションに使用する遅延および同期のリモート・プロシージャ・コール・メカニズムによって、サポートされているLOBデータ型にピース単位の変更のみが伝播されます。ただし、マテリアライズド・ビューの定義問合せのWHERE句でLOB列は参照できません。
ユーザー定義型(列オブジェクト、オブジェクト表、REF、VARRAY、ネストした表など)を使用する表およびマテリアライズド・ビューはレプリケートできます。
アドバンスト・レプリケーションでは、次のデータ型の列を持つ表およびマテリアライズド・ビューのレプリケーションをサポートしていません。
FLOAT
BINARY_FLOAT
BINARY_DOUBLE
LONG
LONG RAW
SECUREFILE記憶域を持つCLOB
SECUREFILE記憶域を持つNCLOB
SECUREFILE記憶域を持つBLOB
BFILE
オブジェクト・リレーショナルまたはバイナリXMLとして格納されているXMLType
Expression型
型継承または型進化を使用しているユーザー定義型
型継承または型進化を使用している、オラクル社が提供する型
アドバンスト・レプリケーションでサポートされるには、LONGデータ型を、BASICFILE記憶域を持つLOBに変換する必要があります。
マスター表または更新可能マテリアライズド・ビュー内のUROWID列のレプリケーションもサポートされていません。ただし、読取り専用マテリアライズド・ビューではUROWID列を使用できます。
|
関連項目:
|
アドバンスト・レプリケーションでは、次の表タイプのレプリケーション、およびそれらの表タイプに基づくマテリアライズド・ビューをサポートしていません。
さらに、透過的データ暗号化を使用して暗号化された列のある表は、マスター・レプリケーションではサポートされていません。ただし、暗号化された列のある表に基づくマテリアライズド・ビューはサポートされています。
表を作成するときは、システム変更番号(SCN)を追跡するために次のオプションを指定できます。
NOROWDEPENDENCIES。SCNがデータ・ブロック・レベルで追跡されることを指定します(デフォルト)。
ROWDEPENDENCIES。SCNが表の各行に対して追跡されることを指定します。
ROWDEPENDENCIESオプションを使用すると、パラレル伝播使用時のパフォーマンスとスケーラビリティが向上しますが、このオプションでは、各行に6バイトの追加記憶領域が必要になります。
次のSQL文では、ROWDEPENDENCIESオプションを使用して表を作成します。
CREATE TABLE order_items (order_id NUMBER(12), line_item_id NUMBER(3) NOT NULL, product_id NUMBER(6) NOT NULL, unit_price NUMBER(8,2), quantity NUMBER(8) ) ROWDEPENDENCIES;
このorder_items表の各行でSCNが追跡されます。表がクラスタの一部である場合は、CREATE CLUSTER文でROWDEPENDENCIESオプションを使用することもできます。
表6-1に、レプリケーション環境の操作性、信頼性およびパフォーマンスにとって重要な初期化パラメータを示します。この表では、各パラメータが変更可能かどうかを示しています。変更可能な初期化パラメータは、インスタンスの実行中に、ALTER SYSTEM文を使用して変更できます。一部の変更可能なパラメータは、ALTER SESSION文を使用して1つのセッションでも変更できます。
表6-1 アドバンスト・レプリケーションにおいて重要な初期化パラメータ
|
関連項目:
|
レプリケーション環境を計画するときは、レプリケーション環境に関係する各サイトをマスター・サイトにするかマテリアライズド・ビュー・サイトにするかを決定する必要があります。これを決定する際は、両方のタイプのレプリケーション・サイトの特性と利点を考慮してください。1つのレプリケーション環境で、マスター・サイトとマテリアライズド・ビュー・サイトの両方をサポートできます。
表6-2 マスター・サイトとマテリアライズド・ビュー・サイトの特性
| マスター・サイト | マテリアライズド・ビュー・サイト |
|---|---|
|
通常、少数のマスター・サイトと通信しますが、多数のマテリアライズド・ビュー・サイトとも通信する場合もあります。 |
1つのマスター・サイトまたは1つのマスター・マテリアライズド・ビュー・サイトと通信します。 |
|
他のマスター・サイトのデータの完全なコピーである大量のデータを含んでいます。 |
マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのデータのサブセットである少量のデータを含んでいます。 |
|
通常、データ伝播の間隔は短く、継続的に通信します。 |
バルク・データ移送の間隔は長く、定期的に通信します。 |
マスター・サイトには次のような利点があります。
リモート・サイトからのデータ・アクセスの可用性を高めるサポートを提供します。
変更が自動的にかつ通常は短い間隔で伝播されるので、データ操作言語(DML)による変更が頻繁に行われても適切に対処できます。
表をロックせずに、DMLによる変更とデータ伝播を同時に行うことができます。
フェイルオーバーによる保護を提供できます。
マスター・サイトの設定には、アドバンスト・レプリケーション・インタフェースの「レプリケーション用のマスター・サイトの構成」ウィザードまたはレプリケーション・マネージメントAPIのいずれかを使用します。
|
関連項目:
|
マテリアライズド・ビュー・サイトには次のような利点があります。
モバイル・コンピューティングをサポートしています。
マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトのデータのサブセットを含められます。
マテリアライズド・ビュー・サイトの設定には、アドバンスト・レプリケーション・インタフェースのレプリケーション用のマスター・サイトとマテリアライズド・ビュー・サイトの構成ウィザードまたはレプリケーション・マネージメントAPIのいずれかを使用できます。
|
関連項目:
|
マテリアライズド・ビュー・レプリケーションに関する問題の多くは、環境の準備が正しく行われていないことによるものです。マテリアライズド・ビュー環境を作成するには、事前に次の4つのことを行う必要があります。
必要なスキーマの作成
必要なデータベース・リンクの作成
適切な権限の割当て
十分なジョブ・プロセスの割当て
アドバンスト・レプリケーション・インタフェースのレプリケーション用のマスター・サイトとマテリアライズド・ビュー・サイトの構成ウィザードは、これらの作業を自動的に実行します。以降では、レプリケーション環境の理解とレプリケーション・マネージメントAPIの使用に役立つ情報を提供します。「設定ウィザード」を実行した後で、必要なマテリアライズド・ビュー・ログを作成します。インタフェースを使用してマテリアライズド・ビュー・サイトを設定する方法の詳細は、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。
アドバンスト・レプリケーション・インタフェースを使用できない場合、レプリケーション・マネージメントAPIを使用してマテリアライズド・ビュー・サイトを設定する方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』の第2章でマテリアライズ・ビュー・サイトの設定に関する説明を参照してください。
次の項では、アドバンスト・レプリケーション・インタフェースのレプリケーション用のマスター・サイトとマテリアライズド・ビュー・サイトの構成ウィザードまたは『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』に記述されているスクリプトを使用してマテリアライズド・ビュー・サイトを設定する方法について説明します。
各マテリアライズド・ビューには、マテリアライズド・ビュー・サイトで管理アクティビティやリフレッシュ・アクティビティを実行する何人かのユーザーが必要です。マテリアライズド・ビューの管理者とリフレッシャには、必要な権限を作成して付与する必要があります。
マテリアライズド・ビュー・サイトのユーザーのかわりに作業を実行するには、ターゲット・マスター・サイトにも同等のプロキシ・ユーザーが必要です。通常は、プロキシ・マテリアライズド・ビュー管理者とプロキシ・リフレッシャを作成します。
リモート・データベースのマテリアライズド・ビューを含むスキーマは、マスター・データベースのマスター表を含むスキーマに対応している必要があります。したがって、マテリアライズド・ビューを使用してレプリケートするマスター表を含むスキーマを識別してください。マスター・データベースのターゲット・スキーマを識別した後、リモート・データベースで、対応するアカウントを同じ名前で作成します。たとえば、すべてのマスター表がny.example.comデータベースのsalesスキーマ内にある場合は、対応するsalesスキーマをマテリアライズド・ビュー・データベースsf.example.comに作成します。
|
関連項目: 『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』に記載されている手順では、マテリアライズド・ビュー・グループを作成する指示の中で説明されているスクリプトの一部として、必要なスキーマが作成されます。 |
マテリアライズド・ビューの定義問合せでは、1つ以上のデータベース・リンクを使用してリモート表のデータを参照します。マテリアライズド・ビューを作成するには、使用する予定のデータベース・リンクが使用可能になっている必要があります。さらに、リモート・データベースにアクセスするためにデータベース・リンクで使用するアカウントには、セキュリティ・コンテキストが定義され、そのコンテキストに基づいてマテリアライズド・ビューが作成され、リフレッシュが実行されます。
正常な動作を保証するために、マテリアライズド・ビューの定義問合せでは、ユーザー名とパスワードが定義に埋め込まれているデータベース・リンクを使用する必要があります(マテリアライズド・ビューを作成するときは、パブリック・データベース・リンクを使用できません)。ユーザー名とパスワードが埋め込まれているデータベース・リンクは常に、指定されたアカウントを使用してリモート・データベースとの接続を確立します。また、リンクで使用するリモート・アカウントには、マテリアライズド・ビューの定義問合せの中で参照されるデータにアクセスするために必要なSELECT権限が必要です。
マテリアライズド・ビューを作成するには、いくつかの管理データベース・リンクを作成する必要があります。具体的には、マテリアライズド・ビュー・サイトからマスター・サイトへのPUBLICデータベース・リンクを作成します。これを作成すると、各プライベート・データベース・リンク内にUSING句を含める必要がなくなるため、プライベート・データベース・リンクを定義しやすくなります。また、マテリアライズド・ビュー管理者からプロキシ管理者へのプライベート・データベース・リンクおよびプロパゲータから受信者へのプライベート・データベース・リンクも作成する必要がありますが、これらのデータベース・リンクは、アドバンスト・レプリケーション・インタフェースのレプリケーション用のマスター・サイトとマテリアライズド・ビュー・サイトの構成ウィザードを使用すると自動的に作成されます。
|
関連項目: 詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』のセキュリティ・オプションに関する説明を参照してください。 |
管理データベース・リンクを作成した後、マテリアライズド・ビュー・データベースの各レプリケート・マテリアライズド・ビュー・スキーマをマスター・データベースの対応するスキーマに接続するプライベート・データベース・リンクを作成する必要があります。マテリアライズド・ビュー・データベースの各プライベート・データベース・リンクには、対応付けられたマスター・データベースのアカウント情報を埋め込むことが必要です。たとえば、マテリアライズド・ビュー・データベースのhrスキーマには、hrというユーザー名とパスワードを使用してマスター・データベースに接続するプライベート・データベース・リンクが必要です。
マルチマスター・レプリケーションの場合、レプリケーション・プロパゲータおよび受信者スキーマの仮想プライベート・データベース(VPD)の制限はありません。マテリアライズド・ビューの場合、マテリアライズド・ビューに対する定義問合せは、VPDによって変更されません。VPDは、マテリアライズド・ビューの作成とリフレッシュの両方を実行するスキーマに対してNULLポリシーを戻す必要があります。USING TRUSTED CONSTRAINTS句を指定した場合は、NULL以外のVPDポリシーを持つマテリアライズド・ビューを作成できます。この場合、マテリアライズド・ビューが正しく動作することを確認します。マテリアライズド・ビューの結果は、VPDポリシーによってフィルタ処理された行と列に基づいて計算されます。したがって、正しい結果を得るには、マテリアライズド・ビュー定義をVPDポリシーで調整する必要があります。
|
関連項目:
|
マテリアライズド・ビューの作成者と所有者は、ともにマテリアライズド・ビューの定義SELECT文を発行できる必要があります。マテリアライズド・ビューの所有者とは、マテリアライズド・ビューが含まれているスキーマのことです。レプリケーション管理者またはマテリアライズド・ビュー管理者以外のユーザーがマテリアライズド・ビューを作成する場合は、そのユーザーにCREATE MATERIALIZED VIEW権限および定義SELECT文を実行する適切なSELECT権限が付与されている必要があります。
|
関連項目: 『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』に記載されている手順では、マテリアライズド・ビュー・グループを作成する指示の中で説明されているスクリプトの一部として、必要な権限が付与されます。権限要件は、「マテリアライズド・ビューの操作に必要な権限」でも説明されています。 |
遅延トランザクション・キューのサイズを適正に保つために、パージ操作をスケジュールして、正常に送信されたすべての遅延トランザクションを遅延トランザクション・キューから削除します。この操作はマスター・サイトですでに実行済の場合があります。パージ操作を再びスケジュールしてもマスター・サイトに悪影響はありませんが、パージ・スケジュールの特性が変更される可能性があります。
マテリアライズド・ビュー・サイトでプッシュをスケジュールすると、データベース・リンクを使用して、マテリアライズド・ビュー・サイトの遅延トランザクションが対応するターゲット・マスター・サイトに自動的に伝播されます。このタイプのデータベース・リンクは、スケジュール・リンクと呼ばれます。マテリアライズド・ビュー・グループは1つのターゲット・マスター・サイトのみを持つので、通常、マテリアライズド・ビュー・サイトの各マテリアライズド・ビュー・グループには1つのスケジュール・リンクのみが存在します。
レプリケーション環境の自動化を処理するために、十分なジョブ・スレーブを割り当てることが重要です。ジョブ・スレーブは、遅延トランザクション・キューの伝播、遅延トランザクション・キューのパージ、マテリアライズド・ビューのリフレッシュなどを自動的に行います。
マルチマスター・レプリケーションの場合、各マスター・サイト間にスケジュール・リンクがあります。たとえば、マスター・サイトが6つある場合、各サイトには他の5つのサイトへのスケジュール・リンクがあります。通常、スケジュール・リンクごとにプロセスが1つ必要です。遅延トランザクション・キューのパージやその他のユーザー定義ジョブのために、追加のジョブ・プロセスが必要になります。
マテリアライズド・ビュー・レプリケーションの特性として、マテリアライズド・ビュー・サイトには、通常、マスター・データベースへのスケジュール・リンクが1つあり、少なくとも1つのジョブ・プロセスが必要です。マテリアライズド・ビュー・サイトで必要なジョブ・プロセスの数は、パージ・スケジュール、ユーザー定義ジョブおよびスケジュール・リンクに依存しますが、通常は1つから3つを必要とします。また、それぞれの並列度に対して少なくとも1つのジョブ・スレーブが必要です。
ユーザーがアプリケーション・インタフェースを使用してマテリアライズド・ビューを手動でリフレッシュする場合は、スケジュール・リンクを作成する必要がなくなり、マテリアライズド・ビュー・サイトで必要なジョブ・プロセスが1つ減ります。
ジョブ・スレーブは、データベースの初期化パラメータ・ファイルにあるJOB_QUEUE_PROCESSES初期化パラメータを使用して定義されます。この初期化パラメータは、変更可能です。そのため、インスタンス実行中に変更できます。ジョブ・スレーブの間隔は自動的に判断されます。つまり、ジョブ・スレーブが起動してジョブを実行するタイミングはOracleが判断します。
リモート・マテリアライズド・ビュー・サイトのマテリアライズド・ビュー・グループおよびマテリアライズド・ビューを作成する前に、必要なマテリアライズド・ビュー・ログをマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトに作成しておく必要があります。マテリアライズド・ビュー・ログは、高速リフレッシュを使用するマテリアライズド・ビューを1つでもサポートしているすべてのマスター表またはマスター・マテリアライズド・ビューで必要になります。
マテリアライズド・ビュー・ログを作成するには、次の権限が必要です。
CREATE ANY TABLE
CREATE ANY TRIGGER
SELECT(マテリアライズド・ビュー・ログのマスターに対する権限)
COMMENT ANY TABLE
|
関連項目: Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用してマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトにマテリアライズド・ビュー・ログを作成する方法の詳細は、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。 |
マテリアライズド・ビュー・ログを作成する場合は、必要に応じてログに列を追加できます。マテリアライズド・ビューを高速リフレッシュするには、マテリアライズド・ビュー・ログに次のタイプの列を追加する必要があります。
副問合せのWHERE句で参照される列で、等価結合の一部ではなく、主キー列でもない列。このような列は、フィルタ列と呼ばれます。
副問合せが多対多または1対多のいずれかの関係の場合に、等価結合内の列で主キー列ではない列。副問合せが多対1の場合は、マテリアライズド・ビュー・ログに結合列を追加する必要はありません。
コレクション列はマテリアライズド・ビュー・ログに追加できません。また、完全リフレッシュを使用するマテリアライズド・ビューの場合は、マテリアライズド・ビュー・ログは不要です。
たとえば、次のようなDDLを考えてみます。
1) CREATE MATERIALIZED VIEW oe.customers REFRESH FAST AS 2) SELECT * FROM oe.customers@orc1.example.com c 3) WHERE EXISTS 4) (SELECT * FROM oe.orders@orc1.example.com o 5) WHERE c.customer_id = o.customer_id AND o.order_total > 20000);
このDDLの5行目では、WHERE句内で3つの列が参照されています。列orders.customer_idとcustomers.customer_idは等価結合句の一部として参照されています。customers.customer_idは主キー列であるため、この列はデフォルトでロギングされますが、orders.customer_idは主キー列ではないため、マテリアライズド・ビュー・ログに追加する必要があります。また、列orders.order_totalは追加フィルタ列であるため、これもロギングする必要があります。
したがって、orders.customer_idとorders.order_totalをoe.orders表のマテリアライズド・ビュー・ログに追加します。
これらの列が追加されたマテリアライズド・ビュー・ログを作成するには、次の文を発行します。
CREATE MATERIALIZED VIEW LOG ON oe.orders WITH PRIMARY KEY (customer_id,order_total);
oe.customers表にマテリアライズド・ビュー・ログがすでに存在する場合は、次の文を発行してこれらの列を追加できます。
ALTER MATERIALIZED VIEW LOG ON oe.orders ADD (customer_id,order_total);
ユーザー定義データ型を使用している場合は、列オブジェクトの属性をマテリアライズド・ビュー・ログにロギングできます。たとえば、oe.customers表にcust_address.postal_code属性がある場合、次の文を発行すると、この属性をマテリアライズド・ビュー・ログにロギングできます。
ALTER MATERIALIZED VIEW LOG ON oe.customers ADD (cust_address.postal_code);
作成するマテリアライズド・ビューの定義問合せを分析し、マテリアライズド・ビュー・ログに追加する必要がある列を識別することをお薦めします。マテリアライズド・ビュー・ログに列を追加せずに、追加列を必要とするマテリアライズド・ビューを作成またはリフレッシュしようとした場合、マテリアライズド・ビューの作成またはリフレッシュは失敗します。
|
注意: マテリアライズド・ビューを高速リフレッシュするには、副問合せ内の結合列をマテリアライズド・ビュー・ログに追加する必要があります(結合列が主キー列ではなく、副問合せが多対多または1対多のいずれかの関係の場合)。副問合せが多対1の場合は、マテリアライズド・ビュー・ログに結合列を追加する必要はありません。 |
|
関連項目:
|
マテリアライズド・ビュー環境は、様々な場所から様々な方法で作成できます。一般的には、マスター・サイトのデプロイメント・テンプレートを使用してマテリアライズド・ビュー環境をローカルで事前作成し、それをターゲット・マテリアライズド・ビュー・サイトに個別に配置します。
また、マテリアライズド・ビュー・サイトへの接続を確立してマテリアライズド・ビュー環境を直接作成する方法もあります。
デプロイメント・テンプレートを使用してOracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースでマテリアライズド・ビュー環境をまとめて作成する方法の詳細は、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。
また、リモート・マテリアライズド・ビュー・サイトに直接接続し、Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用してマテリアライズド・ビュー環境を個別に作成する方法の詳細は、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。
デプロイメント・テンプレートを使用してレプリケーション・マネージメントAPIでマテリアライズド・ビュー環境をまとめて事前作成する方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』のデプロイメント・テンプレートの作成に関する説明を参照してください。
また、リモート・マテリアライズド・ビュー・サイトに直接接続し、レプリケーション・マネージメントAPIを使用してマテリアライズド・ビュー・サイトを個別に作成する方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』のマテリアライズド・ビュー・グループの作成に関する説明を参照してください。
1つ以上のマテリアライズド・ビュー・サイトを含むマテリアライズド・ビュー環境を作成した後、新しくマテリアライズド・ビュー・サイトを追加することがあります。次の2つの条件がどちらも成立する場合は、新規マテリアライズド・ビュー・サイトに作成したマテリアライズド・ビューを高速リフレッシュしようとしたときに問題が発生することがあります。
新規マテリアライズド・ビュー・サイトのマテリアライズド・ビューと、他のマテリアライズド・ビュー・サイトの既存マテリアライズド・ビューが、同一のマスター表またはマスター・マテリアライズド・ビューに基づいている場合。
新規マテリアライズド・ビュー・サイトに新規マテリアライズド・ビューを作成中に、既存のマテリアライズド・ビューをリフレッシュする場合。
問題が発生するのは、新規マテリアライズド・ビューが最初の高速リフレッシュを実行する前に、マスターのマテリアライズド・ビュー・ログがパージされたときです。このようなときに新規マテリアライズド・ビュー・サイトでマテリアライズド・ビューを高速リフレッシュしようとすると、次のエラーが発生することがあります。
ORA-12004 REFRESH FAST cannot be used for materialized view materialized_view_name ORA-12034 materialized view log on materialized_view_name younger than last refresh
これらのエラーを受け取った場合の解決策は、新規マテリアライズド・ビューの完全リフレッシュを実行することのみです。
この問題を回避するには、次のオプションのいずれかを選択します。
デプロイメント・テンプレートを使用してマテリアライズド・ビュー・サイトにマテリアライズド・ビュー環境を作成します。デプロイメント・テンプレートを使用すると、この問題は発生しません。
新規マテリアライズド・ビュー・サイトにダミーのマテリアライズド・ビューを作成してから、本番のマテリアライズド・ビューを作成します。ダミーのマテリアライズド・ビューを作成することにより、本番のマテリアライズド・ビューを作成中にマテリアライズド・ビュー・ログがパージされなくなります。
マテリアライズド・ビュー・サイトにダミーのマテリアライズド・ビューを作成する場合は、次の手順を実行します。
マスター表またはマスター・マテリアライズド・ビューに基づいたdummy_mviewという名前のダミーのマテリアライズド・ビューを作成します。たとえば、salesというマスター表に基づいたダミー・マテリアライズド・ビューを作成するには、新規マテリアライズド・ビュー・サイトで次の文を発行します。
CREATE MATERIALIZED VIEW dummy_mview REFRESH FAST AS SELECT * FROM pr.sales@orc1.example.com WHERE 1=0;
本番のマテリアライズド・ビューを新規マテリアライズド・ビュー・サイトに作成します。
新規マテリアライズド・ビュー・サイトで本番のマテリアライズド・ビューの高速リフレッシュを実行します。
ダミー・マテリアライズド・ビューを削除します。
異なるサイトで別々のリリースのOracle Databaseを含むアドバンスト・レプリケーション環境の構成を計画する場合、その環境は次の要件を満たす必要があります。
Oracle Database 11gのマスター・サイトは、Oracle9i リリース2(9.2)以上のマスター・サイトとのみ相互運用できる。
Oracle Database 11gのマテリアライズド・ビュー・サイトは、Oracle9i リリース2(9.2)以上のマスター・サイトとのみ相互運用できる。
Oracle Database 11gのマスター・サイトは、Oracle9i リリース2(9.2)以上のマテリアライズド・ビュー・サイトとのみ相互運用できる。
スケジュール・リンクによって、あるマスター・サイトから別のマスター・サイトへの遅延トランザクション・キューの伝播方法、または、あるマテリアライズド・ビュー・サイトからそのマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトへの遅延トランザクション・キューの伝播方法が決まります。スケジュール・リンクを作成すると、遅延トランザクション・キューをシステムの別のサイトにプッシュするジョブがローカル・ジョブ・キューに作成されます。リモート・マスター・サイトへの遅延トランザクションの伝播は、レプリケーション・プロパゲータのセキュリティ・コンテキスト内で行われます。
スケジュール・リンクを構成すると、シリアル伝播またはパラレル伝播を使用して情報をプッシュできます。一般的に、parallelismパラメータを1に設定した場合でも、パラレル伝播を使用する必要があります。
レプリケーション環境のスケジュール・リンクを作成する前に、レプリケーションをシステム全体でグローバルに発生させる方法を慎重に検討する必要があります。たとえば、一定の間隔で遅延トランザクションを伝播できます。この場合、プッシュする頻度と時刻を決定する必要があります。また、リアルタイム・レプリケーション(同期レプリケーション)をシミュレートするために、各スケジュール・リンクを使用して、マスター・サイトの遅延トランザクション・キューをその接続先に連続的にプッシュする場合もあります。
あるいは、夜間など、必ず接続できる時間帯や通信コストが最低の時間帯にプッシュをスケジュールする場合もあります。さらに、レプリケーションによるネットワーク・リソースへの負荷を分散するために、各マスター・サイト間でリンクのスケジュールをずらすこともできます。
サイトの遅延トランザクション・キューをリモートの接続先に定期的にプッシュするようにスケジュールできます。たとえば、1日に1回または1時間に1回というように設定できます。これを行うには、DBMS_DEFER_SYS.SCHEDULE_PUSHプロシージャを使用し、表6-3に示されている設定を指定します。
表6-3 定期的なプッシュのスケジューリングの設定
| SCHEDULE_PUSHプロシージャのパラメータ | 値 |
|---|---|
|
|
0 |
|
|
適切な日付式。たとえば、1時間の間隔を指定するには、 |
定期的なプッシュのスケジューリングには、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用することもできます。これを行うには、スケジュール・リンクを設定するときに、「遅延秒数」を0(ゼロ)に設定します。
次に、遅延トランザクション・キューを定期的にプッシュする間隔(「送信間隔」コントロール)を設定します。
1時間ごとの定期的プッシュをスケジュールする例を、次に示します。
BEGIN
DBMS_DEFER_SYS.SCHEDULE_PUSH (
destination => 'orc2.example.com',
interval => 'SYSDATE + (1/24)',
next_date => SYSDATE,
delay_seconds => 0);
END;
/
|
関連項目:
|
非同期レプリケーション・メカニズムを使用している場合でも、スケジュール・リンクを構成すると、連続的なリアルタイム・レプリケーションをシミュレートできます。これを行うには、DBMS_DEFER_SYS.SCHEDULE_PUSHプロシージャを使用し、表6-4に示されている設定を指定します。
表6-4 連続的なプッシュをシミュレートする設定
| SCHEDULE_PUSHプロシージャのパラメータ | 値 |
|---|---|
|
|
1200 |
|
|
|
|
|
1以上 |
|
|
|
このように設定すると、「間隔」に設定した時間中ずっと、遅延トランザクション・キューに入れられるトランザクションが連続的にプッシュされます。delay_secondsパラメータに指定されている間に、伝播するトランザクションが遅延トランザクション・キューにない場合は、このジョブにより使用されているリソースが解放され、次のジョブ・スレーブが使用可能になったときに新しく開始されます。
parallelismパラメータを0(ゼロ)に設定してシリアル伝播を使用している場合は、delay_secondsおよびintervalパラメータの設定を低くして環境に適切な値にし、連続的なプッシュをシミュレートできます。ただし、シリアル伝播を使用している場合、連続的なプッシュのシミュレーションでプッシュ・ジョブを頻繁に開始する必要がある場合はコストが高くなります。
連続的なプッシュをシミュレートする例を次に示します。
BEGIN
DBMS_DEFER_SYS.SCHEDULE_PUSH (
destination => 'orc2.example.com',
interval => 'SYSDATE + (1/144)',
next_date => SYSDATE,
parallelism => 1,
execution_seconds => 1500,
delay_seconds => 1200);
END;
/
|
関連項目:
|
スケジュール・パージによって、マスター・サイトまたはマテリアライズド・ビュー・サイトの遅延トランザクション・キューから適用済のトランザクションをパージする方法が決定されます。Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースの「構成ウィザード」を使用してマスター・サイトまたはマテリアライズド・ビュー・サイトを設定すると、一定の基準でローカル遅延トランザクション・キューをパージするジョブが各サイトのローカル・ジョブ・キューに作成されます。レプリケーション環境のサイトを構成する前に、パージを発生させる方法を慎重に検討する必要があります。たとえば、次のような方法があります。
サイトの遅延トランザクション・キューのプッシュとパージを同期化できます。たとえば、トランザクション・キューのプッシュとパージを連続的に行うように構成できます。このように構成した場合、パフォーマンスが向上することがありますが、これは、最後にプッシュされたトランザクションに関する情報が、対応するパージ操作に使用するサーバーのバッファ・キャッシュにすでに存在していることが多いためです。
サーバーがCPUの限界に達していない場合、遅延トランザクション・キューの連続的なパージをスケジュールすると、可能なかぎりキューのサイズを小さく保つことができます。
通常の営業時間帯にトランザクションのスループットが非常に大きくなるサーバーでは、1日の遅延トランザクション全体を格納できる場合は、オフピーク時にパージが行われるようにスケジュールできます。
サイトの遅延トランザクション・キューを定期的にパージするようにスケジュールできます。たとえば、1日に1回または1週間に1回というように設定できます。これを行うには、DBMS_DEFER_SYS.SCHEDULE_PURGEプロシージャを使用し、表6-5に示されている設定を指定します。
表6-5 定期的なパージのスケジューリングの設定
| SCHEDULE_PURGEプロシージャのパラメータ | 値 |
|---|---|
|
|
0 |
|
|
適切な日付式。たとえば、間隔を1日に指定するには、 |
定期的なパージのスケジューリングには、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用することもできます。これを行うには、「遅延秒数」を0(ゼロ)に設定します。次に、遅延トランザクション・キューを定期的にパージする間隔(「パージ間隔」コントロール)を設定します。
1日に1回の定期的なパージをスケジュールする例を、次に示します。
BEGIN
DBMS_DEFER_SYS.SCHEDULE_PURGE (
next_date => SYSDATE,
interval => 'SYSDATE + 1',
delay_seconds => 0);
END;
/
|
関連項目:
|
サイトの遅延トランザクション・キューの連続的なパージを設定するには、DBMS_DEFER_SYS.SCHEDULE_PURGEプロシージャを使用し、表6-6に示されている設定を指定します。
表6-6 連続的なパージのスケジューリングの設定
| SCHEDULE_PURGEプロシージャのパラメータ | 値 |
|---|---|
|
|
500000 |
|
|
|
|
|
|
連続的なパージの設定には、アドバンスト・レプリケーション・インタフェースを使用することもできます。これを行うには、「パージ・スケジュール」ページで、「遅延秒数」を500,000に設定し、間隔(「間隔」フィールド)を、「遅延秒数」設定よりも小さい値に設定します。
連続的なパージをシミュレートする例を次に示します。
BEGIN
DBMS_DEFER_SYS.SCHEDULE_PURGE (
next_date => SYSDATE,
interval => 'SYSDATE + (1/144)',
purge_method => dbms_defer_sys.purge_method_quick,
delay_seconds => 500000);
END;
/
|
関連項目:
|
レプリケーション環境のスケジュール・リンクを作成すると、シリアル伝播またはパラレル伝播を使用して各サイトから接続先に変更を非同期伝播できます。レプリケーション環境を構成する前に、シリアル伝播またはパラレル伝播のいずれを使用するかを決定する必要があります。
シリアル伝播では、レプリケート・トランザクションは、ソース・システムでコミットされたのと同じ順序で一度に1つずつ伝播されます。シリアル伝播を使用するスケジュール・リンクを構成するには、DBMS_DEFER_SYS.SCHEDULE_PUSHプロシージャのparallelismパラメータを0(ゼロ)に設定します。または、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して、「送信スケジュールの編集」ページの「伝播プロセス」制御を0(ゼロ)に設定します。
パラレル伝播では、スループットを向上させるため、レプリケート・トランザクションは複数のパラレル・ストリームを使用して伝播されます。必要に応じて依存トランザクションの実行命令が発行されるので、データ整合性が保持されます。パラレル伝播を使用するスケジュール・リンクを構成するには、DBMS_DEFER_SYS.SCHEDULE_PUSHプロシージャのparallelismパラメータを1以上に設定します。または、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して、「送信スケジュールの編集」ページの「伝播プロセス」制御を1以上に設定します。通常は、パラレル伝播を使用します。
|
関連項目:
|
レプリケーション環境にマテリアライズド・ビュー・サイトを含める場合、デプロイメント・テンプレートを使用してマテリアライズド・ビュー・サイトにレプリケート・オブジェクトを作成できます。
デプロイメント・テンプレートを使用する場合、デプロイメント・テンプレートのインスタンス化のためにマテリアライズド・ビュー・サイトを準備する必要があります。デプロイメント・テンプレートが適切に設計されている場合は、リモート・マテリアライズド・ビュー・サイトで必要な準備作業はほとんどありません。この項では、リモート・マテリアライズド・ビュー・サイトで実行する最も一般的な準備作業について説明します。必要な準備作業がすべて完了した後で、オンライン・インスタンシエーションまたはオフライン・インスタンシエーションを実行できます。
次の点を考慮して、マテリアライズド・ビュー・スナップショット・サイトでインスタンス化を実行するために必要な準備作業を決定します。
リモート・マテリアライズド・ビュー・サイトからターゲット・マスター・サイトにネットワーク接続されているかどうか。
マテリアライズド・ビュー・サイトにOracle9i リリース2(9.2)以上のデータベースがあるかどうか。
リモート・マテリアライズド・ビュー・サイトがマテリアライズド・ビュー・レプリケーションをサポートするように設定されているかどうか。
デプロイメント・テンプレートに必要なスキーマがマテリアライズド・ビュー・サイトに存在するかどうか。
必要なデータベース・リンクがデプロイメント・テンプレートに含まれていない場合、マテリアライズド・ビュー・サイトからマスター・サイトに必要なデータベース・リンクが存在するかどうか。
マテリアライズド・ビューでデプロイメント・テンプレートをインスタンス化するために、オンライン・インスタンシエーションまたはオフライン・インスタンシエーションのどちらを使用するか。
デプロイメント・テンプレートに必要なロールバック・セグメントがマテリアライズド・ビュー・サイトに存在し、かつそのロールバック・セグメントがオンラインであるかどうか。
次の項では、これらの考慮事項に対する指針を示します。
ネットワーク接続性は、すべてのレプリケーション環境においてアドバンスト・レプリケーションの重要な要素です。ターゲット・マスター・サイトに対する適切なOracle Net接続がリモート・マテリアライズド・ビュー・サイトにあるかどうかを確認します。
|
関連項目: Oracleネットワーク接続の設定方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。 |
マテリアライズド・ビュー・サイトをOracle Database 11gと連携させるには、Oracle9i リリース2 (9.2)以上のデータベースを使用している必要があります。マテリアライズド・ビュー・サイトがこれらの要件を満たしていない場合は、デプロイメント・テンプレートをインスタンス化する前にマテリアライズド・ビュー・サイトのデータベースをアップグレードする必要があります。
各マテリアライズド・ビュー・サイトには、マテリアライズド・ビュー・サイトをサポートする特殊な権限を持つユーザーが何人か必要です。これらのユーザーは、管理に必要な権限を持ち、さらにデータの伝播とリフレッシュも実行します。
マテリアライズド・ビュー・サイトの設定では、マテリアライズド・ビューの自動リフレッシュ(オプション)や遅延トランザクション・キューのパージを実行するいくつかの自動化ジョブをスケジュールする必要もあります。
マテリアライズド・ビュー・サイトの設定に使用するツールは、次のとおりです。
アドバンスト・レプリケーション・インタフェース: アドバンスト・レプリケーション・インタフェースを使用してリモート・マテリアライズド・ビュー・サイトに接続し、レプリケーション用のマスター・サイトとマテリアライズド・ビュー・サイトの構成ウィザードを使用できます。
|
関連項目: Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用してマテリアライズド・ビュー・サイトを設定する方法の詳細は、アドバンスト・レプリケーション・インタフェースのオンライン・ヘルプを参照してください。 |
レプリケーション・マネージメントAPI: Enterprise Managerのアドバンスト・レプリケーション・インタフェースでリモート・マテリアライズド・ビュー・サイトに接続できない場合は、レプリケーション・マネージメントAPIを使用してマテリアライズド・ビュー・サイトを設定します。マテリアライズド・ビュー・サイトを設定するAPIコールを含むSQLスクリプトを作成するときに、その他の準備作業(必要なスキーマ、データベース・リンク、ロールバック・セグメントの作成など、次の3つの項で説明する作業)を実行するためのDDLとAPIコールも追加できます。作成したスクリプトは、オフライン・インスタンシエーション・ファイルとともに配布し、オフライン・インスタンシエーション・ファイルよりも前に実行する必要があります。
|
関連項目: レプリケーション・マネージメントAPIを使用してマテリアライズド・ビュー・サイトを設定する方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。 |
インスタンス化するデプロイメント・テンプレートで複数のスキーマにオブジェクトが作成される場合は、必要なスキーマがすべて作成済であることを確認する必要があります。また、デプロイメント・テンプレートをインスタンス化するユーザーは、そのスキーマに対する適切なCREATE権限を持っている必要があります。たとえば、デプロイメント・テンプレートでスキーマoeにプロシージャを作成し、ユーザーhrがこのテンプレートをインスタンス化する場合、hrにはスキーマoeに対するCREATE ANY PROCEDURE権限が必要です。
リモート・マテリアライズド・ビュー・サイト用に必要なすべてのデータベース・リンクを作成するDDLをデプロイメント・テンプレートに含めると便利ですが、必ずしもそうする必要はありません。データベース・リンクDDLがデプロイメント・テンプレートに含まれていない場合は、デプロイメント・テンプレートをインスタンス化する前に、ターゲット・マスター・サイトへのデータベース・リンクを手動で作成します。データベース・リンクは、オンライン・インスタンシエーション時にマテリアライズド・ビューにデータを移入したり、マテリアライズド・ビュー環境を適切にメンテナンスするために必要です。
デプロイメント・テンプレートをマテリアライズド・ビュー・サイトでインスタンス化するときは、オンライン・インスタンシエーションまたはオフライン・インスタンシエーションのいずれかを選択できます。オンライン・インスタンシエーションでは、マテリアライズド・ビューのデータはインスタンス化時にマスター・サイトからプルされます。オフライン・インスタンシエーションでは、マテリアライズド・ビューのデータはテンプレート自体にパッケージ化されており、テンプレートをインスタンス化するときにローカルで適用されます。一般的に、マテリアライズド・ビューに大量のデータが含まれている場合は、オフライン・インスタンシエーションの方がネットワーク・リソースの使用率を最小化できます。
インスタンス化しているデプロイメント・テンプレートで、現在リモート・マテリアライズド・ビュー・サイトに存在しない特定のロールバック・セグメントを使用する場合は、必要なロールバック・セグメントを作成します。テンプレート・オブジェクトがデフォルトのロールバック・セグメントと特定のロールバック・セグメントのうちのどちらを使用しているのかを確認するには、DBA_REPCAT_TEMPLATE_OBJECTSデータ・ディクショナリ・ビューを問い合せます。
|
関連項目: レプリケーションに関係するデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。 |
非同期のマルチマスター・レプリケーション環境および更新可能マテリアライズド・ビュー・レプリケーション環境では、たとえば異なるサイトから発行された2つのトランザクションがほぼ同時に同じ行を更新する場合などに発生するレプリケーション競合に対処する必要があります。可能なかぎり、競合の発生を回避できるようにレプリケーション環境を計画してください。レプリケーション環境でデータ競合が発生した場合は、ビジネス・ルールに従って競合を解消し、すべてのサイトでデータを適正に収束することを保証するメカニズムが必要です。
セキュリティは、マルチマスター・レプリケーション環境およびマテリアライズド・ビュー・レプリケーション環境のどちらの環境でも重要な課題です。レプリケーション環境を構成する場合、まずセキュリティ対策を講じる必要があります。
|
関連項目: レプリケーション環境でのセキュリティ・オプションの詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。 |
耐障害性機能とは、システムまたはサイトの障害時にもアプリケーションを継続して実行できる機能です。また、アプリケーションをフェイルオーバー・システム上で実行でき、障害発生時にプライマリ・システム上でアクセスしていたのと同じか、またはほとんど同じデータにアクセスできます。図6-3に示されているように、Oracleサーバーではマルチマスター・レプリケーションとOracle Real Application Clusters (Oracle RAC)という、耐障害性を実現する2つのテクノロジを提供しています。
図6-3 耐障害性を実現するための方法: レプリケーションまたはOracle Real Application Clusters
Oracle Real Application Clusters (Oracle RAC)は、Oracleサーバーのインスタンスをサポートするシステムに障害が発生したときに、システムの耐障害性を確保するフェイルオーバーをサポートしています。Oracle RACには、クラスタまたは大規模パラレル・ハードウェア・プラットフォームが必要なため、クラスタまたは大規模パラレル・システムが稼働しているローカル環境での処理システムを障害から保護する場合に適しています。
このような環境では、Oracle RACは耐障害性を実現するための理想的なソリューションで、大量のトランザクションをサポートしており、インスタンス障害が発生した場合でもトランザクションの消失やデータの不整合が発生することがありません。Oracle RAC環境では、1つのインスタンスで障害が発生しても、他の正常なインスタンスによって未完了のトランザクションが自動的にリカバリされます。障害が発生したシステムで実行されていたアプリケーションはフェイルオーバー・システムで実行でき、データベースのすべてのデータにアクセスできます。
ただし、Oracle RACには、サイト全体におよぶ障害(停電、洪水、火事、破壊行為など)によってクラスタまたは大規模パラレル・システム全体が操作不能になるような状況に対しては耐障害性がありません。サイト障害に対して耐障害性を確保するために、マルチマスター・レプリケーションを使用して、地理的に離れた場所でデータベースのレプリカをメンテナンスできます。さらに、マルチマスター・レプリケーションを使用すると、異なるオペレーティング・システムまたはOracleの異なるリリース(あるいはその両方)が稼働するサイト間でデータをレプリケートできます。
ローカル・システムに障害が発生しても、アプリケーションはリモート・サイトで実行を継続できます。マルチマスター・レプリケーションを使用する場合は、障害サイトでのトランザクションのリカバリと、障害サイトを再開したときのデータの非一貫性を防ぐために、なんらかの管理手順が必要になることがあります。
|
注意: スタンバイ・データベースを構成して、Oracle Databaseをサイト障害から守ることもできます。 |
|
関連項目:
|
耐障害性を実現するためにレプリケーション機能を使用する場合は、次の事項を考慮してください。
レプリケーション機能によって、プライマリ・システムと同じ量のトランザクションを処理できる必要があります。
プライマリ・サイトで障害が発生した場合、プライマリ・サイトで少し前にコミットされたトランザクションは、フェイルオーバー・サイトにまだ非同期に伝播されていない可能性があります。このトランザクションは消失したように見えます。
この消失したトランザクションは、プライマリ・サイトがリカバリされたときに処理する必要があります。
たとえば、リモートのフェイルオーバー・サイトのメンテナンスにレプリケーションを使用する受注入力システムにおいて、システムの実行時にプライマリ・システムで障害が発生したとします。
障害発生時、少し前にプライマリ・サイトで実行された2つのトランザクションの変更は、フェイルオーバー・サイトに伝播および適用させていません。最初のトランザクションは新規の受注の入力で、2番目のトランザクションは既存の受注の取消しです。
新規受注入力の場合、フェイルオーバー・システムでの処理の継続中にその受注が存在しないことが発見されると、再入力されると考えられます。既存の受注の取消しの場合は、受注の取消しは発見されずに、受注処理が継続されると考えられます(つまり、取り消された商品が出荷されて、顧客に請求が送られます)。
プライマリ・サイトがリストアされた場合を考えます。フェイルオーバー・システムで実行されたすべての変更をプライマリ・システムに単に戻すと、競合が発生します。
具体的には、プライマリ・システムに障害が発生する直前に受注された商品に対する注文が重複します。さらに、プライマリ・システムでは取り消されているはずの受注の出荷および請求トランザクションにより、データが変更されます。
こうした状況に対処するには、システムを綿密に設計する必要があります。次の項では、このプロセスについて説明します。
アドバンスト・レプリケーションでは、レプリケートされた複数のマスター・サイトを使用してサイト障害に対する耐障害性を提供しています。実装の最も容易な方法から順番にリストした次の方法のいずれかを使用してシステムを構成する必要があります。
フェイルオーバー・サイトは読取りアクセス専用で使用します。つまり、プライマリ・サイトで障害が発生した場合でも、フェイルオーバー・サイトでは更新できません。
障害の後、プライマリ・サイトは、エクスポートおよびインポート、または全体バックアップによって、フェイルオーバー・サイトからリストアされます。
すべてのデータおよびトランザクションでは、競合を完全に解消します。このためには、綿密な設計および実現が必要です。重複トランザクションなど、プライマリ・サイトがリストアしたときに発生する競合を、適切かつ確実に解消する必要があります。
アプリケーション・レベルのルーチンやプロシージャを独自に作成して、プライマリ・サイトがリストアされたとき、およびアクティブなフェイルオーバー・システムでキューに入れられていたトランザクションがプライマリ・サイトに伝播および適用されたときに発生するデータの不整合を処理します。
Oracle Netを使用すると、接続時に自動的に起動されるフェイルオーバーを構成でき、この機能により、最初のマスター・サイトに障害が発生した場合、Oracle Netは別のマスター・サイトに接続を切り替えることができます。自動的な接続時フェイルオーバーを構成するには、tnsnames.oraファイルでFAILOVERオプションをonに設定し、複数の接続記述子を指定します。
|
関連項目: 接続時フェイルオーバーの構成方法の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。 |
レプリケーション環境のマスター・サイトであるデータベースをリカバリすると、レプリケート・データの一貫性が失われてレプリケーション・エラーが発生することがあります。たとえば、リストアされたマスター・サイトが別のマスター・サイトに異なるトランザクションを伝播していることがあります。場合によっては、不正確なリカバリ操作を修正するために、追加の手順を実行する必要があります。その方法の1つは、リカバリしたデータベース内のすべてのレプリケート・オブジェクトを削除し、再作成する方法です。
レプリケート・オブジェクトの削除および再作成を実行する前に、リストアしたデータベースから保留中の遅延トランザクションおよび遅延エラー・レコードを削除し、未解決の分散トランザクションを解決してください。リストアされたデータベースがいくつかのレプリケーション環境のマスター定義サイトであった場合、オブジェクトを削除および作成する前に新しいマスター定義サイトを設定する必要があります。リストアされたデータベースがマスターであるマテリアライズド・ビュー、およびリストアされたデータベース内のマテリアライズド・ビューは、完全リフレッシュを行う必要があります。
データに対する継続的なアクセスを可能にするため、マスター定義サイトの変更(リストアされるデータベースがマスター定義サイトであった場合)、またはマテリアライズド・ビュー・サイトのマスター・サイトの変更(それらのマスター・サイトがリストアされている場合)が必要な場合があります。
レプリケート・オブジェクトやアドバンスト・レプリケーションで使用するオブジェクト(DBA_REPSITESデータ・ディクショナリ・ビューなど)のエクスポートおよびインポートを実行した後は、DBMS_REPCATパッケージのREPCAT_IMPORT_CHECKプロシージャを実行する必要があります。
次の例では、このプロシージャを使用して、マテリアライズド・ビュー・サイトのhr_repgレプリケーション・グループのオブジェクトをチェックして、オブジェクト識別子とステータス値が適切であることを確認します。
BEGIN
DBMS_REPCAT.REPCAT_IMPORT_CHECK( gname => 'hr_repg',
master => FALSE);
END;
/
|
関連項目: 『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』のREPCAT_IMPORT_CHECKプロシージャを参照してください。 |
