メニュー
AWS Database Migration Service
ユーザーガイド (Version API バージョン: 2016-01-01)

移行タスクのトラブルシューティング

以下のセクションでは、AWS Database Migration Service (AWS DMS) に関連する問題のトラブルシューティングの情報を提供します。

移行タスクの実行の遅れ

移行タスクの実行が遅くなる、または後続のタスクの実行が初期タスクより遅くなる原因として、複数の問題が考えられます。移行タスクの実行が遅くなる最も一般的な原因は、AWS DMS のレプリケーションのインスタンスに割り当てられているリソースが不十分であることです。レプリケーションのインスタンスの CPU、メモリ、スワップ、および IOPS の使用率をチェックし、インスタンスのリソースが実行中のタスクのために十分であることを確認します。たとえば、エンドポイントとしての Amazon Redshift の複数のタスクは I/O 集約型です。レプリケーションのインスタンスに対して IOPS を増やすか、より効率的に移行するためにレプリケーションの複数のインスタンス間で作業を分割できます。

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

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

  • ターゲットが Amazon RDS DB インスタンスの場合、Multi-AZ がターゲット DB インスタンスに対して有効にされていないことを確認します。

  • ロード中の自動バックアップまたはターゲットデータベースでのログ作成をオフにし、移行が完了したらこれらの機能をオンに戻します。

  • プロビジョンド IOPS がターゲットで利用可能な場合は、この機能を使用します。

  • 移行データに LOB が含まれる場合は、タスクが LOB 移行のために最適化されていることを確認します。LOB 用の最適化の詳細については、「ターゲットメタデータのタスク設定」を参照してください。

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

タスクのステータスバーで、タスクの進捗状況を予測できます。この予測の正確さはソースデータベースのテーブル統計の正確さによって異なります。テーブル統計が正確であればあるほど、正確に予測できます。予測された列の統計がないテーブルが 1 つだけのタスクでは、どのような種類であっても完了率の予測を提供できません。この場合、タスクのステータスと、ロードされた列の表示を使って、タスクが実際に実行されて進行していることを確認できます。

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

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

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

Amazon RDS 接続問題

エンドポイントとして設定した Amazon RDS DB インスタンスに接続できない理由は複数考えられます。具体的には次のとおりです。

  • ユーザー名とパスワードの組み合わせが間違っています。

  • インスタンス用に Amazon RDS コンソールに表示されるエンドポイント値が AWS DMS エンドポイントを作成するのに使用したエンドポイント識別子と同じであることを確認します。

  • インスタンス用に Amazon RDS コンソールで表示されるポート値が AWS DMS エンドポイントに割り当てられたポートと同じであることを確認します。

  • Amazon RDS DB インスタンスに割り当てられたセキュリティグループが、AWS DMS のレプリケーションのインスタンスからの接続を許可することを確認します。

  • AWS DMS のレプリケーションのインスタンスと Amazon RDS DB インスタンスが同じ VPC にない場合は、DB インスタンスがパブリックにアクセス可能であることを確認します。

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

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

ネットワーキングの問題

最も一般的なネットワーキング問題には、AWS DMS のレプリケーションのインスタンスによって使用される VPC のセキュリティグループが関係しています。デフォルトでは、このセキュリティグループではすべてのポートの 0.0.0.0/0 からの送信を許可するルールがあります。このセキュリティグループを変更するか、独自のセキュリティグループを使用する場合、少なくとも、対応するデータベースポートでソースおよびターゲットエンドポイントへの送信が許可される必要があります。

