チェンジ・データ・キャプチャでは、Oracleのリレーショナル表に対して追加、更新または削除されたデータを効率的に識別およびキャプチャし、アプリケーションやユーザーがこの変更データを使用できるようにします。
この章では、チェンジ・データ・キャプチャについて説明します。内容は次のとおりです。
チェンジ・データ・キャプチャのパブリッシュおよびサブスクライブ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
で行を選択するので、その秒の残りの間に発生した変更を見逃すことになります。
変更値選択を使用するには、この例外を受け入れるか、必要な詳細度の変更値列を人為的に追加するか、キャプチャ処理中のソース・テーブルへの変更をロックアウトする必要がありますが、これによって、ソース・データベースのパフォーマンスがさらに低下することになります。
変更データのキャプチャ元であるすべての表が変更値列を持つ必要があることを考慮して、あらかじめ、このキャプチャ・メカニズムでソース・データベースを設計する必要があります。レガシー・システムのデータソースでデータ・ウェアハウスを構築する場合、それらのレガシー・システムでは、必要とする変更値列が提供されない場合があります。
チェンジ・データ・キャプチャは、コストが高く扱いにくい表区別や変更値選択メカニズムに依存しません。そうしたメカニズムに依存することなく、ユーザー表に対して行ったINSERT
、UPDATE
およびDELETE
操作で生成された変更データをキャプチャします。この変更データはチェンジ・テーブルと呼ばれるリレーショナル表に格納され、制御された方法でアプリケーションやユーザーによって使用できるようになります。
チェンジ・データ・キャプチャは、次のいずれかのモードでコミット済の変更データをキャプチャおよび公開できます。
同期
変更データは、データ操作言語(DML)操作(INSERT
、UPDATE
またはDELETE
)を行う各SQL文が実行されると、ソース・データベースのトリガーによってすぐにキャプチャされます。このモードでは、変更データは、ソース・テーブルを変更するトランザクションの一部としてキャプチャされます。同期チェンジ・データ・キャプチャは、OracleのStandard EditionおよびEnterprise Editionで使用できます。このモードの詳細は、「同期チェンジ・データ・キャプチャ」を参照してください。
非同期
変更データは、REDOログ・ファイルに送られたデータを利用することによって、DML操作を実行するSQL文がコミットされた後にキャプチャされます。このモードでは、変更データは、ソース・テーブルを変更するトランザクションの一部としてキャプチャされないので、トランザクションに影響を与えません。
非同期チェンジ・データ・キャプチャには、HotLog、分散HotLogおよびAutoLogの3つのモードがあります。これらのモードの詳細は、「非同期チェンジ・データ・キャプチャ」を参照してください。
非同期チェンジ・データ・キャプチャは、Oracle Streamsに対して構築され、リレーショナル・インタフェースを提供します。Oracle Streamsの詳細は、『Oracle Streams概要および管理』を参照してください。
チェンジ・データ・キャプチャを使用して変更データをキャプチャするメリットとして、次のようなことがあげられます。
完全性
チェンジ・データ・キャプチャは、UPDATE
操作前後のデータ値を含む、INSERT
、UPDATE
および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つ以上のチェンジ・テーブルが含まれます。
チェンジ・ソース
チェンジ・ソースは、チェンジ・データ・キャプチャの次のモードでは、ステージング・データベースにあります。
同期: 詳細は、「同期チェンジ・データ・キャプチャ」を参照してください。
非同期HotLog: 詳細は、「非同期HotLogモード」を参照してください。
非同期AutoLog: 詳細は、「非同期AutoLogモード」を参照してください。
次に、パブリッシャが実行する主なタスクを示します。
サブスクライバが変更データを参照するために必要なソース・データベースとソース・テーブル、および変更データをキャプチャするモード(同期またはいずれかの非同期モード)を判断します。
オラクル社が提供するパッケージDBMS_CDC_PUBLISH
を使用して、対象のソース・テーブルから変更データをキャプチャするようにシステムをセットアップします。
SQL文のGRANT
およびREVOKE
を使用して、ユーザーやロールに対してチェンジ・テーブルへのSELECT
権限の付与および取消しを行うことで、サブスクライバにチェンジ・テーブル内の変更データへの制御付きのアクセスを許可します。ただし、サブスクライバが変更データにアクセスするには、チェンジ・テーブルを直接使用するのではなく、ビューを使用することに注意してください。
図16-1では、パブリッシャは、サブスクライバがHQ
ソース・データベースの変更データを参照する必要があることを判断します。特に、サブスクライバが必要なのは、sh.sales
およびsh.promotions
ソース・テーブルの変更データです。
パブリッシャは、変更データのキャプチャに非同期AutoLogモードを使用することを決定します。パブリッシャは、DW
ステージング・データベース上に、1つのチェンジ・ソースHQ_SRC
、1つのチェンジ・セットSH_SET
、およびsales_ct
とpromo_ct
の2つのチェンジ・テーブルを作成します。sales_ct
チェンジ・テーブルには、ソース・テーブルsh.sales
の列がすべて含まれます。一方、promo_ct
チェンジ・テーブルについては、パブリッシャはPROMO_COST
列を除外することにしました。
サブスクライバは、パブリッシュされた変更データのコンシューマです。サブスクライバはまた、次のタスクを実行します。
Oracleが提供するパッケージDBMS_CDC_SUBSCRIBE
を次の目的に使用します。
サブスクリプションの作成
サブスクリプションは、単一チェンジ・セット内の1つ以上の対象ソース・テーブルの変更データに対するアクセスを制御します。サブスクリプションには1つ以上のサブスクライバ・ビューが含まれます。
サブスクライバ・ビューは、サブスクリプションにおける特定のパブリケーションからの変更データを指定するビューです。サブスクライバは、パブリッシャが公開し、使用するアクセス権がサブスクライバに付与された変更データの参照において制限を受けます。サブスクライバ・ビューを指定する方法の選択に関する詳細は、「変更データのサブスクライブ」を参照してください。
変更データのセットを受け取る準備ができた時点でのチェンジ・データ・キャプチャへの通知
サブスクリプション・ウィンドウでは、サブスクライバ・ビューでサブスクライバが現在参照できるパブリケーションの行のタイム・レンジが定義されます。サブスプリクション・ウィンドウ内の最も古い行が低位限界と呼ばれ、最も新しい行が高位限界と呼ばれます。各サブスクリプションは、そのサブスクライバ・ビューすべてに適用される独自のサブスクリプション・ウィンドウを持ちます。
変更データのセットに関する作業が完了した時点でのチェンジ・データ・キャプチャへの通知
サブスクライバは、サブスクライバが実行されているユーザー・アカウントの権限、およびサブスクライバに付与されているすべての追加の権限を所有しています。
図16-2において、サブスクライバが必要なのは、図16-1のパブリッシャが公開している列のサブセットです。図16-2に示されているパブリケーションは、図16-1ではチェンジ・テーブルとして表されていることに注意してください。これは、サブスクライバとパブリッシャそれぞれで使用される用語が異なることによるものです。
サブスクライバは、サブスクリプションsales_promos_list
および2つのサブスクライバ・ビュー(spl_sales
とspl_promos
)を、DWステージング・データベース上のSH_SET
チェンジ・セットに作成します。各サブスクライバ・ビュー内に、サブスクライバは、パブリッシャによって使用可能とされた列のサブセットを含めます。パブリッシャがPROMO_COST
列を含むチェンジ・テーブルを作成しなかったため、サブスクライバはその列の変更データを参照できません。サブスクライバは、パブリッシャが設定したチェンジ・データ・キャプチャのモードを認識する必要はありません。
サブスクライバにとって、チェンジ・データ・キャプチャは次のような利点があります。
各サブスクライバは、すべての変更の参照が保証されます。
複数のサブスクライバが追跡され、各サブスクライバには変更データへの共有アクセス権が付与されます。
すべてのサブスクライバに不要になったデータがチェンジ・テーブルから自動的に削除されることによって、すべての記憶域管理が処理されます。チェンジ・データ・キャプチャは、パージ処理のために、24時間に1回実行されるジョブ・キューのジョブを開始します。このジョブでは多くの不具合が発生する可能性があるため(ジョブが削除されたり、スケジュールが変更される場合など)、この自動処理は、開始および実行されているジョブ・キュー・プロセス、および、存在しているチェンジ・データ・キャプチャのジョブに依存します。また、ロジカル・スタンバイ環境では、パージ・ジョブは実行されません。
注意: Oracleでは、サブスクライバがサブスクライバ・ビューを介して変更データにアクセスする際にのみ、これらの利点が提供されます。 |
チェンジ・データ・キャプチャには、変更データのキャプチャ用に同期モードと非同期モードがあります。次の項では、チェンジ・データ・キャプチャの各モードがどのように実行されるか、およびチェンジ・データ・キャプチャの各モードに関連付けられたチェンジ・ソースの概要について説明します。
同期モードでは、変更データのキャプチャにソース・データベースのトリガーが使用されます。このモードでは、変更データがソース・データベース上で継続的にリアルタイムでキャプチャされるため、待機時間がありません。チェンジ・テーブルは、ソース・テーブルでDML操作がコミットされた際に移入されます。
ソース・データベースを表す、事前定義の同期チェンジ・ソースSYNC_SOURCE
が1つあります。これは唯一の同期チェンジ・ソースです。変更や削除はできません。
チェンジ・データ・キャプチャの同期モードでは、キャプチャ時にソース・データベースのオーバーヘッドが増加しますが、変更データの抽出の簡素化により(表区別や変更値選択を使用して変更データを抽出するのと比較して)コストを削減できます。
チェンジ・データ・キャプチャのこのモードのチェンジ・テーブルは、ソース・データベースにローカルに存在する必要があります。
図16-3に、同期モードの構成を示します。ソース・テーブルで発生したDML操作の後に実行されたトリガーによって、SYNC_SOURCE
チェンジ・ソース内のチェンジ・セットにチェンジ・テーブルが移入されます。
非同期モードでは、変更がソース・データベースに対してコミットされた後にデータベースのREDOログ・ファイルから変更データがキャプチャされます。
チェンジ・データ・キャプチャの非同期モードは、ソース・データベースで有効化されたサプリメンタル・ロギングのレベルに依存します。サプリメンタル・ロギングによって、ソース・データベースでREDOロギングのオーバーヘッドが増加するので、チェンジ・データ・キャプチャを使用してアプリケーションやユーザーのニーズと注意深くバランスを取る必要があります。サプリメンタル・ロギングの詳細は、「非同期チェンジ・データ・キャプチャとサプリメンタル・ロギング」を参照してください。
以降の項では、変更データのキャプチャにおける次の3つのモードについて説明します。
非同期HotLogモードでは、変更データは、ソース・データベース上のオンラインREDOログ・ファイルからキャプチャされます。ソース・テーブル・トランザクションのコミット操作から変更データの取得までの間にはわずかな待機時間があります。
ソース・データベースの現在のオンラインREDOログ・ファイルを表す、事前定義のHotLogチェンジ・ソースHOTLOG_SOURCE
が1つあります。これは唯一のHotLogチェンジ・ソースです。変更や削除はできません。
チェンジ・データ・キャプチャのこのモードのチェンジ・テーブルは、ソース・データベースにローカルに存在する必要があります。
図16-4に、非同期HotLogモードの構成を示します。コミット済トランザクションは、ログ・ライター・プロセス(LGWR
)によって、ソース・データベース上のオンラインREDOログ・ファイルに記録されます。チェンジ・データ・キャプチャでは、トランザクションが新たにコミットされると、Oracle Streamsプロセスが使用され、HOTLOG_SOURCE
チェンジ・ソース内のチェンジ・セットにチェンジ・テーブルが自動的に移入されます。
非同期分散HotLogモードでは、変更データは、ソース・データベース上のオンラインREDOログ・ファイルからキャプチャされます。
事前定義の分散HotLogチェンジ・ソースはありません。分散HotLogモードでは、チェンジ・データ・キャプチャの他のモードとは異なり、ソース・データベースとステージング・データベースにまたがって、チェンジ・データ・キャプチャのアクティビティおよびオブジェクトが分散されます。チェンジ・ソースは、ステージング・データベースのパブリッシャによってソース・データベース上に定義されます。
分散HotLogチェンジ・ソースは、ソース・データベースの現在のオンラインREDOログ・ファイルを表します。ただし、ステージング・データベースのパブリッシャは、それぞれ異なるステージング・データベースのチェンジ・セットを含む分散HotLogチェンジ・ソースを複数定義できます。ソース・データベースおよびステージング・データベースは、異なるハードウェアのプラットフォーム上に配置でき、異なるオペレーティング・システム上で動作できますが、これにはいくつかの制限が適用されます。これらの制限については、「サポートされる分散HotLog構成および制限の概要」を参照してください。
図16-5に、非同期分散HotLogモードの構成を示します。ソース・データベース上のチェンジ・ソースは、オンラインREDOログ・ファイルから変更データをキャプチャし、Oracle Streamsを使用して、その変更データをステージング・データベース上のチェンジ・セットに伝播します。ステージング・データベースのチェンジ・セットは、チェンジ・セット内にチェンジ・テーブルを移入します。
チェンジ・データ・キャプチャのこのモードでは、2人(ソース・データベースとステージング・データベースに各1人ずつ)のパブリッシャが必要となります。ソース・データベースのパブリッシャは、ステージング・データベースのパブリッシャとしてステージング・データベースに接続するソース・データベースのデータベース・リンクを定義します。ステージング・データベースのパブリッシャは、ソース・データベースのパブリッシャとしてソース・データベースに接続するステージング・データベースのデータベース・リンクを定義します。公開操作はすべて、ステージング・データベースのパブリッシャが実行します。詳細は、「非同期分散HotLogの公開の実行」を参照してください。
非同期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の公開の実行」を参照してください。
図16-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バージョンは同じである必要があります。
図16-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概要および管理』を参照してください。
チェンジ・セットは、トランザクション一貫性が保証され、1単位として管理可能な変更データの論理グループです。チェンジ・セットは、1つの(唯一の)チェンジ・ソースのメンバーです。
注意: 次の条件を満たす場合、チェンジ・データ・キャプチャのチェンジ・ソースに1つ以上のチェンジ・セットを含めることができます。
|
パブリッシャが、同じチェンジ・セットに2つ以上のチェンジ・テーブルを含める場合、サブスクライバはチェンジ・セット内で表される表間で結合操作を実行でき、トランザクション一貫性を保証されます。
理論上は、チェンジ・セットは、そのチェンジ・ソースと同じモードを共有します。たとえば、AutoLogチェンジ・セットは、AutoLogチェンジ・ソースに格納されているチェンジ・セットです。パブリッシャは、DBMS_CDC_PUBLISH.CREATE_CHANGE_SET
パッケージを使用してチェンジ・セットを定義できます。同期チェンジ・データ・キャプチャの場合、パブリッシャは事前定義のチェンジ・セットSYNC_SET
も使用できます。ただし、SYNC_SET
チェンジ・セットの変更または削除はできません。
パブリッシャは、チェンジ・セットのチェンジ・テーブルが無制限に大きくならないように、チェンジ・セットのレベルで、チェンジ・テーブルから不要な変更データをパージできます。変更データのパージに関する詳細は、「チェンジ・テーブルの不要なデータのパージ」を参照してください。
表16-1に、チェンジ・ソースとチェンジ・セットの有効な組合せの概要と、それぞれが事前定義かパブリッシャ定義かを示します。また、チェンジ・ソースによって表されるソース・データベースが、ステージング・データベースからリモートかローカルかを示し、チェンジ・ソースが、チェンジ・データ・キャプチャの同期または非同期のどちらのモードで使用されるかを示します。
表16-1 チェンジ・ソースとチェンジ・セットの概要
モード | チェンジ・ソース | 表されるソース・データベース | 関連チェンジ・セット |
---|---|---|---|
同期 |
事前定義の |
ローカル |
事前定義の |
非同期HotLog |
事前定義の |
ローカル |
パブリッシャ定義。 |
非同期分散HotLog |
パブリッシャ定義 |
リモート |
パブリッシャ定義。チェンジ・セットはすべて、同じステージング・データベース上に存在する必要がある。 |
非同期AutoLogオンライン |
パブリッシャ定義 |
リモート |
パブリッシャ定義。AutoLogオンライン・チェンジ・ソースに含めることができるチェンジ・セットは1つのみ。 |
非同期AutoLogアーカイブ |
パブリッシャ定義 |
リモート |
パブリッシャ定義。 |
特定のチェンジ・テーブルには、特定のソース・テーブルに対して実行されたDML操作の結果として生成された変更データが含まれています。チェンジ・テーブルは、データベース表に格納されている変更データ自体と、制御列が含まれるチェンジ・テーブルのメンテナンスに必要なシステム・メタデータで構成されています。
パブリッシャは、チェンジ・テーブルに含めるソース列を指定します。通常、チェンジ・テーブルに有益なデータを含めるには、パブリッシャは、主キー列とサブスクライバが必要とするその他の列をチェンジ・テーブルに含める必要があります。たとえば、サブスクライバがsh.costs
表のUNIT_COST
列とUNIT_PRICE
列に発生する変更を必要とすると仮定します。パブリッシャがチェンジ・テーブルにPROD_ID
列を含めないと、サブスクライバは、ある製品の単位原価および単位価格が変更になったということしかわからず、これらの変更がどの製品に対して発生したかは判別できません。
制御列にはオプションと必須のものがあります。必須の制御列は、常にチェンジ・テーブルに含まれます。オプションの制御列は、チェンジ・テーブルを作成する際にパブリッシャが指定した場合に含まれます。制御列はチェンジ・データ・キャプチャによって管理されます。制御列の詳細は、「チェンジ・テーブルの制御列の理解」および「TARGET_COLMAP$およびSOURCE_COLMAP$の値の理解」を参照してください。
チェンジ・データ・キャプチャ環境に関する情報は、表16-2および表16-3に示す静的データ・ディクショナリ・ビューに用意されています。表16-2は、パブリッシャによる使用を対象としたビューをまとめたものです。この表のビューにアクセスするには、SELECT_CATALOG_ROLE
権限が必要となります。表16-3は、サブスクライバによる使用を対象としたビューの一覧です。表16-3のビューは、接頭辞ALL
またはUSER
が付いています。これらの接頭辞は一般的に次の意味を持ちます。
ALL
接頭辞の付いたビューでは、ユーザーがアクセスできるすべての情報を表示できます。この情報には、現行ユーザー・スキーマの情報および他のスキーマのオブジェクトの情報が含まれます。表示できるのは、現行ユーザーが権限やロールの付与によってこれらのオブジェクトに対するアクセス権を所有している場合です。
USER
接頭辞の付いたビューでは、追加の特別な権限やロールを使用せずに問合せを発行しているユーザーのスキーマの情報をすべて表示できます。
表16-2 チェンジ・データ・キャプチャのパブリッシャによる使用を対象としたビュー
ビュー名 | 説明 |
---|---|
|
既存のチェンジ・ソースを表示します。 |
|
ソース・データベース上の特定の分散HotLogチェンジ・ソースに関連するOracle Streamsの伝播を表示します。このビューは、リリース11.1のチェンジ・ソースではソース・データベース上に移入され、9.2、10.1または10.2のチェンジ・ソースではステージング・データベース上に移入されます。 |
|
ステージング・データベース上の特定の分散HotLogチェンジ・セットに関連するOracle Streamsの伝播を表示します。このビューは、リリース11.1のチェンジ・ソースではソース・データベース上に移入され、9.2、10.1または10.2のチェンジ・ソースではステージング・データベース上に移入されます。 |
|
既存のチェンジ・セットを表示します。 |
|
既存のチェンジ・テーブルを表示します。 |
|
データベース内の公開済のソース・テーブルをすべて表示します。 |
|
データベース内の公開済のソース・テーブルの列をすべて表示します。 |
|
サブスクリプションをすべて表示します。 |
|
任意のサブスクライバがサブスクライブしたソース・テーブルをすべて表示します。 |
|
任意のサブスクライバがサブスクライブしたソース・テーブルの列を表示します。 |
表16-3 チェンジ・データ・キャプチャのサブスクライバによる使用を対象としたビュー
ビュー名 | 説明 |
---|---|
|
現行ユーザーが所有するチェンジ・テーブルの公開ソース・テーブルをすべて表示します。 |
|
現行ユーザーが所有するチェンジ・テーブルの公開ソース・テーブルをすべて表示します。 |
|
現行ユーザーが所有するチェンジ・テーブルのソース・テーブルの公開済の列をすべて表示します。 |
|
現行ユーザーが所有するチェンジ・テーブルのソース・テーブルの公開済の列をすべて表示します。 |
|
現行ユーザーが作成したサブスクリプションをすべて表示します。 |
|
現行ユーザーが作成したサブスクリプションをすべて表示します。 |
|
現行ユーザーがサブスクライブしたソース・テーブルを表示します。 |
|
現行ユーザーがサブスクライブしたソース・テーブルを表示します。 |
|
現行ユーザーがサブスクライブしたソース・テーブルの列を表示します。 |
|
現行ユーザーがサブスクライブしたソース・テーブルの列を表示します。 |
これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
この項では、パブリッシャの作成に関する情報、変更データをキャプチャするモードの選択に関する情報、チェンジ・データ・キャプチャの非同期分散HotLogモードで必要なデータベース・リンクの設定手順、およびチェンジ・データ・キャプチャで必要なデータベース初期化パラメータの設定手順など、変更データの公開を開始する前に、パブリッシャが実行する必要のあるタスクについて説明します。
パブリッシャは公開の実際の手順を実行する前に、次のタスクを行う必要があります。
サブスクライバからの要件の収集
関連ソース・テーブルを含むソース・データベースの判別
キャプチャ・モード(「データをキャプチャするモードの決定」で説明している同期、非同期HotLog、非同期分散HotLog、または非同期AutoLog)の選択
ソース・データベースおよびステージング・データベースのDBAがデータベース初期化パラメータを設定していることの確認(「チェンジ・データ・キャプチャの公開用初期化パラメータの設定」および「変更データの公開」を参照)
ソース・データベースからステージング・データベースへのデータベース・リンクおよびステージング・データベースからソース・データベースへのデータベース・リンクの設定(「非同期分散HotLogの公開の実行」を参照)。これには、ソース・データベースのパブリッシャがステージング・データベースのパブリッシャのユーザー名およびパスワードを知っている必要があり、ステージング・データベースのパブリッシャがソース・データベースのパブリッシャのユーザー名およびパスワードを知っている必要があります。
チェンジ・データ・キャプチャのパブリッシャとなるユーザーは、チェンジ・データ・キャプチャのすべてのモードにおいて、ステージング・データベースDBAが作成します。また、チェンジ・データ・キャプチャの非同期分散HotLogモードでは、ソース・データベースDBAも、パブリッシャとなるユーザーを作成します。このパブリッシャがソース・データベースで実行するタスクは、ソース・データベースからステージング・データベースへのデータベース・リンクの作成のみです。
SYS
およびSYSTEM
ユーザーは、チェンジ・データ・キャプチャのパブリッシャとして使用できません。また、チェンジ・データ・キャプチャのパブリッシャは、デフォルト表領域としてSYSTEM
表領域は使用できません。
以降の項では、チェンジ・データ・キャプチャの各モードで必要とされるパブリッシャの設定方法について説明します。
注意: パブリッシャをSQLDROP USER CASCADE 文で削除すると、そのパブリッシャが所有していたチェンジ・データ・キャプチャのすべてのオブジェクト(他のパブリッシャが所有するチェンジ・データ・キャプチャのオブジェクトを含むものは除く)が削除されます。たとえば、チェンジ・テーブルCDCPUB2.SALES_CT が含まれるチェンジ・セットCDCPUB1_SET をパブリッシャCDCPUB1 が所有しているものと仮定します。ここで、CDCPUB1 を削除するDROP USER CASCADE 文を発行しても、CDCPUB1_SET チェンジ・セットは削除されません。ただし、このチェンジ・セットに含まれるすべてのチェンジ・テーブルが削除された後であれば、パブリッシャはDBMS_CDC_PUBLISH.DROP_CHANGE_SET サブプログラムでCDCPUB1_SET チェンジ・セットを削除できます。 |
使用するチェンジ・データ・キャプチャのモードにかかわらず、ステージング・データベースのパブリッシャは、次に示す権限およびロールを付与されている必要があります。
非同期HotLog、分散HotLog、およびAutoLogの公開では、ステージング・データベースのパブリッシャは、Oracle Streams管理者として構成されている必要があり、CREATE
SEQUENCE
権限も付与されている必要があります。Oracle Streams管理者の構成に関する詳細は、『Oracle Streams概要および管理』を参照してください。
CREATE SEQUENCE
権限が付与されている
ステージング・データベースのDBAが発行したDBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE
サブプログラムに指定されているGRANTEE
である
非同期分散HotLogの公開では、ソース・データベースのパブリッシャは、DBA
ロールが付与されており、DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE
サブプログラムで指定されている権限受領者である必要があります。
ステージング・データベース上にパブリッシャのアカウントを作成する際は、DBAがそのパブリッシャのデフォルト表領域を指定し、パブリッシャは、作成するすべてのチェンジ・テーブル用としてこの表領域を使用することをお薦めします。
変更データをキャプチャするモードの決定は、次の要因によって影響されます。
ステージング・データベースがソース・データベースとリモートかどうか。
変更がソース・データベースに発生してから、チェンジ・データ・キャプチャでキャプチャされるまでの待機時間の許容範囲。一般に、待機時間は表16-4に示す同期から非同期AutoLogアーカイブにかけて長くなります。
ソース・データベース・トランザクションに対するパフォーマンスの影響およびデータベース全体のパフォーマンス。
ソース・データベースとステージング・データベースが、同じオペレーティング・システムまたはOracleデータベースの同じリリースを使用して同じハードウェア上で動作するかどうか。
表16-4に、モードの決定に影響を与えるこれらの要因の概要を示します。
表16-4 チェンジ・データ・キャプチャのモードの選択に影響を与える要因
初期化パラメータは、チェンジ・データ・キャプチャを正常に行うために、ソース・データベースかステージング・データベース、またはその両方で設定する必要があります。どのパラメータを設定するかは、チェンジ・データ・キャプチャが変更データを公開するモード、および、ソース・データベースかステージング・データベースのどちらでパラメータを設定しているかに依存します。
次の項では、チェンジ・データ・キャプチャの各モードにおける、データベース初期化パラメータの設定について説明します。DBAが、現行の設定に値を追加する必要がある場合もあります。DBAは、SQL SHOW
PARAMETERS
文を使用して現行の設定値を参照できます。
これらのデータベース初期化パラメータの詳細は『Oracle Databaseリファレンス』を、非同期の公開用のデータベース初期化パラメータ設定の詳細は『Oracle Streams概要および管理』を参照してください。
表16-5に、ソース・データベースの初期化パラメータおよび非同期HotLogの公開用の推奨設定を示します。
表16-5 非同期HotLogの公開用のソース・データベース初期化パラメータ
パラメータ | 推奨値 |
---|---|
|
11.0 |
|
50000000 |
|
(現行値) + 2 |
|
(現行値) + (5 * (計画しているチェンジ・セットの数)) |
|
(現行値) + (7 * (計画しているチェンジ・セットの数)) |
|
(現行値) + (2 * (計画しているチェンジ・セットの数)) |
|
動的な変更の際に |
|
3600 |
表16-6に、ソース・データベースがOracle Databaseリリース10.1.0、10.2.0または11.1.0の場合の、ソース・データベースの初期化パラメータおよび非同期分散HotLogの公開用の推奨設定を示します。
表16-7に、ソース・データベースがOracle Databaseリリース9.2の場合の、ソース・データベースの初期化パラメータおよび非同期分散HotLogの公開用の推奨設定を示します。
表16-8に、ステージング・データベースの初期化パラメータおよび非同期分散HotLogの公開用の推奨設定を示します。これらは、ソース・データベースに使用されているOracleデータベースのリリースにかかわらず同じです。
表16-6 非同期分散HotLogの公開用のソース・データベース(10.1.0、10.2.0、11.1.0)初期化パラメータ
パラメータ | 推奨値 |
---|---|
|
11.0(ソースOracleデータベースのリリースによって異なる) |
|
|
|
(現行値) + 2 |
|
4または計画している分散HotLogチェンジ・ソース数のいずれか大きい方の値 |
|
(現行値) + (3 * (計画しているチェンジ・ソースの数)) |
|
(現行値) + (4 * (計画しているチェンジ・ソースの数)) |
|
(現行値) + (計画しているチェンジ・ソースの数) |
|
動的な変更の際に |
|
3600 |
表16-7 非同期分散HotLogの公開用のソース・データベース(9.2)初期化パラメータ
パラメータ | 推奨値 |
---|---|
|
9.2.0 |
|
|
|
(現行値) + 2 |
|
1 |
|
計画しているチェンジ・ソースの数と同じ値 |
|
4または計画している分散HotLogチェンジ・ソース数のいずれか大きい方の値 |
|
(現行値) + (3 * (計画しているチェンジ・ソースの数)) |
|
(現行値) + (4 * (計画しているチェンジ・ソースの数)) |
|
(現行値) + (計画しているチェンジ・ソースの数) |
|
|
|
3600 |
表16-8 非同期分散HotLogの公開用のステージング・データベース(11.1.0)初期化パラメータ
パラメータ | 推奨値 |
---|---|
|
11.0 |
|
|
|
50000000 |
|
4または計画している分散HotLogチェンジ・セット数のいずれか大きい方の値 |
|
(現行値) + (2 * (計画しているチェンジ・セットの数)) |
|
(現行値) + (3 * (計画しているチェンジ・セットの数)) |
|
(現行値) + (計画しているチェンジ・セットの数) |
|
動的な変更の際に |
表16-9に、データベース初期化パラメータとソース・データベースの非同期AutoLogの公開用推奨設定を、表16-10に、データベース初期化パラメータとステージング・データベースの非同期AutoLogの公開用推奨設定を示します。
表16-9 非同期AutoLogの公開用のソース・データベース初期化パラメータ
パラメータ | 推奨値 |
---|---|
|
11.0 |
|
自身のアーカイブREDOログ・ファイルが保存されるソース・データベース上のディレクトリ指定。 |
|
このパラメータには、
|
|
REDO転送サービスでアーカイブREDOログ・ファイルをこの宛先に転送できるよう指定します。 |
|
REDO転送サービスでREDOログ・ファイルをこの宛先に転送できるよう指定します。 |
|
REDOログ・ファイルをアーカイブする際の、デフォルトのファイル名のフォーマット・テンプレートを指定します。注2文字列値( |
|
このソース・データベースでREDOログ・ファイルをリモートの宛先に送信できるよう指定します。 |
注1 このパラメータの整数値は、1〜10の間の任意の値を指定できます。このマニュアルでは、値1および2を使用します。各LOG_ARCHIVE_DEST_
n
パラメータに対して、対応するLOG_ARCHIVE_DEST_STATE_
n
パラメータ(n
は同じ数値)を指定する必要があります。
注2 フォーマット・テンプレートでは、%tがスレッド番号、%sが順序番号、%rがリセットログIDに対応します。これらを組み合せることにより、コピーされたREDOログ・ファイルに一意の名前が割り当てられます。どの要素も必須ですが、順番とフォーマットは柔軟に変更できます。
表16-10 非同期AutoLogの公開用のステージング・データベース初期化パラメータ
パラメータ | 推奨値 |
---|---|
|
11.1.0 |
|
|
|
50000000 |
|
自身のアーカイブREDOログ・ファイルが保存されるステージング・データベース上のディレクトリ指定。ステージング・データベースにAutoLogオンライン・チェンジ・ソースが含まれる場合、次の属性を指定する必要があります。
|
|
ステージング・データベースにAutoLogオンライン・チェンジ・ソースが含まれる場合、これは、ソース・データベースから変更データを受け取る、ステージング・データベース上のスタンバイREDOログ・ファイルを指定します。これらのスタンバイREDOログ・ファイルには一意の場所を指定することが非常に重要です。一意の場所を指定することで、ステージング・データベースの自身のアーカイブ・ログ・ファイルがこれらのスタンバイREDOログ・ファイルによって上書きされないようにするためです。
|
|
REDO転送サービスでアーカイブREDOログ・ファイルをこの宛先に転送できるよう指定します。 |
|
REDO転送サービスでREDOログ・ファイルをこの宛先に転送できるよう指定します。 |
|
REDOログ・ファイルをアーカイブする際の、デフォルトのファイル名のフォーマット・テンプレートを指定します。注2文字列値( |
|
2 |
|
(現行値) + (5 * (計画しているチェンジ・セットの数)) |
|
(現行値) + (7 * (計画しているチェンジ・セットの数)) |
|
このステージング・データベースで、アーカイブREDOログ・ファイルをリモートで受け取ることができるよう指定します。 |
|
(現行値) + (2 * (計画しているチェンジ・セットの数)) |
|
動的な変更の際に |
|
3600 |
注1 このパラメータの整数値は、1〜10の間の任意の値を指定できます。このマニュアルでは、値1および2を使用します。各LOG_ARCHIVE_DEST_
n
パラメータに対して、対応するLOG_ARCHIVE_DEST_STATE_
n
パラメータ(n
は同じ数値)を指定する必要があります。
注2 フォーマット・テンプレートでは、%tがスレッド番号、%sが順序番号、%rがリセットログIDに対応します。これらを組み合せることにより、コピーされたREDOログ・ファイルに一意の名前が割り当てられます。どの要素も必須ですが、順番とフォーマットは柔軟に変更できます。
非同期チェンジ・データ・キャプチャでは、各チェンジ・セットについて、Oracle Streams構成を使用します。このStreams構成は、Streamsの取得プロセスと適用プロセス、キューおよびキュー表で構成されます。各Streams構成では、追加のプロセス、パラレル実行サーバーおよびメモリーが使用されます。Streamsアーキテクチャの詳細は、『Oracle Streams概要および管理』を参照してください。
構成になんらかの変更があった場合は、初期化パラメータの調整が必要となることがあります。詳細は、表16-10「非同期AutoLogの公開用のステージング・データベース初期化パラメータ」を参照してください。
次の項では、様々なタイプの公開を実行する手順を提供します。
同期チェンジ・データ・キャプチャに対しては、パブリッシャは事前定義のチェンジ・ソース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 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
がサブスクリプションを作成する準備ができました。
チェンジ・データ・キャプチャは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
モードで実行されているものとします。
データベースをFORCE
LOGGING
ロギング・モードに設定し、非同期チェンジ・データ・キャプチャではキャプチャできない、ソース・データベースでのロギングされないダイレクト書込み操作を回避します。
ALTER DATABASE FORCE LOGGING;
ロギングは、表領域レベルまたは表レベルでも実行可能です。
サプリメンタル・ロギングを有効化します。サプリメンタル・ロギングによって、UPDATE
操作を実行するとすぐに、追加の列データがREDOログ・ファイルに配置されます。最低限、どのようなチェンジ・データ・キャプチャのソース・データベースに対しても、データベース・レベルの最小サプリメンタル・ロギングを有効化する必要があります。
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
ソース・テーブルでキャプチャされるすべての列に対して、無条件のログ・グループを作成します。変更されない、無条件のログ・グループにないソース・テーブルの列は、実際のソース・テーブルの値を反映せずに、チェンジ・テーブルにおいて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のチェンジ・データ・キャプチャでは、ステージング・データベースはソース・データベースとリモートです。ただし、データベース・リンク、Oracle Streamsおよびチェンジ・データ・キャプチャを設定する手順は、ソース・データベースとステージング・データベースの両方で実行する必要があります。次に、ソース・データベースDBA、ステージング・データベースDBA、および各データベースのパブリッシャが実行する必要があるタスクを示します。
ソース・データベースDBAは、Oracle Net、データベース初期化パラメータの設定、強制ロギングおよびサプリメンタル・ロギングを有効化するためのソース・データベースの変更、およびソース・データベースのパブリッシャの作成を行います。
ステージング・データベースDBAは、データベース初期化パラメータの設定およびステージング・データベースのパブリッシャの作成を行います。
ソース・データベースのパブリッシャは、ソース・データベースからステージング・データベースへのデータベース・リンクの設定を行います。
ステージング・データベースのパブリッシャは、ステージング・データベースからソース・データベースへのデータベース・リンクの設定、個々のソース・テーブルに加えられる変更を格納するチェンジ・テーブル、チェンジ・セット、チェンジ・ソースの新規作成、および必要な権限のサブスクライバへの付与を行います。
この例では、ソース・データベースDBA、ステージング・データベースDBA、および各データベースのパブリッシャは4人の異なるユーザーとします。
手順1 ソース・データベースDBA: ソース・データベースの準備
ソース・データベースDBAは、次のタスクを実行します。
Oracle Netを構成して、ソース・データベースがステージング・データベースと通信できるようにします。Oracle Netについては、『Oracle Database Net Services管理者ガイド』を参照してください。
「チェンジ・データ・キャプチャの公開用初期化パラメータの設定」で説明しているように、ソース・データベース上でデータベース初期化パラメータを設定します。次のコード例では、ソース・データベースがOracle Databaseリリース11.1、計画しているチェンジ・ソースの数が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つのチェンジ・セットが定義されます。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
モードで実行されているものとします。
データベースをFORCE
LOGGING
ロギング・モードに設定し、非同期チェンジ・データ・キャプチャではキャプチャできない、ソース・データベースでのロギングされないダイレクト書込みを回避します。
ALTER DATABASE FORCE LOGGING;
サプリメンタル・ロギングを有効化します。サプリメンタル・ロギングによって、更新操作を実行するとすぐに、追加の列データがREDOログ・ファイルに配置されます。
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
ソース・テーブルでキャプチャされるすべての列に対して、無条件のログ・グループを作成します。変更されない、無条件のログ・グループにないソース・テーブルの列は、実際のソース・テーブルの値を反映せずに、チェンジ・テーブルにおいて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
がサブスクリプションを作成する準備ができました。
チェンジ・データ・キャプチャは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ログ・ファイルを受け取る準備をする必要があります。
ソース・データベースDBAはOracle Netを構成して、ソース・データベースがステージング・データベースと通信できるようにします。Oracle Netについては、『Oracle Database Net Services管理者ガイド』を参照してください。
ソース・データベース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: データベース初期化パラメータの設定
ステージング・データベース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
モードで実行されているものとします。
データベースをFORCE
LOGGING
ロギング・モードに設定し、非同期チェンジ・データ・キャプチャではキャプチャできない、ソース・データベースでのロギングされないダイレクト書込みを回避します。
ALTER DATABASE FORCE LOGGING;
サプリメンタル・ロギングを有効化します。サプリメンタル・ロギングによって、更新操作を実行するとすぐに、追加の列データがREDOログ・ファイルに配置されます。
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
ソース・テーブルでキャプチャされるすべての列に対して、無条件のログ・グループを作成します。変更されない、無条件のログ・グループにないソース・テーブルの列は、実際のソース・テーブルの値を反映せずに、チェンジ・テーブルにおいて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ログ・ファイルを実際に作成する必要があります。
ソース・データベース上で使用されるログ・ファイルのサイズを決定します。スタンバイREDOログ・ファイルはこのサイズと同じかそれ以上にする必要があるためです。ソース・データベースに対してV$LOG
を問い合せると、ソース・データベースのログ・ファイルのサイズを確認できます。
ステージング・データベース上で必要なスタンバイ・ログ・ファイル・グループの数を決定します。この数は、ソース・データベース上のオンライン・ログ・ファイル・グループの数より少なくとも1以上大きな数にする必要があります。ソース・データベースに対してV$LOG
を問い合せると、ソース・データベース上のオンライン・ログ・ファイル・グループの数を確認できます。
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値を取得する必要があります。手順9で、パブリッシャはチェンジ・ソースを作成する際に、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のリストがALL_PUBLISHED_COLUMNS
ビューに格納されます。パブリケーションIDとは、パブリッシャが定義した各チェンジ・テーブルに、チェンジ・データ・キャプチャによって割り当てられる数値のことです。
サブスクライバは、使用する1つ以上のソース・テーブルを登録し、これらの表へのサブスクリプションを取得します。サブスクライバに十分なアクセス権があるとすると、サブスクライバは次のいずれかの方法で、パブリッシャが1つ以上のチェンジ・テーブルを作成したどのソース・テーブルに対してもサブスクライブできます。
対象の列およびソース・テーブルを指定する
対象の列を含むパブリケーションが複数ある場合、チェンジ・データ・キャプチャはユーザーのかわりに1つを選択します。
対象の列およびパブリケーションIDを指定する
単一のソース・テーブルに複数のパブリケーションがあり、これらのパブリケーションでいくつかの列が共有されている際に、共有されている列のどれかが単一のサブスクリプションで使用される場合、サブスクライバは、ソース・テーブルではなくパブリケーションIDを指定する必要があります。
次の手順では、両方のシナリオを例示する例を示します。
手順1 サブスクライバがアクセス権を付与されているソース・テーブルの検索
サブスクライバは、ALL_SOURCE_TABLES
ビューを問い合せて、サブスクライバがアクセス権を付与されている公開済のソース・テーブルをすべて参照します。
SELECT * FROM ALL_SOURCE_TABLES; SOURCE_SCHEMA_NAME SOURCE_TABLE_NAME ------------------------------ ------------------------------ SH PRODUCTS
手順2 サブスクライバがアクセス権を付与されている列およびチェンジ・セット名の検索
サブスクライバは、ALL_PUBLISHED_COLUMNS
ビューを問い合せて、サブスクライバがアクセス権を付与されているsh.products
表のパブリケーションID、列およびチェンジ・セットをすべて参照します。
SELECT UNIQUE CHANGE_SET_NAME, COLUMN_NAME, PUB_ID FROM ALL_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に示す結果のかわりに、ALL_PUBLISHED_COLUMNS
ビューの問合せでは、次の例に示すように、対象の列が複数のパブリケーションに含まれていることが示されるものとします。
SELECT UNIQUE CHANGE_SET_NAME, COLUMN_NAME, PUB_ID FROM ALL_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; /
手順9 手順6〜8の繰返し
サブスクライバは、追加の変更データが必要な間は、手順6〜8を繰り返します。
手順10 サブスクリプションの終了
サブスクライバは、DBMS_CDC_SUBSCRIBE
.DROP_SUBSCRIPTION
プロシージャを使用して、サブスクリプションを終了します。これは、サブスクリプションの基礎をなすパブリケーションが、無期限に変更データを保持することを回避するために必要です。
BEGIN DBMS_CDC_SUBSCRIBE.DROP_SUBSCRIPTION( subscription_name => 'SALES_SUB'); END; /
この項では、チェンジ・セットおよびチェンジ・テーブルの管理に関わる管理タスクの情報を提供します。ほとんどの場合、これらのタスクはパブリッシャが実行します。ただし、チェンジ・テーブルから不要なデータをパージする場合は、パブリッシャとサブスクライバの両方で行う必要があります(「チェンジ・テーブルの不要なデータのパージ」を参照)。
この項では次のトピックについて説明します。
この項では、パブリッシャが非同期チェンジ・ソースの管理を行うことができるタスクに関する情報を取り上げます。次のトピックで構成されています。
パブリッシャは、非同期分散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で停止するかどうかを指定できます。パブリッシャは、次のコールで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)が処理されます。この際、変更データが失われることはありません。 |
SQL文のTRUNCATE
TABLE
をPRODUCTS
ソース・テーブルに対して発行して、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$
制御列を評価する必要があります。無条件のログ・グループの作成については、「非同期チェンジ・データ・キャプチャとサプリメンタル・ロギング」を、制御列については、「チェンジ・テーブルの制御列の理解」を参照してください。
チェンジ・テーブルは、データベース表に格納されている変更データ自体と、制御列が含まれるチェンジ・テーブルのメンテナンスに必要なシステム・メタデータで構成されています。
表16-11に、チェンジ・テーブルの制御列を示します。表には、列名、データ型、モード、列がオプションかどうか、および説明が含まれます。
モードは、列に関連付けられたチェンジ・データ・キャプチャのタイプを示します。値All
は、列が同期モードおよび非同期チェンジ・データ・キャプチャのすべてのモードに関連付けられていることを示します。同期および非同期チェンジ・データ・キャプチャの両方のモードについて、サブスクライバがサブスクライバ・ビューを問い合せてDML変更を発生した順番で戻す場合、その問合せでは、CSCN$
およびRSID$
の順でデータを整列する必要があります。
制御列は、パブリッシャがチェンジ・テーブルから除外することを選択できる場合はオプションとみなされます。表16-11では、どのモードでどの制御列がオプションとなるかを示しています。オプションの制御列はすべてDBMS_CDC_PUBLISH.CREATE_CHANGE_TABLE
プロシージャのパラメータで指定されます。DBMS_CDC_PUBLISH.CREATE_CHANGE_TABLE
プロシージャの構文については、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。
表16-11 チェンジ・テーブルの制御列
列 | データ型 | モード | オプション列 | 説明 |
---|---|---|---|---|
|
All |
不可 |
この列の値には、次のいずれかを指定できます。注1
|
|
|
All |
不可 |
同期CDCの場合は、 |
|
|
|
非同期 |
可能 |
実行された実際のDDL文を含むCLOB。 |
|
|
非同期 |
可能 |
このリリースでは使用されません。 |
|
|
非同期 |
可能 |
実行されたDDL操作の種類を示すビット・ベクトル。 |
|
All |
可能 |
このトランザクション内の一意の行順序ID。注2 |
|
|
同期 |
可能 |
ビット・マスク注3(ソース・テーブル内の更新済列のビットマスク)。 |
|
|
All |
可能 |
ビット・マスク注3(チェンジ・テーブル内の更新済列のビットマスク)。 |
|
|
All |
不可 |
このトランザクションのコミット時刻。 |
|
|
All |
可能 |
ソース・テーブルで操作が発生した時刻。 |
|
|
All |
可能 |
操作を実行したユーザーの名前。リリース10.2より前のOracle Databaseで作成されたチェンジ・ソースの場合、値は常に |
|
|
All |
可能 |
ソース・テーブル内で影響を受ける行のROWID。リリース10.2より前のOracle Databaseで作成されたチェンジ・ソースの場合、値は常にNULLです。 |
|
|
非同期 |
不可 |
トランザクションIDのUNDOセグメント番号。 |
|
|
非同期 |
不可 |
トランザクションIDのスロット番号。 |
|
|
非同期 |
不可 |
トランザクションIDの順序番号。 |
|
|
同期 |
可能 |
オブジェクトID。 |
注1 この列に基づいた問合せを指定する場合、I
またはD
列値をそれぞれ「I」、「D」として指定します。OPERATION$
列は2文字列で、値は左揃えおよび空白詰めです。「I」または「D」の値を指定する問合せでは、値は戻されません。
注2 RSID$
列を使用して、特定の操作のアフター・イメージとビフォア・イメージを関連付けることができます。特定の更新操作について、アフター・イメージのRSID$
列の値は常に、ビフォア・イメージのRSID$
列値の値と一致します。
注3 ビットマスクは、行のどの列が更新されているかを示すバイナリ値の配列です。
TARGET_COLMAP$
およびSOURCE_COLMAP$
列は、行のどの列が変更されたかを示すために使用します。TARGET_COLMAP$
列は、チェンジ・テーブル行のどの列が変更されたかを示します。SOURCE_COLMAP$
列(同期チェンジ・テーブルにのみ含まれる)は、ソース・テーブル行のどの列が変更されたかを示します。
TARGET_COLMAP$
およびSOURCE_COLMAP$
列のデータ型はRAW(128)
なので、各列には128バイトのバイナリ情報を格納できます。このバイナリ情報は、左側の下位バイトと右側の上位バイトが連なったワードから構成されます。デフォルトでは、フィールドが表示される際に、システムによって各バイトが解釈され、それぞれの値が表示されます。例16-1に、TARGET_COLMAP$
のサンプル値を示します。例の後でこのデータの解釈方法を説明します。
例16-1 TARGET_COLMAP$のサンプル値
FE110000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000
例16-1の最初の「FE」が下位バイトで、最後の「00」が上位バイトです。値の意味を正しく解釈するには、各バイトに設定されているビットを考察する必要があります。ビットマップのビットは、0から開始してカウントされます。最初のビットはビット0、2つ目のビットはビット1などとなります。ビット0は常に無視されます。その他のビットについては、特定のビットが1に設定される場合、その列の値が変更されていることを意味します。
例16-1で示したバイト列を解釈するには、左から右に読む必要があります。最初のバイトは文字列「FE」です。左から右にビットに分解すると、この文字列は「1111 1110」となり、チェンジ・テーブルの列「7,6,5,4 3,2,1,-」(ハイフンは無視されたビットを表す)にマップされます。最初のビットは、チェンジ・テーブルの列7が変更されたかどうかを示します。最も右側のビットは無視されています。例16-1のこれらの値は、最初の7列に値があることを示しています。チェンジ・テーブル内の最初のいくつかの列は制御列であるため、これは典型的なことです。
例16-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
例16-1を使用すると、パブリッシャは、OPERATION$
、CSCN$
、COMMIT_TIMESTAMP$
、XIDUSN$
、XIDSLT$
、XIDSEQ$
、RSID$
、TARGET_COLMAP$
およびC_DATE
の列が、このTARGET_COLMAP$
の値によって表されるチェンジ・テーブルの特定の変更行で変更されたことがわかります。
チェンジ・データ・キャプチャでは、すべての変更行のすべての制御列の値が生成されるので、制御列に対応するビットは、各TARGET_COLMAP$
列で常に1に設定されることに注意してください。OPERATION$
列の値がUN
およびI
の場合、変更されたユーザー列に対応するビットは、必要に応じて1に設定されます。OPERATION$
列の値については、表16-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$
列の値がUO
、UU
、UN
およびI
の場合、SOURCE_COLMAP$
列において、変更されたソース列は1に設定される。OPERATION$
列の値については、表16-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
権限を付与する必要があります。
また、パブリッシャは、チェンジ・テーブルのサブスクライバに(INSERT
、UPDATE
、DELETE
文を使用する)いかなる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_SUBSCRIBE.PURGE_WINDOW
プロシージャへのコールとチェンジ・データ・キャプチャによるPURGE
プロシージャへのコール(またはパブリッシャによるいずれかのPURGE
プロシージャへのコール)は一緒に機能します。つまり、各サブスクライバがサブスクリプション・ウィンドウをパージする際、不要になった変更データが示され、実際にデータをパージする前に、すべてのサブスクライバからの入力全体がPURGE
プロシージャによって評価されます。表をパージする場合はPURGE_CHANGE_TABLE
プロシージャを、チェンジ・セットのすべてのチェンジ・テーブルをパージする場合はPURGE_CHANGE_SET
プロシージャを使用します。
force
がN
に設定されている場合、Oracle Databaseは最も効率的な方法で(表ロックを使用して)パージしようとします。ただしパージは保証されません。force
をY
に設定すると、このパージは保証されます。
サブスクライバがPURGE_WINDOW
のコールに失敗し、不要な行がパージ・ジョブによって削除されない結果となる可能性があることに注意してください。パブリッシャはDBA_SUBSCRIPTIONS
ビューを問い合せて、このような事態が起こっているかどうかを判断できます。極端な場合には、パブリッシャがアクティブなサブスクリプションを手動で削除して領域を再利用できるようにすることもあります。そのような事態の一例は、サブスクライバが、適切な場合にPURGE_WINDOW
プロシージャのコールに失敗するアプリケーション・プログラムである場合です。パブリッシャは、必要に応じてDBMS_CDC_PUBLISH.DROP_SUBSCRIPTION
プロシージャを使用してアクティブなサブスクリプションを削除できますが、サブスクライバが変更データを使用している可能性があることを第一に考慮する必要があります。
チェンジ・テーブルを削除するには、パブリッシャは、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
プロシージャをコールします。これは、通常の安全策を無効にし、アクティブなサブスクリプションがある場合でもチェンジ・テーブルを削除できるようチェンジ・データ・キャプチャに通知します。サブスクリプションは有効でなくなり、サブスクライバは変更データにアクセスできなくなります。
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
パラメータの効果と似ています)。チェンジ・データ・キャプチャでは、これらの場合について、インポート・ログに警告が生成されます。
チェンジ・データ・キャプチャ・オブジェクトは、すべての基底オブジェクトが予定どおり正常な形式で存在しているかどうかを判別するためにインポート操作の最後に検証されます。チェンジ・データ・キャプチャでは、検証の問題が検出されると、インポート・ログに検証の警告が生成されます。検証の警告を伴ってインポートされたチェンジ・データ・キャプチャ・オブジェクトは通常、変更データのキャプチャを続行できません。
次に、チェンジ・データ・キャプチャ・オブジェクトをサポートする、データ・ポンプ・エクスポート・コマンドとインポート・コマンドの例を示します。
> 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チェンジ・データ・キャプチャ・オブジェクトの基になるデータベース・オブジェクトを手動で削除する必要があります。
パブリッシャは、適切なDBMS_CDC_PUBLISH
プロシージャを使用して、AutoLogのチェンジ・ソース、チェンジ・セットおよびチェンジ・テーブルを再作成する必要があります。
サブスクライバは、AutoLogチェンジ・セットに対してサブスクリプションを再作成する必要があります。
AutoLogチェンジ・データ・キャプチャのオブジェクトが関与するデータ・ポンプの全データベース・エクスポート操作と、前述の手順におけるデータ・ポンプの全データベース・インポート操作後の再作成との合間において、変更データが失われる場合があります。この合間でソース・テーブルに対する変更をできるだけ防止することによって、この可能性を最小化できます。
データ・ポンプ・インポート操作後にAutoLogチェンジ・データ・キャプチャ構成を再作成する前に、基底のオブジェクト(チェンジ・テーブルの基になる表、サブスクライバ・ビュー、チェンジ・セットで使用される順序、Streamsの適用プロセス、Streamsのキューおよびキュー表)を最初に削除する必要があります。表16-12に、基底の各オブジェクトおよびデータ・ポンプ・インポート操作後にそれらのオブジェクトを削除する方法を示します。
表16-12 データ・ポンプ・インポート操作後にオブジェクトを削除する方法
オブジェクト | オブジェクトを削除するSQL文またはPL/SQLパッケージ |
---|---|
表 |
SQL |
サブスクライバ・ビュー |
SQL |
チェンジ・セットで使用される順序 |
SQL |
Streams適用プロセス |
PL/SQL |
Streamsのキュー |
PL/SQL |
Streamsのキュー表 |
PL/SQL |
チェンジ・セットで使用される順序の名前を取得するには、CDC$
で始まり、少なくともチェンジ・セット名の頭文字が含まれる順序名についてALL_SEQUENCES
ビューを問い合せます。
Streamsオブジェクトの名前を取得するには、CDC$
で始まり、少なくともチェンジ・セット名の頭文字が含まれる名前について、DBA_APPLY
、DBA_QUEUES
およびDBA_QUEUE_TABLES
ビューを問い合せます。
チェンジ・データ・キャプチャ環境は動的です。パブリッシャは、チェンジ・テーブルを随時追加または削除できます。また、必要に応じて既存のチェンジ・テーブルに列を追加したり、そこから列を削除できます。次のリストでは、チェンジ・データ・キャプチャ環境に対する変更がサブスクリプションに与える影響について説明します。
パブリッシャが、新規のチェンジ・テーブルを追加したり、既存のチェンジ・テーブルに列を追加したりしても、サブスクライバには明示的に通知されません。サブスクライバは、ALL_PUBLISHED_COLUMNS
ビューをチェックして、新規の列が追加されたかどうかや、その列へのアクセス権が付与されているかどうかを確認できます。
表16-13に、パブリッシャがチェンジ・テーブルに列を追加した際の影響を示します。
表16-13 パブリッシャがチェンジ・テーブルに列を追加することによる影響
パブリッシャが追加するもの | 条件 | 結果 |
---|---|---|
ユーザー列 |
新しいサブスクリプションにこの列が含まれる |
このサブスクリプションのサブスクリプション・ウィンドウが、列が追加された点から始まります。 |
ユーザー列 |
新しいサブスクリプションに、この新しく追加した列が含まれない |
このサブスクリプションのサブスクリプション・ウィンドウは、変更データが最初に使用できる時点から始まります。新しい列は表示されません。 |
ユーザー列 |
サブスクリプションが存在する |
このサブスクリプションのサブスクリプション・ウィンドウが変更されないまま残ります。 |
制御列 |
新しいサブスクリプションが作成される |
このサブスクリプションのサブスクリプション・ウィンドウは、変更データが最初に使用できる時点から始まります。サブスクリプションでは、制御列を即時に参照できます。制御列を追加する前に存在していたチェンジ・テーブルのすべての行では、新規に追加された制御列の値がNULLになります。 |
制御列 |
サブスクリプションが存在する |
このサブスクリプションでは、サブスクリプション・ウィンドウの低位限界が制御列が追加された時点を超えるようにサブスクリプション・ウィンドウをパージする( |
以降の項では、チェンジ・データ・キャプチャの同期モードを使用する際に、パブリッシャが注意すべき情報を取り上げます。
同期チェンジ・データ・キャプチャは、ダイレクト・パス・インサート文(および、関連する
MERGE
文およびINSERT
文のmulti_table_insert
句)の機能をサポートしていません。
パブリッシャが同期モードでチェンジ・テーブルを作成する際、チェンジ・データ・キャプチャは、ソース・テーブルに対してトリガーを作成します。ダイレクト・パス・インサート文は、データベース・トリガーをすべて無効にするため、パラレルDMLモードでダイレクト・パス・インサート
用のSQL文を使用してソース・テーブルに挿入された行は、チェンジ・テーブルにキャプチャされません。
同様に、チェンジ・データ・キャプチャは、マルチテーブルのインサート操作およびマージ操作から挿入された行をキャプチャできません。これらの文はダイレクト・パス・インサート文を使用するためです。また、ダイレクト・パス・インサート
文では、チェンジ・データ・キャプチャで使用されるトリガーが起動されなかったことを示すエラー・メッセージは戻されません。
ダイレクト・パス・インサート文およびトリガーの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
同期チェンジ・データ・キャプチャでは、次のものを除く、Oracleのすべての組込みデータ型の列をサポートしています。
BFILE
BLOB
CLOB
LONG
NCLOB
ROWID
UROWID
オブジェクト・タイプ(XMLTypeなど)
仮想列はサポートされません。
同期チェンジ・データ・キャプチャでは、次の表構造をサポートしません。
一時表であるソース・テーブル
オブジェクト表であるソース・テーブル
サポートされていないデータ型の列(LOB
列を含む)またはオーバーフロー・セグメントを持つ索引構成表
同期チェンジ・テーブルのソース・テーブルを削除した後にごみ箱からリストアすると、そのチェンジ・テーブルには変更がキャプチャされなくなります。パブリッシャは、リストアしたソース・テーブルに対する今後の変更をキャプチャするために、新しい同期チェンジ・テーブルを作成する必要があります。
以降の項では、チェンジ・データ・キャプチャの非同期モードを使用する際に、パブリッシャとソースおよびステージング・データベースDBAが注意すべき情報を提供します。
チェンジ・データ・キャプチャの非同期モードでは、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
ビューを移入するようにします。パブリッシャは次の手順に従います。
ステージング・データベースで次の問合せを使用して、チェンジ・セット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
元の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ログ・ファイルすべてが必要です。
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となります。
たとえば、ソース・テーブルに、X
とY
という2つの列が格納されており、ソース・データベースDBAは、そのテーブルに対してY
列のみが含まれる無条件のログ・グループを定義しているものと仮定します。さらに、ユーザーはその表の行のY
列のみ更新するものとします。サブスクライバがその行の変更データを参照する際、変更されていない列X
の値はNULLとなります。ただし、X
の実際の列値はREDOログ・ファイルから除外されており、チェンジ・テーブルに含めることができないので、サブスクライバは、X
列の実際のソース・テーブル値がNULLであることが推測できません。サブスクライバは、列X
の実際のソース・テーブル値がNULLであるか、変更されていないのかを判別するには、TARGET_COLMAP$
制御列の内容で判断します。
様々なタイプのサプリメンタル・ロギングの詳細は、『Oracle Databaseユーティリティ』を参照してください。
非同期チェンジ・データ・キャプチャでは、変更データのキャプチャおよびチェンジ・セットの移入を行うために、Oracle Streamsのコンポーネント(構成要素)が生成されます。これらのコンポーネントを、他の目的で再利用または共有しないでください。たとえば、分散HotLogチェンジ・ソースに対してチェンジ・データ・キャプチャによって生成されるキャプチャ・キューは、ユーザーが新たに作成したStreams伝播用のソース・キューとしては使用できません。
HotLogおよびAutoLogモードの場合、各チェンジ・セットには、Streamsの取得プロセス、キュー、キュー表および適用プロセスが含まれます。これらのオブジェクトはすべてステージング・データベースのパブリッシャが所有します。分散HotLogモードの場合、各チェンジ・ソースはソース・データベース上に存在し、Streamsの取得プロセス、キューおよびキュー表が含まれます。各チェンジ・セットはステージング・データベース上に存在し、それぞれにStreamsの適用プロセスが含まれます。チェンジ・ソースに最初のチェンジ・セットを作成すると、チェンジ・ソース内のすべてのチェンジ・セット間で共有されるキューおよびキュー表がチェンジ・データ・キャプチャによってステージング・データベース上に生成されます。また、チェンジ・ソース・キューからステージング・データベースのチェンジ・セット・キューまでソース・データベースのStreamsの伝播が生成されます。ソース・データベース・オブジェクトはソース・データベースのパブリッシャが所有し、ステージング・データベース・オブジェクトはステージング・データベースのパブリッシャが所有します。
図16-8は、非同期分散HotLogチェンジ・データ・キャプチャ環境でStreamsコンポーネントがどのように使用されるかを例示しています。この例では、ソース・データベース上に1つの分散HotLogチェンジ・ソースdisthot_change_src
があり、ステージング・データベース上に2つのチェンジ・セットChange_Set_1
およびChange_Set_2
があります。
図16-8 非同期分散HotLogチェンジ・データ・キャプチャ・システムのStreamsコンポーネント
非同期チェンジ・データ・キャプチャでは、次のものを除く、Oracleのすべての組込みデータ型の列をサポートしています。
BFILE
LONG
ROWID
UROWID
オブジェクト・タイプ(XMLTypeなど)
仮想列はサポートされません。
非同期チェンジ・データ・キャプチャでは、次の表構造をサポートしません。
一時表であるソース・テーブル
オブジェクト表であるソース・テーブル
サポートされていないデータ型の列(LOB
列を含む)またはオーバーフロー・セグメントを持つ索引構成表
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
TABLE
、ALTER
TABLE
およびDROP
TABLE
の各SQL文に対してシステム・トリガーが配置されます。システム・トリガーがソース・データベースに対して使用禁止にされていると、チェンジ・データ・キャプチャは正しく動作しません。したがって、システム・トリガーは使用禁止にしないでください。
チェンジ・データ・キャプチャをデータベースから削除するために、admin
ディレクトリにSQLスクリプトrmcdc.sql
が用意されています。これは、チェンジ・データ・キャプチャによって、CREATE
TABLE
、ALTER
TABLE
およびDROP
TABLE
の各SQL文に配置されたシステム・トリガーを削除します。さらに、rmcdc.sql
は、チェンジ・データ・キャプチャで使用されるJavaクラスをすべて削除します。rmcdc.sql
をコールした後は、システムでチェンジ・データ・キャプチャが動作しなくなることに注意してください。システム管理者がデータベースからJava仮想マシンを削除することにした場合、rmjvm
をコールする前にrmcdc.sql
をコールする必要があります。
チェンジ・データ・キャプチャを再インストールするために、admin
ディレクトリにSQLスクリプトinitcdc.sql
が用意されています。これは、チェンジ・データ・キャプチャに必要なチェンジ・データ・キャプチャのシステム・トリガーとJavaクラスを作成します。チェンジ・データ・キャプチャを再インストールするには、Java仮想マシンを使用できるようにする必要があります。
Database Configuration Assistantで提供される事前定義のテンプレートはすべて、Oracleのチェンジ・データ・キャプチャ機能をサポートしています。事前定義のテンプレートには次のものがあります。
汎用
データ・ウェアハウス
トランザクション処理
新規データベース
「新規データベース」オプションを選択してカスタム・データベースを作成する場合、「追加」データベース構成ダイアログ・ボックスではデフォルトで「Oracle JVM」が選択されます。Oracleのチェンジ・データ・キャプチャではOracle JVM機能が必要なので、この設定を変更しないてください。
以降の項では、チェンジ・データ・キャプチャの分散HotLogモードでサポートされている構成および制限について説明します。
チェンジ・データ・キャプチャの分散HotLogモードでは、ソース・データベースおよびステージング・データベースに次のOracle Databaseのリリースを組み合せて使用できます。
9.2.0.6以降のパッチ・セットが適用されたOracle Databaseリリース9.2のソース・データベースとリリース11.1のステージング・データベース
Oracle Databaseリリース10.1のソース・データベースとリリース11.1のステージング・データベース
Oracle Databaseリリース10.2のソース・データベースとリリース11.1のステージング・データベース
Oracle Databaseリリース11.1のソース・データベースとリリース11.1のステージング・データベース
注意: リリース9.2または10.1のOracle Databaseがチェンジ・データ・キャプチャの分散HotLogモードのソース・データベースとなる場合、ソース・データベースのメタデータはステージング・データベース上に格納されるのに対して、Oracle Databaseリリース11.1のソース・データベースのメタデータはソース・データベース上に格納されます。したがって、Oracle Databaseリリース9.2またはリリース10.1のソース・データベースのメタデータを参照するには、パブリッシャは、ステージング・データベースに対してCHANGE_SOURCES データ・ディクショナリ・ビューを問い合せ、Oracle Databaseリリース11.1のソース・データベースのメタデータを参照するには、ソース・データベースに対してCHANGE_SOURCES データ・ディクショナリ・ビューを問い合せる必要があります。 |
前述のとおり、Oracle Databaseリリース11.1の分散HotLogチェンジ・ソースのメタデータはソース・データベースに格納されますが、リリース9.2または10.1のチェンジ・ソースのメタデータはステージング・データベースに格納されます。
リリース10.2のOracle Databaseをリリース11.1にアップグレードするときは、メタデータを移動する必要があります。
リリース9.2または10.1のOracle Databaseをリリース11.1にアップグレードする際、そのアップグレード操作の一部として、チェンジ・データ・キャプチャによってステージング・データベースからソース・データベースにソース・データベースのメタデータが移動されることはありません。ただし、アップグレード後に最初にチェンジ・ソースを有効化(DBMS_CDC_PUBLISH.ALTER_HOTLOG_CHANGE_SOURCE
プロシージャを使用)すると、メタデータをアップグレードしてソース・データベースに移動する必要があることがチェンジ・データ・キャプチャによって検出され、これらの操作が自動的に実行されます。
パブリッシャがアップグレードの直後にチェンジ・ソースを変更しないことを選択する場合、より適切なタイミングが訪れるまで、チェンジ・ソース・メタデータをステージング・データベース上に留めておくことができます。ただし、Oracle Databaseリリース11.1にアップグレードした後は、ソース・データベース・メタデータを無制限にステージング・データベース上に残しておかないことをお薦めします。これは、分散HotLogチェンジ・ソースに関する情報を、ソース・データベースのデータ・ディクショナリ・ビューで利用できるようにするためです。
チェンジ・データ・キャプチャの分散HotLogモードでは、ソース・データベースおよびステージング・データベースに異なるハードウェア・プラットフォームやオペレーティング・システム(またはその両方)を使用できます。
チェンジ・データ・キャプチャの分散HotLogモードのステージング・データベースにパブリッシャが複数存在し、1人のパブリッシャが別のパブリッシャの分散HotLogチェンジ・セットのチェンジ・テーブルを定義している場合、チェンジ・データ・キャプチャは、そのチェンジ・セットを作成したパブリッシャが確立したデータベース・リンクを使用して、ソース・データベースにアクセスします。したがって、チェンジ・セットを作成したパブリッシャが確立した、ソース・データベースへのデータベース・リンクは、チェンジ・テーブルを正常に作成するために失われてはならないものです。チェンジ・テーブル作成時にチェンジ・セットのパブリッシャのデータベース・リンクが存在しないと、リモート・データベースの接続が見つからなかったことを示すエラーが戻されます。
ソース・データベースからステージング・データベースへのデータベース・リンクは、分散HotLogチェンジ・ソースの存在期間中は存在している必要があります。
ステージング・データベースからソース・データベースへのデータベース・リンクは、分散HotLogのチェンジ・ソース、チェンジ・セットおよびチェンジ・テーブルの作成、変更または削除時には存在している必要があります。ただし、このデータベース・リンクは、変更のキャプチャのために必要ではありません。必要な分散HotLogのチェンジ・ソース、チェンジ・セットおよびチェンジ・テーブルを配置および有効化すると、変更のキャプチャを妨げずにこのデータベース・リンクを削除できます。データベース・リンクを削除した場合、分散HotLogのチェンジ・ソース、チェンジ・セットおよびチェンジ・テーブルを作成、変更または削除する際に再作成する必要があります。