1. Oracle DatabaseのためのOracle GoldenGateの使用
  2. DDLサポートの構成

12 DDLサポートの構成

この章では、Oracle GoldenGateにおけるDDLサポートの理解とその構成方法について説明します。

内容は次のとおりです。

  • DDL構成の前提条件
    Extractでは、ソースOracle Databaseから専用のDDLトリガーを使用するか、またはOracleログマイニング・サーバーを介してネイティブに、DDL操作をキャプチャできます。
  • DDL同期の概要
    Oracle GoldenGateでは、あるデータベースから別のデータベースへのDDL操作の同期がサポートされています。
  • Oracle GoldenGateにおけるDDLサポートの制限事項
    この項では、DDL機能の制限について説明します。
  • DDLサポートの構成ガイドライン
    次に、Oracle GoldenGateプロセスがDDLレプリケーションをサポートするよう構成する際に考慮するガイドラインを示します。
  • DDLスコープの理解
    データベース・オブジェクトはスコープに分類されます。スコープは、オブジェクトに対するDDL操作がOracle GoldenGateでどのように処理されるかを定義するカテゴリです。
  • DDL内の修飾されていないオブジェクト名の正しい識別
    Extractでは、DDL操作の実行時に有効な現在のスキーマ(セッション・スキーマとも呼ばれる)をキャプチャします。ソースがマルチテナント・コンテナ・データベースの場合、現在のコンテナもキャプチャされます。
  • DDLサポートの有効化
    データ定義言語(DDL)は、絶えず変化する動的環境で便利です。
  • DDLレプリケーションのフィルタリング
    デフォルトでは、すべてのDDLがExtractに渡されます。
  • 特別なフィルタのケース
    この項では、DDLフィルタを作成する前に考慮する必要がある特別なケースについて説明します。
  • Oracle GoldenGateにおける導出オブジェクト名の処理方法
    DDL操作には、ベース・オブジェクト名と導出オブジェクト名を含めることができます。
  • DDL文字列置換の使用
    Oracle GoldenGateによって処理される際、DDL操作内で文字列を置換できます。
  • 様々なトポロジをサポートするためのDDLの伝播の制御
    双方向およびカスケード・レプリケーション構成をサポートするには、Oracle GoldenGateによって、およびローカル・ビジネス・アプリケーションなどのその他のアプリケーションによって実行されたDDLを、Extractが識別できることが重要です。
  • サプリメンタル・ログ・グループの自動追加
    この項で説明されているタスクを実行するには、DDLOPTIONSパラメータをADDTRANDATAオプションとともに使用します。
  • レプリケートされたDDLからのコメントの削除
    DDLOPTIONSパラメータをREMOVECOMMENTS BEFOREおよびREMOVECOMMENTS AFTERオプションを指定して使用し、ソースDDLに使用されたコメントがターゲットDDLに含まれないようにします。
  • IDENTIFIED BYパスワードのレプリケート
    DEFAULTUSERPASSWORDALIASおよびREPLICATEPASSWORD | NOREPLICATEPASSWORDオプションを指定してDDLOPTIONSパラメータを使用し、レプリケートされた{CREATE | ALTER} USER name IDENTIFIED BY password文のパスワードの処理方法を制御します。これらのオプションは一緒に使用する必要があります。
  • 処理でDDLが評価される仕組み
    この項では、Oracle GoldenGateによるソースおよびターゲット・システムでのDDL文の処理方法について説明します。
  • DDLレポート情報の表示
    Oracle GoldenGateでは、ExtractおよびReplicatのレポートの最後に、DDLに関する基本的な統計がデフォルトで表示されます。
  • DDL処理のトレース
    Oracle GoldenGateテクニカル・サポートでサポート・ケースを開く場合、トレースを有効化するよう求められることがあります。TRACEおよびTRACE2は、DDLトレースを制御します。
  • トリガーベースのDDLキャプチャをサポートするツールの使用
    この項では、トリガーベースのキャプチャをサポートするために使用できる、その他のツールについて説明します。
  • エディションベース再定義の使用
    Oracle GoldenGateは、エディションベース再定義(EBR)の使用をサポートしており、アプリケーションのデータベース・コンポーネントの使用中でも、Oracle Databaseでそれらのコンポーネントをアップグレードできるため、ダウンタイムをゼロまたは最小限に抑えることができます。

DDL構成の前提条件

Extractでは、ソースOracle Databaseから専用のDDLトリガーを使用するか、またはOracleログマイニング・サーバーを介してネイティブに、DDL操作をキャプチャできます。

どちらの方法を使用できるかは、Extractのキャプチャ・モードおよびソースOracle Databaseのバージョンによって決まります。この項では、各キャプチャ・モードで使用可能なサポートについて説明します(「キャプチャおよび適用モードの選択」を参照)。

親トピック: DDLサポートの構成

統合キャプチャ・モードでのDDLキャプチャのサポート

Extractの統合キャプチャ・モードでは、DDLのキャプチャ方法が2つサポートされています。

  • Oracle 11.2.0.4以降: データベースのCOMPATIBLEパラメータが11.2.0.4以上に設定されているOracle Databaseは、データベース・ログマイニング・サーバーからのDDLキャプチャをサポートしています。この方法はネイティブDDLキャプチャと呼ばれます(トリガーレスDDLキャプチャとも呼ばれます)。トリガーやインストール済サポート対象オブジェクトは不要です。ネイティブDDLキャプチャは、マルチテナント・コンテナ・データベースからDDLをキャプチャする場合にサポートされている唯一の方法です。ダウンストリーム・マイニングの場合、データベース・ログマイニング・サーバーからのDDLキャプチャをサポートするには、ソース・データベースでデータベースのCOMPATIBLEが11.2.0.4以上に設定されていることも必要です。

  • 11.2.0.4より前のバージョン: COMPATIBLEパラメータが11.2.0.4より前に設定されているOracle Databaseには、Oracle GoldenGate DDLトリガーの使用が必要です。トリガーベースのDDLキャプチャを使用するには、DDLサポート用にExtractを構成する前に、DDLトリガーおよびサポートされているオブジェクトをインストールしておく必要があります。

親トピック: DDL構成の前提条件

クラシック・キャプチャ・モードでのDDLキャプチャのサポート

クラシック・キャプチャ・モードでは、Oracle DatabaseからのDDLのキャプチャにOracle GoldenGateのDDLトリガーを使用する必要があります。ネイティブのDDLキャプチャは、クラシック・キャプチャ・モードではサポートされません。

マルチテナント・コンテナ・データベースからのDDLキャプチャは、クラシック・キャプチャ・モードではサポートされません。

クラシック・キャプチャ・モードを使用し、DDLトリガーを使用してCREATE USERをレプリケートする場合、トリガーの所有者とExtractログイン・ユーザーが一致する必要があり、そうでない場合、CREATE USERコマンドをレプリケートする際に権限エラーが発生します。

トリガーベースのDDLキャプチャを使用するには、DDLサポート用にExtractを構成する前に、DDLトリガーおよびサポートされているオブジェクトをインストールしておく必要があります(「トリガーベースのDDLキャプチャのインストール」を参照)。

親トピック: DDL構成の前提条件

DDL同期の概要

Oracle GoldenGateでは、あるデータベースから別のデータベースへのDDL操作の同期がサポートされています。

DDL同期は、次のような場合にアクティブになります。

  • ビジネス・アプリケーションが、ソースとターゲットのオブジェクトにアクティブにアクセスし、更新している場合。

  • Oracle GoldenGateのトランザクション・データの同期がアクティブな場合。

DDLのレプリケーションおよびトランザクション・データ変更(DML)のレプリケーションをサポートするコンポーネント同士は、相互に独立しています。そのため、次のような同期が可能です。

  • DDL変更のみ

  • DML変更のみ

  • DDLとDMLの両方

Oracleに対するDDLサポートについて、サポートされているオブジェクトと操作のリストは、「Oracle DDLでサポートされているオブジェクトおよび操作」を参照してください。

親トピック: DDLサポートの構成

Oracle GoldenGate DDLサポートの制限

この項では、DDL機能の制限について説明します。

このドキュメントの発行後に明らかになったその他の制限事項については、『Oracle GoldenGateリリース・ノート』を参照してください。

親トピック: DDLサポートの構成

DDL文の長さ

Oracle GoldenGateでは、文字数ではなく、バイト数でDDL文の長さが計測されます。サポートされる長さは、約4MBです。これには、影響を受けるオブジェクトの名前とそのDDLタイプやその他の特性に応じてサイズが異なる内部的なオーバーヘッドが含まれます。DDLがサポートされているサイズより長い場合は、Extractにより警告が発行され、DDL操作が無視されます。

ExtractがDDLトリガーによってDDLをキャプチャしている場合、無視されたDDLはマーカー表に保存されます。無視されたOracle DDL文とその他のOracle DDL文は、DDL操作をOracleのUSER_DUMP_DESTディレクトリのテキスト・ファイルに保存するddl_ddl2file.sqlスクリプトを使用してキャプチャできます。スクリプトから、次の入力を求められます。

  • Oracle GoldenGate DDLオブジェクトを含むスキーマの名前。これは、GLOBALSファイルに指定されています。

  • Oracle GoldenGateマーカー順序番号。これは、Extractパラメータ・ファイルでDDLOPTIONSにREPORTオプションが使用されている場合にExtractレポート・ファイルに記録されます。

  • 出力ファイルの名前。

親トピック: Oracle GoldenGateにおけるDDLサポートの制限事項

サポートされているトポロジ

Oracle GoldenGateでは、同種構成でのみDDL同期がサポートされます。ソースとターゲットのオブジェクト定義は同一であることが必要です。

DDLレプリケーションは、OracleからOracleへのレプリケーションでのみサポートされています。OracleからTeradata、SQL ServerからOracleのように、異なるデータベース間ではサポートされていません。

Oracle GoldenGateでは、スタンバイ・データベースのDDLはサポートされません。

Oracle GoldenGateでは、2つ(のみ)のシステム間のすべてのサポートされている1方向構成および双方向構成でDDLレプリケーションがサポートされます。Oracleアクティブ/アクティブ構成で特に考慮する事項については、「アクティブ/アクティブ(双方向)構成でのDDLの伝播」を参照してください。

親トピック: Oracle GoldenGateにおけるDDLサポートの制限事項

フィルタリング、マッピングおよび変換

DDL操作は、Oracle GoldenGateプロセスでは変換されません。ただし、プライマリExtractまたはReplicatプロセスで、ソースDDLを別のターゲット・オブジェクトにマップおよびフィルタリングできます。データ・ポンプExtractによるDDLのマッピングやフィルタリングはできません。DDLは、プライマリExtractから受信したとおりに渡されます。

たとえば、ALTER TABLE TableAは、データ・ポンプによってALTER TABLE TableAとして処理されます。TABLE文の指定に関係なく、そのプロセスでALTER TABLE TableBとしてマップされません。

親トピック: Oracle GoldenGateにおけるDDLサポートの制限事項

名前変更

スキーマ名をターゲットのDDL文に含めることができるように、表でのRENAME操作は同等のALTER TABLE RENAMEに変換されます。たとえば、RENAME tab1 TO tab2は、ALTER TABLE schema.tab1 RENAME TO schema.tab2に変更されます。変換は、Replicatプロセスのレポート・ファイルにレポートされます。

親トピック: Oracle GoldenGateにおけるDDLサポートの制限事項

