この章では、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転送サービスが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章「ルールの監視」 |