4 XStream Outの構成

XStream Outプロセスで使用されるOracle Databaseコンポーネントを構成できます。

• XStream Outの準備
  XStream Outの構成の準備のために、意思決定を行い、タスクを完了する必要があります。
• XStream Outの構成
  XStream Out構成のアウトバウンド・サーバーは、Oracleデータベースの変更をクライアント・アプリケーションにストリームします。

関連項目:

• XStream Outの概念

• XStreamの使用例

• Oracle Call Interfaceプログラマーズ・ガイド

• Oracle Database XStream Java APIリファレンス

4.1 XStream Outの準備

XStream Outの構成の準備のために、意思決定を行い、タスクを完了する必要があります。

• XStream Outの構成方法の決定
  XStream Outを構成するとき、データベースの変更を取得してこれらの変更を論理変更レコード(LCR)の形式でアウトバウンド・サーバーに送信するようにXStreamコンポーネントを構成する必要があります。
• XStream Outの構成の前提条件
  XStream Outアウトバウンド・サーバーの準備は、Oracle Streamsレプリケーション環境の準備に似ています。

4.1.1 XStream Outの構成方法の決定

XStream Outを構成するとき、データベースの変更を取得してこれらの変更を論理変更レコード(LCR)の形式でアウトバウンド・サーバーに送信するようにXStreamコンポーネントを構成する必要があります。

これらのコンポーネントには、取得プロセスおよび少なくとも1つのキューが含まれます。取得プロセスには、ローカル取得プロセスまたはダウンストリーム取得プロセスを使用できます。一部の構成では伝播も構成する必要があります。

ローカル取得とは、ソース・データベース上で取得プロセスが実行されることを意味します。ソース・データベースは、変更が発生したデータベースです。ダウンストリーム取得とは、ソース・データベース以外のデータベース上で取得プロセスが実行されることを意味します。ダウンストリーム取得を使用する主な理由は、ソース・データベースの負荷を削減して、パフォーマンスを向上させることです。ローカル取得を使用する主な理由は、構成および管理が容易であることです。

ソース・データベースに対する変更を取得するデータベースは、取得データベースと呼ばれます。次のいずれかのデータベースを取得データベースとして使用できます。

• ソース・データベース(ローカル取得)

• 宛先データベース(ダウンストリーム取得)

• 第3のデータベース(ダウンストリーム取得)

アウトバウンド・サーバーを実行しているデータベースが取得データベースでない場合、伝播によって、取得データベースからアウトバウンド・サーバーを実行しているデータベースに変更が送信されます。アウトバウンド・サーバーを実行しているデータベースが取得データベースである場合、取得プロセスとアウトバウンド・サーバーが同じキューを使用するため、データベース間のこの伝播は不要です。

このコンポーネントは、次の方法で構成できます。

• ローカル取得およびアウトバウンド・サーバーが同じデータベースに存在する場合:データベース・オブジェクト、取得プロセスおよびアウトバウンド・サーバーがすべて同じデータベース内に存在します。すべてのコンポーネントが1つのデータベースにあるため、構成およびメンテナンスが最も容易な構成です。この構成の概要については、図4-1を参照してください。

• ローカル取得およびアウトバウンド・サーバーが異なるデータベースに存在する場合:データベース・オブジェクトおよび取得プロセスは1つのデータベースに存在し、アウトバウンド・サーバーは別のデータベースに存在します。伝播によって、ソース・データベースからアウトバウンド・サーバー・データベースにLCRが送信されます。この構成は、構成およびメンテナンスを簡単に行うことができ、アウトバウンド・サーバー・データベースのパフォーマンスを最適化する必要がある場合にお薦めします。この構成の概要については、図4-2を参照してください。

• ダウンストリーム取得およびアウトバウンド・サーバーが同じデータベースに存在する場合:データベース・オブジェクトは1つのデータベースに存在し、取得プロセスおよびアウトバウンド・サーバーは別のデータベースに存在します。この構成は、データベース・オブジェクトが存在するデータベースのパフォーマンスを最適化し、変更の取得をもう1つのデータベースで行って負荷を軽減する必要がある場合に適しています。この構成では、ほとんどのコンポーネントはアウトバウンド・サーバーを持つデータベースで実行されます。この構成の概要については、図4-3を参照してください。

• ダウンストリーム取得およびアウトバウンド・サーバーが異なるデータベースに存在する場合:データベース・オブジェクトは1つのデータベースに存在し、アウトバウンド・サーバーは別のデータベースに存在し、取得プロセスは3つ目のデータベースに存在します。この構成は、データベース・オブジェクトを持つデータベースおよびアウトバウンド・サーバーを持つデータベースの両方のパフォーマンスを最適化する場合に最適です。この構成では、取得プロセスが3つ目のデータベースで実行され、伝播によって、取得データベースからアウトバウンド・サーバー・データベースにLCRが送信されます。この構成の概要については、図4-4を参照してください。

次の図は、これらの異なる構成を示しています。

図4-1 ローカル取得とアウトバウンド・サーバーが同じデータベースにある場合

「図4-1 ローカル取得とアウトバウンド・サーバーが同じデータベースにある場合」の説明

図4-2 ローカル取得とアウトバウンド・サーバーが別のデータベースにある場合

「図4-2 ローカル取得とアウトバウンド・サーバーが別のデータベースにある場合」の説明

図4-3 ダウンストリーム取得とアウトバウンド・サーバーが同じデータベースにある場合

「図4-3 ダウンストリーム取得とアウトバウンド・サーバーが同じデータベースにある場合」の説明

図4-4 ダウンストリーム取得とアウトバウンド・サーバーが別のデータベースにある場合

「図4-4 ダウンストリーム取得とアウトバウンド・サーバーが別のデータベースにある場合」の説明

ダウンストリーム取得プロセスを構成する場合は、構成するダウンストリーム取得プロセスのタイプを決定する必要があります。使用可能なタイプは次のとおりです。

• リアルタイム・ダウンストリーム取得プロセスの構成: ソース・データベースのREDO転送サービスがREDOデータをダウンストリーム・データベースに送信し、ダウンストリーム・データベースのリモート・ファイル・サーバー・プロセス(RFS)でネットワークを介してREDOデータを受け取り、スタンバイREDOログにREDOデータを格納します。取得プロセスは変更をリアルタイムで取得します。

• アーカイブ・ログ・ダウンストリーム取得プロセス構成: この構成では、ソース・データベースからのアーカイブREDOログ・ファイルがダウンストリーム・データベースにコピーされ、取得プロセスによってこれらのアーカイブREDOログ・ファイル内の変更が取得されます。これらのログ・ファイルは、REDO転送サービスを使用して自動的に転送することも、FTPなどの方法を使用して手動で転送することもできます。

アーカイブ・ログ・ダウンストリーム取得と比較すると、リアルタイム・ダウンストリーム取得には、ソース・データベースで行われた変更を短時間で取得できるというメリットがあります。リアルタイム・ダウンストリーム取得プロセスでは、REDOログ・ファイルがアーカイブされるまで待たずにREDOログ・ファイルから変更を取得できるため、時間が短縮されます。1つのダウンストリーム・データベースで、同じソース・データベースから変更を取得する複数のリアルタイム・ダウンストリーム取得プロセスを構成することはできますが、複数のソース・データベースに対するリアルタイム・ダウンストリーム取得を構成することはできません。

リアルタイム・ダウンストリーム取得と比較すると、アーカイブ・ログ・ダウンストリーム取得には、複数のソース・データベースに対するダウンストリーム取得プロセスを1つのダウンストリーム・データベースで使用できるというメリットがあります。REDOログ・ファイルを複数のソース・データベースから単一のダウンストリーム・データベースにコピーし、それらのREDOログ・ファイル内の変更を複数のアーカイブ・ログ・ダウンストリーム取得プロセスで取得するように構成できます。

関連項目:

「ローカル取得およびダウンストリーム取得」

4.1.2 XStream Outの構成の前提条件

XStream Outアウトバウンド・サーバーの準備は、Oracle Streamsレプリケーション環境の準備に似ています。

変更を取得して適用プロセスに送信するためのOracle Streamsレプリケーション環境で使用されるコンポーネントは、変更を取得してアウトバウンド・サーバーに送信するために使用されるコンポーネントと同じです。これらのコンポーネントには、取得プロセスと1つ以上のキューが含まれます。取得プロセスがアウトバウンド・サーバーとは異なるデータベース上で実行される場合は伝播も必要です。

この項で説明するタスクの一部は、Oracle Streamsレプリケーション管理者ガイドで詳しく説明されています。この項では各タスクの概要と、XStream Out構成用のタスクの実行に関する特定の情報を提供します。

• すべてのデータベースでのXStream管理者の構成
  XStream管理者は、XStream Out環境でXStreamコンポーネントを構成および管理します。
• XStream管理者への追加権限の付与
  XStream管理者に追加権限が必要な場合があります。
• 必要な場合のネットワーク接続およびデータベース・リンクの構成
  XStream Out構成に複数のデータベースが含まれている場合は、ネットワーク接続性やデータベース・リンクが必要です。
• 各ソース・データベースがARCHIVELOGモードであることの確認
  取得プロセスによって取得される変更を生成する各ソース・データベースはARCHIVELOGモードである必要があります。
• 関連する初期化パラメータの設定
  一部の初期化パラメータは、XStream構成でのコンポーネントの構成、操作、信頼性およびパフォーマンスにとって重要です。これらのパラメータを適切に設定します。
• Streamsプールの構成
  Streamsプールは、Oracle StreamsとXStreamコンポーネントの両方で使用されるシステム・グローバル領域(SGA)内のメモリーの一部です。
• 必要な場合のサプリメンタル・ロギングの構成
  取得プロセスを使用して変更を取得する場合は、列に対する変更が宛先データベースで正常に適用されるように、ソース・データベースで特定の列にサプリメンタル・ロギングを指定する必要があります。
• 必要な場合のダウンストリーム・データベースへのログ・ファイル転送の構成
  ローカル取得プロセスを使用するように決定した場合は、ログ・ファイルの転送は不要です。ただし、REDO転送サービスを使用してアーカイブREDOログ・ファイルをダウンストリーム・データベースに自動的に転送するダウンストリーム取得を使用するように決定した場合は、ソース・データベースから取得データベースへのログ・ファイルの転送を構成します。
• 必要な場合のリアルタイム・ダウンストリーム取得のためのスタンバイREDOログの追加
  リアルタイム・ダウンストリーム取得を構成する場合、スタンバイREDOログを取得データベースに追加します。

4.1.2.1 すべてのデータベースでのXStream管理者の構成

XStream管理者は、XStream Out環境でXStreamコンポーネントを構成および管理します。

ユーザーに適切な権限を付与することによって、XStream管理者を構成できます。XStream構成に含まれる各OracleデータベースでXStream管理者を構成する必要があります。

前提条件

XStream管理者を構成する前に、次の前提条件が満たされていることを確認します。

• ユーザーの作成、権限の付与および表領域の作成ができる管理ユーザーとしてXStream構成の各データベースにログインできることを確認してください。