表からのフェッチとDDLとの相互作用

Oracle GoldenGateでは、一部のデータ型は、変更された行をREDOストリームから特定し、基になる表に問い合せて変更された列をフェッチすることでサポートされます。たとえば、クラシック・キャプチャで、LOBの部分的な更新(dbms_lobパッケージを介した変更)は、変更された行とLOB列をREDOログから特定し、ベース表に行のLOB列の値を問い合せることでサポートされます。同様の手法が、UDTのサポートに使用されます(クラシックと統合の両方のキャプチャ)。

注意:

統合キャプチャでは、ネイティブ・オブジェクト・サポートを使用していない場合のみ、UDTのためのフェッチが必要になります。

そのようなフェッチベースのサポートは、トランザクションがコミットされたSCN(システム変更番号)に基づいてデータベースにフラッシュバック問合せを発行することで実装されます。フラッシュバック問合せ機能にはいくつかの制限があります。一部のDDL操作が妨げとなり、そのDDLより前のデータを取得するためのフラッシュバック問合せが成功しません。そのようなDDLの例には、ALTER TABLE MODIFY COLUMNやALTER TABLE DROP COLUMNがあります。

したがって、Extractのキャプチャにラグがある場合、間にあるDDLによって、そのDDLより前のデータに対するフェッチ・リクエストが失敗することがあります。そのような場合、Extractは元に戻り、変更された列に対するデータの現在のスナップショットをフェッチします。この方法には、いくつかの制限があります。1つ目は、DDLによって、Extractがフェッチする必要のある列が変更されている可能性があるということです(たとえば、間にあるDDLによって、キャプチャ対象のUDTに新規属性が追加された場合など)。2つ目に、DDLによってExtractで論理行識別子として使用される列の1つが変更されている可能性があります。3つ目に、Extractがデータをフェッチする前に、表の名前が変更されている可能性があります。

このようなフェッチに関連する不整合を防ぐには、列の変更の際、次のような予防策を講じます。

  1. 表に対するすべてのDMLを一時停止します。

  2. Extractが残りのすべてのREDOのキャプチャを終了するのを待ち、Replicatがキャプチャされたデータの証跡からの処理を終了するのを待ちます。Replicatが終了したかどうかを判断するには、処理するデータがこれ以上存在しないことを示すメッセージが表示されるまでGGSCIで次のコマンドを発行します。

    INFO REPLICAT group

  3. DDLをソースで実行します。

  4. ソースのDML操作を再開します。

親トピック: Oracle GoldenGateにおけるDDLサポートの制限事項

SQL内のコメント

ソースDDL文でオブジェクト名の間にコメントが含まれている場合、そのコメントは、ターゲットDDL文ではオブジェクト名の最後に表示されますい。次に例を示します。

ソース:

CREATE TABLE hr./*comment*/emp ...

ターゲット:

CREATE TABLE hr.emp /*comment*/ ...

これは、DDL同期の整合性に影響しません。DDL文の他の箇所のコメントは、レプリケート時、元のままです。

親トピック: Oracle GoldenGateにおけるDDLサポートの制限事項

コンパイル・エラー

トリガー、プロシージャ、ファンクションまたはパッケージに対するCREATE操作がコンパイル・エラーになった場合でも、Oracle GoldenGateは、ターゲットに対してそのDDL操作を実行します。実際、DDL操作自体は正常に完了し、再帰プロシージャなどでターゲットに対する依存性の実行が可能になるようこれらの操作を伝播できます。

親トピック: Oracle GoldenGateにおけるDDLサポートの制限事項

時間隔パーティション化

DDLが暗黙的であるため、DDLレプリケーションは時間隔パーティション化の影響を受けません。ただし、これはシステム生成の名前であるため、Replicatではこれをターゲットに変換できません(これは予想される動作と思います)。ソース上でパーティションを削除する必要があります。次に例を示します。

alter table t2 drop partition for (20);

親トピック: Oracle GoldenGateにおけるDDLサポートの制限事項

DDLトリガー内で実行されたDMLまたはDDL

DDLトリガー内で実行されたDMLまたはDDL操作は、キャプチャされません。

親トピック: Oracle GoldenGateにおけるDDLサポートの制限事項

LogMinerデータ・ディクショナリのメンテナンス

Extractが登録され(LogMinerセッション)、LogMinerディクショナリがロードされるか、データベースの重要なDDLアクティビティの後に、ディクショナリ統計を収集することをお薦めします。

親トピック: Oracle GoldenGateにおけるDDLサポートの制限事項

DDLサポートに関する構成のガイドライン

次に、Oracle GoldenGateプロセスがDDLレプリケーションをサポートするよう構成する際に考慮するガイドラインを示します。

親トピック: DDLサポートの構成

データベース権限

Oracle GoldenGateでDDLのキャプチャとレプリケーションをサポートするために必要なデータベース権限については、「Oracle GoldenGate資格証明の確立」を参照してください。

親トピック: DDLサポートの構成ガイドライン

並列処理

Extract/Replicatの並列処理を使用している場合は、関連するDDLとDMLを同じプロセス・ストリームに保持し、データの整合性を確保します。プロセスを次のように構成します。

  • あるオブジェクトに対するすべてのDDLおよびDMLが、同じExtractグループおよび同じReplicatグループで処理されるようにします。

  • 相互に関連するすべてのオブジェクトが、同じプロセス・グループで処理されるようにします。

たとえば、ReplicatAでTable1に対するDMLを処理する場合、Table1に対するDDLも処理する必要があります。Table2に、Table1の外部キーがある場合、そのDML操作とDDL操作もReplicatAによって処理される必要があります。

Extractグループが、異なるReplicatグループによって読み取られる複数の証跡に書き込む場合、ExtractはすべてのDDLをすべての証跡に送信します。各Replicatグループを使用してDDLをフィルタするには、Replicatパラメータ・ファイルでDDLパラメータのフィルタ・オプションを使用します。

親トピック: DDLサポートの構成ガイドライン

オブジェクト名

Oracle GoldenGateでは、データベース定義のオブジェクト名、ケースおよびキャラクタ・セットが保持されます。このサポートにより、データベース階層のすべてのレベルにおいて、シングルバイト名とマルチバイト名、記号およびアクセント文字が保持されます。

DDL同期をサポートするパラメータの入力として指定する場合、オブジェクト名は2つの部分または3つの部分からなる名前として完全修飾されている必要があります。DDL同期をサポートする構成パラメータで、疑問符(?)およびアスタリスク(*)のワイルドカードを使用してオブジェクト名を指定できます。ただし、ワイルドカード指定も、2つの部分または3つの部分からなる名前として完全修飾されている必要があります。ワイルドカードのサポートの詳細は、『Oracle GoldenGateの管理』を参照してください。ワイルドカードを適切に処理するために、WILDCARDRESOLVEパラメータがデフォルトでDYNAMICに設定されています。WILDCARDRESOLVEがこれ以外に設定されている場合、DDL操作を処理するOracle GoldenGateプロセスが異常終了し、エラーがプロセス・レポートに書き込まれます。

親トピック: DDLサポートの構成ガイドライン

データ定義

DDLサポートには同種構成が必要なため、Replicatパラメータ・ファイルでASSUMETARGETDEFSパラメータが使用される必要があります。オブジェクトがDDLサポート用に構成され、SOURCEDEFSパラメータが使用されている場合、Replicatは異常終了します。ASSUMETARGETDEFSの詳細は、『Oracle GoldenGateリファレンス』を参照してください。

定義ファイルの使用の詳細は、『Oracle GoldenGateの管理』を参照してください。

親トピック: DDLサポートの構成ガイドライン

切捨て

TRUNCATE文は、次のようにサポートされます。

  • Oracle GoldenGateのフルDDLサポートの一環として、TRUNCATE TABLE、ALTER TABLE TRUNCATE PARTITIONおよび他のDDLがサポートされます。これは、DDLパラメータによって制御されます(「DDLサポートの有効化」を参照)。

  • スタンドアロンTRUNCATEサポートとして。このサポートによって、TRUNCATE TABLEはレプリケートできますが、他のDDLはできません。GETTRUNCATESパラメータによって、スタンドアロンのTRUNCATE機能が制御されます。詳細は、『Oracle GoldenGateリファレンス』を参照してください。

重複操作によるエラーを回避するために、同時にアクティブにできるのはこれらの機能の1つだけです。

親トピック: DDLサポートの構成ガイドライン

初期同期

DDLレプリケーションを構成するには、ソース・データベースと同期しているターゲット・データベースから開始します。DDLサポートはReplicatの初期ロード・メソッドと互換性があります。

初期ロードを実行する前に、DDLの抽出およびレプリケーションを無効化します。DDL処理は、ExtractおよびReplicatのパラメータ・ファイルのDDLパラメータによって制御されます。

ソース・データとターゲット・データの初期同期ができたら、ソース・アプリケーションを実行する前に、NEXTVALですべてのソース順序値を少なくとも1回使用します。システム内の各順序からNEXTVALを選択するスクリプトを使用できます。これは、Extractの実行中に行われる必要があります。

親トピック: DDLサポートの構成ガイドライン

CREATEまたはRENAMEの後のデータ継続性

CREATE操作またはRENAME操作の結果生じた新規のOracle表に対するDML操作をレプリケートするには、新規表の名前がパラメータ・ファイルのTABLE文およびMAP文に指定される必要があります。ワイルドカードを使用して、それらが必ず含まれるようにできます。

CREATE USERを使用して新規ユーザーを作成し、新規または名前が変更された表をそのスキーマに移動するには、新規ユーザー名がTABLE文およびMAP文に指定される必要があります。新規ユーザーfin2を作成し、新規または名前が変更された表をそのスキーマに移動する場合、fin2オブジェクトをターゲットの同じスキーマにマップするか、異なるスキーマにマップするかに応じて、パラメータ文は次のようになります。

Extract: 

TABLE fin2.*;

Replicat: 

MAP fin2.*, TARGET different_schema.*;

親トピック: DDLサポートの構成ガイドライン

DDLスコープの理解

データベース・オブジェクトは、スコープで分類されます。スコープは、オブジェクトに対するDDL操作がOracle GoldenGateでどのように処理されるかを定義するカテゴリです。

次のスコープがあります。

  • MAPPED

  • UNMAPPED

  • OTHER

スコープを使用すると、DDL操作、文字列の置換およびエラー処理のフィルタリングをより詳細に制御できます。

親トピック: DDLサポートの構成

マップされるスコープ

TABLE文およびMAP文で指定されるオブジェクトは、MAPPEDスコープのオブジェクトです。それらの文での抽出とレプリケーションの指示は、オーバーライド・ルールが適用されていないかぎり、指定されたオブジェクトに対するデータ(DML)とDDLの両方に適用されます。

TABLE文とMAP文内のオブジェクトでは、次の表にリストされたDDL操作がサポートされます。

表12-1 MAP文およびTABLE文にマップ可能なオブジェクト

操作 対象のオブジェクト(1)

CREATE

ALTER

DROP

RENAME

COMMENT ON脚注 2

TABLE脚注 3

INDEX

TRIGGER

SEQUENCE

MATERIALIZED VIEW

VIEW

FUNCTION

PACKAGE

PROCEDURE

SYNONYM

PUBLIC SYNONYM脚注 4

GRANT

REVOKE

TABLE

SEQUENCE

MATERIALIZED VIEW

ANALYZE

TABLE

INDEX

CLUSTER

