ヘッダーをスキップ
Oracle® Databaseデータ・ウェアハウス・ガイド
11gリリース2 (11.2)
B56309-04
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

17 チェンジ・データ・キャプチャ

チェンジ・データ・キャプチャでは、Oracleのリレーショナル表に対して追加、更新または削除されたデータを効率的に識別およびキャプチャし、アプリケーションやユーザーがこの変更データを使用できるようにします。


注意:

Oracle Change Data CaptureはOracle Databaseの今後のリリースでサポートされなくなり、Oracle GoldenGateに置き換わる予定です。そのため、新しいアプリケーションには、Oracle GoldenGateを使用することを強くお薦めします。

Oracle Database 11gリリース2(11.2)では、チェンジ・データ・キャプチャは引き続きこれまでのリリースのように機能します。現在チェンジ・データ・キャプチャを使用している場合、当面は使用し続けることができます。しかし、今後チェンジ・データ・キャプチャに機能強化は行われず、マニュアルに記載された、現在の機能に基づいてサポートされるだけになる予定です。


この章では、チェンジ・データ・キャプチャについて説明します。内容は次のとおりです。

チェンジ・データ・キャプチャのパブリッシュおよびサブスクライブPL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

チェンジ・データ・キャプチャの概要

データ・ウェアハウスでは、1つ以上の本番データベースからリレーショナル・データを抽出し、分析のためにデータ・ウェアハウスに転送することが必要になることがよくあります。チェンジ・データ・キャプチャは、変更があったデータのみを瞬時に識別して処理し、変更データをさらに利用できるようにします。

チェンジ・データ・キャプチャを使用しない変更データのキャプチャ

チェンジ・データ・キャプチャが導入される前は、変更データをキャプチャする方法として、表区別および変更値選択などいくつかの方法がありました。

表区別では、ソース(本番)データベースから、古いバージョンの表が存在している(変更データがキャプチャされる)ステージング・データベースへ表全体のコピーを転送します。SQLのMINUS演算子を次のような問合せで使用すると、挿入済の行および更新済の行の新しいバージョンを取得できます。

SELECT * FROM new_version 
MINUS SELECT * FROM old_version;

次のような問合せでは、削除済の行および更新済の行の古いバージョンも取得できます。

SELECT * FROM old_version 
MINUS SELECT * FROM new_version;

ただし、この方法には次のような問題点があります。

  • 変更データのみでなく、表全体の新しいバージョンをステージング・データベースに転送する必要があるので、転送コストが大幅に増加します。

  • ステージング・データベース上で2つのMINUS演算を実行する計算コストが非常に高くなる可能性があります。

  • 表区別では、古い値に戻ったデータはキャプチャできません。たとえば、製品表の古いバージョンと新しいバージョンの間で製品の価格を何回か変更したとします。新しいバージョンにおける価格が古いバージョンにおける価格と最終的に同じになった場合、表区別では、その価格が変動したことを検出できません。製品表の古いバージョンから新しいバージョンにいたる中間の価格値も、表区別ではキャプチャできません。

  • どの変更が同じトランザクションの一部として行われたかを判断する方法がありません。たとえば、営業部長が取引をまとめるために特別な値引きを作成するとします。値引きおよび売上の作成が同じトランザクションの一部として発生したファクトは、ソース・データベースをそうした目的で特別に設計していないかぎり、キャプチャできません。

変更値選択では、特定の列の値に基づいてソース・テーブルから新しいデータおよび変更済のデータを選択することによって、ソース・データベース上のデータをキャプチャします。たとえば、ソース・テーブルにLAST_UPDATE_DATEという列があるとします。変更をキャプチャするには、LAST_UPDATE_DATE列の値を基準にしてソース・テーブルからの選択を行います。

ただし、この方法にも次のような制限があります。

  • 変更データをキャプチャするオーバーヘッドはソース・データベース上で負担する必要があり、コストが高くなる可能性のある問合せを、ソース・データベース上のソース・テーブルに対して実行する必要があります。これらの問合せが必要となることで、本来必要ではない索引を追加しなければならない場合があります。このオーバーヘッドをステージング・データベースにオフロードする方法はありません。

  • この方法は、中間値のキャプチャにおいて表区別法と大差ありません。製品表の価格が変動する場合、中間の値をすべてキャプチャできないばかりか、価格が変更されたかどうかや、終了値が、前回変更データをキャプチャした際と同じかどうかを判別できません。

  • この方法は、どのデータ変更が同じトランザクション内で一緒に行われたのかをキャプチャする点についても、表区別法と大差ありません。同じトランザクション内で一緒に発生した変更に関する情報をキャプチャする必要がある場合は、ソース・データベースをこの目的で特別に設計する必要があります。

  • 変更値列の詳細度が、新しい行および変更済の行を一意に識別するのに十分な細かさでない場合があります。たとえば、次のように仮定します。

    • LAST_UPDATE_DATEなどの日付列で変更値選択を使用してデータ変更をキャプチャする。

    • キャプチャは、特定の瞬間(2003年2月14日17時10分00秒)に実行される。

    • キャプチャを実行した同時刻に表に追加の更新が発生する。

    次にデータ変更をキャプチャする際は、2003年2月14日17時10分00秒直後のLAST_UPDATE_DATEで行を選択するので、その秒の残りの間に発生した変更を見逃すことになります。

    変更値選択を使用するには、この例外を受け入れるか、必要な詳細度の変更値列を人為的に追加するか、キャプチャ処理中のソース・テーブルへの変更をロックアウトする必要がありますが、これによって、ソース・データベースのパフォーマンスがさらに低下することになります。

  • 変更データのキャプチャ元であるすべての表が変更値列を持つ必要があることを考慮して、あらかじめ、このキャプチャ・メカニズムでソース・データベースを設計する必要があります。レガシー・システムのデータソースでデータ・ウェアハウスを構築する場合、それらのレガシー・システムでは、必要とする変更値列が提供されない場合があります。

チェンジ・データ・キャプチャは、コストが高く扱いにくい表区別や変更値選択メカニズムに依存しません。そうしたメカニズムに依存することなく、ユーザー表に対して行ったINSERTUPDATEおよびDELETE操作で生成された変更データをキャプチャします。この変更データはチェンジ・テーブルと呼ばれるリレーショナル表に格納され、制御された方法でアプリケーションやユーザーによって使用できるようになります。

チェンジ・データ・キャプチャを使用した変更データのキャプチャ

チェンジ・データ・キャプチャは、次のいずれかのモードでコミット済の変更データをキャプチャおよび公開できます。

  • 同期

    変更データは、データ操作言語(DML)操作(INSERTUPDATEまたはDELETE)を行う各SQL文が実行されると、ソース・データベースのトリガーによってすぐにキャプチャされます。このモードでは、変更データは、ソース・テーブルを変更するトランザクションの一部としてキャプチャされます。同期チェンジ・データ・キャプチャは、OracleのStandard EditionおよびEnterprise Editionで使用できます。このモードの詳細は、「同期チェンジ・データ・キャプチャ」を参照してください。

  • 非同期

    変更データは、REDOログ・ファイルに送られたデータを利用することによって、DML操作を実行するSQL文がコミットされた後にキャプチャされます。このモードでは、変更データは、ソース・テーブルを変更するトランザクションの一部としてキャプチャされないので、トランザクションに影響を与えません。

    非同期チェンジ・データ・キャプチャには、HotLog、分散HotLogおよびAutoLogの3つのモードがあります。これらのモードの詳細は、「非同期チェンジ・データ・キャプチャ」を参照してください。

    非同期チェンジ・データ・キャプチャは、Oracle Streamsに対して構築され、リレーショナル・インタフェースを提供します。Oracle Streamsの詳細は、『Oracle Streams概要および管理』を参照してください。

チェンジ・データ・キャプチャを使用して変更データをキャプチャするメリットとして、次のようなことがあげられます。

  • 完全性

    チェンジ・データ・キャプチャは、UPDATE操作前後のデータ値を含む、INSERTUPDATEおよびDELETE操作のすべての結果をキャプチャできます。

  • パフォーマンス

    非同期チェンジ・データ・キャプチャは、ソース・データベースに対するパフォーマンスの影響が最小となるように構成できます。

  • インタフェース

    チェンジ・データ・キャプチャには、パブリッシュやサブスクライブを簡単に実行できるインタフェースとなるDBMS_CDC_PUBLISHパッケージとDBMS_CDC_SUBSCRIBEパッケージがあります。

  • コスト

    チェンジ・データ・キャプチャは、データベースからの変更データの抽出を簡素化し、また、Oracle Databaseの一部でもあるため、オーバーヘッド・コストを軽減します。

同期チェンジ・データ・キャプチャのソース・テーブルとして、透過的なデータ暗号化を使用する表は使用できません。非同期チェンジ・データ・キャプチャについては、ソース・データベースとステージング・データベースの両方でCOMPATIBLEが11以上に設定されている場合は透過的なデータ暗号化をサポートします。チェンジ・データ・キャプチャでは、チェンジ・テーブル内のデータの暗号化は行われません。チェンジ・テーブルの列を暗号化するには、ALTER TABLE文を使用してユーザーが手動で暗号化します。Oracle Streamsの詳細は、『Oracle Streams概要および管理』を参照してください。

チェンジ・データ・キャプチャ・システムでは、パブリッシャとサブスクライバの相互作用に基づいて変更データがキャプチャされ、配布されます。次の項を参照してください。

パブリッシュおよびサブスクライブのモデル

ほとんどのチェンジ・データ・キャプチャ・システムでは、1人のパブリッシャが変更データをキャプチャして公開します。変更データには、複数のサブスクライバ(アプリケーションやユーザー)がアクセスする場合があります。チェンジ・データ・キャプチャには、パブリッシュおよびサブスクライブ・タスクのためにPL/SQLパッケージが用意されています。

次の項では、パブリッシャおよびサブスクライバの役割を詳細に説明します。後続の項では、チェンジ・ソース、チェンジ・データ・キャプチャのモードの詳細、およびチェンジ・テーブルについて説明します。

パブリッシャ

通常、パブリッシャは、チェンジ・データ・キャプチャ・システムを構成するスキーマ・オブジェクトの作成とメンテナンスを行うデータベース管理者(DBA)です。通常、分散HotLogを除くチェンジ・データ・キャプチャのすべてのモードでは、ステージング・データベースに1人のパブリッシャが存在します。チェンジ・データ・キャプチャの分散HotLogモードでは、ソース・データベースおよびステージング・データベースに1人のパブリッシャが定義されている必要があります。次のリストでは、ソース・データベース、ステージング・データベース、およびチェンジ・データ・キャプチャに必要なそれぞれのデータベースのオブジェクトについて説明します。

  • ソース・データベース

    これは、対象データが格納されている本番データベースです。チェンジ・データ・キャプチャに必要な次のオブジェクトは、ソース・データベースにあります。

    • ソース・テーブル

      ソース・テーブルは対象データが格納されている本番データベースの表です。ソース・データベースのすべての表、または表のサブセットです。

    • REDOログ・ファイル

      チェンジ・データ・キャプチャの非同期モードでは、変更データは、オンラインREDOログ・ファイルまたはアーカイブREDOログ・ファイル(またはその両方)から収集されます。非同期AutoLogモードでは、アーカイブREDOログ・ファイルは、ソース・データベースからステージング・データベースにコピーされます。

    • チェンジ・ソース

      チェンジ・ソースは、ソース・データベースの論理表現です。ソースを表す方法は、チェンジ・データ・キャプチャのモードによって異なります。

      チェンジ・ソースは、チェンジ・データ・キャプチャの非同期分散HotLogモードにおいてのみ、ソース・データベースにあります。チェンジ・データ・キャプチャのその他のモードでは、チェンジ・ソースはステージング・データベースにあります。

      分散HotLogチェンジ・ソースの詳細は、「非同期分散HotLogモード」を参照してください。

  • ステージング・データベース

    これは、キャプチャした変更データが適用されるデータベースです。パブリッシャが使用するキャプチャ・モードに応じて、ステージング・データベースは、ソース・データベースと同じ場合もあれば、異なる場合もあります。次のチェンジ・データ・キャプチャ・オブジェクトは、ステージング・データベースにあります。

    • チェンジ・テーブル

      チェンジ・テーブルは、単一のソース・テーブルの変更データがロードされるリレーショナル表です。サブスクライバに対して、チェンジ・テーブルはパブリケーションとして知られています。

    • チェンジ・セット

      チェンジ・セットは、トランザクション一貫性が保証される変更データのセットです。これには、1つ以上のチェンジ・テーブルが含まれます。

    • チェンジ・ソース

      チェンジ・ソースは、チェンジ・データ・キャプチャの次のモードでは、ステージング・データベースにあります。

次に、パブリッシャが実行する主なタスクを示します。

  • サブスクライバが変更データを参照するために必要なソース・データベースとソース・テーブル、および変更データをキャプチャするモード(同期またはいずれかの非同期モード)を判断します。

  • オラクル社が提供するパッケージDBMS_CDC_PUBLISHを使用して、対象のソース・テーブルから変更データをキャプチャするようにシステムをセットアップします。

  • SQL文のGRANTおよびREVOKEを使用して、ユーザーやロールに対してチェンジ・テーブルへのSELECT権限の付与および取消しを行うことで、サブスクライバにチェンジ・テーブル内の変更データへの制御付きのアクセスを許可します。ただし、サブスクライバが変更データにアクセスするには、チェンジ・テーブルを直接使用するのではなく、ビューを使用することに注意してください。

図17-1では、パブリッシャは、サブスクライバがHQソース・データベースの変更データを参照する必要があることを判断します。特に、サブスクライバが必要なのは、sh.salesおよびsh.promotionsソース・テーブルの変更データです。

パブリッシャは、変更データのキャプチャに非同期AutoLogモードを使用することを決定します。パブリッシャは、DWステージング・データベース上に、1つのチェンジ・ソースHQ_SRC、1つのチェンジ・セットSH_SET、およびsales_ctpromo_ctの2つのチェンジ・テーブルを作成します。sales_ctチェンジ・テーブルには、ソース・テーブルsh.salesの列がすべて含まれます。一方、promo_ctチェンジ・テーブルについては、パブリッシャはPROMO_COST列を除外することにしました。

図17-1 チェンジ・データ・キャプチャ・システムのパブリッシャ・コンポーネント

図17-1の説明は図の下のリンクをクリックしてください。
「図17-1 チェンジ・データ・キャプチャ・システムのパブリッシャ・コンポーネント」の説明

サブスクライバ

サブスクライバは、パブリッシュされた変更データのコンシューマです。サブスクライバはまた、次のタスクを実行します。

  • オラクル社が提供するパッケージDBMS_CDC_SUBSCRIBEを次の目的に使用します。

    • サブスクリプションの作成

      サブスクリプションは、単一チェンジ・セット内の1つ以上の対象ソース・テーブルの変更データに対するアクセスを制御します。サブスクリプションには1つ以上のサブスクライバ・ビューが含まれます。

      サブスクライバ・ビューは、サブスクリプションにおける特定のパブリケーションからの変更データを指定するビューです。サブスクライバは、パブリッシャが公開し、使用するアクセス権がサブスクライバに付与された変更データの参照において制限を受けます。サブスクライバ・ビューを指定する方法の選択に関する詳細は、「変更データのサブスクライブ」を参照してください。

    • 変更データのセットを受け取る準備ができた時点でのチェンジ・データ・キャプチャへの通知

      サブスクリプション・ウィンドウでは、サブスクライバ・ビューでサブスクライバが現在参照できるパブリケーションの行のタイム・レンジが定義されます。サブスプリクション・ウィンドウ内の最も古い行が低位限界と呼ばれ、最も新しい行が高位限界と呼ばれます。各サブスクリプションは、そのサブスクライバ・ビューすべてに適用される独自のサブスクリプション・ウィンドウを持ちます。

    • 変更データのセットに関する作業が完了した時点でのチェンジ・データ・キャプチャへの通知

  • SELECT文を使用して、サブスクライバ・ビューから変更データを取り出します。

サブスクライバは、サブスクライバが実行されているユーザー・アカウントの権限、およびサブスクライバに付与されているすべての追加の権限を所有しています。

図17-2において、サブスクライバが必要なのは、図17-1のパブリッシャが公開している列のサブセットです。図17-2に示されているパブリケーションは、図17-1ではチェンジ・テーブルとして表されていることに注意してください。これは、サブスクライバとパブリッシャそれぞれで使用される用語が異なることによるものです。

サブスクライバは、サブスクリプションsales_promos_listおよび2つのサブスクライバ・ビュー(spl_salesspl_promos)を、DWステージング・データベース上のSH_SETチェンジ・セットに作成します。各サブスクライバ・ビュー内に、サブスクライバは、パブリッシャによって使用可能とされた列のサブセットを含めます。パブリッシャがPROMO_COST列を含むチェンジ・テーブルを作成しなかったため、サブスクライバはその列の変更データを参照できません。サブスクライバは、パブリッシャが設定したチェンジ・データ・キャプチャのモードを認識する必要はありません。

図17-2 チェンジ・データ・キャプチャ・システムのサブスクライバ・コンポーネント

図17-2の説明は図の下のリンクをクリックしてください。
「図17-2 チェンジ・データ・キャプチャ・システムのサブスクライバ・コンポーネント」の説明

サブスクライバにとって、チェンジ・データ・キャプチャは次のような利点があります。

  • 各サブスクライバは、すべての変更の参照が保証されます。

  • 複数のサブスクライバが追跡され、各サブスクライバには変更データへの共有アクセス権が付与されます。

  • すべてのサブスクライバに不要になったデータがチェンジ・テーブルから自動的に削除されることによって、すべての記憶域管理が処理されます。チェンジ・データ・キャプチャは、パージ処理のために、24時間に1回実行されるジョブ・キューのジョブを開始します。このジョブでは多くの不具合が発生する可能性があるため(ジョブが削除されたり、スケジュールが変更される場合など)、この自動処理は、開始および実行されているジョブ・キュー・プロセス、および、存在しているチェンジ・データ・キャプチャのジョブに依存します。また、ロジカル・スタンバイ環境では、パージ・ジョブは実行されません。


    注意:

    Oracleでは、サブスクライバがサブスクライバ・ビューを介して変更データにアクセスする際にのみ、これらの利点が提供されます。

チェンジ・ソースとチェンジ・データ・キャプチャのモード

チェンジ・データ・キャプチャには、変更データのキャプチャ用に同期モードと非同期モードがあります。次の項では、チェンジ・データ・キャプチャの各モードがどのように実行されるか、およびチェンジ・データ・キャプチャの各モードに関連付けられたチェンジ・ソースの概要について説明します。

同期チェンジ・データ・キャプチャ

同期モードでは、変更データのキャプチャにソース・データベースのトリガーが使用されます。このモードでは、変更データがソース・データベース上で継続的にリアルタイムでキャプチャされるため、待機時間がありません。チェンジ・テーブルは、ソース・テーブルでDML操作がコミットされた際に移入されます。

ソース・データベースを表す、事前定義の同期チェンジ・ソースSYNC_SOURCEが1つあります。これは唯一の同期チェンジ・ソースです。変更や削除はできません。

チェンジ・データ・キャプチャの同期モードでは、キャプチャ時にソース・データベースのオーバーヘッドが増加しますが、変更データの抽出の簡素化により(表区別や変更値選択を使用して変更データを抽出するのと比較して)コストを削減できます。

チェンジ・データ・キャプチャのこのモードのチェンジ・テーブルは、ソース・データベースにローカルに存在する必要があります。

図17-3に、同期モードの構成を示します。ソース・テーブルで発生したDML操作の後に実行されたトリガーによって、SYNC_SOURCEチェンジ・ソース内のチェンジ・セットにチェンジ・テーブルが移入されます。

図17-3 同期チェンジ・データ・キャプチャ構成

図17-3の説明は図の下のリンクをクリックしてください。
「図17-3 同期チェンジ・データ・キャプチャ構成」の説明

非同期チェンジ・データ・キャプチャ

非同期モードでは、変更がソース・データベースに対してコミットされた後にデータベースのREDOログ・ファイルから変更データがキャプチャされます。

チェンジ・データ・キャプチャの非同期モードは、ソース・データベースで有効化されたサプリメンタル・ロギングのレベルに依存します。サプリメンタル・ロギングによって、ソース・データベースでREDOロギングのオーバーヘッドが増加するので、チェンジ・データ・キャプチャを使用するアプリケーションやユーザーのニーズと注意深くバランスを取る必要があります。サプリメンタル・ロギングの詳細は、「非同期チェンジ・データ・キャプチャとサプリメンタル・ロギング」を参照してください。

以降の項では、変更データのキャプチャにおける次の3つのモードについて説明します。

非同期HotLogモード

非同期HotLogモードでは、変更データは、ソース・データベース上のオンラインREDOログ・ファイルからキャプチャされます。ソース・テーブル・トランザクションのコミット操作から変更データの取得までの間にはわずかな待機時間があります。

ソース・データベースの現在のオンラインREDOログ・ファイルを表す、事前定義のHotLogチェンジ・ソースHOTLOG_SOURCEが1つあります。これは唯一のHotLogチェンジ・ソースです。変更や削除はできません。

チェンジ・データ・キャプチャのこのモードのチェンジ・テーブルは、ソース・データベースにローカルに存在する必要があります。

図17-4に、非同期HotLogモードの構成を示します。コミット済トランザクションは、ログ・ライター・プロセス(LGWR)によって、ソース・データベース上のオンラインREDOログ・ファイルに記録されます。チェンジ・データ・キャプチャでは、トランザクションが新たにコミットされると、Oracle Streamsプロセスが使用され、HOTLOG_SOURCEチェンジ・ソース内のチェンジ・セットにチェンジ・テーブルが自動的に移入されます。

図17-4 非同期HotLog構成

図17-4の説明は図の下のリンクをクリックしてください。
「図17-4 非同期HotLog構成」の説明

非同期分散HotLogモード

非同期分散HotLogモードでは、変更データは、ソース・データベース上のオンラインREDOログ・ファイルからキャプチャされます。

事前定義の分散HotLogチェンジ・ソースはありません。分散HotLogモードでは、チェンジ・データ・キャプチャの他のモードとは異なり、ソース・データベースとステージング・データベースにまたがって、チェンジ・データ・キャプチャのアクティビティおよびオブジェクトが分散されます。チェンジ・ソースは、ステージング・データベースのパブリッシャによってソース・データベース上に定義されます。

分散HotLogチェンジ・ソースは、ソース・データベースの現在のオンラインREDOログ・ファイルを表します。ただし、ステージング・データベースのパブリッシャは、それぞれ異なるステージング・データベースのチェンジ・セットを含む分散HotLogチェンジ・ソースを複数定義できます。ソース・データベースおよびステージング・データベースは、異なるハードウェアのプラットフォーム上に配置でき、異なるオペレーティング・システム上で動作できますが、これにはいくつかの制限が適用されます。これらの制限については、「サポートされる分散HotLog構成および制限の概要」を参照してください。

図17-5に、非同期分散HotLogモードの構成を示します。ソース・データベース上のチェンジ・ソースは、オンラインREDOログ・ファイルから変更データをキャプチャし、Oracle Streamsを使用して、その変更データをステージング・データベース上のチェンジ・セットに伝播します。ステージング・データベースのチェンジ・セットは、チェンジ・セット内にチェンジ・テーブルを移入します。

チェンジ・データ・キャプチャのこのモードでは、2人(ソース・データベースとステージング・データベースに各1人ずつ)のパブリッシャが必要となります。ソース・データベースのパブリッシャは、ステージング・データベースのパブリッシャとしてステージング・データベースに接続するソース・データベースのデータベース・リンクを定義します。ステージング・データベースのパブリッシャは、ソース・データベースのパブリッシャとしてソース・データベースに接続するステージング・データベースのデータベース・リンクを定義します。公開操作はすべて、ステージング・データベースのパブリッシャが実行します。詳細は、「非同期分散HotLogの公開の実行」を参照してください。

図17-5 非同期分散HotLog構成

図17-5の説明は図の下のリンクをクリックしてください。
「図17-5 非同期分散HotLog構成」の説明

非同期AutoLogモード

非同期AutoLogモードでは、変更データは、REDO転送サービスによって管理されるREDOログ・ファイルのセットからキャプチャされます。REDO転送サービスは、ソース・データベースからステージング・データベースへのREDOログ・ファイルの自動転送を制御します。パブリッシャは、データベース初期化パラメータ(「非同期AutoLogの公開用初期化パラメータ」を参照)を使用して、REDOログ・ファイルがソース・データベース・システムからステージング・データベース・システムにコピーされ、自動的に登録されるようにREDO転送サービスを構成します。非同期AutoLogモードでは、ソース・データベースのオンラインREDOログかアーカイブREDOログのいずれかから変更データを取得できます。これらのオプションは、非同期AutoLogオンラインおよび非同期AutoLogアーカイブと呼ばれます。AutoLogオンライン・オプションを指定すると、ソース・データベースのオンラインREDOログから、ステージング・データベースのスタンバイREDOログにREDOデータをコピーするようにREDO転送サービスが設定されます。この場合、チェンジ・セットは、個々のソース・データベースのトランザクションのコミット後に移入されます。任意のステージング・データベースにはAutoLogオンライン・チェンジ・ソースを1つのみ含めることができ、チェンジ・セットを1つのみ含めることができます。AutoLogアーカイブ・オプションを指定すると、ソース・データベースからステージング・データベースにアーカイブREDOログがコピーされるようにREDO転送サービスが設定されます。この場合、チェンジ・セットは、新しいアーカイブREDOログ・ファイルがステージング・データベースに届くと移入されます。待機時間の程度は、ソース・データベース上のREDOログ・ファイルのスイッチの頻度に依存します。AutoLogアーカイブ・オプションは、AutoLogオンライン・オプションよりも待機時間の程度が大きくなりますが、任意のステージング・データベースには必要な数のAutoLogアーカイブ・チェンジ・ソースを含めることができます。

