翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

での移行タスクのトラブルシューティング AWS Database Migration Service

Database Migration Service () AWS に関する問題のトラブルシューティングに関するトピックを以下に示しますAWS DMS。これらのトピックは、 AWS DMS と選択したエンドポイントデータベースの両方を使用して一般的な問題を解決するのに役立ちます。

AWS サポートケースを開いた場合、サポートエンジニアはエンドポイントデータベース設定の 1 つに関する潜在的な問題を特定する可能性があります。エンジニアが、データベースに関する診断情報を返すためのサポート スクリプトを実行するように頼む場合もあります。タスク設定ファイルを使用してタスク設定を設定する方法については、「での診断サポートスクリプトの使用 AWS DMS」をご参照ください。

トラブルシューティングの目的で、 はレプリケーションインスタンスにトレースファイルとダンプファイルを AWS DMS 収集します。トラブルシューティングが必要な問題が発生した場合は、これらのファイルを AWS サポートに提供できます。デフォルトでは、 は 30 日以上経過したトレースファイルとダンプファイルをDMS消去します。トレースとダンプファイルの収集をオプトアウトするには、 AWS サポートでケースを開きます。

移行タスクの実行が遅い

移行タスクの実行が遅くなる、または後続のタスクの実行が初期タスクより遅くなる原因として、いくつかの問題が考えられます。

移行タスクの実行が遅い最も一般的な理由は、 AWS DMS レプリケーション インスタンスに割り当てられたリソースが不十分であることです。インスタンスで実行しているタスクに十分なリソースがあることを確認するには、レプリケーションインスタンスの CPU、メモリ、スワップファイル、および の使用を確認しますIOPS。例えば、エンドポイントとしての Amazon Redshift の複数のタスクは I/O 集約型です。レプリケーションインスタンスIOPSの を増やすか、複数のレプリケーションインスタンスにタスクを分割して、より効率的な移行を行うことができます。

レプリケーションのインスタンスサイズの決定に関する詳細については、「レプリケーションインスタンス向けの最適なサイズの選択」をご参照ください。

以下を実行すると、初期の移行のロードがスピードアップします。

タスクのステータスバーが動かない

タスクのステータスバーで、タスクの進捗状況を予測できます。この予測の正確さはソースデータベースのテーブル統計の正確さによって異なります。テーブル統計が正確であればあるほど、正確に予測できます。

推定行統計がないテーブルが 1 つだけのタスクの場合、 AWS DMS は完全な割合の見積もりを一切提供できません。この場合、タスクのステータスと、ロードされた行の表示を使って、タスクが実際に実行されて進行していることを確認できます。

タスクは完了しましたが、何も移行されませんでした

タスクの完了後に何も移行されなかった場合は、次の操作を実行します。

外部キーとセカンダリ インデックスが見つからない

AWS DMS はテーブル、プライマリキー、および場合によっては一意のインデックスを作成しますが、ソースからデータを効率的に移行するのに必要のない他のオブジェクトは作成しません。たとえば、セカンダリインデックス、非プライマリキーの制約、データデフォルトは作成されません。

データベースからセカンダリオブジェクトを移行するには、ソースデータベースと同じデータベースエンジンに移行中の場合、データベースのネイティブツールを使用します。ソースデータベースで使用したものと異なるデータベースエンジンへ移行中の場合、 AWS Schema Conversion Tool (AWS SCT) を使用してセカンダリオブジェクトを移行します。

AWS DMS は CloudWatch ログを作成しない

レプリケーションタスクで CloudWatch ログが作成されない場合は、アカウントに dms-cloudwatch-logs-roleロールがあることを確認してください。このロールが存在しない場合は、次を実行して作成します。

Amazon への接続で問題が発生する RDS

ソースまたはターゲットとして設定した Amazon RDS DB インスタンスに接続できない理由はいくつかあります。チェックすべき項目：

エラーメッセージ: スレッドの接続文字列が正しくありません。正しくないスレッド値「0」

エンドポイントへの接続をテストしているとき、このエラーが頻繁に発生します。このエラーは、接続文字列にエラーがあることを示します。例えば、ホスト IP アドレスの後ろにスペースがあります。もう一つは、接続文字列にコピーされた不正な文字です。

ネットワーキングに関する問題の発生

最も一般的なネットワークの問題は、レプリケーションインスタンスで使用されるVPC AWS DMS セキュリティグループです。デフォルトでは、このセキュリティグループではすべてのポートの 0.0.0.0/0 からの送信を許可するルールがあります。多くの場合、このセキュリティグループを変更するか、独自のセキュリティグループを使用します。その場合は、少なくとも、それぞれのデータベースポート上のソース エンドポイントとターゲット エンドポイントに出力を与えるようにしてください。

その他の設定関連の問題には、次のようなものがあります：

独自のオンプレミス ネームサーバーの使用については、「 独自のオンプレミスネームサーバーの使用」をご参照ください。

CDC 全ロード後に がスタックする