• セキュリティについての信頼できるユーザー・モデルと信頼されないユーザー・モデルのどちらとするかを決定します。詳細は、XStreamのセキュリティ・モデルを参照してください。

• XStream管理者になるユーザーを特定します。適切な権限を持つ新規ユーザーを作成するか、これらの権限を既存のユーザーに付与します。

  SYSまたはSYSTEMユーザーをXStream管理者として使用しないでください。また、XStream管理者は、デフォルト表領域としてSYSTEM表領域を使用しないようにしてください。

• XStream管理者に新しい表領域が必要な場合、XStream構成の各コンピュータ・システム上に、表領域のためのディスクの空き領域が十分あることを確認します。表領域の推奨サイズは25MBです。

• DBMS_XSTREAM_AUTHパッケージのサブプログラムを実行するユーザーにはSYSDBA管理権限が必要であり、接続時にAS SYSDBAを使用してこの権限を行使する必要があります。

前提条件

この項では、次のことを想定しています。

• XStream管理者のユーザー名は、非CDBの場合はxstrmadminです。XStream管理者のユーザー名は、マルチテナント・コンテナ・データベース(CDB)の場合はc##xstrmadminです。

• XStream管理者によって使用される表領域は、xstream_tbsです。

XStream管理者を構成するには、次の手順を実行します。

1. SQL*Plusで、ユーザーの作成、権限の付与および表領域の作成を行うことができる管理ユーザーとして接続します。これ以降のすべての手順は、この管理ユーザーとして接続したまま実行します。

   CDB内のXStream OutのためのXStream管理者を構成する場合、rootに接続し、CDBルートでXStream管理者を構成します。

   関連項目:

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

   • XStream OutおよびCDBの詳細は、XStream Outおよびマルチテナント環境を参照してください。

2. XStream管理者用の表領域を作成するか、既存の表領域を使用します。

   この表領域には、XStream管理者のスキーマに作成されたあらゆるオブジェクトが格納されます。

   たとえば、次の文では、XStream管理者用の新規表領域が作成されます。

   CREATE TABLESPACE xstream_tbs DATAFILE '/usr/oracle/dbs/xstream_tbs.dbf' 
     SIZE 25M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;
   

   CDB内でXStream管理者を作成する場合、CDBルート、すべてのプラガブル・データベース、すべてのアプリケーション・ルートおよびすべてのアプリケーション・コンテナ(PDB)を含む、CDB内のすべてのコンテナに表領域を作成する必要があります。XStream管理者は共通ユーザーである必要があり、したがってすべてのコンテナの表領域へのアクセス権を持つ必要があるため、表領域はすべてのコンテナで必要です。

3. XStream管理者として機能する新しいユーザーを作成するか、既存のユーザーを指定します。

   たとえば、ユーザーxstrmadminを作成し、このユーザーがxstream_tbs表領域を使用するように指定するには、次の文を実行します。

   CREATE USER xstrmadmin IDENTIFIED BY password 
     DEFAULT TABLESPACE xstream_tbs
     QUOTA UNLIMITED ON xstream_tbs;
   

   CDBでXStream管理者を作成する場合、XStream管理者は共通ユーザーである必要があります。したがって、CREATE USER文にCONTAINER=ALL句を含めます。

   CREATE USER c##xstrmadmin IDENTIFIED BY password 
     DEFAULT TABLESPACE xstream_tbs
     QUOTA UNLIMITED ON xstream_tbs
     CONTAINER=ALL;
   

   注意:

   管理ユーザーの適切なパスワードを入力します。

   関連項目:

   パスワード選択のガイドラインについては、Oracle Databaseセキュリティ・ガイドを参照してください

4. XStream管理者にCREATE SESSION権限を付与します。

   XStream管理者として機能する新しいユーザーを作成した場合、このユーザーにCREATE SESSION権限を付与します。

   たとえば、ユーザーxstrmadminにCREATE SESSION権限を付与するには、次の文を実行します。

   GRANT CREATE SESSION TO xstrmadmin;
   

   CDB内でXStream管理者を作成する場合、XStream管理者にCREATE SESSION権限およびSET CONTAINER権限を付与し、CONTAINER=ALL句を文に含めます。

   たとえば、CDBでユーザーc##xstrmadminにこれらの権限を付与するには、次の文を実行します。

   GRANT CREATE SESSION, SET CONTAINER TO c##xstrmadmin CONTAINER=ALL;
   

5. DBMS_XSTREAM_AUTHパッケージのGRANT_ADMIN_PRIVILEGEプロシージャを実行します。

   ユーザー作成サブプログラム内のパッケージのサブプログラムを実行する場合、ユーザーには、パッケージに対するEXECUTE権限が明示的に付与されていることが必要です。また、ユーザー作成サブプログラム内のビューを問い合せる場合は、そのデータ・ディクショナリ・ビューに対する明示的なREADまたはSELECT権限が必要です。これらの権限は、ロールを通じて付与できません。これらの権限をXStream管理者に付与するには、GRANT_ADMIN_PRIVILEGEプロシージャを実行するか、または権限を直接付与します。

   GRANT_ADMIN_PRIVILEGEプロシージャのパラメータの設定によっては、信頼できるまたは信頼できないXStream管理者の適切な権限を付与でき、非CDBまたはCDBで権限を付与できます。表4-1はそれぞれのケースについてのキー・パラメータ設定を示します。

   表4-1 GRANT_ADMIN_PRIVILEGEのキー・パラメータ設定

   XStream管理者のタイプ	grant_select_privilegesのパラメータ設定	containerのパラメータ設定
   非CDBで信頼できる管理者	TRUE	CURRENT (デフォルト)
   非CDBで信頼できない管理者	FALSE (デフォルト)	CURRENT (デフォルト)
   CDBで信頼できる管理者	TRUE	ALL
   CDBで信頼できない管理者	FALSE (デフォルト)	ALL

   注意:

   • いずれのシナリオの場合でも、XStream管理者がデータベースでXStream OutおよびXStream In構成の両方を管理する必要がある場合、privilege_typeパラメータに*を指定します。

   • CDBでは、containerパラメータにALLが指定されている場合、現在のコンテナはCDBルート(CDB$ROOT)である必要があります。

   関連項目:

   Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス

6. 必要に応じて、XStream管理者に追加の権限を付与します。

   XStream管理者への追加権限の付与を参照してください。

7. XStreamを使用する環境内の各Oracleデータベースで前述のすべての手順を繰り返します。

例4-1 非CDBの信頼できるXStream管理者に対する権限の付与(スクリプトの生成なし)

BEGIN
   DBMS_XSTREAM_AUTH.GRANT_ADMIN_PRIVILEGE(
      grantee                 => 'xstrmadmin',
      privilege_type          => 'CAPTURE',
      grant_select_privileges => TRUE);
END;
/

例4-2 非CDBの信頼できるXStream管理者に対する権限の付与(スクリプトの生成あり)

directory_nameパラメータに指定したディレクトリが存在し、現在のユーザーがアクセスできる必要があります。

BEGIN
   DBMS_XSTREAM_AUTH.GRANT_ADMIN_PRIVILEGE(
      grantee                 => 'xstrmadmin',
      privilege_type          => 'CAPTURE',
      grant_select_privileges => TRUE,
      do_grants               => TRUE,
      file_name               => 'grant_xstrm_privs.sql',
      directory_name          => 'xstrm_dir');
END;
/

例4-3 非CDBの信頼できないXStream管理者に対する権限の付与(スクリプトの生成なし)

BEGIN
   DBMS_XSTREAM_AUTH.GRANT_ADMIN_PRIVILEGE(
      grantee                 => 'xstrmadmin',
      privilege_type          => 'CAPTURE',
      grant_select_privileges => FALSE);
END;
/

例4-4 CDBの信頼できるXStream管理者に対する権限の付与(スクリプトの生成なし)

BEGIN
   DBMS_XSTREAM_AUTH.GRANT_ADMIN_PRIVILEGE(
      grantee                 => 'c##xstrmadmin',
      privilege_type          => 'CAPTURE',
      grant_select_privileges => TRUE,
      container               => 'ALL');
END;
/

4.1.2.2 XStream管理者への追加権限の付与

XStream管理者に追加権限が必要な場合があります。

必要に応じて、次の追加権限をXStream管理者に付与します。

• Oracle Enterprise Manager Cloud Controlを使用して、XStreamコンポーネントを持つデータベースを管理する場合、XStream管理者は信頼できるユーザーである必要があり、DBAロールが付与される必要があります。また、XStream管理者がOracle Enterprise Manager管理ユーザーになるように構成する必要があります。これにより、Oracle Enterprise Manager Cloud Controlジョブの実行に必要な権限など、Oracle Enterprise Manager Cloud Controlで必要な追加の権限が付与されます。Oracle Enterprise Manager管理ユーザーの作成については、Oracle Enterprise Manager Cloud Controlのオンライン・ヘルプを参照してください。

• ローカル・データベースでアクションを実行する権限をリモートのXStream管理者に付与します。これらの権限を付与するには、DBMS_XSTREAM_AUTHパッケージのGRANT_REMOTE_ADMIN_ACCESSプロシージャを使用します。この権限は、リモートのXStream管理者が、ローカルのXStream管理者に接続して管理アクションを実行するデータベース・リンクを使用する場合に付与します。具体的には、次のいずれかの条件に該当する場合にこれらの権限を付与します。

  • ローカル・ソース・データベースで発生した変更を取得するリモート・ダウンストリーム・データベースでダウンストリーム取得プロセスを構成し、そのダウンストリーム取得プロセスでデータベース・リンクを使用してソース・データベースで管理アクションを実行する。

  • リモートXStream管理者を使用して、ローカル・データベースのレプリケートされたデータベース・オブジェクトにインスタンス化システム変更番号(SCN)値を設定する。

• 取得プロセス、伝播、またはアウトバウンド・サーバーで使用されるルールにカスタム・ルールベースの変換で指定されている、他ユーザー所有のすべてのPL/SQLファンクションに対するEXECUTE権限をXStream管理者に付与します。取得プロセスで取得ユーザーが指定されている場合、その取得ユーザーにはこれらの権限が必要です。これらの権限は、直接付与する必要があります。ロールを介して付与することはできません。

• 必要に応じて、データベース・オブジェクトを変更する権限をXStream管理者に付与します。たとえば、XStream管理者が別のスキーマ内の表にサプリメンタル・ログ・グループを作成する必要がある場合、XStream管理者にはその表を変更する権限が必要です。これらの権限は、直接またはロールを介して付与できます。

• XStream管理者が取得プロセス、伝播、またはアウトバウンド・サーバーによって使用されるキューを所有しておらず、キューの作成時にそのキューのキュー・ユーザーとして指定されていない場合、XStream管理者がLCRをキューにエンキューしたり、キューからデキューできるようにするには、XStream管理者をそのキューの保護キュー・ユーザーとして構成する必要があります。また、XStream管理者には、そのキューに対するENQUEUE権限またはDEQUEUE権限(あるいはその両方)が必要な場合があります。キューを管理する方法の詳細は、Oracle Streams概要および管理を参照してください。

