データベース取り込みおよびレプリケーションタスクのトラブルシューティング

ソースカラムのサポートされていないデータ型をサポートされているデータ型に変更すると、変更がターゲットにレプリケートされない場合があります。

この問題は、［カラムの修正］スキーマドリフトオプションが［レプリケート］に設定されていて、［カラムの追加］オプションが［無視］に設定されている場合に発生します。

タスクをデプロイするときに、データベース取り込みとレプリケーションは、サポートされていないデータ型を持つソースカラムに対してターゲットカラムを作成しません。ソースカラムのサポートされていないデータ型を後でサポートされているデータ型に変更した場合、データベース取り込みとレプリケーションはソースに対するカラムの修正操作を処理しますが、変更をターゲットにレプリケートしません。データベース取り込みとレプリケーションがサポートされているデータ型のカラムをターゲットに追加しようとすると、スキーマドリフトオプション［カラムの追加］が［無視］に設定されているため、操作は無視されます。

この状況に対処するには、次の手順を実行します。

1. 1データベース取り込みとレプリケーションタスクウィザードの［スケジュールとランタイムオプション］ページの［スキーマドリフトオプション］で、［カラムの追加］オプションを［レプリケート］に設定します。
2. 2ソースカラムのデータ型をサポートされているデータ型に再度変更し、データベース取り込みとレプリケーションジョブがこのスキーマの変更を検出できるようにします。
ジョブはDDL操作を処理し、新しいターゲットカラムを作成します。
注: ジョブは、ソースカラムのデータ型を変更する前に追加されたカラムの値をプロパゲートしません。
3. 3ソースカラムのすべての値をターゲットにプロパゲートする場合は、ターゲットテーブルをソースと再同期します。

ソースのプライマリキー制約を変更した場合、データベース取り込みとレプリケーションはDDLの変更が発生したソーステーブルの処理を停止します。

この問題は、プライマリキー制約を追加または削除した場合、または既存のプライマリキーに対してカラムを追加または削除した場合に発生します。

初期ジョブと増分ジョブを組み合わせたジョブでソーステーブルの処理を再開するには、ターゲットテーブルをソースと再同期します。

増分ジョブでソーステーブルの処理を再開するには、次の手順を実行します。

1. 1データベース取り込みとレプリケーションタスク定義の［ソース］タブで、ソーステーブルを除外するテーブル選択ルールを追加します。
2. 2タスクを再デプロイします。
データベース取り込みとレプリケーションは編集したタスクをデプロイし、除外されたテーブルのプライマリキーに関する情報を削除します。
3. 3タスクを再度編集して、ソーステーブルを除外したテーブル選択ルールを削除します。
4. 4タスクを再デプロイします。

DDLのカラムレベルの変更によってソーステーブルサブタスクが停止するかエラーが発生した後、データベース取り込みとレプリケーションジョブを再開すると、想定されているテーブル状態の変更が遅れます。

ソーステーブルでのDDLのカラムレベルの変更によってテーブルサブタスクが停止するかエラーが発生した後、データベース取り込みとレプリケーションジョブを再開すると、テーブルに対してDML操作が発生するまで、テーブルサブタスクの状態は変更されないままとなることがあります。例えば、増分または初期と増分の組み合わせのデータベース取り込みタスクでスキーマドリフトオプションを［テーブルの停止］に設定した後、ジョブをデプロイして実行すると、ソーステーブルに対してDDLの変更が発生した場合、ジョブモニタリングの詳細には、テーブルサブタスクがエラー状態であることが示されます。ジョブを停止し、スキーマドリフトオーバーライドを使用してジョブを再開してDDLの変更をレプリケートすると、ソーステーブルに対して最初のDML操作が発生するまで、テーブルサブタスクは一時的にエラー状態のままになります。

データベース取り込みとレプリケーションは、Snowflakeターゲットを持つタスクのデプロイに次のエラーで失敗します。

Information schema query returned too much data. Please repeat query with more selective predicates.

このエラーは、スキーマクエリに関連する既知のSnowflakeの問題が原因で発生します。詳細については、Snowflakeのドキュメントを参照してください。

データベース取り込みとレプリケーションでは、多数のソーステーブルが選択されている場合、このエラーによって、Snowflakeターゲットを持つデータベース取り込みとレプリケーションタスクのデプロイに失敗することがあります。

デプロイの失敗に対処するには、ターゲットテーブルを削除します。次に、データベース取り込みとレプリケーションタスクを更新して、ターゲットテーブルを生成する対象として選択するソーステーブルの数を減らします。次に、タスクを再度デプロイしてみます。

Linuxで実行されるデータベース取り込みとレプリケーションジョブは、次のメモリ不足エラーで異常終了します。

java.lang.OutOfMemoryError: unable to create new native thread