複数の AWS DMS 設定が互いに競合すると、全ロード移行後に、レプリケーション変更が遅くなるか停止することがあります。

例えば、[Target table preparation mode](ターゲットテーブル作成モード) パラメータが [Do nothing](何もしない)または[Truncate](切り詰め) に設定されているとします。この場合、プライマリインデックスと一意のインデックスの作成を含め、ターゲットテーブルで設定を行わない AWS DMS ように に指示しました。ターゲットテーブルにプライマリキーまたは一意のキーを作成していない場合、 は更新ごとに完全なテーブルスキャン AWS DMS を実行します。このアプローチは、パフォーマンスに大きな影響を与える可能性があります。

タスク再開時のプライマリ キー制約違反エラー

このエラーは、以前の移行タスクからのターゲットデータベースにデータが残っている場合に発生することがあります。ターゲットテーブルの準備モードオプションが 何もしない に設定されている場合、前のタスクから挿入されたデータのクリーンアップを含め、ターゲットテーブルの準備は実行しません。 AWS DMS

タスクを再開し、これらのエラーを回避するために、タスクの以前の実行からターゲットテーブルに挿入される行を削除する必要があります。

スキーマの初回ロードが失敗する

場合によっては、スキーマの初期ロードがエラー Operation:getSchemaListDetails:errType=, status=0, errMessage=, errDetails= で失敗することがあります。

このような場合、ソースエンドポイント AWS DMS への接続に が使用するユーザーアカウントには、必要なアクセス許可がありません。

不明なエラーが発生してタスクが失敗する

不明なタイプのエラーの原因はさまざまです。ただし、多くの場合、この問題には AWS DMS レプリケーション インスタンスに割り当てられたリソースが不足していることがわかります。

レプリケーションインスタンスに移行を実行するのに十分なリソースがあることを確認するには、インスタンスの CPU、メモリ、スワップファイル、および の使用を確認しますIOPS。モニタリングの詳細については、「AWS Database Migration Service メトリクス」をご参照ください。

タスクを再開するとテーブルが最初からロードされる

AWS DMS は、テーブルの初期ロードが完了していない場合、テーブルのロードを最初から再開します。タスクが再起動されると、 は最初の AWS DMS ロードが完了しなかったときの最初からテーブルを再ロードします。

タスクあたりのテーブル数が問題の原因の問題

レプリケーション タスクあたりのテーブル数に制限はありません。ただし、経験則として、タスク内のテーブルの数を 60,000 個未満に制限することをお勧めします。1 つのタスクが 60,000 個超のテーブルを使用すると、多くの場合リソース使用がボトルネックになることがあります。

LOB 列にプライマリキーが作成されるとタスクが失敗する

FULL LOB または LIMITEDLOBモードでは、LOBデータ型であるプライマリキーのレプリケーションは AWS DMS サポートされていません。

DMS は、列が null LOBである行を最初に移行し、その後LOB列を更新します。したがって、プライマリキーがLOB列に作成されると、プライマリキーを null にすることはできないため、最初の挿入は失敗します。回避策として、別の列をプライマリキーとして追加し、LOBその列からプライマリキーを削除します。

プライマリ キーのないターゲットテーブル上の重複レコード

フルロードとCDCタスクを実行すると、プライマリキーまたは一意のインデックスを持たないターゲットテーブルに重複レコードが作成される可能性があります。フルロードおよびCDCタスク中にターゲットテーブルのレコードが重複しないようにするには、ターゲットテーブルにプライマリキーまたは一意のインデックスがあることを確認してください。

予約済み IP 範囲の送信元エンドポイント

AWS DMS ソースデータベースが 192.168.0.0/24 の予約済み IP 範囲内の IP アドレスを使用している場合、ソースエンドポイントの接続テストは失敗します。次のステップは、考えられる回避方法を提供します：

エンドポイントに前述の Amazon EC2インスタンスの IP アドレスとデータベースポートを使用します AWS DMS 。エンドポイントに、データベースポートへのアクセス AWS DMS を許可するセキュリティグループがあることを確認します。プロキシは、DMSタスクの実行中に実行する必要があることに注意してください。ユースケースによっては、プロキシのセットアップを自動化する必要がある場合があります。

Amazon Athena クエリでタイムスタンプが文字化けする

Athena クエリでタイムスタンプがガブルされている場合は、 AWS Management Console または ModifyEndpointアクションを使用して Amazon S3 エンドポイントのparquetTimestampInMillisecond値を に設定しますtrue。詳細については、[S3Settings] (S3設定)をご参照ください。

Oracle に関する問題のトラブルシューティング

以下に、Oracle データベース AWS DMS での の使用に固有の問題のトラブルシューティングについて説明します。

ビューからデータを取得する

ビューからデータを 1 回プルできます。これを継続的レプリケーションに使用することはできません。ビューからデータを抽出できるようにするには、Oracle ソースエンドポイントページの [エンドポイント設定] セクションに次のコードを追加する必要があります。ビューからデータを抽出すると、そのビューはターゲットスキーマのテーブルとして表示されます。