• XStream管理者がアクセスする必要がある場合がある任意のオブジェクト・タイプに対するEXECUTE権限をXStream管理者に付与します。これらの権限は、直接またはロールを介して付与できます。

• Oracle Database Vaultを使用している場合、取得プロセスの作成、アウトバウンド・サーバーの作成および取得プロセスのための取得ユーザーの変更というタスクを実行するために、XStream管理者にDV_XSTREAM_ADMINロールを付与する必要があります。XStream管理者がこれらのタスクを実行しない場合は、XStream管理者のDV_XSTREAM_ADMINロールを取り消すことができます。

  また、次の操作を実行するユーザーにBECOME USERシステム権限を付与する必要があります。

  • 取得プロセスの作成または変更

  • アウトバウンド・サーバーの作成または変更

  Oracle Database Vaultがインストールされていない場合は、これらのアクションを実行するユーザーにBECOME USERシステム権限を付与する必要はありません。必要に応じて、これらのいずれかのアクションの完了後に、ユーザーのBECOME USERシステム権限を取り消すことができます。

  Oracle Database Vault管理者ガイドを参照してください。

4.1.2.3 必要な場合のネットワーク接続およびデータベース・リンクの構成

XStream Out構成に複数のデータベースが含まれている場合は、ネットワーク接続とデータベース・リンクが必要です。

すべてのコンポーネントが同じデータベースで実行される場合、ネットワーク接続もデータベース・リンクも必要ありません。これらのコンポーネントには、取得プロセス、キューおよびアウトバウンド・サーバーが含まれています。

次のいずれかの方法でXStreamを構成する場合は、ネットワーク接続とデータベース・リンクを構成する必要があります。

• 取得プロセスおよびアウトバウンド・サーバーが別のデータベースで実行される。

• ダウンストリーム取得が使用される。

これらの決定の詳細は、「XStream Outの構成方法の決定」を参照してください。

ネットワーク接続が必要な場合、データベースで相互に通信できるようにネットワークとOracle Netを構成します。

次のデータベース・リンクが必要です。

• 取得プロセスがアウトバウンド・サーバーとは異なるデータベースで実行されている場合、取得データベースからアウトバウンド・サーバー・データベースへのデータベース・リンクを作成します。伝播はこのデータベース・リンクを使用して、取得データベースからアウトバウンド・サーバー・データベースに変更を送信します。

• ダウンストリーム取得を使用する場合は、取得データベースからソース・データベースへのデータベース・リンクを作成します。ソース・データベースは、取得プロセスが変更を取得するために使用するREDOデータを生成するデータベースです。取得プロセスはこのデータベース・リンクを使用して、ソース・データベースで管理タスクを実行します。

各データベース・リンクの名前は宛先データベースのグローバル名と一致する必要があり、各データベース・リンクは、XStream管理者のスキーマに作成する必要があります。

たとえば、次の特性を持つ構成でデータベース・リンクを作成するとします。

• ソース・データベースのグローバル名はdbs1.example.comです。

• 宛先データベースのグローバル名はdbs2.example.comです。

• XStream管理者はそれぞれのデータベースでxstrmadminです。

前述の前提で、次の文ではdbs1.example.comからdbs2.example.comへのデータベース・リンクが作成されます。

CONNECT [e-mail]
Enter password: password

CREATE DATABASE LINK dbs2.example.com CONNECT TO xstrmadmin 
   IDENTIFIED BY password USING 'dbs2.example.com';

関連項目:

• Oracle Database 2日でデータベース管理者

• データベース・リンクの詳細は、Oracle Database管理者ガイドを参照してください。

4.1.2.4 各ソース・データベースがARCHIVELOGモードであることの確認

取得プロセスによって取得される変更を生成する各ソース・データベースはARCHIVELOGモードである必要があります。

ダウンストリーム取得プロセスでは、リアルタイム・ダウンストリーム取得プロセスを構成する場合、ダウンストリーム・データベースもARCHIVELOGモードである必要があります。ダウンストリーム・データベースでアーカイブ・ログ・ダウンストリーム取得プロセスのみを実行する場合は、ダウンストリーム・データベースをARCHIVELOGモードにする必要はありません。

Oracle Real Application Clusters (Oracle RAC)環境でXStreamを構成している場合は、すべてのインスタンスからのすべてのスレッドのアーカイブREDOログ・ファイルが、取得プロセスを実行するインスタンスから使用できる必要があります。この要件は、ローカルおよびダウンストリーム取得プロセスの両方に関連します。

関連項目:

ARCHIVELOGモードでデータベースを実行する手順については、Oracle Database管理者ガイドを参照してください

4.1.2.5 関連する初期化パラメータの設定

一部の初期化パラメータは、XStream構成でのコンポーネントの構成、操作、信頼性およびパフォーマンスにとって重要です。これらのパラメータを適切に設定します。

XStreamアウトバウンド・サーバーには次の要件が適用されます。

• PROCESSES初期化パラメータが、アウトバウンド・サーバーのバックグラウンド・プロセスとその他のOracle Databaseバックグラウンド・プロセスすべてを受け入れるのに十分な大きさの値に設定されていることを確認してください。

• SESSIONS初期化パラメータが、アウトバウンド・サーバーのバックグラウンド・プロセスによって使用されるセッションとその他のすべてのOracle Databaseセッションを受け入れるのに十分な大きさの値に設定されていることを確認してください。

4.1.2.6 Streamsプールの構成

Streamsプールは、Oracle StreamsおよびXStreamコンポーネントの両方で使用されるシステム・グローバル領域(SGA)内のメモリーの一部です。

Streamsプールは、バッファ・キューLCRをメモリー内に格納し、取得プロセスおよびアウトバウンド・サーバーにメモリーを提供します。

Streamsプールの構成に関する考慮事項は次のとおりです。

• Streamsプールには300MB以上のメモリーが必要です。

• XStream Outを構成したら、max_sga_size取得プロセス・パラメータを使用して、取得プロセス専用に割り当てられたシステム・グローバル領域(SGA)メモリーの量を制御できます。

  データベース上のすべてのコンポーネントに割り当てられたシステムグローバル領域(SGA)メモリーは、合計でSTREAMS_POOL_SIZE初期化パラメータに設定されている値未満である必要があります。

• XStream Outを構成したら、max_sga_size適用パラメータを使用して、アウトバウンド・サーバー専用に割り当てられるSGAメモリーの量を制御できます。

• 各データベースのStreamsプールに、XStreamコンポーネントを実行してLCRを格納し、コンポーネントを正しく実行するために十分な容量があることを確認してください。

• Streamsプールは、アウトバウンド・サーバーが最初に起動されるときに初期化されます。

• ベスト・プラクティスは、STREAMS_POOL_SIZE初期化パラメータを必要なStreamsプール・サイズに明示的に設定することです。

次の条件が満たされる場合、自動共有メモリー管理機能によってStreamsプールのサイズが自動的に管理されます。

• MEMORY_TARGETおよびMEMORY_MAX_TARGET初期化パラメータの両方が0(ゼロ)に設定されている。

• SGA_TARGET初期化パラメータが0(ゼロ)以外の値に設定されている。

次の条件が満たされる場合、Streamsプール・サイズはSTREAMS_POOL_SIZEパラメータによって指定される値(バイト単位)になります。

• MEMORY_TARGET、MEMORY_MAX_TARGETおよびSGA_TARGET初期化パラメータがすべて0(ゼロ)に設定されている。

• STREAMS_POOL_SIZE初期化パラメータが0(ゼロ)以外の値に設定されている。

自動共有メモリー管理を使用している場合に、STREAMS_POOL_SIZE初期化パラメータも0(ゼロ)以外の値に設定すると、自動共有メモリー管理でその値がOracle Streamsプールの最小値として使用されます。環境が適切に動作するためにOracle Streamsプールに最小メモリー量が必要な場合は、最小サイズを設定できます。自動共有メモリー管理によってOracle Streamsプールに割り当てられている現行のメモリーを表示するには、V$SGA_DYNAMIC_COMPONENTSビューを問い合せます。また、V$STREAMS_POOL_STATISTICSビューを問い合せて、Oracle Streamsプールの現在の使用状況を表示できます。

関連項目:

• max_sga_size取得プロセス・パラメータの詳細は、Oracle Database PL/SQLパッケージおよびタイプ・リファレンスを参照してください

• Oracle Database管理者ガイド

• Oracle Databaseリファレンス

4.1.2.7 必要な場合のサプリメンタル・ロギングの構成

取得プロセスを使用して変更を取得する場合は、列に対する変更が宛先データベースで正常に適用されるように、ソース・データベースで特定の列にサプリメンタル・ロギングを指定する必要があります。

サプリメンタル・ロギングによって、これらの列に関する追加の情報がREDOログに記録されます。この追加の情報は、取得プロセスによって取得されて論理変更レコード(LCR)に含められ、XStreamインバウンド・サーバーまたはクライアント・アプリケーションによって変更を適切に処理するために必要とされる場合があります。

• XStream環境内の必要なサプリメンタル・ロギング
  サプリメンタル・ロギングには、データベース・サプリメンタル・ロギングと表サプリメンタル・ロギングの2種類があります。
• 無条件ログ・グループを使用した表サプリメンタル・ロギングの指定
  無条件ログ・グループを使用してサプリメンタル・ロギングを指定できます。
• 条件付きログ・グループを使用した表サプリメンタル・ロギングの指定
  条件付きログ・グループを使用して表サプリメンタル・ロギングを指定できます。
• サプリメンタル・ログ・グループの削除
  条件付きまたは無条件のサプリメンタル・ログ・グループを削除するには、ALTER TABLE文にDROP SUPPLEMENTAL LOG GROUP句を使用します。
• キー列のデータベース・サプリメンタル・ロギングの指定
  ソース・データベース内のすべての主キー列、一意キー列、ビットマップ索引列および外部キー列について、サプリメンタル・ロギングを指定するオプションがあります。
• キー列のデータベース・サプリメンタル・ロギングの削除
  ソース・データベース内のすべての主キー列、一意キー列、ビットマップ索引列および外部キー列のサプリメンタル・ロギングを削除するには、ALTER DATABASE DROP SUPPLEMENTAL LOG DATA文を発行します。
• サプリメンタル・ロギングを自動的に指定するプロシージャ
  DBMS_CAPTURE_ADMパッケージの一部のプロシージャでは、サプリメンタル・ロギングが自動的に指定されます。

4.1.2.7.1 XStream環境内の必要なサプリメンタル・ロギング

サプリメンタル・ロギングには、データベース・サプリメンタル・ロギングと表サプリメンタル・ロギングの2種類があります。

データベース・サプリメンタル・ロギングではデータベース全体のサプリメンタル・ロギングが指定されますが、表サプリメンタル・ロギングでは、特定の表のサプリメンタル・ロギングに使用するログ・グループを指定できます。表サプリメンタル・ロギングを使用する場合は、無条件ログ・グループと条件付きログ・グループのどちらかを選択できます。

無条件ログ・グループでは、表が変更されると、指定した列が変更の影響を受けるかどうかに関係なく、その列のビフォア・イメージがログに記録されます。無条件ログ・グループは、「常時ログ・グループ」と呼ばれることがあります。条件付きログ・グループでは、ログ・グループ内の少なくとも1列が変更される場合にのみ、指定したすべての列のビフォア・イメージがログに記録されます。