脚注 1 TABLEおよびMAPでは、これらの操作の対象のオブジェクト名に使用される可能性のある一部の特殊文字がサポートされません。サポートされていない特殊文字が使用されたオブジェクトは、UNMAPPEDおよびOTHERのスコープでサポートされます。

脚注2

COMMENT ON TABLE、COMMENT ON COLUMNに適用されます。

脚注3

AS SELECTが含まれます

脚注4

表名は、スキーマ名で修飾する必要があります。

Extractの場合、MAPPEDスコープでTABLE文の指示に従ってDDLキャプチャ用にオブジェクトがマークされます。Replicatの場合、MAPPEDスコープでレプリケーション用にDDLがマークされ、MAP文のTARGET句のスキーマと名前によって指定されたオブジェクトにマップされます。このマッピングを実行するために、ReplicatによってALTER SESSIONが発行され、ReplicatセッションのスキーマがTARGET句で指定されたスキーマに設定されます。修飾されていないオブジェクトがDDLに含まれている場合、ターゲットで割り当てられるスキーマは、「DDLスコープの理解」に説明されている状況に応じて異なります。

TABLE文とMAP文が次のとおりであるとします。

Extract (ソース)

TABLE fin.expen;
TABLE hr.tab*;

Replicat (ターゲット)

MAP fin.expen, TARGET fin2.expen2;
MAP hr.tab*, TARGET hrBackup.bak_*;

次のソースDDL文もあるとします。

ALTER TABLE fin.expen ADD notes varchar2(100);

この例では、ソース表fin.expenが、別のスキーマと表名にマップするTARGET句が指定されたMAP文にあるため、ターゲットのDDL文は次のようになります。 

ALTER TABLE fin2.expen2 ADD notes varchar2(100);

同様に、例のTABLE文とMAP文の2つ目のセットには、次のソースとターゲットのDDL文が考えられます。

Source: 

CREATE TABLE hr.tabPayables ... ;

ターゲット: 

CREATE TABLE hrBackup.bak_tabPayables ...;

MAPPEDスコープのオブジェクトでは、DDLサポートを詳細に調整しない場合、DDL構成パラメータからオブジェクト名を省略できます。TABLE文とMAP文でオブジェクト名を変更する必要がある場合、それらのオブジェクトに対するDDLに変更が自動的に適用されます。

オブジェクトがTABLE文に含まれ、MAP文に含まれない場合、そのオブジェクトに対するDDLのスコープは、ソースではMAPPEDですが、ターゲットではUNMAPPEDです。

親トピック: DDLスコープの理解

マップされないスコープ

DDL操作が、TABLE文またはMAP文での使用についてサポートされていて、そのベース・オブジェクト名がそれらのパラメータの1つに含まれない場合、UNMAPPEDスコープです。

オブジェクト名のスコープが、ソースではUNMAPPED (ExtractのTABLE文にない)で、ターゲットではMAPPED (ReplicatのMAP文にある)であることも、その逆もあります。Oracle DDLのスコープがReplicat構成でUNMAPPEDの場合、Replicatはデフォルトでは次のようにします。

  1. Replicatセッションの現在のスキーマをソースDDLオブジェクトのスキーマに設定します。
  2. DDLをそのスキーマとして実行します。
  3. ReplicatをReplicatセッションの現在のスキーマとしてリストアします。

「DDLスコープの理解」を参照してください。

親トピック: DDLスコープの理解

他のスコープ

マップできないDDL操作は、OTHERスコープです。DDLがReplicat構成でOTHERスコープの場合、ソースDDLと同じスキーマ名とオブジェクト名でターゲットに適用されます。

OTHERスコープの例は、データ・ファイル名を操作するDDLなどのシステムに固有の参照を行うDDL操作です。

OTHERスコープのその他の例は、次のとおりです。 

CREATE USER joe IDENTIFIED by joe;
CREATE ROLE ggs_gguser_role IDENTIFIED GLOBALLY;
ALTER TABLESPACE gg_user TABLESPACE GROUP gg_grp_user;

「DDLスコープの理解」を参照してください。

親トピック: DDLスコープの理解

DDL内の修飾されていないオブジェクト名の正しい識別

Extractでは、DDL操作の実行時に有効な現在のスキーマ(セッション・スキーマとも呼ばれる)をキャプチャします。ソースがマルチテナント・コンテナ・データベースの場合、現在のコンテナもキャプチャされます。

コンテナとスキーマは、DDL内の修飾されていないオブジェクト名の解決に使用されます。

次の例で考えてみます。

CONNECT SCOTT/TIGER
CREATE TABLE TAB1 (X NUMBER);
CREATE TABLE SRC1.TAB2(X NUMBER) AS SELECT * FROM TAB1;

両方のDDL文の修飾されていない表TAB1は、DDLの実行時に有効な現在のスキーマSCOTTに基づいてSCOTT.TAB1と解決されます。

現在のスキーマを設定する方法には、次の例に示すようにセッションのcurrent_schemaを設定するという別の方法もあります。 

CONNECT SCOTT/TIGER
ALTER SESSION SET CURRENT_SCHEMA=SRC;
CREATE TABLE TAB1 (X NUMBER);
CREATE TABLE SRC1.TAB2(X NUMBER) AS SELECT * FROM TAB1;

両方のDDL文の修飾されていない表TAB1は、DDLの実行時に有効な現在のスキーマSRCに基づいてSRC.TAB1と解決されます。

クラシックと統合の両方のキャプチャ・モードで、ExtractはDDLの実行時に有効な現在のスキーマをキャプチャし、現在のスキーマを使用して、修飾されていないオブジェクト名(ある場合)を解決します。その結果、Replicatに対して指定されるMAP文は、修飾されていないオブジェクト名を使用するDDLについて正しく機能します。

ターゲットでDDLが成功するために必要な場合、ソース・セッション・スキーマを別のターゲット・セッション・スキーマにマップすることもできます。このマッピングはグローバルで、同じスキーマ名を含む他のマッピングをオーバーライドします。セッション・スキーマをマップするには、MAPSESSIONSCHEMAオプションを指定してDDLOPTIONSパラメータを使用します。詳細は、『Oracle GoldenGateリファレンス』を参照してください。

デフォルトまたはマップされたセッション・スキーマのマッピングが失敗した場合、次のDDLERRORパラメータ文を使用してエラーを処理することができます。エラー1435は、スキーマが存在しないことを示します。 

DDLERROR 1435 IGNORE INCLUDE OPTYPE ALTER OBJTYPE SESSION

親トピック: DDLサポートの構成

DDLサポートの有効化

データ定義言語(DDL)は、絶えず変化する動的環境で便利です。

デフォルトでは、DDLレプリケーション・サポートのステータスは次のようになります。

  • ソースでは、Oracle GoldenGate DDLサポートはデフォルトで無効です。DDLパラメータを使用して、DDLをキャプチャするようExtractを構成する必要があります。

  • ターゲットでは、DDLサポートはデフォルトで有効で、レプリケートされるトランザクション・データの整合性が保たれます。デフォルトでは、Replicatによって証跡に含まれるすべてのDDL操作を処理します。必要に応じてDDLパラメータを使用し、DDL操作を無視またはフィルタするようReplicatを構成します。

親トピック: DDLサポートの構成

DDLレプリケーションのフィルタリング

デフォルトでは、すべてのDDLがExtractに渡されます。

次の方法を使用して、要件に応じて特定(またはすべて)のDDLがターゲット・データベースに適用されるよう、DDL操作をフィルタできます。

  • PL/SQLコードによるフィルタ: トリガーベースのDDLキャプチャでのみ有効です。この方法では、DDL操作が発生するとDDLトリガーによってコールされるOracle関数を使用してDDLをExtractに送信するかどうかを判断します。PL/SQLコードによるフィルタは、DDLトリガーが使用されている場合に、ソース・データベースのパフォーマンスを改善するためにのみ使用する必要があります。組込みルールおよびDDLパラメータによるフィルタと組み合せることができます(次を参照)。DDLトリガーまたはフィルタ・ルールによってフィルタされた後でExtractに渡されるDDLを、DDLパラメータを使用して特定のニーズにあわせてさらにフィルタできます。

  • 組込みフィルタ・ルールによるフィルタ: トリガーベースのDDLキャプチャでのみ有効です。この方法では、フィルタ・ルールをOracle GoldenGateトリガー・ロジックに組み込むために実行するプロシージャを使用します。この方法では、Extractに送信するオブジェクトのタイプを注意深く制御でき、ルールの評価の順序付けが可能です。この方法は、DDLトリガーが使用されている場合に、ソース・データベースのパフォーマンスを改善するためにのみ使用する必要があります。組込みルールをPL/SQLおよびDDLパラメータによるフィルタと組み合せることができます。DDLトリガーまたはフィルタ・ルールによってフィルタされた後でExtractに渡されるDDLを、DDLパラメータを使用して特定のニーズにあわせてさらにフィルタできます。

    注意:

    統合キャプチャ・モードで動作するExtractの場合、PL/SQLまたは組込みフィルタ・ルールによるフィルタは不要です。Extractがクラシック・モードで動作する必要がある場合に、これらのフィルタリング方法を使用する際は、フィルタ処理済オブジェクトに関連付けられている任意のトランザクション・データ(DML)に対して同じフィルタ処理を行う必要があります。たとえば、ACCOUNTSという名前の表を作成するDDLをフィルタ処理で除外する場合は、ACCOUNTS表がTABLE文またはMAP文で指定されないようにするか、適切な除外パラメータを使用してワイルドカードの解決から除外する必要があります。ワイルドカード除外パラメータのリストについては、『Oracle GoldenGateリファレンス』を参照してください。

  • DDLパラメータによるフィルタ: トリガーベースとネイティブDDLの両方で有効です。これは推奨されるフィルタリング方法で、Oracle GoldenGate内で実行され、ExtractとReplicatの両方でフィルタ基準を実行できます。Extractでフィルタリングを行うか、すべてのDDLを証跡に送り、Replicatでフィルタリングを行います。あるいは、異なる場所の組合せでフィルタすることもできます。DDLパラメータでは、フィルタリングを行う場所を制御でき、DDLスコープに基づいてまとめてフィルタする(すべてのMAPPEDスコープを含めるなど)機能など、トリガーの方法よりも多くのフィルタリング・オプションがあります。

    注意:

    TRANSACTIONの実行中にDDL操作が失敗すると、コミットが強制されます(DDLにまたがるトランザクションが2つに分割されます)。前半はコミットされ、後半を再起動できます。リカバリが実行されると、トランザクションのヘッダーに含まれる情報がなくなるため、トランザクションの後半をフィルタすることはできません。

親トピック: DDLサポートの構成

PL/SQLコードによるフィルタ

この方法は、トリガーベースのキャプチャでのみ有効です。

PL/SQLコードを記述して、DDLをExtractに渡すかどうかを判断する関数にDDLに関する情報を渡します。Extractに送信するDDL操作を少なくすることでキャプチャのパフォーマンスを向上させることができます。

  1. Oracle GoldenGateのインストール・ディレクトリにあるddl_filter.sqlファイルを、これから記述するコードをテストできるテスト・マシンにコピーします。
  2. ファイルを編集用に開きます。filterDDLという名前のPL/SQL関数が含まれており、これを変更してif/thenフィルタ基準を指定できます。この関数に渡される情報は、次のとおりです。

    • ora_owner: DDLオブジェクトのスキーマ

    • ora_name: オブジェクトの定義されている名前

    • ora_objtype: オブジェクトのタイプ(TABLE、INDEXなど)

    • ora_optype: 操作のタイプ(CREATE、ALTERなど)

    • ora_login_user: DDLを実行したユーザー

    • retVal: Extractの処理にDDLを含める場合はINCLUDE。DDLを除外する場合はEXCLUDE。

    'compute retVal here'コメントの後ろに、フィルタするDDLのタイプごとにフィルタ・コードを記述します。次に例を示します。 

    if ora_owner='SYS' then