事前定義のAutoLogチェンジ・ソースはありません。AutoLogチェンジ・ソースを作成するソース・データベースに関する情報は、パブリッシャによって提供されます。詳細は、「非同期AutoLogの公開の実行」を参照してください。

図17-6は、チェンジ・データ・キャプチャの非同期AutoLogオンライン構成を示しています。この構成では、ソース・データベース上のLGWRプロセスによって、LOG_ARCHIVE_DEST_2パラメータで指定されているように、ソース・データベースのオンラインREDOログ・ファイルおよびステージング・データベースのスタンバイREDOログ・ファイルの両方にREDOデータがコピーされます。図では、このパラメータをLOG_ARCHIVE_DEST_2として示していますが、この整数値には、1から10の間の任意の値を指定できます。

LGWRプロセスはOracle Netを使用して、REDOデータをネットワークからリモート・ファイル・サーバー(RFS)プロセスに送信することに注意してください。REDOデータをリモートの宛先に送信するには、Oracle Netを介した途切れることのない接続性が必要となります。

ステージング・データベースでは、RFSプロセスによって、REDOデータがスタンバイREDOログ・ファイルに書き込まれます。次に、チェンジ・データ・キャプチャは、Oracle Streamsのダウンストリーム・キャプチャを使用して、AutoLogチェンジ・ソース内のチェンジ・セットにチェンジ・テーブルを移入します。

ソース・データベースとステージング・データベースが動作するハードウェア、オペレーティング・システム、およびOracleバージョンは同じである必要があります。

図17-6 非同期Autologオンライン・チェンジ・データ・キャプチャ構成

図17-6の説明は図の下のリンクをクリックしてください。
「図17-6 非同期Autologオンライン・チェンジ・データ・キャプチャ構成」の説明

図17-7は、典型的なチェンジ・データ・キャプチャの非同期AutoLogアーカイブ構成です。この構成では、ソース・データベース上でのREDOログ・ファイル・スイッチ時に、アーカイバ・プロセスによって、ソース・データベース上のREDOログ・ファイルがLOG_ARCHIVE_DEST_1パラメータの指定先にアーカイブされ、LOG_ARCHIVE_DEST_2パラメータで指定したステージング・データベースにコピーされます。図では、これらのパラメータをLOG_ARCHIVE_DEST_1およびLOG_ARCHIVE_DEST_2として示していますが、これらのパラメータ文字列の整数値には、1から10の間の任意の値を指定できます。

アーカイバ・プロセスはOracle Netを使用して、REDOデータをネットワークからリモート・ファイル・サーバー(RFS)プロセスに送信することに注意してください。REDOログ・ファイルをリモートの宛先に送信するには、Oracle Netを介した途切れることのない接続性が必要となります。

ステージング・データベースでは、RFSプロセスによって、REDOデータがコピー済ログ・ファイルに書き込まれます。次に、チェンジ・データ・キャプチャは、Oracle Streamsのダウンストリーム・キャプチャを使用して、AutoLogチェンジ・ソース内のチェンジ・セットにチェンジ・テーブルを移入します。

REDO転送サービスの詳細は、『Oracle Data Guard概要および管理』を参照してください。

図17-7 非同期Autologアーカイブ・チェンジ・データ・キャプチャ構成

図17-7の説明は図の下のリンクをクリックしてください。
「図17-7 非同期Autologアーカイブ・チェンジ・データ・キャプチャ構成」の説明

チェンジ・セット

チェンジ・セットは、トランザクション一貫性が保証され、1単位として管理可能な変更データの論理グループです。チェンジ・セットは、1つの(唯一の)チェンジ・ソースのメンバーです。


注意:

次の条件を満たす場合、チェンジ・データ・キャプチャのチェンジ・ソースに1つ以上のチェンジ・セットを含めることができます。
  1. 分散HotLogチェンジ・ソースのすべてのチェンジ・セットは同じステージング・データベース上に存在する必要がある。

  2. AutoLogオンライン・チェンジ・ソースに含めることができるチェンジ・セットは1つのみである。


パブリッシャが、同じチェンジ・セットに2つ以上のチェンジ・テーブルを含める場合、サブスクライバはチェンジ・セット内で表される表間で結合操作を実行でき、トランザクション一貫性を保証されます。

理論上は、チェンジ・セットは、そのチェンジ・ソースと同じモードを共有します。たとえば、AutoLogチェンジ・セットは、AutoLogチェンジ・ソースに格納されているチェンジ・セットです。パブリッシャは、DBMS_CDC_PUBLISH.CREATE_CHANGE_SETパッケージを使用してチェンジ・セットを定義できます。同期チェンジ・データ・キャプチャの場合、パブリッシャは事前定義のチェンジ・セットSYNC_SETも使用できます。ただし、SYNC_SETチェンジ・セットの変更または削除はできません。

パブリッシャは、チェンジ・セットのチェンジ・テーブルが無制限に大きくならないように、チェンジ・セットのレベルで、チェンジ・テーブルから不要な変更データをパージできます。変更データのパージに関する詳細は、「チェンジ・テーブルの不要なデータのパージ」を参照してください。

チェンジ・ソースとチェンジ・セットの有効な組合せ

表17-1に、チェンジ・ソースとチェンジ・セットの有効な組合せの概要と、それぞれが事前定義かパブリッシャ定義かを示します。また、チェンジ・ソースによって表されるソース・データベースが、ステージング・データベースからリモートかローカルかを示し、チェンジ・ソースが、チェンジ・データ・キャプチャの同期または非同期のどちらのモードで使用されるかを示します。

表17-1 チェンジ・ソースとチェンジ・セットの概要

モード チェンジ・ソース 表されるソース・データベース 関連チェンジ・セット

同期

事前定義のSYNC_SOURCE

ローカル

事前定義のSYNC_SETおよびパブリッシャ定義。

非同期HotLog

事前定義のHOTLOG_SOURCE

ローカル

パブリッシャ定義。

非同期分散HotLog

パブリッシャ定義。

リモート

パブリッシャ定義。チェンジ・セットはすべて、同じステージング・データベース上に存在する必要がある。

非同期AutoLogオンライン

パブリッシャ定義。

リモート

パブリッシャ定義。AutoLogオンライン・チェンジ・ソースに含めることができるチェンジ・セットは1つのみ。

非同期AutoLogアーカイブ

パブリッシャ定義。

リモート

パブリッシャ定義。


チェンジ・テーブル

特定のチェンジ・テーブルには、特定のソース・テーブルに対して実行されたDML操作の結果として生成された変更データが含まれています。チェンジ・テーブルは、データベース表に格納されている変更データ自体と、制御列が含まれるチェンジ・テーブルのメンテナンスに必要なシステム・メタデータで構成されています。

パブリッシャは、チェンジ・テーブルに含めるソース列を指定します。通常、チェンジ・テーブルに有益なデータを含めるには、パブリッシャは、主キー列とサブスクライバが必要とするその他の列をチェンジ・テーブルに含める必要があります。たとえば、サブスクライバがsh.costs表のUNIT_COST列とUNIT_PRICE列に発生する変更を必要とすると仮定します。パブリッシャがチェンジ・テーブルにPROD_ID列を含めないと、サブスクライバは、ある製品の単位原価および単位価格が変更になったということしかわからず、これらの変更がどの製品に対して発生したかは判別できません。

制御列にはオプションと必須のものがあります。必須の制御列は、常にチェンジ・テーブルに含まれます。オプションの制御列は、チェンジ・テーブルを作成する際にパブリッシャが指定した場合に含まれます。制御列はチェンジ・データ・キャプチャによって管理されます。制御列の詳細は、「チェンジ・テーブルの制御列の理解」および「TARGET_COLMAP$およびSOURCE_COLMAP$の値の理解」を参照してください。

チェンジ・データ・キャプチャ環境に関する情報の取得

チェンジ・データ・キャプチャ環境に関する情報は、表17-2および表17-3に示す静的データ・ディクショナリ・ビューに用意されています。表17-2は、パブリッシャによる使用を対象としたビューをまとめたものです。この表のビューにアクセスするには、SELECT_CATALOG_ROLE権限が必要となります。表17-3は、サブスクライバによる使用を対象としたビューの一覧です。表17-3のビューは、接頭辞ALLまたはUSERが付いています。これらの接頭辞は一般的に次の意味を持ちます。

表17-2 チェンジ・データ・キャプチャのパブリッシャによる使用を対象としたビュー

ビュー名 説明

ALL_CHANGE_SOURCES

既存のチェンジ・ソースを表示します。

ALL_CHANGE_PROPAGATIONS

ソース・データベース上の特定の分散HotLogチェンジ・ソースに関連するOracle Streamsの伝播を表示します。このビューは、リリース11.1または11.2のチェンジ・ソースではソース・データベース上に移入され、9.2、10.1または10.2のチェンジ・ソースではステージング・データベース上に移入されます。

ALL_CHANGE_PROPAGATION_SETS

ステージング・データベース上の特定の分散HotLogチェンジ・セットに関連するOracle Streamsの伝播を表示します。このビューは、リリース11.1または11.2のチェンジ・ソースではソース・データベース上に移入され、9.2、10.1または10.2のチェンジ・ソースではステージング・データベース上に移入されます。

ALL_CHANGE_SETS

既存のチェンジ・セットを表示します。

ALL_CHANGE_TABLES

既存のチェンジ・テーブルを表示します。

DBA_SOURCE_TABLES

データベース内の公開済のソース・テーブルをすべて表示します。

DBA_PUBLISHED_COLUMNS

データベース内の公開済のソース・テーブルの列をすべて表示します。

DBA_SUBSCRIPTIONS

サブスクリプションをすべて表示します。

DBA_SUBSCRIBED_TABLES

任意のサブスクライバがサブスクライブしたソース・テーブルをすべて表示します。

DBA_SUBSCRIBED_COLUMNS

任意のサブスクライバがサブスクライブしたソース・テーブルの列を表示します。


表17-3 チェンジ・データ・キャプチャのサブスクライバによる使用を対象としたビュー

ビュー名 説明

ALL_SOURCE_TABLES

現行ユーザーが所有するチェンジ・テーブルの公開ソース・テーブルをすべて表示します。

USER_SOURCE_TABLES

現行ユーザーが所有するチェンジ・テーブルの公開ソース・テーブルをすべて表示します。

ALL_PUBLISHED_COLUMNS

現行ユーザーが所有するチェンジ・テーブルのソース・テーブルの公開済の列をすべて表示します。脚注1

USER_PUBLISHED_COLUMNS

現行ユーザーが所有するチェンジ・テーブルのソース・テーブルの公開済の列をすべて表示します。

ALL_SUBSCRIPTIONS

現行ユーザーが作成したサブスクリプションをすべて表示します。

USER_SUBSCRIPTIONS

現行ユーザーが作成したサブスクリプションをすべて表示します。

ALL_SUBSCRIBED_TABLES

現行ユーザーがサブスクライブしたソース・テーブルを表示します。

USER_SUBSCRIBED_TABLES

現行ユーザーがサブスクライブしたソース・テーブルを表示します。

ALL_SUBSCRIBED_COLUMNS

現行ユーザーがサブスクライブしたソース・テーブルの列を表示します。

USER_SUBSCRIBED_COLUMNS

現行ユーザーがサブスクライブしたソース・テーブルの列を表示します。


脚注1ALL_PUBLISHED_COLUMNSUSER_PUBLISHED_COLUMNSおよび*_SOURCE_TABLESのビューはシノニムなので、ユーザーには表または列の情報を表示する所有権が必要です。

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

変更データの公開準備

この項では、パブリッシャの作成に関する情報、変更データをキャプチャするモードの選択に関する情報、チェンジ・データ・キャプチャの非同期分散HotLogモードで必要なデータベース・リンクの設定手順、およびチェンジ・データ・キャプチャで必要なデータベース初期化パラメータの設定手順など、変更データの公開を開始する前に、パブリッシャが実行する必要のあるタスクについて説明します。

パブリッシャは公開の実際の手順を実行する前に、次のタスクを行う必要があります。

パブリッシャとなるユーザーの作成

チェンジ・データ・キャプチャのすべてのモードにおいて、ステージング・データベースDBAは、チェンジ・データ・キャプチャのパブリッシャとなるユーザーを作成します。また、チェンジ・データ・キャプチャの非同期分散HotLogモードでは、ソース・データベースDBAも、パブリッシャとなるユーザーを作成します。このパブリッシャがソース・データベースで実行するタスクは、ソース・データベースからステージング・データベースへのデータベース・リンクの作成のみです。

SYSおよびSYSTEMユーザーは、チェンジ・データ・キャプチャのパブリッシャとして使用できません。また、チェンジ・データ・キャプチャのパブリッシャは、デフォルト表領域としてSYSTEM表領域は使用できません。

以降の項では、チェンジ・データ・キャプチャの各モードで必要とされるパブリッシャの設定方法について説明します。


注意:

パブリッシャをSQL DROP USER CASCADE文で削除すると、そのパブリッシャが所有していたチェンジ・データ・キャプチャのすべてのオブジェクト(他のパブリッシャが所有するチェンジ・データ・キャプチャのオブジェクトを含むものは除く)が削除されます。たとえば、チェンジ・テーブルCDCPUB2.SALES_CTが含まれるチェンジ・セットCDCPUB1_SETをパブリッシャCDCPUB1が所有しているものと仮定します。ここで、CDCPUB1を削除するDROP USER CASCADE文を発行しても、CDCPUB1_SETチェンジ・セットは削除されません。ただし、このチェンジ・セットに含まれるすべてのチェンジ・テーブルが削除された後であれば、パブリッシャはDBMS_CDC_PUBLISH.DROP_CHANGE_SETサブプログラムでCDCPUB1_SETチェンジ・セットを削除できます。

パブリッシャに対する権限およびロールの付与

使用するチェンジ・データ・キャプチャのモードにかかわらず、ステージング・データベースのパブリッシャは、次に示す権限およびロールを付与されている必要があります。

  • EXECUTE_CATALOG_ROLE権限

  • SELECT_CATALOG_ROLE権限

  • CREATE TABLE権限およびCREATE SESSION権限

  • DBMS_CDC_PUBLISHパッケージのEXECUTE

非同期HotLog、分散HotLog、およびAutoLogの公開では、ステージング・データベースのパブリッシャは、Oracle Streams管理者として構成されている必要があり、CREATE SEQUENCE権限も付与されている必要があります。Oracle Streams管理者の構成に関する詳細は、『Oracle Streams概要および管理』を参照してください。

  • CREATE SEQUENCE権限が付与されている

  • DBAロールが付与されている

  • ステージング・データベースのDBAが発行したDBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGEサブプログラムに指定されているGRANTEEである

非同期分散HotLogの公開では、ソース・データベースのパブリッシャは、DBAロールが付与されており、DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGEサブプログラムで指定されている権限受領者である必要があります。

パブリッシャのデフォルト表領域の作成

ステージング・データベース上にパブリッシャのアカウントを作成する際は、DBAがそのパブリッシャのデフォルト表領域を指定し、パブリッシャは、作成するすべてのチェンジ・テーブル用としてこの表領域を使用することをお薦めします。

パスワード・ファイルおよびREMOTE_LOGIN_PASSWORDFILEパラメータの設定

パスワード・ファイルが生成済であることを確認する必要があります。このファイルは、Database Configuration Assistantを使用するときに自動的に生成されます。


関連項目:


データをキャプチャするモードの決定

変更データをキャプチャするモードの決定は、次の要因によって影響されます。

  • ステージング・データベースがソース・データベースとリモートかどうか。

  • 変更がソース・データベースに発生してから、チェンジ・データ・キャプチャでキャプチャされるまでの待機時間の許容範囲。一般に、待機時間は表17-4に示す同期から非同期AutoLogアーカイブにかけて長くなります。

  • ソース・データベース・トランザクションに対するパフォーマンスの影響およびデータベース全体のパフォーマンス。

  • ソース・データベースとステージング・データベースが、同じオペレーティング・システムまたはOracleデータベースの同じリリースを使用して同じハードウェア上で動作するかどうか。

表17-4に、モードの決定に影響を与えるこれらの要因の概要を示します。

表17-4 チェンジ・データ・キャプチャのモードの選択に影響を与える要因

モード ステージング・データベースの場所と、ハードウェアおよびソフトウェア キャプチャ・メカニズム ソース・データベースのパフォーマンスへの影響

同期

場所はソース・データベースと同じである必要があり、ハードウェア、オペレーティング・システムおよびOracleデータベースのリリースはソース・システムと同じである必要があります。

変更データは、反映する同じトランザクションの一部として自動的にコミットされます。

変更データのキャプチャを実行するため、ソース・データベース・トランザクションのオーバーヘッドが増加します。

非同期HotLog

場所はソース・データベースと同じである必要があり、ハードウェア、オペレーティング・システムおよびOracleデータベースのリリースはソース・システムと同じである必要があります。

変更データは、現行のオンラインREDOログ・ファイルからキャプチャされます。チェンジ・セットは、トランザクションが新たにコミットされると自動的に移入されます。

サプリメンタル・ロギングを実行するため、ソース・データベース・トランザクションに対する影響は最小です。変更データのキャプチャを実行すると、ソース・データベースのオーバーヘッドが増加します。

非同期分散HotLog

場所は、ソース・データベースとリモートです。ハードウェア、オペレーティング・システムおよびOracleデータベースのリリースは、ソース・システムと同じである必要はありません。

変更データは、現行のオンラインREDOログ・ファイルからキャプチャされます。チェンジ・セットは、新たにコミットされたトランザクションがステージング・データベースに届くと自動的に移入されます。

サプリメンタル・ロギングを実行するため、ソース・データベース・トランザクションに対する影響は最小です。

オンラインREDOログ・ファイルのマイニング時には、ソース・データベースに多少のオーバーヘッドが生じます。

非同期AutoLogオンライン

場所は、ソース・データベースとリモートです。ハードウェア、オペレーティング・システムおよびOracleデータベースのリリースは、ソース・システムと同じです。

変更データは、スタンバイREDOログ・ファイルからキャプチャされます。チェンジ・セットは、新たにコミットされたトランザクションがステージング・データベースに届くと自動的に移入されます。

サプリメンタル・ロギングを実行するため、ソース・データベース・トランザクションに対する影響は最小です。

REDO転送サービスのソース・データベースのオーバーヘッドは最小です。

非同期AutoLogアーカイブ

場所は、ソース・データベースとリモートです。ハードウェア、オペレーティング・システムおよびOracleデータベースのリリースは、ソース・システムと同じです。

変更データは、アーカイブREDOログ・ファイルからキャプチャされます。チェンジ・セットは、アーカイブREDOログ・ファイルがステージング・データベースに届くと自動的に移入されます。

サプリメンタル・ロギングを実行するため、ソース・データベース・トランザクションに対する影響は最小です。

REDO転送サービスのソース・データベースのオーバーヘッドは最小です。


チェンジ・データ・キャプチャの公開用初期化パラメータの設定

初期化パラメータは、チェンジ・データ・キャプチャを正常に行うために、ソース・データベースかステージング・データベース、またはその両方で設定する必要があります。どのパラメータを設定するかは、チェンジ・データ・キャプチャが変更データを公開するモード、および、ソース・データベースかステージング・データベースのどちらでパラメータを設定しているかに依存します。

次の項では、チェンジ・データ・キャプチャの各モードにおける、データベース初期化パラメータの設定について説明します。DBAが、現行の設定に値を追加する必要がある場合もあります。DBAは、SQL SHOW PARAMETERS文を使用して現行の設定値を参照できます。

これらのデータベース初期化パラメータの一般情報は『Oracle Databaseリファレンス』を、非同期の公開用のデータベース初期化パラメータ設定の詳細は『Oracle Streams概要および管理』を参照してください。

同期公開用初期化パラメータ

JAVA_POOL_SIZEパラメータを次のように設定します。

JAVA_POOL_SIZE = 50000000

非同期HotLogの公開用初期化パラメータ

表17-5に、ソース・データベースの初期化パラメータおよび非同期HotLogの公開用の推奨設定を示します。

表17-5 非同期HotLogの公開用のソース・データベース初期化パラメータ

パラメータ 推奨値

COMPATIBLE

11.0

JAVA_POOL_SIZE

50000000

JOB_QUEUE_PROCESSES

(現行値) + 2

PARALLEL_MAX_SERVERS

(現行値) + (5 * (計画しているチェンジ・セットの数))

PROCESSES

(現行値) + (7 * (計画しているチェンジ・セットの数))

SESSIONS

(現行値) + (2 * (計画しているチェンジ・セットの数))

STREAMS_POOL_SIZE

  • STREAMS_POOL_SIZEパラメータの現行値が50MB以上の場合、このパラメータは次のように設定します。

    (現行値) + ((計画しているチェンジ・セットの数) * (21MB))

  • STREAMS_POOL_SIZEパラメータの現行値が50MBより小さい場合、このパラメータの値は次のように設定します。

    50MB + ((計画しているチェンジ・セットの数) * (21MB))

動的な変更の際にSTREAMS_POOL_SIZEパラメータがどのように適用されるかについては、『Oracle Streams概要および管理』を参照してください。

UNDO_RETENTION

3600


非同期分散HotLogの公開用初期化パラメータ

表17-6に、ソース・データベースがOracle Databaseリリース10.1.0、10.2.0、11.1.0または11.2.0の場合の、ソース・データベースの初期化パラメータおよび非同期分散HotLogの公開用の推奨設定を示します。

表17-7に、ソース・データベースがOracle Databaseリリース9.2の場合の、ソース・データベースの初期化パラメータおよび非同期分散HotLogの公開用の推奨設定を示します。

表17-8に、ステージング・データベースの初期化パラメータおよび非同期分散HotLogの公開用の推奨設定を示します。これらは、ソース・データベースに使用されているOracleデータベースのリリースにかかわらず同じです。

表17-6 非同期分散HotLogの公開用のソース・データベース(10.1.0、10.2.0、11.1.0、11.2.0)初期化パラメータ

パラメータ 推奨値

COMPATIBLE

11.0(ソースOracleデータベースのリリースによって異なる)

GLOBAL_NAMES

TRUE

JOB_QUEUE_PROCESSES

(現行値) + 2

OPEN_LINKS

4または計画している分散HotLogチェンジ・ソース数のいずれか大きい方の値

PARALLEL_MAX_SERVERS

(現行値) + (3 * (計画しているチェンジ・ソースの数))

PROCESSES

(現行値) + (4 * (計画しているチェンジ・ソースの数))

SESSIONS

(現行値) + (計画しているチェンジ・ソースの数)

STREAMS_POOL_SIZE

  • STREAMS_POOL_SIZEパラメータの現行値が50MB以上の場合、このパラメータは次のように設定します。

    (現行値) + ((計画しているチェンジ・ソースの数) * (20MB))

  • STREAMS_POOL_SIZEパラメータの現行値が50MBより小さい場合、このパラメータの値は次のように設定します。

    50MB + ((計画しているチェンジ・セットの数) * (20MB))

動的な変更の際にSTREAMS_POOL_SIZEパラメータがどのように適用されるかについては、『Oracle Streams概要および管理』を参照してください。

UNDO_RETENTION

3600


表17-7 非同期分散HotLogの公開用のソース・データベース(9.2)初期化パラメータ

パラメータ 推奨値

COMPATIBLE

9.2.0

GLOBAL_NAMES

TRUE

JOB_QUEUE_PROCESSES

(現行値) + 2

LOG_PARALLELISM

1

LOGMNR_MAX_PERSISTENT_SESSIONS

計画しているチェンジ・ソースの数と同じ値

OPEN_LINKS

4または計画している分散HotLogチェンジ・ソース数のいずれか大きい方の値

PARALLEL_MAX_SERVERS

(現行値) + (3 * (計画しているチェンジ・ソースの数))

PROCESSES

(現行値) + (4 * (計画しているチェンジ・ソースの数))

SESSIONS

(現行値) + (計画しているチェンジ・ソースの数)

SHARED_POOL_SIZE

  • SHARED_POOL_SIZEパラメータの現行値が50MB以上の場合、このパラメータは次のように設定します。

    (現行値) + ((計画しているチェンジ・ソースの数) * (20MB))

  • SHARED_POOL_SIZEパラメータの現行値が50MBより小さい場合、このパラメータの値は次のように設定します。

    50MB * ((計画しているチェンジ・ソースの数) * (20MB))

UNDO_RETENTION

3600


表17-8 非同期分散HotLogの公開用のステージング・データベース(11.2.0)初期化パラメータ

パラメータ 推奨値

COMPATIBLE

11.0

GLOBAL_NAMES

TRUE

JAVA_POOL_SIZE

50000000

OPEN_LINKS

4または計画している分散HotLogチェンジ・セット数のいずれか大きい方の値

PARALLEL_MAX_SERVERS

(現行値) + (2 * (計画しているチェンジ・セットの数))

PROCESSES

(現行値) + (3 * (計画しているチェンジ・セットの数))

SESSIONS