設定に関連した他の問題を次に示します。

  • レプリケーションのインスタンスと、ソースとターゲット両方のエンドポイントが同じ VPC 内にある—エンドポイントが使用するセキュリティグループはレプリケーションのインスタンスからのデータベースポートへの着信を許可する必要があります。レプリケーションインスタンスによって使用されるセキュリティグループでエンドポイントへの受信が許可されることを確認してください。または、エンドポイントにより使用されるセキュリティグループに、レプリケーションインスタンスのプライベート IP アドレスにアクセスを許可するセキュリティルールを作成できます。

  • ソースエンドポイントがレプリケーションのインスタンス (インターネットゲートウェイを使用) が使用する VPC の外部にある— VPC セキュリティグループは VPC 宛てでないトラフィックをインターネットゲートウェイに送信するルーティングルールを含む必要があります。この設定では、エンドポイントへ接続が、レプリケーションインスタンス上のパブリック IP アドレスから行われているように見えます。

  • ソースエンドポイントがレプリケーションのインスタンス (NAT のゲートウェイを使用) が使用する VPC の外部にある— NAT 識別子 (nat-#####) を受け取る 1 つの Elastic Network Interface にバインドされた 1 つの Elastic IP アドレスを使用する、ネットワークアドレス変換 (NAT) ゲートウェイを設定できます。インターネットゲートウェイではなくその NAT ゲートウェイへのデフォルトルートが VPC に含まれている場合、レプリケーションインスタンスはインターネットゲートウェイのパブリック IP アドレスを使用してデータベースエンドポイントに接続しているように見えます。この場合、VPC 外のデータベースエンドポイントへの進入は、レプリケーションインスタンスのパブリック IP アドレスではなく NAT アドレスからの進入を許可する必要があります。

フルロード後、CDC が停止する

複数の AWS DMS 設定が互いに競合すると、フルロード移行後に、レプリケーション変更が遅くなるか停止することがあります。たとえば、[Target table preparation mode] パラメータが [Do nothing] または [Truncate] に設定されている場合、AWS DMS はターゲットテーブルでプライマリキーや固有なキーの作成を含め、一切のセットアップを行わないように指示されています。ターゲットテーブルでプライマリキーまたは固有なキーを作成していない場合、AWS DMS は更新プログラムごとにテーブル全体をスキャンする必要があり、パフォーマンスに大きな影響を与えることがあります。

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

このエラーは、以前の移行タスクからのターゲットデータベースにデータが残っている場合に発生することがあります。[Target table preparation mode] パラメータが [Do nothing] に設定されている場合、AWS DMS は以前のタスクから挿入されたデータの削除を含め、ターゲットテーブルで一切の準備を行いません。タスクを再開し、これらのエラーを回避するために、タスクの以前の実行からターゲットテーブルに挿入される行を削除する必要があります。

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

スキーマの初回ロードが Operation:getSchemaListDetails:errType=, status=0, errMessage=, errDetails= のエラーが発生して失敗する場合、ソースエンドポイントに接続するのに AWS DMS が使用するユーザーアカウントには必要なアクセス許可がありません。

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

これらのタイプのエラーの原因はさまざまですが、AWS DMS のレプリケーションのインスタンスに割り当てられたリソースが不十分なことに関連した問題である場合がよくあります。レプリケーションのインスタンスの CPU、メモリ、スワップ、および IOPS の使用率をチェックし、インスタンスのリソースが移行を実行するために十分であることを確認します。モニタリングの詳細については、「データ移行サービスメトリクス」を参照してください。

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

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

タスクあたりのテーブル数

レプリケーションのタスクあたりのテーブル数に制限は設定されていませんが、通常、1 つのタスクのテーブル数を 60,000 個未満に制限すると良いようです。1 つのタスクが 60,000 個超のテーブルを使用すると、多くの場合リソース使用がボトルネックになることがあります。

Oracle 固有の問題のトラブルシューティング

以下は、AWS DMS を Oracle データベースで使用する際に固有の問題です。

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

ビューからデータを抽出可能にするため、Oracle ソース エンドポイントの の [Extra connection attributes] セクションの [Advanced] に次のコードを追加する必要があります。

Copy
exposeViews=true

Oracle 12c から LOB を移行する

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

Oracle LogMiner と BinaryReader の切り替え

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

BinaryReader を使用して変更をキャプチャするには

  1. AWS マネジメントコンソールにサインインし、DMS を選択します。

  2. [Endpoints] を選択します。

  3. BinaryReader を使用したい Oracle ソースエンドポイントを選択します。

  4. [Modify] を選択します。

  5. [Advanced] を選択し、次のコードを [Extra connection attributes] テキストボックスに追加します。

    Copy
    useLogminerReader=N
  6. SQL-Plus のような Oracle 開発者用ツールを使って、Oracle エンドポイントに接続するのに使用される AWS DMS ユーザーアカウントに追加の権限を与えます。

    Copy
    SELECT ON V_$TRANSPORTABLE_PLATFORM

エラー: Oracle CDC は停止しました。122301 Oracle CDC の最大再試行カウンタを超えました。

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

Copy
Exec rdsadmin.rdsadmin_util.set_configuration(‘archivelog retention hours’,24);

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

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

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

  1. AWS マネジメントコンソールにサインインし、[DMS] を選択します。

  2. [Endpoints] を選択します。

  3. サプリメンタルロギングを追加する Oracle ソースエンドポイントを選択します。

  4. [Modify] を選択します。

  5. [Advanced] を選択し、次のコードを [Extra connection attributes] テキストボックスに追加します。

    Copy
    addSupplementalLogging=Y
  6. [Modify] を選択します。

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

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

  • テーブルにプライマリキーを追加します。この手順は、ID 列を追加し、トリガーを使用してシーケンスを入力するだけです。

  • プライマリキーとしてシステム生成 ID を含むテーブルのマテリアライズドビューを作成し、テーブルではなくマテリアライズドビューを移行します。

  • ロジカルスタンバイを作成し、テーブルにプライマリキーを追加して、ロジカルスタンバイから移行します。

エラー: ORA-12899: 列 <column-name> の値が大きすぎる

エラー「ORA-12899: 列 <column-name> の値が大きすぎます」は、ソースとターゲットのデータベースで使用される文字セットの不一致、または NLS の設定が 2 つのデータベース間で異なることが原因で生じることがよくあります。このエラーの一般的な原因は、ソースデータベースの NLS_LENGTH_SEMANTICS パラメータが CHAR に設定されており、ターゲットデータベースの NLS_LENGTH_SEMANTICS パラメータが BYTE に設定されていることです。

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

Oracle NUMBER データ型は、NUMBER の精度とスケールに応じてさまざまな AWS DMS のデータ型に変換されます。このような変換は「AWS Database Migration Service のソースとしての Oracle データベースの使用」に記載されています。NUMBER 型が変換される方法は、Oracle のソースエンドポイントの追加の接続属性の使用に影響を受ける可能性があります。このような追加の接続属性は「AWS Database Migration Service での追加の接続属性の使用」に記載されています。

MySQL 固有の問題のトラブルシューティング

以下は、AWS DMS を MySQL データベースで使用する際に固有の問題です。

バイナリログ作成が無効化されるため、Amazon RDS DB インスタンスのエンドポイントの CDC タスクが失敗する

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

ターゲット MySQL のインスタンスへの接続は、タスクの実行中に接続が切断されます

タスクログに次のようなエラーが表示されて、MySQL ターゲットからの接続が切断されている LOB のタスクがあるとき、タスクの設定調整が必要となる場合があります。

Copy
[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.

Copy
[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.

タスクが MySQL ターゲットから切断される問題を解決するには、以下を実行します。

  • 最大の LOB を保持するために、十分に大きい値に設定された データベース変数 max_allowed_packetがあることを確認します。

  • 次の変数が大きいタイムアウト値に設定されていることを確認します。これらの変数ごとに、少なくとも 5 分の値を使用することをお勧めします。

    • net_read_timeout

    • net_write_timeout

    • wait_timeout

    • interactive_timeout

MySQL 互換エンドポイントへの自動コミットを追加する

MySQL 互換ターゲットエンドポイントに自動コミットを追加するには

  1. AWS マネジメントコンソールにサインインし、[DMS] を選択します。

  2. [Endpoints] を選択します。

  3. 自動コミットを追加したい MySQL 互換ターゲットエンドポイントを選択します。

  4. [Modify] を選択します。

  5. [Advanced] を選択し、次のコードを [Extra connection attributes] テキストボックスに追加します。

    Copy
    Initstmt= SET AUTOCOMMIT=1
  6. [Modify] を選択します。

MySQL 互換ターゲットエンドポイントで外部キーを無効化する

MySQL、Aurora または MariaDB ターゲットエンドポイントの [Extra Connection Attributes] セクションの [Advanced] に以下を追加して、MySQL の外部キーのチェックを無効化できます。

MySQL 互換ターゲットエンドポイントで外部キーを無効化するには

  1. AWS マネジメントコンソールにサインインし、[DMS] を選択します。

  2. [Endpoints] を選択します。

  3. 外部キーを無効にしたい Oracle のターゲットエンドポイントを選択します。

  4. [Modify] を選択します。

  5. [Advanced] を選択し、次のコードを [Extra connection attributes] テキストボックスに追加します。

    Copy
    Initstmt=SET FOREIGN_KEY_CHECKS=0
  6. Modify を選択します。

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

この問題を引き起こす可能性がある最も一般的な状況は、AWS DMS がサポートしない文字セットでソースエンドポイントの文字がエンコードされている場合です。たとえば、AWS DMS は UTF8MB4 文字セットをサポートしていません。

[Bad event] ログのエントリ

移行ログの [Bad event] のエントリは通常、ソースデータベースエンドポイントで、サポートされていない DDL オペレーションが試行されたことを指します。サポートされていない DDL オペレーションは、レプリケーションインスタンスが省略できないイベントを発生させ、bad event が記録されます。この問題を修正するには、タスクを最初から再開します。テーブルがリロードされ、サポートされていない DDL オペレーションの発行後の時点で変更のキャプチャが開始されます。

MySQL 5.5 の変更データキャプチャ

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

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

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

Copy
Call mysql.rds_set_configuration(‘binlog retention hours’, 24);

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

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

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

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

Copy
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 がターゲットデータベースにテーブルとプライマリキーを作成するように設定されている場合、現在プライマリキーはソースデータベースで使用されたのと同じ名前を使用していません。代わりに、AWS DMS はテーブル名に基づいてプライマリキー名を作成します。テーブル名が長いと、作成された自動的に生成される識別子が、MySQL に許可されている制限よりも長くなる場合があります。現在、この問題を解決するには、ターゲットデータベースのテーブルとプライマリキーを事前作成し、タスク設定 [Target table preparation mode] が [Do nothing] または [Truncate] に設定されているタスクを使用してターゲットテーブルを入力します。

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

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

Copy
“[SOURCE_CAPTURE ]E: Column ‘<column name>' uses an unsupported character set [120112] A field data conversion failed. (mysql_endpoint_capture.c:2154)

テーブルまたはデータベースが UTF8MB4 エンコーディングを使用している場合、このエラーがよく発生します。AWS DMS では UTF8MB4 文字セットはサポートされていません。さらに、接続に関係したデータベースのパラメータを確認します。次のコマンドを使用してこれらのパラメータを確認できます。

Copy
SHOW VARIABLES LIKE '%char%';

PostgreSQL 固有の問題のトラブルシューティング

以下は、AWS DMS を PostgreSQL データベースで使用する際に固有の問題です。

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

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

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

エラー「SQL_ERROR SqlState: 3F000 NativeError: 7 Message: エラー: 作成用のスキーマが選択されていません」は、JSON テーブルのマッピングがスキーマに対してワイルドカード値を含み、ソースデータベースがその値をサポートしていない時に発生することがあります。

CDC を使用時、テーブルへの削除や更新がレプリケートされない

変更データキプチャ (CDC) 中の削除や更新オペレーションは、ソーステーブルにプライマリキーがない場合無視されます。AWS DMS では、プライマリキーを持つ PostgreSQL テーブルの変更データキャプチャ (CDC) がサポートされています。テーブルにプライマリキーがない場合、WAL ログにはデータベース行の前イメージが含まれていないため、AWS DMS がテーブルを更新できません。削除オペレーションをレプリケートする場合は、ソーステーブルにプライマリキーを作成します。

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

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

PostgreSQL の DDL キャプチャを防止する

次の [Extra Connection Attribute] ステートメントを追加して、PostgreSQL ターゲットエンドポイントが DDL ステートメントをキャプチャするのを防止できます。[Extra Connection Attribute] パラメータは、ソースエンドポイントの [Advanced] タブで使用できます。

Copy
captureDDLs=N

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

DDL キャプチャに関連したデータベースオブジェクトをどのスキーマで作成するかを制御できます。次の [Extra Connection Attribute] ステートメントを追加します。[Extra Connection Attribute] パラメータは、ターゲットエンドポイントの [Advanced] タブで使用できます。

Copy
ddlArtifactsSchema=xyzddlschema

PostgreSQL に移行した後 Oracle テーブルが存在しない

Oracle のデフォルトは大文字のテーブル名ですが、PostgreSQL のデフォルトは小文字のテーブル名です。通常、Oracle から PostgreSQL への移行を実行する場合、タスクのテーブルマッピングセクションで変換ルールを追加してテーブル名を変換する必要があります。

テーブルとデータは引き続きアクセス可能です。テーブル名のケースを変換する変換ルールを使わずにテーブルを移行した場合、それらを参照するときにはテーブル名を引用符で囲む必要があります。

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

AWS DMS では、PostgreSQL ソースエンドポイントとしてのビューはサポートされていません。

Microsoft SQL Server 固有の問題のトラブルシューティング

以下は、Microsoft SQL Server データベースで AWS DMS を使用する際に固有の問題です。

AWS DMS ユーザーアカウントの CDC 使用を特別に許可する

AWS DMS が使用するユーザーアカウントでは、変更データキャプチャ (CDC) を使用する場合に正しく動作するために、SQL Server の SysAdmin の役割が必要です。SQL Server の CDC はオンプレミスのデータベースまたは EC2 インスタンスのデータベースでのみ利用可能です。

SQL Server 変更データキャプチャ (CDC) および Amazon RDS

AWS DMS では現在、Amazon RDS SQL Server DB インスタンスからの変更データキャプチャ (CDC) をサポートしていません。SQL Server の CDC はオンプレミスのデータベースまたは Amazon EC2 インスタンスのデータベースでのみ利用可能です。

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

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

Copy
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)

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

IDENTITY 列が存在しない

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

エラー: SQL Server は公開をサポートしていません

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

Copy
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 Server データベースが「FULL」または「BULK LOGGED」データ復旧モデルのいずれかであることが必要です。「SIMPLE」モデルはサポートされていません。

SIMPLE 復旧モデルは、ユーザーがデータベースを復旧するのに必要な最低限の情報を記録します。すべての非アクティブのログエントリは、チェックポイントが発生すると自動的に切り捨てられます。すべてのオペレーションが記録されていますが、チェックポイントが発生するとすぐにログが自動的に切り捨てられます。つまり、再び利用可能となり、古いログエントリは上書きできるようになります。ログエントリが上書きされると、変更内容はキャプチャできません。そのため AWS DMS では、SIMPLE データ復旧モデルをサポートしていません。SQL Server をソースとして使用するためのその他の前提条件については、「Microsoft SQL Server データベースの AWS Database Migration Service のソースとしての使用」を参照してください。

Amazon Redshift 固有の問題のトラブルシューティング

以下は、AWS DMS を Amazon Redshift データベースで使用する際に固有の問題です。

AWS DMS レプリケーションのインスタンスとは異なるリージョンの Amazon Redshift クラスターにロードする

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

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

エラー "リレーション「awsdms_apply_exceptions」がすでに存在します" は、Redshift エンドポイントが PostgreSQL エンドポイントとして指定されている場合に頻繁に発生します。この問題を解決するには、エンドポイントを変更し、[Target engine] を「redshift」に変更します。

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

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

dms.awsdms_changes000000000XXXX のような名前のクラスターのテーブルを参照する

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

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

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

  • CRUD (SELECT、INSERT、UPDATE、DELETE)

  • BULK Load

  • CREATE、ALTER、DROP (タスクの定義によって必要な場合)

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

Amazon Aurora 特有の問題のトラブルシューティング

以下は、AWS DMS で Amazon Aurora データベースを使用している際に発生する特有の問題です。

エラー: CHARACTER SET UTF8 フィールドが「,」で切り取られています。行が「\n」で切り取られています

ターゲットとして Amazon Aurora を使用しているときに、ログに以下のようなエラーが表示された場合、通常、このエラーは SQL_MODE パラメータの一部に ANSI_QUOTES があることを示しています。SQL_MODE パラメータの一部として ANSI_QUOTES がある場合、二重引用符が引用符として処理され、タスクの実行時に問題が起きることがあります。このエラーを修正するには、SQL_MODE パラメータから ANSI_QUOTES を削除します。

Copy
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)