自動スキーマ展開でサポートされる操作

自動スキーマ展開は、Oracle、MySQL、PostgreSQL、SQL Server、Db2 LUW、DB2400、TeradataおよびOracle TimesTenターゲットでサポートされています。

自動スキーマ展開は、Oracle、MySQL、PostgreSQL、SQL Server、Db2 LUW、Db2 zOS、DB2400、Sybase、Teradata、Oracle TimesTenおよびSnowflakeソースでサポートされています。

次の操作がサポートされます。

デフォルトの自動スキーマ展開レスポンスは、AUTOSCHEMAOPTIONSを使用してオーバーライドできます。次のオプションがサポートされています。
- TYPEMAP: このオプションを使用して、デフォルトのデータ型マッピングをオーバーライドします
- IGNORE_DATA_TRUNCATION: デフォルトのデータ型マッピングでデータ切捨ての可能性が予測される場合、Replicatはデフォルトで適切なエラーで異常終了します。これらのデータ切捨てエラーを無視し、異常終了せずにReplicatを続行できるようにするには、Replicatパラメータ・ファイルでAUTOSCHEMAOPTIONS IGNORE_DATA_TRUNCATIONを指定します。
- IGNORE_MODIFY_KEY_COLUMN: デフォルトでは、自動スキーマ展開では主キー列の変更が許可されず、Replicatは適切なエラーで異常終了します。AUTOSCHEMAOPTIONS IGNORE_MODIFY_KEY_COLUMNを指定すると、キー列に対する変更をスキップできます。
- ALLOW_MODIFY_KEY_COLUMN: デフォルトでは、自動スキーマ展開では主キー列の変更は許可されず、Replicatは異常終了します。AUTOSCHEMAOPTIONS ALLOW_MODIFY_KEY_COLUMNを指定すると、キー列に対するすべての変更を許可できます。
- MODIFY_COLUMN_NULLABILITY_ONLY: AUTOSCHEMAOPTIONS MODIFY_COLUMN_NULLABILITY_ONLYを指定できるのは、列のNULL値可能性の変更のみで、型の変更は対象外の場合です。

自動スキーマ展開では、ソース表とターゲット表の同期を保持するために、証跡ファイルのメタデータ・レコードから検出されたスキーマ変更に基づいて、次の操作がサポートされます。

ターゲット・データベースでの欠落表の作成
ADD/MODIFY/DROP列の実行によるターゲット表の変更

すべてのソース列メタデータに基づいて、デフォルトで、対応するターゲット列にベスト・フィット・データ型が選択されます。

注意:自動スキーマ展開を実装する前に、データ型マッピングから特定のソース・データベースとターゲット・データベースのレプリケーション・シナリオに適用可能なデフォルトのデータ型マッピングを確認してください。

すべてのケースで、ターゲット・データ型がソース・データ型と完全に同じであるとはかぎりません。可能なかぎり、ターゲット・データ型の選択は、ターゲット・タイプが常に互換性があり、(ソース列と同じサイズまたはより広いサイズで)対応するソース列のデータに対応できる大きさになるように行われます。ターゲット・データベース上の対応するソース列のデータ型に適切な型がない(ターゲット・データベースで使用可能な型がデータの切捨てを引き起こす可能性があるなど)場合、適切な推奨事項でエラーがユーザーに返されます。

欠落表の作成

AutoSchemaでは、次のユースケースがサポートされます。

CDC Extractによって生成された証跡データの適用中に、ターゲットに欠落している表を作成します。
初期ロードExtractによって生成された証跡データの適用中に、ターゲットに欠落している表を作成します。
initialLoad Extractによって生成された証跡のみを適用するときに、DDL AUTOSCHEMA包含基準の一部としてOPTYPE RECREATEを指定することで、既存のターゲット表を削除し、別のExtractを作成することを選択できます。
証跡メタデータの対応するすべてのソース・キー列がNULL値可能でない場合、自動スキーマは、対応するすべての列を含むPRIMARY KEY句を使用してターゲット表を作成します。
証跡メタデータから対応するソース・キー列のいずれかがNULL値可能である場合、自動スキーマは、対応するすべての列を含むUNIQUE KEY句を使用してターゲット表を作成します。

既存の表の変更

ソースで列が追加/削除/変更された場合、対応するALTER TABLE DDLが生成され、対応するマップされたターゲット表に対して実行されます。自動スキーマでは、型(データ型名、長さ、精度、スケール(該当する場合)を含む)およびnullability制約のみに関連する変更がサポートされます。ただし、他の列属性に対する変更は考慮されません。ソース列でタイプ/NULL値可能性関連のスキーマ変更が検出された場合、それらはターゲット列に伝播されます。

ソース表で1つまたは複数のスキーマを変更すると、特定のターゲット・データベースでのサポートに応じて、マップされたターゲット表で1つまたは複数のALTER TABLE DDLが発生する可能性があります。ターゲットに対するDDLの数は、次のような特定のターゲット・データベースでサポートされる構文によって異なります。

1つのALTER TABLE DDLで複数の列を追加/削除/変更できないデータベースはほとんどありません。
1つのALTER TABLE DDL文で列の型とnullabilityの両方を変更できないデータベースはほとんどありません。

このような場合、ターゲット・データベースの要件に基づいて、必要な数のALTER TABLE DDL文がターゲット表で実行されます。

自動スキーマは、さらにアクションが必要なターゲット・データベースに影響を与える可能性があります。たとえば、ALTER TABLE MODIFY COLUMNによってデータが切り捨てられる場合、異なるデータベースで異なる方法で処理できます。データベースでは、操作によって一部の既存データが切り捨てられることが検出され、Replicatが停止する可能性があります。これは通常、MySQLが厳密モードを有効にして実行されている場合、OracleとMySQLの間で発生します。ただし、MySQLが非厳密モードで構成されている場合、警告なしでトラクションが発生する可能性があります。

IBM iの場合、システムの構成方法によっては、Replicatがハングしているように見える場合があります。Db2 (以前のDb2 LUW)およびDb2 z/OSに対する一部のアクションでは、特定のアクションで表の再編成が必要になる場合があります。Db2 z/OSでは、再編成が実行されるまで削除列は認識されず、Db2の場合、表は再編成保留状態になり、それに対するさらなる操作の許可を停止する可能性があります。

ノート:必要に応じて、OPTYPE ADDCOLUMN、OPTYPE DROPCOLUMNおよびOPTYPE MODIFYCOLUMNをDDL AUTOSCHEMAの包含/除外基準に選択的に追加できます。