データベース・レベルのサプリメンタル・ロギング、表レベルの無条件ログ・グループおよび表レベルの条件付きログ・グループによって、変更ログに記録する古い値が決定されます。

取得プロセスによって取得されたLCRを、1つ以上のXStreamインバウンド・サーバーを使用して適用する予定の場合は、宛先データベースの表内にある次のタイプの列について、ソース・データベースでサプリメンタル・ロギングを使用可能にする必要があります。

• 宛先データベースで変更が適用される表の主キーに使用されるソース・データベースの列はすべて、ログ・グループに無条件でログを記録するか、主キー列のデータベース・サプリメンタル・ロギングによってログを記録する必要があります。

• 変更を適用するインバウンド・サーバーの並列性が1より大きい場合、ソース・データベースの複数の列に基づく宛先データベースの一意制約列は、条件付きでログに記録する必要があります。一意制約列がソース・データベースの1つの列に基づく場合は、サプリメンタル・ロギングを指定する必要はありません。

• 変更を適用するインバウンド・サーバーの並列性が1より大きい場合、ソース・データベースの複数の列に基づく宛先データベースの外部キー列は、条件付きでログに記録する必要があります。外部キー列がソース・データベースの1つの列に基づく場合は、サプリメンタル・ロギングを指定する必要はありません。

• 変更を適用するインバウンド・サーバーの並列性が1より大きい場合、ソース・データベースの複数の列に基づく宛先データベースのビットマップ索引列は、条件付きでログに記録する必要があります。ビットマップ索引列がソース・データベースの1つの列に基づく場合は、サプリメンタル・ロギングを指定する必要はありません。

• 宛先データベースでインバウンド・サーバーの代替キー列として使用されるソース・データベースの列は、無条件でログに記録する必要があります。表の代替キー列を指定するには、DBMS_APPLY_ADMパッケージのSET_KEY_COLUMNSプロシージャを使用します。

• ソース・データベースの複数の列が宛先データベースの列リストに使用されている場合、適用時に競合解消用の列リストで指定された列は、条件付きでログに記録する必要があります。

• 宛先データベースの文DMLハンドラ、変更ハンドラ、プロシージャDMLハンドラまたはエラー・ハンドラで使用されるソース・データベースの列は、無条件でログに記録する必要があります。

• ルールまたはルールベースの変換で使用されるソース・データベースの列は、無条件でログに記録する必要があります。

• 宛先データベースで値の仮想依存性定義に指定されているソース・データベースの列は、無条件でログに記録する必要があります。

• 宛先データベースで表の行のサブセット化を指定する場合は、宛先表に含まれるソース・データベースの列またはサブセット条件に含まれるソース・データベースの列を、無条件でログに記録する必要があります。インバウンド・サーバーの行のサブセット化条件を指定するには、DBMS_XSTREAM_ADMパッケージのADD_SUBSET_RULESプロシージャでdml_conditionパラメータを使用します。

ソース・データベースでこれらのタイプの列にサプリメンタル・ロギングを使用しないと、これらの列が関係する変更は宛先データベースで正しく適用されない可能性があります。

注意:

LOB、LONG、LONG RAW、ユーザー定義型(オブジェクト型、REF、VARRAY、ネストした表など)およびOracle提供の型(Any型、XML型、空間型、メディア型など)のデータ型の列は、サプリメンタル・ログ・グループに含めることはできません。

4.1.2.7.2 無条件ログ・グループを使用した表サプリメンタル・ロギングの指定

無条件ログ・グループを使用してサプリメンタル・ロギングを指定できます。

表の主キー列のみを含む無条件のサプリメンタル・ログ・グループを指定するには、ADD SUPPLEMENTAL LOG DATA句にPRIMARY KEYオプションを指定してALTER TABLE文を実行します。たとえば、次の文ではシステム生成名を使用して、無条件のログ・グループにhr.regions表の主キー列が追加されます。

ALTER TABLE hr.regions ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

表のすべての列を含む無条件のサプリメンタル・ログ・グループを指定するには、ADD SUPPLEMENTAL LOG DATA句にALLオプションを指定して、ALTER TABLE文を実行します。たとえば、次の文ではシステム生成名を使用して、無条件のログ・グループにhr.regions表のすべての列が追加されます。

ALTER TABLE hr.regions ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

ユーザーが選択した列を含む無条件のサプリメンタル・ログ・グループを指定するには、ADD SUPPLEMENTAL LOG GROUP句にALWAYSを指定して、ALTER TABLE文を使用します。これらのログ・グループにはキー列を含めることができます(必要な場合)。

たとえば、次の文では、無条件のログ・グループlog_group_dep_pkにhr.departments表のdepartment_id列およびmanager_id列が追加されます。

ALTER TABLE hr.departments ADD SUPPLEMENTAL LOG GROUP log_group_dep_pk
  (department_id, manager_id) ALWAYS;

ALWAYS指定があるため、このログ・グループは無条件のログ・グループになります。

4.1.2.7.3 条件付きログ・グループを使用した表サプリメンタル・ロギングの指定

条件付きログ・グループを使用して表サプリメンタル・ロギングを指定できます。

ALTER TABLE文のADD SUPPLEMENTAL LOG DATA句で、次のオプションを使用できます。

• FOREIGN KEYオプション: 表の外部キー列を含む条件付きログ・グループが作成されます。

• UNIQUEオプション: 表の一意キー列およびビットマップ索引列を含む条件付きログ・グループが作成されます。

1つのALTER TABLE文に複数のオプションを指定する場合、各オプションに対して個別の条件付きログ・グループが作成されます。

たとえば、次の文では、2つの条件付きログ・グループが作成されます。

ALTER TABLE hr.employees ADD SUPPLEMENTAL LOG DATA 
  (UNIQUE, FOREIGN KEY) COLUMNS;

一方の条件付きログ・グループには表の一意キー列およびビットマップ索引列が含まれ、他方には表の外部キー列が含まれます。どちらのログ・グループもシステム生成名を持ちます。

注意:

UNIQUEオプションを指定した場合、ビットマップ結合索引列のサプリメンタル・ロギングは有効になりません。

追加するように選択したすべての列を含む条件付きのサプリメンタル・ログ・グループを指定するには、ADD SUPPLEMENTAL LOG GROUP句を指定して、ALTER TABLE文を実行します。ログ・グループを条件付きにするには、ALWAYS指定を含めないでください。

たとえば、hr.jobs表のmin_salaryおよびmax_salary列が、宛先データベースで競合解消用の列リストに含まれているとします。次の文では、min_salaryおよびmax_salary列が条件付きのログ・グループlog_group_jobs_crに追加されます。

ALTER TABLE hr.jobs ADD SUPPLEMENTAL LOG GROUP log_group_jobs_cr 
  (min_salary, max_salary);

4.1.2.7.4 サプリメンタル・ログ・グループの削除

条件付きまたは無条件のサプリメンタル・ログ・グループを削除するには、ALTER TABLE文にDROP SUPPLEMENTAL LOG GROUP句を使用します。

たとえば、サプリメンタル・ログ・グループlog_group_jobs_crを削除するには、次の文を実行します。

ALTER TABLE hr.jobs DROP SUPPLEMENTAL LOG GROUP log_group_jobs_cr;

4.1.2.7.5 キー列のデータベース・サプリメンタル・ロギングの指定

ソース・データベース内のすべての主キー列、一意キー列、ビットマップ索引列および外部キー列について、サプリメンタル・ロギングを指定するオプションがあります。

データベース全体に対する変更を取得するように取得プロセスを構成する場合は、このオプションを選択できます。ソース・データベース内のすべての主キー列、一意キー列、ビットマップ索引列および外部キー列のサプリメンタル・ロギングを指定するには、次のSQL文を発行します。

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA 
   (PRIMARY KEY, UNIQUE, FOREIGN KEY) COLUMNS;

主キー列、一意キー列、ビットマップ索引列および外部キー列がすべてのソース・データベースと宛先データベースで同一の場合に、このコマンドをソース・データベースで実行すると、すべての宛先データベースで主キー列、一意キー列、ビットマップ索引列および外部キー列に必要なサプリメンタル・ロギングが提供されます。PRIMARY KEYオプションを指定した場合に、表が変更されると、行の主キーのすべての列がREDOログ・ファイルに記録されます(無条件ロギング)。UNIQUEオプションを指定した場合に、一意キーまたはビットマップ索引に属するいずれかの列が変更されると、行の一意キーおよびビットマップ索引のすべての列がREDOログ・ファイルに記録されます(条件付きロギング)。FOREIGN KEYオプションを指定した場合に、外部キーに属するいずれかの列が変更されると、行の外部キーのすべての列がREDOログ・ファイルに記録されます(条件付きロギング)。

これらのオプションの1つ以上を省略できます。たとえば、データベースのすべての外部キー列に対してサプリメンタル・ロギングが必要でない場合、次の例に示すとおり、FOREIGN KEYオプションを省略できます。

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA 
   (PRIMARY KEY, UNIQUE) COLUMNS;

PRIMARY KEY、UNIQUEおよびFOREIGN KEYのみでなく、ALLオプションを使用することもできます。ALLオプションを指定すると、行が変更された場合に、その行のすべての列(LOB、LONG、LONG RAW、ユーザー定義型およびOracleが提供する型の列を除く)がREDOログ・ファイルに記録されます(無条件ロギング)。

サプリメンタル・ロギング文は累積的に実行されます。異なる識別キーを指定して2つのALTER DATABASE ADD SUPPLEMENTAL LOG DATA文を連続して発行すると、どちらのキーに対してもサプリメンタル・ロギングが行われます。

注意:

UNIQUEオプションを指定した場合、ビットマップ結合索引列のサプリメンタル・ロギングは有効になりません。

関連項目:

データ型の詳細は、Oracle Database SQL言語リファレンスを参照してください。

4.1.2.7.6 キー列のデータベース・サプリメンタル・ロギングの削除

ソース・データベース内のすべての主キー列、一意キー列、ビットマップ索引列および外部キー列のサプリメンタル・ロギングを削除するには、ALTER DATABASE DROP SUPPLEMENTAL LOG DATA文を発行します。

たとえば、すべての主キー列、一意キー列、ビットマップ索引列および外部キー列のデータベース・サプリメンタル・ロギングを削除するには、次のSQL文を発行します。

ALTER DATABASE DROP SUPPLEMENTAL LOG DATA 
  (PRIMARY KEY, UNIQUE, FOREIGN KEY) COLUMNS;

注意:

キー列のデータベース・サプリメンタル・ロギングを削除しても、既存の表レベルのサプリメンタル・ログ・グループには影響しません。

4.1.2.7.7 サプリメンタル・ロギングを自動的に指定するプロシージャ

DBMS_CAPTURE_ADMパッケージの一部のプロシージャでは、サプリメンタル・ロギングが自動的に指定されます。

DBMS_CAPTURE_ADMパッケージの次のプロシージャでは、サプリメンタル・ロギングが自動的に指定されます。