(現行値) + (計画しているチェンジ・セットの数)

STREAMS_POOL_SIZE

  • STREAMS_POOL_SIZEパラメータの現行値が50MB以上の場合、このパラメータは次のように設定します。

    (現行値) * ((計画しているチェンジ・セットの数) * (11MB))

  • STREAMS_POOL_SIZEパラメータの現行値が50MBより小さい場合、このパラメータの値は次のように設定します。

    50MB + ((計画しているチェンジ・セットの数) * (11MB))

動的な変更の際にSTREAMS_POOL_SIZEパラメータがどのように適用されるかについては、『Oracle Streams概要および管理』を参照してください。


非同期AutoLogの公開用初期化パラメータ

表17-9に、データベース初期化パラメータとソース・データベースの非同期AutoLogの公開用推奨設定を、表17-10に、データベース初期化パラメータとステージング・データベースの非同期AutoLogの公開用推奨設定を示します。

表17-9 非同期AutoLogの公開用のソース・データベース初期化パラメータ

パラメータ 推奨値

COMPATIBLE

11.0

LOG_ARCHIVE_DEST_1脚注1

自身のアーカイブREDOログ・ファイルが保存されるソース・データベース上のディレクトリ指定。

LOG_ARCHIVE_DEST_2脚注1

このパラメータには、SERVICEARCHLGWR ASYNCOPTIONALNOREGISTERREOPEN属性を指定する必要があります。この属性によって、REDOログ・ファイルがソース・データベースからステージング・データベースにコピーされるようREDO転送サービスが構成されます。また、このパラメータには、AutoLogオプションに応じて、VALID_FORまたはTEMPLATE属性を指定する必要があります。これらの属性は次のような設定となります。

  • SERVICE: ステージング・データベースのネットワーク名を指定します。

  • ARCHまたはLGWR ASYNC:

    AutoLogオンライン・オプションを使用するには、LGWR ASYNCを指定します。LGWR ASYNCは、REDOがソース・データベースで生成されると、ログ・ライター・プロセス(LGWR)によって、REDOデータがステージング・データベースに非同期式にコピーされるように指定します。コピーしたREDOデータがチェンジ・データ・キャプチャで使用できるようになるのは、ソース・データベースのトランザクションのコミット後です。AutoLogアーカイブ・オプションを使用するには、ARCHまたはLGWR ASYNCを指定します。ARCHは、ソース・データベースのログ・スイッチの発生後に、アーカイバ・プロセス(ARCn)によって、REDOログ・ファイルがステージング・データベースにコピーされるように指定します。LGWR ASYNCは、REDOがソース・データベースで生成されると、ログ・ライター・プロセス(LGWR)によって、REDOデータがステージング・データベースに非同期式にコピーされるように指定します。ARCHおよびLGWR ASYNCのどちらの場合でも、コピーしたREDOデータがチェンジ・データ・キャプチャで使用できるようになるのは、AutoLogアーカイブ・オプション使用時におけるソース・データベースのログ・スイッチの発生後です。

  • OPTIONALは、ソース・データベースの対応するオンラインREDOログが上書きされることが可能となるまでは、ステージング・データベースへのREDOログ・ファイルのコピーが成功する必要がないことを指定します。これは、ステージング・データベースへの転送失敗に起因するソース・データベースでの操作の停止を回避するために必要です。元のREDOログ・ファイルはアーカイブまたはバックアップされた形式で、必要であればソース・データベースで使用できる状態で残ります。

  • NOREGISTER: ステージング・データベースの場所がステージング・データベースの制御ファイルに記録されないように指定します。

  • REOPEN: ステージング・データベースへのアクセスが失敗した場合、再度アクセスする前に、ログ・ライター・プロセス(LGWR)またはアーカイバ・プロセス(ARCn)が待機する必要のある最小秒数を指定します。

  • VALID_FOR: AutoLogオンライン・オプション使用時に、ソース・データベースのオンラインREDOログから、ステージング・データベースのスタンバイREDOログにREDOデータをコピーできるようにするには、VALID_FORを(ONLINE_LOGFILE, PRIMARY_ROLE)または(ONLINE_LOGFILE, ALL_ROLES)のいずれかに設定します。

  • TEMPLATE AutoLogアーカイブ・オプション使用時に、TEMPLATEを指定して、ステージング・データベースにコピーされるアーカイブREDOログ・ファイルに使用されるファイル名のフォーマット・テンプレートおよびディレクトリ指定を定義します。脚注2

LOG_ARCHIVE_DEST_STATE_1脚注1

ENABLE

REDO転送サービスでアーカイブREDOログ・ファイルをこの宛先に転送できるよう指定します。

LOG_ARCHIVE_DEST_STATE_2脚注1

ENABLE

REDO転送サービスでREDOログ・ファイルをこの宛先に転送できるよう指定します。

LOG_ARCHIVE_FORMAT脚注2

"arch_%s_%t_%r.dbf"

REDOログ・ファイルをアーカイブする際の、デフォルトのファイル名のフォーマット・テンプレートを指定します。脚注2 文字列値(arch)およびファイル名の拡張子(.dbf)は、ここで示しているものと同じである必要はありません。

REMOTE_ARCHIVE_ENABLE

TRUE

このソース・データベースでREDOログ・ファイルをリモートの宛先に送信できるよう指定します。


脚注1このパラメータの整数値は、1から10の間の任意の値を指定できます。このマニュアルでは、値1および2を使用します。各LOG_ARCHIVE_DEST_nパラメータに対して、対応するLOG_ARCHIVE_DEST_STATE_nパラメータ(nは同じ数値)を指定する必要があります。

脚注2フォーマット・テンプレートでは、%tがスレッド番号、%sが順序番号、%rがリセットログIDに対応します。これらを組み合せることにより、コピーされたREDOログ・ファイルに一意の名前が割り当てられます。どの要素も必須ですが、順番とフォーマットは柔軟に変更できます。

表17-10 非同期AutoLogの公開用のステージング・データベース初期化パラメータ

パラメータ 推奨値

COMPATIBLE

11.2.0

GLOBAL_NAMES

TRUE

JAVA_POOL_SIZE

50000000

LOG_ARCHIVE_DEST_1脚注1

自身のアーカイブREDOログ・ファイルが保存されるステージング・データベース上のディレクトリ指定。ステージング・データベースにAutoLogオンライン・チェンジ・ソースが含まれる場合、次の属性を指定する必要があります。

  • LOCATIONは、ステージング・データベースの自身のアーカイブREDOログ・ファイルに一意のディレクトリ・パス名を指定します。

  • オンラインREDOログ・ファイルをローカルでアーカイブできるようにするには、VALID_FORを(ONLINE_LOGFILE, PRIMARY_ROLE)または(ONLINE_LOGFILE, ALL_ROLES)のいずれかに設定します。

LOG_ARCHIVE_DEST_2脚注1

ステージング・データベースにAutoLogオンライン・チェンジ・ソースが含まれる場合、これは、ソース・データベースから変更データを受け取る、ステージング・データベース上のスタンバイREDOログ・ファイルを指定します。これらのスタンバイREDOログ・ファイルには一意の場所を指定することが非常に重要です。一意の場所を指定することで、ステージング・データベースの自身のアーカイブ・ログ・ファイルがこれらのスタンバイREDOログ・ファイルによって上書きされないようにするためです。

  • LOCATIONは、ステージング・データベースのスタンバイREDOログ・ファイルに一意のディレクトリ・パス名を指定します。

  • MANDATORYは、スタンバイREDOログ・ファイルが、上書きされる前に正常にアーカイブされるように指定します。

  • ステージング・データベースで、ソース・データベースから変更データを受け取り、その変更データをステージング・データベースのスタンバイ・ログ・ファイルに書き込むようにするには、VALID_FORを(STANDBY_LOGFILE, PRIMARY_ROLE)または(STANDBY_LOGFILE, ALL_ROLES)のいずれかに設定します。

LOG_ARCHIVE_DEST_STATE_1脚注1

ENABLE

REDO転送サービスでアーカイブREDOログ・ファイルをこの宛先に転送できるよう指定します。

LOG_ARCHIVE_DEST_STATE_2脚注1

ENABLE

REDO転送サービスでREDOログ・ファイルをこの宛先に転送できるよう指定します。

LOG_ARCHIVE_FORMAT脚注2

"arch_%s_%t_%r.dbf"

REDOログ・ファイルをアーカイブする際に、デフォルトのファイル名のフォーマット・テンプレートを指定します。脚注2文字列値(arch)およびファイル名の拡張子(.dbf)は、ここで示しているものと同じである必要はありません。

JOB_QUEUE_PROCESSES

2

PARALLEL_MAX_SERVERS

(現行値) + (5 * (計画しているチェンジ・セットの数))

PROCESSES

(現行値) + (7 * (計画しているチェンジ・セットの数))

REMOTE_ARCHIVE_ENABLE

TRUE

このステージング・データベースで、アーカイブREDOログ・ファイルをリモートで受け取ることができるよう指定します。

SESSIONS

(現行値) + (2 * (計画しているチェンジ・セットの数))

STREAMS_POOL_SIZE

  • STREAMS_POOL_SIZEパラメータの現行値が50MB以上の場合、このパラメータは次のように設定します。

    (現行値) + ((計画しているチェンジ・セットの数) * (21MB))

  • STREAMS_POOL_SIZEパラメータの現行値が50MBより小さい場合、このパラメータの値は次のように設定します。

    50MB + ((計画しているチェンジ・セットの数) * (21MB))

動的な変更の際にSTREAMS_POOL_SIZEパラメータがどのように適用されるかについては、『Oracle Streams概要および管理』を参照してください。

UNDO_RETENTION

3600


脚注1このパラメータの整数値は、1から10の間の任意の値を指定できます。このマニュアルでは、値1および2を使用します。各LOG_ARCHIVE_DEST_nパラメータに対して、対応するLOG_ARCHIVE_DEST_STATE_nパラメータ(nは同じ数値)を指定する必要があります。

脚注2フォーマット・テンプレートでは、%tがスレッド番号、%sが順序番号、%rがリセットログIDに対応します。これらを組み合せることにより、コピーされたREDOログ・ファイルに一意の名前が割り当てられます。どの要素も必須ですが、順番とフォーマットは柔軟に変更できます。

Oracle Streamsの値変更時の初期化パラメータ値の調整

非同期チェンジ・データ・キャプチャでは、各チェンジ・セットについて、Oracle Streams構成を使用します。このStreams構成は、Streamsの取得プロセスと適用プロセス、キューおよびキュー表で構成されます。各Streams構成では、追加のプロセス、パラレル実行サーバーおよびメモリーが使用されます。Streamsアーキテクチャの詳細は、『Oracle Streams概要および管理』を参照してください。

構成になんらかの変更があった場合は、初期化パラメータの調整が必要となることがあります。詳細は、表17-10「非同期AutoLogの公開用のステージング・データベース初期化パラメータ」を参照してください。

CDC環境に対する変更のトラッキング

チェンジ・テーブルでパーティションのメンテナンス操作、ダイレクト・パス・ロード、DDL操作が発生したときに、これらを追跡することが可能です。これを実行するには、DBMS_CDC_PUBLISH.CREATE_CHANGE_TABLEプロシージャのddl_markersフラグをセットします。

変更データの公開

次の項では、様々なタイプの公開を実行する手順を提供します。

同期公開の実行

同期チェンジ・データ・キャプチャに対しては、パブリッシャは事前定義のチェンジ・ソースSYNC_SOURCEを使用する必要があります。パブリッシャは、新しいチェンジ・セットを定義したり、事前定義のチェンジ・セットSYNC_SETを使用したりできます。パブリッシャは、SYSまたはSYSTEMが所有するソース・テーブル上にチェンジ・テーブルを作成してはいけません。こうすると、トリガーが起動されず、変更がキャプチャされないためです。

この例では、チェンジ・セットの作成方法を示します。パブリッシャが事前定義のSYNC_SETを使用する場合は、手順3をスキップして、残りの手順でチェンジ・セット名としてSYNC_SETを指定してください。

この例では、パブリッシャとソース・データベースDBAは2人の異なるユーザーとします。

同期チェンジ・データ・キャプチャでは、ソース・データベースとステージング・データベースは同じであることに注意してください。

手順1   ソース・データベースDBA: JAVA_POOL_SIZEパラメータの設定

ソース・データベースDBAは、「チェンジ・データ・キャプチャの公開用初期化パラメータの設定」で説明しているように、データベース初期化パラメータを設定します。

java_pool_size = 50000000
手順2   ソース・データベースDBA: パブリッシャに対する権限の作成および付与

ソース・データベースDBAは、チェンジ・データ・キャプチャのパブリッシャとなるユーザー(cdcpubなど)を作成し、必要な権限をそのパブリッシャに付与することで、チェンジ・データ・キャプチャのチェンジ・セットおよびチェンジ・テーブルをソース・データベース上に作成するために必要な操作をそのパブリッシャが実行できるようにします(「パブリッシャとなるユーザーの作成」を参照)。この例では、表領域ts_cdcpubがすでに作成済であるものとします。

CREATE USER cdcpub IDENTIFIED EXTERNALLY DEFAULT TABLESPACE ts_cdcpub
QUOTA UNLIMITED ON SYSTEM
QUOTA UNLIMITED ON SYSAUX;
GRANT CREATE SESSION TO cdcpub;
GRANT CREATE TABLE TO cdcpub;
GRANT CREATE TABLESPACE TO cdcpub;
GRANT CREATE JOB TO cdcpub;
GRANT UNLIMITED TABLESPACE TO cdcpub;
GRANT SELECT_CATALOG_ROLE TO cdcpub;
GRANT EXECUTE_CATALOG_ROLE TO cdcpub;
GRANT ALL ON sh.sales TO cdcpub;
GRANT ALL ON sh.products TO cdcpub;
GRANT EXECUTE ON DBMS_CDC_PUBLISH TO cdcpub;
手順3   ステージング・データベースのパブリッシャ: チェンジ・セットの作成

パブリッシャは、ステージング・データベース上でDBMS_CDC_PUBLISH.CREATE_CHANGE_SETプロシージャを使用してチェンジ・セットを作成します。

次の例では、CHICAGO_DAILYというチェンジ・セットの作成方法を示します。

BEGIN
    DBMS_CDC_PUBLISH.CREATE_CHANGE_SET( 
    change_set_name    => 'CHICAGO_DAILY', 
    description        => 'Change set for sales history info', 
    change_source_name => 'SYNC_SOURCE');
END;
/

チェンジ・セットは、事前定義のチェンジ・ソースSYNC_SOURCEから変更をキャプチャします。begin_dateおよびend_dateパラメータは同期チェンジ・セットに指定できないので、変更データのキャプチャは、変更データが最初に使用可能となった時点から始まり、無期限に続きます。

手順4   ステージング・データベースのパブリッシャ: チェンジ・テーブルの作成

パブリッシャは、DBMS_CDC_PUBLISH.CREATE_CHANGE_TABLEプロシージャを使用してチェンジ・テーブルを作成します。

パブリッシャは、DBMS_CDC_PUBLISH.CREATE_CHANGE_TABLEプロシージャのoptions_stringフィールドを設定して、チェンジ・テーブルの物理プロパティと表領域プロパティを厳密に制御できます。options_stringフィールドには、CREATE TABLE文で使用可能な、パーティション化以外の任意のオプションを指定できます。

次の例では、ソース・テーブルに発生した変更をキャプチャするチェンジ・テーブルを作成します。例では、ソース・テーブルとして、サンプル・スキーマ表sh.productsを使用します。パブリッシャがすでにTS_CHICAGO_DAILY表領域を作成済であるものとします。

BEGIN
   DBMS_CDC_PUBLISH.CREATE_CHANGE_TABLE(
   owner             => 'cdcpub',
   change_table_name => 'products_ct', 
   change_set_name   => 'CHICAGO_DAILY',
   source_schema     => 'SH',
   source_table      => 'PRODUCTS',
   column_type_list  => 'PROD_ID NUMBER(6), 
                         PROD_NAME VARCHAR2(50),
                         PROD_LIST_PRICE NUMBER(8,2)', 
   capture_values    => 'both',
   rs_id             => 'y', 
   row_id            => 'n',
   user_id           => 'n',
   timestamp         => 'n',
   object_id         => 'n',
   source_colmap     => 'y',
   target_colmap     => 'y',
   options_string    => 'TABLESPACE TS_CHICAGO_DAILY');
END;
 /

この文では、チェンジ・セットCHICAGO_DAILY内にproducts_ctという名前のチェンジ・テーブルを作成します。column_type_listパラメータには、このチェンジ・テーブルによりキャプチャされる列を指定します。source_schemaおよびsource_tableパラメータは、ソース・データベースにあるスキーマおよびソース・テーブルを特定します。

例におけるcapture_values設定は、更新操作で変更された各行について、変更データが2つの別個の行を持つことを示します。1つ目の行には更新前の行値が含まれ、2つ目の行には更新後の行値が含まれます。

詳細は、「チェンジ・テーブルの管理」を参照してください。

手順5   ステージング・データベースのパブリッシャ: サブスクライバへのアクセス権の付与

パブリッシャは、ユーザーおよびロールに対してチェンジ・テーブルへのSELECT権限の付与および取消しを行うことで、サブスクライバの変更データへのアクセスを制御します。パブリッシャは、特定のチェンジ・テーブルへのアクセス権を付与します。この手順を行わないと、サブスクライバはどのような変更データにもアクセスできません。この例では、ユーザーsubscriber1がすでに存在しているものとします。

GRANT SELECT ON cdcpub.products_ct TO subscriber1;

これで、チェンジ・データ・キャプチャの同期システムが設定され、subscriber1がサブスクリプションを作成する準備ができました。

非同期HotLogの公開の実行

チェンジ・データ・キャプチャはOracle Streamsのローカル・キャプチャを使用して、非同期HotLogの公開を実行します。Oracle Streamsのローカル・キャプチャの詳細は、『Oracle Streams概要および管理』を参照してください。

HotLogのチェンジ・データ・キャプチャでは、パブリッシャは、事前定義のチェンジ・ソースHOTLOG_SOURCEを使用し、変更を格納するチェンジ・テーブルとチェンジ・セットを作成する必要があります。ステージング・データベースは常にソース・データベースです。この例では、パブリッシャとソース・データベースDBAは2人の異なるユーザーとします。

非同期のHotLogチェンジ・データ・キャプチャでは、ソース・データベースとステージング・データベースは同じであることに注意してください。

次の手順では、非同期HotLogの公開のための、REDOロギング、Oracle Streamsおよびチェンジ・データ・キャプチャを設定します。

手順1   ソース・データベースDBA: データベース初期化パラメータの設定

ソース・データベースDBAは、「チェンジ・データ・キャプチャの公開用初期化パラメータの設定」で説明しているように、データベース初期化パラメータを設定します。この例では、1つのチェンジ・セットが定義されます。STREAMS_POOL_SIZEパラメータの現行値は50MBです。

compatible = 11.0
java_pool_size = 50000000
job_queue_processes = 2
parallel_max_servers = <current value> + 5
processes = <current value> + 7
sessions = <current value> + 2
streams_pool_size = <current value> + 21 MB
undo_retention = 3600
手順2   ソース・データベースDBA: ソース・データベースの変更

ソース・データベースDBAは、次の3つのタスクを実行します。2つ目は必須です。1つ目と3つ目はオプションですが、実行することをお薦めします。データベースは現在、ARCHIVELOGモードで実行されているものとします。

  1. データベースをFORCE LOGGINGロギング・モードに設定し、非同期チェンジ・データ・キャプチャではキャプチャできない、ソース・データベースでのロギングされないダイレクト書込み操作を回避します。

    ALTER DATABASE FORCE LOGGING;
    

    ロギングは、表領域レベルまたは表レベルでも実行可能です。

  2. サプリメンタル・ロギングを有効化します。サプリメンタル・ロギングによって、UPDATE操作を実行するとすぐに、追加の列データがREDOログ・ファイルに配置されます。最低限、どのようなチェンジ・データ・キャプチャのソース・データベースに対しても、データベース・レベルの最小サプリメンタル・ロギングを有効化する必要があります。

    ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
    
  3. ソース・テーブルでキャプチャされるすべての列に対して、無条件のログ・グループを作成します。変更されない、無条件のログ・グループにないソース・テーブルの列は、実際のソース・テーブルの値を反映せずに、チェンジ・テーブルにおいてNULLとなります。この例では、sh.products表の行のみをキャプチャします。ソース・データベースDBAは、チェンジ・テーブルが作成される各ソース・テーブルについて、この手順を繰り返します。

    ALTER TABLE sh.products
    ADD SUPPLEMENTAL LOG GROUP log_group_products
      (PROD_ID, PROD_NAME, PROD_LIST_PRICE) ALWAYS;
    

    行の列が更新されたらすぐにその行のすべての列値をキャプチャする場合、ALTER TABLE文に各列を1つずつリストするのではなく、次の文を使用できます。ただし、すべての列を必要としない場合、この形式のALTER TABLE文は使用しないでください。すべての列のロギングを実行すると、選択した列のみのロギングよりも大きなオーバーヘッドが生じます。

    ALTER TABLE sh.products ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
    

    ARCHIVELOGモードでのデータベースの運用およびFORCE LOGGINGモードについては、『Oracle Database管理者ガイド』を参照してください。サプリメンタル・ロギングの詳細は、「非同期チェンジ・データ・キャプチャとサプリメンタル・ロギング」および『Oracle Databaseユーティリティ』を参照してください。

手順3   ソース・データベースDBA: パブリッシャに対する権限の作成および付与

ソース・データベースDBAは、チェンジ・データ・キャプチャのパブリッシャとなるユーザー(cdcpubなど)を作成し、必要な権限をそのパブリッシャに付与することで、チェンジ・データ・キャプチャのチェンジ・セットおよびチェンジ・テーブルをソース・データベース上に作成するために必要な基底のOracle Streams操作をそのパブリッシャが実行できるようにします(「パブリッシャとなるユーザーの作成」を参照)。この例では、表領域ts_cdcpubがすでに作成済であるものとします。

CREATE USER cdcpub IDENTIFIED EXTERNALLY DEFAULT TABLESPACE ts_cdcpub
QUOTA UNLIMITED ON SYSTEM 
QUOTA UNLIMITED ON SYSAUX;
GRANT CREATE SESSION TO cdcpub;
GRANT CREATE TABLE TO cdcpub;
GRANT CREATE TABLESPACE TO cdcpub;
GRANT UNLIMITED TABLESPACE TO cdcpub;
GRANT SELECT_CATALOG_ROLE TO cdcpub;
GRANT EXECUTE_CATALOG_ROLE TO cdcpub;
GRANT CREATE SEQUENCE TO cdcpub;
GRANT DBA TO cdcpub;
GRANT EXECUTE on DBMS_CDC_PUBLISH TO cdcpub;

EXECUTE DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE(GRANTEE => 'cdcpub');

HotLogチェンジ・データ・キャプチャでは、ソース・データベースとステージング・データベースは同じデータベースであることに注意してください。

手順4   ソース・データベースDBA: ソース・テーブルの準備

ソース・データベースDBAは、各ソース・テーブルをインスタンス化することによって、非同期チェンジ・データ・キャプチャのソース・データベース上にソース・テーブルを準備する必要があります。各ソース・テーブルをインスタンス化すると、基底のOracle Streams環境で、各ソース・テーブルの変更のキャプチャに必要な情報が記録されます。ソース・テーブルの構造および列データ型は、チェンジ・データ・キャプチャでサポートされる必要があります。詳細は、「非同期チェンジ・データ・キャプチャでサポートされるデータ型と表構造」を参照してください。

BEGIN
DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION(TABLE_NAME => 'sh.products');
END;
/
手順5   ステージング・データベースのパブリッシャ: チェンジ・セットの作成

パブリッシャは、ステージング・データベース上でDBMS_CDC_PUBLISH.CREATE_CHANGE_SETプロシージャを使用してチェンジ・セットを作成します。チェンジ・データ・キャプチャによってチェンジ・セットが作成される際に、関連するOracle Streamsの取得プロセスと適用プロセスも作成される(開始はされない)ことに注意してください。

次の例では、今日から発生する変更をキャプチャし、5日後に変更データのキャプチャを終了するCHICAGO_DAILYというチェンジ・セットを作成します。

BEGIN
       DBMS_CDC_PUBLISH.CREATE_CHANGE_SET(
       change_set_name => 'CHICAGO_DAILY',
       description => 'Change set for product info',
       change_source_name => 'HOTLOG_SOURCE',
       stop_on_ddl => 'y',
       begin_date => sysdate,
       end_date => sysdate+5);
END;
/

チェンジ・セットは、事前定義のチェンジ・ソースHOTLOG_SOURCEから変更をキャプチャします。

手順6   ステージング・データベースのパブリッシャ: ソース・テーブルに対する変更を格納するチェンジ・テーブルの作成

パブリッシャは、ステージング・データベース上でDBMS_CDC_PUBLISH.CREATE_CHANGE_TABLEプロシージャを使用してチェンジ・テーブルを作成します。

パブリッシャは、公開される各ソース・テーブルについて、1つ以上のチェンジ・テーブルを作成し、含める列、およびキャプチャする変更データのビフォア・イメージおよびアフター・イメージの組合せを指定します。

次の例では、ソース・データベースのソース・テーブルに加えられた変更をキャプチャするチェンジ・テーブルをステージング・データベースに作成します。例では、ソース・テーブルとして、サンプル表sh.productsを使用します。

