13.3 Oracle GoldenGateにおけるDDLサポートの制限事項

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

13.3.1 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レポート・ファイルに記録されます。
出力ファイルの名前。

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

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

Oracle GoldenGateは、スタンバイ・データベースではDDLをサポートしていません。

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

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

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

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

13.3.4 名前変更

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

13.3.5 表からのフェッチと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がデータをフェッチする前に、表の名前が変更されている可能性があります。

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

表に対するすべてのDMLを一時停止します。
Extractが残りのすべてのREDOのキャプチャを終了するのを待ち、Replicatがキャプチャされたデータの証跡からの処理を終了するのを待ちます。Replicatが終了したかどうかを判断するには、処理するデータがこれ以上存在しないことを示すメッセージが表示されるまでGGSCIで次のコマンドを発行します。
```
INFO REPLICAT group
```
DDLをソースで実行します。
ソースのDML操作を再開します。

13.3.6 SQL内のコメント

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

ソース:

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

ターゲット:

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

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

13.3.7 コンパイル・エラー

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

13.3.8 時間隔パーティション化

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

alter table t2 drop partition for (20);

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

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

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

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