retVal:='EXCLUDE';
end if;
if ora_objtype='USER' and ora_optype ='DROP' then
retVal:='EXCLUDE';
end if;
if ora_owner='JOE' and ora_name like 'TEMP%' then
retVal:='EXCLUDE';
end if;

    この例では、次のDDLが、DDLトリガーによる処理から除外されます。

    • SYSによって所有されているオブジェクトに対するDDL

    • 任意のDROP USER

    • JOE.TEMP%に対する任意のDDL

  3. (オプション)フィルタリングをトレースするには、PL/SQLの各if/then文に次の構文を追加します。
    if ora_owner='JOE' and ora_name like 'TEMP%' then
retVal:='EXCLUDE';
if "&gg_user" .DDLReplication.trace_level >= 1 then
"&gg_user" .trace_put_line ('DDLFILTER', 'excluded JOE.TEMP%');
end if;

    説明:

    • &gg_userは、Oracle GoldenGate DDLサポート・オブジェクトのスキーマです。

    • .DDLReplication.trace_levelは、DDLトレースのレベルです。トリガー・トレースを使用するには、Extractパラメータ・ファイルでDDLまたはDDLONLYオプションを指定してTRACEまたはTRACE2パラメータを使用する必要があります。.DDLReplication.trace_levelパラメータを>=1に設定する必要があります。

    • trace_put_lineは、Extractがトレース・ファイルに書き込む、フィルタされたDDLのタイプを表すユーザー定義テキスト文字列です。

  4. コードを保存します。
  5. テスト・システムでDDLアクティビティを停止します。
  6. SQL*Plusで次のようにddl_filter.sqlファイルをコンパイルします。ここで、schema_nameは、Oracle GoldenGate DDLオブジェクトがインストールされているスキーマです。
    @ddl_filter schema_name
  7. テスト環境でテストし、フィルタリングが機能することを確認します。コード内のエラーによってソースとターゲットのDDLが同期しなくなることがあるため、このテストを実行することは重要です。
  8. テストが成功したら、ファイルをソース本番システムのOracle GoldenGateのインストール・ディレクトリにコピーします。
  9. ソース・システムでDDLアクティビティを停止します。
  10. 前に行ったようにddl_filter.sqlファイルをコンパイルします。
    @ddl_filter schema_name
  11. ソース・システムでDDLアクティビティを停止します。

親トピック: DDLレプリケーションのフィルタリング

組込みフィルタ・ルールによるフィルタ

この方法は、トリガーベースのキャプチャでのみ有効です。

選択ルールまたは除外ルールを追加して、DDLトリガーによってExtractに送信されるDDL操作を制御できます。ルールを格納し、Extractに送信するDDL操作を少なくすることでキャプチャのパフォーマンスを向上させることができます。

  1. DDLAUX.addRule()関数を使用して、次のガイドに則したルールを定義します。この関数は、ddl_setup.sqlスクリプトを使用してDDLオブジェクトがインストールされた後にOracle GoldenGate DDLスキーマにインストールされます。
  2. ルールをアクティブにするには、SQL*Plusで関数を実行するか、SQLファイルに一連のルールを入力してそのファイルをSQL*Plusで実行します。

親トピック: DDLレプリケーションのフィルタリング

DDLAUX.addRule()関数の定義 
FUNCTION addRule( obj_name IN VARCHAR2 DEFAULT NULL,
base_obj_name IN VARCHAR2 DEFAULT NULL,
owner_name IN VARCHAR2 DEFAULT NULL,
base_owner_name IN VARCHAR2 DEFAULT NULL,
base_obj_property IN NUMBER DEFAULT NULL,
obj_type IN NUMBER DEFAULT NULL,
command IN VARCHAR2 DEFAULT NULL,
inclusion IN boolean DEFAULT NULL ,
sno IN NUMBER DEFAULT NULL)
RETURN NUMBER;
DDLAUX.addRule()のパラメータ

この関数に渡される情報は次のパラメータで、オブジェクトの属性と関連しています。すべてのパラメータがオプションで、複数のパラメータを指定できます。

  • sno: ルールを識別するシリアル番号を指定します。ルールの評価は、シリアル番号の小さいものから大きいものの順に、一致が見つかるまで行われます。snoを使用して除外ルールの前に選択ルールを置き、除外ルールの例外を作成できます。これはファンクションでプロシージャではないため、ルールのシリアル番号を返します。これを使用して削除するルールをDDLAUX.dropRule()に指定します。コードの冒頭でDECLARE sno NUMBER; BEGIN sno :=を使用して指定しないかぎり、シリアル番号は自動的に生成されます。

    次に例を示します。

    DECLARE 
  sno NUMBER; 
BEGIN 
  sno := tkggadmin..DDLAUX.ADDRULE(obj_name => 'GGS%' , 
                                   obj_type => TYPE_TABLE); 
END;
/

  • obj_name: オブジェクト名を指定します。名前に大文字と小文字の区別がある場合は、二重引用符で囲みます。

  • owner_name: オブジェクトのスキーマの名前を指定します。

  • base_obj_name: DDLオブジェクトのベース・オブジェクト名を指定します(オブジェクトが索引の場合のベース表など)。名前に大文字と小文字の区別がある場合は、二重引用符で囲みます。

  • base_owner_name: ベース・オブジェクトのスキーマ名を指定します。

  • base_obj_property: ベース・オブジェクトのプロパティを指定します。

  • obj_type: オブジェクト・タイプを指定します。

  • command: コマンドを指定します。

  • inclusion = TRUE: 指定されたオブジェクトがDDLトリガーによってキャプチャされることを示します。このパラメータが指定されない場合、ルールは除外ルールとなり、指定されたオブジェクトはキャプチャされません。除外ルールと選択ルールの両方を指定できます。DDLがルールのいずれにも一致しない場合、デフォルトで選択されます(Extractに渡されます)。パラメータなしでDDLAUX.addRule()をコールすると、すべてのオブジェクトに対するすべてのDDLを除外する空のルールが生成されます。

DDLAUX.addRule()に対して有効なDDLコンポーネント

関数コードで指定できる定義済DDLオブジェクト・タイプ、ベース・オブジェクト・プロパティおよびDDLコマンドは次のとおりです。

有効なオブジェクトは次のとおりです。

  • TYPE_INDEX
  • TYPE_TABLE
  • TYPE_VIEW
  • TYPE_SYNONYM
  • TYPE_SEQUENCE
  • TYPE_PROCEDURE
  • TYPE_FUNCTION
  • TYPE_PACKAGE
  • TYPE_TRIGGER

有効なベース・オブジェクト・プロパティは次のとおりです。

  • TB_IOT
  • TB_CLUSTER
  • TB_NESTED
  • TB_TEMP
  • TB_EXTERNAL

有効なコマンドは次のとおりです。

  • CMD_CREATE
  • CMD_DROP
  • CMD_TRUNCATE
  • CMD_ALTER
ルールベースのトリガーのフィルタの例

次の例では、名前がIMPTEMPで始まる表以外のすべての一時表を除外します。 

1. DDLAUX.ADDRULE(obj_name => 'IMPTEMP%', base_obj_property => TB_TEMP, obj_type => TYPE_TABLE, INCLUSION => TRUE);
2. DDLAUX.ADDRULE(base_obj_property => TB_TEMP, obj_type => TYPE_TABLE);

注意:

IMPTEMP%表を含めるため、そのルールを先にします。

次の例では、名前が'GGS%'のすべての表を除外します。 

DECLARE sno NUMBER; BEGIN sno := DDLAUX.ADDRULE(obj_name => 'GGS%' , obj_type => TYPE_TABLE); END

次の例では、すべての一時表を除外します。

DDLAUX.ADDRULE(base_obj_property => TB_TEMP, obj_type => TYPE_TABLE);

次の例では、TEMP表のすべての索引を除外します。 

DDLAUX.ADDRULE(base_obj_property => TB_TEMP, obj_type => TYPE_INDEX);

次の例では、スキーマTKGGADMINのすべてのオブジェクトを除外します。 

DDLAUX.ADDRULE(owner_name => 'TKGGADMIN');

次の例では、TEMP表に対するTRUNCATE操作のすべてのオブジェクトを除外します。 

DDLAUX.ADDRULE(base_obj_property => TB_TEMP, obj_type => TYPE_TABLE, command => CMD_TRUNCATE)
フィルタ・ルールの削除

削除するルールを指定してDDLAUX.dropRule()関数を使用します。この関数は、ddl_setup.sqlスクリプトを使用してDDLオブジェクトがインストールされた後にOracle GoldenGate DDLスキーマにインストールされます。入力として、削除するルールのシリアル番号を指定します。 

FUNCTION dropRule(sno IN NUMBER) RETURN BOOLEAN;

DDLパラメータを使用したフィルタリング

この方法は、トリガーベースのキャプチャ・モードおよび統合キャプチャ・モードでのみ有効です。

DDLパラメータは、ExtractおよびReplicatプロセス内でDDLをフィルタリングするための主要なOracle GoldenGateパラメータです。

オプションを指定せずに使用すると、DDLパラメータによるフィルタリングが実行されず、すべてのDDL操作が次のように伝播されます。

  • Extractパラメータとして、サポートされているすべてのデータベース・オブジェクトで生成された、サポートされている全DDL操作が取得されて証跡に送信されます。

  • Replicatパラメータとして、Oracle GoldenGateの証跡からすべてのDDL操作がレプリケートされ、ターゲットに適用されます。これは、このパラメータを使用しない場合のデフォルトの動作と同じです。

オプションを指定して使用すると、DDLパラメータがフィルタリング・エージェントとして機能し、次に基づいてDDL操作が含まれるか除外されます。

  • スコープ

  • オブジェクト・タイプ

  • 操作タイプ

  • オブジェクト名

  • DDLコマンド構文またはコメント、あるいはその両方の文字列

パラメータ・ファイルで使用できるDDLパラメータは1つのみですが、他のオプションとともに複数の選択オプションと除外オプションを組み合せて、必要なレベルまでDDLをフィルタできます。

  • DDLフィルタリング・オプションは、トランザクション・ソースからのキャプチャを行うプライマリExtractに対しては有効ですが、データ・ポンプExtractに対しては無効です。

  • 複数のフィルタ・オプションの指定を組み合せた場合、AND文として論理的にリンクされます。

  • レプリケートされるDDL文では、複数のオプションが指定されたすべてのフィルタ基準を満たしている必要があります。

  • 複雑なDDLフィルタリング基準を使用する場合、本番環境で使用する前にテスト環境で構成をテストすることをお薦めします。

DDLパラメータ構文およびその他の使用方法のガイドラインについては、『Oracle GoldenGateリファレンス』を参照してください。

注意:

DDLサポートを構成する前に、「処理でDDLが評価される仕組み」を参照することをお薦めします。

親トピック: DDLレプリケーションのフィルタリング

特別なフィルタのケース