BEGIN
   DBMS_CDC_PUBLISH.CREATE_CHANGE_TABLE(
   owner              => 'cdcpub',
   change_table_name  => 'products_ct', 
   change_set_name    => 'CHICAGO_DAILY',
   source_schema      => 'SH',
   source_table       => 'PRODUCTS',
   column_type_list   => 'PROD_ID NUMBER(6), PROD_NAME VARCHAR2(50),
      PROD_LIST_PRICE NUMBER(8,2)',
   capture_values     => 'both',
   rs_id              => 'y',
   row_id             => 'n',
   user_id            => 'n',
   timestamp          => 'n',
   object_id          => 'n',
   source_colmap      => 'n',
   target_colmap      => 'y',
   options_string     => 'TABLESPACE TS_CHICAGO_DAILY');
END;
/

この文では、チェンジ・セットCHICAGO_DAILY内にproducts_ctという名前のチェンジ・テーブルを作成します。column_type_listパラメータには、このチェンジ・テーブルによりキャプチャされる列を指定します。source_schemaおよびsource_tableパラメータには、ソース・データベースにあるスキーマおよびソース・テーブルを指定します。

この文におけるcapture_values設定は、更新操作で変更された各行について、変更データが2つの別個の行を持つことを示します。1つ目の行には更新前の行値が含まれ、2つ目の行には更新後の行値が含まれます。

この文のoptions_stringパラメータは、チェンジ・テーブルの表領域を指定します。この例では、パブリッシャがすでにTS_CHICAGO_DAILY表領域を作成済であるものとします。

詳細は、「チェンジ・テーブルの管理」を参照してください。

手順7   ステージング・データベースのパブリッシャ: チェンジ・セットの有効化

非同期チェンジ・セットは作成時には常に無効化されているため、パブリッシャがチェンジ・セットを変更して有効化する必要があります。チェンジ・セットを有効化すると、Oracle Streamsの取得プロセスおよび適用プロセスが開始されます。

BEGIN
   DBMS_CDC_PUBLISH.ALTER_CHANGE_SET(
      change_set_name => 'CHICAGO_DAILY',
      enable_capture => 'y');
END;
/
手順8   ステージング・データベースのパブリッシャ: サブスクライバへのアクセス権の付与

パブリッシャは、ユーザーおよびロールに対してチェンジ・テーブルへのSELECT権限の付与および取消しを行うことで、サブスクライバの変更データへのアクセスを制御します。パブリッシャは、特定のチェンジ・テーブルへのアクセス権を付与します。この手順を行わないと、サブスクライバは変更データにアクセスできません。この例では、ユーザーsubscriber1がすでに存在しているものとします。

GRANT SELECT ON cdcpub.products_ct TO subscriber1;

これで、チェンジ・データ・キャプチャの非同期HotLogシステムが設定され、subscriber1がサブスクリプションを作成する準備ができました。

非同期分散HotLogの公開の実行

分散HotLogのチェンジ・データ・キャプチャでは、ステージング・データベースはソース・データベースとリモートです。ただし、データベース・リンク、Oracle Streamsおよびチェンジ・データ・キャプチャを設定する手順は、ソース・データベースとステージング・データベースの両方で実行する必要があります。次に、ソース・データベースDBA、ステージング・データベースDBA、および各データベースのパブリッシャが実行する必要があるタスクを示します。

  • ソース・データベースDBAは、Oracle Net、データベース初期化パラメータの設定、強制ロギングおよびサプリメンタル・ロギングを有効化するためのソース・データベースの変更、およびソース・データベースのパブリッシャの作成を行います。

  • ステージング・データベースDBAは、データベース初期化パラメータの設定およびステージング・データベースのパブリッシャの作成を行います。

  • ソース・データベースのパブリッシャは、ソース・データベースからステージング・データベースへのデータベース・リンクの設定を行います。

  • ステージング・データベースのパブリッシャは、ステージング・データベースからソース・データベースへのデータベース・リンクの設定、個々のソース・テーブルに加えられる変更を格納するチェンジ・テーブル、チェンジ・セット、チェンジ・ソースの新規作成、および必要な権限のサブスクライバへの付与を行います。

この例では、ソース・データベースDBA、ステージング・データベースDBA、および各データベースのパブリッシャは4人の異なるユーザーとします。

手順1   ソース・データベースDBA: ソース・データベースの準備

ソース・データベースDBAは、次のタスクを実行します。

  1. Oracle Netを構成して、ソース・データベースがステージング・データベースと通信できるようにします。Oracle Netについては、『Oracle Database Net Services管理者ガイド』を参照してください。

  2. 「チェンジ・データ・キャプチャの公開用初期化パラメータの設定」で説明しているように、ソース・データベース上でデータベース初期化パラメータを設定します。次のコード例では、ソース・データベースがOracle Databaseリリース11.2、計画しているチェンジ・ソースの数が1、およびSTREAMS_POOL_SIZEパラメータの現行値が50MBです。

    compatible = 11.0
    global_names = true
    job_queue_processes = <current value> + 2
    open_links = 4
    
    parallel_max_servers = <current value> + 3
    processes = <current value> + 4
    sessions = <current value> + 1
    streams_pool_size = <current value> + 20 MB
    undo_retention = 3600
    
手順2   ステージング・データベースDBA: データベース初期化パラメータの設定

ステージング・データベースDBAは、次のタスクを実行します。

  1. 「チェンジ・データ・キャプチャの公開用初期化パラメータの設定」で説明しているように、ステージング・データベース上でデータベース初期化パラメータを設定します。この例では、1つのチェンジ・セットが定義されます。STREAMS_POOL_SIZEパラメータの現行値は50MB以上です。

    compatible = 11.0
    global_names = true
    java_pool_size = 50000000
    open_links = 4
    job_queue_processes = 2
    parallel_max_servers = <current_value> + 2
    processes = <current_value> + 3
    sessions = <current value> + 1
    streams_pool_size = <current_value> + 11 MB
    undo_retention = 3600
    
手順3   ソース・データベースDBA: ソース・データベースの変更

ソース・データベースDBAは、次の3つのタスクを実行します。2つ目は必須です。1つ目と3つ目はオプションですが、実行することをお薦めします。データベースは現在、ARCHIVELOGモードで実行されているものとします。

  1. データベースをFORCE LOGGINGロギング・モードに設定し、非同期チェンジ・データ・キャプチャではキャプチャできない、ソース・データベースでのロギングされないダイレクト書込みを回避します。

    ALTER DATABASE FORCE LOGGING;
    
  2. サプリメンタル・ロギングを有効化します。サプリメンタル・ロギングによって、更新操作を実行するとすぐに、追加の列データがREDOログ・ファイルに配置されます。

    ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
    
  3. ソース・テーブルでキャプチャされるすべての列に対して、無条件のログ・グループを作成します。変更されない、無条件のログ・グループにないソース・テーブルの列は、実際のソース・テーブルの値を反映せずに、チェンジ・テーブルにおいてNULLとなります。この例では、sh.products表の行のみをキャプチャします。ソース・データベースDBAは、チェンジ・テーブルが作成される各ソース・テーブルについて、この手順を繰り返します。

    ALTER TABLE sh.products
    ADD SUPPLEMENTAL LOG GROUP log_group_products
        (PROD_ID, PROD_NAME, PROD_LIST_PRICE) ALWAYS;
    

    行の列が更新されたらすぐにその行のすべての列値をキャプチャする場合、ALTER TABLE文に各列を1つずつリストするのではなく、次の文を使用できます。ただし、すべての列を必要としない場合、この形式のALTER TABLE文は使用しないでください。すべての列のロギングを実行すると、選択した列のみのロギングよりも大きなオーバーヘッドが生じます。

    ALTER TABLE sh.products ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
    

    関連項目:


手順4   ソース・データベースDBA: パブリッシャに対する権限の作成および付与

ソース・データベースDBAは、ソース・データベースのパブリッシャとなるユーザー(source_cdcpubなど)を作成し、必要な権限をそのパブリッシャに付与することで、ソース・データベースからステージング・データベースのパブリッシャに接続するためのデータベース・リンクをそのパブリッシャが設定できるようにします(「パブリッシャとなるユーザーの作成」を参照)。次に例を示します。

CREATE USER source_cdcpub IDENTIFIED EXTERNALLY
   QUOTA UNLIMITED ON SYSTEM
   QUOTA UNLIMITED ON SYSAUX;
GRANT CREATE SESSION TO source_cdcpub;
GRANT DBA TO source_cdcpub;
GRANT CREATE DATABASE LINK TO source_cdcpub;
GRANT EXECUTE on DBMS_CDC_PUBLISH TO source_cdcpub;
GRANT EXECUTE_CATALOG_ROLE TO source_cdcpub;
GRANT SELECT_CATALOG_ROLE TO source_cdcpub;
EXECUTE DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE(
      GRANTEE=> 'source_cdcpub');
手順5   ステージング・データベースDBA: パブリッシャに対する権限の作成および付与

ステージング・データベースDBAは、チェンジ・データ・キャプチャのパブリッシャとなるユーザー(staging_cdcpubなど)を作成し、必要な権限をそのパブリッシャに付与することで、基本的なOracle Streams操作の実行、ステージング・データベースからソース・データベースのパブリッシャに接続するデータベース・リンクの作成、ソース・データベース上でのチェンジ・ソースの作成、およびステージング・データベース上でのチェンジ・セットおよびチェンジ・テーブルの作成を、そのパブリッシャが実行できるようにします(「パブリッシャとなるユーザーの作成」を参照)。次に例を示します。

CREATE USER staging_cdcpub IDENTIFIED EXTERNALLY
   DEFAULT TABLESPACE ts_cdcpub
   QUOTA UNLIMITED ON SYSTEM;
GRANT CREATE SESSION TO staging_cdcpub;
GRANT CREATE TABLE TO staging_cdcpub;
GRANT CREATE TABLESPACE TO staging_cdcpub;
GRANT UNLIMITED TABLESPACE TO staging_cdcpub;
GRANT SELECT_CATALOG_ROLE TO staging_cdcpub;
GRANT EXECUTE_CATALOG_ROLE TO staging_cdcpub;
GRANT CONNECT, RESOURCE, DBA TO staging_cdcpub;
GRANT CREATE SEQUENCE TO staging_cdcpub;
EXECUTE DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE(grantee => 'staging_cdcpub');
GRANT CREATE DATABASE LINK TO staging_cdcpub;
手順6   ソース・データベースのパブリッシャ: データベース・リンクの作成

ソース・データベースのパブリッシャは、ソース・データベースからステージング・データベースへのリンクを作成します。GLOBAL_NAMES初期化パラメータをTRUEに設定しているので、データベース・リンクの名前はステージング・データベースの名前と同じになります。このリンクは、ステージング・データベースのパブリッシャのユーザー名およびパスワードを使用してステージング・データベースに接続します。この例では、ステージング・データベースの名前はstaging_dbになっています。

CREATE DATABASE LINK staging_db
CONNECT TO staging_cdcpub IDENTIFIED BY Stg395V3
USING 'staging_db';

データベース・リンクの詳細は、『Oracle Database管理者ガイド』を参照してください。

手順7   ステージング・データベースのパブリッシャ: データベース・リンクの作成

ステージング・データベースのパブリッシャは、ステージング・データベースからソース・データベースへのリンクを作成します。ここでも、GLOBAL_NAMES初期化パラメータをTRUEに設定しているので、データベース・リンクの名前はソース・データベースの名前と同じになります。このリンクは、ソース・データベースのパブリッシャのユーザー名およびパスワードを使用してソース・データベースに接続します。この例では、ソース・データベースの名前はsource_dbになっています。

CREATE DATABASE LINK source_db
CONNECT TO source_cdcpub IDENTIFIED BY Lvh412A7
USING 'source_db';

このデータベース・リンクは、分散HotLogのチェンジ・ソース、チェンジ・セットおよびチェンジ・テーブルの作成、変更または削除時には存在している必要があります。ただし、このデータベース・リンクは、変更のキャプチャのために必要ではありません。必要な分散HotLogのチェンジ・ソース、チェンジ・セットおよびチェンジ・テーブルを配置および有効化すると、変更のキャプチャを妨げずにこのデータベース・リンクを削除できます。データベース・リンクを削除した場合、分散HotLogのチェンジ・ソース、チェンジ・セットおよびチェンジ・テーブルを作成、変更または削除する際に再作成する必要があります。

手順8   ステージング・データベースのパブリッシャ: チェンジ・ソース・データベースの識別およびチェンジ・ソースの作成

ステージング・データベースのパブリッシャは、ステージング・データベース上でDBMS_CDC_PUBLISH.CREATE_HOTLOG_CHANGE_SOURCEプロシージャを使用して、ソース・データベース上に分散HotLogチェンジ・ソースを作成します。

チェンジ・データ・キャプチャによってチェンジ・ソースが作成される際に、関連するOracle Streamsの取得プロセスも作成される(開始はされない)ことに注意してください。

パブリッシャは、分散HotLogチェンジ・ソースを作成し、ステージング・データベースからソース・データベースに定められるデータベース・リンクを指定します。データベース・リンクの名前は、ソース・データベースの名前と同じです。

BEGIN
   DBMS_CDC_PUBLISH.CREATE_HOTLOG_CHANGE_SOURCE(
       change_source_name => 'CHICAGO',
       description => 'test source',
       source_database => 'source_db');
END;
/
手順9   ステージング・データベースのパブリッシャ: チェンジ・セットの作成

パブリッシャは、ステージング・データベース上でDBMS_CDC_PUBLISH.CREATE_CHANGE_SETプロシージャを使用してチェンジ・セットを作成します。分散HotLogチェンジ・ソースには、同じステージング・データベース上の1つ以上のチェンジ・セットを格納できます。開始および終了の日付をパブリッシャが指定することはできません。

チェンジ・データ・キャプチャによってチェンジ・セットが作成される際に、関連するOracle Streamsの適用プロセスも作成される(開始はされない)ことに注意してください。

次の例では、今日から始まる変更をキャプチャし、無期限に変更データをキャプチャし続けるCHICAGO_DAILYというチェンジ・セットの作成方法を示します。将来のある時点で、パブリッシャがこのチェンジ・セットでの変更データのキャプチャを停止する場合は、そのチェンジ・セットを無効にしてから削除する必要があります。

BEGIN
   DBMS_CDC_PUBLISH.CREATE_CHANGE_SET(
       change_set_name => 'CHICAGO_DAILY',
       description => 'change set for product info',
       change_source_name => 'CHICAGO',
       stop_on_ddl => 'y');
END;
/
手順10   ステージング・データベースのパブリッシャ: チェンジ・テーブルの作成

パブリッシャは、ステージング・データベース上でDBMS_CDC_PUBLISH.CREATE_CHANGE_TABLEプロシージャを使用してチェンジ・テーブルを作成します。

パブリッシャは、公開される各ソース・テーブルについて、1つ以上のチェンジ・テーブルを作成し、含める列、およびキャプチャする変更データのビフォア・イメージおよびアフター・イメージの組合せを指定します。

パブリッシャは、DBMS_CDC_PUBLISH.CREATE_CHANGE_TABLEプロシージャのoptions_stringフィールドを設定して、チェンジ・テーブルの物理プロパティと表領域プロパティを厳密に制御できます。options_stringフィールドには、CREATE TABLE文で使用可能な、パーティション化以外の任意のオプションを指定できます。この例では、チェンジ・セットの表領域を指定しています。この例では、パブリッシャがすでにTS_CHICAGO_DAILY表領域を作成済であるものとします。

次の例では、ソース・データベースのソース・テーブルに加えられた変更をキャプチャするチェンジ・テーブルをステージング・データベースに作成します。例では、サンプル表sh.productsを使用します。

BEGIN
   DBMS_CDC_PUBLISH.CREATE_CHANGE_TABLE(
       owner             => 'staging_cdcpub',
       change_table_name => 'products_ct',
       change_set_name   => 'CHICAGO_DAILY',
       source_schema     => 'SH',
       source_table      => 'PRODUCTS',
       column_type_list  => 'PROD_ID NUMBER(6), PROD_NAME VARCHAR2(50),
          PROD_LIST_PRICE NUMBER(8,2),
          JOB_ID VARCHAR2(10), DEPARTMENT_ID NUMBER(4)',
       capture_values    => 'both',
       rs_id             => 'y',
       row_id            => 'n',
       user_id           => 'n',
       timestamp         => 'n',
       object_id         => 'n',
       source_colmap     => 'n',
       target_colmap     => 'y',
       options_string    => 'TABLESPACE TS_CHICAGO_DAILY');
END;
/

この例では、チェンジ・セットCHICAGO_DAILY内にproducts_ctという名前のチェンジ・テーブルを作成します。column_type_listパラメータには、このチェンジ・テーブルによりキャプチャされる列を指定します。source_schemaおよびsource_tableパラメータには、ソース・データベース(ステージング・データベースではない)にあるスキーマおよびソース・テーブルを指定します。

例におけるcapture_values設定は、更新操作で変更された各行について、変更データが2つの別個の行を持つことを示します。1つ目の行には更新前の行値が含まれ、2つ目の行には更新後の行値が含まれます。分散HotLogチェンジ・セットの場合、object_idおよびsource_colmapキャプチャ値は、'n'に設定する必要があります。チェンジ・ソースのリリースが9.2または10.1の場合は、row_idおよびuser_id'n'に設定する必要があります。

詳細は、「チェンジ・テーブルの管理」を参照してください。

手順11   ステージング・データベースのパブリッシャ: チェンジ・ソースの有効化

分散HotLogチェンジ・ソースは作成時には常に無効化されているため、パブリッシャがチェンジ・ソースを変更して有効化する必要があります。チェンジ・ソースを有効化すると、Oracle Streamsの取得プロセスが開始されます。

BEGIN
  DBMS_CDC_PUBLISH.ALTER_HOTLOG_CHANGE_SOURCE(
    change_source_name => 'CHICAGO',
    enable_source      => 'Y');
END;
/
手順12   ステージング・データベースのパブリッシャ: チェンジ・セットの有効化

非同期チェンジ・セットは作成時には常に無効化されているため、パブリッシャがチェンジ・セットを変更して有効化する必要があります。チェンジ・セットを有効化すると、Oracle Streamsの適用プロセスが開始されます。

BEGIN
   DBMS_CDC_PUBLISH.ALTER_CHANGE_SET(
       change_set_name => 'CHICAGO_DAILY',
       enable_capture  => 'y');
END;
/
手順13   ステージング・データベースのパブリッシャ: サブスクライバへのアクセス権の付与

パブリッシャは、ステージング・データベースにおけるユーザーおよびロールに対してチェンジ・テーブルへのSELECT権限の付与および取消しを行うことで、サブスクライバの変更データへのアクセスを制御します。パブリッシャは、特定のチェンジ・テーブルへのアクセス権を付与します。この手順を行わないと、サブスクライバはどのような変更データにもアクセスできません。この例では、ユーザーsubscriber1がすでに存在しているものとします。

GRANT SELECT ON staging_cdcpub.products_ct TO subscriber1;

これで、チェンジ・データ・キャプチャの分散HotLogシステムが設定され、subscriber1がサブスクリプションを作成する準備ができました。

非同期AutoLogの公開の実行

チェンジ・データ・キャプチャはOracle Streamsのダウンストリーム・キャプチャを使用して、非同期AutoLogの公開を実行します。チェンジ・データ・キャプチャのステージング・データベースは、Streams環境において、ダウンストリーム・データベースとみなされます。非同期AutoLogオンライン・オプションでは、Streamsのリアルタイム・ダウンストリーム・キャプチャが使用されます。非同期AutoLogアーカイブ・オプションでは、Streamsのアーカイブ・ログ・ダウンストリーム・キャプチャが使用されます。Oracle Streamsのダウンストリーム・キャプチャの詳細は、『Oracle Streams概要および管理』を参照してください。

非同期AutoLogのチェンジ・データ・キャプチャでは、パブリッシャは、新しいチェンジ・ソースに加え、個々のソース・テーブルに加えられる変更を格納するチェンジ・テーブルおよびチェンジ・セットを作成します。

非同期AutoLogの公開のために、REDO転送サービス、Streamsおよびチェンジ・データ・キャプチャを設定する手順は、ソース・データベースとステージング・データベースの両方で実行する必要があります。ソース・データベースとステージング・データベースは通常、別個のシステム上にあるため、この例では、ソース・データベースDBA、ステージング・データベースDBAおよびパブリッシャが別々のユーザーであるものとします。

手順1   ソース・データベースDBA: ソース・データベースからのREDOログ・ファイルのコピーの準備

ソース・データベースDBAおよびステージング・データベースDBAは、次のように、REDO転送サービスを設定して、ソース・データベースからステージング・データベースにREDOログ・ファイルをコピーし、ステージング・データベースでこれらのREDOログ・ファイルを受け取る準備をする必要があります。

  1. ソース・データベースDBAはOracle Netを構成して、ソース・データベースがステージング・データベースと通信できるようにします。Oracle Netについては、『Oracle Database Net Services管理者ガイド』を参照してください。

  2. ソース・データベースDBAは、「チェンジ・データ・キャプチャの公開用初期化パラメータの設定」で説明しているように、ソース・データベース上でデータベース初期化パラメータを設定します。次のコード例のSTAGINGDBは、ステージング・データベースのネットワーク名です。

    次に、AutoLogオンライン・オプションの例を示します。

    compatible = 11.0
    log_archive_dest_1 ="location=/oracle/dbs mandatory reopen=5"
    log_archive_dest_2 ="service=stagingdb lgwr async optional noregister reopen=5
                         valid_for=(online_logfile,primary_role)" 
    log_archive_dest_state_1 = enable
    log_archive_dest_state_2 = enable
    log_archive_format="arch_%s_%t_%r.dbf"
    

    次に、AutoLogアーカイブ・オプションの例を示します。

    compatible = 11.0
    log_archive_dest_1="location=/oracle/dbs mandatory reopen=5"
    log_archive_dest_2 = "service=stagingdb arch optional noregister reopen=5
                          template=/usr/oracle/dbs/arch_%s_%t_%r.dbf" 
    log_archive_dest_state_1 = enable
    log_archive_dest_state_2 = enable
    log_archive_format="arch_%s_%t_%r.dbf"
    

    REDO転送サービスの詳細は、『Oracle Data Guard概要および管理』を参照してください。

手順2   ステージング・データベースDBA: データベース初期化パラメータの設定

ステージング・データベースは非同期Autolog CDCのARCHIVELOGモードで実行する必要があります。ステージング・データベースDBAは、「チェンジ・データ・キャプチャの公開用初期化パラメータの設定」で説明しているように、ステージング・データベース上でデータベース初期化パラメータを設定します。これらの例では、1つのチェンジ・セットが定義されます。STREAMS_POOL_SIZEの現行値は50MB以上です。

次に、AutoLogオンライン・オプションの例を示します。

compatible = 11.0
global_names = true
java_pool_size = 50000000
log_archive_dest_1="location=/oracle/dbs mandatory reopen=5
                    valid_for=(online_logfile,primary_role)"
log_archive_dest_2="location=/usr/oracle/dbs mandatory
                    valid_for=(standby_logfile,primary_role)"
log_archive_dest_state_1=enable
log_archive_dest_state_2=enable
log_archive_format="arch_%s_%t_%r.dbf"
job_queue_processes = 2
parallel_max_servers = <current_value> + 5
processes = <current_value> + 7
sessions = <current value> + 2
streams_pool_size = <current_value> + 21 MB
undo_retention = 3600

次に、AutoLogアーカイブ・オプションの例を示します。

compatible = 11.0
global_names = true
java_pool_size = 50000000
log_archive_dest_1="location=/oracle/dbs mandatory reopen=5
                    valid_for=(online_logfile,primary_role)"
log_archive_dest_2="location=/oracle/stdby mandatory
                    valid_for=(standby_logfile,primary_role)"
log_archive_dest_state_1=enable
log_archive_dest_state_2=enable
log_archive_format="arch_%s_%t_%r.dbf"
job_queue_processes = 2
parallel_max_servers = <current_value> + 5
processes = <current_value> + 7
sessions = <current value> + 2
streams_pool_size = <current_value> + 21 MB
undo_retention = 3600
手順3   ソース・データベースDBA: ソース・データベースの変更

ソース・データベースDBAは、次の3つのタスクを実行します。2つ目は必須です。1つ目と3つ目はオプションですが、実行することをお薦めします。データベースは現在、ARCHIVELOGモードで実行されているものとします。

  1. データベースをFORCE LOGGINGロギング・モードに設定し、非同期チェンジ・データ・キャプチャではキャプチャできない、ソース・データベースでのロギングされないダイレクト書込みを回避します。

    ALTER DATABASE FORCE LOGGING;
    
  2. サプリメンタル・ロギングを有効化します。サプリメンタル・ロギングによって、更新操作を実行するとすぐに、追加の列データがREDOログ・ファイルに配置されます。

    ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
    
  3. ソース・テーブルでキャプチャされるすべての列に対して、無条件のログ・グループを作成します。変更されない、無条件のログ・グループにないソース・テーブルの列は、実際のソース・テーブルの値を反映せずに、チェンジ・テーブルにおいてNULLとなります。この例では、sh.products表の行のみをキャプチャします。ソース・データベースDBAは、チェンジ・テーブルが作成される各ソース・テーブルについて、この手順を繰り返します。

    ALTER TABLE sh.products
    ADD SUPPLEMENTAL LOG GROUP log_group_products
        (PROD_ID, PROD_NAME, PROD_LIST_PRICE) ALWAYS;
    

    行の列が更新されたらすぐにその行のすべての列値をキャプチャする場合、ALTER TABLE文に各列を1つずつリストするのではなく、次の文を使用できます。ただし、すべての列を必要としない場合、この形式のALTER TABLE文は使用しないでください。すべての列のロギングを実行すると、選択した列のみのロギングよりも大きなオーバーヘッドが生じます。

    ALTER TABLE sh.products ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
    

    ARCHIVELOGモードでのデータベースの運用については、『Oracle Database管理者ガイド』を参照してください。サプリメンタル・ロギングの詳細は、「非同期チェンジ・データ・キャプチャとサプリメンタル・ロギング」および『Oracle Databaseユーティリティ』を参照してください。

