ヘッダーをスキップ
Oracle Streams概要および管理
11g リリース1(11.1)
E05775-02
  目次
目次
索引
索引

前へ
前へ
 
次へ
次へ
 

10 暗黙的取得の構成

暗黙的取得とは、データベースの変更が自動的に取得され、エンキューされることを意味します。暗黙的取得は、取得プロセスまたは同期取得を使用して実行できます。取得プロセスではREDOログ内の変更が取得され、同期取得では内部メカニズムを使用してDMLの変更が取得されます。取得プロセスおよび同期取得の両方で、取得された変更は論理変更レコード(LCR)に再フォーマットされ、そのLCRがANYDATAキューにエンキューされます。

次の各項では、暗黙的取得の構成について説明します。

この章で説明する各タスクは、特に明記されていないかぎり、適切な権限を付与されているOracle Streams管理者が完了する必要があります。

取得プロセスの構成

ソース・データベースでローカルに変更を取得するか、またはダウンストリーム・データベースでリモートに変更を取得する取得プロセスを作成できます。取得プロセスがダウンストリーム・データベースで実行されている場合は、ソース・データベースからのREDOデータがダウンストリーム・データベースにコピーされ、ダウンストリーム・データベースで取得プロセスによってREDOデータの変更が取得されます。

ローカル取得プロセスを作成するには、次のいずれかのプロシージャを使用します。

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の詳細は、「取得プロセスの作成」を参照してください。


注意:

  • DBMS_STREAMS_ADMパッケージまたはOracle Enterprise Manager内のプロシージャを使用すると、取得プロセスを含むOracle Streams環境全体を構成できます。

  • 取得プロセスの作成後、その取得プロセスのソース・データベースのDBIDまたはグローバル名は変更しないでください。ソース・データベースのDBIDまたはグローバル名のいずれかを変更した場合、その取得プロセスを削除して再作成する必要があります。

  • Oracle Database Vaultがインストールされている場合は、取得プロセスを作成するユーザーにBECOME USERシステム権限が付与されている必要があります。Oracle Database Vaultがインストールされていない場合は、この権限がユーザーに付与されている必要はありません。ユーザーのBECOME USERシステム権限は、取得プロセスが作成された後、必要に応じて取り消すことができます。

  • ダウンストリーム取得を構成するには、ソース・データベースがOracle Database 10g リリース1以上のデータベースである必要があります。



関連項目:


取得プロセスの構成準備

取得プロセスを構成する前に、次のタスクを完了する必要があります。

ローカル取得プロセスの構成

次の各項では、DBMS_STREAMS_ADMパッケージおよびDBMS_CAPTURE_ADMパッケージを使用してローカル取得プロセスを作成する方法について説明します。

この項の項目は次のとおりです。

DBMS_STREAMS_ADMを使用したローカル取得プロセスの構成の例

DBMS_STREAMS_ADMパッケージを使用してローカル取得プロセスを構成するには、次の手順を実行します。

  1. 「取得プロセスの構成準備」で説明されているタスクを実行します。

  2. 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表がインスタンス化のために準備されます。

    • 表のすべての主キー、一意キー、ビットマップ索引および外部キーの列に対してサプリメンタル・ロギングが有効にされます。

  3. 必要に応じて、「取得プロセスの構成後に行う作業」で説明されている手順を実行します。


関連項目:


DBMS_CAPTURE_ADMを使用したローカル取得プロセスの構成の例

DBMS_CAPTURE_ADMパッケージを使用してローカル取得プロセスを構成するには、次の手順を実行します。

  1. 「取得プロセスの構成準備」で説明されているタスクを実行します。

  2. 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_scnfirst_scnの両方がNULLに設定されているためです。

    • ローカルな変更を取得する他の取得プロセスがローカル・データベースで実行されていない場合は、DBMS_CAPTURE_ADMパッケージのBUILDプロシージャが自動的に実行されます。このプロシージャが実行されると、データ・ディクショナリがREDOログに抽出され、この取得プロセスの最初の起動時にLogMinerデータ・ディクショナリが作成されます。

  3. 必要に応じて、「取得プロセスの構成後に行う作業」で説明されている手順を実行します。

NULL以外の開始SCNを使用したローカル取得プロセスの構成の例

この例では、DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャを実行して、開始SCN223525に設定されたローカル取得プロセスを作成します。この例では、データベースに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以外にしてローカル取得プロセスを構成するには、次の手順を実行します。

  1. 「取得プロセスの構成準備」で説明されているタスクを実行します。

  2. 次のプロシージャを実行して、取得プロセスを作成します。

    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以上である必要があります。

  3. 必要に応じて、「取得プロセスの構成後に行う作業」で説明されている手順を実行します。