"ExposeViews": true

Oracle 12c LOBsからの移行

AWS DMS は、Oracle データベースの変更をキャプチャするために、Binary Reader と Oracle の 2 つの方法を使用できます LogMiner。デフォルトでは、 は Oracle AWS DMS を使用して変更 LogMiner をキャプチャします。ただし、Oracle 12c では、Oracle はLOB列をサポート LogMiner していません。Oracle 12c のLOB列への変更をキャプチャするには、Binary Reader を使用します。

Oracle LogMiner と Binary Reader の切り替え

AWS DMS は、ソース Oracle データベースの変更をキャプチャするために、Binary Reader と Oracle の 2 つの方法を使用できます LogMiner。Oracle LogMiner がデフォルトです。Binary Reader を使用して変更をキャプチャするように切り替えるには、次を実行します。

エラー: Oracle CDCが 122301 oracle CDC 最大再試行カウンターを超過しました。

このエラーは、必要な Oracle アーカイブログを AWS DMS が使用して変更をキャプチャする前にサーバーから削除した場合に発生します。データベースサーバーのログリテンションポリシーを増やします。Amazon RDS データベースの場合は、次の手順を実行してログの保持期間を長くします。例えば、次のコードでは、Amazon RDS DB インスタンスのログ保持期間が 24 時間に増加します。

exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24);
            

Oracle ソース エンドポイントにサプリメンタル ログを自動的に追加する

デフォルトでは、 AWS DMS はサプリメンタルログ記録をオフにしています。Oracle ソースエンドポイントのサプリメンタルロギングを自動的にオンにするには、以下の手順を実行します。

LOB 変更がキャプチャされない

現在、LOB変更をキャプチャ AWS DMS するには、テーブルに のプライマリキーが必要です。を含むテーブルにプライマリキーLOBsがない場合、LOB変更をキャプチャするために実行できるアクションがいくつかあります。

エラー: ORA-12899: 列の値が多すぎます column-name

エラーORA「-12899: 列の値が大きすぎます column-name「 は多くの場合、いくつかの問題が原因で発生します。

これらの問題の 1 つで、ソースデータベースとターゲットデータベースで使用される文字セットに不一致があります。

これらの問題の別の点では、2 つのデータベース間で各国語サポート (NLS) の設定が異なります。このエラーの一般的な原因は、ソースデータベース NLS_LENGTH_SEMANTICS パラメータが に設定CHARされ、ターゲットデータベース NLS_LENGTH_SEMANTICS パラメータが に設定されている場合ですBYTE。

NUMBER データ型が誤って解釈されている

Oracle NUMBER データ型は、 の精度とスケールに応じて、さまざまな AWS DMS データ型に変換されますNUMBER。このような変換はOracle のソースデータ型に記載されています。NUMBER タイプを変換する方法は、ソース Oracle エンドポイントのエンドポイント設定を使用することによっても影響を受ける可能性があります。エンドポイントの設定は「のソースとして Oracle を使用する場合のエンドポイント設定 AWS DMS」に記載されています。

全ロード中にレコードが欠落している

全ロードを実行すると、 はデータベースレベルで開いているトランザクション AWS DMS を検索し、トランザクションがコミットされるのを待ちます。例えば、タスク設定 に基づいてTransactionConsistencyTimeout=600、開いているトランザクションがテーブルマッピングに含まれていないテーブルにある場合でも、 は 10 分間 AWS DMS 待機します。ただし、オープントランザクションがテーブルマッピングに含まれるテーブルにあり、トランザクションが時間内にコミットされていない場合、ターゲットテーブルの結果からレコードが欠落します。

TransactionConsistencyTimeout タスクの設定変更し、オープントランザクションがコミットに時間がかかることがわかっている場合は、待機時間を増やします。

また、FailOnTransactionConsistencyBreached タスク設定が false のデフォルト値であることに注意してください。つまり、他のトランザクション AWS DMS は引き続き適用されますが、オープントランザクションは失われます。オープントランザクションが時間内に終了しないときにタスクが失敗するようにするには、FailOnTransactionConsistencyBreached を true に設定できます。

テーブルエラー

WHERE 句がプライマリ キー列を参照するわけではなく、サプリメンタル ログがすべての列に使用されるわけではない場合、レプリケーション中に Table Error がテーブル統計情報に表示されます。

この問題を解決するには、参照テーブルのすべての列のサプリメンタル ログを有効にします。詳細については、「サプリメンタル ロギングの設定」をご参照ください。

エラー:Oracle アーカイブされた REDO ログの宛先 ID を取得できません

このエラーは、Oracle ソースにアーカイブログが生成されていないか、V$ARCHIVED_LOG が空の場合に発生します。ログを手動で切り替えることで、エラーを解決できます。

Amazon RDS データベースの場合は、次の手順を実行してログファイルを切り替えます。switch_logfile プロシージャにはパラメータがありません。