手順4   ステージング・データベースDBA: スタンバイREDOログ・ファイルの作成

この手順は、AutoLogオンライン・オプションにのみ必要となります。

ステージング・データベースDBAは、ステージング・データベース上にスタンバイREDOログ・ファイルを実際に作成する必要があります。

  1. ソース・データベース上で使用されるログ・ファイルのサイズを決定します。スタンバイREDOログ・ファイルはこのサイズと同じかそれ以上にする必要があるためです。ソース・データベースに対してV$LOGを問い合せると、ソース・データベースのログ・ファイルのサイズを確認できます。

  2. ステージング・データベース上で必要なスタンバイ・ログ・ファイル・グループの数を決定します。この数は、ソース・データベース上のオンライン・ログ・ファイル・グループの数より少なくとも1以上大きな数にする必要があります。ソース・データベースに対してV$LOGを問い合せると、ソース・データベース上のオンライン・ログ・ファイル・グループの数を確認できます。

  3. SQL文ALTER DATABASE ADD STANDBY LOGFILEを使用して、ステージング・データベースにスタンバイ・ログ・ファイル・グループを追加します。

    ALTER DATABASE ADD STANDBY LOGFILE GROUP 3
        ('/oracle/dbs/slog3a.rdo', '/oracle/dbs/slog3b.rdo') SIZE 500M;
    

    ステージング・データベースに対してV$STANDBY_LOGを問い合せると、スタンバイ・ログ・ファイル・グループが正常に追加されていることが確認できます。

手順5   ステージング・データベースDBA: パブリッシャに対する権限の作成および付与

ステージング・データベースDBAは、チェンジ・データ・キャプチャのパブリッシャとなるユーザー(cdcpubなど)を作成し、必要な権限をそのパブリッシャに付与することで、チェンジ・データ・キャプチャのチェンジ・ソース、チェンジ・セットおよびチェンジ・テーブルをステージング・データベース上に作成するために必要な基本的なOracle Streams操作をそのパブリッシャが実行できるようにします(「パブリッシャとなるユーザーの作成」を参照)。次に例を示します。

CREATE USER cdcpub IDENTIFIED EXTERNALLY DEFAULT TABLESPACE ts_cdcpub
   QUOTA UNLIMITED ON SYSTEM
   QUOTA UNLIMITED ON SYSAUX;
GRANT CREATE SESSION TO cdcpub;
GRANT CREATE TABLE TO cdcpub;
GRANT CREATE TABLESPACE TO cdcpub;
GRANT UNLIMITED TABLESPACE TO cdcpub;
GRANT SELECT_CATALOG_ROLE TO cdcpub;
GRANT EXECUTE_CATALOG_ROLE TO cdcpub;
GRANT DBA TO cdcpub;
GRANT CREATE SEQUENCE TO cdcpub;
GRANT EXECUTE on DBMS_CDC_PUBLISH TO cdcpub;
EXECUTE DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE(grantee => 'cdcpub');
手順6   ソース・データベースDBA: LogMinerデータ・ディクショナリの作成

ソース・データベースDBAは、ソース・データベースでLogMinerデータ・ディクショナリを作成することで、REDO転送サービスによって、このデータ・ディクショナリをステージング・データベースに転送できるようにします。LogMinerデータ・ディクショナリを作成することによって、変更データのキャプチャを開始する直前の表定義が提供されます。チェンジ・データ・キャプチャは、変更データのキャプチャの過程で行われるソース・テーブルのデータ定義言語(DDL)操作で、自動的にデータ・ディクショナリを更新します。これによって、ディクショナリが常にソース・データベース表と同期していることが保証されます。

LogMinerデータ・ディクショナリを作成する際、ソース・データベースDBAは、データ・ディクショナリ作成のSCN値を取得する必要があります。手順8で、パブリッシャはチェンジ・ソースを作成する際に、first_scnパラメータとしてこの値を指定する必要があります。

SET SERVEROUTPUT ON
VARIABLE f_scn NUMBER;
BEGIN
    :f_scn := 0;
    DBMS_CAPTURE_ADM.BUILD(:f_scn);
    DBMS_OUTPUT.PUT_LINE('The first_scn value is ' || :f_scn);
END;
/
The first_scn value is 207722

非同期AutoLogの公開を機能させるには、ソース・データベースDBAは、ソース・テーブルを準備する前にデータ・ディクショナリを作成する(およびその作成を完了させる)ことが重要となります。ソース・データベースDBAは、手順6および手順7をここで示している順番どおりに注意して実行する必要があります。

LogMinerデータ・ディクショナリの詳細は、『Oracle Streams概要および管理』を参照してください。

手順7   ソース・データベースDBA: ソース・テーブルの準備

ソース・データベースDBAは、非同期チェンジ・データ・キャプチャに対して、各ソース・テーブルをインスタンス化することによって、ソース・データベース上にソース・テーブルを準備する必要があります。これによって、基底のOracle Streams環境で、各ソース・テーブルの変更のキャプチャに必要な情報が記録されます。ソース・テーブルの構造および列データ型は、チェンジ・データ・キャプチャでサポートされる必要があります。詳細は、「非同期チェンジ・データ・キャプチャでサポートされるデータ型と表構造」を参照してください。

BEGIN
   DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION(
       TABLE_NAME => 'sh.products');
END;
/
手順8   ソース・データベースDBA: ソース・データベースのグローバル名の取得

手順8で、パブリッシャは、ソース・データベースのグローバル名を参照する必要があります。ソース・データベースのグローバル名は、AutoLogチェンジ・ソースを作成するためにステージング・データベース上で使用されます。ソース・データベースDBAは、ソース・データベースにおけるGLOBAL_NAMEビューのGLOBAL_NAME列を問い合せて、パブリッシャのこの情報を取得できます。

SELECT GLOBAL_NAME FROM GLOBAL_NAME;
GLOBAL_NAME                                                                     
----------------------------------------------------------------------------
HQDB 
手順9   ステージング・データベースのパブリッシャ: 各チェンジ・ソース・データベースの識別およびチェンジ・ソースの作成

パブリッシャは、ステージング・データベース上でDBMS_CDC_PUBLISH.CREATE_AUTOLOG_CHANGE_SOURCEプロシージャを使用してチェンジ・ソースを作成します。

キャプチャ・システムの管理プロセスは、チェンジ・ソースの作成から始まります。チェンジ・ソースは、データのキャプチャ対象のソース・データベースを記述し、ソース・データベースとステージング・データベースとの間の関係を管理します。チェンジ・ソースは、ソース・データベースからのデータ・ディクショナリ作成のSCNをfirst_scnパラメータとして常に指定します。

パブリッシャは、データ・ディクショナリ作成のSCN、およびグローバル・データベース名をソース・データベースDBAから取得します(それぞれ手順6と手順8を参照)。パブリッシャが、ソース・データベースDBAからfirst_scnパラメータ値に使用する値を取得できない場合は、適切な権限を使用し、ソース・データベースにおけるV$ARCHIVED_LOGビューの問合せを実行して、値を確認できます。詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』DBMS_CDC_PUBLISHの章を参照してください。

ステージング・データベースでは、パブリッシャはAutoLogチェンジ・ソースを作成し、source_databaseパラメータ値としてグローバル名を、first_scnパラメータ値としてデータ・ディクショナリ作成のSCNを指定します。次のようにしてAutoLogオンライン・チェンジ・ソースを作成します。

BEGIN
   DBMS_CDC_PUBLISH.CREATE_AUTOLOG_CHANGE_SOURCE(
       change_source_name  => 'CHICAGO',
       description         => 'test source',
       source_database     => 'HQDB',
       first_scn           => 207722,
       online_log          => 'y');
END;
/

次のようにしてAutoLogアーカイブ・チェンジ・ソースを作成します。

BEGIN
   DBMS_CDC_PUBLISH.CREATE_AUTOLOG_CHANGE_SOURCE(
       change_source_name   => 'CHICAGO',
       description          => 'test source',
       source_database      => 'HQDB',
       first_scn            => 207722);
END;
/
手順10   ステージング・データベースのパブリッシャ: チェンジ・セットの作成

パブリッシャは、ステージング・データベース上でDBMS_CDC_PUBLISH.CREATE_CHANGE_SETプロシージャを使用してチェンジ・セットを作成します。パブリッシャは、データ・キャプチャの開始および終了箇所を示すために、開始および終了の日付をオプションで提供できます。

チェンジ・データ・キャプチャによってチェンジ・セットが作成される際に、関連するOracle Streamsの取得プロセスと適用プロセスも作成される(開始はされない)ことに注意してください。

次の例では、今日から始まる変更をキャプチャし、無期限に変更データをキャプチャし続けるCHICAGO_DAILYというチェンジ・セットの作成方法を示します。将来のある時点で、パブリッシャがこのチェンジ・セットでの変更データのキャプチャを停止する場合は、そのチェンジ・セットを無効にしてから削除する必要があります。

BEGIN
   DBMS_CDC_PUBLISH.CREATE_CHANGE_SET(
       change_set_name    => 'CHICAGO_DAILY',
       description        => 'change set for product info',
       change_source_name => 'CHICAGO',
       stop_on_ddl        => 'y');
END;
/
手順11   ステージング・データベースのパブリッシャ: チェンジ・テーブルの作成

パブリッシャは、ステージング・データベース上でDBMS_CDC_PUBLISH.CREATE_CHANGE_TABLEプロシージャを使用してチェンジ・テーブルを作成します。

パブリッシャは、公開される各ソース・テーブルについて、1つ以上のチェンジ・テーブルを作成し、含める列、およびキャプチャする変更データのビフォア・イメージおよびアフター・イメージの組合せを指定します。

パブリッシャは、DBMS_CDC_PUBLISH.CREATE_CHANGE_TABLEプロシージャのoptions_stringフィールドを設定して、チェンジ・テーブルの物理プロパティと表領域プロパティを厳密に制御できます。options_stringフィールドには、CREATE TABLE文で使用可能な、パーティション化以外の任意のオプションを指定できます。この例では、チェンジ・セットの表領域を指定しています。この例では、パブリッシャがすでにTS_CHICAGO_DAILY表領域を作成済であるものとします。

次の例では、ソース・データベースのソース・テーブルに加えられた変更をキャプチャするチェンジ・テーブルをステージング・データベースに作成します。例では、サンプル表sh.productsを使用します。

BEGIN
   DBMS_CDC_PUBLISH.CREATE_CHANGE_TABLE(
       owner             => 'cdcpub',
       change_table_name => 'products_ct',
       change_set_name   => 'CHICAGO_DAILY',
       source_schema     => 'SH',
       source_table      => 'PRODUCTS',
       column_type_list  => 'PROD_ID NUMBER(6), PROD_NAME VARCHAR2(50),
          PROD_LIST_PRICE NUMBER(8,2)',
          JOB_ID VARCHAR2(10), DEPARTMENT_ID NUMBER(4)',
       capture_values    => 'both',
       rs_id             => 'y',
       row_id            => 'n',
       user_id           => 'n',
       timestamp         => 'n',
       object_id         => 'n',
       source_colmap     => 'n',
       target_colmap     => 'y',
       options_string    => 'TABLESPACE TS_CHICAGO_DAILY');
END;
/

この例では、チェンジ・セットCHICAGO_DAILY内にproducts_ctという名前のチェンジ・テーブルを作成します。column_type_listパラメータには、このチェンジ・テーブルによりキャプチャされる列を指定します。source_schemaおよびsource_tableパラメータには、ソース・データベース(ステージング・データベースではない)にあるスキーマおよびソース・テーブルを指定します。

例におけるcapture_values設定は、更新操作で変更された各行について、変更データが2つの別個の行を持つことを示します。1つ目の行には更新前の行値が含まれ、2つ目の行には更新後の行値が含まれます。

詳細は、「チェンジ・テーブルの管理」を参照してください。

手順12   ステージング・データベースのパブリッシャ: チェンジ・セットの有効化

非同期チェンジ・セットは作成時には常に無効化されているため、パブリッシャがチェンジ・セットを変更して有効化する必要があります。チェンジ・セットを有効化すると、Oracle Streamsの取得プロセスおよび適用プロセスが開始されます。

BEGIN
   DBMS_CDC_PUBLISH.ALTER_CHANGE_SET(
       change_set_name => 'CHICAGO_DAILY',
       enable_capture  => 'y');
END;
/
手順13   ソース・データベースDBA: ソース・データベースでのREDOログ・ファイルの切替え

データのキャプチャを開始するには、ログ・ファイルがアーカイブされる必要があります。ソース・データベースDBAは、現行のREDOログ・ファイルを切り替えることによって、プロセスを開始できます。

ALTER SYSTEM SWITCH LOGFILE;
手順14   ステージング・データベースのパブリッシャ: サブスクライバへのアクセス権の付与

パブリッシャは、ステージング・データベースにおけるユーザーおよびロールに対してチェンジ・テーブルへのSQLのSELECT権限の付与および取消しを行うことで、サブスクライバの変更データへのアクセスを制御します。パブリッシャは、特定のチェンジ・テーブルへのアクセス権を付与します。この手順を行わないと、サブスクライバはどのような変更データにもアクセスできません。この例では、ユーザーsubscriber1がすでに存在しているものとします。

GRANT SELECT ON cdcpub.products_ct TO subscriber1;

これで、チェンジ・データ・キャプチャの非同期AutoLogシステムが設定され、subscriber1がサブスクリプションを作成する準備ができました。

変更データのサブスクライブ

パブリッシャがチェンジ・テーブルを作成する際に、チェンジ・データ・キャプチャによってパブリケーションIDが割り当てられ、すべてのパブリケーションIDのリストがDBA_PUBLISHED_COLUMNSビューに格納されます。パブリケーションIDとは、パブリッシャが定義した各チェンジ・テーブルに、チェンジ・データ・キャプチャによって割り当てられる数値のことです。

サブスクライバは、使用する1つ以上のソース・テーブルを登録し、これらの表へのサブスクリプションを取得します。サブスクライバに十分なアクセス権があるとすると、サブスクライバは次のいずれかの方法で、パブリッシャが1つ以上のチェンジ・テーブルを作成したどのソース・テーブルに対してもサブスクライブできます。

次の手順では、両方のシナリオを例示する例を示します。

手順1   サブスクライバがアクセス権を付与されているソース・テーブルの検索

サブスクライバは、DBA_SOURCE_TABLESビューを問い合せて、サブスクライバがアクセス権を付与されている公開済のソース・テーブルをすべて参照します。

SELECT * FROM DBA_SOURCE_TABLES;

SOURCE_SCHEMA_NAME             SOURCE_TABLE_NAME
------------------------------ ------------------------------
SH                             PRODUCTS
手順2   サブスクライバがアクセス権を付与されている列およびチェンジ・セット名の検索

サブスクライバは、DBA_PUBLISHED_COLUMNSビューを問い合せて、サブスクライバがアクセス権を付与されているsh.products表のチェンジ・セット、列およびパブリケーションIDをすべて参照します。

SELECT UNIQUE CHANGE_SET_NAME, COLUMN_NAME, PUB_ID 
FROM DBA_PUBLISHED_COLUMNS
WHERE SOURCE_SCHEMA_NAME ='SH' AND SOURCE_TABLE_NAME = 'PRODUCTS';

CHANGE_SET_NAME     COLUMN_NAME        PUB_ID
----------------    ------------------ ------------ 
CHICAGO_DAILY       PROD_ID            41494
CHICAGO_DAILY       PROD_LIST_PRICE    41494
CHICAGO_DAILY       PROD_NAME          41494
手順3   サブスクリプションの作成

サブスクライバは、DBMS_CDC_SUBSCRIBE.CREATE_SUBSCRIPTIONプロシージャをコールして、サブスクリプションを作成します。

次の例は、サブスクライバが対象のチェンジ・セット(CHICAGO_DAILY)を指定してから、サブスクリプションが存在する期間を通して使用される一意のサブスクリプション名を指定する方法を示しています。

BEGIN
       DBMS_CDC_SUBSCRIBE.CREATE_SUBSCRIPTION(
       change_set_name   => 'CHICAGO_DAILY',
       description       => 'Change data for PRODUCTS',
       subscription_name => 'SALES_SUB');
END;
/
手順4   ソース・テーブルとその列へのサブスクライブ

サブスクライバは、DBMS_CDC_SUBSCRIBE.SUBSCRIBEプロシージャをコールして、サブスクライバが必要とするソース・テーブルの列を指定します。

サブスクリプションには、同じチェンジ・セットによって参照される1つ以上のソース・テーブルを含めることができます。

次の例では、サブスクライバは、PRODUCTS表のPROD_ID列、PROD_NAME列およびPROD_LIST_PRICE列を参照します。手順2の問合せに示すように、これらの列はすべて同じパブリケーションに含まれ、サブスクライバはそのパブリケーションに対するアクセス権を所有しているので、次のコールを使用できます。

BEGIN
       DBMS_CDC_SUBSCRIBE.SUBSCRIBE(
       subscription_name => 'SALES_SUB',
       source_schema     => 'SH',
       source_table      => 'PRODUCTS',
       column_list       => 'PROD_ID, PROD_NAME, PROD_LIST_PRICE',
       subscriber_view   => 'SALES_VIEW');
END;
/

ただし、セキュリティの理由から、パブリッシャがこれらすべての列を含む単一のチェンジ・テーブルを作成していないと仮定します。手順2に示す結果のかわりに、DBA_PUBLISHED_COLUMNSビューの問合せでは、次の例に示すように、対象の列が複数のパブリケーションに含まれていることが示されるものとします。

SELECT UNIQUE CHANGE_SET_NAME, COLUMN_NAME, PUB_ID 
FROM DBA_PUBLISHED_COLUMNS
WHERE SOURCE_SCHEMA_NAME ='SH' AND SOURCE_TABLE_NAME = 'PRODUCTS';

CHANGE_SET_NAME     COLUMN_NAME        PUB_ID
----------------    ------------------ ------------ 
CHICAGO_DAILY       PROD_ID            34883
CHICAGO_DAILY       PROD_NAME          34885
CHICAGO_DAILY       PROD_LIST_PRICE    34883
CHICAGO_DAILY       PROD_ID            34885

戻されたこのデータから、PROD_ID列がパブリケーション34883とパブリケーション34885の両方に含まれていることがわかります。単一のサブスクライブ・コールでは、単一のパブリケーションの使用可能な列を指定する必要があります。したがって、サブスクライバが両方のパブリケーションの列にサブスクライブする場合は、PROD_IDを使用してサブスクライバ・ビュー間を結合してから、それぞれ異なるパブリケーションIDを指定する次の2つのコールを使用する必要があります。

BEGIN
       DBMS_CDC_SUBSCRIBE.SUBSCRIBE(
       subscription_name => 'MULTI_PUB',
       publication_id    => 34885,
       column_list       => 'PROD_ID, PROD_NAME',
       subscriber_view   => 'prod_idname');

       DBMS_CDC_SUBSCRIBE.SUBSCRIBE(
       subscription_name => 'MULTI_PUB',
       publication_id    => 34883, 
       column_list       => 'PROD_ID, PROD_LIST_PRICE',
       subscriber_view   => 'prod_price'); 
END; 
/

DBMS_CDC_SUBSCRIBE.SUBSCRIBEコールでは、一意のサブスクライバ・ビューを指定することに注意してください。

手順5   サブスクリプションのアクティブ化

サブスクライバは、DBMS_CDC_SUBSCRIBE.ACTIVATE_SUBSCRIPTIONプロシージャをコールして、サブスクリプションをアクティブ化します。

サブスクライバは、ソース・テーブル(またはパブリケーション)へのサブスクライブを完了し、変更データを受け取る準備ができた時点で、このプロシージャをコールします。サブスクライブするソース・テーブルが1つの場合も複数の場合も、サブスクライバはACTIVATE_SUBSCRIPTIONプロシージャを1回コールするだけで済みます。

ACTIVATE_SUBSCRIPTIONプロシージャは空のサブスクライバ・ビューを作成します。この時点で、DBMS_CDC_SUBSCRIBE.SUBSCRIBEコールを行うことができます。

BEGIN
   DBMS_CDC_SUBSCRIBE.ACTIVATE_SUBSCRIPTION(
       subscription_name => 'SALES_SUB');
END;
/
手順6   変更データの次のセットの取得

サブスクライバは、DBMS_CDC_SUBSCRIBE.EXTEND_WINDOWプロシージャをコールして、次に使用できる変更データのセットを取得します。これによって、サブスクリプション・ウィンドウの高位限界が設定されます。次に例を示します。

 BEGIN
   DBMS_CDC_SUBSCRIBE.EXTEND_WINDOW(
       subscription_name => 'SALES_SUB');
END;
/

これがEXTEND_WINDOWプロシージャに対するサブスクライバの最初のコールである場合、サブスクリプション・ウィンドウには、パブリケーション内のすべての変更データが含まれます。それ以外の場合、サブスクリプション・ウィンドウには、EXTEND_WINDOWプロシージャへの最後のコールから作成された新しい変更データがすべて追加されます。

新しい変更データが追加されていない場合、サブスクリプション・ウィンドウは変化しません。

手順7   サブスクライバ・ビューの内容の読取りと問合せ

サブスクライバは、サブスクライバ・ビューでSQL文のSELECTを使用して、変更データを(サブスクリプション・ウィンドウの現行の境界内で)問い合せます。これは、サブスクリプションに含まれるサブスクライバ・ビューごとに行うことができます。次に例を示します。

SELECT PROD_ID, PROD_NAME, PROD_LIST_PRICE FROM SALES_VIEW;

PROD_ID    PROD_NAME                                          PROD_LIST_PRICE
---------- -------------------------------------------------- ---------------
30         And 2 Crosscourt Tee Kids                          14.99
30         And 2 Crosscourt Tee Kids                          17.66
10         Gurfield& Murks Pleated Trousers                   17.99
10         Gurfield& Murks Pleated Trousers                   21.99

サブスクライバ・ビューの名前SALES_VIEWは、手順4でサブスクライバがDBMS_CDC_SUBSCRIBE.SUBSCRIBEプロシージャをコールしたときに指定したものです。

手順8   変更データの現行セットが必要なくなったことの指定

サブスクライバは、DBMS_CDC_SUBSCRIBE.PURGE_WINDOWプロシージャを使用して、現在の変更データのセットを必要としなくなったことを、チェンジ・データ・キャプチャに知らせます。これは、チェンジ・データ・キャプチャによるチェンジ・テーブル内のデータ量の管理およびサブスクリプション・ウィンドウの低位限界の設定に役立ちます。DBMS_CDC_SUBSCRIBE.PURGE_WINDOWプロシージャをコールすると、サブスクリプション・ウィンドウが空になります。DBMS_CDC_SUBSCRIBE.PURGE_WINDOWの機能の詳細は、「チェンジ・テーブルの不要なデータのパージ」を参照してください。

次に例を示します。

BEGIN
   DBMS_CDC_SUBSCRIBE.PURGE_WINDOW(
       subscription_name => 'SALES_SUB');
END;
/

注意:

DBMS_CDC_PUBLISH.PURGEを使用する前にDBMS_CDC_SUBSCRIBE.EXTEND_WINDOWをコールしてください。これによって、まだサブスクライバに必要なデータを保護し、パージしてはいけない重要なデータがあることをパブリッシャに認識させることができます。

手順9   手順6から8の繰返し

サブスクライバは、追加の変更データが必要な間は、手順6から8を繰り返します。

手順10   サブスクリプションの終了

サブスクライバは、DBMS_CDC_SUBSCRIBE.DROP_SUBSCRIPTIONプロシージャを使用して、サブスクリプションを終了します。これは、サブスクリプションの基礎をなすパブリケーションが、無期限に変更データを保持することを回避するために必要です。

BEGIN
   DBMS_CDC_SUBSCRIBE.DROP_SUBSCRIPTION(
       subscription_name => 'SALES_SUB');
END;
/

公開されたデータの管理

この項では、チェンジ・セットおよびチェンジ・テーブルの管理に関わる管理タスクの情報を提供します。ほとんどの場合、これらのタスクはパブリッシャが実行します。ただし、チェンジ・テーブルから不要なデータをパージする場合は、パブリッシャとサブスクライバの両方で行う必要があります(「チェンジ・テーブルの不要なデータのパージ」を参照)。

この項では次のトピックについて説明します。

非同期チェンジ・ソースの管理

この項では、パブリッシャが非同期チェンジ・ソースの管理を行うことができるタスクに関する情報を取り上げます。次のトピックで構成されています。

非同期分散HotLogチェンジ・ソースの有効化および無効化

パブリッシャは、非同期分散HotLogチェンジ・ソースを有効化または無効化できます。チェンジ・ソースが無効化されると、有効化されるまで新しい変更データを処理できません。

