| Oracle® Streams概要および管理 11gリリース2 (11.2) B61351-03 |
|
 前 |
 次 |
この章では、Oracle Streamsを使用して、表に対するデータ操作言語(DML)の変更を記録する方法について説明します。
この章の内容は次のとおりです。
Oracle Streamsでは、挿入、更新および削除に関する情報など、データベース表に対する変更に関する情報を記録できます。変更が記録される表はソース・テーブルと呼ばれ、記録された変更に関する情報はチェンジ・テーブルと呼ばれる別の表に格納されます。また、ソース・テーブルが存在するデータベースはソース・データベースと呼ばれ、チェンジ・テーブルが存在するデータベースは宛先データベースと呼ばれます。宛先データベースは、ソース・データベースと同じデータベースにすることも、異なるデータベースにすることもできます。
記録される情報は、DML操作によって各行で変更されたデータ、および各変更に関するメタデータを示すものです。通常、データ・ウェアハウス環境では表の変更に関する情報が記録されますが、他のタイプの環境では表の変更が追跡されることもあります。
Oracle Streamsの適用プロセスでは、表の変更をチェンジ・テーブルに記録するために、変更ハンドラを使用します。変更ハンドラは、表の変更を追跡する特別なタイプの文DMLハンドラであり、DBMS_STREAMS_ADM.MAINTAIN_CHANGE_TABLEプロシージャまたはDBMS_APPLY_ADM.SET_CHANGE_HANDLERプロシージャのいずれかによって作成されたものです。この章では、これらのプロシージャを使用して変更ハンドラを作成および管理する方法について説明します。変更ハンドラに関する情報は、ALL_APPLY_CHANGE_HANDLERSおよびDBA_APPLY_CHANGE_HANDLERSビューに格納されます。
|
注意: 変更ハンドラのプロシージャを使用しなくても、表の変更を追跡する文DMLハンドラを作成できます。このような文DMLハンドラは技術的には変更ハンドラとみなされず、その情報もALL_APPLY_CHANGE_HANDLERSおよびDBA_APPLY_CHANGE_HANDLERSビューには格納されません。 |
DBMS_STREAMS_ADMパッケージのMAINTAIN_CHANGE_TABLEプロシージャでは、ソース・テーブルに対する変更を記録するOracle Streams環境を構成できます。このプロシージャでは、必要なすべてのOracle Streamsコンポーネントを構成します。また、このプロシージャを使用すると、各変更に関して記録するメタデータを識別できます。たとえば、他の多くのタイプのメタデータと同様に、変更を行ったユーザーのユーザー名と変更時間を記録するように指定できます。
MAINTAIN_CHANGE_TABLEプロシージャを使用して、表の変更を記録するOracle Stream環境を構成する前に、いくつかの決定を行い、前提条件を満たす必要があります。
次の各項では、MAINTAIN_CHANGE_TABLEプロシージャに関する決定と前提条件について説明します。
次の各項では、MAINTAIN_CHANGE_TABLEプロシージャを実行する前に行う決定について説明します。
表の変更を記録するOracle Streams環境は、次のコンポーネントで構成されます。
取得プロセスは、ソース・テーブルに対する変更に関する情報をREDOログから取得します。取得プロセスは、行論理変更レコード(行LCR)の各行変更に関する情報をカプセル化します。変更が行われるデータベースはソース・データベースと呼ばれます。取得プロセスが実行されるデータベースは取得データベースと呼ばれます。
伝播は、ソース・テーブルとチェンジ・テーブルが異なるデータベースにある場合に、取得された行LCRをチェンジ・テーブルが存在するデータベースに送信します。ソース・テーブルとチェンジ・テーブルが同じデータベースにある場合、伝播は不要です。
適用プロセスは、情報をチェンジ・テーブルに記録します。適用プロセスは、文DMLハンドラを使用して、行LCR内の情報をチェンジ・テーブルに挿入します。
これらのコンポーネントは、次の方法で構成できます。
1つのデータベースでのローカル取得とローカル適用: ソース・テーブル、取得プロセス、適用プロセスおよびチェンジ・テーブルがすべて同じデータベースにあります。すべてのコンポーネントが1つのデータベースにあるため、構成およびメンテナンスが最も容易なオプションです。
ローカル取得とリモート適用: 1つのデータベースにソース・テーブルと取得プロセスがあり、もう1つのデータベースに適用プロセスとチェンジ・テーブルがあります。伝播によって、ソース・データベースの行LCRが宛先データベースに送信されます。このオプションは、構成およびメンテナンスの容易さが求められ、ソース・テーブルとチェンジ・テーブルが異なるデータベースに存在する必要がある場合に適しています。
ダウンストリーム取得とローカル適用: 1つのデータベースにソース・テーブルがあり、もう1つのデータベースに取得プロセス、適用プロセスおよびチェンジ・テーブルがあります。このオプションは、ソース・テーブルが存在するデータベースのパフォーマンスを最適化し、変更の取得をもう1つのデータベースで行って負荷を軽減する必要がある場合に適しています。このオプションを使用した場合、チェンジ・テーブルが存在するデータベースでほとんどのコンポーネントが実行されます。
ダウンストリーム取得とリモート適用: 1つのデータベースにソース・テーブルがあり、もう1つのデータベースに適用プロセスとチェンジ・テーブルがあり、第3のデータベースに取得プロセスがあります。このオプションは、ソース・テーブルが存在するデータベースとチェンジ・テーブルが存在するデータベースの両方のパフォーマンスを最適化する必要がある場合に適しています。このオプションを使用した場合、取得プロセスは第3のデータベースで実行され、伝播によって取得データベースから宛先データベースに行LCRが送信されます。
MAINTAIN_CHANGE_TABLEプロシージャが実行されるデータベースが常に取得データベースになります。表20-1に、各タイプの環境を構成するときのプロシージャの実行場所を示します。
表20-1 MAINTAIN_CHANGE_TABLEの構成オプション
| 環境のタイプ | MAINTAIN_CHANGE_TABLEの実行場所 |
|---|---|
|
1つのデータベースでのローカル取得とローカル適用 |
ソース・テーブルが存在するソース・データベース |
|
ローカル取得とリモート適用 |
ソース・テーブルが存在するソース・データベース |
|
ダウンストリーム取得とローカル適用 |
ソース・テーブルは存在せず、チェンジ・テーブルが存在する宛先データベース |
|
ダウンストリーム取得とリモート適用 |
ソース・テーブルもチェンジ・テーブルも存在しない第3のデータベース |
ダウンストリーム取得を構成するには、追加の要件を満たす必要があります。詳細は、「ダウンストリーム取得の操作要件」を参照してください。
ダウンストリーム取得プロセスを構成する場合は、構成するダウンストリーム取得プロセスのタイプを決定する必要があります。使用可能なタイプは次のとおりです。
リアルタイム・ダウンストリーム取得プロセス構成: この構成では、REDO転送サービスによって、ソース・データベースのログ・ライター・プロセス(LGWR)を使用して、ダウンストリーム・データベースにREDOデータが送信され、ダウンストリーム・データベースのリモート・ファイル・サーバー・プロセス(RFS)でネットワークを介してREDOデータが受信され、そのREDOデータがスタンバイREDOログに格納されます。
アーカイブ・ログ・ダウンストリーム取得プロセス構成: この構成では、ソース・データベースからのアーカイブREDOログ・ファイルがダウンストリーム・データベースにコピーされ、取得プロセスによってこれらのアーカイブREDOログ・ファイル内の変更が取得されます。これらのログ・ファイルは、REDO転送サービスを使用して自動的に転送することも、FTPなどの方法を使用して手動で転送することもできます。
アーカイブ・ログ・ダウンストリーム取得と比較すると、リアルタイム・ダウンストリーム取得には、ソース・データベースで行われた変更を短時間で取得できるというメリットがあります。リアルタイム・ダウンストリーム取得プロセスでは、REDOログ・ファイルから変更を取得する前に、REDOログ・ファイルがアーカイブされるまで待機する必要がないため、取得時間が短縮されます。同じソース・データベースから変更を取得する複数のリアルタイム・ダウンストリーム取得プロセスを構成できますが、1つのダウンストリーム・データベースで複数のソース・データベースに対してリアルタイム・ダウンストリーム取得を構成することはできません。
リアルタイム・ダウンストリーム取得と比較すると、アーカイブ・ログ・ダウンストリーム取得には、複数のソース・データベースに対するダウンストリーム取得プロセスを1つのダウンストリーム・データベースで使用できるというメリットがあります。REDOログ・ファイルを複数のソース・データベースから単一のダウンストリーム・データベースにコピーし、それらのREDOログ・ファイル内の変更を複数のアーカイブ・ログ・ダウンストリーム取得プロセスで取得するように構成できます。
MAINTAIN_CHANGE_TABLEプロシージャのcolumn_type_listパラメータでは、チェンジ・テーブル内で追跡する列を指定できます。Oracle Streams環境では、リストに指定した列の変更のみが記録されます。表のすべての列を追跡するには、このパラメータですべての列を指定します。列のサブセットを追跡するには、追跡する列を指定します。column_type_listパラメータでは、列のデータ型と有効な任意の列プロパティ(表内の制約指定など)を指定できます。
様々な理由でリストから列を省略できます。たとえば、一部の列には、チェンジ・テーブルへの移入を避けるべき給与データなどの機密情報が含まれている場合があります。また、表が数百もの列で構成されていても、追跡が必要な列はごくわずかしかない場合があります。
MAINTAIN_CHANGE_TABLEプロシージャのextra_column_listパラメータでは、チェンジ・テーブルに記録するメタデータを指定できます。このパラメータでは、次のタイプのメタデータを指定できます。
value_type
source_database_name
command_type
object_owner
object_name
tag
transaction_id
scn
commit_scn
commit_time
position
compatible
instance_number
message_number
row_text
row_id
serial#
session#
source_time
thread#
tx_name
username
チェンジ・テーブルでは、各メタデータ属性の列名にはドル記号($)が追加されます。たとえば、command_type属性のメタデータは、チェンジ・テーブルのcommand_type$列に格納されます。
value_typeおよびmessage_numberを除き、これらのメタデータ属性はすべて行LCR属性であり、行LCRに格納できます。
チェンジ・テーブルのvalue_type$列には、列値が元の列値であるか、新しい列値であるかに応じて、OLDまたはNEWのいずれかが含まれます。
チェンジ・テーブルのmessage_number$列には、トランザクション内の各行LCRの識別番号が含まれます。メッセージ番号は、トランザクション内の行LCRごとに段階的に増加し、トランザクション内の行LCRの順序を示します。
|
注意: LCRのpositionは、一般的にXStream構成で使用されます。 |
MAINTAIN_CHANGE_TABLEプロシージャのcapture_valuesパラメータでは、ソース・テーブルに対する更新操作に応じてチェンジ・テーブルに記録する値を指定できます。行に対して更新操作が実行されると、各列の古い値は更新操作前の値になり、新しい値は更新操作後の値になります。古い値または新しい値あるいはその両方を記録するように指定できます。
MAINTAIN_CHANGE_TABLEプロシージャのkeep_change_columns_onlyパラメータでは、KEEP_COLUMNS宣言ルールベースの変換を構成するかどうかを指定できます。KEEP_COLUMNS宣言ルールベースの変換では、column_type_listパラメータで指定したリストに含まれる列が行LCRに維持されます。リストに含まれない列は行LCRから削除されます。
たとえば、表が10列で構成され、そのうち3列のみをチェンジ・テーブルで追跡する必要があるとします。この場合、通常、追跡しない7列を削除する7つのDELETE_COLUMN宣言ルールベースの変換を構成するよりも、追跡する必要がある3列を維持する1つのKEEP_COLUMNS宣言ルールベースの変換を構成する方が効率的です。
keep_change_columns_onlyパラメータは、column_type_listパラメータで表の列のサブセットを指定する場合にのみ関係します。この場合、ネットワークで送信される情報量を減らしたり、行LCRから機密情報を除外するように変換を構成できます。
column_type_listパラメータで指定していない列に関する情報が宛先データベースで必要な場合は、keep_change_columns_onlyパラメータをFALSEに設定します。たとえば、execute_lcrパラメータをTRUEに設定し、構成でソース・テーブルのすべての列がレプリケートされる状況で、column_type_listパラメータでこれらの列のサブセットを指定した場合は、keep_change_columns_onlyパラメータをFALSEに設定します。
MAINTAIN_CHANGE_TABLEプロシージャのoptions_stringパラメータでは、チェンジ・テーブルを作成するCREATE TABLE文にオプションの文字列を追加できます。この文字列は、生成されたCREATE TABLE文において、表の列を定義する右カッコの後に追加されます。文字列は構文的に正確である必要があります。たとえば、特定の表領域に表を格納するTABLESPACE句を指定できます。また、チェンジ・テーブルをパーティション化することもできます。チェンジ・テーブルをパーティション化するメリットは、DELETE文で行を削除するかわりに、ALTER TABLE文のTRUNCATE PARTITION句を使用してパーティションを切り捨てることができることです。
|
関連項目: CREATE TABLEオプションの詳細は、『Oracle Database SQL言語リファレンス』を参照 |
MAINTAIN_CHANGE_TABLEプロシージャでは、Oracle Streams環境を直接構成することも、環境を構成するスクリプトを生成することもできます。プロシージャを使用して直接構成する方がスクリプトを実行するよりも簡単で、環境も即座に構成されます。ただし、次のような理由でスクリプトを生成することもできます。
環境を構成する前に、プロシージャによって実行されるアクションを確認する。
スクリプトを変更して構成をカスタマイズする。
たとえば、適用プロセスによって変更が適用される前に、適用ハンドラを使用してそれらの変更のカスタマイズ処理を行う必要がある場合があります。この場合、プロシージャを使用してスクリプトを生成し、適用ハンドラを追加するようにそのスクリプトを変更できます。
perform_actionsパラメータでは、プロシージャで環境を直接構成するかどうかを制御します。
MAINTAIN_CHANGE_TABLEプロシージャの実行時に環境を直接構成するには、perform_actionsパラメータをTRUEに設定します。このパラメータのデフォルト値はTRUEです。
MAINTAIN_CHANGE_TABLEプロシージャの実行時に構成スクリプトを生成するには、perform_actionsパラメータをFALSEに設定し、script_nameおよびscript_directory_objectパラメータを使用して構成スクリプトの名前と場所を指定します。
一部の環境では、チェンジ・テーブルに加えて、ソース・テーブルを宛先データベースにレプリケートする必要があります。この場合、ソース・テーブルとチェンジ・テーブルは異なるデータベースにあり、ソース・テーブルの追加のレプリカがチェンジ・テーブルと同じデータベースに含まれます。
たとえば、hr.employees表に対する変更を記録するOracle Streams環境を考えます。チェンジ・テーブルの名前はhr.emp_change_tableであり、ソース・テーブルとチェンジ・テーブルは異なるデータベースにあるとします。この場合、hr.employees表に対する変更を記録するOracle Streams環境には、次の表が関係します。
データベース1のhr.employees表
データベース2のhr.emp_change_table
宛先データベースの適用プロセスでは、操作のタイプ(挿入、更新および削除)ごとに別々の変更ハンドラを使用して変更が記録されます。
Oracle Streams環境でデータベース2にhr.employees表もレプリケートされる場合は、次の表が関係します。
データベース1のhr.employees表
データベース2のhr.employees表(レプリカ)
データベース2のhr.emp_change_table
表の変更を記録するのみでなく、表をレプリケートする環境では、操作のタイプ(挿入、更新および削除)ごとに別々の変更ハンドラが宛先データベースの適用プロセスに追加されます。これらの変更ハンドラでは、行LCRを実行して、レプリケートされた表に変更を適用します。
execute_lcrパラメータでは、プロシージャでソース・テーブルのレプリケーションを構成するかどうかを制御します。
ソース・テーブルをレプリケートするOracle Streams環境を構成するには、execute_lcrパラメータをTRUEに設定します。
ソース・テーブルをレプリケートしないOracle Streams環境を構成するには、execute_lcrパラメータをFALSEに設定します。このパラメータのデフォルト値はFALSEです。
|
注意: keep_change_columns_onlyパラメータをTRUEに設定し、column_listパラメータでソース・テーブルの列のサブセットを指定した場合は、execute_lcrパラメータをFALSEに設定する必要があります。変更をレプリケートするために必要な列値が行LCRに含まれていない場合は、適用エラーが発生します。 |
DBMS_STREAMS_ADMパッケージには、MAINTAIN_GLOBAL、MAINTAIN_SCHEMAS、MAINTAIN_TABLESなど、レプリケーション環境を構成するプロシージャが用意されています。MAINTAIN_CHANGE_TABLEプロシージャの使用方法はこれらの他のプロシージャの使用方法と類似しており、前提条件の多くも同じです。
次の各項では、MAINTAIN_CHANGE_TABLEプロシージャを実行する前に満たす必要がある前提条件について説明します。
これらの前提条件の多くは、『Oracle Streamsレプリケーション管理者ガイド』で詳しく説明されています。
環境内の各データベースでは、Oracle Streams管理者にOracle Streamsコンポーネントを構成および管理させる必要があります。手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
構成する予定のOracle Streams環境のタイプに応じて、ネットワーク接続性と1つ以上のデータベース・リンクが必要になる場合があります。環境に複数のデータベースが存在する場合は、環境内のデータベース間のネットワーク接続性が必要です。
各タイプのOracle Streams環境では、次のデータベース・リンクが必要です。
1つのデータベースでのローカル取得とローカル適用: データベース・リンクは不要です。
ローカル取得とリモート適用: ソース・データベースから宛先データベースへのデータベース・リンクが必要です。
ダウンストリーム取得とローカル適用: 次のデータベース・リンクが必要です。
ソース・データベースから接続先データベースへのデータベース・リンク。
宛先データベースからソース・データベースへのデータベース・リンク
ダウンストリーム取得とリモート適用: 次のデータベース・リンクが必要です。
ソース・データベースから接続先データベースへのデータベース・リンク。
ソース・データベースから取得データベースへのデータベース・リンク
取得データベースからソース・データベースへのデータベース・リンク
取得データベースから宛先データベースへのデータベース・リンク
手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
Oracle Streamsの取得プロセスではREDOログをスキャンして変更を取得するため、ソース・テーブルが存在するソース・データベースをARCHIVELOGモードにする必要があります。ダウンストリーム取得プロセスを構成する予定の場合は、取得データベースもARCHIVELOGモードにする必要があります。手順については、『Oracle Database管理者ガイド』を参照してください。
一部の初期化パラメータは、Oracle Streams環境の構成、操作、信頼性およびパフォーマンスにとって重要です。これらのパラメータをOracle Streams環境にあわせて適切に設定します。手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
Oracle Streamsプールは、Oracle Streamsで使用されるシステム・グローバル領域(SGA)にあるメモリーです。データベース・メモリーを構成して、Oracle Streamsプールに十分な空き領域を確保します。手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
ソース・データベースでローカル取得プロセスを使用するように決定した場合は、ログ・ファイルの転送は不要です。ただし、REDO転送サービスによってアーカイブREDOログ・ファイルをダウンストリーム・データベースに自動的に転送するダウンストリーム取得を使用するように決定した場合は、Oracle Streams環境を構成する前に、ソース・データベースから取得データベースへのログ・ファイルの転送を構成します。手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
リアルタイム・ダウンストリーム取得プロセスを使用するように決定した場合は、取得データベースでスタンバイREDOログを構成する必要があります。手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
MAINTAIN_CHANGE_TABLEプロシージャでスクリプトを生成し、そのスクリプトを使用してOracle Streams環境を構成するように決定した場合は、取得データベースにスクリプトを格納するディレクトリ・オブジェクトを作成します。取得データベースは、プロシージャを実行するデータベースです。スクリプトを生成しない場合、このディレクトリ・オブジェクトは不要です。
ディレクトリ・オブジェクトは、ファイル・システム上のディレクトリの別名と類似しています。各ディレクトリ・オブジェクトはSQL文CREATE DIRECTORYを使用して作成する必要があり、MAINTAIN_CHANGE_TABLEプロシージャを起動するユーザーにはそのディレクトリ・オブジェクトに対するREADおよびWRITE権限が必要です。
たとえば、次の文では、/usr/db_filesディレクトリに対応するdb_files_directoryという名前のディレクトリ・オブジェクトを作成します。
CREATE DIRECTORY db_files_directory AS '/usr/db_files';
ディレクトリ・オブジェクトを作成するユーザーには、そのディレクトリ・オブジェクトに対するREADおよびWRITE権限が自動的に割り当てられます。Oracle Streamsレプリケーション環境を構成する場合は、通常、Oracle Streams管理者がディレクトリ・オブジェクトを作成します。
ソース・テーブルをレプリケートするように決定した場合は、宛先データベースでソース・テーブルをインスタンス化します。ソース・テーブルをレプリケートしないように決定した場合、インスタンス化は不要です。
ソース・テーブルをレプリケートするように決定したためにインスタンス化が必要な場合は、MAINTAIN_CHANGE_TABLEプロシージャを実行する前に、次の手順を実行します。
ソース・テーブルをインスタンス化のために準備します。
ソース・テーブルとレプリカ・テーブルに一貫性があることを確認します。
宛先データベースでレプリカ・テーブルのインスタンス化SCNを設定します。
この項では、表の変更を記録するOracle Streams環境を構成する方法について例を挙げて説明します。具体的には、表の変更を記録する4つのタイプのOracle Streams環境について説明します。
この項では、次の例を示します。
この例では、1つのデータベースでのローカル取得とローカル適用を使用して表に対する変更を記録する方法について説明します。具体的には、この例では、hr.jobs表に対する変更を記録します。
次の表に、この例で構成されるOracle Streams環境に関する事前の決定を示します。
| 決定 | この例での前提 |
|---|---|
| 構成する環境のタイプの決定 |
この例では、1つのデータベースでのローカル取得とローカル適用を構成します。 |
| 追跡する列の決定 |
この例では、hr.jobs表のすべての列を追跡します。 |
| 記録するメタデータの決定 |
この例では、command_type、value_type (OLDまたはNEW)およびcommit_scnメタデータを記録します。 |
| 更新操作に応じて追跡する値の決定 |
この例では、ソース・テーブルに対して更新操作が実行されたときに、古い列値と新しい列値の両方を追跡します。 |
| KEEP_COLUMNS変換を構成するかどうかの決定 |
この例では、KEEP_COLUMNS宣言ルールベースの変換を構成しません。 |
| チェンジ・テーブルに対してCREATE TABLEオプションを指定するかどうかの決定 |
この例では、どのCREATE TABLEオプションも指定しません。チェンジ・テーブルは、デフォルトのCREATE TABLEオプションを使用して作成されます。 |
| 構成アクションを直接実行するか、スクリプトで実行するかの決定 |
この例では、構成アクションを直接実行します。スクリプトは使用しません。 |
| ソース・テーブルをレプリケートするかどうかの決定 |
この例では、ソース・テーブルをレプリケートしません。 |
図20-1に、この例で作成されるOracle Stream環境の概要を示します。
1つのデータベースでのローカル取得とローカル適用を使用して表に対する変更を記録するOracle Streams環境を構成するには、次の手順を実行します。
MAINTAIN_CHANGE_TABLEプロシージャを実行するために必要な前提条件を満たします。手順については、「MAINTAIN_CHANGE_TABLEプロシージャに関する前提条件」を参照してください。
この構成では、次のタスクを完了する必要があります。
データベースでOracle Streams管理者を構成します。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。
データベースがARCHIVELOGモードであることを確認します。「ソース・データベースがARCHIVELOGモードであることの確認」を参照してください。
データベースで初期化パラメータが適切に設定されていることを確認します。「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。
データベースでOracle Streamsプールを適切に構成します。「Oracle Streamsプールの構成」を参照してください。
データベースにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。
MAINTAIN_CHANGE_TABLEプロシージャを実行します。
BEGIN
DBMS_STREAMS_ADM.MAINTAIN_CHANGE_TABLE(
change_table_name => 'hr.jobs_change_table',
source_table_name => 'hr.jobs',
column_type_list => 'job_id VARCHAR2(10),
job_title VARCHAR2(35),
min_salary NUMBER(6),
max_salary NUMBER(6)',
extra_column_list => 'command_type,value_type,commit_scn',
capture_values => '*',
keep_change_columns_only => FALSE);
END;
/
このプロシージャでは、指定のない各パラメータにはデフォルト値が使用されます。hr.jobs表のすべての列がcolumn_type_listパラメータで指定されているため、keep_change_columns_onlyパラメータはFALSEに設定されています。
このプロシージャが完了したら、Oracle Streams環境が構成されます。
このプロシージャがエラーによって停止した場合は、エラーからのリカバリ方法またはDBMS_STREAMS_ADM.RECOVER_OPERATIONプロシージャを使用して構成操作をロールバックする方法について、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
構成されたOracle Streams環境は次の特性を持ちます。
無条件のサプリメンタル・ログ・グループには、hr.jobs表のすべての列が含まれます。
データベースにはhr.jobs_change_tableが存在します。このチェンジ・テーブルの定義は次のとおりです。
Name Null? Type ----------------------------------------- -------- --------------------------- COMMAND_TYPE$ VARCHAR2(10) VALUE_TYPE$ VARCHAR2(3) COMMIT_SCN$ NUMBER JOB_ID VARCHAR2(10) JOB_TITLE VARCHAR2(35) MIN_SALARY NUMBER(6) MAX_SALARY NUMBER(6)
データベースには、システム生成名を持つキューがあります。このキューは、取得プロセスおよび適用プロセスで使用されます。
システム生成名を持つ取得プロセスでは、hr.jobs表に対するデータ操作言語(DML)の変更を取得します。
システム生成名を持つ適用プロセスが使用されます。この適用プロセスでは、システム生成名を持つ変更ハンドラを使用して、hr.jobs表に対する挿入、更新および削除に関して取得された行LCRを処理します。変更ハンドラでは、行LCR内の情報を使用して、hr.jobs_change_tableへの移入を行います。
この例では、ローカル取得とリモート適用を使用して表に対する変更を記録する方法について説明します。この例で構成されるOracle Stream環境では、表に対する変更を記録するのみでなく、変更をレプリケートします。
具体的には、この例では、hr.departments表の列のサブセットに対する変更を記録します。また、hr.departments表のすべての列に対するデータ操作言語(DML)の変更をレプリケートします。この例で構成されるOracle Streams環境では、ソース・データベースct1.example.comに対する変更を取得し、その変更を宛先データベースct2.example.comに送信します。ct2.example.comの適用プロセスでは、チェンジ・テーブルに変更を記録し、その変更をレプリカのhr.departments表に適用します。
次の表に、この例で構成されるOracle Streams環境に関する事前の決定を示します。
| 決定 | この例での前提 |
|---|---|
| 構成する環境のタイプの決定 |
この例では、2つのデータベースを使用するローカル取得とリモート適用を構成します。ソース・データベースはct1.example.comであり、宛先データベースはct2.example.comです。取得プロセスは、ct1.example.comのローカル取得プロセスになります。 |
| 追跡する列の決定 |
この例では、hr.departments表のdepartment_idおよびmanager_id列を追跡します。 |
| 記録するメタデータの決定 |
この例では、command_typeおよびvalue_type (OLDまたはNEW)メタデータを記録します。extra_column_listパラメータがMAINTAIN_CHANGE_TABLEで指定されていない場合、このメタデータはデフォルトで記録されます。 |
| 更新操作に応じて追跡する値の決定 |
この例では、ソース・テーブルに対して更新操作が実行されたときに、古い列値と新しい列値の両方を追跡します。 |
| KEEP_COLUMNS変換を構成するかどうかの決定 |
この例では、表のすべての列がレプリケートされるため、KEEP_COLUMNS宣言ルールベースの変換を構成しません。 |
| チェンジ・テーブルに対してCREATE TABLEオプションを指定するかどうかの決定 |
この例では、どのCREATE TABLEオプションも指定しません。チェンジ・テーブルは、デフォルトのCREATE TABLEオプションを使用して作成されます。 |
| 構成アクションを直接実行するか、スクリプトで実行するかの決定 |
この例では、構成アクションを直接実行します。スクリプトは使用しません。 |
| ソース・テーブルをレプリケートするかどうかの決定 |
この例では、宛先データベースにソース・テーブルをレプリケートします。したがって、ソース・データベースと宛先データベースの両方にhr.departments表が存在します。MAINTAIN_CHANGE_TABLEプロシージャでは、ソース・データベースから宛先データベースへのこの表の単方向レプリケーション環境を構成します。 |
図20-2に、この例で作成されるOracle Stream環境の概要を示します。
ローカル取得とリモート適用を使用して表に対する変更を記録およびレプリケートするOracle Streams環境を構成するには、次の手順を実行します。
MAINTAIN_CHANGE_TABLEプロシージャを実行するために必要な前提条件を満たします。手順については、「MAINTAIN_CHANGE_TABLEプロシージャに関する前提条件」を参照してください。
この構成では、次のタスクを完了する必要があります。
両方のデータベースでOracle Streams管理者を構成します。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。
ネットワーク接続性とデータベース・リンクを構成します。
ソース・データベースct1.example.comと宛先データベースct2.example.comの間のネットワーク接続性を構成します。
ソース・データベースct1.example.comから宛先データベースct2.example.comへのデータベース・リンクを作成します。
手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
ソース・データベースがARCHIVELOGモードであることを確認します。この例では、ソース・データベースはct1.example.comです。「ソース・データベースがARCHIVELOGモードであることの確認」を参照してください。
すべてのデータベースで初期化パラメータが適切に設定されていることを確認します。「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。
すべてのデータベースでOracle Streamsプールを適切に構成します。「Oracle Streamsプールの構成」を参照してください。
この例ではソース・テーブルhr.departmentsをレプリケートするため、宛先データベースでソース・テーブルをインスタンス化します。「宛先データベースでのソース・テーブルのインスタンス化」を参照してください。
ソース・データベースct1.example.comにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。
MAINTAIN_CHANGE_TABLEプロシージャを実行します。
BEGIN
DBMS_STREAMS_ADM.MAINTAIN_CHANGE_TABLE(
change_table_name => 'hr.dep_change_table',
source_table_name => 'hr.departments',
column_type_list => 'department_id NUMBER(4),
manager_id NUMBER(6)',
capture_values => '*',
source_database => 'ct1.example.com',
destination_database => 'ct2.example.com',
keep_change_columns_only => FALSE,
execute_lcr => TRUE);
END;
/
このプロシージャでは、指定のない各パラメータにはデフォルト値が使用されます。execute_lcrパラメータがTRUEに設定されているため、keep_change_columns_onlyパラメータはFALSEに設定されています。すべての列が宛先データベースにレプリケートされるため、行論理変更レコード(LCR)には表のすべての列の変更に関する情報が含まれている必要があります。execute_lcrパラメータがTRUEに設定されていて、column_type_listパラメータでレプリケート対象のすべての列が指定されている場合(この例は該当しません)、keep_change_columns_onlyパラメータはTRUEにしか設定できません。
このプロシージャが完了したら、Oracle Streams環境が構成されます。
このプロシージャがエラーによって停止した場合は、エラーからのリカバリ方法またはDBMS_STREAMS_ADM.RECOVER_OPERATIONプロシージャを使用して構成操作をロールバックする方法について、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
構成されたOracle Streams環境は次の特性を持ちます。
無条件のサプリメンタル・ログ・グループには、ソース・データベースct1.example.comで変更が記録されるhr.departments表の列が含まれます。これらの列は、MAINTAIN_CHANGE_TABLEプロシージャのcolumn_type_listパラメータで指定されたものです。
宛先データベースct2.example.comにはhr.dep_change_tableが存在します。このチェンジ・テーブルの定義は次のとおりです。
Name Null? Type ----------------------------------------- -------- --------------------------- COMMAND_TYPE$ VARCHAR2(10) VALUE_TYPE$ VARCHAR2(3) DEPARTMENT_ID NUMBER(4) MANAGER_ID NUMBER(6)
ソース・データベースct1.example.comには、システム生成名を持つキューがあります。このキューは、取得プロセスで使用されます。
宛先データベースct2.example.comには、システム生成名を持つキューがあります。このキューは、適用プロセスで使用されます。
ソース・データベースct1.example.comでは、システム生成名を持つローカル取得プロセスを使用して、hr.departments表に対するデータ操作言語(DML)の変更を取得します。
宛先データベースct2.example.comでは、システム生成名を持つ適用プロセスが使用されます。この適用プロセスでは、システム生成名を持つ変更ハンドラを使用して、hr.departments表に対する挿入、更新および削除に関して取得された行LCRを処理します。変更ハンドラでは、行LCR内の情報を使用して、hr.dep_change_tableへの移入を行います。
また、適用プロセスでは、操作のタイプ(挿入、更新および削除)ごとに、システム生成名を持つ変更ハンドラを使用して行LCRを実行します。これにより、ソース・テーブルに対する変更が宛先データベースにあるレプリカのhr.departments表に適用されます。
ct1.example.comデータベースでは、システム生成名を持つ伝播が実行されます。この伝播によって、ct1.example.comデータベースから取得された変更がct2.example.comデータベースに送信されます。
この例では、ダウンストリーム取得とローカル適用を使用して表に対する変更を記録する方法について説明します。具体的には、この例では、ソース・データベースと宛先データベースを使用して、hr.locations表に対する変更を記録します。宛先データベースは、ダウンストリーム取得プロセス用の取得データベースにもなります。
次の表に、この例で構成されるOracle Streams環境に関する事前の決定を示します。
| 決定 | この例での前提 |
|---|---|
| 構成する環境のタイプの決定 |
この例では、ソース・データベースct1.example.comと宛先データベースct2.example.comを使用するダウンストリーム取得とローカル適用を構成します。取得プロセスは、ct2.example.comで実行されるリアルタイム・ダウンストリーム取得プロセスになります。 |
| 追跡する列の決定 |
この例では、hr.locations表のすべての列を追跡します。 |
| 記録するメタデータの決定 |
この例では、command_type、value_type (OLDまたはNEW)、object_owner、object_nameおよびusernameメタデータを記録します。 |
| 更新操作に応じて追跡する値の決定 |
この例では、ソース・テーブルに対して更新操作が実行されたときに、古い列値と新しい列値の両方を追跡します。 |
| KEEP_COLUMNS変換を構成するかどうかの決定 |
この例では、KEEP_COLUMNS宣言ルールベースの変換を構成しません。 |
| チェンジ・テーブルに対してCREATE TABLEオプションを指定するかどうかの決定 |
この例では、どのCREATE TABLEオプションも指定しません。チェンジ・テーブルは、デフォルトのCREATE TABLEオプションを使用して作成されます。 |
| 構成アクションを直接実行するか、スクリプトで実行するかの決定 |
この例では、構成アクションを直接実行します。スクリプトは使用しません。 |
| ソース・テーブルをレプリケートするかどうかの決定 |
この例では、ソース・テーブルをレプリケートしません。 |
図20-3に、この例で作成されるOracle Stream環境の概要を示します。
ダウンストリーム取得とリモート適用を使用して表に対する変更を記録するOracle Streams環境を構成するには、次の手順を実行します。
MAINTAIN_CHANGE_TABLEプロシージャを実行するために必要な前提条件を満たします。手順については、「MAINTAIN_CHANGE_TABLEプロシージャに関する前提条件」を参照してください。
この構成では、次のタスクを完了する必要があります。
両方のデータベースでOracle Streams管理者を構成します。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。
ネットワーク接続性とデータベース・リンクを構成します。
ソース・データベースct1.example.comと宛先データベースct2.example.comの間のネットワーク接続性を構成します。
ダウンストリーム取得は宛先データベースで構成されるため、ソース・データベースct1.example.comから宛先データベースct2.example.comへのデータベース・リンクを作成します。このデータベース・リンクは、ct1.example.comからct2.example.comにREDOログ・データを送信するために使用されます。
ダウンストリーム取得は宛先データベースで構成されるため、宛先データベースct2.example.comからソース・データベースct1.example.comへのデータベース・リンクを作成します。このデータベース・リンクは、ソース・データベースでダウンストリーム取得に関連する管理タスクを実行するために使用されます。
手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
ソース・データベースと宛先データベースがARCHIVELOGモードであることを確認します。この例では、ソース・データベースはct1.example.comであり、宛先データベースはct2.example.comです。「ソース・データベースがARCHIVELOGモードであることの確認」を参照してください。
両方のデータベースで初期化パラメータが適切に設定されていることを確認します。「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。
両方のデータベースでOracle Streamsプールを適切に構成します。「Oracle Streamsプールの構成」を参照してください。
宛先データベースがソース・データベースに対する変更の取得データベースになるため、ソース・データベースct1.example.comから取得データベースct2.example.comにコピーするログ・ファイルを構成します。「ダウンストリーム取得データベースへのログ・ファイルの転送の構成」を参照してください。
この例ではリアルタイム・ダウンストリーム取得プロセスを構成するため、取得データベースにスタンバイREDOログを追加し、取得データベースct2.example.comでスタンバイREDOログを構成します。「リアルタイム・ダウンストリーム取得に対するスタンバイREDOログの構成」を参照してください。
宛先データベースct2.example.comにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。
MAINTAIN_CHANGE_TABLEプロシージャを実行します。
BEGIN
DBMS_STREAMS_ADM.MAINTAIN_CHANGE_TABLE(
change_table_name => 'hr.loc_change_table',
source_table_name => 'hr.locations',
column_type_list => 'location_id NUMBER(4),
street_address VARCHAR2(40),
postal_code VARCHAR2(12),
city VARCHAR2(30),
state_province VARCHAR2(25),
country_id CHAR(2)',
extra_column_list => 'command_type,value_type,object_owner,
object_name,username',
capture_values => '*',
source_database => 'ct1.example.com',
destination_database => 'ct2.example.com',
keep_change_columns_only => FALSE);
END;
/
このプロシージャでは、指定のない各パラメータにはデフォルト値が使用されます。hr.locations表のすべての列がcolumn_type_listパラメータで指定されているため、keep_change_columns_onlyパラメータはFALSEに設定されています。
このプロシージャが完了したら、Oracle Streams環境が構成されます。
このプロシージャがエラーによって停止した場合は、エラーからのリカバリ方法またはDBMS_STREAMS_ADM.RECOVER_OPERATIONプロシージャを使用して構成操作をロールバックする方法について、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
downstream_real_time_mine取得プロセス・パラメータをYに設定します。
DBA_CAPTUREビューのCAPTURE_NAME列を問い合せて、取得プロセスの名前を調べます。
DBMS_CAPTURE_ADMパッケージのSET_PARAMETERプロシージャを実行して、downstream_real_time_mine取得プロセス・パラメータをYに設定します。
たとえば、取得プロセス名がcap$chg5である場合、次のプロシージャを実行します。
BEGIN
DBMS_CAPTURE_ADM.SET_PARAMETER(
capture_name => 'cap$chg5',
parameter => 'downstream_real_time_mine',
value => 'Y');
END;
/
ログ・ファイルを切り替えるために必要な権限を持つ管理ユーザーとして、ソース・データベースct1.example.comに接続します。
現行のログ・ファイルがソース・データベースにアーカイブされます。
ALTER SYSTEM ARCHIVE LOG CURRENT;
現行のログ・ファイルがソース・データベースにアーカイブされると、ソース・データベースのREDOログのリアルタイム・マイニングが開始されます。
構成されたOracle Streams環境は次の特性を持ちます。
ソース・データベースct1.example.comの無条件のサプリメンタル・ログ・グループには、hr.locations表のすべての列が含まれます。
extra_column_listパラメータでusernameが指定されているため、変更を行ったユーザーのユーザー名に関する追加情報がREDOログに記録されるように、ソース・データベースが構成されます。この情報は、取得プロセスで取得され、チェンジ・テーブルに記録されます。extra_column_listパラメータで指定された他の値(command_type、value_type、object_ownerおよびobject_name)は常にREDOログで追跡されます。したがって、この情報を取得するのに追加の構成は不要です。
宛先データベースct2.example.comにはhr.loc_change_tableが存在します。このチェンジ・テーブルの定義は次のとおりです。
Name Null? Type ----------------------------------------- -------- --------------------------- COMMAND_TYPE$ VARCHAR2(10) VALUE_TYPE$ VARCHAR2(3) OBJECT_OWNER$ VARCHAR2(30) OBJECT_NAME$ VARCHAR2(30) USERNAME$ VARCHAR2(30) LOCATION_ID NUMBER(4) STREET_ADDRESS VARCHAR2(40) POSTAL_CODE VARCHAR2(12) CITY VARCHAR2(30) STATE_PROVINCE VARCHAR2(25) COUNTRY_ID CHAR(2)
宛先データベースct2.example.comには、システム生成名を持つキューがあります。このキューは、ダウンストリーム取得プロセスおよび適用プロセスで使用されます。
宛先データベースct2.example.comでは、システム生成名を持つリアルタイム・ダウンストリーム取得プロセスを使用して、hr.locations表に対するデータ操作言語(DML)の変更を取得します。
宛先データベースct2.example.comでは、システム生成名を持つ適用プロセスが使用されます。この適用プロセスでは、システム生成名を持つ変更ハンドラを使用して、hr.locations表に対する挿入、更新および削除に関して取得された行LCRを処理します。変更ハンドラでは、行LCR内の情報を使用して、hr.loc_change_tableへの移入を行います。
この例では、ダウンストリーム取得とリモート適用を使用して表に対する変更を記録する方法について説明します。具体的には、この例では、ソース・データベース、宛先データベースおよび取得データベースの3つのデータベースを使用して、hr.employees表に対する変更を記録します。
次の表に、この例で構成されるOracle Streams環境に関する事前の決定を示します。
| 決定 | この例での前提 |
|---|---|
| 構成する環境のタイプの決定 |
この例では、3つのデータベースを使用するダウンストリーム取得とリモート適用を構成します。ソース・データベースはct1.example.comであり、宛先データベースはct2.example.comであり、取得データベースはct3.example.comです。取得プロセスは、リアルタイム・ダウンストリーム取得プロセスになります。 |
| 追跡する列の決定 |
この例では、hr.employees表のsalaryおよびcommission_pct以外の列を追跡します。 |
| 記録するメタデータの決定 |
この例では、command_type、value_type (OLDまたはNEW)、object_owner、object_nameおよびusernameメタデータを記録します。 |
| 更新操作に応じて追跡する値の決定 |
この例では、ソース・テーブルに対して更新操作が実行されたときに、古い列値と新しい列値の両方を追跡します。 |
| KEEP_COLUMNS変換を構成するかどうかの決定 |
この例では、従業員の給与と歩合に関する情報を行LCRに含めないように、KEEP_COLUMNS宣言ルールベースの変換を構成します。 |
| チェンジ・テーブルに対してCREATE TABLEオプションを指定するかどうかの決定 |
この例では、CREATE TABLEオプションでSTORAGE句を指定します。 |
| 構成アクションを直接実行するか、スクリプトで実行するかの決定 |
この例では、構成アクションを直接実行します。スクリプトは使用しません。 |
| ソース・テーブルをレプリケートするかどうかの決定 |
この例では、ソース・テーブルをレプリケートしません。 |
図20-4に、この例で作成されるOracle Stream環境の概要を示します。
ダウンストリーム取得とリモート適用を使用して表に対する変更を記録するOracle Streams環境を構成するには、次の手順を実行します。
MAINTAIN_CHANGE_TABLEプロシージャを実行するために必要な前提条件を満たします。手順については、「MAINTAIN_CHANGE_TABLEプロシージャに関する前提条件」を参照してください。
この構成では、次のタスクを完了する必要があります。
3つすべてのデータベースでOracle Streams管理者を構成します。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。
ネットワーク接続性とデータベース・リンクを構成します。
ソース・データベースct1.example.comと宛先データベースct2.example.comの間のネットワーク接続性を構成します。
ソース・データベースct1.example.comと第3のデータベースct3.example.comの間のネットワーク接続性を構成します。
宛先データベースct2.example.comと第3のデータベースct3.example.comの間のネットワーク接続性を構成します。
ソース・データベースct1.example.comから宛先データベースct2.example.comへのデータベース・リンクを作成します。
ダウンストリーム取得は第3のデータベースで構成されるため、ソース・データベースct1.example.comから第3のデータベースct3.example.comへのデータベース・リンクを作成します。
ダウンストリーム取得は第3のデータベースで構成されるため、第3のデータベースct3.example.comからソース・データベースct1.example.comへのデータベース・リンクを作成します。
ダウンストリーム取得は第3のデータベースで構成されるため、第3のデータベースct3.example.comから宛先データベースct2.example.comへのデータベース・リンクを作成します。
手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
ソース・データベースと取得データベースがARCHIVELOGモードであることを確認します。この例では、ソース・データベースはct1.example.comであり、取得データベースはct3.example.comです。「ソース・データベースがARCHIVELOGモードであることの確認」を参照してください。
すべてのデータベースで初期化パラメータが適切に設定されていることを確認します。「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。
すべてのデータベースでOracle Streamsプールを適切に構成します。「Oracle Streamsプールの構成」を参照してください。
第3のデータベース(ct3.example.com)がソース・データベースに対する変更の取得データベースになるため、ソース・データベースct1.example.comから取得データベースct3.example.comにコピーするログ・ファイルを構成します。「ダウンストリーム取得データベースへのログ・ファイルの転送の構成」を参照してください。
この例ではリアルタイム・ダウンストリーム取得プロセスを構成するため、取得データベースにスタンバイREDOログを追加し、取得データベースct3.example.comでスタンバイREDOログを構成します。「リアルタイム・ダウンストリーム取得に対するスタンバイREDOログの構成」を参照してください。
取得データベースct3.example.comにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。
MAINTAIN_CHANGE_TABLEプロシージャを実行します。
BEGIN
DBMS_STREAMS_ADM.MAINTAIN_CHANGE_TABLE(
change_table_name => 'hr.emp_change_table',
source_table_name => 'hr.employees',
column_type_list => 'employee_id VARCHAR2(6),
first_name VARCHAR2(20),
last_name VARCHAR2(25),
email VARCHAR2(25),
phone_number VARCHAR2(20),
hire_date DATE,
job_id VARCHAR2(10),
manager_id NUMBER(6),
department_id NUMBER(4)',
capture_values => '*',
options_string => 'STORAGE (INITIAL 6144
NEXT 6144
MINEXTENTS 1
MAXEXTENTS 5)',
source_database => 'ct1.example.com',
destination_database => 'ct2.example.com',
keep_change_columns_only => TRUE);
END;
/
このプロシージャでは、指定のない各パラメータにはデフォルト値が使用されます。options_stringパラメータでは、チェンジ・テーブルに対するSTORAGE句を指定しています。keep_change_columns_onlyパラメータはTRUEに設定されているため、取得された行論理変更レコード(LCR)にsalaryおよびcommission_pct列以外の列を保持する宣言ルールベースの変換が作成されます。salaryおよびcommission_pct列はcolumn_type_listパラメータで指定されていないため、これらの列は除外されます。
このプロシージャが完了したら、Oracle Streams環境が構成されます。
このプロシージャがエラーによって停止した場合は、エラーからのリカバリ方法またはDBMS_STREAMS_ADM.RECOVER_OPERATIONプロシージャを使用して構成操作をロールバックする方法について、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
downstream_real_time_mine取得プロセス・パラメータをYに設定します。
DBA_CAPTUREビューのCAPTURE_NAME列を問い合せて、取得プロセスの名前を調べます。
DBMS_CAPTURE_ADMパッケージのSET_PARAMETERプロシージャを実行して、downstream_real_time_mine取得プロセス・パラメータをYに設定します。
たとえば、取得プロセス名がcap$chg5である場合、次のプロシージャを実行します。
BEGIN
DBMS_CAPTURE_ADM.SET_PARAMETER(
capture_name => 'cap$chg5',
parameter => 'downstream_real_time_mine',
value => 'Y');
END;
/
ログ・ファイルを切り替えるために必要な権限を持つ管理ユーザーとして、ソース・データベースct1.example.comに接続します。
現行のログ・ファイルがソース・データベースにアーカイブされます。
ALTER SYSTEM ARCHIVE LOG CURRENT;
現行のログ・ファイルがソース・データベースにアーカイブされると、ソース・データベースのREDOログのリアルタイム・マイニングが開始されます。
構成されたOracle Streams環境は次の特性を持ちます。
無条件のサプリメンタル・ログ・グループには、ソース・データベースct1.example.comで変更が記録されるhr.employees表の列が含まれます。これらの列は、MAINTAIN_CHANGE_TABLEプロシージャのcolumn_type_listパラメータで指定されたものです。
宛先データベースct2.example.comにはhr.emp_change_tableが存在します。このチェンジ・テーブルの定義は次のとおりです。
Name Null? Type ----------------------------------------- -------- --------------------------- COMMAND_TYPE$ VARCHAR2(10) VALUE_TYPE$ VARCHAR2(3) EMPLOYEE_ID NOT NULL NUMBER(6) FIRST_NAME VARCHAR2(20) LAST_NAME NOT NULL VARCHAR2(25) EMAIL NOT NULL VARCHAR2(25) PHONE_NUMBER VARCHAR2(20) HIRE_DATE NOT NULL DATE JOB_ID NOT NULL VARCHAR2(10) MANAGER_ID NUMBER(6) DEPARTMENT_ID NUMBER(4)
取得データベースct3.example.comには、システム生成名を持つキューがあります。このキューは、ダウンストリーム取得プロセスで使用されます。
宛先データベースct2.example.comには、システム生成名を持つキューがあります。このキューは、適用プロセスで使用されます。
取得データベースct3.example.comでは、システム生成名を持つリアルタイム・ダウンストリーム取得プロセスを使用して、hr.employees表に対するデータ操作言語(DML)の変更を取得します。
取得データベースct3.example.comでは、hr.employees表の行LCRにsalaryおよびcommission_pct列以外のすべての列を保持するKEEP_COLUMNS宣言ルールベースの変換が使用されます。
ct3.example.comデータベースでは、システム生成名を持つ伝播が実行されます。この伝播によって、ct3.example.comデータベースから取得された変更がct2.example.comデータベースに送信されます。
宛先データベースct2.example.comでは、システム生成名を持つ適用プロセスが使用されます。この適用プロセスでは、システム生成名を持つ変更ハンドラを使用して、hr.employees表に対する挿入、更新および削除に関して取得された行LCRを処理します。変更ハンドラでは、行LCR内の情報を使用して、hr.emp_change_tableへの移入を行います。
この項では、変更ハンドラの設定および設定解除について説明します。
この項の内容は次のとおりです。
DBMS_APPLY_ADMパッケージのSET_CHANGE_HANDLERプロシージャでは、単一の適用プロセスの対象として指定された表に対する特定の操作用の変更ハンドラを設定解除および設定できます。このプロシージャでは、指定された表に対する変更を取得し、その変更を指定された適用プロセスに送信するようにOracle Streamsコンポーネントが構成されていると想定されます。
この項の例では、「ローカル取得とリモート適用を使用した表の変更の記録およびレプリケーション」で作成された更新操作用の変更ハンドラを設定解除するものとします。次に、この変更ハンドラを再設定します。
変更ハンドラを設定するには、次の手順を実行します。
適用プロセスが使用されるデータベースにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。
この例では、hr.departments表に対するUPDATE操作用の変更ハンドラを設定解除します。これらの変更はapp$chg38適用プロセスによって適用されると想定します。次の問合せを実行して、チェンジ・テーブルの所有者、チェンジ・テーブルの名前、チェンジ・テーブルで追跡される取得値および変更ハンドラの名前を調べます。
COLUMN CHANGE_TABLE_OWNER HEADING 'Change Table Owner' FORMAT A20
COLUMN CHANGE_TABLE_NAME HEADING 'Change Table Name' FORMAT A20
COLUMN CAPTURE_VALUES HEADING 'Capture|Values' FORMAT A7
COLUMN HANDLER_NAME HEADING 'Change Handler Name' FORMAT A25
SELECT CHANGE_TABLE_OWNER,
CHANGE_TABLE_NAME,
CAPTURE_VALUES,
HANDLER_NAME
FROM DBA_APPLY_CHANGE_HANDLERS
WHERE SOURCE_TABLE_OWNER = 'HR' AND
SOURCE_TABLE_NAME = 'DEPARTMENTS' AND
APPLY_NAME = 'APP$CHG38' AND
OPERATION_NAME = 'UPDATE';
出力は次のようになります。
Capture
Change Table Owner Change Table Name Values Change Handler Name
-------------------- -------------------- ------- -------------------------
HR DEP_CHANGE_TABLE * HR_DEPARTMENTS_CHG$10
この問合せで返される値を書き留めて、この例の後続の手順で使用してください。
変更ハンドラを設定解除します。
変更ハンドラを設定解除するには、SET_CHANGE_HANDLERプロシージャのchange_handler_nameパラメータにNULLを指定し、他のプロシージャ・パラメータを使用してチェンジ・テーブルの所有者、チェンジ・テーブルの名前、取得値、操作、ソース・テーブルおよび適用プロセスを指定します。次に例を示します。
BEGIN
DBMS_APPLY_ADM.SET_CHANGE_HANDLER(
change_table_name => 'hr.dep_change_table',
source_table_name => 'hr.departments',
capture_values => '*',
apply_name => 'app$chg38',
operation_name => 'UPDATE',
change_handler_name => NULL);
END;
/
この変更ハンドラが設定解除されると、今後更新の変更が記録されなくなります。
変更ハンドラを設定します。
変更ハンドラを設定するには、SET_CHANGE_HANDLERプロシージャのchange_handler_nameパラメータに変更ハンドラを指定し、他のプロシージャ・パラメータを使用してチェンジ・テーブルの所有者、チェンジ・テーブルの名前、取得値、操作、ソース・テーブルおよび適用プロセスを指定します。次に例を示します。
BEGIN
DBMS_APPLY_ADM.SET_CHANGE_HANDLER(
change_table_name => 'hr.dep_change_table',
source_table_name => 'hr.departments',
capture_values => '*',
apply_name => 'app$chg38',
operation_name => 'UPDATE',
change_handler_name => 'hr_departments_chg$10');
END;
/
この変更ハンドラが再設定されると、更新の変更が記録されるようになります。
表に対する変更を記録するように既存のOracle Streamsコンポーネントを構成できます。これらの既存のコンポーネントには、取得プロセス、伝播および適用プロセスがあります。既存のコンポーネントを使用するには、DBMS_STREAMS_ADMパッケージのMAINTAIN_CHANGE_TABLEプロシージャを実行するときにコンポーネント名を指定します。
この項の例は、「1つのデータベースでのローカル取得とローカル適用を使用した表の変更の記録」で作成されたOracle Streams環境に基づきます。その例では、hr.jobs表に対する変更を記録するOracle Streams環境を構成しました。この項の例では、hr.employees表に対する変更も記録するように、既存の取得プロセスと適用プロセスを構成します。
次の表に、hr.employees表で記録される変更に関する事前の決定を示します。
| 決定 | この例での前提 |
|---|---|
| 構成する環境のタイプの決定 |
この例では、1つのデータベースでローカル取得とローカル適用を実行する既存のOracle Streamsコンポーネントを使用します。 |
| 追跡する列の決定 |
この例では、hr.employees表のすべての列を追跡します。 |
| 記録するメタデータの決定 |
この例では、command_type、value_type (OLDまたはNEW)およびcommit_scnメタデータを記録します。 |
| 更新操作に応じて追跡する値の決定 |
この例では、ソース・テーブルに対して更新操作が実行されたときに、古い列値と新しい列値の両方を追跡します。 |
| KEEP_COLUMNS変換を構成するかどうかの決定 |
この例では、KEEP_COLUMNS宣言ルールベースの変換を構成しません。 |
| チェンジ・テーブルに対してCREATE TABLEオプションを指定するかどうかの決定 |
この例では、どのCREATE TABLEオプションも指定しません。チェンジ・テーブルは、デフォルトのCREATE TABLEオプションを使用して作成されます。 |
| 構成アクションを直接実行するか、スクリプトで実行するかの決定 |
この例では、構成アクションを直接実行します。スクリプトは使用しません。 |
| ソース・テーブルをレプリケートするかどうかの決定 |
この例では、ソース・テーブルをレプリケートしません。 |
既存のOracle Streamsコンポーネントを使用して表に対する変更を記録するには、次の手順を実行します。
MAINTAIN_CHANGE_TABLEプロシージャを実行するために必要な前提条件を満たしていることを確認します。手順については、「MAINTAIN_CHANGE_TABLEプロシージャに関する前提条件」を参照してください。
この構成では、次のタスクを完了する必要があります。
データベースでOracle Streams管理者を構成します。「すべてのデータベースでのOracle Streams管理者の構成」を参照してください。
データベースがARCHIVELOGモードであることを確認します。「ソース・データベースがARCHIVELOGモードであることの確認」を参照してください。
データベースで初期化パラメータが適切に設定されていることを確認します。「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。
データベースでOracle Streamsプールを適切に構成します。「Oracle Streamsプールの構成」を参照してください。
この例では、これらの前提条件はすでに満たされているはずです。既存のOracle Streams環境では、hr.jobs表に対する変更が記録されているためです。
既存のOracle Streamsコンポーネントの名前を調べます。
SQL*Plusで、コンポーネントが存在するデータベースに接続し、該当するデータ・ディクショナリ・ビューを問い合せます。
データベースの取得プロセスの名前を調べるには、DBA_CAPTUREビューのCAPTURE_NAME列を問い合せます。
データベースの伝播の名前を調べるには、DBA_PROPAGATIONビューのPROPAGATION_NAME列を問い合せます。
データベースの適用プロセスの名前を調べるには、DBA_APPLYビューのAPPLY_NAME列を問い合せます。
この例では、1つのデータベースで取得プロセスと適用プロセスを使用して変更を記録します。したがって、伝播は使用しません。
取得プロセスの名前がcap$chg3であり、適用プロセスの名前がapp$chg4であると想定します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。
既存の取得プロセスが使用されるデータベースにOracle Streams管理者として接続します。
MAINTAIN_CHANGE_TABLEプロシージャを実行します。
BEGIN
DBMS_STREAMS_ADM.MAINTAIN_CHANGE_TABLE(
change_table_name => 'hr.employees_change_table',
source_table_name => 'hr.employees',
column_type_list => 'employee_id VARCHAR2(6),
first_name VARCHAR2(20),
last_name VARCHAR2(25),
email VARCHAR2(25),
phone_number VARCHAR2(20),
hire_date DATE,
job_id VARCHAR2(10),
salary NUMBER(8,2),
commission_pct NUMBER(2,2),
manager_id NUMBER(6),
department_id NUMBER(4)',
extra_column_list => 'command_type,value_type,commit_scn',
capture_values => '*',
capture_name => 'cap$chg3',
apply_name => 'app$chg4',
keep_change_columns_only => FALSE);
END;
/
このプロシージャでは、指定のない各パラメータにはデフォルト値が使用されます。hr.jobs表のすべての列がcolumn_type_listパラメータで指定されているため、keep_change_columns_onlyパラメータはFALSEに設定されています。
このプロシージャが完了したら、Oracle Streams環境が構成されます。
このプロシージャがエラーによって停止した場合は、エラーからのリカバリ方法またはDBMS_STREAMS_ADM.RECOVER_OPERATIONプロシージャを使用して構成操作をロールバックする方法について、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
構成されたOracle Streams環境は次の特性を持ちます。
前述の「1つのデータベースでのローカル取得とローカル適用を使用した表の変更の記録」で説明した特性を持ちます。
無条件のサプリメンタル・ログ・グループには、hr.employees表のすべての列が含まれます。
データベースにはhr.employees_change_tableが存在します。このチェンジ・テーブルの定義は次のとおりです。
Name Null? Type ----------------------------------------- -------- --------------------------- COMMAND_TYPE$ VARCHAR2(10) VALUE_TYPE$ VARCHAR2(3) COMMIT_SCN$ NUMBER EMPLOYEE_ID VARCHAR2(6) FIRST_NAME VARCHAR2(20) LAST_NAME VARCHAR2(25) EMAIL VARCHAR2(25) PHONE_NUMBER VARCHAR2(20) HIRE_DATE DATE JOB_ID VARCHAR2(10) SALARY NUMBER(8,2) COMMISSION_PCT NUMBER(2,2) MANAGER_ID NUMBER(6) DEPARTMENT_ID NUMBER(4)
取得プロセスcap$chg3では、hr.employees表に対するデータ操作言語(DML)の変更を取得します。
適用プロセスapp$chg4では、システム生成名を持つ変更ハンドラを使用して、hr.employees表に対する挿入、更新および削除に関して取得された行LCRを処理します。変更ハンドラでは、行LCR内の情報を使用して、hr.employees_change_tableへの移入を行います。
チェンジ・テーブルは、時間の経過に伴って大きくなることがあります。1つ以上のチェンジ・テーブルを問い合せて、トランザクション一貫性が保証された一連の変更データを取得できます。変更データが不要になった場合は、チェンジ・テーブルから削除できます。これらの操作を実行するには、MAINTAIN_CHANGE_TABLEプロシージャの実行時にextra_column_listパラメータにcommit_scnを含めることで、コミットSCNメタデータを追跡するようにチェンジ・テーブルを構成します。コミットSCNを使用すると、一貫性が保証されたデータを取得したり、削除する不要データを指定できます。
この項の例では、次の各項で作成されたチェンジ・テーブルをメンテナンスします。
hr.jobs_change_tableは、「1つのデータベースでのローカル取得とローカル適用を使用した表の変更の記録」の例で作成されたものです。
hr.employees_change_tableは、「既存のOracle Streamsコンポーネントを使用した表の変更の記録」で作成されたものです。
この項の例では、チェンジ・テーブルを問い合せてトランザクション一貫性が保証された一連の変更データを取得してから、表示された変更データを削除します。
チェンジ・テーブルをメンテナンスするには、次の手順を実行します。
チェンジ・テーブルに変更を適用する適用プロセスの現在の最低水位標を調べます。この最低水位標以下のシステム変更番号(SCN)でコミットされた変更は確実に適用されています。
たとえば、適用プロセスの名前がapp$chg4である場合は、次の問合せを実行してその最低水位標を調べます。
SELECT APPLIED_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS WHERE APPLY_NAME='APP$CHG4';
返された最低水位標SCNを書き留めます。この例では、最低水位標SCNは663090であるとします。
手順1で返された最低水位標以下の変更について、チェンジ・テーブルを問い合せます。
たとえば、hr.jobs_change_tableに対しては次の問合せを実行します。
SELECT * FROM hr.jobs_change_table WHERE commit_scn$ <= 663090;
たとえば、hr.employees_change_tableに対しては次の問合せを実行します。
SELECT * FROM hr.employees_change_table WHERE commit_scn$ <= 663090;
これらの問合せでは、手順1で返された最低水位標SCNを指定します。返される変更のトランザクション一貫性は、指定したSCNまで保証されています。
手順2で表示された変更が不要な場合は、次の文を実行してその変更を削除します。
DELETE FROM hr.jobs_change_table WHERE commit_scn$ <= 663090; DELETE FROM hr.employees_change_table WHERE commit_scn$ <= 663090; COMMIT;
他の方法でチェンジ・テーブルをメンテナンスすることもできます。たとえば、2つのSCN値の間の変更の範囲を使用して、チェンジ・テーブルを問い合せることができます。また、2つ以上のチェンジ・テーブル内の一貫性が保証された一連のデータを表示するビューを作成することもできます。
MAINTAIN_CHANGE_TABLEプロシージャによってOracle Streams環境が構成されたら、次の表に示す項を参照して、Oracle Streams環境を管理できます。
| 管理対象 | 参照先 |
|---|---|
| サプリメンタル・ロギング | 『Oracle Streamsレプリケーション管理者ガイド』 |
| 取得プロセス | 「取得プロセスの管理」 |
| 適用プロセス | 第17章「Oracle Streams情報コンシュームの管理」 |
| 文DMLハンドラ | 「文DMLハンドラの管理」 |
| キュー | 「キューの管理」 |
| 伝播 | 「Oracle Streamsの伝播および伝播ジョブの管理」 |
| ルール | 第18章「ルールの管理」 |
この項では、表の変更を追跡する構成でのOracle Streamsコンポーネントの監視について説明します。
この項の内容は次のとおりです。
他のデータベース表を監視する場合と同様に、SELECT文を使用してチェンジ・テーブルを監視できます。チェンジ・テーブルの列は、MAINTAIN_CHANGE_TABLEプロシージャのcolumn_type_listパラメータによって異なります。チェンジ・テーブルには、ソース・テーブルの各列に対応する列を追跡対象として含めることも、ソース・テーブルの列のサブセットを含めることもできます。また、チェンジ・テーブルには、各変更に関するメタデータを含むいくつかの列を追加することもできます。
たとえば、「1つのデータベースでのローカル取得とローカル適用を使用した表の変更の記録」で構成されたOracle Streams環境では、hr.jobs表に対する変更が記録されます。hr.jobs表の各列がチェンジ・テーブルhr.jobs_change_tableで追跡され、デフォルトのメタデータ列(command_type$、value_type$およびcommit_scn$)がチェンジ・テーブルに追加されています。
このサンプル・チェンジ・テーブルを監視するには、次の手順を実行します。
データベースにhrユーザーとして接続します。
SQL*Plusでデータベースに接続する方法については、『Oracle Database管理者ガイド』を参照してください。
ソース・テーブルを変更して、チェンジ・テーブルに移入されるようにします。
INSERT INTO hr.jobs VALUES('BN_CNTR','Bean Counter',6000,8000);
COMMIT;
UPDATE hr.jobs SET min_salary=7000 WHERE job_id='BN_CNTR';
COMMIT;
DELETE FROM hr.jobs WHERE job_id='BN_CNTR';
COMMIT;
チェンジ・テーブルを問い合せます。
COLUMN COMMAND_TYPE$ HEADING 'Command Type' FORMAT A12 COLUMN VALUE_TYPE$ HEADING 'Value|Type' FORMAT A5 COLUMN COMMIT_SCN$ HEADING 'Commit SCN' FORMAT 9999999 COLUMN JOB_ID HEADING 'Job ID' FORMAT A10 COLUMN JOB_TITLE HEADING 'Job Title' FORMAT A12 COLUMN MIN_SALARY HEADING 'Minimum|Salary' FORMAT 9999999 COLUMN MAX_SALARY HEADING 'Maximum|Salary' FORMAT 9999999 SELECT * FROM hr.jobs_change_table;
出力は次のようになります。
Value Minimum Maximum
Command Type Type Commit SCN Job ID Job Title Salary Salary
------------ ----- ---------- ---------- ------------ -------- --------
INSERT NEW 663075 BN_CNTR Bean Counter 6000 8000
UPDATE OLD 663082 BN_CNTR Bean Counter 6000 8000
UPDATE NEW 663082 BN_CNTR Bean Counter 7000 8000
DELETE OLD 663090 BN_CNTR Bean Counter 7000 8000
この出力には、手順2で行った変更が示されます。
この項では、変更ハンドラの監視について説明します。
この項の内容は次のとおりです。
DBA_APPLY_CHANGE_HANDLERSビューを問い合せて、データベースの各変更ハンドラに関する次の情報を表示できます。
変更ハンドラの名前
更新操作用の変更ハンドラによって追跡される取得値(新しい列値の場合はNEW、古い列値の場合はOLD、両方の場合は*)
変更ハンドラを使用している適用プロセスの名前
変更ハンドラが起動される操作(INSERT、UPDATEまたはDELETE)
次の問合せを実行すると、前述の情報が表示されます。
COLUMN HANDLER_NAME HEADING 'Change Handler Name' FORMAT A30
COLUMN CAPTURE_VALUES HEADING 'Capture|Values' FORMAT A7
COLUMN APPLY_NAME HEADING 'Apply|Process' FORMAT A10
COLUMN OPERATION_NAME HEADING 'Operation' FORMAT A10
SELECT HANDLER_NAME,
CAPTURE_VALUES,
APPLY_NAME,
OPERATION_NAME
FROM DBA_APPLY_CHANGE_HANDLERS
ORDER BY HANDLER_NAME;
出力は次のようになります。
Capture Apply
Change Handler Name Values Process Operation
------------------------------ ------- ---------- ----------
HR_DEPARTMENTS_CHG$40 APP$CHG38 INSERT
HR_DEPARTMENTS_CHG$41 APP$CHG38 DELETE
HR_DEPARTMENTS_CHG$42 * APP$CHG38 UPDATE
HR_JOBS_CHG$80 APP$CHG79 INSERT
HR_JOBS_CHG$81 APP$CHG79 DELETE
HR_JOBS_CHG$82 * APP$CHG79 UPDATE
INSERTおよびDELETE操作の「Capture Values」列がNULLであることに注意してください。DBA_APPLY_CHANGE_HANDLERSビューには、UPDATE操作を追跡する変更ハンドラの取得値のみが表示されます。挿入については新しい列値のみが対象となり、削除については古い列値のみが対象となります。
DBA_APPLY_CHANGE_HANDLERSビューを問い合せて、データベースの各変更ハンドラに関する次の情報を表示できます。
変更ハンドラの名前
ソース・テーブルに対する変更を追跡するチェンジ・テーブルの所有者
ソース・テーブルに対する変更を追跡するチェンジ・テーブルの名前
ソース・テーブルの所有者
ソース・テーブルの名前
次の問合せを実行すると、前述の情報が表示されます。
COLUMN HANDLER_NAME HEADING 'Change Handler Name' FORMAT A25
COLUMN CHANGE_TABLE_OWNER HEADING 'Change|Table|Owner' FORMAT A8
COLUMN CHANGE_TABLE_NAME HEADING 'Change|Table|Name' FORMAT A17
COLUMN SOURCE_TABLE_OWNER HEADING 'Source|Table|Owner' FORMAT A8
COLUMN SOURCE_TABLE_NAME HEADING 'Source|Table|Name' FORMAT A17
SELECT HANDLER_NAME,
CHANGE_TABLE_OWNER,
CHANGE_TABLE_NAME,
SOURCE_TABLE_OWNER,
SOURCE_TABLE_NAME
FROM DBA_APPLY_CHANGE_HANDLERS
ORDER BY HANDLER_NAME;
出力は次のようになります。
Change Change Source Source
Table Table Table Table
Change Handler Name Owner Name Owner Name
------------------------- -------- ----------------- -------- -----------------
HR_DEPARTMENTS_CHG$40 HR DEP_CHANGE_TABLE HR DEPARTMENTS
HR_DEPARTMENTS_CHG$41 HR DEP_CHANGE_TABLE HR DEPARTMENTS
HR_DEPARTMENTS_CHG$42 HR DEP_CHANGE_TABLE HR DEPARTMENTS
HR_JOBS_CHG$80 HR JOBS_CHANGE_TABLE HR JOBS
HR_JOBS_CHG$81 HR JOBS_CHANGE_TABLE HR JOBS
HR_JOBS_CHG$82 HR JOBS_CHANGE_TABLE HR JOBS
MAINTAIN_CHANGE_TABLEプロシージャによってOracle Streams環境が構成されたら、次の表に示す項を参照して、Oracle Streams環境を監視できます。
| 監視対象 | 参照先 |
|---|---|
| サプリメンタル・ロギング | 「サプリメンタル・ロギングの監視」 |
| 取得プロセス | 「取得プロセスの監視」 |
| 適用プロセス | 第26章「Oracle Streams適用プロセスの監視」 |
| 文DMLハンドラ | 「文DMLハンドラに関する情報の表示」 |
| キュー | 「バッファ・キューの監視」 |
| 伝播 | 「Oracle Streamsの伝播および伝播ジョブの監視」 |
| ルール | 第27章「ルールの監視」 |