exec rdsadmin.rdsadmin_util.switch_logfile;

自己管理 Oracle ソース データベースの場合、次のコマンドを使用してログ スイッチを強制します。

ALTER SYSTEM SWITCH LOGFILE ;

Oracle REDO ログまたはアーカイブログの読み取りパフォーマンスの評価

Oracle ソースでパフォーマンスの問題が発生した場合は、Oracle REDO ログまたはアーカイブログの読み取りパフォーマンスを評価して、パフォーマンスを改善する方法を探ることができます。REDO またはアーカイブログの読み取りパフォーマンスをテストするには、AWS DMS 診断用 Amazon マシンイメージ () を使用しますAMI。

AWS DMS 診断を使用してAMI、次の操作を実行できます。

その後、結果に基づいて是正措置を講じることができます。

My に関する問題のトラブルシューティングSQL

以下に、 AWS DMS と MySQL データベースの使用に固有の問題のトラブルシューティングについて説明します。

CDC バイナリログ記録が無効になっているため、Amazon RDS DB インスタンスエンドポイントの タスクが失敗する

自動バックアップが無効になっているため、この問題は Amazon RDS DB インスタンスで発生します。バックアップ保持期間を 0 以外の値に設定することで自動バックアップを有効にすることができます。

ターゲットへの接続 SQLタスク中にインスタンスが切断される

My ターゲットから切断LOBsされている SQLのタスクがある場合、タスクログに次のタイプのエラーが表示されることがあります。

[TARGET_LOAD ]E: RetCode: SQL_ERROR SqlState: 08S01 NativeError: 
2013 Message: [MySQL][ODBC 5.3(w) Driver][mysqld-5.7.16-log]Lost connection 
to MySQL server during query [122502] ODBC general error.

 [TARGET_LOAD ]E: RetCode: SQL_ERROR SqlState: HY000 NativeError: 
2006 Message: [MySQL][ODBC 5.3(w) Driver]MySQL server has gone away 
[122502] ODBC general error.

この場合、一部のタスク設定の調整が必要になる場合があります。

タスクがターゲットSQLから切断される問題を解決するには、次の手順を実行します。

システム変数の設定については、SQL「マイドキュメント」の「サーバーシステム変数」を参照してください。 SQL

SQL互換エンドポイントへの自動コミットの追加

ターゲットの My SQL互換エンドポイントで外部キーを無効にする

My の外部キーチェックを無効にするには、ターゲット My SQL、Amazon Aurora My SQL互換エディションSQL、または MariaDB エンドポイントの Advanced セクションで、次の接続属性を追加します。

文字が疑問符に置き換えられる

この問題を引き起こす最も一般的な状況は、ソースエンドポイント文字が がサポート AWS DMS していない文字セットによってエンコードされている場合です。

[Bad event](不良イベント) ログのエントリ

移行ログの「不正なイベント」エントリは通常、サポートされていないデータ定義言語 (DDL) オペレーションがソースデータベースエンドポイントで試行されたことを示します。サポートされていないDDLオペレーションは、レプリケーションインスタンスがスキップできないイベントを引き起こすため、不正なイベントがログに記録されます。

この問題を解決するには、タスクを最初から再起動します。これにより、テーブルが再ロードされ、サポートされていないDDLオペレーションが発行された後の時点で変更のキャプチャが開始されます。

MySQL 5.5 でデータキャプチャを変更する

AWS DMS Amazon RDS My SQL互換データベースの 変更データキャプチャ (CDC) には、My バージョン 5.5 SQL以前ではサポートされていない完全なイメージ行ベースのバイナリログ記録が必要です。を使用するには AWS DMS CDC、Amazon RDS DB インスタンスを MySQL バージョン 5.6 にアップグレードする必要があります。

Amazon RDS DB インスタンスのバイナリログの保持期間を長くする

AWS DMS では、変更データキャプチャのためにバイナリログファイルを保持する必要があります。Amazon RDS DB インスタンスのログ保持期間を増やすには、次の手順を使用します。以下の例では、バイナリログの保持を 24 時間に延長します。

call mysql.rds_set_configuration('binlog retention hours', 24);
            

ログメッセージ: ソースデータベースからの一部の変更は、ターゲットデータベースに適用されても効果がありません。

が MySQL データベース列の値を既存の値に AWS DMS 更新すると、My から のメッセージが返されzero rows affectedますSQL。この動作は、Oracle や SQL Server などの他のデータベースエンジンとは異なります。これらのエンジンは、置換値が現在の値と同じであっても、1 つの行を更新します。

エラー: 識別子が長すぎます

以下のエラーは識別子が長すぎるときに発生します。

TARGET_LOAD E: RetCode: SQL_ERROR SqlState: HY000 NativeError: 
1059 Message: MySQLhttp://ODBC 5.3(w) Driverhttp://mysqld-5.6.10Identifier 
name 'name' is too long 122502 ODBC general error. (ar_odbc_stmt.c:4054)
            