非同期分散HotLogチェンジ・ソースは常に無効な状態で作成されます。

パブリッシャは、次のコールでPRODUCTS_SOURCE非同期分散HotLogチェンジ・ソースを有効化できます。

BEGIN
DBMS_CDC_PUBLISH.ALTER_HOTLOG_CHANGE_SOURCE(
change_source_name => 'PRODUCTS_SOURCE',
enable_source      => 'y');
END;
/

チェンジ・ソースを有効化すると、そのチェンジ・ソースについて、Oracle Streamsの取得プロセスが開始されます。パブリッシャは、同じコールを使用(ただし、enable_sourceを'n'に設定)してPRODUCTS_SOURCE非同期分散HotLogチェンジ・ソースを無効化できます。チェンジ・ソースを無効化すると、そのチェンジ・ソースについて、Oracle Streamsの取得プロセスが停止されます。

非同期分散HotLogチェンジ・ソースおよびそのチェンジ・セットは、変更データの処理およびチェンジ・テーブルの移入を行うために別々に有効化する必要があります。詳細は、「非同期チェンジ・セットの有効化および無効化」を参照してください。

無効化されたチェンジ・ソースでは、新しい変更データを処理できませんが、チェンジ・ソースおよびそのチェンジ・セットを有効化し、変更データを処理できるようにするまで、必要なアーカイブREDOログ・ファイルが使用できる状態であれば、変更データを失うことはありません。Oracleでは、可能なかぎりチェンジ・ソースおよびチェンジ・セットを有効化して、アーカイブREDOログ・ファイルを蓄積しないようにすることをお薦めします。詳細は、「非同期チェンジ・データ・キャプチャおよびREDOログ・ファイル」を参照してください。

非同期チェンジ・セットの管理

この項では、パブリッシャが非同期チェンジ・セットの管理を行うことができるタスクについて説明します。次のトピックで構成されています。

開始日および終了日を設定した非同期チェンジ・セットの作成

非同期HotLogおよびAutoLogチェンジ・ソースに関連するチェンジ・セットでは、キャプチャする変更データを制限するために、開始日および終了日をオプションで指定できます。分散HotLogチェンジ・ソースに関連するチェンジ・セットでは、開始日および終了日の指定はできません。開始日を設定していないチェンジ・セットでは、最初に使用可能となった変更データからキャプチャを開始します。終了日を設定していないチェンジ・セットでは、変更データのキャプチャが無制限に続きます。

次の例では、現時点から2日後にキャプチャを開始し、無制限にキャプチャし続けるチェンジ・セットPRODUCTS_SETをAutoLogチェンジ・ソースHQ_SOURCEに作成します。

BEGIN
DBMS_CDC_PUBLISH.CREATE_CHANGE_SET(
change_set_name    => 'PRODUCTS_SET',
description        => 'Products Application Change Set',
change_source_name => 'HQ_SOURCE',
stop_on_ddl        => 'Y',
begin_date         => sysdate+2);
END;
/

非同期チェンジ・セットの有効化および無効化

パブリッシャは、非同期チェンジ・セットを有効化または無効化できます。チェンジ・セットが無効化されると、有効化されるまで新しい変更データを処理できません。

同期チェンジ・セットは常に有効な状態で作成されます。非同期チェンジ・セットは常に無効な状態で作成されます。

パブリッシャは、次のコールでPRODUCTS_SET非同期チェンジ・セットを有効化できます。

BEGIN
DBMS_CDC_PUBLISH.ALTER_CHANGE_SET(
change_set_name => 'PRODUCTS_SET',
enable_capture  => 'y');
END;
/

非同期HotLogおよびAutoLogチェンジ・セットでは、チェンジ・セットを有効化すると、Oracle Streamsの取得プロセスおよび適用プロセスが開始されます。非同期分散HotLogチェンジ・セットでは、チェンジ・セットを有効化すると、Oracle Streamsの適用プロセスが開始されます。

パブリッシャは、同じコールを使用(ただし、enable_capture'n'に設定)してPRODUCTS_SET非同期チェンジ・セットを無効化できます。非同期HotLogおよびAutoLogチェンジ・セットでは、チェンジ・セットを無効化すると、Oracle Streamsの取得プロセスおよび適用プロセスが停止されます。非同期分散HotLogチェンジ・セットでは、チェンジ・セットを無効化すると、Oracle Streamsの適用プロセスが停止されます。

非同期分散HotLogチェンジ・ソースおよびそのチェンジ・セットは、変更データの処理およびチェンジ・テーブルの移入を行うために別々に有効化する必要があります。詳細は、「非同期分散HotLogチェンジ・ソースの有効化および無効化」を参照してください。

無効化されたチェンジ・セットでは、新しい変更データを処理できませんが、チェンジ・セットを有効化し、変更データを処理できるようにするまで、必要なアーカイブREDOログ・ファイルが使用できる状態であれば、変更データを失うことはありません。Oracleでは、可能なかぎりチェンジ・セットを有効化して、アーカイブREDOログ・ファイルを蓄積しないようにすることをお薦めします。詳細は、「非同期チェンジ・データ・キャプチャおよびREDOログ・ファイル」を参照してください。

チェンジ・データ・キャプチャは、内部キャプチャ・エラーが発生すると、非同期チェンジ・セットを自動的に無効化できます。パブリッシャは、詳細をアラート・ログで確認し、DDLに対して必要な処理を行うか、内部エラーからリカバリしてから、明示的にチェンジ・セットを有効化する必要があります。詳細は、「非同期チェンジ・セットで戻されたエラーからのリカバリ」を参照してください。

非同期チェンジ・セットのDDLでのキャプチャの停止

パブリッシャは、DDLが検出された場合に、チェンジ・データ・キャプチャでチェンジ・セットが自動的に無効化されるよう指定できます。キャプチャされているソース・テーブル列の削除など、一部のDDLコマンドは、キャプチャに悪影響を及ぼす可能性があります。チェンジ・セットがDDLで停止した場合、パブリッシャには、キャプチャを続行する前に、問題を分析および解決する機会があります。チェンジ・セットがDDLで停止しなかった場合、DDLの発生後に内部キャプチャ・エラーが発生した可能性があります。

パブリッシャは、チェンジ・セットの作成時または変更時に、チェンジ・セットがDDLで停止するかどうかを指定できます。パブリッシャは、次のコールでPRODUCTS_SETチェンジ・セットがDDLで停止するように変更できます。

BEGIN
DBMS_CDC_PUBLISH.ALTER_CHANGE_SET(
change_set_name  => 'PRODUCTS_SET',
stop_on_ddl      => 'y');
END;
/

パブリッシャは、stop_on_ddl'n'に設定して、PRODUCTS_SETチェンジ・セットがDDLで停止しないように変更できます。

DDL文によってプロセスが停止される場合、DDL文およびチェンジ・セットに関するメッセージがアラート・ログに書き込まれます。たとえば、TRUNCATE TABLE DDL文によって、PRODUCTS_SETチェンジ・セットの処理が停止される場合、アラート・ログには次のような行が含まれます。

Change Data Capture received DDL for change set PRODUCTS_SET
Change Data Capture received DDL and stopping: truncate table products

次のDDL文では列データ自体は影響されないので、stop_on_ddlパラメータを'Y'に設定している際も、チェンジ・データ・キャプチャが変更データのキャプチャを停止することはありません。

  • ANALYZE TABLE

  • LOCK TABLE

  • 表アクセスへのGRANT権限

  • 表アクセスへのREVOKE権限

  • 表に対するCOMMENT

  • 列に対するCOMMENT

これらの文は、チェンジ・データ・キャプチャ処理への影響を考慮することなく、ソース・データベースで発行可能です。たとえば、ANALYZE TABLEコマンドをPRODUCTSソース・テーブルで発行すると、ステージング・データベースのアラート・ログには、stop_on_ddlパラメータを'Y'に設定している場合に次のような行が含まれます。

Change Data Capture received DDL and ignoring: analyze table products compute statistics

非同期チェンジ・セットで戻されたエラーからのリカバリ

非同期チェンジ・データ・キャプチャ時のエラーは、様々な事情に起因していることが考えられます。チェンジ・セットがDDLで停止した場合は、キャプチャを続行する前にそのDDLを取り除く必要があります。チェンジ・セットがDDLで停止していないが、キャプチャに影響するDDL変更が発生した場合は、Oracleエラーを生じる場合があります。ディスク領域不足など、システムの状態もOracleエラーの原因となる場合があります。

これらのすべての場合で、チェンジ・セットは無効化され、エラーがあるものとしてマークされます。サブスクライバのプロシージャでチェンジ・セットにエラーが検出されると、次のメッセージが戻されます。

ORA-31514: change set disabled due to capture error

パブリッシャは、詳細をアラート・ログで確認して、根本にある問題を解決する必要があります。次に、recover_after_errorおよびremove_ddlパラメータを'y'に設定して、ALTER_CHANGE_SETをコールすることによって、エラーからのリカバリを試みることができます。

パブリッシャは、問題を解決するまで、必要なだけこの手順を繰り返すことができます。リカバリが成功すると、エラーがチェンジ・セットから取り除かれるので、パブリッシャは、非同期チェンジ・セットを有効化できます(「非同期チェンジ・セットの有効化および無効化」を参照)。

パブリッシャは、複数の連続したDDLが存在する場合、チェンジ・セットがそれぞれのDDLで別々に停止することを認識している必要があります。たとえば、2つの連続したDDLがあるとします。チェンジ・セットが最初のDDLで停止した場合、パブリッシャはそのDDLを削除し、そのチェンジ・セットに関するキャプチャを再有効化する必要があります。チェンジ・セットは次に、2つ目のDDLで停止します。パブリッシャはそのDDLを削除し、そのチェンジ・セットに関するキャプチャを再有効化する必要があります。

キャプチャ・エラーの解決に詳細な情報が必要な場合、パブリッシャは、DBA_APPLY_ERRORビューを問い合せて、Streamsの適用エラーに関する情報を参照できます(キャプチャ・エラーはStreamsの適用エラーに対応します)。パブリッシャは、キャプチャ・エラーからのリカバリには常にDBMS_CDC_PUBLISH.ALTER_CHANGE_SETプロシージャを使用する必要があります。リカバリには、Streamsとチェンジ・データ・キャプチャの両方の機能が必要で、DBMS_CDC_PUBLISH.ALTER_CHANGE_SETプロシージャのみが両方の機能を実行するためです。エラー・キューおよび適用エラーについては、『Oracle Streams概要および管理』を参照してください。

次の2つのシナリオでは、チェンジ・データ・キャプチャに戻された2つの異なるタイプのエラーを、パブリッシャが調査して、リカバリする方法を例示します。

ディスク領域不足によるエラー

パブリッシャはアラート・ログの内容を参照して、特定のチェンジ・セットについて戻されているエラーおよび処理されていないSCNを判別できます。たとえば、アラート・ログには、次のような行が含まれる場合があります(LCRは論理変更レコードを指します)。

Change Data Capture has encountered error number: 1688 for change set: 
   CHICAGO_DAILY
Change Data Capture did not process LCR with scn 219337

パブリッシャは、エラー・メッセージ・テキストについて、DBA_APPLY_ERRORビューを問い合せて、アラート・ログで指定されているエラー番号に関連するメッセージを判別できます。この場合、DBA_APPLY_ERRORビューのAPPLY_NAMEは、アラート・ログで指定されたチェンジ・セットのAPPLY_NAMEと同じです。次に例を示します。

SQL> SELECT ERROR_MESSAGE FROM DBA_APPLY_ERROR
       WHERE APPLY_NAME =
      (SELECT APPLY_NAME FROM ALL_CHANGE_SETS WHERE SET_NAME ='CHICAGO_DAILY');

ERROR_MESSAGE 
-------------------------------------------------------------------------------- 
ORA-01688: unable to extend table LOGADMIN.CT1 partition P1 by 32 in tablespace 
    TS_CHICAGO_DAILY 

エラーの原因となっている問題を修正したら、パブリッシャは、エラーからのリカバリを試行できます。たとえば、パブリッシャは次のコールを使用して、エラー後にCHICAGO_DAILYチェンジ・セットのリカバリを試行できます。

BEGIN
DBMS_CDC_PUBLISH.ALTER_CHANGE_SET(
  change_set_name     => 'CHICAGO_DAILY',
  recover_after_error => 'y');
END;
/

リカバリが成功しないとエラーが戻されるので、パブリッシャは、問題の解決を試行するためにさらなる操作を行うことになります。パブリッシャは、問題を解決するまで、必要なだけリカバリ手順を再試行できます。


注意:

リカバリが成功したら、パブリッシャはチェンジ・セットを忘れずに有効化する必要があります。有効化すると、チェンジ・データ・キャプチャによって、エラーが発生した論理変更レコード(LCR)が処理されます。この際、変更データが失われることはありません。

DDLでの停止によるエラー

SQL文のTRUNCATE TABLEPRODUCTSソース・テーブルに対して発行して、stop_on_ddlパラメータを'Y'に設定した状態で、チェンジ・セットの有効化を試みた際に次のようなエラーが戻されたとします。

ERROR at line 1:
ORA-31468: cannot process DDL change record
ORA-06512: at "SYS.DBMS_CDC_PUBLISH", line 79
ORA-06512: at line 2

アラート・ログには次のような行が含まれます。

Mon Jun  9 16:13:44 2003
Change Data Capture received DDL for change set PRODUCTS_SET
Change Data Capture received DDL and stopping: truncate table products
Mon Jun  9 16:13:50 2003
Change Data Capture did not process LCR with scn 219777
Streams Apply Server P001 pid=19 OS id=11730 stopped
Streams Apply Reader P000 pid=17 OS id=11726 stopped
Streams Apply Server P000 pid=17 OS id=11726 stopped
Streams Apply Server P001 pid=19 OS id=11730 stopped
Streams AP01 with pid=15, OS id=11722 stopped

TRUNCATE TABLE文は表のすべての行を削除するので、パブリッシャは、チェンジ・データ・キャプチャ処理を再有効化する前に、サブスクライバに通知する必要があります。サブスクリプション・ウィンドウをパージおよび拡張するようサブスクライバに提案する場合もあります。パブリッシャは次に、チェンジ・セットを変更し、remove_ddl => 'Y'パラメータおよびrecover_after_error => 'Y'パラメータを次のように指定して、チェンジ・データ・キャプチャ処理のリストアを試行できます。

BEGIN
DBMS_CDC_PUBLISH.ALTER_CHANGE_SET(
  change_set_name     => 'PRODUCTS_SET',
  recover_after_error => 'y',
  remove_ddl          => 'y');
END;
/

この手順が完了したら、アラート・ログには次のような行が含まれます。

Mon Jun  9 16:20:17 2003
Change Data Capture received DDL and ignoring: truncate table products
The scn for the truncate statement is 202998

ここで、パブリッシャはチェンジ・セットを有効化する必要があります。TRUNCATE TABLE文の後に発生したすべての変更データは、チェンジ・テーブルに反映されます。この際、変更データが失われることはありません。

同期チェンジ・セットの管理

パブリッシャは、同期チェンジ・セットを有効化または無効化できます。チェンジ・セットが無効化されると、有効化されるまで新しい変更データを処理できません。

同期チェンジ・セットの有効化および無効化

同期チェンジ・セットは常に有効な状態で作成されます。非同期チェンジ・セットは常に無効な状態で作成されます。

パブリッシャは、次のコールでPRODUCTS_SET同期チェンジ・セットを有効化できます。

BEGIN
DBMS_CDC_PUBLISH.ALTER_CHANGE_SET(
change_set_name => 'PRODUCTS_SET',
enable_capture  => 'y');
END;
/

パブリッシャは、同じコールを使用(ただし、enable_capture'n'に設定)してPRODUCTS_SET同期チェンジ・セットを無効化できます。

チェンジ・テーブルの管理

チェンジ・テーブル管理タスクは、チェンジ・テーブルの不要データのパージを除いて、すべてパブリッシャが行います。このタスクを最も効率的に機能させるには、パブリッシャとサブスクライバの両方からのアクションが必要です。

この項では次のトピックについて説明します。

チェンジ・テーブルの作成

チェンジ・テーブルを作成する際は、パブリッシャは、次の推奨事項を認識している必要があります。

  • チェンジ・データ・キャプチャのすべてのモードで、パブリッシャは、システム表領域にチェンジ・テーブルを作成してはいけません。

    次のいずれかの方法を使用して、パブリッシャが管理する表領域にチェンジ・テーブルが作成されるようにできます。最初の方法では、パブリッシャが作成したすべてのチェンジ・テーブルが単一の表領域に作成され、2つ目の方法では、パブリッシャは、各チェンジ・テーブルに対して異なる表領域を指定できます。

    • データベース管理者がパブリッシャのアカウントを作成する際に、デフォルト表領域を指定する。次に例を示します。

      CREATE USER cdcpub DEFAULT TABLESPACE ts_cdcpub;
      
    • パブリッシャがチェンジ・テーブルを作成する際に、options_stringパラメータを使用して、作成されるチェンジ・テーブルの表領域を指定する。例については、「同期公開の実行」の手順4を参照してください。

    両方の方法を使用する場合、options_stringパラメータでパブリッシャが指定した表領域が、SQL文のCREATE USERで指定したデフォルト表領域よりも優先されます。

  • 非同期のチェンジ・データ・キャプチャについて、パブリッシャは、DBMS_CDC_PUBLISH.CREATE_CHANGE_TABLEプロシージャで参照されるソース・テーブルが、このプロシージャをコールする前に作成されていることを確認する必要があります。このプロシージャで指定されるチェンジ・セットで、stop_on_ddlパラメータを'Y'に設定している場合は特にそうです。

    パブリッシャが、stop_on_ddlパラメータを'Y'に設定してチェンジ・セットを作成した後にチェンジ・テーブルを作成し、次にソース・テーブルが作成されたものと仮定します。このシナリオでは、ソース・テーブルを作成するDDLによって、stop_on_ddl制約が発動され、チェンジ・データ・キャプチャ処理が停止されます。


    注意:

    パブリッシャはチェンジ・テーブルのパーティション化プロパティを変更しないでください。チェンジ・テーブルのパーティション化は、チェンジ・データ・キャプチャによって、チェンジ・テーブル管理の一部として自動的に管理されます。

  • 非同期のチェンジ・データ・キャプチャについては、ソース・データベースDBAは、チェンジ・テーブルでキャプチャされるすべてのソース・テーブル列に対して、無条件のログ・グループを作成する必要があります。これは、ソース・テーブルにチェンジ・テーブルが作成される前に行う必要があります。キャプチャされるソース・テーブル列に対して無条件のログ・グループを作成しない場合、更新DML操作が発生する際に、チェンジ・テーブル内の変更されていないユーザー列値の一部が、実際のソース・テーブル値を反映せずにNULLとなります。実際にNULLである列値と変更されていない列値を区別するには、パブリッシャがTARGET_COLMAP$制御列を評価する必要があります。無条件のログ・グループの作成については、「非同期チェンジ・データ・キャプチャとサプリメンタル・ロギング」を、制御列については、「チェンジ・テーブルの制御列の理解」を参照してください。

チェンジ・テーブルの制御列の理解

チェンジ・テーブルは、データベース表に格納されている変更データ自体と、制御列が含まれるチェンジ・テーブルのメンテナンスに必要なシステム・メタデータで構成されています。

表17-11に、チェンジ・テーブルの制御列を示します。表には、列名、データ型、モード、列がオプションかどうか、および説明が含まれます。

モードは、列に関連付けられたチェンジ・データ・キャプチャのタイプを示します。値Allは、列が同期モードおよび非同期チェンジ・データ・キャプチャのすべてのモードに関連付けられていることを示します。同期および非同期チェンジ・データ・キャプチャの両方のモードについて、サブスクライバがサブスクライバ・ビューを問い合せてDML変更を発生した順番で戻す場合、その問合せでは、CSCN$およびRSID$の順でデータを整列する必要があります。

制御列は、パブリッシャがチェンジ・テーブルから除外することを選択できる場合はオプションとみなされます。表17-11では、どのモードでどの制御列がオプションとなるかを示しています。オプションの制御列はすべてDBMS_CDC_PUBLISH.CREATE_CHANGE_TABLEプロシージャのパラメータで指定されます。DBMS_CDC_PUBLISH.CREATE_CHANGE_TABLEプロシージャの構文については、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

表17-11 チェンジ・テーブルの制御列

データ型 モード オプション列 説明

OPERATION$

CHAR(2)

All

不可

この列に指定できる値は次のいずれかです。脚注1

I: この行が挿入操作を表すことを示します。

UO: この行が、次の場合について、更新されたソース・テーブル行のビフォア・イメージを表すことを示します。

  • 非同期チェンジ・データ・キャプチャ

  • 主キー・ベースのオブジェクトIDがチェンジ・テーブルに含まれ、主キーではないキャプチャされた列が変更される際の同期チェンジ・データ・キャプチャ

UU: UOによって示される行を除いて、この行が、同期チェンジ・データ・キャプチャの更新されたソース・テーブル行のビフォア・イメージを表すことを示します。

UN: この行が、更新されたソース・テーブル行のアフター・イメージを表すことを示します。

D: この行が削除操作を表すことを示します。

CSCN$

NUMBER

All

不可

同期CDCの場合は、EXTEND_WINDOW操作で使用する値。非同期CDCの場合は、DML操作で使用する値。

DDLDESC$

CLOB

非同期

可能

実行された実際のDDL文を含むCLOB。

DDLPDOBJN$

NUMBER

非同期

可能

このリリースでは使用されません。

DDLOPER$

NUMBER

非同期

可能

実行されたDDL操作の種類を示すビット・ベクトル。

RSID$

NUMBER

All

可能

このトランザクション内の一意の行順序ID。脚注2 RSID$列は、1つのトランザクション内では操作のキャプチャ順序を反映しますが、複数のトランザクションにわたる順序は反映しません。パブリッシャは、RSID$列値を単独で使用しても、トランザクション間のコミット済操作を整列できません。そのためには、CSCN$列値と組み合せて使用する必要があります。

SOURCE_COLMAP$

RAW(128)

同期

可能

ソース・テーブル内の更新済列のビット・マスク脚注3

TARGET_COLMAP$

RAW(128)

All

可能

チェンジ・テーブル内の更新済列のビット・マスク脚注3

COMMIT_TIMESTAMP$

DATE

All

不可

このトランザクションのコミット時刻。

TIMESTAMP$

DATE

All

可能

ソース・テーブルで操作が発生した時刻。

USERNAME$

VARCHAR2(30)

All

可能

操作を実行したユーザーの名前。リリース10.2より前のOracle Databaseで作成されたチェンジ・ソースの場合、値は常にNULLです。

ROW_ID$

ROW_ID

All

可能

ソース・テーブル内で影響を受ける行のROWID。リリース10.2より前のOracle Databaseで作成されたチェンジ・ソースの場合、値は常にNULLです。

XIDUSN$

NUMBER

非同期

不可

トランザクションIDのUNDOセグメント番号。

XIDSLT$

NUMBER

非同期

不可

トランザクションIDのスロット番号。

XIDSEQ$

NUMBER

非同期

不可

トランザクションIDの順序番号。

SYS_NC_OID$

RAW(16)

同期

可能

オブジェクトID。


脚注1この列に基づいた問合せを指定する場合、IまたはD列値をそれぞれ「I」、「D」として指定します。OPERATION$列は2文字列で、値は左揃えおよび空白詰めです。「I」または「D」の値を指定する問合せでは、値は戻されません。

脚注2RSID$列を使用して、特定の操作のアフター・イメージとビフォア・イメージを関連付けることができます。特定の更新操作について、アフター・イメージのRSID$列の値は常に、ビフォア・イメージのRSID$列値の値と一致します。

脚注3ビットマスクは、行のどの列が更新されているかを示すバイナリ値の配列です。

TARGET_COLMAP$およびSOURCE_COLMAP$の値の理解

TARGET_COLMAP$およびSOURCE_COLMAP$列は、行のどの列が変更されたかを示すために使用します。TARGET_COLMAP$列は、チェンジ・テーブル行のどの列が変更されたかを示します。SOURCE_COLMAP$列(同期チェンジ・テーブルにのみ含まれる)は、ソース・テーブル行のどの列が変更されたかを示します。

TARGET_COLMAP$およびSOURCE_COLMAP$列のデータ型はRAW(128)なので、各列には128バイトのバイナリ情報を格納できます。このバイナリ情報は、左側の下位バイトと右側の上位バイトが連なったワードから構成されます。デフォルトでは、フィールドが表示される際に、システムによって各バイトが解釈され、それぞれの値が表示されます。例17-1に、TARGET_COLMAP$のサンプル値を示します。例の後でこのデータの解釈方法を説明します。

例17-1 TARGET_COLMAP$のサンプル値

FE110000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000

例17-1の最初の「FE」が下位バイトで、最後の「00」が上位バイトです。値の意味を正しく解釈するには、各バイトに設定されているビットを考察する必要があります。ビットマップのビットは、0から開始してカウントされます。最初のビットはビット0、2つ目のビットはビット1などとなります。ビット0は常に無視されます。その他のビットについては、特定のビットが1に設定される場合、その列の値が変更されていることを意味します。