関連項目:

  • 「取得プロセスの作成」

  • CREATE_CAPTUREプロシージャのfirst_scnパラメータおよびstart_scnパラメータの設定の詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照


ダウンストリーム取得プロセスの構成

この項では、ダウンストリーム取得プロセスの準備と、リアルタイム・ダウンストリーム取得プロセスおよびアーカイブ・ログ・ダウンストリーム取得プロセスの構成について説明します。

この項の内容は次のとおりです。

ダウンストリーム・データベースへのREDOデータの送信準備

ダウンストリーム・データベースにREDOデータを送信するためにソース・データベースを準備し、そのREDOデータを受け入れるようにダウンストリーム・データベースを準備するには、この項の手順を実行する必要があります。

ダウンストリーム・データベースにREDOデータを送信する準備として、次の手順を実行します。

  1. 「取得プロセスの構成準備」で説明されているタスクを実行します。

  2. ソース・データベースがダウンストリーム・データベースと通信できるように、Oracle Netを構成します。


    関連項目:

    Oracle Database Net Services管理者ガイド

  3. REDOデータの転送がサポートされるように両方のデータベースで認証を構成します。

    REDO転送セッションは、Secure Sockets Layer(SSL)プロトコルまたはリモート・ログイン・パスワード・ファイルのいずれかを使用して認証されます。ソース・データベースにリモート・ログイン・パスワード・ファイルがある場合、このファイルは、ダウンストリーム取得データベース・システムの適切なディレクトリにコピーされます。パスワード・ファイルは、ソース・データベースとダウンストリーム取得データベースで同じである必要があります。


    関連項目:

    REDO転送の認証要件の詳細は、Oracle Data Guard概要および管理を参照

  4. ソース・データベースで、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_NAMEdbs1で、ダウンストリーム・データベースのDB_UNIQUE_NAMEdbs2の場合は、次のパラメータを指定します。

      LOG_ARCHIVE_CONFIG='DG_CONFIG=(dbs1,dbs2)'
      

      LOG_ARCHIVE_CONFIGパラメータは、デフォルトでデータベースによるREDOの送受信を可能にします。


    関連項目:

    これらの初期化パラメータの詳細は、Oracle DatabaseリファレンスおよびOracle Data Guard概要および管理を参照

  5. ダウンストリーム・データベースで、ソース・データベースおよびダウンストリーム・データベースのDB_UNIQUE_NAMEを含むように、LOG_ARCHIVE_CONFIG初期化パラメータのDB_CONFIG属性を設定します。

    たとえば、ソース・データベースのDB_UNIQUE_NAMEdbs1で、ダウンストリーム・データベースのDB_UNIQUE_NAMEdbs2の場合は、次のパラメータを指定します。

    LOG_ARCHIVE_CONFIG='DG_CONFIG=(dbs1,dbs2)'
    

    LOG_ARCHIVE_CONFIGパラメータは、デフォルトでデータベースによるREDOの送受信を可能にします。

  6. 手順4または手順5で、データベースでのインスタンスの実行中にいずれかの初期化パラメータをリセットした場合は、データベースの再起動時に新しい値が維持されるように、初期化パラメータ・ファイルでもそれらのパラメータをリセットする必要がある場合があります。

    手順4または手順5で、インスタンスの実行中に初期化パラメータをリセットせずに、初期化パラメータ・ファイルでリセットした場合は、データベースを再起動します。ソース・データベースのグローバル名は、ソース・データベースがオープンな場合にのみダウンストリーム・データベースに送信されるため、ダウンストリーム・データベースにREDOログ・ファイルを送信するときには、ソース・データベースがオープンである必要があります。

  7. 次のそれぞれの項で手順を実行します。

リアルタイム・ダウンストリーム取得プロセスの構成

ダウンストリーム取得を実行する取得プロセスを作成するには、CREATE_CAPTUREプロシージャを使用する必要があります。この項の例では、ソース・データベースへのデータベース・リンクを使用するリアルタイム・ダウンストリーム取得プロセスの作成について説明します。ただし、リアルタイム・ダウンストリーム取得プロセスでは、データベース・リンクが使用されない場合があります。