場合によっては、ターゲットデータベースにテーブルとプライマリキーを作成する AWS DMS ように を設定します。このような場合、 DMS は現在、ソースデータベースで使用されたプライマリキーに同じ名前を使用しません。代わりに、 はテーブル名に基づいてプライマリキー名DMSを作成します。テーブル名が長い場合、自動生成された識別子は、My で許可されている制限よりも長くすることができますSQL。

この問題の当面解決策として、まずターゲットデータベースでテーブルとプライマリキーを事前に作成します。次に、タスク設定[Target table preparation mode] (ターゲットテーブル作成モード)を [Do nothing] (何もしない)または[Truncate] (切り詰め) に設定するタスクを使用し、ターゲットテーブルに代入します。

エラー: サポートされていない文字セットによりフィールドデータ変換が失敗しました

以下のエラーは、サポートされていない文字セットによりフィールドデータ変換が失敗した場合に発生します。

"[SOURCE_CAPTURE ]E: Column 'column-name' uses an unsupported character set [120112] 
A field data conversion failed. (mysql_endpoint_capture.c:2154)
            

接続に関係したデータベースのパラメータを確認します。以下のコマンドを使用してこれらのパラメータを設定できます。

SHOW VARIABLES LIKE '%char%';
            

エラー: コードページ 1252 から UTF8 [120112] へのフィールドデータ変換に失敗しました

ソース MySQL データベースに codepage-1252 以外の文字がある場合、移行中に次のエラーが発生する可能性があります。

  
[SOURCE_CAPTURE ]E: Error converting column 'column_xyz' in table
'table_xyz with codepage 1252 to UTF8 [120112] A field data conversion failed. 
(mysql_endpoint_capture.c:2248)
                

回避策として、ソース My SQLエンドポイントでCharsetMapping追加の接続属性を使用して文字セットマッピングを指定できます。このエンドポイント設定を追加する場合、 AWS DMS 移行タスクを最初から再起動する必要がある場合があります。

例えば、ソース文字セットが Utf8または であるソースSQLエンドポイントには、次のエンドポイント設定を使用できますlatin1。65001 はUTF8コードページ識別子です。

   
CharsetMapping=utf8,65001
CharsetMapping=latin1,65001
                

インデックス、外部キー、カスケード更新、または削除が移行されない

AWS DMS は、インデックスや外部キーなどのセカンダリオブジェクトの移行をサポートしていません。カスケード更新または削除オペレーションから子テーブルに加えられた変更をレプリケートするには、ターゲットテーブルでトリガーを実行する外部キー制約をアクティブにする必要があります。この制限を回避するには、ターゲットテーブルに外部キーを手動で作成します。次に、以下に説明CDCするように、フルロード と 用に 1 つのタスクを作成するかCDC、フルロード と 用に 2 つの個別のタスクを作成します。

フルロードと をサポートする単一のタスクを作成する CDC

この手順では、1 つのタスクを使用して外部キーとインデックスをフルロードと に移行する方法について説明しますCDC。

フルロードとCDCタスクを個別に作成する

以下の手順では、フルロード用の個別のタスクと を使用して外部キーとインデックスを移行する方法について説明しますCDC。

Postgre に関する問題のトラブルシューティングSQL

以下に、PostgreSQL データベース AWS DMS での の使用に固有の問題のトラブルシューティングについて説明します。

JSON 切り捨てられるデータ型

AWS DMS は PostgreSQL JSONのデータ型をLOBデータ型列として扱います。つまり、制限付きLOBモードを使用する場合LOBのサイズ制限がJSONデータに適用されます。

例えば、制限LOBモードが 4,096 KB に設定されているとします。この場合、4,096 KB を超えるJSONデータは 4,096 KB の制限で切り捨てられ、Postgre での検証テストに失敗しますSQL。

次のログ情報はJSON、 LOB モード設定が制限され、検証に失敗したために が切り捨てられたことを示しています。

03:00:49
2017-09-19T03:00:49 [TARGET_APPLY ]E: Failed to execute statement: 
  'UPDATE "public"."delivery_options_quotes" SET "id"=? , "enabled"=? , 
  "new_cart_id"=? , "order_id"=? , "user_id"=? , "zone_id"=? , "quotes"=? , 
  "start_at"=? , "end_at"=? , "last_quoted_at"=? , "created_at"=? , 
  "updated_at"=? WHERE "id"=? ' [1022502] (ar_odbc_stmt
2017-09-19T03:00:49 [TARGET_APPLY ]E: Failed to execute statement: 
  'UPDATE "public"."delivery_options_quotes" SET "id"=? , "enabled"=? , 
  "new_cart_id"=? , "order_id"=? , "user_id"=? , "zone_id"=? , "quotes"=? , 
  "start_at"=? , "end_at"=? , "last_quoted_at"=? , "created_at"=? , 
  "updated_at"=? WHERE "id"=? ' [1022502] (ar_odbc_stmt.c:2415)

