4 XStream Outの構成

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

関連項目:

• XStream Outの概念

• XStreamの使用例

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

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

4.1 XStream Outの準備

XStream Outの構成に向けて準備するために、行う必要のある意思決定とタスクを示します。

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を構成するためのタスクの実行に関する具体的な情報を示します。

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です。マルチテナント・コンテナ・データベース(CDB)の場合、XStream管理者のユーザー名はc##xstrmadminです。

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

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

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

   CDBでXStream Out用にXStream管理者を構成する場合は、ルートに接続して、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内のすべてのコンテナ(CDBルート、すべてのプラガブル・データベース(PDB)、すべてのアプリケーション・ルートおよびすべてのアプリケーション・コンテナを含む)に表領域を作成する必要があります。表領域がすべてのコンテナで必要となるのは、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管理者を作成する場合は、CREATE SESSION権限とSET CONTAINER権限をXStream管理者に付与し、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管理者が取得プロセスの作成、アウトバウンド・サーバーの作成、取得プロセスの取得ユーザーの変更などのタスクを実行できるようにするには、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インバウンド・サーバーまたはクライアント・アプリケーションによって変更を適切に適用するために必要とされる場合があります。

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

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

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

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

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

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

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

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

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

• 変更を適用するインバウンド・サーバーの並列性が2以上の場合、ソース・データベースの複数の列に基づく宛先データベースのビットマップ索引列は、条件付きでログに記録する必要があります。ビットマップ索引列がソース・データベースの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;

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

たとえば、次の文では、無条件のログ・グループ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プロシージャを実行して、取得された同じ変更を受信する別のアウトバウンド・サーバーを追加できます。取得プロセスは、アウトバウンド・サーバーと同じデータベースに配置することも、別のデータベースに配置することもできます。

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

ヒント:

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

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の変更を取得するよう指示するルール・セットを使用して作成し、起動します。

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

   • 現在のユーザーをアウトバウンド・サーバーの接続ユーザーとして設定します。この例では、現在のユーザーは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つのアウトバウンド・サーバーが含まれているデータベースに追加のアウトバウンド・サーバーを追加できます。

追加のアウトバウンド・サーバーは、もう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を含む)のすべてのデータベース変更をストリームすることも、特定のコンテナからの変更をストリームすることもできます。

CDBでXStream Outを構成する前に、XStream Outとマルチテナント環境を確認してください。

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

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

• 取得プロセスとアウトバウンド・サーバーはCDBルート内に配置する必要があります。

• 取得プロセスとアウトバウンド・サーバーは同じCDB内に配置する必要があります。

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

• アプリケーション・ルートに対する変更を取得するときは、ALTER PLUGGABLE DATABASE APPLICATION文が他のアプリケーション・ルートにのみレプリケートされるようにする必要があります。

また、CDBに対してXStream管理者を正しく作成していることを確認します。

注意:

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

関連項目:

• XStream Outとマルチテナント環境

• CDBにおけるシステム生成ルールとXStream Out

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

• CDB以外を使用したPDBの作成方法は、Oracle Database管理者ガイド

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

CDBでローカル取得を使用してXStream Outを構成する方法の例を示します。

この例は、図4-5で説明しいる例と同じXStream Out構成を示しています。ただし、データベースがCDB内のPDBである点だけが異なります。

前提条件

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

• XStream Outの構成の前提条件に記載されたタスクを完了します。

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

前提条件

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

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

• アウトバウンド・サーバーの名前は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 CREATE_OUTBOUNDを使用してPDBに対して作成されたXStream Out構成の例

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

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

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

   SQL*PlusでCDB内のコンテナに接続する方法については、Oracle Database管理者ガイドを参照してください。

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を受信するクライアント・アプリケーションを作成および実行します。サンプル・アプリケーションについては、サンプルXStreamクライアント・アプリケーションを参照してください。

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

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

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

前提条件

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

• XStream Outの構成の前提条件に記載されたタスクを完了します。

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

• この例ではダウンストリーム・キャプチャを使用します。そのため、ソース・データベースからダウンストリーム・データベースへのログ・ファイル転送を構成する必要があります。ダウンストリーム・データベースへのログ・ファイル転送の構成(必要な場合)を参照してください。

リアルタイム・ダウンストリーム取得を使用する場合は、必要なスタンバイREDOログも追加する必要があります。リアルタイム・ダウンストリーム取得に対するスタンバイ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です。

   SQL*PlusでCDB内のコンテナに接続する方法については、Oracle Database管理者ガイドを参照してください。

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を受信するクライアント・アプリケーションを作成および実行します。サンプル・アプリケーションについては、サンプルXStreamクライアント・アプリケーションを参照してください。

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