この項では、DDLフィルタを作成する前に考慮する必要がある特別なケースについて説明します。

次に、フィルタ条件を作成するための特別なケースを示します。

親トピック: DDLサポートの構成

DDL EXCLUDE ALL

DDL EXCLUDE ALLは、トリガーベースのDDLキャプチャを使用している場合に、主としてExtractのために用意されている特別な処理オプションです。DDL EXCLUDE ALLはDDL操作のレプリケーションをブロックしますが、Oracle GoldenGateが現在のオブジェクト・メタデータを保持できるようにします。Extractがログマイニング・サーバーから直接DDLを受信する場合(トリガーレスDDLキャプチャ・モード)、現在のメタデータは常に保持されます。

Oracle GoldenGate以外の方法を使用してDDLをターゲットに適用し、Oracle GoldenGateによってデータの変更をターゲット・オブジェクトにレプリケートする場合、DDL EXCLUDE ALLを使用できます。現在のメタデータをオブジェクトの変更としてOracle GoldenGateに提供するため、Oracle GoldenGateプロセスの停止と起動の必要がなくなります。次の特別な条件がDDL EXCLUDE ALLに適用されます。

  • DDL EXCLUDE ALLでは、INCLUDE句を使用する必要がありません。

  • DDL EXCLUDE ALLを使用する場合、WILDCARDRESOLVEパラメータをIMMEDIATEに設定し、必要に応じてただちにDMLを解決できるようにします。詳細は、『Oracle GoldenGateリファレンス』を参照してください。

すべてのDDLメタデータと操作がレプリケートされないようにするには、DDLパラメータ全体を省略します。

親トピック: 特別なフィルタのケース

暗黙的DDL

ユーザーによって生成されたDDL操作によって、暗黙的DDL操作が生成される場合があります。たとえば、次の文では、2つの異なるDDL操作が生成されます。