03:00:49
2017-09-19T03:00:49 [TARGET_APPLY ]E: RetCode: SQL_ERROR SqlState: 
  22P02 NativeError: 1 Message: ERROR: invalid input syntax for type json;, 
  Error while executing the query [1022502] (ar_odbc_stmt.c:2421)
2017-09-19T03:00:49 [TARGET_APPLY ]E: RetCode: SQL_ERROR SqlState: 
  22P02 NativeError: 1 Message: ERROR: invalid input syntax for type json;, 
  Error while executing the query [1022502] (ar_odbc_stmt.c:2421)

ユーザー定義のデータ型の列が正しく移行されない

PostgreSQL ソースからレプリケートする場合、 は、ユーザー定義のデータ型の列を除き、すべての列に対して同じデータ型のターゲットテーブル AWS DMS を作成します。このような場合、データ型はターゲットで「character varying」として作成されます。

エラー: 作成用のスキーマが選択されていません

場合によっては、SQL「_ERROR SqlState: 3F000 NativeError: 7 Message: ERROR: no schema has been selected to create in」というエラーが表示されることがあります。

このエラーは、JSONテーブルマッピングにスキーマのワイルドカード値が含まれているが、ソースデータベースがその値をサポートしていない場合に発生する可能性があります。

テーブルの削除と更新が を使用してレプリケートされない CDC

ソーステーブルにプライマリキーがない場合、変更データキャプチャ (CDC) 中の削除および更新オペレーションは無視されます。 は、プライマリキーを持つ PostgreSQL テーブルの変更データキャプチャ (CDC) AWS DMS をサポートします。

テーブルにプライマリキーがない場合、先行書き込み (WAL) ログにはデータベース行の前イメージは含まれません。この場合、 AWS DMS はテーブルを更新できません。削除オペレーションをレプリケートする場合は、ソーステーブルにプライマリ キーを作成します。

TRUNCATE ステートメントが反映されない

変更データキャプチャ (CDC) を使用する場合、TRUNCATEオペレーションは ではサポートされていません AWS DMS。

PostgreSQL によるキャプチャの防止 DDL

次のエンドポイント設定DDLステートメントを追加することで、PostgreSQL ターゲットエンドポイントがステートメントをキャプチャしないようにできます。

"CaptureDDLs": "N"
            

キャプチャするデータベースオブジェクトがDDL作成されるスキーマの選択

キャプチャに関連するデータベースオブジェクトDDLが作成されるスキーマを制御できます。次の [エンドポイント設定] ステートメントを追加します。この [エンドポイント設定] パラメータは、ソースエンドポイントのタブで提供されています。

"DdlArtifactsSchema: "xyzddlschema"                
            

Postgre への移行後に Oracle テーブルが見つからないSQL

この場合、通常、テーブルとデータには引き続きアクセスできます。

Oracle のデフォルトは大文字のテーブル名、PostgreSQL のデフォルトは小文字のテーブル名です。Oracle から Postgre への移行を実行する場合はSQL、タスクのテーブルマッピングセクションで特定の変換ルールを指定することをお勧めします。これらは、テーブル名の大文字と小文字を変換するための変換ルールです。

テーブル名のケースを変換する変換ルールを使わずにテーブルを移行した場合、それらを参照するときテーブル名を引用符で囲みます。

ReplicationSlotDiskUsage は増加し、restart_lsn はETLワークロードなどの長いトランザクション中に進行を停止します。

論理レプリケーションが有効な場合、トランザクションあたりのメモリに保持される変更の最大数は 4MB です。その後、変更がディスクにこぼれます。その結果 ReplicationSlotDiskUsage が増加し、restart_lsnは、トランザクションが完了/中止され、ロールバックが完了するまで進みません。トランザクションが長いので、ロールバックに長時間かかることがあります。

従って、論理レプリケーションが有効になっている場合は、トランザクションの長期実行を避けてください。代わりに、トランザクションをいくつかの小さなトランザクションに分割してください。

ソースとしてビューを使用したタスクで行がコピーされない

ビューを移行するには、table-type を all または view に設定します。詳細については、「 コンソールからテーブル選択および変換を指定する」を参照してください。

ビューをサポートするソースには、次のようなものがあります。

Microsoft SQL Server に関する問題のトラブルシューティング

ここでは、Microsoft SQL Server データベース AWS DMS での の使用に固有の問題のトラブルシューティングについて説明します。

RDS for SQL Server がセカンダリにフェイルオーバーした後、継続的なレプリケーションが失敗する

ソースSQLサーバーインスタンスがセカンダリにフェイルオーバーした場合、 AWS DMS 継続的なレプリケーションは接続を試み続け、ソースがオンラインに戻った後もレプリケーションを続行します。ただし、SQLサーバーMAZインスタンスRDSの場合、特定の状況では、セカンダリデータベース所有者を に設定することができますNT AUTHORITY\SYSTEM。フェイルオーバー後、タスクは次のエラーでDMS失敗します。