• BUILD

• PREPARE_GLOBAL_INSTANTIATION

• PREPARE_SCHEMA_INSTANTIATION

• PREPARE_TABLE_INSTANTIATION

BUILDプロシージャでは、ALTER DATABASE ADD SUPPLEMENTAL LOG DATA文を実行することで、データベース・サプリメンタル・ロギングが自動的に指定されます。ほとんどの場合、BUILDプロシージャは取得プロセスの作成時に自動的に実行されます。

PREPARE_GLOBAL_INSTANTIATION、PREPARE_SCHEMA_INSTANTIATIONおよびPREPARE_TABLE_INSTANTIATIONプロシージャでは、インストール用に準備された表の主キー列、一意キー列、ビットマップ索引列および外部キー列のサプリメンタル・ロギングが自動的に指定されます。

DBMS_XSTREAM_ADMパッケージ内の特定のプロシージャは、前にリストした、ADD_SUBSET_RULES、ADD_TABLE_RULES、ADD_SCHEMA_RULES、ADD_GLOBAL_RULESなどのプロシージャを自動的に実行します。

関連項目:

これらのプロシージャの詳細は、Oracle Database PL/SQLパッケージおよびタイプ・リファレンスを参照してください

4.1.2.8 必要な場合のダウンストリーム・データベースへのログ・ファイルの転送の構成

ローカル取得プロセスを使用するように決定した場合は、ログ・ファイルの転送は不要です。ただし、REDO転送サービスを使用してアーカイブREDOログ・ファイルをダウンストリーム・データベースに自動的に転送するダウンストリーム取得を使用するように決定した場合は、ソース・データベースから取得データベースへのログ・ファイルの転送を構成します。

この決定の詳細は、「XStream Outの構成方法の決定」を参照してください。

ヒント:

Oracle Enterprise Manager Cloud Controlを使用して、ログ・ファイルの転送およびダウンストリーム取得プロセスを構成できます。手順については、Oracle Enterprise Manager Cloud Controlのオンライン･ヘルプを参照してください。

この項の手順では、ソース・データベースのREDOログ・ファイルを取得データベースに転送するように構成し、取得データベースでそれらのREDOログ・ファイルを受け入れるように構成します。

ダウンストリーム・データベースへのログ・ファイル転送を構成するには、次のようにします。

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

   関連項目:

   Oracle Database Net Services管理者ガイド

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

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

   関連項目:

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

3. ソース・データベースからダウンストリーム・データベースにREDOデータを転送するREDO転送サービスを構成するために、ソース・データベースで次の初期化パラメータを設定します。

   • LOG_ARCHIVE_DEST_n: ダウンストリーム・データベースにREDOデータを送信するように1つ以上のLOG_ARCHIVE_DEST_n初期化パラメータを設定します。このパラメータの次の属性を次の方法で設定します。

     • SERVICE: ダウンストリーム・データベースのネットワーク・サービス名を指定します。

     • ASYNCまたはSYNC: REDO転送モードを指定します。

       ASYNCを指定するメリットは、ソース・データベースのパフォーマンスにほとんど影響を与えないことです。ダウンストリーム・データベースまたはネットワークのパフォーマンスが低い場合は、ASYNCを使用してソース・データベースのパフォーマンスへの影響を回避することをお薦めします。

       SYNCを指定するメリットは、ASYNCを指定した場合より高速にダウンストリーム・データベースにREDOデータが送信されることです。また、SYNC AFFIRMを指定すると、MAXIMUM AVAILABILITYスタンバイ保護モードと同様に動作します。ALTER DATABASE STANDBY DATABASE TO MAXIMIZE AVAILABILITY SQL文を指定しても、XStreamの取得プロセスには影響しないことに注意してください。

     • 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初期化パラメータに指定した名前を使用します。

     次に、リアルタイム・ダウンストリーム取得プロセスにダウンストリーム・データベースdbs2を指定するLOG_ARCHIVE_DEST_n設定の例を示します。

     LOG_ARCHIVE_DEST_2='SERVICE=DBS2.EXAMPLE.COM ASYNC NOREGISTER
        VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
        DB_UNIQUE_NAME=dbs2'
     

     次に、アーカイブ・ログ・ダウンストリーム取得プロセスにダウンストリーム・データベース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'
     

     リアルタイム・ダウンストリーム取得とアーカイブ・ログ・ダウンストリーム取得の違いの詳細は、XStream Outの構成方法の決定を参照してください。

     ヒント:

     アーカイブ・ログ・ダウンストリーム取得プロセスを構成している場合は、リモート・ソース・データベースからのログ・ファイルとローカル・データベースのログ・ファイルを別々に保持するTEMPLATE属性の値を指定してください。また、ダウンストリーム・データベースに複数のソース・データベースからのログ・ファイルが含まれている場合、各ソース・データベースからのログ・ファイルを個別に格納する必要があります。

   • LOG_ARCHIVE_DEST_STATE_n: ダウンストリーム・データベースのLOG_ARCHIVE_DEST_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概要および管理を参照してください

4. ダウンストリーム・データベースで、ソース・データベースおよびダウンストリーム・データベースの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の送受信が可能になります。

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

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

これらの手順が完了すると、リアルタイム・ダウンストリーム取得プロセスを構成する必要がある場合に、ダウンストリーム・データベースにスタンバイREDOログ・ファイルを追加できます。この場合、必要な場合のリアルタイム・ダウンストリーム取得のためのスタンバイREDOログの追加の手順を参照してください。

4.1.2.9 必要な場合のリアルタイム・ダウンストリーム取得のためのスタンバイREDOログの追加

リアルタイム・ダウンストリーム取得を構成するように決定した場合、スタンバイREDOログを取得データベースに追加します。

この決定の詳細は、「XStream Outの構成方法の決定」を参照してください。

この項の例では、ダウンストリーム・データベースでスタンバイREDOログを追加します。スタンバイREDOログは、リアルタイム・ダウンストリーム取得プロセスを構成するために必要です。この例では、ソース・データベースはdbs1.example.com、ダウンストリーム・データベースはdbs2.example.comです。

この項の手順は、リアルタイム・ダウンストリーム取得を構成している場合にのみ実行する必要があります。アーカイブ・ログ・ダウンストリーム取得を構成している場合、この項の手順は実行しないでください。

リアルタイム・ダウンストリーム取得のためのスタンバイREDOログを追加するには、次のようにします。

1. 必要な場合のダウンストリーム・データベースへのログ・ファイルの転送の構成の手順を実行します。