この項の例では、次のことが想定されています。

  • ソース・データベースはdbs1.example.comで、ダウンストリーム・データベースdbs2.example.comです。

  • dbs2.example.comで作成される取得プロセスでは、streams_queueが使用されます。

  • 取得プロセスでは、hr.departments表に対するDML変更が取得されます。

この項の内容は次のとおりです。


注意:

1つのダウンストリーム・データベースで使用可能なリアルタイム・ダウンストリーム取得プロセスは1つのみです。


関連項目:

リアルタイム・ダウンストリーム取得に関する概念については、「ダウンストリーム取得」を参照してください。

ダウンストリーム・データベースへのスタンバイREDOログの追加

次の手順を実行して、スタンバイREDOログをダウンストリーム・データベースに追加します。

  1. 「ダウンストリーム・データベースへのREDOデータの送信準備」の手順を実行します。

  2. ダウンストリーム・データベースで、ローカルに生成された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 
      
  3. ダウンストリーム・データベースで、ダウンストリーム・データベースがソース・データベースから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概要および管理を参照

  4. ステップ2または3で、データベースのインスタンスが実行中に初期化パラメータをリセットした場合、該当する初期化パラメータ・ファイルでもそれをリセットすれば、データベースの再起動時に新しい値が維持されます。

    Step ステップ2または3で、インスタンスの実行中には初期化パラメータをリセットしなかったが、初期化パラメータ・ファイルでリセットした場合は、データベースを再起動します。ソース・データベースのグローバル名は、ソース・データベースがオープンな場合にのみダウンストリーム・データベースに送信されるため、ダウンストリーム・データベースにREDOデータを送信するときには、ソース・データベースがオープンである必要があります。

  5. スタンバイREDOログ・ファイルを作成します。


    注意:

    次に、スタンバイREDOログ・ファイルをダウンストリーム・データベースに追加する一般的な手順の概要を示します。スタンバイREDOログ・ファイルの追加に使用する実際の手順とSQL文は、環境によって異なります。たとえば、Oracle Real Application Clusters(Oracle RAC)環境では手順が異なります。スタンバイREDOログ・ファイルをデータベースに追加する手順の詳細は、Oracle Data Guard概要および管理を参照してください。

    1. SQL*Plusで、ソース・データベースdbs1.example.comに管理ユーザーとして接続します。

      SQL*Plusでデータベースに接続する方法については、Oracle Database管理者ガイドを参照してください。

    2. ソース・データベースで使用するログ・ファイルのサイズを決定します。スタンバイ・ログ・ファイルのサイズは、ソース・データベースのログ・ファイル・サイズと正確に同じか、またはそれより大きくなるようにします。たとえば、ソース・データベースのログ・ファイル・サイズが500MBの場合は、スタンバイ・ログ・ファイルのサイズも500MB以上にします。ソース・データベースにおけるREDOログ・ファイルのサイズ(バイト単位)は、ソース・データベースでV$LOGビューを問い合せて確認することができます。

      たとえば、V$LOGビューを問い合せます。

      SELECT BYTES FROM V$LOG;
      
    3. ダウンストリーム・データベースで必要なスタンバイ・ログ・ファイル・グループの数を決定します。スタンバイ・ログ・ファイル・グループの数は、ソース・データベースでのオンライン・ログ・ファイル・グループの数より1以上大きくする必要があります。たとえば、ソース・データベースに2つのオンライン・ログ・ファイル・グループがある場合、ダウンストリーム・データベースには3つ以上のスタンバイ・ログ・ファイル・グループが必要です。ソース・データベースのオンライン・ログ・ファイル・グループの数は、ソース・データベースでV$LOGビューを問い合せて確認することができます。

      たとえば、V$LOGビューを問い合せます。

      SELECT COUNT(GROUP#) FROM V$LOG;
      
    4. SQL*Plusで、ダウンストリーム・データベースdbs2.example.comに管理ユーザーとして接続します。

    5. 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;
      
    6. 次の問合せを実行して、スタンバイ・ログ・ファイル・グループが正常に追加されたことを確認します。

      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へのデータベース・リンクを使用しています。

次の手順を実行します。

  1. SQL*Plusで、ダウンストリーム・データベースdbs2.example.comにOracle Streams管理者として接続します。

    SQL*Plusでデータベースに接続する方法については、Oracle Database管理者ガイドを参照してください。

  2. 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プロシージャを実行する際にユーザーを権限受領者に指定することによって有効にできます。

  3. 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.comreal_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.comLogMinerデータ・ディクショナリdbs2.example.comに作成されます。

    dbs2.example.comの複数の取得プロセスでdbs1.example.comソース・データベースから変更が取得されている場合、新しい取得プロセスreal_time_captureでは既存のアーカイブ・ログ取得プロセスのいずれかと同じdbs1.example.comのLogMinerデータ・ディクショナリが使用されます。Oracle Streamsでは、新しい取得プロセスと共有されるデータ・ディクショナリが自動的に選択されます。


    注意:

    • 単一のダウンストリーム・データベースでは、1つのリアルタイム・ダウンストリーム取得プロセスのみを使用できます。

    • ダウンストリーム取得プロセスの作成時、CREATE_CAPTUREプロシージャのfirst_scnパラメータがNULLに設定されている場合は、use_database_linkパラメータをTRUEに設定する必要があります。TRUEに設定しないと、エラーが発生します。


  4. downstream_real_time_mine取得プロセス・パラメータをYに設定します。

    BEGIN
      DBMS_CAPTURE_ADM.SET_PARAMETER(
        capture_name => 'real_time_capture',
        parameter    => 'downstream_real_time_mine',
        value        => 'Y');
    END;
    /
    
  5. 取得プロセスのポジティブ・ルール・セットを作成して、ルールを追加します。

    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表が準備されます。

    • 表のすべての主キー、一意キー、ビットマップ索引および外部キーの列に対してサプリメンタル・ロギングが有効にされます。

  6. ログ・ファイルを切り替えるために必要な権限を持つ管理ユーザーとして、ソース・データベースdbs1.example.comに接続されます。

  7. 現行のログ・ファイルがソース・データベースにアーカイブされます。

    ALTER SYSTEM ARCHIVE LOG CURRENT;
    

    現行のログ・ファイルがソース・データベースにアーカイブされると、ソース・データベースのREDOログのリアルタイム・マイニングが開始されます。

  8. 必要に応じて、「取得プロセスの構成後に行う作業」で説明されている手順を実行します。

アーカイブ・ログ・ダウンストリーム取得プロセスの構成

この項では、ログ・ファイルを暗黙的または明示的に割り当てるアーカイブ・ログ・ダウンストリーム取得プロセスの構成について説明します。

この項の内容は次のとおりです。

ログを暗黙的に割り当てるアーカイブ・ログのダウンストリーム取得プロセスの構成

ダウンストリーム取得を実行する取得プロセスを作成するには、CREATE_CAPTUREプロシージャを使用する必要があります。この項の例では、ソース・データベースへのデータベース・リンクを管理の目的で使用するアーカイブ・ログ・ダウンストリーム取得プロセスの作成について説明します。

この項の例では、次のことが想定されています。

  • ソース・データベースはdbs1.example.comで、ダウンストリーム・データベースdbs2.example.comです。

  • dbs2.example.comで作成される取得プロセスでは、strmadminが所有するstreams_queueが使用されます。

  • 取得プロセスは、dbs1.example.comhr.departments表に行われたDML変更を取得します。

  • この取得プロセスでは、ログ・ファイルを暗黙的に割り当てます。つまり、REDO転送サービスまたは手動でソース・データベースからダウンストリーム・データベースに追加されたすべてのREDOログ・ファイルがダウンストリーム取得プロセスによって自動的にスキャンされます。

次の手順を実行します。

  1. 「ダウンストリーム・データベースへのREDOデータの送信準備」の手順を実行します。

  2. SQL*Plusで、ダウンストリーム・データベースdbs2.example.comにOracle Streams管理者として接続します。

    SQL*Plusでデータベースに接続する方法については、Oracle Database管理者ガイドを参照してください。

  3. 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プロシージャを実行する際にユーザーを権限受領者に指定することによって有効にできます。

  4. 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.comstrm04_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.comLogMinerデータ・ディクショナリ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に設定しないと、エラーが発生します。


    関連項目:

    • 「取得プロセスの作成」

    • ALTER DATABASE文の詳細は、Oracle Database SQL言語リファレンスを参照

    • REDOログ・ファイルの登録の詳細は、Oracle Data Guard概要および管理を参照


  5. 取得プロセスのポジティブ・ルール・セットを作成して、ルールを追加します。

    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に設定されているため、このルールは取得プロセスのポジティブ・ルール・セットに追加されます。

  6. 必要に応じて、「取得プロセスの構成後に行う作業」で説明されている手順を実行します。

ログを明示的に割り当てるアーカイブ・ログのダウンストリーム取得プロセスの構成

ダウンストリーム取得を実行する取得プロセスを作成するには、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ログ・ファイルは自動的にダウンストリーム取得データベースに転送されません。かわりに、各ファイルは手動で転送されます。

次の手順を実行します。

  1. SQL*Plusで、ソース・データベースdbs1.example.comにOracle Streams管理者として接続します。

    ダウンストリーム・データベースからソース・データベースへのデータベース・リンクを使用しない場合は、ソース・データベースにOracle Streams管理者が存在している必要があります。

    SQL*Plusでデータベースに接続する方法については、Oracle Database管理者ガイドを参照してください。

  2. 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データ・ディクショナリが作成されます。

  3. インスタンス化のために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を指定すると、表内のすべての主キー、一意キー、ビットマップ索引および外部キー列に対するサプリメンタル・ロギングが有効になります。

  4. ソース・データベースの現行の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であると想定されています。

  5. ダウンストリーム・データベースdbs2.example.comにOracle Streams管理者として接続します。

  6. 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.comstrm05_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ルール・セットに関連付けません。次の手順でルール・セットを作成して、取得プロセスに関連付けます。


    関連項目:


  7. 取得プロセスのポジティブ・ルール・セットを作成して、ルールを追加します。

    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に設定されているため、このルールは取得プロセスのポジティブ・ルール・セットに追加されます。

  8. ダウンストリーム取得プロセスの先頭SCNが含まれているソース・データベースdbs1.example.comのREDOログ・ファイルがアーカイブされた後、アーカイブREDOログ・ファイルをダウンストリーム・データベースが実行されているコンピュータに転送します。手順2BUILDプロシージャによって、ダウンストリーム取得プロセスの先頭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ログ・ファイルをダウンストリーム取得プロセスが実行されているコンピュータに転送します。

  9. ダウンストリーム・データベースdbs2.example.comに管理ユーザーとして接続します。

  10. 転送された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';
    
  11. 必要に応じて、「取得プロセスの構成後に行う作業」で説明されている手順を実行します。

取得プロセスの構成後に行う作業

新しい取得プロセスによって取得された論理変更レコード(LCR)を処理する伝播および適用プロセスを構成する場合は、次の順序で構成を実行します。

  1. 伝播および適用プロセスで必要となるキューを作成します。「キューの構成」を参照してください。

  2. 新しい取得プロセスによって取得されたLCRを伝播するすべての伝播を作成します。「ANYDATAキュー間でのOracle Streamsの伝播の作成」を参照してください。

  3. 新しい取得プロセスによって取得されたLCRをデキューするすべての適用プロセスを作成します。「適用プロセスの作成の概要」を参照してください。取得LCRを適用するように、各適用プロセスを構成します。

  4. 新しい取得プロセスによってすべての宛先データベースの変更が取得される表をインスタンス化します。インスタンス化の詳細は、Oracle Streamsレプリケーション管理者ガイドを参照してください。

  5. 新しい取得プロセスによって取得されたLCRを処理する適用プロセスを起動します。「適用プロセスの起動」を参照してください。

  6. 新しい取得プロセスを起動します。「取得プロセスの起動」を参照してください。


注意:

使用しているOracle Streams環境によっては、その他の構成手順が必要となる場合があります。たとえば、一部のOracle Streams環境では、変換、適用ハンドラ、競合解決などが含まれます。

同期取得の構成

同期取得を作成するには、次のいずれかのプロシージャを使用します。

DBMS_STREAMS_ADMパッケージ内の両方のプロシージャでは、指定された名前を持つ同期取得が存在しない場合は同期取得が作成され、同期取得のポジティブ・ルール・セットが存在しない場合はポジティブ・ルール・セットがされます。また、ルール・セットに表ルールまたはサブセット・ルールを追加することもできます。

CREATE_SYNC_CAPTUREプロシージャでは同期取得は作成されますが、同期取得のルール・セットおよびルールは作成されません。ただし、CREATE_SYNC_CAPTUREプロシージャを使用すると、同期取得に関連付ける既存のルール・セットを指定できます。また、デフォルトの取得ユーザー以外の取得ユーザーを指定できます。

次の各項では、同期取得の構成について説明します。


注意:

  • 同期取得を作成するには、ユーザーにDBAロールが付与されている必要があります。

  • Oracle Database Vaultがインストールされている場合は、同期取得を作成するユーザーにBECOME USERシステム権限が付与されている必要があります。Oracle Database Vaultがインストールされていない場合は、この権限がユーザーに付与されている必要はありません。ユーザーのBECOME USERシステム権限は、同期取得が作成された後、必要に応じて取り消すことができます。



関連項目:


同期取得の構成準備

同期取得を構成する前に、次のタスクを完了する必要があります。

  • 同期取得が使用されるすべてのデータベースで初期化パラメータが適切に設定されていることを確認します。「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を適用するように各適用プロセスを構成します。適用プロセスは、「同期取得の構成後に行う作業」で実行するインスタンス化が終了するまで起動しないでください。

DBMS_STREAMS_ADMパッケージを使用した同期取得の構成

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パッケージを使用して同期取得を作成するには、次の手順を実行します。

  1. 「同期取得の構成準備」で説明されているタスクを実行します。

  2. SQL*Plusで、dbs1.example.comデータベースにOracle Streams管理者として接続します。

    SQL*Plusでデータベースに接続する方法については、Oracle Database管理者ガイドを参照してください。

  3. 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ファンクションを実行することによって、指定された表がインスタンス化のために準備されます。

  4. 必要に応じて、「同期取得の構成後に行う作業」で説明されている手順を実行します。


注意:

ADD_TABLE_RULESプロシージャまたはADD_SUBSET_RULESプロシージャでルールが同期取得のルール・セットに追加される場合、プロシージャは指定した表の排他ロックを取得する必要があります。指定した表に処理中のトランザクションがある場合、プロシージャはロックを取得できるまで待機します。

DBMS_CAPTURE_ADMパッケージを使用した同期取得の構成

この項では、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パッケージを使用して同期取得を作成するには、次の手順を実行します。

  1. 「同期取得の構成準備」で説明されているタスクを実行します。

  2. SQL*Plusで、dbs1.example.comデータベースにOracle Streams管理者として接続します。

    SQL*Plusでデータベースに接続する方法については、Oracle Database管理者ガイドを参照してください。

  3. 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;
    /
    

    このプロシージャを実行すると、次のアクションが実行されます。

    • sync01_captureという名前の同期取得が作成されます。この場合、同じ名前の同期取得が存在していない必要があります。

    • 同期取得を有効にします。同期取得は無効にできません。

    • 同期取得がstreams_queueという名前の既存のキューに関連付けられます。

    • 同期取得がstrmadminスキーマ内のsync01_rule_setという名前の既存のルール・セットに関連付けられます。

    • hrが同期取得の取得ユーザーとして構成されます。

  4. 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.comsync01_captureという名前の同期取得のルール・セットにサブセット・ルールが追加されます。同期取得は、サブセット・ルールによって、department_id1700の行に対する変更を取得するよう指示されます。この同期取得では、同じ表の他の行に対する変更は取得されません。

    • 表に対してDBMS_CAPTURE_ADM.PREPARE_SYNC_INSTANTIATIONファンクションを自動的に実行することで、インスタンス化用にhr.departments表を準備します。

    • 変更が行われるセッションにNULLタグが含まれている場合にのみ、同期取得によって変更が取得されるように指定されます。これは、include_tagged_lcrパラメータがFALSEに設定されているためです。この動作は、同期取得のシステム作成ルールによって実行されます。

  5. 必要に応じて、「同期取得の構成後に行う作業」で説明されている手順を実行します。


注意:

CREATE_SYNC_CAPTUREプロシージャでは、同期取得を作成する場合、変更を取得する各表に対して排他ロックを取得する必要があります。これらの表は、同期取得の指定されたルール・セット内のルールによって判別されます。同様に、ADD_TABLE_RULESまたはADD_SUBSET_RULESプロシージャでは、同期取得のルール・セットにルールを追加する場合、指定された表に対して排他ロックを取得する必要があります。これらのプロシージャは、同期取得によって変更が取得される表に未処理のトランザクションがある場合、ロックを取得できるまで待機します。

同期取得の構成後に行う作業

新しい取得プロセスによって取得されたLCRを処理する伝播および適用プロセスを構成した場合は、次の手順を実行します。

  1. 新しい同期取得によってすべての宛先データベースの変更が取得される表をインスタンス化します。インスタンス化の詳細は、Oracle Streamsレプリケーション管理者ガイドを参照してください。

  2. 同期取得によって取得されたLCRを処理する適用プロセスを起動します。「適用プロセスの起動」を参照してください。


注意:

使用しているOracle Streams環境によっては、その他の構成手順が必要となる場合があります。たとえば、一部のOracle Streams環境では、変換、適用ハンドラ、競合解決などが含まれます。