[SOURCE_CAPTURE  ]E:  RetCode: SQL_ERROR  SqlState: 42000 NativeError: 33009 Message: 
                [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]The database owner SID recorded in the master 
                database differs from the database owner SID recorded in database 'rdsadmin'. You should correct 
                this situation by resetting the owner of database 'rdsadmin' using the ALTER AUTHORIZATION statement. 
                Line: 1 Column: -1 [1022502]  (ar_odbc_stmt.c:5035)

これを修正するには、「db_owner をデータベース の rdsa アカウントに変更する」の手順に従ってタスクを再開しますDMS。

SQL サーバーデータベースの変更のキャプチャエラー

変更データキャプチャ (CDC) 中のエラーは、前提条件の 1 つが満たされていないことを示していることがよくあります。たとえば、最も一般的に見過ごされる前提条件は、完全データベースバックアップです。タスクログは以下のエラーで、この欠落を示します。

SOURCE_CAPTURE E: No FULL database backup found (under the 'FULL' recovery model). 
To enable all changes to be captured, you must perform a full database backup. 
120438 Changes may be missed. (sqlserver_log_queries.c:2623)                
            

で SQL Server をソースとして使用するための前提条件を確認しますのソースとしての Microsoft SQL Server データベースの使用 AWS DMS。

IDENTITY 列が存在しない

AWS DMS は、ターゲットスキーマの作成時に ID 列をサポートしていません。初期ロードの完了後に追加する必要があります。

エラー: SQL サーバーはパブリケーションをサポートしていません

SQL Server Express をソースエンドポイントとして使用すると、次のエラーが生成されます。

RetCode: SQL_ERROR SqlState: HY000 NativeError: 21106 
Message: This edition of SQL Server does not support publications.                
            

AWS DMS は現在、ソースまたはターゲットとして SQL Server Express をサポートしていません。

ターゲットに変更が表示されない

AWS DMS では、変更を一貫してキャプチャするために、ソースSQLサーバーデータベースがFULL「」またはBULKLOGGED「」のデータ復旧モデルにある必要があります。SIMPLE「」モデルはサポートされていません。

SIMPLE 復旧モデルは、ユーザーがデータベースを復旧するために必要な最小限の情報をログに記録します。すべての非アクティブのログエントリは、チェックポイントが発生すると自動的に切り捨てられます。

すべてのオペレーションは引き続きログに記録されます。ただし、チェックポイントが発生するとすぐに、ログは自動的に切り捨てられます。この切り捨ては、ログが再利用可能になり、古いログエントリを上書きできることを意味します。ログエントリが上書きされると、変更をキャプチャできません。この問題は、 AWS DMS がSIMPLEデータ復旧モデルをサポートしていない理由です。SQL Server をソースとして使用するために必要なその他の前提条件については、「」を参照してくださいのソースとしての Microsoft SQL Server データベースの使用 AWS DMS。

パーティションにまたがってマッピングされる不均一テーブル

変更データキャプチャ (CDC) 中、 がテーブルCDCで適切に実行 AWS DMS できない場合、特殊な構造を持つテーブルの移行は中断されます。次のようなメッセージが発行されます。

[SOURCE_CAPTURE ]W: Table is not uniformly mapped across partitions. Therefore - it is excluded from CDC (sqlserver_log_metadata.c:1415)
[SOURCE_CAPTURE ]I: Table has been mapped and registered for CDC. (sqlserver_log_metadata.c:835)
            

SQL サーバーテーブルCDCで を実行すると、 はSQLサーバーログを AWS DMS 解析します。各ログレコードで、 は、変更中に挿入、更新、または削除された列のデータを含む 16 進値を AWS DMS 解析します。

16 進数レコードを解析するために、 はSQLサーバーシステムテーブルからテーブルメタデータを AWS DMS 読み取ります。これらのシステムテーブルは、特別に構造化されたテーブルカラムが何であるかを識別し、「xoffset」や「null bit position」などの内部プロパティの一部を表示します。

AWS DMS は、テーブルのすべての raw パーティションでメタデータが同じであることを想定しています。しかし、場合によっては、特別に構造化されたテーブルのすべてのパーティションで同じメタデータが保持されないことがあります。このような場合は、変更CDCを誤って解析し、ターゲットに誤ったデータを提供しないように、そのテーブルで を停止 AWS DMS できます。回避策には、次のものが含まれます：

Amazon Redshift に関する問題のトラブルシューティング

以下に、Amazon Redshift データベース AWS DMS での の使用に固有の問題のトラブルシューティングについて説明します。

異なる AWS リージョンの Amazon Redshift クラスターにロードする

レプリケーションインスタンスとは異なる AWS AWS DMS リージョンの Amazon Redshift クラスターにロードすることはできません。DMS では、レプリケーション インスタンスと Amazon Redshift クラスターが同じ リージョンにある必要があります。

エラー: リレーション「awsdms_apply_exceptions」がすでに存在します