2. ダウンストリーム・データベースで、次の初期化パラメータを設定して、ローカルに生成されるREDOデータのアーカイブを構成します。

   • LOG_ARCHIVE_DEST_n初期化パラメータで、ダウンストリーム・データベースを実行中のコンピュータ・システム上のディレクトリまたは高速リカバリ領域のいずれかになるよう、アーカイブ・ログの宛先を少なくとも1つ設定します。このパラメータの次の属性を次の方法で設定します。

     • LOCATION: ディスク・ディレクトリの有効なパス名を指定するか、または高速リカバリ領域を使用するためにUSE_DB_RECOVERY_FILE_DESTを指定します。この場所は、スタンバイREDOログから書き込まれるアーカイブREDOログ・ファイルのローカルの宛先です。リモート・ソース・データベースからのログ・ファイルは、ローカル・データベースのログ・ファイルとは別々に保持する必要があります。高速リカバリ領域の構成の詳細は、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドを参照してください。

     • 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を指定します。この場所は、スタンバイREDOログから書き込まれるアーカイブREDOログ・ファイルのローカルの宛先です。リモート・ソース・データベースからのログ・ファイルは、ローカル・データベースのログ・ファイルとは別々に保持する必要があります。高速リカバリ領域の構成の詳細は、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドを参照してください。

     • 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で、データベース上でインスタンスを実行中に初期化パラメータをリセットした場合、データベースが再起動されたときに新しい値が保持されるように、それらのパラメータを関連する初期化パラメータ・ファイルでもリセットする必要があります。

   手順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以上にする必要があります。ソース・データベースでV$LOGビューを問い合せて、ソース・データベースのREDOログ・ファイルのサイズ(バイト単位)を確認できます。

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

      SELECT BYTES FROM V$LOG;
      

   3. ダウンストリーム・データベースで必要なスタンバイ・ログ・ファイル・グループの数を決定します。

      スタンバイ・ログ・ファイル・グループの数は、ソース・データベースのオンライン・ログ・ファイル・グループの数より1つ以上多くする必要があります。たとえば、ソース・データベースに2つのオンライン・ログ・ファイル・グループが存在する場合、ダウンストリーム・データベースには3つ以上のスタンバイ・ログ・ファイル・グループが必要です。

      単一インスタンス・データベースでソース・データベースのV$LOGビューを問い合せるか、またはデータベース・クラスタのGV$LOGビューを問い合せることで、ソース・データベースのオンライン・ログ・ファイル・グループの数を判別できます。

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

      SELECT COUNT(GROUP#) FROM GV$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
      

   7. ソース・データベースからのログ・ファイルが手順3でLOCATION属性に指定した場所に存在することを確認します。ディレクトリ内のファイルを確認するには、ソース・データベースのログ・ファイルを切り替える必要がある場合があります。

これらの手順が完了すると、リアルタイム・ダウンストリーム取得プロセスを構成できます。

ヒント:

Oracle Enterprise Manager Cloud Controlを使用して、リアルタイム・ダウンストリーム取得を構成できます。手順については、Oracle Enterprise Manager Cloud Controlのオンライン･ヘルプを参照してください。

4.2 XStream Outの構成

XStream Out構成のアウトバウンド・サーバーは、Oracleデータベースの変更をクライアント・アプリケーションにストリームします。

クライアント・アプリケーションは、Oracle Call Interface(OCI)またはJavaインタフェースを使用してアウトバウンド・サーバーに連結し、これらの変更を受け取ります。

アウトバウンド・サーバーの構成には、取得されたデータベース変更をアウトバウンド・サーバーに送信するコンポーネントの作成が含まれます。また、アウトバウンド・サーバー自体の構成も含まれ、これにはクライアント・アプリケーションがアウトバウンド・サーバーに連結するために使用する接続ユーザーの指定も含まれます。

DBMS_XSTREAM_ADMパッケージの次のプロシージャを使用して、アウトバウンド・サーバーを作成できます。

• CREATE_OUTBOUNDプロシージャは、アウトバウンド・サーバー、キューおよび取得プロセスを1回のプロシージャ・コールで単一データベースに作成します。

• ADD_OUTBOUNDプロシージャは、アウトバウンド・サーバーを作成したり、既存のXStream Out構成にアウトバウンド・サーバーを追加したりできます。既存のXStream Out構成を持たないデータベースでこのプロシージャを使用すると、アウトバウンド・サーバーの作成のみが実行されます。取得プロセスとキューを個別に作成する必要があり、これらはADD_OUTBOUNDプロシージャを実行する前に存在する必要があります。取得プロセスは、アウトバウンド・サーバーと同じデータベースまたは別のデータベースに構成できます。

いずれの場合も、アウトバウンド・サーバーと通信し、アウトバウンド・サーバーからLCRを受信するクライアント・アプリケーションを作成する必要があります。

複数のアウトバウンド・サーバーが必要な場合は、CREATE_OUTBOUNDプロシージャを使用して、最初のアウトバウンド・サーバーのデータベース変更を取得する取得プロセスを作成できます。次に、ADD_OUTBOUNDプロシージャを実行して、取得された同じ変更内容を取得する追加のアウトバウンド・サーバーを追加できます。取得プロセスは、アウトバウンド・サーバーと同じデータベースまたは別のデータベースに存在できます。

また、CDBでXStream Outを構成する場合は特別な考慮事項があります。この項では、CDBでアウトバウンド・サーバーを作成する手順を説明します。

ヒント:

複数のアウトバウンド・サーバーを持つXStream Out構成のベスト・プラクティスは、すべてのアウトバウンド・サーバーの変更を取得する1つの取得プロセスを作成することです。

• CREATE_OUTBOUNDを使用したアウトバウンド・サーバーの構成
  DBMS_XSTREAM_ADMパッケージのCREATE_OUTBOUNDプロシージャは、単一のデータベース内に取得プロセス、キューおよびアウトバウンド・サーバーを作成します。
• 取得プロセス・ストリームへのアウトバウンド・サーバーの追加
  XStream Out構成では多くの場合、1つの取得プロセスからのLCRのストリームを処理する複数のアウトバウンド・サーバーが必要です。少なくとも1つのアウトバウンド・サーバーが含まれているデータベースに追加のアウトバウンド・サーバーを追加できます。
• ADD_OUTBOUNDを使用したアウトバウンド・サーバーの構成
  DBMS_XSTREAM_ADMパッケージのADD_OUTBOUNDプロシージャは、アウトバウンド・サーバーを作成します。
• CDB内でのXStream Outの構成
  CDB内でXStream Outを構成する場合、XStream Outによって取得されてクライアント・アプリケーションに送信される対象となるデータベース変更を決定する必要があります。XStream Outは、CDBルート、すべてのPDB、すべてのアプリケーション・ルートおよびすべてのアプリケーションPDBを含むすべてのコンテナのすべてのデータベース変更をストリームできます。また、XStream Outは特定のコンテナの変更をストリームすることもできます。

4.2.1 CREATE_OUTBOUNDを使用したアウトバウンド・サーバーの構成

DBMS_XSTREAM_ADMパッケージのCREATE_OUTBOUNDプロシージャは、単一のデータベース内に取得プロセス、キューおよびアウトバウンド・サーバーを作成します。

取得プロセスとアウトバウンド・サーバーの両方が、プロシージャによって作成されたキューを使用します。プロシージャを実行するとき、ユーザーが新規のアウトバウンド・サーバーの名前を指定し、プロシージャによって取得プロセスおよびキューの名が生成されます。すべてのコンポーネントを同じデータベース上で実行させる場合、CREATE_OUTBOUNDプロシージャは、アウトバウンド・サーバーを作成するための最も速く、簡単な方法です。

前提条件

XStream Outを構成する前に、次の前提条件が満たされていることを確認します。

• XStream Outの構成の前提条件で説明されているタスクが完了している。

前提条件

この項では、次のことを想定しています。

• 取得プロセスはローカル取得プロセスで、アウトバウンド・サーバーと同じデータベースで実行されます。

  この項の手順は、XStream Outの構成方法の決定に記載されている、同じデータベース構成上のローカル取得およびアウトバウンド・サーバーのみ設定できます。

• アウトバウンド・サーバーの名前はxoutです。

• oe.orders表およびoe.order_items表に対して行われたデータ操作言語(DML)およびデータ定義言語(DDL)の変更は、アウトバウンド・サーバーに送信されます。

• hrスキーマに対して行われたDMLおよびDDLの変更は、アウトバウンド・サーバーに送信されます。

図4-5は、このXStream Out構成の概要を示したものです。

図4-5 CREATE_OUTBOUNDを使用して作成されたXStream Out構成の例

「図4-5 CREATE_OUTBOUNDを使用して作成されたXStream Out構成の例」の説明

CREATE_OUTBOUNDプロシージャを使用してアウトバウンド・サーバーを作成するには、次のようにします。

1. SQL*Plusで、データベースにXStream管理者として接続します。

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

2. CREATE_OUTBOUNDプロシージャを実行します。

   この項の前提で、次のCREATE_OUTBOUNDプロシージャを実行します。

   DECLARE
     tables  DBMS_UTILITY.UNCL_ARRAY;
     schemas DBMS_UTILITY.UNCL_ARRAY;
   BEGIN
       tables(1)  := 'oe.orders';
       tables(2)  := 'oe.order_items';
       schemas(1) := 'hr';
     DBMS_XSTREAM_ADM.CREATE_OUTBOUND(
       server_name     =>  'xout',
       table_names     =>  tables,
       schema_names    =>  schemas);
   END;
   /
   

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

   • oe.orders表、oe.order_items表およびhrスキーマ内のすべての表のサプリメンタル・ロギングを構成します。

   • 取得プロセスおよびアウトバウンド・サーバーで使用されるシステム生成名でキューを作成します。

   • oe.orders表、oe.order_items表およびhrスキーマに対するDMLおよびDDLの変更を取得するよう指示するルール・セットを使用する、システム生成名を持つ取得プロセスを作成して起動します。

   • oe.orders表、oe.order_items表およびhrスキーマに対するDMLおよびDDLの変更をクライアント・アプリケーションに送信するよう指示するルール・セットを使用する、xoutという名前のアウトバウンド・サーバーを作成して起動します。

   • 現在のユーザーをアウトバウンド・サーバーの接続ユーザーとして設定します。この例では、現在のユーザーはXStream管理者です。クライアント・アプリケーションは、アウトバウンド・サーバーと対話するために接続ユーザーとしてデータベースに接続する必要があります。

   注意:

   server_name値は30バイトを超えることはできません。

   ヒント:

   すべてのデータベース変更を取得してアウトバウンド・サーバーに送信するには、table_namesおよびschema_namesパラメータをNULL(デフォルト)に指定します。

3. アウトバウンド・サーバーに接続してLCRを受信するクライアント・アプリケーションを作成して実行します。サンプル・アプリケーションについては、「サンプルXStreamクライアント・アプリケーション」を参照してください。

4. 手順2で作成された取得プロセスからLCRを受信する1つ以上の追加のアウトバウンド・サーバーを追加するには、「取得プロセス・ストリームへのアウトバウンド・サーバーの追加」の手順に従います。

クライアント・アプリケーションを実行すると、アウトバウンド・サーバーが自動的に起動します。

関連項目:

Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス

4.2.2 取得プロセス・ストリームへのアウトバウンド・サーバーの追加

XStream Out構成では多くの場合、1つの取得プロセスからのLCRのストリームを処理する複数のアウトバウンド・サーバーが必要です。少なくとも1つのアウトバウンド・サーバーが含まれているデータベースに追加のアウトバウンド・サーバーを追加できます。

追加されたアウトバウンド・サーバーは、別のアウトバウンド・サーバーと同じキューを使用して取得プロセスからLCRを受信します。XStream Out環境が存在する場合は、DBMS_XSTREAM_ADMパッケージのADD_OUTBOUNDプロシージャを使用して、取得プロセス・ストリームに別のアウトバウンド・サーバーを追加します。

前提条件

この項の手順を実行する前に、少なくとも1つのアウトバウンド・サーバーが含まれているXStream Out環境を構成します。次の項では、XStream Out環境の構成について説明します。

• CREATE_OUTBOUNDを使用したアウトバウンド・サーバーの構成

• ADD_OUTBOUNDを使用したアウトバウンド・サーバーの構成

前提条件

この項では、次のことを想定しています。

• アウトバウンド・サーバーの名前はxout2です。

• アウトバウンド・サーバーによって使用されるキューは、xstrmadmin.xstream_queueです。

• oe.orders表およびoe.order_items表に対して行われたDMLおよびDDLの変更は、アウトバウンド・サーバーに送信されます。

• hrスキーマに対して行われたDMLおよびDDLの変更は、アウトバウンド・サーバーに送信されます。

• データベース変更のソース・データベースは、db1.example.comです。

図4-6は、このXStream Out構成の概要を示したものです。

図4-6 アウトバウンド・サーバーが追加されたXStream Out構成の例

「図4-6 アウトバウンド・サーバーが追加されたXStream Out構成の例」の説明

ADD_OUTBOUNDプロシージャを使用して取得プロセス・ストリームに別のアウトバウンド・サーバーを追加するには、次のようにします。

1. SQL*Plusで、追加のアウトバウンド・サーバーを実行するデータベースにXStream管理者として接続します。

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

2. 取得プロセスからLCRを受信する既存のアウトバウンド・サーバーで使用されるキューの名前を確認します。

   アウトバウンド・サーバーに関する一般情報の表示の問合せを実行して、キューの所有者および名前を確認します。この問合せでは、取得プロセスの名前およびソース・データベース名も表示されます。

3. ADD_OUTBOUNDプロシージャを実行します。

   この項の前提で、次のADD_OUTBOUNDプロシージャを実行します。

   DECLARE
     tables  DBMS_UTILITY.UNCL_ARRAY;
     schemas DBMS_UTILITY.UNCL_ARRAY;
   BEGIN
       tables(1)  := 'oe.orders';
       tables(2)  := 'oe.order_items';
       schemas(1) := 'hr';
     DBMS_XSTREAM_ADM.ADD_OUTBOUND(
       server_name     =>  'xout2',
       queue_name      =>  'xstrmadmin.xstream_queue',
       source_database =>  'db1.example.com',
       table_names     =>  tables,
       schema_names    =>  schemas);
   END;
   /
   

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

   • xout2という名前のアウトバウンド・サーバーを作成します。アウトバウンド・サーバーには、oe.orders表、oe.order_items表およびhrスキーマに対するDMLおよびDDLの変更をクライアント・アプリケーションに送信するよう指示するルール・セットがあります。ルールでは、これらの変更はdb1.example.comデータベースで発生したものである必要があることを指定します。アウトバウンド・サーバーは、キューxstrmadmin.xstream_queueからLCRをデキューします。

   • 現在のユーザーをアウトバウンド・サーバーの接続ユーザーとして設定します。この例では、現在のユーザーはXStream管理者です。クライアント・アプリケーションは、アウトバウンド・サーバーと対話するために接続ユーザーとしてデータベースに接続する必要があります。

   注意:

   server_name値は30バイトを超えることはできません。

   ヒント:

   取得プロセスによって送信されたすべてのLCRをアウトバウンド・サーバーで受信するには、table_namesおよびschema_namesパラメータをNULL(デフォルト)に指定します。

4. クライアント・アプリケーションが存在しない場合は、アウトバウンド・サーバーに接続してLCRを受信するクライアント・アプリケーションを作成して実行します。サンプル・アプリケーションについては、「サンプルXStreamクライアント・アプリケーション」を参照してください。

クライアント・アプリケーションを実行すると、アウトバウンド・サーバーが自動的に起動します。

関連項目:

『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』

4.2.3 ADD_OUTBOUNDを使用したアウトバウンド・サーバーの構成

DBMS_XSTREAM_ADMパッケージのADD_OUTBOUNDプロシージャは、アウトバウンド・サーバーを作成します。

このプロシージャは、取得プロセスおよびキューを作成しません。既存のXStream Out構成を持たないデータベースでは、これらのコンポーネントを手動で構成する必要があります。

ADD_OUTBOUNDプロシージャを使用して、XStream Outの構成方法の決定に記載されているいずれかの構成を設定できます。ただし、ローカル取得とアウトバウンド・サーバーを同じデータベース上に構成することを選択した場合は、CREATE_OUTBOUNDプロシージャを使用してすべてのコンポーネントを同時に構成する方が通常は簡単です。CREATE_OUTBOUNDを使用したアウトバウンド・サーバーの構成を参照してください。

この項には、ダウンストリーム取得とアウトバウンド・サーバーを同じデータベースに構成した例があります。

前提条件

XStream Outを構成する前に、次の前提条件が満たされていることを確認します。

• XStream Outの構成の前提条件で説明されているタスクが完了している。

  ダウンストリーム取得を使用することを決定した場合は、ソース・データベースからダウンストリーム・データベースへのログ・ファイル転送を構成する必要があります。必要な場合のダウンストリーム・データベースへのログ・ファイルの転送の構成を参照してください。

  リアルタイム・ダウンストリーム取得を使用する場合は、必要なスタンバイREDOログを追加する必要もあります。必要な場合のリアルタイム・ダウンストリーム取得のためのスタンバイREDOログの追加を参照してください。

  この項の例では、ダウンストリーム取得を使用します。このため、この例を実行するにはログ・ファイル転送を構成する必要があります。

前提条件

この項では、次のことを想定しています。

• アウトバウンド・サーバーの名前はxoutです。

• アウトバウンド・サーバーによって使用されるキューは、xstrmadmin.xstream_queueです。

• ソース・データベースはdb1.example.comです。

• 取得プロセスおよびアウトバウンド・サーバーは、ソース・データベースとは異なるデータベースで実行されます。このため、ダウンストリーム取得が構成されます。

• oe.orders表およびoe.order_items表に対して行われたDMLおよびDDLの変更は、アウトバウンド・サーバーに送信されます。

• hrスキーマに対して行われたDMLおよびDDLの変更は、アウトバウンド・サーバーに送信されます。

図4-7は、このXStream Out構成の概要を示したものです。

図4-7 ADD_OUTBOUNDを使用して作成されたXStream Out構成の例

「図4-7 ADD_OUTBOUNDを使用して作成されたXStream Out構成の例」の説明

ADD_OUTBOUNDプロシージャを使用してアウトバウンド・サーバーを作成するには、次のようにします。

1. SQL*Plusで、取得プロセス(取得データベース)を実行するデータベースにXStream管理者として接続します。

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

2. 取得プロセスで使用されるキューを作成します。

   たとえば、次のプロシージャを実行します。

   BEGIN
     DBMS_XSTREAM_ADM.SET_UP_QUEUE(
       queue_table => 'xstrmadmin.xstream_queue_table',
       queue_name  => 'xstrmadmin.xstream_queue');
   END;
   /
   

3. ダウンストリーム取得データベースからソース・データベースへのデータベース・リンクを作成します。

   この例では、ダウンストリーム取得データベースからdb1.example.comへのデータベース・リンクを作成します。たとえば、ユーザーxstrmadminが両方のデータベースのXStream管理者の場合、次のようにデータベース・リンクを作成します。

   CREATE DATABASE LINK db1.example.com CONNECT TO xstrmadmin 
      IDENTIFIED BY password USING 'db1.example.com';
   

   必要な場合のネットワーク接続およびデータベース・リンクの構成を参照してください。

   データベース・リンクを作成しない場合は、ソース・データベースで次の手順を実行する必要があります。

   1. ソース・データベースにXStream管理者として接続します。

   2. DBMS_CAPTURE_ADM.BUILDプロシージャを実行します。次に例を示します。

      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
      

      このプロシージャによって、ダウンストリーム取得データベースで作成される取得プロセスの有効な先頭SCN値が表示されます。戻されたSCN値をメモし、手順4で取得プロセスを作成するときに使用できるようにしてください。

   3. 必要なサプリメンタル・ロギングが、ソース・データベースでデータベース・オブジェクトに対して指定されていることを確認してください。

      この例では、サプリメンタル・ロギングが、db1.example.comデータベースのhrスキーマ、oe.orders表およびoe.order_items表に対して構成されていることを確認します。

      サプリメンタル・ロギングの指定手順については必要な場合のサプリメンタル・ロギングの構成を参照してください。

   これらの手順は、データベース・リンクを作成する場合は不要です。

4. ダウンストリーム取得データベースに接続しているときに、取得プロセスを作成し、取得プロセスにルールを追加します。

   たとえば、次のプロシージャを実行して、取得プロセスを作成します。

   BEGIN
     DBMS_CAPTURE_ADM.CREATE_CAPTURE(
       queue_name         => 'xstrmadmin.xstream_queue',
       capture_name       => 'xout_capture',
       capture_class      => 'xstream');
   END;
   /
   

   hrスキーマ、oe.orders表およびoe.order_items表への変更を取得する取得プロセスのルール・セットにルールを追加します。

   たとえば、次のプロシージャを実行してルールを作成します。

   BEGIN
     DBMS_XSTREAM_ADM.ADD_SCHEMA_RULES(
       schema_name     => 'hr',
       streams_type    => 'capture',
       streams_name    => 'xout_capture',
       queue_name      => 'xstrmadmin.xstream_queue',
       include_dml     => TRUE,
       include_ddl     => TRUE,
       source_database => 'db1.example.com');
   END;
   /
   
   BEGIN 
     DBMS_XSTREAM_ADM.ADD_TABLE_RULES(
       table_name      =>  'oe.orders',
       streams_type    => 'capture',
       streams_name    => 'xout_capture',
       queue_name      => 'xstrmadmin.xstream_queue',
       include_dml     => TRUE,
       include_ddl     => TRUE,
       source_database => 'db1.example.com');
   END;
   /
   
   BEGIN 
     DBMS_XSTREAM_ADM.ADD_TABLE_RULES(
       table_name      =>  'oe.order_items',
       streams_type    => 'capture',
       streams_name    => 'xout_capture',
       queue_name      => 'xstrmadmin.xstream_queue',
       include_dml     => TRUE,
       include_ddl     => TRUE,
       source_database => 'db1.example.com');
   END;
   /
   

   取得プロセスは起動しないでください。

5. ADD_OUTBOUNDプロシージャを実行します。

   この項の前提で、次のADD_OUTBOUNDプロシージャを実行します。

   DECLARE
     tables  DBMS_UTILITY.UNCL_ARRAY;
     schemas DBMS_UTILITY.UNCL_ARRAY;
   BEGIN
       tables(1)  := 'oe.orders';
       tables(2)  := 'oe.order_items';
       schemas(1) := 'hr';
     DBMS_XSTREAM_ADM.ADD_OUTBOUND(
       server_name     =>  'xout',
       queue_name      =>  'xstrmadmin.xstream_queue',
       source_database =>  'db1.example.com',
       table_names     =>  tables,
       schema_names    =>  schemas);
   END;
   /
   

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

   • xoutという名前のアウトバウンド・サーバーを作成します。アウトバウンド・サーバーには、oe.orders表、oe.order_items表およびhrスキーマに対するDMLおよびDDLの変更をクライアント・アプリケーションに送信するよう指示するルール・セットがあります。ルールでは、これらの変更はdb1.example.comデータベースで発生したものである必要があることを指定します。アウトバウンド・サーバーは、キューxstrmadmin.xstream_queueからLCRをデキューします。

   • 現在のユーザーをアウトバウンド・サーバーの接続ユーザーとして設定します。この例では、現在のユーザーはXStream管理者です。クライアント・アプリケーションは、アウトバウンド・サーバーと対話するために接続ユーザーとしてデータベースに接続する必要があります。

   注意:

   server_name値は30バイトを超えることはできません。

   ヒント:

   取得プロセスによって送信されたすべてのLCRをアウトバウンド・サーバーで受信するには、table_namesおよびschema_namesパラメータをNULL(デフォルト)に指定します。

6. アウトバウンド・サーバーに接続してLCRを受信するクライアント・アプリケーションを作成して実行します。サンプル・アプリケーションについては、「サンプルXStreamクライアント・アプリケーション」を参照してください。

   クライアント・アプリケーションを実行すると、アウトバウンド・サーバーが自動的に起動します。

7. 手順4で作成された取得プロセスからLCRを受信する1つ以上の追加のアウトバウンド・サーバーを追加するには、「取得プロセス・ストリームへのアウトバウンド・サーバーの追加」の手順に従います。

関連項目:

Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス

4.2.4 CDB内でのXStream Outの構成

CDB内でXStream Outを構成する場合、XStream Outによって取得されてクライアント・アプリケーションに送信される対象となるデータベース変更を決定する必要があります。XStream Outは、CDBルート、すべてのPDB、すべてのアプリケーション・ルートおよびすべてのアプリケーションPDBを含むすべてのコンテナのすべてのデータベース変更をストリームできます。また、XStream Outは特定のコンテナの変更をストリームすることもできます。

また、XStream Outをローカル取得で構成したり、ソース・データベースからの変更を取得するために必要な作業を軽減するためにXStream Outをダウンストリーム取得で構成したりできます。

CDB内のXStream Outを構成する場合、次の制限が適用されます。

• 取得プロセスおよびアウトバウンド・サーバーはCDBルート内に存在する必要があります。

• 取得プロセスおよびアウトバウンド・サーバーは同じCDB内に存在する必要があります。

• CDB内の各コンテナは、XStream Out構成中にオープンされている必要があります。

• アプリケーション・ルートに加えられた変更が取得される場合、ALTER PLUGGABLE DATABASE APPLICATION文が他のアプリケーション・ルートにのみレプリケートされるようにする必要があります。

また、CDBに対してXStream管理者を正しく作成するようにします。

注意:

CDB以外を使用してコンテナが作成されている場合、CDB以外からのXStream Outコンポーネントをそのコンテナ内で使用できません。CDBルートのXStream Outコンポーネント(取得プロセスやアウトバウンド・サーバーなど)を削除して再作成する必要があります。

• CDB内でのローカル取得を使用したXStream Outの構成
  この例では、CDB内でローカル取得を使用したXStream Out構成を示しています。
• CDB内でのダウンストリーム取得を使用したXStream Outの構成
  ダウンストリーム取得を使用すると、XStream Outコンポーネントをソース・データベース以外のデータベースに配置できます。複数のCDBがある場合は、ソース・データベースを1つのCDB内に存在させ、ダウンストリーム取得を使用して別のCDB内の変更を取得できます。

4.2.4.1 CDB内でのローカル取得を使用したXStream Outの構成

この例では、CDB内でローカル取得を使用したXStream Out構成を示しています。

前提条件

XStream Outを構成する前に、CDB内のすべてのコンテナが、XStream Out構成中に読取り/書込みモードでオープンしていることを確認します。

前提条件

この項では、次のことを想定しています。

• 取得プロセスはローカル取得プロセスで、アウトバウンド・サーバーと同じデータベースで実行されます。

• アウトバウンド・サーバーの名前はxoutです。

• PDB pdb1.example.comのoe.orders表およびoe.order_items表に対して行われたデータ操作言語(DML)およびデータ定義言語(DDL)の変更は、アウトバウンド・サーバーに送信されます。

• PDB pdb1.example.comのhrスキーマに対して行われたDMLおよびDDLの変更は、アウトバウンド・サーバーに送信されます。

図4-8は、このXStream Out構成の概要を示したものです。

図4-8 PDBについてCREATE_OUTBOUNDを使用して作成されたXStream Out構成の例

「図4-8 PDBについてCREATE_OUTBOUNDを使用して作成されたXStream Out構成の例」の説明

CREATE_OUTBOUNDプロシージャを使用してアウトバウンド・サーバーを作成するには、次のようにします。

1. SQL*Plusで、CDB(PDB pdb1.example.comではない)のルートにXStream管理者として接続します。

2. アウトバウンド・サーバーおよび他のXStreamコンポーネントを作成します。

   1. ソースCDB内のすべてのコンテナが、読取り/書込みモードでオープンしていることを確認します。

   2. CREATE_OUTBOUNDプロシージャを実行します。

      この例の前提で、次のCREATE_OUTBOUNDプロシージャを実行します。

      DECLARE
        tables  DBMS_UTILITY.UNCL_ARRAY;
        schemas DBMS_UTILITY.UNCL_ARRAY;
      BEGIN
          tables(1)  := 'oe.orders';
          tables(2)  := 'oe.order_items';
          schemas(1) := 'hr';
        DBMS_XSTREAM_ADM.CREATE_OUTBOUND(
          server_name     =>  'xout',
          source_database =>  'pdb1.example.com',
          table_names     =>  tables,
          schema_names    =>  schemas);
      END;
      /
      

      注意:

      CDB内のすべてのコンテナ(CDBルート、すべてのPDB、すべてのアプリケーション・ルートおよびすべてのアプリケーションPDBが含まれます)の変更を取得し、これらの変更内容をXStreamクライアント・アプリケーションに送信するには、CREATE_OUTBOUNDプロシージャを実行する際にsource_databaseパラメータを省略します。

   3. CREATE_OUTBOUNDプロシージャが正常に完了した後、必要に応じて1つ以上のコンテナのオープン・モードを変更します。

   手順2.bに記載されている手順を実行すると、次のアクションが実行されます。

   • pdb1.example.com PDBのoe.orders表、oe.order_items表およびhrスキーマ内のすべての表のサプリメンタル・ロギングを構成します。

   • 取得プロセスおよびアウトバウンド・サーバーで使用されるシステム生成名でキューを作成します。

   • pdb1.example.com PDBからoe.orders表、oe.order_items表およびhrスキーマに対するDMLおよびDDLの変更を取得するよう指示するルール・セットを使用する、システム生成名を持つ取得プロセスを作成して起動します。

   • oe.orders表、oe.order_items表およびhrスキーマに対するDMLおよびDDLの変更をクライアント・アプリケーションに送信するよう指示するルール・セットを使用する、xoutという名前のアウトバウンド・サーバーを作成して起動します。

   • 現在のユーザーをアウトバウンド・サーバーの接続ユーザーとして設定します。この例では、現在のユーザーはXStream管理者です。クライアント・アプリケーションは、アウトバウンド・サーバーと対話するために接続ユーザーとしてデータベースに接続する必要があります。

   注意:

   server_name値は30バイトを超えることはできません。

   ヒント:

   pdb1.example.comデータベースからすべてのデータベース変更を取得してアウトバウンド・サーバーに送信するには、table_namesおよびschema_namesパラメータにNULL(デフォルト)を指定します。

3. CDBのルートのアウトバウンド・サーバーに接続してLCRを受信するクライアント・アプリケーションを作成して実行します。

クライアント・アプリケーションを実行すると、アウトバウンド・サーバーが自動的に起動します。

4.2.4.2 CDB内でのダウンストリーム取得を使用したXStream Outの構成

ダウンストリーム取得を使用すると、XStream Outコンポーネントをソース・データベース以外のデータベースに配置できます。複数のCDBがある場合は、ソース・データベースを1つのCDB内に存在させ、ダウンストリーム取得を使用して別のCDB内の変更を取得できます。

前提条件

XStream Outを構成する前に、次の前提条件を満たす必要があります。

• CDB内のすべてのコンテナが、XStream Out構成中に読取り/書込みモードでオープンしていることを確認します。

• この例ではダウンストリーム取得を使用します。したがって、ソース・データベースからダウンストリーム・データベースへのログ・ファイル転送を構成する必要があります。

• リアルタイム・ダウンストリーム取得を使用する場合は、必要なスタンバイREDOログを追加する必要もあります。

前提条件

この項では、次のことを想定しています。

• アウトバウンド・サーバーの名前はxoutです。

• アウトバウンド・サーバーで使用されるキューはc##xstrmadmin.xstream_queueです。

• ソース・データベースは、CDB data.example.comのPDB pdb1.example.comです。

• 取得プロセスは、CDB capture.example.comで実行されます。

• アウトバウンド・サーバーは、CDB capture.example.comで実行されます。

• PDB pdb1.example.comからoe.orders表およびoe.order_items表に対して行われたDMLおよびDDLの変更は、アウトバウンド・サーバーに送信されます。

• PDB pdb1.example.comからhrスキーマに対して行われたDMLおよびDDLの変更は、アウトバウンド・サーバーに送信されます。

図4-9は、このXStream Out構成の概要を示したものです。

図4-9 複数のCDBおよびダウンストリーム取得を使用したXStream Out構成の例

「図4-9 複数のCDBおよびダウンストリーム取得を使用したXStream Out構成の例」の説明

CDB内でダウンストリーム取得を使用してXStream Outを構成するには、次の手順を実行します。

1. SQL*Plusで、ダウンストリーム取得CDBのルートにXStream管理者として接続します。

   この例では、ダウンストリーム取得CDBはcapture.example.comです。

2. 取得プロセスで使用されるキューを作成します。

   たとえば、次のプロシージャを実行します。

   BEGIN
     DBMS_XSTREAM_ADM.SET_UP_QUEUE(
       queue_table => 'c##xstrmadmin.xstream_queue_table',
       queue_name  => 'c##xstrmadmin.xstream_queue');
   END;
   /
   

3. 必要に応じて、ダウンストリーム取得CDB内のルートからソースCDBのルートにデータベース・リンクを作成します。

   この例では、capture.example.comのルートからdata.example.comのルートにデータベース・リンクを作成します。たとえば、ユーザーc##xstrmadminが両方のデータベースのXStream管理者の場合、次のようにデータベース・リンクを作成します。

   CREATE DATABASE LINK data.example.com CONNECT TO c##xstrmadmin 
      IDENTIFIED BY password USING 'data.example.com';
   

4. ソースCDB内のすべてのコンテナが、読取り/書込みモードでオープンしていることを確認します。

5. 手順3でデータベース・リンクを作成しなかった場合は、ソースCDBのルートで追加の手順を実行する必要があります。

   これらの手順は、手順3でデータベース・リンクを作成した場合は不要です。

   BUILDプロシージャを実行し、必要なサプリメンタル・ロギングがソースCDB内のデータベース・オブジェクトに対して指定されていることを確認します。

   1. ソースCDBのルートにXStream管理者として接続します。

   2. DBMS_CAPTURE_ADM.BUILDプロシージャを実行します。次に例を示します。

      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
      

      このプロシージャによって、capture.example.com CDBのルートで作成される取得プロセスの有効な先頭SCN値が表示されます。戻されたSCN値をメモし、手順6で取得プロセスを作成するときに使用できるようにしてください。

   3. 必要なサプリメンタル・ロギングが、ソースCDB内のデータベース・オブジェクトに対して指定されていることを確認してください。

      この例では、サプリメンタル・ロギングが、pdb1.example.com PDBのhrスキーマ、oe.orders表およびoe.order_items表に対して構成されていることを確認します。

6. ダウンストリーム取得CDBのルートに接続中に、取得プロセスを作成します。

   たとえば、capture.example.comにXStream管理者として接続中に、次のプロシージャを実行して取得プロセスを作成します。

   BEGIN
     DBMS_CAPTURE_ADM.CREATE_CAPTURE(
       queue_name         => 'c##xstrmadmin.xstream_queue',
       capture_name       => 'real_time_capture',
       rule_set_name      => NULL,
       start_scn          => NULL,
       source_database    => NULL,
       use_database_link  => TRUE,
       first_scn          => NULL,
       logfile_assignment => 'implicit',
       source_root_name   => 'data.example.com',
       capture_class      => 'xstream');
   END;
   /
   

   手順3でデータベース・リンクを作成しなかった場合、DBMS_CAPTURE_ADM.BUILDプロシージャによって戻されるSCN値をfirst_scnパラメータに指定します。

   取得プロセスは起動しないでください。

7. 取得プロセスの作成後、必要に応じて1つ以上のPDBのオープン・モードをオプションで変更します。

8. ADD_OUTBOUNDプロシージャを実行します。

   この項の前提で、次のADD_OUTBOUNDプロシージャを実行します。

   DECLARE
     tables  DBMS_UTILITY.UNCL_ARRAY;
     schemas DBMS_UTILITY.UNCL_ARRAY;
   BEGIN
       tables(1)  := 'oe.orders';
       tables(2)  := 'oe.order_items';
       schemas(1) := 'hr';
     DBMS_XSTREAM_ADM.ADD_OUTBOUND(
       server_name           =>  'xout',
       queue_name            =>  'c##xstrmadmin.xstream_queue',
       source_database       =>  'pdb1.example.com',
       table_names           =>  tables,
       schema_names          =>  schemas,
       source_root_name      => 'data.example.com',
       source_container_name => 'pdb1');
   END;
   /
   

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

   • xoutという名前のアウトバウンド・サーバーを作成します。アウトバウンド・サーバーには、oe.orders表、oe.order_items表およびhrスキーマに対するDMLおよびDDLの変更をクライアント・アプリケーションに送信するよう指示するルール・セットがあります。ルールでは、これらの変更はCDB data.example.comのPDB pdb1.example.comで発生したものである必要があることを指定します。アウトバウンド・サーバーは、キューc##xstrmadmin.xstream_queueからLCRをデキューします。

   • 現在のユーザーをアウトバウンド・サーバーのconnect_userとして設定します。この例では、current_userはXStream管理者です。クライアント・アプリケーションは、アウトバウンド・サーバーと対話するためにconnect_userとしてデータベースに接続する必要があります。

   注意:

   server_name値は30バイトを超えることはできません。

9. アウトバウンド・サーバーに接続してLCRを受信するクライアント・アプリケーションを作成して実行します。

クライアント・アプリケーションを実行すると、アウトバウンド・サーバーはダウンストリーム取得CDBで自動的に起動します。