CREATE TABLE customers (custID number, name varchar2(50), address varchar2(75), address2 varchar2(75), city varchar2(50), state (varchar2(2), zip number, contact varchar2(50), areacode number(3), phone number(7), primary key (custID));

最初の(明示的)DDL操作は、CREATE TABLE文自体です。

2つ目のDDL操作は、暗黙的なCREATE UNIQUE INDEX文で、主キーの索引を作成します。この操作は、ユーザー・アプリケーションではなく、データベース・エンジンによって生成されます。

暗黙的DDLのフィルタリングのガイドライン

暗黙的DDLのフィルタ方法は、DDLのフィルタに使用するメカニズムによって異なります。詳細は、「DDLレプリケーションのフィルタリング」を参照してください。

  • DDLパラメータを使用してDDL操作をフィルタする場合、ターゲットで明示的DDLによって暗黙的DDLが生成されるため、デフォルトではOracle GoldenGateで暗黙的DDLは除外されます。たとえば、前述の例のCREATE TABLE文がReplicatによって適用されると、ターゲット・データベースで適切な索引が作成されます。

  • DDLトリガーを使用してDDL操作をフィルタする場合、次の事項に基づいて、フィルタ・ルールで暗黙的DDLを処理する必要があります。

    • フィルタ・ルールで明示的DDLを伝播から除外する場合、暗黙的DDLを除外するルールも作成する必要があります。たとえば、次の例のCREATE TABLE文は除外するが、暗黙的CREATE UNIQUE INDEX文は除外しない場合、ターゲット・データベースは、存在しない表に索引を作成しようとします。 

      CREATE TABLE customers (custID number, name varchar2(50), address varchar2(75), address2 varchar2(75), city varchar2(50), state (varchar2(2), zip number, contact varchar2(50), areacode number(3), phone number(7), primary key (custID));

    • フィルタリング・ルールで明示的DDLの伝播が許可されている場合、暗黙的DDLを除外する必要はありません。Oracle GoldenGateおよびターゲット・データベースによって適切に処理されます。

親トピック: 特別なフィルタのケース

Oracle GoldenGateによる導出オブジェクト名の処理方法

DDL操作には、ベース・オブジェクト名と導出オブジェクト名を含めることができます。

ベース・オブジェクトは、データを含むオブジェクトです。導出オブジェクトは、ベース・オブジェクトの一部の属性を継承し、そのオブジェクトに関連する関数を実行するオブジェクトです。ベース・オブジェクトと導出オブジェクトの両方を含むDDL文は、次のとおりです。

  • RENAMEおよびALTER RENAME

  • 索引、シノニムまたはトリガーに対するCREATEおよびDROP

次のDDL文があるとします。

CREATE INDEX hr.indexPayrollDate ON TABLE hr.tabPayroll (payDate);

この場合、表がベース・オブジェクトです。その名前(hr.tabPayroll)がベース名で、MAPPEDスコープでのTABLEまたはMAPによるマッピングの対象です。導出オブジェクトは索引で、その名前(hr.indexPayrollDate)が導出名です。

導出名は、ベース・オブジェクトとは別の独自のTABLEまたはMAP文でマップできます。また、MAP文を使用して両方を処理できます。MAPの場合、ターゲットでの導出オブジェクト名の変換は次のように処理されます。

親トピック: DDLサポートの構成

ベース・オブジェクトに対するMAPはあるが、導出オブジェクトに対するMAPはない場合

ベース・オブジェクトに対するMAP文はあるが、導出オブジェクトに対するものはない場合、結果は導出オブジェクト名と一致するマッピングに基づいたスキーマです。導出オブジェクトはMAPDERIVEDオプションが有効な場合のみマッピングされます。また、これはデフォルト・オプションです。

たとえば、次を考えてみます。

Extract (ソース)

Table hr.*;

Replicat (ターゲット)

MAP hr.*, TARGET hrBackup.*;

次のソースDDL文があるとします。

CREATE INDEX hr.indexPayrollDate ON TABLE hr.Payroll (payDate);

ターゲットでReplicatによって実行されるCREATE INDEX文は次のとおりです。 

CREATE INDEX hrBackup.indexPayrollDate ON TABLE hrBackup.Payroll (payDate);

この例では、マッピングは導出オブジェクトのスキーマがhrからhrBackupに変更されるために導出オブジェクト名と一致するようなマッピングです。

次に別の例を示します。この例では、導出オブジェクト名と一致するマッピングはなく、導出オブジェクト名はそのままとなります。

Extract (ソース)

Table hr.tab*;

Replicat (ターゲット)

MAP hr.tab*, TARGET hrBackup.*;

次のソースDDL文があるとします。

CREATE INDEX hr.indexPayrollDate ON TABLE hr.tabPayroll (payDate);

ターゲットでReplicatによって実行されるCREATE INDEX文は次のとおりです。

CREATE INDEX hr.indexPayrollDate ON TABLE hrBackup.tabPayroll (payDate);

親トピック: Oracle GoldenGateにおける導出オブジェクト名の処理方法

ベース・オブジェクトと導出オブジェクトに対するMAPがある場合

ベース・オブジェクトに対するMAP文があり、導出オブジェクトに対するものもある場合、結果は明示的マッピングです。DDL文にMAPPEDが含まれる場合、Replicatで独自のTARGET句に従って各オブジェクトのスキーマと名前が変換されます。たとえば、次のようだとします。

Extract (ソース)

TABLE hr.tab*;  TABLE hr.index*;

Replicat (ターゲット)

MAP hr.tab*, TARGET hrBackup.*;MAP hr.index*, TARGET hrIndex.*;

次のソースDDL文があるとします。

CREATE INDEX hr.indexPayrollDate ON TABLE hr.tabPayroll (payDate);

ターゲットでReplicatによって実行されるCREATE INDEX文は次のとおりです。 

CREATE INDEX hrIndex.indexPayrollDate ON TABLE hrBackup.tabPayroll (payDate);

ターゲットの索引が、ベース・オブジェクトとは異なるスキーマによって所有される必要がある場合、またはターゲットでの名前がソースの名前と異なる必要がある場合、明示的マッピングを使用します。

親トピック: Oracle GoldenGateにおける導出オブジェクト名の処理方法

ベース・オブジェクトに対するMAPはあるが、導出オブジェクトに対するMAPはない場合

導出オブジェクトに対するMAP文はあるが、ベース・オブジェクトに対するものはない場合、Replicatでいずれのオブジェクトに対する名前の変換も行われません。ターゲットのDDL文は、ソースと同じになります。導出オブジェクトをマップするには、次の方法があります。

  • ベース・オブジェクトに対する明示的なMAP文を使用します。

  • 名前に問題がなければ、ワイルドカードを使用してベースと導出の両方のオブジェクトを同じMAP文でマップします。

  • 名前の変換方法に応じて、各オブジェクトに対するMAP文を作成します。

親トピック: Oracle GoldenGateにおける導出オブジェクト名の処理方法

導出オブジェクトとしての新規表

次のものから作成された新規の表のOracle GoldenGateによる処理方法について、次に説明します。

  • RENAMEおよびALTER RENAME

  • CREATE TABLE AS SELECT

親トピック: Oracle GoldenGateにおける導出オブジェクト名の処理方法

CREATE TABLE AS SELECT

CREATE TABLE AS SELECT (CTAS)文には、基礎となる任意の数のオブジェクトを参照するSELECT文とINSERT文が含まれます。デフォルトでは、Oracle GoldenGateにより、ターゲット・データベースからAS SELECT句のデータが取得されます。このパラメータを使用して元の挿入を保持するようにCTAS操作を強制できます。

注意:

このため、CTAS (CREATE TABLE AS SELECT)文から作成されるOracle XMLTypeの表はサポートされません。XMLType表の場合、行オブジェクトIDがソースとターゲットの間で一致する必要がありますが、これは、このシナリオでは保持されません。空のCTAS文(新規表にデータを挿入しない)で作成されたXMLType表は適切に保持されません。

また、CTASによるCTASの挿入への応答を可能にするGETCTASDMLパラメータを使用できるため、レプリケーション中にOIDを保持できます。このパラメータは、統合ディクショナリでのみサポートされるため、トレイルを使用するには、ダウンストリームReplicatが12.1.2.1以上である必要があり、そうでないと、相違が生じる場合があります。

AS SELECT句のオブジェクトがターゲット・データベースに存在し、その名前がソースの名前と同一である必要があります。

MAP文でOracle GoldenGateは、新規の表の名前(CREATE TABLE name)のみTARGET指定にマップします。AS SELECT句の基になるオブジェクトの名前はマップしません。それらのオブジェクトに依存性があり、名前がTARGETの指定に変換されると、データに矛盾が生じる可能性があります。

次に、ソースのCREATE TABLE AS SELECT文の例とそれがOracle GoldenGateによってどのようにレプリケートされるかを示します。 

CREATE TABLE a.tab1 AS SELECT * FROM a.tab2;

ReplicatのMAP文は次のとおりです。 

MAP a.tab*, TARGET a.x*;

Replicatによって適用されるターゲットのDDL文は次のとおりです。

CREATE TABLE a.xtab1 AS SELECT * FROM a.tab2;

AS SELECT * FROM句の表名は、ソースと同じtab2のまま(xtab2ではなく)です。

ソースとターゲットで、基礎となるオブジェクトのデータの一貫性を保つには、Oracle GoldenGateによるデータ・レプリケーションに備えて構成します。前述の例では、次の文を使用してこの要件に対応できます。

ソース

TABLE a.tab*;

ターゲット:

MAPEXCLUDE a.tab2
MAP a.tab*, TARGET a.x*;
MAP a.tab2, TARGET a.tab2;

「DDL内の修飾されていないオブジェクト名の正しい識別」を参照してください。

RENAMEおよびALTER TABLE RENAME

RENAMEおよびALTER TABLE RENAME操作では、ベース・オブジェクトは常に新規の表の名前です。次の例では、ベース・オブジェクト名は、index_paydateとみなされます。 

ALTER TABLE hr.indexPayrollDate RENAME TO index_paydate;

または

RENAME hr.indexPayrollDate TO index_paydate;

導出オブジェクト名はhr.indexPayrollDateです。

導出オブジェクトのマッピングの無効化

NOMAPDERIVEDオプションを指定してDDLOPTIONSパラメータを使用し、これを含むMAP文のTARGET句に従って導出オブジェクトの名前が変換されないようにします。NOMAPDERIVEDによって、ベースまたは導出オブジェクトの名前を含む明示的なMAP文はオーバーライドされます。導出オブジェクトを含むソースDDLは、ソースと同じスキーマとオブジェクト名のターゲットにレプリケートされます。

次の表に、MAP文がベース・オブジェクトのみに対するものか、導出オブジェクトのみに対するものか、両方に対するものかに基づいたMAPDERIVEDの結果を、NOMAPDERIVEDと比較して示します。

ベース・オブジェクト 導出オブジェクト MAP/NOMAP DERIVED MAPごとの導出オブジェクトの変換されるか 導出オブジェクトにベース・オブジェクトのスキーマが割り当てられるか

マップされる脚注 5

マップされる

MAPDERIVED

はい

いいえ

マップされる

マップされない

MAPDERIVED

いいえ

はい

マップされない

マップされる

MAPDERIVED

いいえ

いいえ

マップされない

マップされない

MAPDERIVED

いいえ

いいえ

マップされる

マップされる

NOMAPDERIVED

いいえ

いいえ

マップされる

マップされない

NOMAPDERIVED

いいえ

いいえ

マップされない

マップされる

NOMAPDERIVED

いいえ

いいえ

マップされない

マップされない

NOMAPDERIVED

いいえ

いいえ

脚注5

「マップされる」とは、MAP文に含まれていることを示しています。

次の例では、NOMAPDERIVEDと比較したMAPDERIVEDの結果を示します。次の表では、ベース名と導出名の両方がMAPDERIVEDで変換されるため、トリガーと表のどちらもターゲットのrptに所有されていることを示しています。

MAP文 Extractに取得されたソースDDL文 Replicatにより適用されたターゲットDDL文

MAP fin.*, TARGET rpt.*;

CREATE TRIGGER fin.act_trig ON fin.acct;

CREATE TRIGGER rpt.act_trig ON rpt.acct;

次の表では、トリガーはfinによって所有されています。これは、NOMAPDERIVEDの使用によって変換が防止されているためです。

MAP文 Extractに取得されたソースDDL文 Replicatにより適用されたターゲットDDL文

MAP fin.*, TARGET rpt.*;

CREATE TRIGGER fin.act_trig ON fin.acct;

CREATE TRIGGER fin.act_trig ON rpt.acct;

注意:

RENAME文の場合、新しい表名がベース表名とみなされ、古い表名が導出表名とみなされます。

親トピック: Oracle GoldenGateにおける導出オブジェクト名の処理方法

DDL文字列置換の使用

Oracle GoldenGateによって処理される際、DDL操作内で文字列を置換できます。

この機能によって、ディレクトリ名、コメントおよびデータ構造と直接関係ないその他の文字列の変更とマッピングに対する利便性が増します。たとえば、ある表領域名を別のものに置換したり、コメント内の文字列を置換できます。文字列の置換は、DDLSUBSTパラメータによって制御されます。詳細は、『Oracle GoldenGateリファレンス』を参照してください。

注意:

DDLSUBSTパラメータ文を作成する前に、この章の「処理でDDLが評価される仕組み」を参照することをお薦めします。

親トピック: DDLサポートの構成

様々なトポロジをサポートするためのDDLの伝播の制御

双方向およびカスケード・レプリケーション構成をサポートするには、Oracle GoldenGateおよびローカル・ビジネス・アプリケーションなどのアプリケーションによって実行されたDDLを、Extractが識別できることが重要です。

デプロイする構成によっては、ローカル・システム上のこれらのDDLのソースのいずれかまたは両方をキャプチャすることが適当な場合もあります。

注意:

Oracle GoldenGate DDLは、ログ・グループを作成するためにExtractによって実行されるALTER TABLE文、およびソースDDLの変更をレプリケートするためにReplicatによって実行されるDDLで構成されます。

DDLOPTIONSパラメータの次のオプションは、Oracle GoldenGate DDLサポートが構成され有効になっていることを前提として、ローカル・システム上のDDLがExtractによってキャプチャされ、リモート・システムに送信されるかどうかを制御します。

  • GETREPLICATESおよびIGNOREREPLICATESオプションは、Oracle GoldenGateで生成されたDDLがExtractによってキャプチャされるか無視されるかを制御します。デフォルトはIGNOREREPLICATESで、Oracle GoldenGateで生成されたDDLは伝播されません。Oracle GoldenGateで実行されたDDL操作を識別するために、各Extract文とReplicat DDL文に次のコメントが含まれています。 

    /* GOLDENGATE_DDL_REPLICATION */

  • GETAPPLOPSおよびIGNOREAPPLOPSオプションは、Oracle GoldenGate以外のアプリケーションで生成されたDDLがExtractによってキャプチャされるか無視されるかを制御します。デフォルトはGETAPPLOPSで、DDLはローカル・アプリケーション(Oracle GoldenGate以外の)から伝播されます。

これらのデフォルト設定では、DDLがソースに戻されないように、独自のDDLおよびローカルReplicatによってローカル・データベースに適用されるDDLはExtractで無視されます。また、レプリケーション用に構成されているその他のDDLはすべてキャプチャされます。デフォルトのDDLOPTIONS構成は次のとおりです。 

DDLOPTIONS GETAPPLOPS, IGNOREREPLICATES

この動作は変更できます。次の項を参照してください。

親トピック: DDLサポートの構成

アクティブ/アクティブ(双方向)構成でのDDLの伝播

Oracle GoldenGateでは、2つのシステム間のアクティブ/アクティブDDLレプリケーションがサポートされます。アクティブ/アクティブ双方向レプリケーションの場合、Oracle GoldenGateプロセスで次のように構成される必要があります。

  1. 一方のシステムでビジネス・アプリケーションによって実行されるDDLを他方のシステムにレプリケートし、同期を保つ必要があります。この要件を満たすには、両方のシステムのExtractパラメータ・ファイルでDDLOPTIONS文にGETAPPLOPSオプションを含めます。

  2. 一方のシステムでReplicatによって適用されるDDLは、ローカルのExtractによってキャプチャされ、他方のシステムに戻される必要があります。この要件を満たすには、両方のシステムのExtractパラメータ・ファイルでDDLOPTIONS文にGETREPLICATESオプションを使用します。

    注意:

    ループバックが起こらないよう、内部的なOracle GoldenGateトークンによって、実際のReplicatのDDL文自体は無視されます。ReplicatのDDLを元のシステムに戻す目的は、着信DMLの受信に備えて、そのシステムのReplicatがオブジェクト・メタデータ・キャッシュを更新し、新しいメタデータを持つことです。

  3. 各Replicatは、キャプチャされたReplicat DDL文がリモートExtractから届いたら、そのオブジェクト・メタデータ・キャッシュを更新するように構成する必要があります。この要件を満たすには、両方のシステムのReplicatパラメータ・ファイルでDDLOPTIONS文にUPDATEMETADATAオプションを使用します。

その結果、DDLOPTIONS文は次のようになります。

Extract(プライマリおよびセカンダリ)

DDLOPTIONS GETREPLICATES, GETAPPLOPS

Replicat(プライマリおよびセカンダリ)

DDLOPTIONS UPDATEMETADATA

警告:

元のDDLと同じオブジェクトに対してDDLまたはDMLを発行する前に、元のDDLがリモート・システムにレプリケートされ、そのシステムのExtractによって再度キャプチャされる時間を考慮します。これによって、各操作が元のシステムのReplicatに正しい順序で届くことを保証し、メタデータの非一貫性によってDMLエラーが発生することを防止します。詳細は、次の図を参照してください。

ddl_update_metadata.pngの説明が続きます
図ddl_update_metadata.pngの説明

図のラベルの意味は次のとおりです。

  • 1: ALTER TABLE Customer ADD Birth_Date date

  • 2: 新しいメタデータ: First_Name varchar2(50)、Last_Name varchar2(50)、Address varchar2(50)、City varchar2(50)、Country varchar2(25)、Birth_Date date

  • 3: ALTER TABLE

  • 4: 新しいメタデータ: First_Name varchar2(50)、Last_Name varchar2(50)、Address varchar2(50)、City varchar2(50)、Country varchar2(25)、Birth_Date date

  • 5: ALTER TABLE

  • 6: DDLOPTIONS UPDATEMETADATA 新しいメタデータ: First_Name varchar2(50)、Last_Name varchar2(50)、Address varchar2(50)、City varchar2(50)、Country varchar2(25)、Birth_Date date

DDLOPTIONSの詳細は、『Oracle GoldenGateリファレンス』を参照してください。

双方向構成の構成方法の詳細は、『Oracle GoldenGateの管理』を参照してください。

親トピック: 様々なトポロジをサポートするためのDDLの伝播の制御

カスケード構成でのDDLの伝播

カスケード構成では、各中間システムのExtractパラメータ・ファイルでDDLOPTIONSに次の設定を使用します。この構成では、Extractで中間システムのReplicatからDDLが強制的にキャプチャされ、次のシステム・ダウンストリームにカスケードされます。 

DDLOPTIONS GETREPLICATES, IGNOREAPPLOPS

DDLOPTIONSの詳細は、『Oracle GoldenGateリファレンス』を参照してください

カスケード構成の構成方法の詳細は、Oracle GoldenGateの管理for Windows and UNIXを参照してください。

親トピック: 様々なトポロジをサポートするためのDDLの伝播の制御

サプリメンタル・ログ・グループの自動追加

この項で説明されているタスクを実行するには、DDLOPTIONSパラメータをADDTRANDATAオプションとともに使用します。

DDLOPTIONSを使用して次のタスクを実行できます。

  • CREATE TABLEで作成された新規表に対してOracleのサプリメンタル・ロギングを自動的に有効化します。

  • ALTER TABLEの対象の表のOracleのサプリメンタル・ロギングを更新し、列を追加または削除します。

  • 名前が変更された表のOracleのサプリメンタル・ロギングを更新します。

  • 一意キーまたは主キーが追加または削除された表のOracleのサプリメンタル・ロギングを更新します。

DDLOPTIONS ADDSCHEMATRANDATAを使用するには、ADD SCHEMATRANDATAコマンドをGGSCIで発行してスキーマレベルのサプリメンタル・ロギングを有効にする必要があります。

デフォルトでは、サプリメンタル・ロギングを追加するALTER TABLEは、GETREPLICATESパラメータが使用されていないかぎり、ターゲットにレプリケートされません。

マルチテナント・コンテナ・データベースでは、DDLOPTIONS ADDTRANDATAはサポートされません。詳細は、「ロギング・プロパティの構成」を参照してください。

親トピック: DDLサポートの構成

レプリケートされたDDLからのコメントの削除

DDLOPTIONSパラメータにREMOVECOMMENTS BEFOREおよびREMOVECOMMENTS AFTERオプションを使用し、ソースDDLに使用されたコメントがターゲットDDLに含まれないようにします。

デフォルトでは、コメントは削除されず、文字列の置換に使用できます。

DDLOPTIONSの詳細は、『Oracle GoldenGateリファレンス』を参照してください。

親トピック: DDLサポートの構成

IDENTIFIED BYパスワードのレプリケート

DEFAULTUSERPASSWORDALIASおよびREPLICATEPASSWORD | NOREPLICATEPASSWORDオプションを指定してDDLOPTIONSパラメータを使用し、レプリケートされた{CREATE | ALTER} USER name IDENTIFIED BY password文のパスワードの処理方法を制御します。これらのオプションは一緒に使用する必要があります。

ReplicatがOracle 10gまたは11gデータベースに対して動作する際のパスワード・ベリファイアの指定に関する重要な情報については、DDLOPTIONSのUSEPASSWORDVERIFIERLEVELオプションを参照してください。

DDLOPTIONSの詳細は、『Oracle GoldenGateリファレンス』を参照してください。

注意:

プロファイル/パスワードの検証ファンクションはSYSスキーマに存在する必要があるため、CREATE | ALTER PROFILEのレプリケーションは失敗します。これらのDDLを正常にレプリケートするには、SYSスキーマへのDDLは除外されるため、ソース/ターゲットの両方でパスワード検証ファンクションを手動で作成する必要があります。

親トピック: DDLサポートの構成

処理でDDLが評価される仕組み

この項では、Oracle GoldenGateによるソースおよびターゲット・システムでのDDL文の処理方法について説明します。

Oracle GoldenGateパラメータの異なる基準が処理される順序を示し、ExtractとReplicatがそれぞれDDLを処理する方法の違いについて説明します。

Extract

  1. Extractは、DDL文をキャプチャします。

  2. Extractは、コメントがあれば、メインの文から分離します。

  3. Extractは、DDLパラメータを検索します。(この例では、存在するものとします。)

  4. Extractは、IGNOREREPLICATESパラメータを検索します。これがあり、ReplicatがこのシステムでこのDDLを生成した場合、ExtractはそのDDL文を無視します。(この例では、このシステムではReplicat操作がないものとします。)

  5. Extractは、DDL文がRENAMEかどうかを判断します。そうである場合、名前変更に内部的にフラグが付けられます。

  6. Extractにより、ベース・オブジェクト名と導出オブジェクト名(存在する場合)が取得されます。

  7. 文がRENAMEの場合、ExtractはこれをALTER TABLE RENAMEに変更します。

  8. Extractは、DDLOPTIONS REMOVECOMMENTS BEFOREパラメータを検索します。これがある場合、ExtractはDDL文からコメントを削除しますが、INSTRまたはINSTRCOMMENTSを使用するDDL INCLUDEまたはDDL EXCLUDEに備えてコメントを格納します。

  9. ExtractはDDLのスコープ(MAPPED、UNMAPPEDまたはOTHER)を判断します。

    • 操作とオブジェクト・タイプがマッピングに対してサポートされており、ベース・オブジェクト名や導出オブジェクト名(RENAMEの場合)がTABLEパラメータに含まれている場合、MAPPEDです。

    • 操作とオブジェクト・タイプがマッピングに対してサポートされておらず、ベース・オブジェクト名や導出オブジェクト名(RENAMEの場合)がTABLEパラメータに含まれていない場合、UNMAPPEDです。

    • これ以外の場合、操作はOTHERと識別されます。

  10. Extractは、DDLパラメータにINCLUDE句とEXCLUDE句があるかどうかをチェックし、これらの句のDDLパラメータ基準を評価します。INCLUDEまたはEXCLUDEがTRUEと評価されるには、すべてのオプションがTRUEと評価される必要があります。次のようになります。

    • EXCLUDE句がTRUEと評価される場合、ExtractはDDL文を破棄し、別のDDL文を評価します。この場合、処理の手順が最初から始まります。

    • INCLUDE句がTRUEと評価される場合、またはDDLパラメータにINCLUDE句もEXCLUDE句も含まれていない場合、ExtractはDDL操作を含めて、処理ロジックが続けられます。

  11. Extractは、DDLSUBSTパラメータを検索し、INCLUDE句およびEXCLUDE句を評価します。それらの句の基準が最終的にTRUEになる場合、Extractは文字列の置換を行います。Extractは、パラメータ・ファイル内の各DDLSUBSTパラメータに対してDDL文を評価します。すべてのtrueのDDLSUBST指定について、DDLSUBSTパラメータがファイル内にリストされている順に、Extractによって文字列の置換が行われます。

  12. DDLSUBTが処理されたため、ExtractはREMOVECOMMENTS AFTERパラメータを検索します。これがある場合、ExtractはDDL文からコメントを削除します。

  13. Extractは、DDLOPTIONS ADDTRANDATAを検索します。これがある場合、操作がCREATE TABLEであれば、ExtractはALTER TABLE name ADD SUPPLEMENTAL LOG GROUPコマンドを表に対して発行します。

  14. Extractにより、DDL文が証跡に書き込まれます。

Replicat

  1. Replicatは、DDL文を証跡から読み取ります。

  2. Replicatは、コメントがあれば、メインの文から分離します。

  3. Replicatは、DDLOPTIONS REMOVECOMMENTS BEFOREを検索します。これがある場合、ReplicatはDDL文からコメントを削除します。

  4. Replicatは、DDL同期スコープを評価し、DDLが名前のマッピングに適しているかを判断します。そうでないものは、OTHERスコープです。

  5. Replicatは、パラメータ・ファイルのMAP文を評価します。(証跡から読み取った)このDDLのソースのベース・オブジェクト名がいずれかのMAPに含まれる場合、操作はMAPPEDスコープとしてマークされます。そうではない場合、UNMAPPEDスコープとしてマークされます。

  6. Replicatは、ソースのベース・オブジェクト名を、MAP文のTARGET句に指定されたベース・オブジェクト名で置き換えます。

  7. 導出オブジェクトがある場合、ReplicatはDDLOPTIONS MAPDERIVEDを検索します。これがある場合、Replicatは、ソースの導出名をMAP文のターゲット導出名で置き換えます。

  8. Replicatは、DDLパラメータにINCLUDE句とEXCLUDE句があるかどうかをチェックし、それらに含まれるDDLパラメータ基準を評価します。INCLUDEまたはEXCLUDEがTRUEと評価されるには、すべてのオプションがTRUEと評価される必要があります。次のようになります。

    • EXCLUDE句がTRUEと評価される場合、ReplicatはDDL文を破棄し、別のDDL文の評価を始めます。この場合、処理の手順が最初から始まります。

    • INCLUDE句がTRUEと評価される場合、またはDDLパラメータにINCLUDE句もEXCLUDE句も含まれていない場合、ReplicatはDDL操作を含めて、処理ロジックが続けられます。

  9. Replicatは、DDLSUBSTパラメータを検索し、INCLUDE句およびEXCLUDE句を評価します。それらの句のオプションが最終的にTRUEになる場合、Replicatは文字列の置換を行います。Replicatは、パラメータ・ファイル内の各DDLSUBSTパラメータに対してDDL文を評価します。すべてのtrueのDDLSUBST指定について、DDLSUBSTパラメータがファイル内にリストされている順に、Replicatによって文字列の置換が行われます。

  10. DDLSUBTが処理されたため、ReplicatはREMOVECOMMENTS AFTERパラメータを検索します。これがある場合、ReplicatはDDL文からコメントを削除します。

  11. Replicatは、ターゲット・データベースでDDL操作を実行します。

  12. エラーがない場合は、Replicatにより次のDDL文が処理されます。エラーがある場合は、Replicatにより次の手順が実行されます。

  13. Replicatは、Replicat DDLERRORパラメータのINCLUDEルールとEXCLUDEルールを、パラメータ・ファイルに出現する順に分析します。Replicatは、エラー・コードに対するルールを検出すると、指定されたエラー処理を適用します。検出されない場合は、DEFAULT処理を適用します。

  14. エラー処理によってDDL文が正常完了とならない場合、Replicatは、ルールでの指定に応じて異常終了、操作の無視、または操作の破棄のいずれかを実行します。

注意:

同じソースに対して複数のターゲットがMAP文にある場合、ターゲットごとに処理ロジックが実行されます。

親トピック: DDLサポートの構成

DDLレポート情報の表示

Oracle GoldenGateでは、ExtractおよびReplicatのレポートの最後に、DDLに関する基本的な統計がデフォルトで表示されます。

拡張DDLレポートを有効にするには、REPORTオプションを指定してDDLOPTIONSパラメータを使用します。拡張レポートには、DDL処理に関する次の情報が含まれます。

  • Oracle GoldenGateにより処理されたDDL操作に関する順を追った履歴。

  • 使用されているDDLのフィルタリング・パラメータおよび処理パラメータ。

拡張DDLレポート情報によって、レポート・ファイルのサイズは大きくなりますが、トラブルシューティングやサプリメンタル・ロギングを追加するADDTRANDATAがいつ適用されたかを確認する場合などの特定の状況で役立ちます。

レポートを表示するには、GGSCIでVIEW REPORTコマンドを使用します。 

VIEW REPORT group

親トピック: DDLサポートの構成

ReplicatでのDDLレポートの表示

Replicatレポートには、次がリストされます。

  • Replicatが証跡から処理した各DDL操作の構文全体とソースのOracle GoldenGate SCN。ソースSCNは、特にバックアップからのリストアが存在し、Replicatが証跡の過去の時点に移動される場合に追跡目的で使用できます。

  • 操作のスコープ(MAPPED、UNMAPPED、OTHER)およびターゲットDDL文でオブジェクト名がどのようにマップされたか(該当する場合)を示す後続のエントリ。

  • 処理基準がどのように適用されたかを示す別のエントリ。

  • 操作が成功したか失敗したか、およびReplicatによりエラー処理ルールが適用されたかどうかを示す追加のエントリ。

Replicatレポートの一部である次の例は、一連の処理およびエラー処理を示しています。

2011-01-20 15:11:45  GGS INFO     2104  DDL found, operation [drop table myTableTemp ], Source SCN [1186713.0].
 2011-01-20 15:11:45  GGS INFO     2100  DDL is of mapped scope, after mapping new operation [drop table "QATEST2"."MYTABLETEMP" ].
 2011-01-20 15:11:45  GGS INFO     2100  DDL operation included [include objname myTable*], optype [DROP], objtype [TABLE], objname [QATEST2.MYTABLETEMP].
 2011-01-20 15:11:45  GGS INFO     2100  Executing DDL operation.
 2011-01-20 15:11:48  GGS INFO     2105  DDL error ignored for next retry: error code [942], filter [include objname myTableTemp], error text [ORA-00942: table or view does not exist], retry [1].
 2011-01-20 15:11:48  GGS INFO     2100  Executing DDL operation , trying again due to RETRYOP parameter.
 2011-01-20 15:11:51  GGS INFO     2105  DDL error ignored for next retry: error code [942], filter [include objname myTableTemp], error text [ORA-00942: table or view does not exist], retry [2].
 2011-01-20 15:11:51  GGS INFO     2100  Executing DDL operation, trying again due to RETRYOP parameter.
 2011-01-20 15:11:54  GGS INFO     2105  DDL error ignored for next retry: error code [942], filter [include objname myTableTemp], error text [ORA-00942: table or view does not exist], retry [3].
 2011-01-20 15:11:54  GGS INFO     2100  Executing DDL operation, trying again due to RETRYOP parameter.
 2011-01-20 15:11:54  GGS INFO     2105  DDL error ignored: error code [942], filter [include objname myTableTemp], error text [ORA-00942: table or view does not exist].

親トピック: DDLレポート情報の表示

ExtractでのDDLレポートの表示

Extractレポートには、次がリストされます。

  • キャプチャされた各DDL操作の構文全体、開始と終了のSCN、Oracleインスタンス、DDL順序番号(履歴表のSEQNO列)および操作のサイズ(バイト)。

  • 処理基準がどのように操作に適用されたかを示す後続のエントリ(文字列置換またはINCLUDEとEXCLUDEのフィルタリング)。

  • 操作が証跡に書き込まれたか除外されたかを示す別のエントリ。

Extractレポートから取得された次の例は、含まれた操作と除外された操作を示しています。含まれた操作にはレポート・メッセージがありますが、除外された操作にはありません。

2011-01-20 15:11:41  GGS INFO     2100  DDL found, operation [create table myTable (
    myId number (10) not null,
    myNumber number,
    myString varchar2(100),
    myDate date,
    primary key (myId)
) ], start SCN [1186754], commit SCN [1186772] instance [test11g (1)], DDL seqno [4134].
 
2011-01-20 15:11:41  GGS INFO     2100  DDL operation included [INCLUDE OBJNAME myTable*], optype [CREATE], objtype [TABLE], objname [QATEST1.MYTABLE].
 
2011-01-20 15:11:41  GGS INFO     2100  DDL operation written to extract trail file.
 
2011-01-20 15:11:42  GGS INFO     2100  Successfully added TRAN DATA for table with the key, table [QATEST1.MYTABLE], operation [ALTER TABLE "QATEST1"."MYTABLE" ADD SUPPLEMENTAL LOG GROUP "GGS_MYTABLE_53475" (MYID) ALWAYS  /* GOLDENGATE_DDL_REPLICATION */ ].
 
2011-01-20 15:11:43  GGS INFO     2100  DDL found, operation [create table myTableTemp (
    vid varchar2(100),
    someDate date,
    primary key (vid)
) ], start SCN [1186777], commit SCN [1186795] instance [test11g (1)], DDL seqno [4137].
 
2011-01-20 15:11:43  GGS INFO     2100  DDL operation excluded [EXCLUDE OBJNAME myTableTemp OPTYPE CREATE], optype [CREATE], objtype [TABLE], objname [QATEST1.MYTABLETEMP].

親トピック: DDLレポート情報の表示

プロセス・レポートの統計

GGSCIでSENDコマンドを使用して、DDL処理に関する現在の統計をExtractおよびReplicatのレポートに送信できます。 

SEND {EXTRACT | REPLICAT} group REPORT

統計には、次の総数が表示されます。

  • すべてのDDL操作

  • MAPPEDスコープの操作

  • UNMAPPEDスコープの操作

  • OTHERスコープの操作

  • 除外された操作(操作数から含まれる操作を引いた数)

  • エラー(Replicatのみ)

  • 再試行されたエラー(Replicatのみ)

  • 破棄されたエラー(Replicatのみ)

  • 無視された操作(Replicatのみ)

親トピック: DDLレポート情報の表示

DDL処理のトレース

Oracle GoldenGateテクニカル・サポートでサポート・ケースを開く場合、トレースを有効化するよう求められることがあります。TRACEおよびTRACE2は、DDLトレースを制御します。

『Oracle GoldenGateリファレンス』を参照してください。

親トピック: DDLサポートの構成

トリガーベースのDDLキャプチャをサポートするツールの使用

この項では、トリガーベースのキャプチャをサポートするために使用できる、その他のツールについて説明します。

親トピック: DDLサポートの構成

DDLトリガーのトレース

Oracle GoldenGate DDLトリガーのアクティビティをトレースするには、次のツールを使用します。

  • ggs_ddl_trace.logトレース・ファイル: Oracle GoldenGateでは、OracleのUSER_DUMP_DESTディレクトリにトレース・ファイルを作成します。RACでは、各ノードにそのノードのDDLトレースをキャプチャする独自のトレース・ファイルが存在します。トレース・ファイルは、次のように問い合せることができます。 

    select value from sys.v_$parameter where name = 'user_dump_dest';

  • ddl_tracelevelスクリプト: このスクリプトを編集して実行し、トレース・レベルを設定します。値Noneでは、致命的エラーとインストール・ログ以外、DDLトレースは生成されません。デフォルト値の0では、最小限のトレース情報が生成されます。値1または2では、トレース・ファイルに多くの情報が生成されます。サポート・ケースの一環としてOracle GoldenGateテクニカル・サポートのアナリストから求められないかぎり、1または2は使用しないでください。

  • ddl_cleartraceスクリプト: このスクリプトを定期的に実行して、トレース・ファイルの増大によりディスク領域が過度に使用されることを防止します。ファイルは削除されますが、Oracle GoldenGateによって別のファイルが作成されます。DDLトリガーは、Oracleディレクトリの領域が少なくなるとトレース・ファイルへの書込みを停止し、領域が再度使用可能になると書込みを再開します。このスクリプトは、Oracle GoldenGateディレクトリにあります。スクリプトを実行する前に、トレース・ファイルをバックアップします。

親トピック: トリガーベースのDDLキャプチャをサポートするツールの使用

DDL履歴表のメタデータの表示

GGSCIでDUMPDDLコマンドを使用して、DDL履歴表に含まれている情報を表示します。この情報は、独自の形式で格納されていますが、判読可能な形式で画面に出力したり、問合せ可能な一連のSQL表にエクスポートすることができます。DDL履歴表の情報は、Extractプロセスによって使用されるものと同じです。

親トピック: トリガーベースのDDLキャプチャをサポートするツールの使用

DDLトリガー・エラーの処理

params.sql非実行可能スクリプトで、ソースDDLの失敗または成功に関連するOracle GoldenGate DDLトリガーの失敗を処理します。params.sqlスクリプトは、ルートのOracle GoldenGateディレクトリにあります。使用するパラメータは次のとおりです。

  • ddl_fire_error_in_trigger: TRUEに設定されている場合、Oracle GoldenGate DDLトリガーの失敗は、Oracle GoldenGateエラー・メッセージおよびデータベース・エラー・メッセージとともにソースのエンドユーザー・アプリケーションに示されます。ソースの処理は失敗します。

    FALSEに設定されている場合、エラーは発生せず、メッセージは、Oracle GoldenGateディレクトリのトリガー・トレース・ファイルに書き込まれます。ソースの処理は成功しますが、DDLはレプリケートされません。後続のデータ変更が古いターゲット・オブジェクトの構造に適合しない場合、ターゲット・アプリケーション最終的には失敗します。デフォルトはFALSEです。

  • ddl_cause_error: TRUEに設定されている場合、故意にエラーを発生させ、トリガーのエラー・レスポンスをテストします。エラーを生成するために、Oracle GoldenGateで、例外処理を使用せずに0(ゼロ)行をSELECTしようとします。テストが終了したら、このフラグをデフォルトのFALSEに戻します。

親トピック: トリガーベースのDDLキャプチャをサポートするツールの使用

エディションベース再定義の使用

Oracle GoldenGateは、エディションベース再定義(EBR)の使用をサポートしており、アプリケーションのデータベース・コンポーネントの使用中でも、Oracle Databaseでそれらのコンポーネントをアップグレードできるため、ダウンタイムをゼロまたは最小限に抑えることができます。

エディションは、エディション付きオブジェクトが属する非スキーマ・オブジェクトです。エディションは、エディション付きオブジェクトを所有している、またはネームスペースと考えることができます。すべてのデータベースは、ORA$BASEという名前の1つのエディションから始まり、これには、アップグレードされたデータベースが含まれます。データベースには複数のエディションが存在することができますが、それぞれの子は1つのみです。たとえば、edition1、edition2、edition3の3つのエディションを連続して作成した場合、edition1はedition2の親になり、edition2はedition3の親になります。これは、それらを作成するユーザーまたはデータベース・セッションに関係なく、新しいエディションが作成された際に、どのエディションが最新であるかにも関係ありません。エディションを作成すると、その親のすべてのエディション付きオブジェクトを継承します。Oracle GoldenGateでエディションを使用するには、それらを作成する必要があります。エディションの作成および管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

オブジェクトがエディション化可能なタイプの場合、エディション付きとみなされ、EDITIONABLE属性で作成され、スキーマは、そのオブジェクト・タイプのエディション化に有効です。エディション付きオブジェクトを作成、変更または削除すると、それが属するエディションの名前がREDOログに記録されます。コンテナ・データベースでは、エディションはコンテナに属し、各コンテナには、独自のデフォルト・エディションが含まれます。

CREATE | DROP EDITION DDLは、すべてのExtract構成でキャプチャされます。これらはOTHERカテゴリに分類され、EDITIONのOBJTYPEオプション値が割り当てられます。OBJTYPEオプションは、次のようなフィルタリングに使用できます。 

DDL EXCLUDE OBJTYPE EDITION
DDL EXCLUDE OBJTYPE EDITION OPTYPE CREATE
DDL EXCLUDE OBJTYPE EDITION OPTYPE DROP
DDL EXCLUDE OBJTYPE EDITION OPTYPE DROP ALLOWEMPTYOWNER OBJNAME edition_name

ExtractまたはReplicatからエディションを除外するには、次の構文を使用する必要があります。

EXCLUDE OBJTYPE EDITION, ALLOWEMPTYOWNER OBJNAME edition_name

エディションは、OTHERカテゴリに分類されるため、エディション名でマッピングは実行されません。適用されると、USE権限がReplicatユーザーに自動的に付与されます。Replicatは、元の作成ユーザーがターゲット・データベースに存在する場合、そのユーザーに対してgrant use on edition name with grant optionも実行します。エディションはマップ可能な操作ではないため、所有者は含まれず、このため標準のEXCLUDE文が機能しません。

エディションの作成または変更に使用されるDDLは、実際にはエディションのユーザーを有効にせず、エディションのスキーマを有効にします。DDLをエディション付きオブジェクトに適用するために、Replicatユーザーを有効にする必要はないため、この区別は重要です。ReplicatがCREATE EDITION DDLを適用すると、元のユーザーがターゲット・データベースに存在する場合は、ユーザー作成の元の権限がUSEに付与されます。レプリケートされていないCREATE EDITION文の場合は、USE WITH GRANT OPTIONを発行して、Replicatユーザーに付与する必要があります。

エディション化可能なオブジェクトがエディション付きになるかどうかは、適用されるスキーマによって制御されます。エディション名の属性が証跡ファイルに存在し、空でない場合に、Replicatは、DDLを適用する前に、その現在のセッション・エディションを切り替えます。

コンテナ・データベース環境は、ExtractおよびReplicatの両方でサポートされます。追加の構成は必要ありません。Replicatユーザーのスキーマは、共通ユーザーの場合エディションに対して有効にすることはできません。DDLを他のスキーマのエディション付きオブジェクトに適用するときに、Replicatユーザーのスキーマをエディションに対して有効にする必要はありません。

注意:

EBRサポートは統合ディクショナリに制限されます。DDLトリガーの使用時にはサポートされません。

親トピック: DDLサポートの構成