例17-1で示したバイト列を解釈するには、左から右に読む必要があります。最初のバイトは文字列「FE」です。左から右にビットに分解すると、この文字列は「1111 1110」となり、チェンジ・テーブルの列「7,6,5,4 3,2,1,-」(ハイフンは無視されたビットを表す)にマップされます。最初のビットは、チェンジ・テーブルの列7が変更されたかどうかを示します。最も右側のビットは無視されています。例17-1のこれらの値は、最初の7列に値があることを示しています。チェンジ・テーブル内の最初のいくつかの列は制御列であるため、これは典型的なことです。

例17-1の次のバイトは文字列「11」です。ビットに分解すると、この文字列は「0001 0001」で、チェンジ・テーブルの列「15,14,13,12 11,10,9,8」にマップされます。これらのビットでは、列8と12が変更されたことを示します。列9、10、11、13、14、15は変更されていません。残りの文字列はすべて「00」で、他の列がすべて変更されていないことを示しています。

パブリッシャは、次の問合せを発行して、列数の列名へのマッピングを割り出すことができます。

SELECT COLUMN_NAME, COLUMN_ID FROM ALL_TAB_COLUMNS 
WHERE OWNER='PUBLISHER_STEWART' AND TABLE_NAME='MY_CT';

COLUMN_NAME                    COLUMN_ID
------------------------------ ----------
OPERATION$                           1
CSCN$                                2
COMMIT_TIMESTAMP$                    3
XIDUSN$                              4
XIDSLT$                              5
XIDSEQ$                              6
RSID$                                7
TARGET_COLMAP$                       8
C_ID                                 9
C_KEY                                10
C_ZIP                                11

COLUMN_NAME                     COLUMN_ID
------------------------------ ----------
C_DATE                               12
C_1                                  13
C_3                                  14
C_5                                  15
C_7                                  16
C_9                                  17

例17-1を使用すると、パブリッシャは、OPERATION$CSCN$COMMIT_TIMESTAMP$XIDUSN$XIDSLT$XIDSEQ$RSID$TARGET_COLMAP$およびC_DATEの列が、このTARGET_COLMAP$の値によって表されるチェンジ・テーブルの特定の変更行で変更されたことがわかります。

チェンジ・データ・キャプチャでは、すべての変更行のすべての制御列の値が生成されるので、制御列に対応するビットは、各TARGET_COLMAP$列で常に1に設定されることに注意してください。OPERATION$列の値がUNおよびIの場合、変更されたユーザー列に対応するビットは、必要に応じて1に設定されます。OPERATION$列の値については、表17-11を参照してください。また、非同期CDCを使用した場合、UPDATE SET句に指定した列は、値が実際に元の値から変更されたかどうかにかかわらず必ず1になることに注意してください。同期CDCの場合は、値が元の値から変更された場合にかぎり1になります。

TARGET_COLMAP$列の値は、一般的にチェンジ・テーブルのNULL値の意味の判別に使用します。チェンジ・テーブルの列値は次の2つの理由からNULLとなります。ユーザーまたはアプリケーションによって値がNULLに変更された場合と、ソース・テーブルからのREDOデータに値が存在していなかったため、チェンジ・データ・キャプチャによってNULL値が列に挿入された場合です。ユーザーが値をNULLに変更した場合、その列のビットは1に設定され、チェンジ・データ・キャプチャによって値がNULLに設定された場合は、列は0に設定されます。

SOURCE_COLMAP$列の値も同様の方法で解釈されますが、次の例外があります。

  • SOURCE_COLMAP$列は、チェンジ・テーブルの列ではなく、ソース・テーブルの列を指す。

  • SOURCE_COLMAP$列は、制御列がソース・テーブルにないため、制御列を参照しない。

  • OPERATION$列の値がUOUUUNおよびIの場合、SOURCE_COLMAP$列において、変更されたソース列は1に設定される。OPERATION$列の値については、表17-11を参照してください。

  • SOURCE_COLMAP$列は、同期チェンジ・テーブルに対してのみ有効である。

チェンジ・マーカーの使用

次の例は、チェンジ・マーカーの使用方法を示しています。まず、チェンジ・セットを作成します。

BEGIN
   DBMS_CDC_PUBLISH.CREATE_CHANGE_SET (
      CHANGE_SET_NAME     => 'async_set1',
      CHANGE_SOURCE_NAME  => 'HOTLOG_SOURCE',
      STOP_ON_DDL         => 'N',
      BEGIN_DATE          => SYSDATE,
      END_DATE            => SYSDATE+5);

PL/SQL procedure successfully completed

次に、チェンジ・テーブルを作成します。ここでは、3つのDDLマーカー(ddloper$ddldesc$ddlpdobjn$)を使用します。

BEGIN
   DBMS_CDC_PUBLISH.CREATE_CHANGE_TABLE (
      OWNER             => 'tcdcpub',
      CHANGE_TABLE_NAME => 'cdc_psales_act',
      CHANGE_SET_NAME   => 'async_set1',
      SOURCE_SCHEMA     => 'tcdcpub',
      SOURCE_TABLE      => 'cdc_psales',
      COLUMN_TYPE_LIST  => 'PROD_IC NUMBER(6)
         NUMBER, TIME_ID DATE',
      CAPTURE_VALUES    => 'both',
      RS_ID             => 'N',
      ROW_ID            => 'N',
      USER_ID           => 'N',
      TIMESTAMP         => 'N',
      OBJECT_ID         => 'N',
      SOURCE_COLMAP     => 'N',
      TARGET_COLMAP     => 'Y',
      OPTIONS_STRING    => NULL,
      DDL_MARKERS       => 'Y');
END;
/

PL/SQL procedure successfully completed.
describe cdc_psales_act;

Name                    Null?     Type
---------------------------------------
OPERATION$                        CHAR(2)
CSCN$                             NUMBER
COMMIT_TIMESTAMP                  DATE
XIDUSN$                           NUMBER
XIDSLT$                           NUMBER
XIDSEQ$                           NUMBER
TARGET_COLMAP$                    RAW(128)
DDLOPER$                          NUMBER
DDLDESC$                          CLOB
DDLPDOBJN$                        NUMBER
PROD_D                            NUMBER(6)
CUST_ID                           NUMBER
TIME_ID                           DATE

次に、このチェンジ・セットのキャプチャを有効にします。

BEGIN
   DBMS_CDC_PUBLISH.ALTER_CHANGE_SET (
      CHANGE_SET_NAME  => 'asynch_set1',
      ENABLE_CAPTURE   => 'Y');
END;
.
PL/SQL procedure successfully completed

最後にDDL文を発行し、キャプチャが実行されたかどうか確認します。

ALTER TABLE cdc_psales DROP PARTITION Dec_06;

SELECT ddloper$, DECODE(ddloper$, NULL, 'NULL',
       DBMS_CDC_PUBLISH.GET_DDLOPER(ddloper$)) 
          AS DDL_OPER
FROM cdc_psales_act
WHERE DDLOPER$ IS NOT NULL
ORDER BY cscn$;

ddloper$            DDL_OPER
---------------------------------
512                 Drop Partition
1 row selected.

SELECT ddldesc$
FROM cdc_psales_act
WHERE ddloper$
IS NOT NULL 
ORDER BY cscn;

DDLDESC$
------------------------
alter table cdc_psales drop partition Dec_06
1 row selected.

チェンジ・テーブルへのサブスクライバのアクセスの制御

パブリッシャは、サブスクライバに権限を付与して、サブスクライバがチェンジ・テーブルにアクセスできるようにします。ソース・テーブルに対する権限はチェンジ・テーブルには適用されません。そのため、サブスクライバは、ソース・テーブルに対してSELECT操作を実行する権限は所有していても、そのソース・テーブルを参照するチェンジ・テーブルに対してSELECT操作を実行する権限を所有していない場合があります。

パブリッシャは、SQL文のGRANTおよびREVOKEを実行し、ユーザーやロールに対してチェンジ・テーブルへのSELECT権限の付与と取消しを行うことで、サブスクライバによる変更データへのアクセスを制御します。パブリッシャは、サブスクライバがチェンジ・テーブルにサブスクライブできるように、事前にSELECT権限を付与する必要があります。

また、パブリッシャは、チェンジ・テーブルのサブスクライバに(INSERTUPDATEDELETE文を使用する)いかなるDMLアクセス権も与えてはいけません。サブスクライバがチェンジ・テーブル内のデータを意図せずに変更してしまった場合、ソースとの不整合が発生する可能性があるためです。さらに、パブリッシャは、サブスクライバがDMLアクセス権を持っているスキーマには、チェンジ・テーブルを作成しないようにする必要があります。

チェンジ・テーブルの不要なデータのパージ

この項ではパージ操作について説明します。パージ操作で最高の結果を得るには、サブスクライバ側の行為が必要となります。各サブスクライバは、変更データの使用を完了したらそのことを知らせます。その後、チェンジ・テーブルでサブスクライバが使用しなくなったデータを、チェンジ・データ・キャプチャまたはパブリッシャが次のように実際に削除(パージ)します。

  • サブスクライバ

    変更データの使用が完了したら、サブスクライバはDBMS_CDC_SUBSCRIBE.PURGE_WINDOWプロシージャをコールする必要があります。これによって、このサブスクライバがその変更データを必要としなくなったことが、チェンジ・データ・キャプチャおよびパブリッシャに示されます。DBMS_CDC_SUBSCRIBE.PURGE_WINDOWプロシージャを実行してもチェンジ・テーブルから物理的に行が削除されるわけではありませんが、データはサブスクライバ・ビューから論理的に削除され、選択できなくなります。

    さらに、「変更データのサブスクライブ」に示すように、不要なサブスクリプションを削除するには、サブスクライバはDBMS_CDC_SUBSCRIBE.DROP_SUBSCRIPTIONプロシージャをコールする必要があります。

    DBMS_CDC_SUBSCRIBE.DROP_SUBSCRIPTIONプロシージャおよびDBMS_CDC_SUBSCRIBE.PURGE_WINDOWプロシージャの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

  • チェンジ・データ・キャプチャ

    チェンジ・データ・キャプチャでは、DBMS_SCHEDULERパッケージ(最初のチェンジ・テーブルを作成したパブリッシャのアカウントで実行する)を使用してパージ・ジョブが作成されます。このパージ・ジョブによってDBMS_CDC_PUBLISH.PURGEプロシージャがコールされ、サブスクライバがチェンジ・テーブルで使用しなくなったデータが削除されます。このジョブの名前はcdc$_default_purge_jobです。デフォルトでは、このジョブは24時間ごとに実行されます。このジョブのスケジュールは、DBMS_SCHEDULER.SET_ATTRIBUTEを使用してrepeat_interval属性を設定することにより変更できます。DBMS_SCHEDULERパッケージではその他の属性を確認したり変更することもできます。

    これによって、チェンジ・テーブルのサイズが無制限に大きくならないことが保証されます。DBMS_CDC_PUBLISH.PURGEプロシージャへのコールでは、アクティブなサブスクリプション・ウィンドウがすべて評価され、どの変更データがまだ必要であるかが判別されます。アクティブなサブスクリプション・ウィンドウで、1つ以上のサブスクライバによって参照されている可能性のあるデータはパージされません。

    DBMS_SCHEDULERパッケージについては、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

  • パブリッシャ

    パブリッシャはいつでもパージ操作を手動で実行できます。パブリッシャは、チェンジ・データ・キャプチャによって行われる自動パージ操作よりも、詳細にパージ操作を実行できます。パブリッシャが使用できるパージ操作には次の3つがあります。

    • DBMS_CDC_PUBLISH.PURGE

      ステージング・データベース上のすべてのチェンジ・テーブルをパージします。これは、チェンジ・データ・キャプチャによって自動的に行われるPURGE操作と同じです。

    • DBMS_CDC_PUBLISH.PURGE_CHANGE_SET

      指定のチェンジ・セットのチェンジ・テーブルをすべてパージします。

    • DBMS_CDC_PUBLISH.PURGE_CHANGE_TABLE

      指定のチェンジ・テーブルをパージします。

したがって、サブスクライバによるDBMS_CDC_SUBSCRIBE.PURGE_WINDOWプロシージャへのコールとチェンジ・データ・キャプチャによるPURGEプロシージャへのコール(またはパブリッシャによるいずれかのPURGEプロシージャへのコール)は一緒に機能します。つまり、各サブスクライバがサブスクリプション・ウィンドウをパージする際、不要になった変更データが示され、実際にデータをパージする前に、すべてのサブスクライバからの入力全体がPURGEプロシージャによって評価されます。表をパージする場合はPURGE_CHANGE_TABLEプロシージャを、チェンジ・セットのすべてのチェンジ・テーブルをパージする場合はPURGE_CHANGE_SETプロシージャを使用します。

forceNに設定されている場合、Oracle Databaseは最も効率的な方法で(表ロックを使用して)パージしようとします。ただしパージは保証されません。forceYに設定すると、このパージは保証されます。

サブスクライバがPURGE_WINDOWのコールに失敗する可能性もあるので注意してください。失敗した場合は、不要な行がパージ・ジョブによって削除されません。パブリッシャは、必要に応じてDBMS_CDC_PUBLISH.DROP_SUBSCRIPTIONプロシージャを使用してアクティブなサブスクリプションを削除できますが、サブスクライバが変更データを使用している可能性があることを第一に考慮する必要があります。極端な場合には、パブリッシャがアクティブなサブスクリプションを手動で削除して領域を再利用できるようにすることもあります。そのような事態の一例は、サブスクライバが、適切な場合にPURGE_WINDOWプロシージャのコールに失敗するアプリケーション・プログラムである場合です。パブリッシャは、必要に応じてDBMS_CDC_PUBLISH.DROP_SUBSCRIPTIONプロシージャを使用してアクティブなサブスクリプションを削除できますが、サブスクライバが変更データを使用している可能性があることを第一に考慮する必要があります。

DBMS_CDC_PUBLISH.PURGEを使用する前にDBMS_CDC_SUBSCRIBE.EXTEND_WINDOWを実行することが重要です。これによって、データを保護し、サブスクライバが必要とするデータをパブリッシャに認識させることができます。EXTEND_WINDOWプロシージャを実行しない場合、パージ・ジョブは期待どおりに動作します。つまり、サブスクライバでデータが使用されるかどうかにかかわらず、すべてのデータがパージされます。

チェンジ・テーブルの削除

チェンジ・テーブルを削除するには、パブリッシャは、DBMS_CDC_PUBLISH.DROP_CHANGE_TABLEプロシージャをコールする必要があります。このプロシージャは、チェンジ・テーブル自体とそのチェンジ・データ・キャプチャ・メタデータの両方を確実に削除します。パブリッシャがチェンジ・テーブルにSQL文のDROP TABLEを使用しようとすると、次のエラーが発生して失敗します。

ORA-31496 must use DBMS_CDC_PUBLISH.DROP_CHANGE_TABLE to drop change tables

DBMS_CDC_PUBLISH.DROP_CHANGE_TABLEプロシージャは、チェンジ・テーブルを使用中のアクティブなサブスクライバがある間に、パブリッシャが不注意でそのチェンジ・テーブルを削除しないための保護対策でもあります。サブスクリプションがアクティブな間にDBMS_CDC_PUBLISH.DROP_CHANGE_TABLEがコールされると、このプロシージャは次のエラーで失敗します。

ORA-31424 change table has active subscriptions

アクティブなサブスクリプションがあっても、チェンジ・テーブルを削除する必要がある場合、パブリッシャはforce_flag => 'Y'パラメータを使用してDROP_CHANGE_TABLEプロシージャをコールします。これは、通常の安全策を無効にし、アクティブなサブスクリプションがある場合でもチェンジ・テーブルを削除できるようチェンジ・データ・キャプチャに通知します。サブスクリプションは有効でなくなり、サブスクライバは変更データにアクセスできなくなります。


注意:

DROP USER CASCADE文は、パブリッシャのすべてのチェンジ・テーブルを削除するため、その(削除された)チェンジ・テーブルに対して他のユーザーがアクティブなサブスクリプションを持っていた場合、それらは有効ではなくなります。DROP USER CASCADE文は、チェンジ・テーブルの削除に加え、DROP USER CASCADE文で指定したユーザーが所有するすべてのサブスクリプション、チェンジ・セットおよびチェンジ・ソースを削除します。

Oracle Data Pumpを使用したチェンジ・データ・キャプチャ・オブジェクトのエクスポートおよびインポート

Oracle Data Pumpは、チェンジ・データ・キャプチャで使用できるエクスポートおよびインポート・ユーティリティです。

以降の項では、チェンジ・データ・キャプチャでOracle Data Pumpを使用する際の制限事項、例およびパブリッシャの考慮事項を示します。

チェンジ・データ・キャプチャでOracle Data Pumpを使用する際の制限事項

チェンジ・データ・キャプチャのチェンジ・ソース、チェンジ・セット、チェンジ・テーブルおよびサブスクリプションは、Oracle Data Pumpのexpdpおよびimpdpコマンドを使用してエクスポートおよびインポートされます。これには次の制限事項があります。

  • チェンジ・データ・キャプチャ・オブジェクトは、データベース全体のエクスポートおよびインポート操作(expdpおよびimpdbコマンドでFULL=yパラメータを指定した操作)の一部としてのみエクスポートおよびインポートされます。スキーマ・レベルのインポートおよびエクスポート操作には、基底のオブジェクトの一部(チェンジ・テーブルの基になる表など)が含まれますが、変更データのキャプチャに必要なチェンジ・データ・キャプチャのメタデータは含まれません。

  • チェンジ・データ・キャプチャ・オブジェクトのインポートを実行するユーザーは、次の権限が必要です。

    • CREATE SEQUENCEまたはCREATE ANY SEQUENCE

      インポートを実行するユーザーが元のパブリッシャである場合は、CREATE SEQUENCEで十分です。

    • ALTER DATABASE

    • EXP_FULL_DATABASEまたはIMP_FULL_DATABASE

      PUBLICによるインポート・パッケージへのアクセスは削除されました。アクセスできるのは、EXP_FULL_DATABASEまたはIMP_FULL_DATABASE権限を持つユーザーのみです。

  • AutoLogのチェンジ・ソース、チェンジ・セットおよびチェンジ・テーブルはサポートされていません。「インポート操作後のAutoLogチェンジ・データ・キャプチャ・オブジェクトの再作成」を参照してください。

  • 非同期のチェンジ・セットおよびチェンジ・テーブルのエクスポートは、ユーザーがエクスポート対象のデータベースにDDLおよびDML変更を加えていない時に行う必要があります。

  • 非同期のチェンジ・セットおよびチェンジ・テーブルをインポートする際は、基底のOracle Streams構成もインポートする必要があります。それには、Oracle Data Pumpのインポート・パラメータSTREAMS_CONFIGURATIONを明示的にyに設定し(または暗黙的にデフォルトを受け入れて)、必要なStreamsオブジェクトがインポートされるようにします。インポート操作を実行し、STREAMS_CONFIGURATION=nを指定する場合、インポートされた非同期のチェンジ・セットおよびチェンジ・テーブルでは、変更データのキャプチャが続行できなくなります。

  • チェンジ・データ・キャプチャ・オブジェクトは、インポートされる際に既存のオブジェクトを上書きすることはありません(表に対するインポート・コマンドのTABLE_EXISTS_ACTION = skipパラメータの効果と似ています)。チェンジ・データ・キャプチャでは、これらの場合について、インポート・ログに警告が生成されます。

  • チェンジ・データ・キャプチャ・オブジェクトは、すべての基底オブジェクトが予定どおり正常な形式で存在しているかどうかを判別するためにインポート操作の最後に検証されます。チェンジ・データ・キャプチャでは、検証の問題が検出されると、インポート・ログに検証の警告が生成されます。検証の警告を伴ってインポートされたチェンジ・データ・キャプチャ・オブジェクトは通常、変更データのキャプチャを続行できません。

Oracle Data Pumpのエクスポートおよびインポートのコマンド例

次に、チェンジ・データ・キャプチャ・オブジェクトをサポートする、データ・ポンプ・エクスポート・コマンドとインポート・コマンドの例を示します。

> expdp DIRECTORY=dpump_dir FULL=y
> impdp DIRECTORY=dpump_dir FULL=y STREAMS_CONFIGURATION=y

Oracle Data Pumpについては、『Oracle Databaseユーティリティ』を参照してください。

チェンジ・テーブルのエクスポートおよびインポートにおけるパブリッシャの考慮事項

チェンジ・テーブルをエクスポートおよびインポートする際のパブリッシャの考慮事項を次に示します。

  • チェンジ・テーブルのインポート時には、ジョブ・キュー内でチェンジ・データ・キャプチャのパージ・ジョブの有無がチェックされます。パージ・ジョブが見つからない場合は、(DBMS_CDC_PUBLISH.PURGEプロシージャを使用して)自動的にパージ・ジョブが発行されます。チェンジ・テーブルがインポートされても、パージ・ジョブの実行時(デフォルトでは24時間後)までにサブスクリプションが発生しなければ、その表のすべての行がパージされます。

    パブリッシャは、次のいずれかの方法を選択し、チェンジ・テーブルからのデータのパージを防止できます。

    • DBMS_SCHEDULERパッケージを使用してパージ・ジョブを一時停止し、ジョブを(STOP_JOBプロシージャを使用して)使用禁止にするか、将来サブスクリプションが存在するようになった時点で(SET_ATTRIBUTEプロシージャを使用して)ジョブを実行します。


      注意:

      パージ・ジョブを無効にする場合は、サブスクリプションがアクティブになった後にリセットするのを忘れないようにする必要があります。これにより、チェンジ・テーブルが無制限に大きくなるのを防止できます。

    • 一時的なサブスクリプションを作成して、チェンジ・テーブルのデータを実際のサブスクリプションが行われるまで保持します。その後で、一時的なサブスクリプションを削除します。

  • チェンジ・テーブルがすでに存在するソース・テーブルにデータをインポートすると、インポートしたデータも関連するチェンジ・テーブルに記録されます。

    チェンジ・テーブルct_salesが対応付けられているソース・テーブルSALESをパブリッシャが所有しているとします。パブリッシャがSALESにデータをインポートすると、そのデータはct_salesにも記録されます。

  • オプションのROW_ID制御列を持つチェンジ・テーブルをインポートすると、チェンジ・テーブルに格納されているROW_ID列が意味を持つのは、関連するソース・テーブルがインポートされていない場合のみです。ソース・テーブルが再作成されるかインポートされると、各行にはチェンジ・テーブルに以前に記録されていたROW_IDとは無関係な新規ROW_IDが割り当てられます。

Oracle9iデータベースで使用できる元のレベルのエクスポートおよびインポートのサポートは、下位互換性のために保持されています。SYNC_SETチェンジ・セットにある同期チェンジ・テーブルは、全データベース、スキーマまたは個々の表のエクスポート操作の一部としてエクスポートでき、必要に応じてインポートできます。チェンジ・データ・キャプチャ・オブジェクト(チェンジ・ソース、チェンジ・セット、SYNC_SETチェンジ・セットにないチェンジ・テーブル、サブスクリプション)は、元のエクスポートおよびインポートのサポート対象外です。

インポート操作後のAutoLogチェンジ・データ・キャプチャ・オブジェクトの再作成

AutoLogチェンジ・データ・キャプチャ・オブジェクトを格納しているデータベースに対して、データ・ポンプの全データベース・インポート操作が完了したら、次の手順を実行して、これらのオブジェクトをリストアする必要があります。

  1. パブリッシャは、AutoLogチェンジ・データ・キャプチャ・オブジェクトの基になるデータベース・オブジェクトを手動で削除する必要があります。

  2. パブリッシャは、適切なDBMS_CDC_PUBLISHプロシージャを使用して、AutoLogのチェンジ・ソース、チェンジ・セットおよびチェンジ・テーブルを再作成する必要があります。

  3. サブスクライバは、AutoLogチェンジ・セットに対してサブスクリプションを再作成する必要があります。

AutoLogチェンジ・データ・キャプチャのオブジェクトが関与するデータ・ポンプの全データベース・エクスポート操作と、前述の手順におけるデータ・ポンプの全データベース・インポート操作後の再作成との合間において、変更データが失われる場合があります。この合間でソース・テーブルに対する変更をできるだけ防止することによって、この可能性を最小化できます。

データ・ポンプ・インポート操作後にAutoLogチェンジ・データ・キャプチャ構成を再作成する前に、基底のオブジェクト(チェンジ・テーブルの基になる表、サブスクライバ・ビュー、チェンジ・セットで使用される順序、Streamsの適用プロセス、Streamsのキューおよびキュー表)を最初に削除する必要があります。表17-12に、基底の各オブジェクトおよびデータ・ポンプ・インポート操作後にそれらのオブジェクトを削除する方法を示します。

表17-12 データ・ポンプ・インポート操作後にオブジェクトを削除する方法

オブジェクト オブジェクトを削除するSQL文またはPL/SQLパッケージ

SQL DROP TABLE

サブスクライバ・ビュー

SQL DROP VIEW

チェンジ・セットで使用される順序

SQL DROP SEQUENCE

Streams適用プロセス

PL/SQL DBMS_APPLY_ADM.DROP_APPLY()パッケージ

Streamsのキュー

PL/SQL DBMS_AQADM.DROP_QUEUE()パッケージ

Streamsのキュー表

PL/SQL DBMS_AQADM.DROP_QUEUE_TABLE()パッケージ


チェンジ・セットで使用される順序の名前を取得するには、CDC$で始まり、少なくともチェンジ・セット名の頭文字が含まれる順序名についてALL_SEQUENCESビューを問い合せます。

