20 Oracle Streamsを使用した表の変更の記録
20.1 Oracle Streamsを使用した表の変更の記録について
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
ビューには格納されません。
20.2 表の変更を記録するOracle Streams環境の準備
DBMS_STREAMS_ADM
パッケージのMAINTAIN_CHANGE_TABLE
プロシージャでは、ソース・テーブルに対する変更を記録するOracle Streams環境を構成できます。このプロシージャでは、必要なすべてのOracle Streamsコンポーネントを構成します。また、このプロシージャを使用すると、各変更に関して記録するメタデータを識別できます。たとえば、他の多くのタイプのメタデータと同様に、変更を行ったユーザーのユーザー名と変更時間を記録するように指定できます。
MAINTAIN_CHANGE_TABLE
プロシージャを使用して、表の変更を記録するOracle Stream環境を構成する前に、いくつかの決定を行い、前提条件を満たす必要があります。
次の各項では、MAINTAIN_CHANGE_TABLE
プロシージャに関する決定と前提条件について説明します。
20.2.1 MAINTAIN_CHANGE_TABLEプロシージャを実行する前に行う決定
次の各項では、MAINTAIN_CHANGE_TABLE
プロシージャを実行する前に行う決定について説明します。
20.2.1.1 構成する環境のタイプの決定
表の変更を記録する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転送サービスがREDOデータをダウンストリーム・データベースに送信し、ダウンストリーム・データベースのリモート・ファイル・サーバー・プロセス(RFS)でネットワークを介してREDOデータを受け取り、スタンバイREDOログにREDOデータを格納します。
-
アーカイブ・ログ・ダウンストリーム取得プロセス構成: この構成では、ソース・データベースからのアーカイブREDOログ・ファイルがダウンストリーム・データベースにコピーされ、取得プロセスによってこれらのアーカイブREDOログ・ファイル内の変更が取得されます。これらのログ・ファイルは、REDO転送サービスを使用して自動的に転送することも、FTPなどの方法を使用して手動で転送することもできます。
アーカイブ・ログ・ダウンストリーム取得と比較すると、リアルタイム・ダウンストリーム取得には、ソース・データベースで行われた変更を短時間で取得できるというメリットがあります。リアルタイム・ダウンストリーム取得プロセスでは、REDOログ・ファイルがアーカイブされるまで待たずにREDOログ・ファイルから変更を取得できるため、時間が短縮されます。同じソース・データベースから変更を取得する複数のリアルタイム・ダウンストリーム取得プロセスを構成できますが、1つのダウンストリーム・データベースで複数のソース・データベースに対してリアルタイム・ダウンストリーム取得を構成することはできません。
リアルタイム・ダウンストリーム取得と比較すると、アーカイブ・ログ・ダウンストリーム取得には、複数のソース・データベースに対するダウンストリーム取得プロセスを1つのダウンストリーム・データベースで使用できるというメリットがあります。REDOログ・ファイルを複数のソース・データベースから単一のダウンストリーム・データベースにコピーし、それらのREDOログ・ファイル内の変更を複数のアーカイブ・ログ・ダウンストリーム取得プロセスで取得するように構成できます。
20.2.1.2 追跡する列の決定
MAINTAIN_CHANGE_TABLE
プロシージャのcolumn_type_list
パラメータでは、チェンジ・テーブル内で追跡する列を指定できます。Oracle Streams環境では、リストに指定した列の変更のみが記録されます。表のすべての列を追跡するには、このパラメータですべての列を指定します。列のサブセットを追跡するには、追跡する列を指定します。column_type_list
パラメータでは、列のデータ型と有効な任意の列プロパティ(表内の制約指定など)を指定できます。
様々な理由でリストから列を省略できます。たとえば、一部の列には、チェンジ・テーブルへの移入を避けるべき給与データなどの機密情報が含まれている場合があります。また、表が数百もの列で構成されていても、追跡が必要な列はごくわずかしかない場合があります。
20.2.1.3 記録するメタデータの決定
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位置は、XStream構成で一般的に使用されます。
関連項目:
20.2.1.4 更新操作に応じて追跡する値の決定
MAINTAIN_CHANGE_TABLE
プロシージャのcapture_values
パラメータでは、ソース・テーブルに対する更新操作に応じてチェンジ・テーブルに記録する値を指定できます。行に対して更新操作が実行されると、各列の古い値は更新操作前の値になり、新しい値は更新操作後の値になります。古い値または新しい値あるいはその両方を記録するように指定できます。
20.2.1.5 KEEP_COLUMNS変換を構成するかどうかの決定
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
に設定します。
関連項目:
20.2.1.6 チェンジ・テーブルに対してCREATE TABLEオプションを指定するかどうかの決定
MAINTAIN_CHANGE_TABLE
プロシージャのoptions_string
パラメータでは、チェンジ・テーブルを作成するCREATE
TABLE
文にオプションの文字列を追加できます。この文字列は、生成されたCREATE
TABLE
文において、表の列を定義する右カッコの後に追加されます。文字列は構文的に正確である必要があります。たとえば、特定の表領域に表を格納するTABLESPACE
句を指定できます。また、チェンジ・テーブルをパーティション化することもできます。チェンジ・テーブルをパーティション化するメリットは、DELETE
文で行を削除するかわりに、ALTER
TABLE
文のTRUNCATE
PARTITION
句を使用してパーティションを切り捨てることができることです。
関連項目:
CREATE
TABLE
オプションの詳細は、『Oracle Database SQL言語リファレンス』を参照
20.2.1.7 構成アクションを直接実行するか、スクリプトで実行するかの決定
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
パラメータを使用して構成スクリプトの名前と場所を指定します。
20.2.1.8 ソース・テーブルをレプリケートするかどうかの決定
一部の環境では、チェンジ・テーブルに加えて、ソース・テーブルを宛先データベースにレプリケートする必要があります。この場合、ソース・テーブルとチェンジ・テーブルは異なるデータベースにあり、ソース・テーブルの追加のレプリカがチェンジ・テーブルと同じデータベースに含まれます。
たとえば、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に含まれていない場合は、適用エラーが発生します。
関連項目:
20.2.2 MAINTAIN_CHANGE_TABLEプロシージャに関する前提条件
DBMS_STREAMS_ADM
パッケージには、MAINTAIN_GLOBAL
、MAINTAIN_SCHEMAS
、MAINTAIN_TABLES
など、レプリケーション環境を構成するプロシージャが用意されています。MAINTAIN_CHANGE_TABLE
プロシージャの使用方法はこれらの他のプロシージャの使用方法と類似しており、前提条件の多くも同じです。
次の各項では、MAINTAIN_CHANGE_TABLE
プロシージャを実行する前に満たす必要がある前提条件について説明します。
これらの前提条件の多くは、『Oracle Streamsレプリケーション管理者ガイド』で詳しく説明されています。
20.2.2.1 すべてのデータベースでのOracle Streams管理者の構成
環境内の各データベースでは、Oracle Streams管理者にOracle Streamsコンポーネントを構成および管理させる必要があります。詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
20.2.2.2 ネットワーク接続性とデータベース・リンクの構成
構成する予定のOracle Streams環境のタイプに応じて、ネットワーク接続性と1つ以上のデータベース・リンクが必要になる場合があります。環境に複数のデータベースが存在する場合は、環境内のデータベース間のネットワーク接続性が必要です。
各タイプのOracle Streams環境では、次のデータベース・リンクが必要です。
-
1つのデータベースでのローカル取得とローカル適用: データベース・リンクは不要です。
-
ローカル取得とリモート適用: ソース・データベースから宛先データベースへのデータベース・リンクが必要です。
-
ダウンストリーム取得とローカル適用: 次のデータベース・リンクが必要です。
-
ソース・データベースから接続先データベースへのデータベース・リンク。
-
宛先データベースからソース・データベースへのデータベース・リンク
-
-
ダウンストリーム取得とリモート適用: 次のデータベース・リンクが必要です。
-
ソース・データベースから接続先データベースへのデータベース・リンク。
-
ソース・データベースから取得データベースへのデータベース・リンク
-
取得データベースからソース・データベースへのデータベース・リンク
-
取得データベースから宛先データベースへのデータベース・リンク
-
詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
20.2.2.3 ソース・データベースがARCHIVELOGモードであることの確認
Oracle Streamsの取得プロセスではREDOログをスキャンして変更を取得するため、ソース・テーブルが存在するソース・データベースをARCHIVELOG
モードにする必要があります。ダウンストリーム取得プロセスを構成する予定の場合は、取得データベースもARCHIVELOG
モードにする必要があります。詳細は、『Oracle Database管理者ガイド』を参照してください。
20.2.2.4 Oracle Streamsに関連する初期化パラメータの設定
一部の初期化パラメータは、Oracle Streams環境の構成、操作、信頼性およびパフォーマンスにとって重要です。これらのパラメータをOracle Streams環境にあわせて適切に設定します。詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
20.2.2.5 Oracle Streamsプールの構成
Oracle Streamsプールは、Oracle Streamsで使用されるシステム・グローバル領域(SGA)にあるメモリーです。データベース・メモリーを構成して、Oracle Streamsプールに十分な空き領域を確保します。詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
20.2.2.6 ダウンストリーム取得データベースへのログ・ファイルの転送の構成
ソース・データベースでローカル取得プロセスを使用するように決定した場合は、ログ・ファイルの転送は不要です。ただし、REDO転送サービスによってアーカイブREDOログ・ファイルをダウンストリーム・データベースに自動的に転送するダウンストリーム取得を使用するように決定した場合は、Oracle Streams環境を構成する前に、ソース・データベースから取得データベースへのログ・ファイルの転送を構成します。詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
関連項目:
20.2.2.7 リアルタイム・ダウンストリーム取得に対するスタンバイREDOログの構成
リアルタイム・ダウンストリーム取得プロセスを使用するように決定した場合は、取得データベースでスタンバイREDOログを構成する必要があります。詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
関連項目:
20.2.2.8 スクリプトを使用する場合に必要なディレクトリ・オブジェクトの構成
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管理者がディレクトリ・オブジェクトを作成します。
20.2.2.9 宛先データベースでのソース・テーブルのインスタンス化
ソース・テーブルをレプリケートするように決定した場合は、宛先データベースでソース・テーブルをインスタンス化します。ソース・テーブルをレプリケートしないように決定した場合、インスタンス化は不要です。
ソース・テーブルをレプリケートするように決定したためにインスタンス化が必要な場合は、MAINTAIN_CHANGE_TABLE
プロシージャを実行する前に、次の手順を実行します。
-
ソース・テーブルをインスタンス化のために準備します。
-
ソース・テーブルとレプリカ・テーブルに一貫性があることを確認します。
-
宛先データベースでレプリカ・テーブルのインスタンス化SCNを設定します。
関連項目:
-
インスタンス化手順については、『Oracle Streamsレプリケーション管理者ガイド』を参照
20.3 表の変更を記録するOracle Streams環境の構成
この項では、表の変更を記録するOracle Streams環境を構成する方法について例を挙げて説明します。具体的には、表の変更を記録する4つのタイプのOracle Streams環境について説明します。
この項では、次の例を示します。
20.3.1 1つのデータベースでのローカル取得とローカル適用を使用した表の変更の記録
この例では、1つのデータベースでのローカル取得とローカル適用を使用して表に対する変更を記録する方法について説明します。具体的には、この例では、hr.jobs
表に対する変更を記録します。
次の表に、この例で構成されるOracle Streams環境に関する事前の決定を示します。
決定 | この例の前提 |
---|---|
この例では、1つのデータベースでのローカル取得とローカル適用を構成します。 |
|
この例では、 |
|
この例では、 |
|
この例では、ソース・テーブルに対して更新操作が実行されたときに、古い列値と新しい列値の両方を追跡します。 |
|
この例では、 |
|
この例では、どの |
|
この例では、構成アクションを直接実行します。スクリプトは使用しません。 |
|
この例では、ソース・テーブルをレプリケートしません。 |
図20-1に、この例で作成されるOracle Stream環境の概要を示します。
1つのデータベースでのローカル取得とローカル適用を使用して表に対する変更を記録する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
への移入を行います。
関連項目:
hr.jobs
表を変更し、hr.jobs_change_table
を問い合せて変更の追跡を確認する例については、「チェンジ・テーブルの監視」を参照
20.3.2 ローカル取得とリモート適用を使用した表の変更の記録およびレプリケーション
この例では、ローカル取得とリモート適用を使用して表に対する変更を記録する方法について説明します。この例で構成されるOracle Stream環境では、表に対する変更を記録するのみでなく、変更をレプリケートします。
具体的には、この例では、hr.departments
表の列のサブセットに対する変更を記録します。また、hr.departments
表のすべての列に対するデータ操作言語(DML)の変更をレプリケートします。この例で構成されるOracle Streams環境では、ソース・データベースct1.example.com
に対する変更を取得し、その変更を宛先データベースct2.example.com
に送信します。ct2.example.com
の適用プロセスでは、チェンジ・テーブルに変更を記録し、その変更をレプリカのhr.departments
表に適用します。
次の表に、この例で構成されるOracle Streams環境に関する事前の決定を示します。
決定 | この例の前提 |
---|---|
この例では、2つのデータベースを使用するローカル取得とリモート適用を構成します。ソース・データベースは |
|
この例では、 |
|
この例では、 |
|
この例では、ソース・テーブルに対して更新操作が実行されたときに、古い列値と新しい列値の両方を追跡します。 |
|
この例では、表のすべての列がレプリケートされるため、 |
|
この例では、どの |
|
この例では、構成アクションを直接実行します。スクリプトは使用しません。 |
|
この例では、宛先データベースにソース・テーブルをレプリケートします。したがって、ソース・データベースと宛先データベースの両方に |
図20-2に、この例で作成されるOracle Stream環境の概要を示します。
ローカル取得とリモート適用を使用して表に対する変更を記録およびレプリケートする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
データベースに送信されます。
20.3.3 ダウンストリーム取得とローカル適用を使用した表の変更の記録
この例では、ダウンストリーム取得とローカル適用を使用して表に対する変更を記録する方法について説明します。具体的には、この例では、ソース・データベースと宛先データベースを使用して、hr.locations
表に対する変更を記録します。宛先データベースは、ダウンストリーム取得プロセス用の取得データベースにもなります。
次の表に、この例で構成されるOracle Streams環境に関する事前の決定を示します。
決定 | この例の前提 |
---|---|
この例では、ソース・データベース |
|
この例では、 |
|
この例では、 |
|
この例では、ソース・テーブルに対して更新操作が実行されたときに、古い列値と新しい列値の両方を追跡します。 |
|
この例では、 |
|
この例では、どの |
|
この例では、構成アクションを直接実行します。スクリプトは使用しません。 |
|
この例では、ソース・テーブルをレプリケートしません。 |
図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
への移入を行います。
関連項目:
20.3.4 ダウンストリーム取得とリモート適用を使用した表の変更の記録
この例では、ダウンストリーム取得とリモート適用を使用して表に対する変更を記録する方法について説明します。具体的には、この例では、ソース・データベース、宛先データベースおよび取得データベースの3つのデータベースを使用して、hr.employees
表に対する変更を記録します。
次の表に、この例で構成されるOracle Streams環境に関する事前の決定を示します。
決定 | この例の前提 |
---|---|
この例では、3つのデータベースを使用するダウンストリーム取得とリモート適用を構成します。ソース・データベースは |
|
この例では、 |
|
この例では、 |
|
この例では、ソース・テーブルに対して更新操作が実行されたときに、古い列値と新しい列値の両方を追跡します。 |
|
この例では、従業員の給与と歩合に関する情報を行LCRに含めないように、 |
|
この例では、 |
|
この例では、構成アクションを直接実行します。スクリプトは使用しません。 |
|
この例では、ソース・テーブルをレプリケートしません。 |
図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
への移入を行います。
関連項目:
20.4 表の変更を記録するOracle Streams環境の管理
この項では、変更ハンドラの設定および設定解除について説明します。
この項には、次の項目が含まれます。
20.4.1 変更ハンドラの設定解除および設定
DBMS_APPLY_ADM
パッケージのSET_CHANGE_HANDLER
プロシージャでは、単一の適用プロセスの対象として指定された表に対する特定の操作用の変更ハンドラを設定解除および設定できます。このプロシージャでは、指定された表に対する変更を取得し、その変更を指定された適用プロセスに送信するようにOracle Streamsコンポーネントが構成されていると想定されます。
この項の例では、「ローカル取得とリモート適用を使用した表の変更の記録およびレプリケーション」で作成された更新操作用の変更ハンドラを設定解除するものとします。次に、この変更ハンドラを再設定します。
変更ハンドラを設定するには、次の手順を実行します。
20.4.2 既存のOracle Streamsコンポーネントを使用した表の変更の記録
表に対する変更を記録するように既存のOracle Streamsコンポーネントを構成できます。これらの既存のコンポーネントには、取得プロセス、伝播および適用プロセスがあります。既存のコンポーネントを使用するには、DBMS_STREAMS_ADM
パッケージのMAINTAIN_CHANGE_TABLE
プロシージャを実行するときにコンポーネント名を指定します。
この項の例は、「1つのデータベースでのローカル取得とローカル適用を使用した表の変更の記録」で作成されたOracle Streams環境に基づきます。その例では、hr.jobs
表に対する変更を記録するOracle Streams環境を構成しました。この項の例では、hr.employees
表に対する変更も記録するように、既存の取得プロセスと適用プロセスを構成します。
次の表に、hr.employees
表で記録される変更に関する事前の決定を示します。
決定 | この例の前提 |
---|---|
この例では、1つのデータベースでローカル取得とローカル適用を実行する既存のOracle Streamsコンポーネントを使用します。 |
|
この例では、 |
|
この例では、 |
|
この例では、ソース・テーブルに対して更新操作が実行されたときに、古い列値と新しい列値の両方を追跡します。 |
|
この例では、 |
|
この例では、どの |
|
この例では、構成アクションを直接実行します。スクリプトは使用しません。 |
|
この例では、ソース・テーブルをレプリケートしません。 |
既存の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
への移入を行います。
20.4.3 チェンジ・テーブルのメンテナンス
チェンジ・テーブルは、時間の経過に伴って大きくなることがあります。1つ以上のチェンジ・テーブルを問い合せて、トランザクション一貫性が保証された一連の変更データを取得できます。変更データが不要になった場合は、チェンジ・テーブルから削除できます。これらの操作を実行するには、MAINTAIN_CHANGE_TABLE
プロシージャの実行時にextra_column_list
パラメータにcommit_scn
を含めることで、コミットSCNメタデータを追跡するようにチェンジ・テーブルを構成します。コミットSCNを使用すると、一貫性が保証されたデータを取得したり、削除する不要データを指定できます。
この項の例では、次の各項で作成されたチェンジ・テーブルをメンテナンスします。
-
hr.jobs_change_table
は、「1つのデータベースでのローカル取得とローカル適用を使用した表の変更の記録」の例で作成されたものです -
hr.employees_change_table
は、「既存のOracle Streamsコンポーネントを使用した表の変更の記録」で作成されたものです
この項の例では、チェンジ・テーブルを問い合せてトランザクション一貫性が保証された一連の変更データを取得してから、表示された変更データを削除します。
チェンジ・テーブルをメンテナンスするには、次の手順を実行します。
他の方法でチェンジ・テーブルをメンテナンスすることもできます。たとえば、2つのSCN値の間の変更の範囲を使用して、チェンジ・テーブルを問い合せることができます。また、2つ以上のチェンジ・テーブル内の一貫性が保証された一連のデータを表示するビューを作成することもできます。
関連項目:
20.4.4 Oracle Streams環境の管理
MAINTAIN_CHANGE_TABLE
プロシージャによってOracle Streams環境が構成されたら、次の表に示す項を参照して、Oracle Streams環境を管理できます。
管理対象 | 参照先 |
---|---|
サプリメンタル・ロギング |
|
取得プロセス |
|
適用プロセス |
|
文DMLハンドラ |
|
キュー |
「キューの管理」 |
伝播 |
|
ルール |
20.5 表の変更を記録するOracle Streams環境の監視
この項では、表の変更を追跡する構成でのOracle Streamsコンポーネントの監視について説明します。
この項には、次の項目が含まれます。
20.5.1 チェンジ・テーブルの監視
他のデータベース表を監視する場合と同様に、SELECT
文を使用してチェンジ・テーブルを監視できます。チェンジ・テーブルの列は、MAINTAIN_CHANGE_TABLE
プロシージャのcolumn_type_list
パラメータによって異なります。チェンジ・テーブルには、ソース・テーブルの各列に対応する列を追跡対象として含めることも、ソース・テーブルの列のサブセットを含めることもできます。また、チェンジ・テーブルには、各変更に関するメタデータを含むいくつかの列を追加することもできます。
たとえば、「1つのデータベースでのローカル取得とローカル適用を使用した表の変更の記録」で構成されたOracle Streams環境では、hr.jobs
表に対する変更が記録されます。hr.jobs
表の各列がチェンジ・テーブルhr.jobs_change_table
で追跡され、デフォルトのメタデータ列(command_type$
、value_type$
およびcommit_scn$
)がチェンジ・テーブルに追加されています。
このサンプル・チェンジ・テーブルを監視するには、次の手順を実行します。
20.5.2 変更ハンドラの監視
20.5.2.1 変更ハンドラに関する一般情報の表示
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
操作を追跡する変更ハンドラの取得値のみが表示されます。挿入については新しい列値のみが対象となり、削除については古い列値のみが対象となります。
20.5.2.2 変更ハンドラの対象となるチェンジ・テーブルとソース・テーブルの表示
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