オペレーティングシステムに設定されているユーザープロセスの最大数を超えている可能性があります。最大ユーザープロセスのLinux ulimit値がまだunlimitedに設定されていない場合、unlimitedまたはそれ以上の値に設定します。その後、ジョブを再開します。

アセットを、同じ名前のアセットがすでに含まれている別の場所にコピーすると、次のいずれかのエラーで操作が失敗する場合があります。

Operation succeeded on 1 artifacts, failed on 1 artifacts.
Operation did not succeed on any of the artifacts.

アセットを、同じ名前のアセットが既に存在する別の場所にコピーしようとすると、データベース取り込みとレプリケーションは、一方に「- Copy 1」などのサフィックスを付けることで両方のアセットを保持するかどうかを尋ねる警告メッセージを表示します。両方のアセットを保持することを選択した場合、データベース取り込みとレプリケーションは名前の長さを検証して、サフィックスが追加されても最大長の50文字を超えないことを確認します。名前の長さが50文字を超えると、コピー操作は失敗します。この場合、アセットを別の場所にコピーし、コピーの名前を変更してから、名前を変更したアセットを元の場所に戻す必要があります。

Kafkaコンシューマが次のいずれかのエラーで終了します。

org.apache.avro.AvroTypeException: Invalid default for field meta_data: null not a {"type":"array"...
org.apache.avro.AvroTypeException: Invalid default for field header: null not a {"type":"record"...

このエラーは、コンシューマが新しいAvroバージョンにアップグレードされたが、古いバージョンのAvroスキーマファイルを引き続き使用しているために発生する可能性があります。

この問題を解決するには、データベース取り込みとレプリケーションが提供する新しいAvroスキーマファイルを使用します。

Confluentスキーマレジストリを使用するKafkaターゲットに増分変更データをプロパゲートするデータベース取り込みとレプリケーションジョブは、次のエラーで失敗します。

io.confluent.kafka.schemaregistry.client.rest.exceptions.RestClientException: Register operation timed out; error code: 50002

この問題は、ジョブが多くのソーステーブルを処理している場合に発生することがあります。多くのスキーマを処理するにはConfluentスキーマレジストリが必要です。この問題を解決するには、Confluentスキーマレジストリのkafkastore.timeout.msオプションの値を増やしてみてください。このオプションは、Kafkaストアに対する操作のタイムアウトを設定します。詳細については、Confluentスキーマレジストリのドキュメントを参照してください。

Google BigQueryターゲットを持つデータベース取り込みとレプリケーションジョブのサブタスクは、次のエラーでソーステーブルの初期ロード処理を完了できません。

The job has timed out on the server. Try increasing the timeout value.

この問題は、ジョブが多くのソーステーブルを処理するように構成されており、ソーステーブルの初期ロード処理が完了する前にGoogle BigQueryターゲット接続がタイムアウトした場合に発生します。この問題を解決するには、Google BigQuery V2ターゲット接続プロパティのタイムアウト間隔を増やします。

1. 1Administratorで、データベース取り込みジョブに関連付けられているGoogle BigQuery V2接続を編集モードで開きます。
2. 2［オプションのプロパティを指定］フィールドで、timeoutプロパティを、必要なタイムアウト間隔（秒単位）に設定します。次の形式を使用します。
"timeout": "<timeout_interval_in_seconds>"
3. 3接続を保存します。
4. 4データベース取り込みとレプリケーションタスクを再デプロイします。

Amazon Redshiftターゲットを持つデータベース取り込みとレプリケーションタスクは、デプロイ中に次のエラーのいずれかを返します。

データベース取り込みとレプリケーション could not find target table 'table_name' which is mapped to source table 'table_name' when deploying the database ingestion task.

com.amazon.redshift.util.RedshiftException: ERROR: Relation "table_name" already exists

この問題は、Amazon Redshiftがデフォルトでテーブル名とカラム名を小文字として読み取るために発生します。

このエラーを防ぐために、データベースパラメータグループを設定するときに、enable_case_sensitive_identifierパラメータを「true」に設定します。このパラメータの詳細については、AWS Amazon Redshiftのドキュメント（https://docs.aws.amazon.com/redshift/latest/dg/r_enable_case_sensitive_identifier.html）を参照してください。

ソーステーブルまたはカラム名にマルチバイト文字または特殊文字が含まれ、ターゲットがDatabricks Deltaである場合、データベース取り込みとレプリケーションタスクのデプロイは失敗します。

デプロイ中に新しいDatabricksターゲットテーブルが作成されると、Databricksが使用するHiveメタストアにエントリが追加されます。Hiveメタストアは通常MySQLデータベースです。より具体的に説明すると、カラム名はメタストアのTABLE_PARAMSフィールドに挿入されます。TABLE_PARAMSからのPARAM_VALUEの文字セット照合はlatin1_binであり、文字セットはlatin1です。この文字セットは日本語の文字をサポートしていません。この問題を解決するには、照合がUTF-8_bin、文字セットがUTF-8である外部メタストアを作成します。詳細については、https://docs.microsoft.com/en-us/azure/databricks/kb/metastore/jpn-char-external-metastoreとhttps://kb.databricks.com/metastore/jpn-char-external-metastore.htmlでDatabricksのドキュメントを参照してください。

Azure Synapse Analyticsターゲットと、日本語データを持つテーブルが含まれているOracle、PostgreSQL、またはSAP HANAソースを使用したデータベース取り込みとレプリケーションの初期ロードタスクでは、ターゲットカラムに日本語データが???文字として書き込まれる場合があります。

この問題を解決するには、タスクを編集して、次のソースデータ型をターゲットデータ型にマッピングするカスタムデータ型マッピングを追加します。

• - Oracleソースの場合:
VARCHAR2(25) -> NVARCHAR(MAX)
VARCHAR2 (152) -> NVARCHAR(MAX)
• - PostgreSQLソースの場合:
CHARACTER VARYING(25) -> NVARCHAR(MAX)
CHARACTER VARYING(125) -> NVARCHAR(MAX)
• - SAP HANAソースの場合:
TEXT(25) -> NVARCHAR(MAX)
TEXT(125) -> NVARCHAR(MAX)

XMLデータを含むSQL ServerソースとMicrosoft Azure Synapse Analyticsターゲットを含むデータベース取り込みとレプリケーションの初期ロードジョブが失敗する

500,000文字以上の半角文字のXMLカラムデータを含むSQL ServerソースとMicrosoft Azure Synapse Analyticsターゲットを含むデータベース取り込みとレプリケーションジョブを実行すると、Synapse Analyticsがターゲット テーブルを作成するためのSQLクエリを処理しようとした場合に、サブタスクが失敗することがあります。データをターゲットテーブルに書き込む前に、データベース取り込みとレプリケーションはデフォルトでXMLデータを500,000バイトに切り捨て、xバイトの補助メタデータを追加します。Synapse Analyticsは、各ソース文字を2バイトとして格納し、最大行サイズは1000000バイトとなります。その結果、ターゲット表に書き込まれる行のバイト数が、最大ターゲット行サイズよりも大きくなる可能性があります。この場合、サブタスクは失敗し、トレースメッセージで次のような情報が報告されます。

Unexpected error encountered filling record reader buffer: HadoopExecutionException: The size of the schema/row at ordinal 1 is 1000050 bytes. It exceeds the maximum allowed row size of 1000000 bytes for Polybase.

この問題を修正するには、適切な下限切り捨てポイントを指定し、それをタスクウィザードの［ターゲット］ページのunloadClobTruncationSizeカスタムプロパティで指定します。行にXMLカラムが1つしかない場合は、<実際のスキーマ/行サイズ>と最大行サイズの差の分だけ切り捨てポイントを減らします。例えば、前述のサンプルメッセージに基づいて、1つのXMLカラムを含む行の下限切り捨てポイントを500000 - 50、つまり、499950バイトとして計算します。

Informaticaストアドプロシージャの処理中にプロセッサリソースの制限を超えると、Db2 for z/OSソースを使用したデータベース取り込みとレプリケーションの増分ロードジョブが異常終了する

z/OSソースシステムでSELECT、INSERT、UPDATE、DELETEなどのSQL操作で使用されるプロセッサリソースの量を制限するため、Db2 DSNRLSTxxリソース制限テーブルを使用すると、Db2 for z/OSソースを使用したデータベース取り込みとレプリケーションの増分ロードジョブが異常終了する場合があります。デフォルトまたは設定されたリソース制限が、キャプチャされた変更データを処理するためにデータベース取り込みとレプリケーションジョブが使用するWLMストアドプロシージャの長時間処理に対応するのに十分な大きさでない場合、ジョブは終了します。リソース制限に関連する異常終了が発生した場合は、次の手順を実行します。

1. 1ランタイム環境で、データベース取り込みとレプリケーションパッケージ専用のリソース制限テーブルに行を追加します。次のカラムを含む行を追加します。
• ▪ データベース取り込みとレプリケーションタスクが使用する認証IDを持つAUTHIDカラムか、データベース取り込みとレプリケーションタスクと同じパッケージ名を持つRLFPDGカラム、またはこれら両方のカラム。
• ▪ NULLまたはデフォルトの制限値より大きいリソース制限が定義されたASUTIMEカラム。
2. 2リソース制限テーブルへの変更を有効にするには、Db2 -START RLIMITコマンドを発行します。

これらの手順を実行する権限がない場合は、Db2 DBAまたはz/OSのシステムプログラマに問い合わせてください。