「Relation 'awsdms_apply_exceptions' already exists」というエラーは、Redshift エンドポイントが PostgreSQL エンドポイントとして指定されている場合によく発生します。この問題を解決するには、エンドポイントを変更し、[Target engine] を「redshift」に変更します。

名前が「awsdms_changes」で始まるテーブルのエラー

名前が[awsdms_changes]で始まるテーブルに関連するエラーメッセージは、同一の Amazon Redshift クラスターにデータをロードしようとする 2 つのタスクが同時に実行される場合に頻繁に発生します。一時テーブルに名前が付けられる方法のため、同じテーブルを更新する場合、同時に実行されるタスクは競合する場合があります。

dms.awsdms_changes000000000XXXX のような名前のクラスター内のテーブルの表示

AWS DMS は、Amazon S3 に保存されているファイルからデータがロードされるときに一時テーブルを作成します。このような一時テーブルの名前には、プレフィックス dms.awsdms_changes が付きます。これらのテーブルは、 がデータを最初にロードしたとき、および最終的なターゲットテーブルに配置される前に AWS DMS 保存するために必要です。

Amazon Redshift での作業に必要なアクセス許可

Amazon Redshift AWS DMS で を使用するには、Amazon Redshift へのアクセスに使用するユーザーアカウントに次のアクセス許可が必要です。

Amazon Redshift をターゲットとして使用するための前提条件を確認するには、「AWS Database Migration Service のターゲットとしての Amazon Redshift データベースの使用」をご参照ください。

Amazon Aurora My に関する問題のトラブルシューティングSQL

ここでは、Amazon Aurora MySQL データベース AWS DMS での の使用に固有の問題のトラブルシューティングについて説明します。

エラー: CHARACTERSETUTF8フィールドは「」で終了し、「」で囲まれた行は「\n」で終了します

Amazon Aurora MySQL をターゲットとして使用している場合、ログに次のようなエラーが表示されることがあります。このタイプのエラーは通常、ANSI_QUOTES パラメータの一部として SQL_MODE があることを示します。ANSI_QUOTES パラメータの一部として SQL_MODE を指定すると、二重引用符が引用符のように処理され、タスクの実行時に問題が発生する可能性があります。

このエラーを修正するには、ANSI_QUOTES パラメータから SQL_MODE を削除します。

2016-11-02T14:23:48 [TARGET_LOAD ]E: Load data sql statement. load data local infile 
"/rdsdbdata/data/tasks/7XO4FJHCVON7TYTLQ6RX3CQHDU/data_files/4/LOAD000001DF.csv" into table 
`VOSPUSER`.`SANDBOX_SRC_FILE` CHARACTER SET UTF8 fields terminated by ',' 
enclosed by '"' lines terminated by '\n'( `SANDBOX_SRC_FILE_ID`,`SANDBOX_ID`,
`FILENAME`,`LOCAL_PATH`,`LINES_OF_CODE`,`INSERT_TS`,`MODIFIED_TS`,`MODIFIED_BY`,
`RECORD_VER`,`REF_GUID`,`PLATFORM_GENERATED`,`ANALYSIS_TYPE`,`SANITIZED`,`DYN_TYPE`,
`CRAWL_STATUS`,`ORIG_EXEC_UNIT_VER_ID` ) ; (provider_syntax_manager.c:2561) 
            

に関する問題のトラブルシューティング SAP ASE

次に、 SAP ASE データベース AWS DMS で を使用することに固有の問題のトラブルシューティングについて説明します。

エラー: ソースにNULL値を含む複合一意インデックスがある場合、LOB列にはNULL値があります

NULL 値を許容する複合一意インデックスで設定されたテーブルでソースSAPASEとして を使用すると、継続的なレプリケーション中にLOB値が移行されない場合があります。この動作は通常、DMSレプリケーションインスタンスクライアントで ANSI_NULL がデフォルトで 1 に設定された結果です。

LOB フィールドが正しく移行されるようにするには、タスクの AWS DMS ソースエンドポイント'AnsiNull=0'にエンドポイント設定を含めます。

Db2 IBM に関する問題のトラブルシューティング

次に、Db2 データベース AWS DMS での IBM の使用に固有の問題のトラブルシューティングについて説明します。

エラー: Resume from timestamp is not supported Task

継続的なレプリケーション (CDC) で、特定のタイムスタンプからレプリケーションを開始する場合は、接続属性StartFromContextを必要なタイムスタンプに設定します。詳細については、Db2 を使用する場合のエンドポイント設定LUW」を参照してください。StartFromContext を必要なタイムスタンプに設定すると、次の問題が防止されます。

Last Error Resume from timestamp is not supported Task error notification received from 
subtask 0, thread 0 [reptask/replicationtask.c:2822] [1020455] 'Start from timestamp' was blocked to prevent Replicate from 
scanning the log (to find the timestamp). When using IBM DB2 for LUW, 'Start from timestamp' is only supported if an actual 
change was captured by this Replicate task earlier to the specified timestamp.