暗黙的取得とは、データベースの変更が自動的に取得され、エンキューされることを意味します。暗黙的取得は、取得プロセスまたは同期取得を使用して実行できます。取得プロセスではREDOログ内の変更が取得され、同期取得では内部メカニズムを使用してDMLの変更が取得されます。取得プロセスおよび同期取得の両方で、取得された変更は論理変更レコード(LCR)に再フォーマットされ、そのLCRがANYDATA
キューにエンキューされます。
次の各項では、暗黙的取得の構成について説明します。
この章で説明する各タスクは、特に明記されていないかぎり、適切な権限を付与されているOracle Streams管理者が完了する必要があります。
ソース・データベースでローカルに変更を取得するか、またはダウンストリーム・データベースでリモートに変更を取得する取得プロセスを作成できます。取得プロセスがダウンストリーム・データベースで実行されている場合は、ソース・データベースからのREDOデータがダウンストリーム・データベースにコピーされ、ダウンストリーム・データベースで取得プロセスによってREDOデータの変更が取得されます。
ローカル取得プロセスを作成するには、次のいずれかのプロシージャを使用します。
DBMS_STREAMS_ADM.ADD_TABLE_RULES
DBMS_STREAMS_ADM.ADD_SUBSET_RULES
DBMS_STREAMS_ADM.ADD_SCHEMA_RULES
DBMS_STREAMS_ADM.ADD_GLOBAL_RULES
DBMS_CAPTURE_ADM.CREATE_CAPTURE
DBMS_STREAMS_ADM
パッケージ内の各プロシージャでは、指定された名前を持つ取得プロセスが存在しない場合は取得プロセスが作成され、取得プロセスにポジティブ・ルール・セットとネガティブ・ルール・セットのいずれも存在しない場合はそのいずれかのルール・セットが作成されます。また、ルール・セットに表ルール、スキーマ・ルールまたはグローバル・ルールを追加することもできます。
CREATE_CAPTURE
プロシージャでは取得プロセスは作成されますが、取得プロセスのルール・セットおよびルールは作成されません。ただし、CREATE_CAPTURE
プロシージャを使用すると、取得プロセスの先頭SCNおよび開始SCNが作成されます。ダウンストリーム取得を実行する取得プロセスを作成するには、CREATE_CAPTURE
プロシージャを使用する必要があります。
次の各項では、取得プロセスの構成について説明します。
注意: 取得プロセスを起動または再起動する際、開始SCN未満のFIRST_CHANGE# 値が含まれているREDOログ・ファイルをスキャンする必要がある場合があります。取得プロセスによってスキャンされる前に必要なREDOログ・ファイルを削除すると、取得プロセスは強制終了されます。取得プロセスの先頭SCN、開始SCNおよび必須チェックポイントSCNを判別するには、DBA_CAPTURE データ・ディクショナリ・ビューを問い合せます。取得プロセスには、必須チェックポイントSCNが含まれているREDOログ・ファイルおよび後続のすべてのREDOログ・ファイルが必要です。取得プロセスの先頭SCNおよび開始SCNの詳細は、「取得プロセスの作成」を参照してください。 |
|
関連項目:
|
取得プロセスを構成する前に、次のタスクを完了する必要があります。
ARCHIVELOG
モードで実行される取得プロセスによって取得されるREDOデータを生成するすべてのソース・データベースを構成します。「ARCHIVELOGモードおよび取得プロセス」およびOracle Database管理者ガイドを参照してください。ダウンストリーム取得プロセスでは、リアルタイム・ダウンストリーム取得プロセスを構成する場合、ダウンストリーム・データベースもARCHIVELOG
モードで実行する必要があります。アーカイブ・ログ・ダウンストリーム取得プロセスでのみ実行する場合は、ダウンストリーム・データベースをARCHIVELOG
モードで実行する必要はありません。
取得プロセスが実行されるすべてのデータベースで初期化パラメータが適切に設定されていることを確認します。「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。
Oracle Streams構成に含まれる各データベースのOracle Streams管理者を作成します。この章の例では、Oracle Streams管理者がstrmadmin
であると想定しています。取得プロセスを作成するには、Oracle Streams管理者にDBA
ロールが付与されている必要がありますが、このロールは必要に応じて取得プロセスを作成した後にのみ起動できます。「Oracle Streams管理者の構成」を参照してください。
取得プロセスに関連付けるANYDATA
キューが存在しない場合は作成します。詳細は、「ANYDATAキューの作成」を参照してください。この章の例では、取得プロセスで使用されるキューは、strmadmin.streams_queue
であるとします。
ソース・データベースのいくつかの列に対してサプリメンタル・ロギングを指定して、それらの列に対する変更が宛先データベースに正常に適用されるようにします。通常、サプリメンタル・ロギングはOracle Streamsレプリケーション環境で必要ですが、適用プロセスで取得LCRを処理する環境でも必要となる場合があります。
「取得プロセスの構成」に示されているADD_TABLE_RULES
などのプロシージャを使用すると、レプリケートされた表のすべての主キー、一意キー、ビットマップ索引および外部キーの列に対してサプリメンタル・ロギングが自動的に構成されます。また、ALTER
DATABASE
文を使用すると、データベース内のすべての表のサプリメンタル・ロギングを指定でき、ALTER
TABLE
文を使用すると、特定の表のサプリメンタル・ロギングを指定できます。サプリメンタル・ロギングの指定の詳細は、Oracle Streamsレプリケーション管理者ガイドを参照してください。
次の各項では、DBMS_STREAMS_ADM
パッケージおよびDBMS_CAPTURE_ADM
パッケージを使用してローカル取得プロセスを作成する方法について説明します。
この項の項目は次のとおりです。
DBMS_STREAMS_ADM
パッケージを使用してローカル取得プロセスを構成するには、次の手順を実行します。
「取得プロセスの構成準備」で説明されているタスクを実行します。
DBMS_STREAMS_ADM
パッケージのADD_TABLE_RULES
プロシージャを実行して、ローカル取得プロセスを作成します。
BEGIN DBMS_STREAMS_ADM.ADD_TABLE_RULES( table_name => 'hr.employees', streams_type => 'capture', streams_name => 'strm01_capture', queue_name => 'strmadmin.streams_queue', include_dml => TRUE, include_ddl => TRUE, include_tagged_lcr => FALSE, source_database => NULL, inclusion_rule => TRUE); END; /
このプロシージャを実行すると、次のアクションが実行されます。
strm01_capture
という名前の取得プロセスが作成されます。この取得プロセスは、存在しない場合にのみ作成されます。新しい取得プロセスが作成された場合は、このプロシージャによって開始SCNが作成された時間の設定も実行されます。
取得プロセスがstreams_queue
という名前の既存のキューに関連付けられます。
取得プロセスにポジティブ・ルール・セットがない場合は、ポジティブ・ルール・セットが作成され、取得プロセスに関連付けられます。これは、inclusion_rule
パラメータがTRUE
に設定されているためです。ルール・セットではSYS.STREAMS$_EVALUATION_CONTEXT
評価コンテキストが使用されます。ルール・セットの名前はシステムによって生成されます。
2つのルールが作成されます。一方のルールはhr.employees
表へのDML変更についてTRUE
と評価され、他方のルールはhr.employees
表に対するDDL変更についてTRUE
と評価されます。
取得プロセスに関連付けられたポジティブ・ルール・セットにこれらの2つのルールが追加されます。これらのルールは、inclusion_rule
パラメータがTRUE
にセットされているため、ポジティブ・ルール・セットに追加されます。
変更にNULL
タグが付いている場合にのみ取得プロセスによってREDOログ内の変更が取得されるように指定されます。これは、include_tagged_lcr
パラメータがFALSE
に設定されているためです。この動作は、取得プロセスのシステム作成ルールによって実行されます。
ソース・データベースに対して行われたローカルな変更を取得する取得プロセスが作成されます。これは、source_database
パラメータがNULL
に設定されているためです。ローカル取得プロセスの場合は、このパラメータに対してローカル・データベースのグローバル名を指定することもできます。
hr.employees
表がインスタンス化のために準備されます。
表のすべての主キー、一意キー、ビットマップ索引および外部キーの列に対してサプリメンタル・ロギングが有効にされます。
必要に応じて、「取得プロセスの構成後に行う作業」で説明されている手順を実行します。
DBMS_CAPTURE_ADM
パッケージを使用してローカル取得プロセスを構成するには、次の手順を実行します。
「取得プロセスの構成準備」で説明されているタスクを実行します。
DBMS_CAPTURE_ADM
パッケージのCREATE_CAPTURE
プロシージャを実行して、ローカル取得プロセスを作成します。
BEGIN DBMS_CAPTURE_ADM.CREATE_CAPTURE( queue_name => 'strmadmin.streams_queue', capture_name => 'strm02_capture', rule_set_name => 'strmadmin.strm01_rule_set', start_scn => NULL, source_database => NULL, first_scn => NULL); END; /
このプロシージャを実行すると、次のアクションが実行されます。
strm02_capture
という名前の取得プロセスが作成されます。この場合、同じ名前の取得プロセスが存在していない必要があります。
取得プロセスをstreams_queue
という名前の既存のキューに関連付けます。
取得プロセスをstrm01_rule_set
という名前の既存のルール・セットに関連付けます。このルール・セットは、取得プロセスのポジティブ・ルール・セットです。
ソース・データベースに対して行われたローカルな変更を取得する取得プロセスが作成されます。これは、source_database
パラメータがNULL
に設定されているためです。ローカル取得プロセスの場合は、このパラメータに対してローカル・データベースのグローバル名を指定することもできます。
取得プロセスの開始SCNおよび先頭SCNがOracle Databaseによって決定されるように指定されます。これは、start_scn
とfirst_scn
の両方がNULL
に設定されているためです。
ローカルな変更を取得する他の取得プロセスがローカル・データベースで実行されていない場合は、DBMS_CAPTURE_ADM
パッケージのBUILD
プロシージャが自動的に実行されます。このプロシージャが実行されると、データ・ディクショナリがREDOログに抽出され、この取得プロセスの最初の起動時にLogMinerデータ・ディクショナリが作成されます。
必要に応じて、「取得プロセスの構成後に行う作業」で説明されている手順を実行します。
この例では、DBMS_CAPTURE_ADM
パッケージのCREATE_CAPTURE
プロシージャを実行して、開始SCNが223525
に設定されたローカル取得プロセスを作成します。この例では、データベースに1つ以上のローカル取得プロセスがあること、およびその取得プロセスで1つ以上のチェックポイントが記録されていることが想定されています。新しい取得プロセスに対して、ソース・データベースの現行のSCN以上の開始SCNは常に指定できます。ソース・データベースの現行のSCN未満の開始SCNを指定する場合、指定する開始SCNは、1回以上正常に起動され、1つ以上のチェックポイントが記録されている既存のローカル取得プロセスの最小の先頭SCNより大きくする必要があります。
次の問合せを実行すると、既存の取得プロセスの先頭SCN、およびそれらの取得プロセスでチェックポイントが記録されているかどうかを確認できます。
SELECT CAPTURE_NAME, FIRST_SCN, MAX_CHECKPOINT_SCN FROM DBA_CAPTURE;
出力は次のようになります。
CAPTURE_NAME FIRST_SCN MAX_CHECKPOINT_SCN ------------------------------ ---------- ------------------ CAPTURE_SIMP 223522 230825
これらの結果は、capture_simp
取得プロセスの先頭SCNが223522
であることを示しています。また、MAX_CHECKPOINT_SCN
の値がNULL
ではないため、この取得プロセスでチェックポイントが記録されていることがわかります。したがって、新しい取得プロセスの開始SCNには、223522
以上を設定できます。
開始SCNをNULL
以外にしてローカル取得プロセスを構成するには、次の手順を実行します。
「取得プロセスの構成準備」で説明されているタスクを実行します。
次のプロシージャを実行して、取得プロセスを作成します。
BEGIN DBMS_CAPTURE_ADM.CREATE_CAPTURE( queue_name => 'strmadmin.streams_queue', capture_name => 'strm05_capture', rule_set_name => 'strmadmin.strm01_rule_set', start_scn => 223525, source_database => NULL, first_scn => NULL); END; /
このプロシージャを実行すると、次のアクションが実行されます。
strm05_capture
という名前の取得プロセスが作成されます。この場合、同じ名前の取得プロセスが存在していない必要があります。
取得プロセスがstreams_queue
という名前の既存のキューに関連付けられます。
取得プロセスがstrm01_rule_set
という名前の既存のルール・セットに関連付けられます。このルール・セットは、取得プロセスのポジティブ・ルール・セットです。
取得プロセスの開始SCNとして223525
が指定されます。新しい取得プロセスでは、既存の取得プロセスのいずれかと同じLogMinerデータ・ディクショナリが使用されます。Oracle Streamsでは、新しい取得プロセスと共有されるLogMinerデータ・ディクショナリが自動的に選択されます。first_scn
パラメータがNULL
に設定されているため、新しい取得プロセスの開始SCNは、LogMinerデータ・ディクショナリを共有する既存の取得プロセスの先頭SCNと同じになります。この例では、既存の取得プロセスはcapture_simp
です。
ソース・データベースに対して行われたローカルな変更を取得する取得プロセスが作成されます。これは、source_database
パラメータがNULL
に設定されているためです。ローカル取得プロセスの場合は、このパラメータに対してローカル・データベースのグローバル名を指定することもできます。
注意: この例のプロシージャの実行時に、ローカル取得プロセスが存在していない場合は、取得プロセスの作成時に、DBMS_CAPTURE_ADM.BUILD プロシージャが自動的に実行され、データ・ディクショナリがREDOログに抽出されます。新しい取得プロセスの最初の起動時に、この取得プロセスでは、このREDOデータを使用してLogMinerデータ・ディクショナリが作成されます。この場合、指定するstart_scn パラメータ値は現行のデータベースSCN以上である必要があります。 |
必要に応じて、「取得プロセスの構成後に行う作業」で説明されている手順を実行します。
関連項目:
|
この項では、ダウンストリーム取得プロセスの準備と、リアルタイム・ダウンストリーム取得プロセスおよびアーカイブ・ログ・ダウンストリーム取得プロセスの構成について説明します。
この項の内容は次のとおりです。
ダウンストリーム・データベースにREDOデータを送信するためにソース・データベースを準備し、そのREDOデータを受け入れるようにダウンストリーム・データベースを準備するには、この項の手順を実行する必要があります。
ダウンストリーム・データベースにREDOデータを送信する準備として、次の手順を実行します。
「取得プロセスの構成準備」で説明されているタスクを実行します。
ソース・データベースがダウンストリーム・データベースと通信できるように、Oracle Netを構成します。
関連項目: Oracle Database Net Services管理者ガイド |
REDOデータの転送がサポートされるように両方のデータベースで認証を構成します。
REDO転送セッションは、Secure Sockets Layer(SSL)プロトコルまたはリモート・ログイン・パスワード・ファイルのいずれかを使用して認証されます。ソース・データベースにリモート・ログイン・パスワード・ファイルがある場合、このファイルは、ダウンストリーム取得データベース・システムの適切なディレクトリにコピーされます。パスワード・ファイルは、ソース・データベースとダウンストリーム取得データベースで同じである必要があります。
関連項目: REDO転送の認証要件の詳細は、Oracle Data Guard概要および管理を参照 |
ソース・データベースで、REDOデータをソース・データベースからダウンストリーム・データベースに送信するようにREDO転送サービスを構成するために、次の初期化パラメータを設定します。
LOG_ARCHIVE_DEST_
n
: ダウンストリーム・データベースにREDOデータを送信するように1つ以上のLOG_ARCHIVE_DEST_
n
初期化パラメータを設定します。これを行うには、このパラメータの次の属性を設定します。
SERVICE
: ダウンストリーム・データベースのネットワーク・サービス名を指定します。
ASYNC
またはSYNC
: REDO転送モードを指定します。
ASYNC
を指定するメリットは、ソース・データベースのパフォーマンスへの影響が、ほとんどまたはまったくないことです。ソース・データベースでOracle Database 10gリリース1以上が実行されている場合に、ダウンストリーム・データベースまたはネットワークのパフォーマンスが低いときは、ASYNC
を使用してソース・データベースのパフォーマンスへの影響を回避することをお薦めします。
SYNC
を指定するメリットは、ASYNC
を指定した場合より速くREDOデータがダウンストリーム・データベースに送信されることです。また、SYNC
AFFIRM
を指定すると、MAXIMUM
AVAILABILITY
スタンバイ保護モードと同様の動作になります。ALTER
DATABASE
STANDBY
DATABASE
TO
MAXIMIZE
AVAILABILITY
SQL文を指定しても、Oracle Streamsの取得プロセスには影響しないことに注意してください。
NOREGISTER
: アーカイブREDOログ・ファイルの場所がダウンストリーム・データベース制御ファイルに記録されないようにこの属性を指定します。
VALID_FOR
: (ONLINE_LOGFILE,PRIMARY_ROLE)
または(ONLINE_LOGFILE,ALL_ROLES)
を指定します。
TEMPLATE
: アーカイブ・ログ・ダウンストリーム取得プロセスを構成している場合は、ダウンストリーム・データベースのアーカイブREDOログのディレクトリおよび書式テンプレートを指定します。TEMPLATE
属性は、ダウンストリーム・データベースのLOG_ARCHIVE_FORMAT
初期化パラメータ設定より優先されます。TEMPLATE
属性は、リモートの宛先でのみ有効です。各ソース・データベースで、書式に%t
、%s
および%r
のすべての変数が使用されるようにしてください。
リアルタイム・ダウンストリーム取得プロセスを構成している場合は、TEMPLATE
属性を指定しないでください。
DB_UNIQUE_NAME
: ダウンストリーム・データベースの一意の名前。ダウンストリーム・データベースでDB_UNIQUE_NAME
初期化パラメータに指定した名前を使用します。
次の例は、リアルタイム・ダウンストリーム取得プロセスのダウンストリーム・データベースを指定するLOG_ARCHIVE_DEST_
n
設定です。
LOG_ARCHIVE_DEST_2='SERVICE=DBS2.EXAMPLE.COM ASYNC NOREGISTER VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=dbs2'
次の例は、アーカイブ・ログ・ダウンストリーム取得プロセスのダウンストリーム・データベースを指定するLOG_ARCHIVE_DEST_
n
設定です。
LOG_ARCHIVE_DEST_2='SERVICE=DBS2.EXAMPLE.COM ASYNC NOREGISTER VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) TEMPLATE=/usr/oracle/log_for_dbs1/dbs1_arch_%t_%s_%r.log DB_UNIQUE_NAME=dbs2'
ヒント: TEMPLATE 属性に、リモート・ソース・データベースのログ・ファイルを、ローカル・データベースのログ・ファイルとは別に格納する値を指定します。また、ダウンストリーム・データベースに複数のソース・データベースからのログ・ファイルが含まれている場合は、各ソース・データベースからのログ・ファイルを個別に格納する必要があります。 |
LOG_ARCHIVE_DEST_STATE_
n
: ダウンストリーム・データベースのLOG_ARCHIVE_DEST_STATE_
n
パラメータに対応する初期化パラメータをENABLE
に設定します。
たとえば、ダウンストリーム・データベースにLOG_ARCHIVE_DEST_2
初期化パラメータが設定されている場合、LOG_ARCHIVE_DEST_STATE_2
パラメータを次のように設定します。
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_CONFIG
: ソース・データベースおよびダウンストリーム・データベースのDB_UNIQUE_NAME
を含むように、この初期化パラメータのDB_CONFIG
属性を設定します。
たとえば、ソース・データベースのDB_UNIQUE_NAME
がdbs1
で、ダウンストリーム・データベースのDB_UNIQUE_NAME
がdbs2
の場合は、次のパラメータを指定します。
LOG_ARCHIVE_CONFIG='DG_CONFIG=(dbs1,dbs2)'
LOG_ARCHIVE_CONFIG
パラメータは、デフォルトでデータベースによるREDOの送受信を可能にします。
関連項目: これらの初期化パラメータの詳細は、Oracle DatabaseリファレンスおよびOracle Data Guard概要および管理を参照 |
ダウンストリーム・データベースで、ソース・データベースおよびダウンストリーム・データベースのDB_UNIQUE_NAME
を含むように、LOG_ARCHIVE_CONFIG
初期化パラメータのDB_CONFIG
属性を設定します。
たとえば、ソース・データベースのDB_UNIQUE_NAME
がdbs1
で、ダウンストリーム・データベースのDB_UNIQUE_NAME
がdbs2
の場合は、次のパラメータを指定します。
LOG_ARCHIVE_CONFIG='DG_CONFIG=(dbs1,dbs2)'
LOG_ARCHIVE_CONFIG
パラメータは、デフォルトでデータベースによるREDOの送受信を可能にします。
手順4または手順5で、データベースでのインスタンスの実行中にいずれかの初期化パラメータをリセットした場合は、データベースの再起動時に新しい値が維持されるように、初期化パラメータ・ファイルでもそれらのパラメータをリセットする必要がある場合があります。
手順4または手順5で、インスタンスの実行中に初期化パラメータをリセットせずに、初期化パラメータ・ファイルでリセットした場合は、データベースを再起動します。ソース・データベースのグローバル名は、ソース・データベースがオープンな場合にのみダウンストリーム・データベースに送信されるため、ダウンストリーム・データベースにREDOログ・ファイルを送信するときには、ソース・データベースがオープンである必要があります。
次のそれぞれの項で手順を実行します。
ダウンストリーム取得を実行する取得プロセスを作成するには、CREATE_CAPTURE
プロシージャを使用する必要があります。この項の例では、ソース・データベースへのデータベース・リンクを使用するリアルタイム・ダウンストリーム取得プロセスの作成について説明します。ただし、リアルタイム・ダウンストリーム取得プロセスでは、データベース・リンクが使用されない場合があります。
この項の例では、次のことが想定されています。
ソース・データベースはdbs1.example.com
で、ダウンストリーム・データベースはdbs2.example.com
です。
dbs2.example.com
で作成される取得プロセスでは、streams_queue
が使用されます。
取得プロセスでは、hr.departments
表に対するDML変更が取得されます。
この項の内容は次のとおりです。
注意: 1つのダウンストリーム・データベースで使用可能なリアルタイム・ダウンストリーム取得プロセスは1つのみです。 |
次の手順を実行して、スタンバイREDOログをダウンストリーム・データベースに追加します。
「ダウンストリーム・データベースへのREDOデータの送信準備」の手順を実行します。
ダウンストリーム・データベースで、ローカルに生成されたREDOデータのアーカイブを構成するように次の初期化パラメータを設定します。
LOG_ARCHIVE_DEST_
n
初期化パラメータで、少なくとも1つのアーカイブ・ログの保存先を、ダウンストリーム・データベースを実行しているコンピュータ・システム上のディレクトリまたはフラッシュ・リカバリ領域に設定します。これを設定するには、このパラメータの次の属性を設定します。
LOCATION
: ディスク・ディレクトリの有効なパス名またはUSE_DB_RECOVERY_FILE_DEST
を指定します。LOCATION
属性に指定する各宛先は、一意のディレクトリ・パス名またはUSE_DB_RECOVERY_FILE_DEST
である必要があります。これは、ローカル・データベースによって生成されたアーカイブREDOログ・ファイルのローカルの宛先です。
VALID_FOR
: (ONLINE_LOGFILE,PRIMARY_ROLE)
または(ONLINE_LOGFILE,ALL_ROLES)
を指定します。
次の例は、リアルタイム・ダウンストリーム取得データベースでローカルに生成されたREDOデータのLOG_ARCHIVE_DEST_
n
設定です。
LOG_ARCHIVE_DEST_1='LOCATION=/home/arc_dest/local_rl_dbs2 VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE)'
リアルタイム・ダウンストリーム取得構成では、アーカイブ・スタンバイREDOログ・ファイルを、ダウンストリーム・データベースからアーカイブされるオンラインREDOログ・ファイルとは別に保持する必要があります。これを行うには、VALID_FOR
属性のREDOログ・タイプにALL_LOGFILES
ではなく、ONLINE_LOGFILE
を指定します。
必要に応じて、LOG_ARCHIVE_DEST_
n
初期化パラメータの他の属性も指定できます。
この手順で設定済のLOG_ARCHIVE_DEST_
n
パラメータに対応するLOG_ARCHIVE_DEST_STATE_
n
初期化パラメータをENABLE
に設定します。
たとえば、LOG_ARCHIVE_DEST_1
初期化パラメータが設定されている場合、LOG_ARCHIVE_DEST_STATE_1
パラメータを次のように設定します。
LOG_ARCHIVE_DEST_STATE_1=ENABLE
ダウンストリーム・データベースで、ダウンストリーム・データベースがソース・データベースからREDOデータを受信し、ダウンストリーム・データベースのスタンバイREDOログにそのREDOデータを書き込むように、次の初期化パラメータを設定します。
LOG_ARCHIVE_DEST_
n
初期化パラメータで、少なくとも1つのアーカイブ・ログの保存先を、ダウンストリーム・データベースを実行しているコンピュータ・システム上のディレクトリまたはフラッシュ・リカバリ領域に設定します。これを設定するには、このパラメータの次の属性を設定します。
LOCATION
: ディスク・ディレクトリの有効なパス名またはUSE_DB_RECOVERY_FILE_DEST
を指定します。LOCATION
属性に指定する各宛先は、一意のディレクトリ・パス名またはUSE_DB_RECOVERY_FILE_DEST
である必要があります。これは、スタンバイREDOログから書き込まれるアーカイブREDOログ・ファイルのローカルの宛先です。リモート・ソース・データベースからのログ・ファイルは、ローカル・データベースのログ・ファイルとは別に保持するようにしてください。
VALID_FOR
: (STANDBY_LOGFILE,PRIMARY_ROLE)
または(STANDBY_LOGFILE,ALL_ROLES)
を指定します。
次の例は、リアルタイム・ダウンストリーム取得データベースでソース・データベースから受信されたREDOデータのLOG_ARCHIVE_DEST_
n
設定です。
LOG_ARCHIVE_DEST_2='LOCATION=/home/arc_dest/srl_dbs1 VALID_FOR=(STANDBY_LOGFILE,PRIMARY_ROLE)'
必要に応じて、LOG_ARCHIVE_DEST_
n
初期化パラメータの他の属性も指定できます。
この手順で設定済のLOG_ARCHIVE_DEST_
n
パラメータに対応するLOG_ARCHIVE_DEST_STATE_
n
初期化パラメータをENABLE
に設定します。
たとえば、ダウンストリーム・データベースにLOG_ARCHIVE_DEST_2
初期化パラメータが設定されている場合、LOG_ARCHIVE_DEST_STATE_2
パラメータを次のように設定します。
LOG_ARCHIVE_DEST_STATE_2=ENABLE
関連項目: これらの初期化パラメータの詳細は、Oracle DatabaseリファレンスおよびOracle Data Guard概要および管理を参照 |
ステップ2または3で、データベースのインスタンスが実行中に初期化パラメータをリセットした場合、該当する初期化パラメータ・ファイルでもそれをリセットすれば、データベースの再起動時に新しい値が維持されます。
Step ステップ2または3で、インスタンスの実行中には初期化パラメータをリセットしなかったが、初期化パラメータ・ファイルでリセットした場合は、データベースを再起動します。ソース・データベースのグローバル名は、ソース・データベースがオープンな場合にのみダウンストリーム・データベースに送信されるため、ダウンストリーム・データベースにREDOデータを送信するときには、ソース・データベースがオープンである必要があります。
スタンバイREDOログ・ファイルを作成します。
注意: 次に、スタンバイREDOログ・ファイルをダウンストリーム・データベースに追加する一般的な手順の概要を示します。スタンバイREDOログ・ファイルの追加に使用する実際の手順とSQL文は、環境によって異なります。たとえば、Oracle Real Application Clusters(Oracle RAC)環境では手順が異なります。スタンバイREDOログ・ファイルをデータベースに追加する手順の詳細は、Oracle Data Guard概要および管理を参照してください。 |
SQL*Plusで、ソース・データベースdbs1.example.com
に管理ユーザーとして接続します。
SQL*Plusでデータベースに接続する方法については、Oracle Database管理者ガイドを参照してください。
ソース・データベースで使用するログ・ファイルのサイズを決定します。スタンバイ・ログ・ファイルのサイズは、ソース・データベースのログ・ファイル・サイズと正確に同じか、またはそれより大きくなるようにします。たとえば、ソース・データベースのログ・ファイル・サイズが500MBの場合は、スタンバイ・ログ・ファイルのサイズも500MB以上にします。ソース・データベースにおけるREDOログ・ファイルのサイズ(バイト単位)は、ソース・データベースでV$LOG
ビューを問い合せて確認することができます。
たとえば、V$LOG
ビューを問い合せます。
SELECT BYTES FROM V$LOG;
ダウンストリーム・データベースで必要なスタンバイ・ログ・ファイル・グループの数を決定します。スタンバイ・ログ・ファイル・グループの数は、ソース・データベースでのオンライン・ログ・ファイル・グループの数より1以上大きくする必要があります。たとえば、ソース・データベースに2つのオンライン・ログ・ファイル・グループがある場合、ダウンストリーム・データベースには3つ以上のスタンバイ・ログ・ファイル・グループが必要です。ソース・データベースのオンライン・ログ・ファイル・グループの数は、ソース・データベースでV$LOG
ビューを問い合せて確認することができます。
たとえば、V$LOG
ビューを問い合せます。
SELECT COUNT(GROUP#) FROM V$LOG;
SQL*Plusで、ダウンストリーム・データベースdbs2.example.com
に管理ユーザーとして接続します。
SQL文、ALTER
DATABASE
ADD
STANDBY
LOGFILE
を使用して、ダウンストリーム・データベースにスタンバイ・ログ・ファイル・グループを追加します。
たとえば、ソース・データベースに2つのオンラインREDOログ・ファイル・グループがあり、サイズが500MBのログ・ファイルを使用しているとします。この場合は、次の文を使用して適切なスタンバイ・ログ・ファイル・グループを作成します。
ALTER DATABASE ADD STANDBY LOGFILE GROUP 3 ('/oracle/dbs/slog3a.rdo', '/oracle/dbs/slog3b.rdo') SIZE 500M; ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 ('/oracle/dbs/slog4.rdo', '/oracle/dbs/slog4b.rdo') SIZE 500M; ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 ('/oracle/dbs/slog5.rdo', '/oracle/dbs/slog5b.rdo') SIZE 500M;
次の問合せを実行して、スタンバイ・ログ・ファイル・グループが正常に追加されたことを確認します。
SELECT GROUP#, THREAD#, SEQUENCE#, ARCHIVED, STATUS FROM V$STANDBY_LOG;
出力は次のようになります。
GROUP# THREAD# SEQUENCE# ARC STATUS ---------- ---------- ---------- --- ---------- 3 0 0 YES UNASSIGNED 4 0 0 YES UNASSIGNED 5 0 0 YES UNASSIGNED
この項では、DBMS_CAPTURE_ADM
パッケージのCREATE_CAPTURE
プロシージャを実行して、dbs1.example.com
ソース・データベースで行われた変更を取得するアーカイブ・ログ・ダウンストリーム取得プロセスをdbs2.example.com
ダウンストリーム・データベースに作成する例を示します。この例の取得プロセスでは、管理の目的でdbs1.example.com
へのデータベース・リンクを使用しています。
次の手順を実行します。
SQL*Plusで、ダウンストリーム・データベースdbs2.example.com
にOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、Oracle Database管理者ガイドを参照してください。
dbs2.example.com
からdbs1.example.com
へのデータベース・リンクを作成します。たとえば、ユーザーstrmadmin
が両方のデータベースのOracle Streams管理者の場合は、次のデータベース・リンクを作成します。
CREATE DATABASE LINK dbs1.example.com CONNECT TO strmadmin
IDENTIFIED BY password
USING 'dbs1.example.com';
この例では、Oracle Streams管理者がソース・データベースdbs1.example.com
に存在していると想定されています。ソース・データベースにOracle Streams管理者が存在していない場合は、ダウンストリーム・データベース上のOracle Streams管理者が、Oracle Streams管理者によるリモート・アクセスを許可しているユーザーに接続する必要があります。このユーザーのリモート・アクセスは、ソース・データベースでDBMS_STREAMS_AUTH
パッケージのGRANT_REMOTE_ADMIN_ACCESS
プロシージャを実行する際にユーザーを権限受領者に指定することによって有効にできます。
CREATE_CAPTURE
プロシージャを実行して、取得プロセスを作成します。
BEGIN DBMS_CAPTURE_ADM.CREATE_CAPTURE( queue_name => 'strmadmin.streams_queue', capture_name => 'real_time_capture', rule_set_name => NULL, start_scn => NULL, source_database => 'dbs1.example.com', use_database_link => TRUE, first_scn => NULL, logfile_assignment => 'implicit'); END; /
このプロシージャを実行すると、次のアクションが実行されます。
ダウンストリーム・データベースdbs2.example.com
にreal_time_capture
という名前の取得プロセスが作成されます。この場合、同じ名前の取得プロセスが存在していない必要があります。
取得プロセスがdbs2.example.com上のstreams_queueという名前の既存のキュー
に関連付けられます。
取得プロセスによって取得される変更のソース・データベースがdbs1.example.com
になるように指定されます。
ソース・データベースで管理アクションを実行する場合に、ソース・データベースのグローバル名と同じ名前のデータベース・リンクが取得プロセスで使用されるように指定されます。
取得プロセスでdbs1.example.com
からのREDOデータが暗黙的に受け入れられるように指定されます。したがって、この取得プロセスでは、dbs2.example.com
のスタンバイREDOログがスキャンされ、取得する必要がある変更の有無が確認されます。取得プロセスでは、遅延が発生した場合、スタンバイ・REDOログから書き込まれたアーカイブREDOログ・ファイルがスキャンされます。
この手順では、取得プロセスreal_time_capture
をルール・セットに関連付けません。後の手順でルール・セットを作成して、取得プロセスに関連付けます。
dbs2.example.com
の他の取得プロセスでdbs1.example.com
ソース・データベースから変更が取得されていない場合は、データベース・リンクを使用してDBMS_CAPTURE_ADM.BUILD
プロシージャが自動的にdbs1.example.com
で実行されます。このプロシージャが実行されると、dbs1.example.com
のデータ・ディクショナリがREDOログに抽出され、dbs2.example.com
での取得プロセスreal_time_capture
の最初の起動時に、dbs1.example.com
のLogMinerデータ・ディクショナリがdbs2.example.com
に作成されます。
dbs2.example.com
の複数の取得プロセスでdbs1.example.com
ソース・データベースから変更が取得されている場合、新しい取得プロセスreal_time_capture
では既存のアーカイブ・ログ取得プロセスのいずれかと同じdbs1.example.com
のLogMinerデータ・ディクショナリが使用されます。Oracle Streamsでは、新しい取得プロセスと共有されるデータ・ディクショナリが自動的に選択されます。
注意:
|
downstream_real_time_mine
取得プロセス・パラメータをY
に設定します。
BEGIN DBMS_CAPTURE_ADM.SET_PARAMETER( capture_name => 'real_time_capture', parameter => 'downstream_real_time_mine', value => 'Y'); END; /
取得プロセスのポジティブ・ルール・セットを作成して、ルールを追加します。
BEGIN DBMS_STREAMS_ADM.ADD_TABLE_RULES( table_name => 'hr.departments', streams_type => 'capture', streams_name => 'real_time_capture', queue_name => 'strmadmin.streams_queue', include_dml => TRUE, include_ddl => FALSE, include_tagged_lcr => FALSE, source_database => 'dbs1.example.com', inclusion_rule => TRUE); END; /
このプロシージャを実行すると、次のアクションが実行されます。
dbs2.example.com
で取得プロセスreal_time_capture
用のルール・セットが作成されます。ルールには、システムで作成された名前が付けられます。inclusion_rule
パラメータがTRUE
に設定されているため、このルール・セットは取得プロセスのポジティブ・ルール・セットとなります。
hr.departments
表に対するDML変更を取得するルールが作成され、取得プロセスのポジティブ・ルール・セットに追加されます。ルールには、システムで生成された名前が付けられます。inclusion_rule
パラメータがTRUE
に設定されているため、このルールは取得プロセスのポジティブ・ルール・セットに追加されます。
手順2
で作成したデータベース・リンクを使用して、dbs1.example.com
でインスタンス化のためにhr.departments表が準備されます。
表のすべての主キー、一意キー、ビットマップ索引および外部キーの列に対してサプリメンタル・ロギングが有効にされます。
ログ・ファイルを切り替えるために必要な権限を持つ管理ユーザーとして、ソース・データベースdbs1.example.com
に接続されます。
現行のログ・ファイルがソース・データベースにアーカイブされます。
ALTER SYSTEM ARCHIVE LOG CURRENT;
現行のログ・ファイルがソース・データベースにアーカイブされると、ソース・データベースのREDOログのリアルタイム・マイニングが開始されます。
必要に応じて、「取得プロセスの構成後に行う作業」で説明されている手順を実行します。
この項では、ログ・ファイルを暗黙的または明示的に割り当てるアーカイブ・ログ・ダウンストリーム取得プロセスの構成について説明します。
この項の内容は次のとおりです。
ダウンストリーム取得を実行する取得プロセスを作成するには、CREATE_CAPTURE
プロシージャを使用する必要があります。この項の例では、ソース・データベースへのデータベース・リンクを管理の目的で使用するアーカイブ・ログ・ダウンストリーム取得プロセスの作成について説明します。
この項の例では、次のことが想定されています。
ソース・データベースはdbs1.example.com
で、ダウンストリーム・データベースはdbs2.example.com
です。
dbs2.example.com
で作成される取得プロセスでは、strmadmin
が所有するstreams_queue
が使用されます。
取得プロセスは、dbs1.example.com
でhr.departments
表に行われたDML変更を取得します。
この取得プロセスでは、ログ・ファイルを暗黙的に割り当てます。つまり、REDO転送サービスまたは手動でソース・データベースからダウンストリーム・データベースに追加されたすべてのREDOログ・ファイルがダウンストリーム取得プロセスによって自動的にスキャンされます。
次の手順を実行します。
「ダウンストリーム・データベースへのREDOデータの送信準備」の手順を実行します。
SQL*Plusで、ダウンストリーム・データベースdbs2.example.com
にOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、Oracle Database管理者ガイドを参照してください。
dbs2.example.com
からdbs1.example.com
へのデータベース・リンクを作成します。たとえば、ユーザーstrmadmin
が両方のデータベースのOracle Streams管理者の場合は、次のデータベース・リンクを作成します。
CREATE DATABASE LINK dbs1.example.com CONNECT TO strmadmin
IDENTIFIED BY password
USING 'dbs1.example.com';
この例では、Oracle Streams管理者がソース・データベースdbs1.example.com
に存在していると想定されています。ソース・データベースにOracle Streams管理者が存在していない場合は、ダウンストリーム・データベース上のOracle Streams管理者が、Oracle Streams管理者によるリモート・アクセスを許可しているユーザーに接続する必要があります。このユーザーのリモート・アクセスは、ソース・データベースでDBMS_STREAMS_AUTH
パッケージのGRANT_REMOTE_ADMIN_ACCESS
プロシージャを実行する際にユーザーを権限受領者に指定することによって有効にできます。
CREATE_CAPTURE
プロシージャを実行して、取得プロセスを作成します。
BEGIN DBMS_CAPTURE_ADM.CREATE_CAPTURE( queue_name => 'strmadmin.streams_queue', capture_name => 'strm04_capture', rule_set_name => NULL, start_scn => NULL, source_database => 'dbs1.example.com', use_database_link => TRUE, first_scn => NULL, logfile_assignment => 'implicit'); END; /
このプロシージャを実行すると、次のアクションが実行されます。
ダウンストリーム・データベースdbs2.example.com
にstrm04_capture
という名前の取得プロセスが作成されます。この場合、同じ名前の取得プロセスが存在していない必要があります。
取得プロセスがdbs2.example.com
上のstreams_queue
という名前の既存のキューに関連付けられます。
取得プロセスによって取得される変更のソース・データベースがdbs1.example.com
になるように指定されます。
取得プロセスでdbs1.example.com
からの新しいREDOログ・ファイルが暗黙的に受け入れられるように指定されます。したがって、この取得プロセスでは、dbs1.example.com
からdbs2.example.com
にコピーされたすべての新しいログ・ファイルがスキャンされ、取得する必要がある変更の有無が確認されます。
この手順では、取得プロセスstrm04_capture
をルール・セットに関連付けません。次の手順でルール・セットを作成して、取得プロセスに関連付けます。
dbs2.example.com
の他の取得プロセスがdbs1.example.com
ソース・データベースからの変更を取得していない場合は、データベース・リンクを使用してDBMS_CAPTURE_ADM.BUILD
プロシージャが自動的にdbs1.example.com
で実行されます。このプロシージャが実行されると、dbs1.example.com
のデータ・ディクショナリがREDOログに抽出され、dbs2.example.com
での取得プロセスの最初の起動時に、dbs1.example.com
のLogMinerデータ・ディクショナリが dbs2.example.com
に作成されます。
dbs2.example.com
の複数の取得プロセスでdbs1.example.com
ソース・データベースから変更が取得されている場合、新しい取得プロセスでは既存の取得プロセスのいずれかと同じdbs1.example.com
のLogMinerデータ・ディクショナリが使用されます。Oracle Streamsでは、新しい取得プロセスと共有されるデータ・ディクショナリが自動的に選択されます。
注意: ダウンストリーム取得プロセスの作成時、CREATE_CAPTURE プロシージャのfirst_scn パラメータがNULL に設定されている場合は、use_database_link パラメータをTRUE に設定する必要があります。TRUEに設定しないと、エラーが発生します。 |
関連項目:
|
取得プロセスのポジティブ・ルール・セットを作成して、ルールを追加します。
BEGIN DBMS_STREAMS_ADM.ADD_TABLE_RULES( table_name => 'hr.departments', streams_type => 'capture', streams_name => 'strm04_capture', queue_name => 'strmadmin.streams_queue', include_dml => TRUE, include_ddl => FALSE, include_tagged_lcr => FALSE, source_database => 'dbs1.example.com', inclusion_rule => TRUE); END; /
このプロシージャを実行すると、次のアクションが実行されます。
dbs2.example.com
で取得プロセスstrm04_capture
用のルール・セットが作成されます。ルールには、システムで生成された名前が付けられます。inclusion_rule
パラメータがTRUE
に設定されているため、このルール・セットは取得プロセスのポジティブ・ルール・セットとなります。
hr.departments
表に対するDML変更を取得するルールが作成され、取得プロセスのルール・セットに追加されます。ルールには、システムで生成された名前が付けられます。inclusion_rule
パラメータがTRUE
に設定されているため、このルールは取得プロセスのポジティブ・ルール・セットに追加されます。
必要に応じて、「取得プロセスの構成後に行う作業」で説明されている手順を実行します。
ダウンストリーム取得を実行する取得プロセスを作成するには、CREATE_CAPTURE
プロシージャを使用する必要があります。この項では、REDOログ・ファイルを明示的に割り当てるアーカイブ・ログ・ダウンストリーム取得プロセスの作成について説明します。ここでは、DBMS_FILE_TRANSFER
パッケージ、FTPまたはその他の方法を使用して、ソース・データベースからダウンストリーム・データベースにREDOログ・ファイルを転送し、次に、それらのREDOログ・ファイルをダウンストリーム取得プロセスに手動で登録する必要があります。
この項の例では、次のことが想定されています。
ソース・データベースはdbs1.example.com
で、ダウンストリーム・データベース は dbs2.example.comです。
dbs2.example.com
で作成される取得プロセスでは、streams_queue
が使用されます。
取得プロセスでは、hr.departments
表に対するDML変更が取得されます。
この取得プロセスでは、管理アクションのためにソース・データベースへのデータベース・リンクは使用されません。
REDO転送サービスでは、アーカイブREDOログ・ファイルは自動的にダウンストリーム取得データベースに転送されません。かわりに、各ファイルは手動で転送されます。
次の手順を実行します。
SQL*Plusで、ソース・データベースdbs1.example.com
にOracle Streams管理者として接続します。
ダウンストリーム・データベースからソース・データベースへのデータベース・リンクを使用しない場合は、ソース・データベースにOracle Streams管理者が存在している必要があります。
SQL*Plusでデータベースに接続する方法については、Oracle Database管理者ガイドを参照してください。
dbs1.example.com
から変更を取得する取得プロセスがdbs2.example.com
に存在しない場合は、REDOログ内のdbs1.example.com
データ・ディクショナリのビルドを実行します。dbs1.example.com
ソース・データベースから変更を取得するようにdbs2.example.com
の取得プロセスがすでに構成されている場合、この手順はオプションとなります。
SET SERVEROUTPUT ON DECLARE scn NUMBER; BEGIN DBMS_CAPTURE_ADM.BUILD( first_scn => scn); DBMS_OUTPUT.PUT_LINE('First SCN Value = ' || scn); END; / First SCN Value = 409391
このプロシージャによって、dbs2.example.com
に作成される取得プロセスの有効な先頭SCN値が表示されます。戻されたSCN値を書き留めます。この値は、dbs2.example.com
に取得プロセスを作成するときに使用します。
このプロシージャを実行してREDOログにデータ・ディクショナリをビルドすると、dbs2.example.com
での取得プロセスの最初の起動時に、この取得プロセスでは、REDOログ内のデータ・ディクショナリ情報を使用してLogMinerデータ・ディクショナリが作成されます。
インスタンス化のためにhr.departments
表を準備します。
BEGIN DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION( table_name => 'hr.departments', supplemental_logging => 'keys'); END; /
この例ではhr.departments
表に対する変更を取得する取得プロセスを作成するため、この表の主キーのサプリメンタル・ロギングが必要となります。PREPARE_TABLE_INSTANTIATION
プロシージャ内のsupplemental_logging
パラメータにkeys
を指定すると、表内のすべての主キー、一意キー、ビットマップ索引および外部キー列に対するサプリメンタル・ロギングが有効になります。
ソース・データベースの現行のSCNを判別します。
SET SERVEROUTPUT ON SIZE 1000000 DECLARE iscn NUMBER; -- Variable to hold instantiation SCN value BEGIN iscn := DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER(); DBMS_OUTPUT.PUT_LINE('Current SCN: ' || iscn); END; /
戻されたSCNは、作成される取得プロセスによって取得される変更をhr.departments
表に適用する宛先データベースのインスタンス化SCNとして使用できます。この例では、戻されたSCNが1001656
であると想定されています。
ダウンストリーム・データベースdbs2.example.com
にOracle Streams管理者として接続します。
CREATE_CAPTURE
プロシージャを実行して取得プロセスを作成し、手順2で取得した値をfirst_scn
パラメータに指定します。
BEGIN DBMS_CAPTURE_ADM.CREATE_CAPTURE( queue_name => 'strmadmin.streams_queue', capture_name => 'strm05_capture', rule_set_name => NULL, start_scn => NULL, source_database => 'dbs1.example.com', use_database_link => FALSE, first_scn => 409391, -- Use value from Step 2 logfile_assignment => 'explicit'); END; /
このプロシージャを実行すると、次のアクションが実行されます。
ダウンストリーム・データベースdbs2.example.com
にstrm05_capture
という名前の取得プロセスが作成されます。この場合、同じ名前の取得プロセスが存在していない必要があります。
取得プロセスがdbs2.example.com
上のstreams_queue
という名前の既存のキューに関連付けられます。
取得プロセスによって取得される変更のソース・データベースがdbs1.example.com
になるように指定されます。
先頭SCNが409391
になるように指定されます。この値は手順2で取得されました。先頭SCNは、取得プロセスで変更を取得できる最小SCNです。先頭SCNが指定されているため、同じソース・データベース用の既存のLogMinerデータ・ディクショナリが存在しているかどうかに関係なく、取得プロセスの最初の起動時に、取得プロセスによって新しいLogMinerデータ・ディクショナリが作成されます。
dbs1.example.com
からの新しいREDOログ・ファイルが取得プロセスに明示的に割り当てられるように指定されます。ダウンストリーム・データベースが実行されているコンピュータにREDOログ・ファイルが転送された後、次のDDL文を使用してそのログ・ファイルを取得プロセスに明示的に割り当てます。
ALTER DATABASE REGISTER LOGICAL LOGFILE file_name FOR capture_process;
ここで、file_name
はREDOログ・ファイルの名前、capture_process
はダウンストリーム・データベースでそのREDOログ・ファイルを使用する取得プロセスの名前です。logfile_assignment
パラメータがexplicit
に設定されている場合は、REDOログ・ファイルを手動で追加する必要があります。
この手順では、取得プロセスstrm05_capture
をルール・セットに関連付けません。次の手順でルール・セットを作成して、取得プロセスに関連付けます。
関連項目:
|
取得プロセスのポジティブ・ルール・セットを作成して、ルールを追加します。
BEGIN DBMS_STREAMS_ADM.ADD_TABLE_RULES( table_name => 'hr.departments', streams_type => 'capture', streams_name => 'strm05_capture', queue_name => 'strmadmin.streams_queue', include_dml => TRUE, include_ddl => FALSE, include_tagged_lcr => FALSE, source_database => 'dbs1.example.com', inclusion_rule => TRUE); END; /
このプロシージャを実行すると、次のアクションが実行されます。
dbs2.example.com
で取得プロセスstrm05_capture
用のルール・セットが作成されます。ルールには、システムで生成された名前が付けられます。inclusion_rule
パラメータがTRUE
に設定されているため、このルール・セットは取得プロセスのポジティブ・ルール・セットとなります。
hr.departments
表に対するDML変更を取得するルールが作成され、取得プロセスのルール・セットに追加されます。ルールには、システムで生成された名前が付けられます。inclusion_rule
パラメータがTRUE
に設定されているため、このルールは取得プロセスのポジティブ・ルール・セットに追加されます。
ダウンストリーム取得プロセスの先頭SCNが含まれているソース・データベースdbs1.example.com
のREDOログ・ファイルがアーカイブされた後、アーカイブREDOログ・ファイルをダウンストリーム・データベースが実行されているコンピュータに転送します。手順2のBUILD
プロシージャによって、ダウンストリーム取得プロセスの先頭SCNが判別されました。REDOログ・ファイルがアーカイブされていない場合は、データベースでALTER
SYSTEM
SWITCH
LOGFILE
文を実行するとアーカイブできます。
次の問合せをdbs1.example.com
で実行すると、ダウンストリーム取得プロセスの先頭SCNアーカイブが含まれているREDOログ・ファイルを識別できます。
COLUMN NAME HEADING 'Archived Redo Log|File Name' FORMAT A50 COLUMN FIRST_CHANGE# HEADING 'First SCN' FORMAT 999999999 SELECT NAME, FIRST_CHANGE# FROM V$ARCHIVED_LOG WHERE FIRST_CHANGE# IS NOT NULL AND DICTIONARY_BEGIN = 'YES';
手順2で戻された先頭SCNと一致するFIRST_CHANGE#
を持つアーカイブREDOログ・ファイルをダウンストリーム取得プロセスが実行されているコンピュータに転送します。
ダウンストリーム・データベースdbs2.example.com
に管理ユーザーとして接続します。
転送されたREDOログ・ファイルを取得プロセスに割り当てます。たとえば、REDOログ・ファイルが/oracle/logs_from_dbs/1/10_486574859.dbf
の場合は、次の文を発行します。
ALTER DATABASE REGISTER LOGICAL LOGFILE '/oracle/logs_from_dbs1/1_10_486574859.dbf' FOR 'strm05_capture';
必要に応じて、「取得プロセスの構成後に行う作業」で説明されている手順を実行します。
新しい取得プロセスによって取得された論理変更レコード(LCR)を処理する伝播および適用プロセスを構成する場合は、次の順序で構成を実行します。
伝播および適用プロセスで必要となるキューを作成します。「キューの構成」を参照してください。
新しい取得プロセスによって取得されたLCRを伝播するすべての伝播を作成します。「ANYDATAキュー間でのOracle Streamsの伝播の作成」を参照してください。
新しい取得プロセスによって取得されたLCRをデキューするすべての適用プロセスを作成します。「適用プロセスの作成の概要」を参照してください。取得LCRを適用するように、各適用プロセスを構成します。
新しい取得プロセスによってすべての宛先データベースの変更が取得される表をインスタンス化します。インスタンス化の詳細は、Oracle Streamsレプリケーション管理者ガイドを参照してください。
新しい取得プロセスによって取得されたLCRを処理する適用プロセスを起動します。「適用プロセスの起動」を参照してください。
新しい取得プロセスを起動します。「取得プロセスの起動」を参照してください。
注意: 使用しているOracle Streams環境によっては、その他の構成手順が必要となる場合があります。たとえば、一部のOracle Streams環境では、変換、適用ハンドラ、競合解決などが含まれます。 |
同期取得を作成するには、次のいずれかのプロシージャを使用します。
DBMS_STREAMS_ADM.ADD_TABLE_RULES
DBMS_STREAMS_ADM.ADD_SUBSET_RULES
DBMS_CAPTURE_ADM.CREATE_SYNC_CAPTURE
DBMS_STREAMS_ADM
パッケージ内の両方のプロシージャでは、指定された名前を持つ同期取得が存在しない場合は同期取得が作成され、同期取得のポジティブ・ルール・セットが存在しない場合はポジティブ・ルール・セットがされます。また、ルール・セットに表ルールまたはサブセット・ルールを追加することもできます。
CREATE_SYNC_CAPTURE
プロシージャでは同期取得は作成されますが、同期取得のルール・セットおよびルールは作成されません。ただし、CREATE_SYNC_CAPTURE
プロシージャを使用すると、同期取得に関連付ける既存のルール・セットを指定できます。また、デフォルトの取得ユーザー以外の取得ユーザーを指定できます。
次の各項では、同期取得の構成について説明します。
注意:
|
関連項目:
|
同期取得を構成する前に、次のタスクを完了する必要があります。
同期取得が使用されるすべてのデータベースで初期化パラメータが適切に設定されていることを確認します。「Oracle Streamsに関連する初期化パラメータの設定」を参照してください。
Oracle Streams構成に関連するすべてのデータベースに、Oracle Streams管理者を作成します。詳細は、「Oracle Streams管理者の構成」を参照してください。この章の例では、Oracle Streams管理者はstrmadmin
であるとします。
ANYDATA
キューが存在しない場合は作成して同期取得に関連付けます。詳細は、「ANYDATAキューの作成」を参照してください。キューはコミット時間キューである必要があります。この章の例では、同期取得によって使用されるキューはstrmadmin.streams_queue
であるとします。このキューは、同期取得を実行するデータベースと同じデータベースに作成します。
新しい同期取得よって取得されたLCRを伝播するすべての伝播を作成します。「ANYDATAキュー間でのOracle Streamsの伝播の作成」を参照してください。
新しい同期取得によって取得されたLCRをデキューするすべての適用プロセスを作成します。「適用プロセスの作成の概要」を参照してください。DBMS_APPLY_ADM.CREATE_APPLY
プロシージャ内のapply_captured
パラメータをFALSE
に設定して、永続LCRを適用するように各適用プロセスを構成します。適用プロセスは、「同期取得の構成後に行う作業」で実行するインスタンス化が終了するまで起動しないでください。
ADD_TABLE_RULES
またはADD_SUBSET_RULES
プロシージャを実行して同期取得を作成する場合は、これらのプロシージャ内のstreams_type
パラメータをsync_capture
に設定します。同期取得は、ADD_TABLE_RULES
プロシージャで作成されたルールによって、表に対するすべてのDML変更を取得するように指示されます。また、ADD_SUBSET_RULES
プロシージャで作成されたルールによって、表に対するDML変更のサブセットを取得するように指示されます。
この項の例では、次のことが想定されています。
ソース・データベースはdbs1.example.com
です。
作成される同期取得では、strmadmin.streams_queue
が使用されます。
作成される同期取得では、hr.departments
表に対して行われたDML変更の結果が取得されます。
作成される同期取得の取得ユーザーは、Oracle Streams管理者strmadmin
です。
DBMS_STREAMS_ADM
パッケージを使用して同期取得を作成するには、次の手順を実行します。
「同期取得の構成準備」で説明されているタスクを実行します。
SQL*Plusで、dbs1.example.com
データベースにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、Oracle Database管理者ガイドを参照してください。
ADD_TABLE_RULES
またはADD_SUBSET_RULES
プロシージャを実行して、同期取得を作成します。次に例を示します。
BEGIN DBMS_STREAMS_ADM.ADD_TABLE_RULES( table_name => 'hr.departments', streams_type => 'sync_capture', streams_name => 'sync_capture', queue_name => 'strmadmin.streams_queue'); END; /
このプロシージャを実行すると、次のアクションが実行されます。
ソース・データベースにsync_capture
という名前の同期取得が作成されます。
同期取得を有効にします。同期取得は無効にできません。
同期取得が既存のstrmadmin.streams_queue
キューに関連付けられます。
同期取得のポジティブ・ルール・セットが作成されます。ルール・セットにはシステムで作成された名前が付けられます。
hr.departments
表に対するDML変更を取得するルールが作成され、同期取得のポジティブ・ルール・セットに追加されます。ルールにはシステムで生成された名前が付けられます。
プロシージャを実行するユーザーが同期取得の取得ユーザーとして構成されます。
表に対してDBMS_CAPTURE_ADM.PREPARE_SYNC_INSTANTIATION
ファンクションを実行することによって、指定された表がインスタンス化のために準備されます。
必要に応じて、「同期取得の構成後に行う作業」で説明されている手順を実行します。
注意: ADD_TABLE_RULES プロシージャまたはADD_SUBSET_RULES プロシージャでルールが同期取得のルール・セットに追加される場合、プロシージャは指定した表の排他ロックを取得する必要があります。指定した表に処理中のトランザクションがある場合、プロシージャはロックを取得できるまで待機します。 |
この項では、DBMS_CAPTURE_ADM
パッケージおよびDBMS_STREAMS_ADM
パッケージ内のプロシージャを実行して同期取得を構成する例を示します。
この項の例では、次のことが想定されています。
ソース・データベースはdbs1.example.com
です。
作成される同期取得では、strmadmin.streams_queue
が使用されます。
作成される同期取得では、strmadmin
スキーマのsync01_rule_set
という名前の既存のルール・セットが使用されます。「ルール・セットの作成」を参照してください。
作成される同期取得では、hr.departments
表に対して行われたDML変更のサブセットの結果が取得されます。
作成される同期取得の取得ユーザーはhr
です。hr
ユーザーはstreams_queue
へのエンキューを行う権限を持っている必要があります。
DBMS_CAPTURE_ADM
パッケージを使用して同期取得を作成するには、次の手順を実行します。
「同期取得の構成準備」で説明されているタスクを実行します。
SQL*Plusで、dbs1.example.com
データベースにOracle Streams管理者として接続します。
SQL*Plusでデータベースに接続する方法については、Oracle Database管理者ガイドを参照してください。
CREATE_SYNC_CAPTURE
プロシージャを実行して、同期取得を作成します。次に例を示します。
BEGIN DBMS_CAPTURE_ADM.CREATE_SYNC_CAPTURE( queue_name => 'strmadmin.streams_queue', capture_name => 'sync01_capture', rule_set_name => 'strmadmin.sync01_rule_set', capture_user => 'hr'); END; /
このプロシージャを実行すると、次のアクションが実行されます。
ADD_TABLE_RULES
またはADD_SUBSET_RULES
プロシージャを実行して同期取得のルール・セットにルールを追加します。たとえば、ADD_SUBSET_RULES
プロシージャを実行して、hr.departments
表に対するDML変更のサブセットを取得するように同期取得に指示します。
BEGIN DBMS_STREAMS_ADM.ADD_SUBSET_RULES( table_name => 'hr.departments', dml_condition => 'department_id=1700', streams_type => 'sync_capture', streams_name => 'sync01_capture', queue_name => 'streams_queue', include_tagged_lcr => FALSE); END; /
このプロシージャを実行すると、次のアクションが実行されます。
ソース・データベースdbs1.example.com
のsync01_capture
という名前の同期取得のルール・セットにサブセット・ルールが追加されます。同期取得は、サブセット・ルールによって、department_id
が1700
の行に対する変更を取得するよう指示されます。この同期取得では、同じ表の他の行に対する変更は取得されません。
表に対してDBMS_CAPTURE_ADM.PREPARE_SYNC_INSTANTIATION
ファンクションを自動的に実行することで、インスタンス化用にhr.departments
表を準備します。
変更が行われるセッションにNULL
タグが含まれている場合にのみ、同期取得によって変更が取得されるように指定されます。これは、include_tagged_lcr
パラメータがFALSE
に設定されているためです。この動作は、同期取得のシステム作成ルールによって実行されます。
必要に応じて、「同期取得の構成後に行う作業」で説明されている手順を実行します。
注意: CREATE_SYNC_CAPTURE プロシージャでは、同期取得を作成する場合、変更を取得する各表に対して排他ロックを取得する必要があります。これらの表は、同期取得の指定されたルール・セット内のルールによって判別されます。同様に、ADD_TABLE_RULES またはADD_SUBSET_RULES プロシージャでは、同期取得のルール・セットにルールを追加する場合、指定された表に対して排他ロックを取得する必要があります。これらのプロシージャは、同期取得によって変更が取得される表に未処理のトランザクションがある場合、ロックを取得できるまで待機します。 |
新しい取得プロセスによって取得されたLCRを処理する伝播および適用プロセスを構成した場合は、次の手順を実行します。
新しい同期取得によってすべての宛先データベースの変更が取得される表をインスタンス化します。インスタンス化の詳細は、Oracle Streamsレプリケーション管理者ガイドを参照してください。
同期取得によって取得されたLCRを処理する適用プロセスを起動します。「適用プロセスの起動」を参照してください。
注意: 使用しているOracle Streams環境によっては、その他の構成手順が必要となる場合があります。たとえば、一部のOracle Streams環境では、変換、適用ハンドラ、競合解決などが含まれます。 |