Streamsオブジェクトの名前を取得するには、CDC$で始まり、少なくともチェンジ・セット名の頭文字が含まれる名前について、DBA_APPLYDBA_QUEUESおよびDBA_QUEUE_TABLESビューを問い合せます。

パブリッシャが変更を行う際のサブスクリプションへの影響

チェンジ・データ・キャプチャ環境は動的です。パブリッシャは、チェンジ・テーブルを随時追加または削除できます。また、必要に応じて既存のチェンジ・テーブルに列を追加したり、そこから列を削除できます。次のリストでは、チェンジ・データ・キャプチャ環境に対する変更がサブスクリプションに与える影響について説明します。

  • パブリッシャが、新規のチェンジ・テーブルを追加したり、既存のチェンジ・テーブルに列を追加したりしても、サブスクライバには明示的に通知されません。サブスクライバは、ALL_PUBLISHED_COLUMNSビューをチェックして、新規の列が追加されたかどうかや、その列へのアクセス権が付与されているかどうかを確認できます。

  • 表17-13に、パブリッシャがチェンジ・テーブルに列を追加した際の影響を示します。

表17-13 パブリッシャがチェンジ・テーブルに列を追加することによる影響

パブリッシャが追加するもの 条件 . . 結果 . .

ユーザー列

新しいサブスクリプションにこの列が含まれる

このサブスクリプションのサブスクリプション・ウィンドウが、列が追加された点から始まります。

ユーザー列

新しいサブスクリプションに、この新しく追加した列が含まれない

このサブスクリプションのサブスクリプション・ウィンドウは、変更データが最初に使用できる時点から始まります。新しい列は表示されません。

ユーザー列

サブスクリプションが存在する

このサブスクリプションのサブスクリプション・ウィンドウが変更されないまま残ります。

制御列

新しいサブスクリプションが作成される

このサブスクリプションのサブスクリプション・ウィンドウは、変更データが最初に使用できる時点から始まります。サブスクリプションでは、制御列を即時に参照できます。制御列を追加する前に存在していたチェンジ・テーブルのすべての行では、新規に追加された制御列の値がNULLになります。

制御列

サブスクリプションが存在する

このサブスクリプションでは、サブスクリプション・ウィンドウの低位限界が制御列が追加された時点を超えるようにサブスクリプション・ウィンドウをパージする(DBMS_CDC_PUBLISH.PURGE_WINDOWプロシージャ)と、新しい制御列を参照できます。


同期チェンジ・データ・キャプチャに関する考慮事項

以降の項では、チェンジ・データ・キャプチャの同期モードを使用する際に、パブリッシャが注意すべき情報を取り上げます。

ダイレクト・パス・インサートの制限

同期チェンジ・データ・キャプチャは、ダイレクト・パス・インサート文(および、関連するMERGE文およびINSERT文のmulti_table_insert句)の機能をサポートしていません。

パブリッシャが同期モードでチェンジ・テーブルを作成する際、チェンジ・データ・キャプチャは、ソース・テーブルに対してトリガーを作成します。ダイレクト・パス・インサート文は、データベース・トリガーをすべて無効にするため、パラレルDMLモードでダイレクト・パス・インサート用のSQL文を使用してソース・テーブルに挿入された行は、チェンジ・テーブルにキャプチャされません。

同様に、チェンジ・データ・キャプチャは、マルチテーブルのインサート操作およびマージ操作から挿入された行をキャプチャできません。これらの文はダイレクト・パス・インサート文を使用するためです。また、ダイレクト・パス・インサート文では、チェンジ・データ・キャプチャで使用されるトリガーが起動されなかったことを示すエラー・メッセージは戻されません。

ダイレクト・パス・インサート文およびトリガーの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

同期チェンジ・データ・キャプチャでサポートされるデータ型と表構造

同期チェンジ・データ・キャプチャでは、次のものを除く、Oracleのすべての組込みデータ型の列をサポートしています。

  • BFILE

  • BLOB

  • CLOB

  • LONG

  • NCLOB

  • ROWID

  • UROWID

  • オブジェクト・タイプ(XMLTypeなど)

仮想列はサポートされません。さらに、チェンジ・データ・キャプチャでは、結果として引用符付き識別子の使用はサポートされず、チェンジ・データ・キャプチャの予約キーワードの使用もサポートされません。予約キーワードのリストについては、『Oracle Database SQL言語リファレンス』を参照してください。

同期チェンジ・データ・キャプチャでは、次の表構造をサポートしません。

  • 一時表であるソース・テーブル

  • オブジェクト表であるソース・テーブル

  • サポートされていないデータ型の列(LOB列を含む)またはオーバーフロー・セグメントを持つ索引構成表

ごみ箱からソース・テーブルをリストアする際の制限

同期チェンジ・テーブルのソース・テーブルを削除した後にごみ箱からリストアすると、そのチェンジ・テーブルには変更がキャプチャされなくなります。パブリッシャは、リストアしたソース・テーブルに対する今後の変更をキャプチャするために、新しい同期チェンジ・テーブルを作成する必要があります。

非同期チェンジ・データ・キャプチャに関する考慮事項

以降の項では、チェンジ・データ・キャプチャの非同期モードを使用する際に、パブリッシャとソースおよびステージング・データベースDBAが注意すべき情報を提供します。

非同期チェンジ・データ・キャプチャおよびREDOログ・ファイル

チェンジ・データ・キャプチャの非同期モードでは、REDOログ・ファイルが使用されます。

  • HotLog

    非同期のHotLogおよび分散HotLogでは、可能な場合はソース・データベースのオンラインREDOログ・ファイルが読み込まれ、それ以外の場合は、アーカイブREDOログ・ファイルが読み込まれます。

  • AutoLog

    非同期AutoLogチェンジ・データ・キャプチャでは、REDO転送サービスによってソース・データベースからステージング・データベースにコピーされたREDOログ・ファイルが読み込まれます。

    AutoLogオンライン・オプションを使用する際は、宛先属性をLGWR ASYNCに指定する必要があります。REDO転送サービスは、ソース・データベースのオンラインREDOログから、ステージング・データベースのスタンバイREDOログにREDOデータをコピーします。チェンジ・データ・キャプチャが変更データを取得するのは、ソース・データベースのトランザクションがコミットされた後です。

    AutoLogアーカイブ・オプションを使用する際は、宛先属性をARCHまたはLGWR ASYNCに指定します。ARCHモードでは、ソース・データベースでのログ・スイッチの発生後に、REDO転送サービスによって、アーカイブREDOログ・ファイルがステージング・データベースにコピーされます。LGWRモードでは、REDOデータは、REDO転送サービスによってステージング・データベースにコピーされ、同時にソース・データベース上でオンラインREDOログ・ファイルに書き込まれます。

ログ・ファイルがアーカイブされるためには、非同期チェンジ・データ・キャプチャのソース・データベースは、ARCHIVELOGモードで実行されている必要があります。これは次のSQL文で指定します。

ALTER DATABASE ARCHIVELOG;

ARCHIVELOGモードでのデータベースの運用については、『Oracle Database管理者ガイド』を参照してください。

チェンジ・データ・キャプチャで使用されるREDOログ・ファイルは、チェンジ・データ・キャプチャでキャプチャされるまで、ステージング・データベースで使用できる状態である必要があります。ただし、REDOログ・ファイルは、チェンジ・データ・キャプチャのサブスクライバが変更データを処理するまで使用できる状態である必要はありません。

特定のチェンジ・セットに対して、チェンジ・データ・キャプチャで必要なくなったREDOログ・ファイルを判別するには、パブリッシャは、チェンジ・セットのStreams取得プロセスを変更して、Streamsが内部クリーンアップを実行し、DBA_LOGMNR_PURGED_LOGビューを移入するようにします。パブリッシャは次の手順に従います。

  1. ステージング・データベースで次の問合せを使用して、チェンジ・セットCHICAGO_DAILYに使用するfirst_scnの新しい適切な値の判別に必要な3つのSCN値を取得します。

    SELECT cap.CAPTURE_NAME, cap.FIRST_SCN, cap.APPLIED_SCN, 
            cap.REQUIRED_CHECKPOINT_SCN
    FROM DBA_CAPTURE cap, ALL_CHANGE_SETS cset
    WHERE cset.SET_NAME = 'CHICAGO_DAILY' AND
          cap.CAPTURE_NAME = cset.CAPTURE_NAME;
    
    CAPTURE_NAME                    FIRST_SCN APPLIED_SCN REQUIRED_CHECKPOINT_SCN
    ------------------------------ ---------- ----------- -----------------------
    CDC$C_CHICAGO_DAILY                778059      778293                  778293
    
  2. 元のfirst_scn値以上で、手順1の問合せで戻されたapplied_scn値およびrequired_checkpoint_scn値以下の、新しいfirst_scn値を決定します。例では、この値は778293で、取得プロセス名はCDC$C_CHICAGO_DAILYなので、パブリッシャは、取得プロセスのfirst_scn値を次のように変更できます。

    BEGIN
    DBMS_CAPTURE_ADM.ALTER_CAPTURE(
      capture_name => 'CDC$C_CHICAGO_DAILY',
      first_scn    => 778293);
    END;
    /
    

    これらの基準を満たすSCN値がない場合、チェンジ・セットでは、そのREDOログ・ファイルすべてが必要です。

  3. DBA_LOGMNR_PURGEDLOGビューを問い合せて、チェンジ・データ・キャプチャで必要なくなったログ・ファイルをすべて参照します。

    SELECT FILE_NAME
    FROM DBA_LOGMNR_PURGED_LOG;
    

    注意:

    REDOログ・ファイルは、チェンジ・データ・キャプチャ以外の目的で、ステージング・データベースで必要となる場合があります。REDOログ・ファイルを削除する前に、パブリッシャは、他のユーザーが必要としていないことを確認する必要があります。

既存の取得プロセスのfirst_scnの設定および取得プロセスのチェックポイントの詳細は、『Oracle Streams概要および管理』を参照してください。

AutoLogチェンジ・ソースのすべてのチェンジ・セットについて、first_scn値は、DBMS_CDC_PUBLISH.ALTER_AUTOLOG_CHANGE_SOURCE first_scnパラメータを使用して更新できます。AutoLogチェンジ・ソースのすべてのチェンジ・セットについて、新しいfirst_scn値は、前述の手順2で示した基準を満たす必要があることに注意してください。

REDOログ・ファイルのサイズおよびログ・スイッチが発生する頻度のどちらも、ソース・データベースでのアーカイブ・ログ・ファイルの生成に影響を及ぼす可能性があります。チェンジ・データ・キャプチャについて、REDOログ・ファイルをどのサイズにするかを決定する最も重要な要因は、変更が行われた時点から、その変更データがサブスクライバで使用可能になるまでの待機時間の許容範囲です。ただし、Oracle Databaseソフトウェアは、各ログ・スイッチでチェックポイント取得を試みるので、REDOログ・ファイルが小さすぎると、頻繁なログ・スイッチによって、チェックポイントの取得も頻繁になり、ソース・データベースのパフォーマンスにマイナスの影響を与えることになります。

ログ・ファイルのアーカイブ情報を監視する手順は、『Oracle Data Guard概要および管理』を参照してください。ソース・データベースとステージング・データベースという用語は、Oracle Data Guardの、プライマリ・データベースとアーカイブ先という用語にそれぞれ置き換えてください。

REDO転送サービスを使用して、AutoLogチェンジ・ソースにREDOログ・ファイルを供給する際に、REDOログ・ファイルの順序のギャップは、自動的に検出および解決されます。AutoLogチェンジ・セットにログ・ファイルを手動で追加する必要がある状況が発生した場合、パブリッシャは、ログ・ファイルをダウンストリーム取得プロセスに明示的に割り当てる手順を使用できます(『Oracle Streams概要および管理』を参照)。これらの手順では、AutoLogチェンジ・セットの取得プロセスの名前が必要です。パブリッシャは、ALL_CHANGE_SETSデータ・ディクショナリ・ビューで、AutoLogチェンジ・セットの取得プロセスの名前を確認できます。

非同期チェンジ・データ・キャプチャとサプリメンタル・ロギング

チェンジ・データ・キャプチャの非同期モードは、ソース・データベースでのサプリメンタル・ロギングが適切な場合に最も機能します。サプリメンタル・ロギングは、同期チェンジ・データ・キャプチャでは使用されません。

ソース・データベースDBAは、データベース・レベルのなんらかの形式のサプリメンタル・ロギングを有効化する必要があります。次の例では、データベース・レベルの最小サプリメンタル・ロギングを有効化します。

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

また、ソース・データベースDBAに関する推奨事項は次のとおりです。

  • ファンクションまたは主キーの一部であるすべてのソース・テーブル列をサプリメンタル・ロギングして、行を一意に識別します。これは、データベース・レベルまたは表レベルの識別キー・ロギングを使用するか、表レベルの無条件のログ・グループを介して行うことができます。

  • 任意の非同期チェンジ・テーブルによってキャプチャされるソース・テーブル列すべてに対して、無条件のログ・グループを作成します。これは、ソース・テーブルにチェンジ・テーブルが作成される前に行う必要があります。

    ALTER TABLE sh.promotions
    ADD SUPPLEMENTAL LOG GROUP log_group_cust
    (PROMO_NAME, PROMO_SUBCATEGORY, PROMO_CATEGORY) ALWAYS;
    

    キャプチャされるすべてのソース・テーブル列に対して無条件のログ・グループを作成しない場合、更新DML操作が発生する際に、チェンジ・テーブル内の変更されていないユーザー列値の一部が、実際のソース・テーブル値を反映せずにNULLとなります。

    たとえば、ソース・テーブルに、XYという2つの列が格納されており、ソース・データベースDBAは、そのテーブルに対してY列のみが含まれる無条件のログ・グループを定義しているものと仮定します。さらに、ユーザーはその表の行のY列のみ更新するものとします。サブスクライバがその行の変更データを参照する際、変更されていない列Xの値はNULLとなります。ただし、Xの実際の列値はREDOログ・ファイルから除外されており、チェンジ・テーブルに含めることができないので、サブスクライバは、X列の実際のソース・テーブル値がNULLであることが推測できません。サブスクライバは、列Xの実際のソース・テーブル値がNULLであるか、変更されていないのかを判別するには、TARGET_COLMAP$制御列の内容で判断します。

様々なタイプのサプリメンタル・ロギングの詳細は、『Oracle Databaseユーティリティ』を参照してください。

非同期チェンジ・データ・キャプチャとOracle Streamsコンポーネント

非同期チェンジ・データ・キャプチャでは、変更データのキャプチャおよびチェンジ・セットの移入を行うために、Oracle Streamsのコンポーネント(構成要素)が生成されます。これらのコンポーネントを、他の目的で再利用または共有しないでください。たとえば、分散HotLogチェンジ・ソースに対してチェンジ・データ・キャプチャによって生成されるキャプチャ・キューは、ユーザーが新たに作成したStreams伝播用のソース・キューとしては使用できません。

HotLogおよびAutoLogモードの場合、各チェンジ・セットには、Streamsの取得プロセス、キュー、キュー表および適用プロセスが含まれます。これらのオブジェクトはすべてステージング・データベースのパブリッシャが所有します。分散HotLogモードの場合、各チェンジ・ソースはソース・データベース上に存在し、Streamsの取得プロセス、キューおよびキュー表が含まれます。各チェンジ・セットはステージング・データベース上に存在し、それぞれにStreamsの適用プロセスが含まれます。チェンジ・ソースに最初のチェンジ・セットを作成すると、チェンジ・ソース内のすべてのチェンジ・セット間で共有されるキューおよびキュー表がチェンジ・データ・キャプチャによってステージング・データベース上に生成されます。また、チェンジ・ソース・キューからステージング・データベースのチェンジ・セット・キューまでソース・データベースのStreamsの伝播が生成されます。ソース・データベース・オブジェクトはソース・データベースのパブリッシャが所有し、ステージング・データベース・オブジェクトはステージング・データベースのパブリッシャが所有します。

図17-8は、非同期分散HotLogチェンジ・データ・キャプチャ環境でStreamsコンポーネントがどのように使用されるかを例示しています。この例では、ソース・データベース上に1つの分散HotLogチェンジ・ソースdisthot_change_srcがあり、ステージング・データベース上に2つのチェンジ・セットChange_Set_1およびChange_Set_2があります。

図17-8 非同期分散HotLogチェンジ・データ・キャプチャ・システムのStreamsコンポーネント

図17-8の説明は図の下のリンクをクリックしてください。
「図17-8 非同期分散HotLogチェンジ・データ・キャプチャ・システムのStreamsコンポーネント」の説明

非同期チェンジ・データ・キャプチャでサポートされるデータ型と表構造

非同期チェンジ・データ・キャプチャでは、次のものを除く、Oracleのすべての組込みデータ型の列をサポートしています。

  • BFILE

  • LONG

  • ROWID

  • UROWID

  • オブジェクト・タイプ(XMLTypeなど)

仮想列はサポートされません。さらに、チェンジ・データ・キャプチャでは、結果として引用符付き識別子の使用はサポートされず、チェンジ・データ・キャプチャの予約キーワードの使用もサポートされません。予約キーワードのリストについては、『Oracle Database SQL言語リファレンス』を参照してください。

非同期チェンジ・データ・キャプチャでは、次の表構造をサポートしません。

  • 一時表であるソース・テーブル

  • オブジェクト表であるソース・テーブル

  • サポートされていないデータ型の列(LOB列を含む)またはオーバーフロー・セグメントを持つ索引構成表

NOLOGGINGおよびUNRECOVERABLE操作の制限

SQL操作のNOLOGGINGまたはUNRECOVERABLEキーワードを使用する場合、非同期チェンジ・データ・キャプチャでは、その操作からの変更をキャプチャできません。同様に、SQL*Loaderのダイレクト・パス・ロードで制御ファイルにUNRECOVERABLE句を使用すると、ダイレクト・ロードからの変更は、非同期チェンジ・データ・キャプチャではキャプチャできません。

NOLOGGINGおよびUNRECOVERABLEキーワードについては『Oracle Database SQL言語リファレンス』を、ダイレクト・パス・ロードおよびSQL*Loaderについては『Oracle Databaseユーティリティ』を参照してください。

実装とシステム構成

チェンジ・データ・キャプチャは、適切なOracleドライバがすでにインストールされた状態でパッケージ化されており、非同期または同期のデータ・キャプチャを実装できます。チェンジ・データ・キャプチャの同期モードはStandard Editionで利用できますが、非同期モードを使用する場合はEnterprise Editionが必要です。

また、チェンジ・データ・キャプチャではJavaが使用されることに注意してください。したがって、Oracle Databaseのインストール時に、Javaが使用可能になっているかどうかを確認してください。

チェンジ・データ・キャプチャでは、CREATE TABLEALTER TABLEおよびDROP TABLEの各SQL文に対してシステム・トリガーが配置されます。システム・トリガーがソース・データベースに対して使用禁止にされていると、チェンジ・データ・キャプチャは正しく動作しません。したがって、システム・トリガーは使用禁止にしないでください。

チェンジ・データ・キャプチャをデータベースから削除するために、adminディレクトリにSQLスクリプトrmcdc.sqlが用意されています。これは、チェンジ・データ・キャプチャによって、CREATE TABLEALTER TABLEおよびDROP TABLEの各SQL文に配置されたシステム・トリガーを削除します。さらに、rmcdc.sqlは、チェンジ・データ・キャプチャで使用されるJavaクラスをすべて削除します。rmcdc.sqlをコールした後は、システムでチェンジ・データ・キャプチャが動作しなくなることに注意してください。システム管理者がデータベースからJava仮想マシンを削除することにした場合、rmjvmをコールする前にrmcdc.sqlをコールする必要があります。

チェンジ・データ・キャプチャを再インストールするために、adminディレクトリにSQLスクリプトinitcdc.sqlが用意されています。これは、チェンジ・データ・キャプチャに必要なチェンジ・データ・キャプチャのシステム・トリガーとJavaクラスを作成します。チェンジ・データ・キャプチャを再インストールするには、Java仮想マシンを使用できるようにする必要があります。

Database Configuration Assistantの考慮事項

Database Configuration Assistantで提供される事前定義のテンプレートはすべて、Oracleのチェンジ・データ・キャプチャ機能をサポートしています。事前定義のテンプレートには次のものがあります。

  • 汎用

  • データ・ウェアハウス

  • トランザクション処理

  • 新規データベース

「新規データベース」オプションを選択してカスタム・データベースを作成する場合、「追加」データベース構成ダイアログ・ボックスではデフォルトで「Oracle JVM」が選択されます。Oracleのチェンジ・データ・キャプチャではOracle JVM機能が必要なので、この設定を変更しないてください。

サポートされる分散HotLog構成および制限の概要

以降の項では、チェンジ・データ・キャプチャの分散HotLogモードでサポートされている構成および制限について説明します。

ソース・データベースおよびステージング・データベースのOracle Databaseのリリース

チェンジ・データ・キャプチャの分散HotLogモードでは、ソース・データベースおよびステージング・データベースに次のOracle Databaseのリリースを組み合せて使用できます。

  • Oracle Databaseリリース9.2(9.2.0.6以上のパッチ・セット)、10.1、10.2、11.1または11.2のソース・データベース。

  • Oracle Databaseリリース11.1または11.2のステージング・データベース。


注意:

リリース9.2または10.1のOracle Databaseがチェンジ・データ・キャプチャの分散HotLogモードのソース・データベースとなる場合、ソース・データベースのメタデータはステージング・データベース上に格納されるのに対して、Oracle Databaseリリース11.1または11.2のソース・データベースのメタデータはソース・データベース上に格納されます。したがって、Oracle Databaseリリース9.2またはリリース10.1のソース・データベースのメタデータを参照するには、パブリッシャは、ステージング・データベースに対してCHANGE_SOURCESデータ・ディクショナリ・ビューを問い合せ、Oracle Databaseリリース11.1または11.2のソース・データベースのメタデータを参照するには、ソース・データベースに対してCHANGE_SOURCESデータ・ディクショナリ・ビューを問い合せる必要があります。

分散HotLogチェンジ・ソースのリリース11(11.1または11.2)へのアップグレード

前述のとおり、Oracle Databaseリリース11の分散HotLogチェンジ・ソースのメタデータはソース・データベースに格納されますが、リリース9.2または10.1のチェンジ・ソースのメタデータはステージング・データベースに格納されます。

リリース10.2のOracle Databaseをリリース11にアップグレードするときは、メタデータを移動する必要があります。

リリース9.2または10.1のOracle Databaseをリリース11にアップグレードする際、そのアップグレード操作の一部として、チェンジ・データ・キャプチャによってステージング・データベースからソース・データベースにソース・データベースのメタデータが移動されることはありません。ただし、アップグレード後に最初にチェンジ・ソースを有効化(DBMS_CDC_PUBLISH.ALTER_HOTLOG_CHANGE_SOURCEプロシージャを使用)すると、メタデータをアップグレードしてソース・データベースに移動する必要があることがチェンジ・データ・キャプチャによって検出され、これらの操作が自動的に実行されます。

パブリッシャがアップグレードの直後にチェンジ・ソースを変更しないことを選択する場合、より適切なタイミングが訪れるまで、チェンジ・ソース・メタデータをステージング・データベース上に留めておくことができます。ただし、Oracle Databaseリリース11にアップグレードした後は、ソース・データベース・メタデータを無制限にステージング・データベース上に残しておかないことをお薦めします。これは、分散HotLogチェンジ・ソースに関する情報を、ソース・データベースのデータ・ディクショナリ・ビューで利用できるようにするためです。

ハードウェア・プラットフォームおよびオペレーティング・システム

チェンジ・データ・キャプチャの分散HotLogモードでは、ソース・データベースおよびステージング・データベースに異なるハードウェア・プラットフォームやオペレーティング・システム(またはその両方)を使用できます。

ステージング・データベースにおける複数のパブリッシャの要件

チェンジ・データ・キャプチャの分散HotLogモードのステージング・データベースにパブリッシャが複数存在し、1人のパブリッシャが別のパブリッシャの分散HotLogチェンジ・セットのチェンジ・テーブルを定義している場合、チェンジ・データ・キャプチャは、そのチェンジ・セットを作成したパブリッシャが確立したデータベース・リンクを使用して、ソース・データベースにアクセスします。したがって、チェンジ・セットを作成したパブリッシャが確立した、ソース・データベースへのデータベース・リンクは、チェンジ・テーブルを正常に作成するために失われてはならないものです。チェンジ・テーブル作成時にチェンジ・セットのパブリッシャのデータベース・リンクが存在しないと、リモート・データベースの接続が見つからなかったことを示すエラーが戻されます。

データベース・リンクの要件

ソース・データベースからステージング・データベースへのデータベース・リンクは、分散HotLogチェンジ・ソースの存在期間中は存在している必要があります。

ステージング・データベースからソース・データベースへのデータベース・リンクは、分散HotLogのチェンジ・ソース、チェンジ・セットおよびチェンジ・テーブルの作成、変更または削除時には存在している必要があります。ただし、このデータベース・リンクは、変更のキャプチャのために必要ではありません。必要な分散HotLogのチェンジ・ソース、チェンジ・セットおよびチェンジ・テーブルを配置および有効化すると、変更のキャプチャを妨げずにこのデータベース・リンクを削除できます。データベース・リンクを削除した場合、分散HotLogのチェンジ・ソース、チェンジ・セットおよびチェンジ・テーブルを作成、変更または削除する際に再作成する必要があります。