翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AWS Database Migration Service での移行タスクのトラブルシューティング
以下では、AWS Database Migration Service (AWS DMS) での問題のトラブルシューティングに関するトピックを見つけることができます。これらのトピックは、AWS DMS とを選択したエンドポイント データベースの両方を使用して一般的な問題を解決するのに役立ちます。
AWS サポートケースがあれば、サポートエンジニアが、エンドポイント データベース構成の 1 つに関する潜在的な問題を特定できることもあります。エンジニアが、データベースに関する診断情報を返すためのサポート スクリプトを実行するように頼む場合もあります。タスク設定ファイルを使用してタスク設定を設定する方法については、「AWS DMS での診断サポート スクリプトの操作」をご参照ください。
トラブルシューティング目的の場合、AWS DMS はレプリケーションインスタンスのトレースファイルとダンプファイルを収集します。トラブルシューティングが必要な問題が発生した場合は、これらのファイルを AWS サポートに提供できます。デフォルトでは、DMS では、30 日を経過したトレースファイルとダンプファイルは消去されます。トレースファイルおよびダンプファイルコレクションをオプトアウトするには、AWS サポートでケースを開きます。
トピック
- 移行タスクの実行が遅い
- タスクのステータスバーが動かない
- タスクは完了しましたが、何も移行されませんでした
- 外部キーとセカンダリ インデックスが見つからない
- AWS DMS が CloudWatch ログを作成しない
- Amazon RDS への接続で問題が発生する
- ネットワーキングに関する問題の発生
- 全ロード後、CDC が停止する
- タスク再開時のプライマリ キー制約違反エラー
- スキーマの初回ロードが失敗する
- 不明なエラーが発生してタスクが失敗する
- タスクを再開するとテーブルが最初からロードされる
- タスクあたりのテーブル数が問題の原因の問題
- LOB 列でプライマリ キーが作成されたときにタスクが失敗する
- プライマリ キーのないターゲットテーブル上の重複レコード
- 予約済み IP 範囲の送信元エンドポイント
- Amazon Athena クエリでタイムスタンプが文字化けする
- Oracle に関する問題のトラブルシューティング
- MySQL に関する問題のトラブルシューティング
- PostgreSQL に関する問題のトラブルシューティング
- Microsoft SQL Server 問題のトラブルシューティング
- Amazon Redshift に関する問題のトラブルシューティング
- Amazon Aurora MySQL に関する問題のトラブルシューティング
- SAP ASE に関する問題のトラブルシューティング
- IBM Db2 に関する問題のトラブルシューティング
- AWS Database Migration Service のレイテンシーに関する問題のトラブルシューティング
- AWS DMS での診断サポート スクリプトの操作
- AWS DMS 診断サポート AMI の使用
移行タスクの実行が遅い
移行タスクの実行が遅くなる、または後続のタスクの実行が初期タスクより遅くなる原因として、いくつかの問題が考えられます。
移行タスクの実行が遅くなる最も一般的な原因は、AWS DMS のレプリケーション インスタンスに割り当てられているリソースが不十分であることです。レプリケーション インスタンスの CPU およびメモリ、スワップファイル、 IOPS の使用率をチェックし、インスタンスのリソースが実行中のタスクのために十分であることを確認します。例えば、エンドポイントとしての Amazon Redshift の複数のタスクは I/O 集約型です。レプリケーションのインスタンスに対して IOPS を増やすか、より効率的に移行するためにレプリケーションの複数のインスタンス間で作業を分割できます。
レプリケーションのインスタンスサイズの決定に関する詳細については、「レプリケーションインスタンス向けの最適なサイズの選択」をご参照ください。
以下を実行すると、初期の移行のロードがスピードアップします。
-
ターゲットが Amazon RDS DB インスタンスの場合、Multi-AZ がターゲット DB インスタンスに対して有効でないことを確認します。
-
ロード中の自動バックアップまたはターゲットデータベースでのログ作成をオフにし、移行が完了したらこれらの機能をオンに戻します。
-
プロビジョンド IOPS がターゲットで利用可能な場合は、この機能を使用します。
-
移行データに LOB が含まれる場合は、タスクが LOB 移行のために最適化されていることを確認します。LOB 用の最適化の詳細については、「ターゲットメタデータのタスク設定」をご参照ください。
タスクのステータスバーが動かない
タスクのステータスバーで、タスクの進捗状況を予測できます。この予測の正確さはソースデータベースのテーブル統計の正確さによって異なります。テーブル統計が正確であればあるほど、正確に予測できます。
予測された行の統計がないテーブルが 1 つだけのタスクでは、AWS DMS はどのような種類であっても完了率の予測を提供できません。この場合、タスクのステータスと、ロードされた行の表示を使って、タスクが実際に実行されて進行していることを確認できます。
タスクは完了しましたが、何も移行されませんでした
タスクの完了後に何も移行されなかった場合は、次の操作を実行します。
-
エンドポイントを作成したユーザーが、移行するテーブルへの読み取りアクセス権を持っているかどうかを確認します。
-
移行するオブジェクトがテーブルであるかどうかを確認します。ビューの場合は、テーブルマッピングを更新し、オブジェクトロケータを[view](ビュー) または[all](すべて) として指定します。詳細については、「 コンソールからテーブル選択および変換を指定する」を参照してください。
外部キーとセカンダリ インデックスが見つからない
AWS DMS によって、テーブル、プライマリ キー、場合によっては一意のインデックスが作成されますが、ソースからデータを効率的に移行するために必要ではない他のオブジェクトは作成されません。たとえば、セカンダリインデックス、非プライマリキーの制約、データデフォルトは作成されません。
データベースからセカンダリオブジェクトを移行するには、ソースデータベースと同じデータベースエンジンに移行中の場合、データベースのネイティブツールを使用します。ソースデータベースで使用したものと異なるデータベースエンジンへ移行中の場合、AWS Schema Conversion Tool (AWS SCT) を使用してセカンダリオブジェクトを移行します。
AWS DMS が CloudWatch ログを作成しない
レプリケーションタスクで CloudWatch ログが作成されない場合は、アカウントに dms-cloudwatch-logs-role
ロールがあることを確認します。このロールが存在しない場合は、次を実行して作成します。
AWS Management Console にサインインして、IAM コンソール (https://console.aws.amazon.com/iam/
) を開きます。 [ロール] タブをクリックします。[ロールの作成] を選択します。
[信頼されたエンティティを選択] セクションで、[AWS のサービス] を選択します。
[ユースケースの選択] セクションで、[DMS] を選択します。
[Next: Permissions] (次へ: アクセス許可) を選択します。
検索フィールドに
AmazonDMSCloudWatchLogsRole
と入力して、[AmazonDMSCloudWatchLogsRole] の隣にあるボックスをオンにします。これにより、CloudWatch にアクセスするための AWS DMS アクセス許可が付与されます。[Next: Tags] (次へ: タグ) を選択します。
[次へ: レビュー] を選択します。
[ロール名] に
dms-cloudwatch-logs-role
と入力します。この名前では大文字と小文字が区別されます。[ロールの作成] を選択します。
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 からの送信を許可するルールがあります。多くの場合、このセキュリティグループを変更するか、独自のセキュリティグループを使用します。その場合は、少なくとも、それぞれのデータベースポート上のソース エンドポイントとターゲット エンドポイントに出力を与えるようにしてください。
その他の設定関連の問題には、次のようなものがあります:
[Replication instance and both source and target endpoints in the same VPC] (レプリケーション インスタンスと、ソースとターゲット両方のエンドポイントが同じ VPC 内にある) - エンドポイントが使用するセキュリティグループはレプリケーション インスタンスからのデータベースポートへの受信を許可する必要があります。レプリケーション インスタンスによって使用されるセキュリティグループにエンドポイントへの入力があることを確認します。または、レプリケーション インスタンスのプライベート IP アドレスへのアクセスを許可するエンドポイントによって使用されるセキュリティグループにルールを作成できます。
[Source endpoint is outside the VPC used by the replication instance (using an internet gateway)] (ソースエンドポイントがレプリケーション インスタンス (インターネットゲートウェイを使用) が使用する VPC の外部にある) - VPC セキュリティグループは VPC 宛てでないトラフィックをインターネットゲートウェイに送信するルーティングルールを含む必要があります。この設定では、エンドポイントへの接続がレプリケーション インスタンス上のパブリック IP アドレスから行われているように見えます。
[Source endpoint is outside the VPC used by the replication instance (using a NAT gateway)] (ソースエンドポイントがレプリケーションインスタンスで使用されている VPC の外にあり、NAT のゲートウェイを使用している) - 単一の Elastic network interface にバインドされた単一の Elastic IP アドレスを使用してネットワークアドレス変換 (NAT) ゲートウェイを設定します。この NAT ゲートウェイは NAT 識別子 (nat-#####) を受け取ります。
場合によっては、インターネットゲートウェイではなく、その NAT ゲートウェイへのデフォルトルートが VPC に含まれていることがあります。このような場合、レプリケーション インスタンスは NAT ゲートウェイのパブリック 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 Database Migration Service メトリクス」をご参照ください。
タスクを再開するとテーブルが最初からロードされる
AWS DMS は、テーブルの初回ロードを完了しなかった場合、テーブルのロードを最初から再開します。タスクが再起動されると、AWS DMSは、最初のロードが完了しなかったときに、テーブルを最初からリロードします。
タスクあたりのテーブル数が問題の原因の問題
レプリケーション タスクあたりのテーブル数に制限はありません。ただし、経験則として、タスク内のテーブルの数を 60,000 個未満に制限することをお勧めします。1 つのタスクが 60,000 個超のテーブルを使用すると、多くの場合リソース使用がボトルネックになることがあります。
LOB 列でプライマリ キーが作成されたときにタスクが失敗する
FULL LOB モードまたは LIMITED LOB モードでは、AWS DMS は LOB データ型のプライマリ キーのレプリケーションをサポートしません。
DMS は、最初に LOB 列が NULL である行を移行し、後で LOB 列を更新します。したがって、LOB 列にプライマリキーが作成されると、プライマリキーを NULL にできないため、最初の挿入は失敗します。回避方法として、別の列をプライマリ キーとして追加し、LOB 列からプライマリ キーを削除します。
プライマリ キーのないターゲットテーブル上の重複レコード
全ロードと CDC タスクを実行すると、プライマリ キーまたは一意のインデックスがないターゲットテーブルに重複レコードを作成できます。全ロードと CDC タスク中にターゲットテーブルでレコードが重複しないようにするには、ターゲットテーブルにプライマリ キーまたは一意のインデックスがあることを確認してください。
予約済み IP 範囲の送信元エンドポイント
AWS DMS ソースデータベースが 192.168.0.0/24 の予約済み IP 範囲内の IP アドレスを使用している場合、ソースエ ンドポイント接続テストは失敗します。次のステップは、考えられる回避方法を提供します:
-
192.168.0.0/24 のソースデータベースと通信できる予約済み範囲外の Amazon EC2 インスタンスを見つけます。
socat プロキシをインストールして実行します。例を以下に示します。
yum install socat socat -d -d -lmlocal2 tcp4-listen:database port,bind=0.0.0.0,reuseaddr,fork tcp4:source_database_ip_address:database_port &
AWS DMS エンドポイントには、Amazon EC2インスタンスの IP アドレスと上記のデータベースポートを使用します。AWS DMS のデータベースポートへのアクセスを許可するセキュリティグループがエンドポイントにあることを確認します。DMSタスクの実行中はプロキシが実行されている必要があることに注意します。ユースケースによっては、プロキシのセットアップを自動化する必要がある場合があります。
Amazon Athena クエリでタイムスタンプが文字化けする
Athena クエリでタイムスタンプが文字化けする場合は、AWS Management Console または[ModifyEndpoint] (エンドポイント変更) アクションでAmazon S3 エンドポイントの parquetTimestampInMillisecond
の値を true
に設定します。詳細については、[S3Settings] (S3設定)をご参照ください。
Oracle に関する問題のトラブルシューティング
以下では、AWS DMS を Oracle データベースと使用する際に固有の問題のトラブルシューティングについて学習できます。
トピック
- ビューからデータを取得する
- Oracle 12c から LOB を移行する
- Oracle LogMiner と Binary Reader の切り替え
- エラー: Oracle CDC は停止しました。122301 Oracle CDC の最大再試行カウンターを超えました。
- Oracle ソース エンドポイントにサプリメンタル ログを自動的に追加する
- LOB の変更がキャプチャされない
- エラー: ORA-12899: 列 column-name の値が大きすぎる
- NUMBER のデータ型が誤って解釈される
- 全ロード中にレコードが欠落している
- テーブルエラー
- エラー:Oracle アーカイブされた REDO ログの宛先 ID を取得できません
- Oracle REDO ログまたはアーカイブログの読み取りパフォーマンスの評価
ビューからデータを取得する
ビューからデータを 1 回プルできます。これを継続的レプリケーションに使用することはできません。ビューからデータを抽出できるようにするには、Oracle ソースエンドポイントページの [エンドポイント設定] セクションに次のコードを追加する必要があります。ビューからデータを抽出すると、そのビューはターゲットスキーマのテーブルとして表示されます。
"ExposeViews": true
Oracle 12c から LOB を移行する
Oracle データベースへの変更をキャプチャするために AWS DMS が使用できる方法は、Binary Reader と Oracle LogMiner の 2 つです。デフォルトでは AWS DMS は Oracle LogMiner を使用して変更をキャプチャします。ただし、Oracle 12c で、Oracle LogMiner は LOB 列をサポートしていません。Oracle 12c での LOB 列の変更をキャプチャするには、Binary Reader を使用します。
Oracle LogMiner と Binary Reader の切り替え
ソース Oracle データベースへの変更をキャプチャするために AWS DMS が使用できる方法は、Binary Reader と Oracle LogMiner の 2 つです。Oracle LogMiner がデフォルトです。Binary Reader を使用して変更をキャプチャするように切り替えるには、次を実行します。
Binary Reader を使用して変更をキャプチャするには
-
AWS Management Console にサインインし、AWS DMS コンソール (https://console.aws.amazon.com/dms/v2/
) を開きます。 [Endpoints] (エンドポイント) を選択します。
Binary Reader を使用したい Oracle ソース エンドポイントを選択します。
Modify を選択します。
[Advanced] (詳細) を選択し、[Extra connection attributes](追加の接続属性) テキストボックスに以下のコードを追加します。
useLogminerReader=N
SQL-Plus のような Oracle デベロッパーツールを使って、Oracle エンドポイントに接続するのに使用される AWS DMS ユーザーアカウントに追加の権限を与えます。
SELECT ON V_$TRANSPORTABLE_PLATFORM
エラー: Oracle CDC は停止しました。122301 Oracle CDC の最大再試行カウンターを超えました。
このエラーは、AWS DMS が変更をキャプチャするために使用できるようになる前に、必要な Oracle アーカイブログがサーバーから削除されると発生します。データベースサーバーのログリテンションポリシーを増やします。Amazon RDS データベースでは、ログの保持を延長するために、以下の手順を実行します。たとえば、以下のコードを使うと Amazon RDS DB インスタンスでのログの保持が 24 時間に延長されます。
exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24);
Oracle ソース エンドポイントにサプリメンタル ログを自動的に追加する
デフォルトでは、AWS DMS のサプリメンタルロギングはオフになっています。Oracle ソースエンドポイントのサプリメンタルロギングを自動的にオンにするには、以下の手順を実行します。
Oracle ソースエンドポイントにサプリメンタルロギングを追加するには
-
AWS Management Console にサインインし、AWS DMS コンソール (https://console.aws.amazon.com/dms/v2/
) を開きます。 [Endpoints] (エンドポイント) を選択します。
サプリメンタル ログを追加する Oracle ソース エンドポイントを選択します。
Modify を選択します。
[Advanced] (詳細) を選択し、[Extra connection attributes] (追加の接続属性) テキストボックスに以下のコードを追加します。
addSupplementalLogging=Y
Modify を選択します。
LOB の変更がキャプチャされない
現在、LOB の変更をキャプチャするには、テーブルに AWS DMS のプライマリキーがあることが必要です。LOB を含むテーブルにプライマリキーがない場合、LOB の変更をキャプチャするにはいくつかのアクションを行うことができます。
テーブルにプライマリキーを追加します。この手順は、ID 列を追加し、トリガーを使用してシーケンスを入力するだけです。
プライマリ キーとしてシステム生成 ID を含むテーブルのマテリアライズド ビューを作成し、テーブルではなくマテリアライズド ビューを移行します。
ロジカルスタンバイを作成し、テーブルにプライマリキーを追加して、ロジカルスタンバイから移行します。
エラー: ORA-12899: 列 column-name
の値が大きすぎる
エラー[ORA-12899: value too large for column column-name
] (ORA-12899: column-name 列の値が大きすぎる) は、多くの場合、いくつかの問題によって引き起こされます。
これらの問題の 1 つで、ソースデータベースとターゲットデータベースで使用される文字セットに不一致があります。
別の問題では、2 つのデータベース間で各国語サポート (NLS) の設定が異なります。このエラーの一般的な原因は、ソースデータベースの NLS_LENGTH_SEMANTICS パラメータが CHAR に設定されており、ターゲットデータベースの NLS_LENGTH_SEMANTICS パラメータが BYTE に設定されていることです。
NUMBER のデータ型が誤って解釈される
Oracle NUMBER データ型は、NUMBER の精度とスケールに応じてさまざまな AWS DMS データ型に変換されます。このような変換はOracle のソースデータ型に記載されています。ソースの Oracle エンドポイントのエンドポイント設定の使用も、NUMBER 型の変換方法に影響します。エンドポイントの設定は「のソースとして Oracle を使用する場合のエンドポイント設定 AWS DMS」に記載されています。
全ロード中にレコードが欠落している
全ロードを実行する場合、AWS DMS は、データベースレベルで開いているトランザクションを検索し、トランザクションがコミットされるのを待ちます。例えば、タスクの設定 TransactionConsistencyTimeout=600
に基づいて、AWS DMS は、オープントランザクションがテーブルマッピングに含まれていないテーブル上にある場合でも、10 分間待機します。ただし、オープントランザクションがテーブルマッピングに含まれるテーブルにあり、トランザクションが時間内にコミットされていない場合、ターゲットテーブルの結果からレコードが欠落します。
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 diagnostic Amazon マシンイメージ (AMI) を使用します。
AWS DMS diagnostic AMI を使用して、次のことを行うことができます。
-
bFile メソッドを使用して REDO ログファイルのパフォーマンスを評価します。
-
LogMiner メソッドを使用して REDO ログファイルのパフォーマンスを評価します。
-
PL/SQL (
dbms_lob.read
) メソッドを使用して REDO ログファイルのパフォーマンスを評価します。 -
シングルスレッドを使用して ASMFile の読み取りパフォーマンスを評価します。
-
マルチスレッドを使用して、ASMFile の読み取りパフォーマンスを評価します。
-
Direct OS Readfile() Windows または Pread64 Linux 関数を使用して、REDO ログファイルを評価します。
その後、結果に基づいて是正措置を講じることができます。
Oracle REDO ログファイルまたはアーカイブログファイルの読み取りパフォーマンスをテストするには
-
AWS DMS diagnostic AMI Amazon EC2 インスタンスを作成して、このインスタンスに接続します。
詳細については、「Working with the AWS DMS diagnostic AMI」を参照してください。
-
awsreplperf コマンドを実行します。
$ awsreplperf
このコマンドは AWS DMS Oracle 読み取りパフォーマンスユーティリティオプションを表示します。
0. Quit 1. Read using Bfile 2. Read using LogMiner 3. Read file PL/SQL (dms_lob.read) 4. Read ASMFile Single Thread 5. Read ASMFile Multi Thread 6. Readfile() function
-
リストからオプションを選択します。
-
次のデータベース接続とアーカイブログ情報を入力します。
Oracle user name [system]: Oracle password: Oracle connection name [orcllx]: Connection format
hostname
:port
/instance
Oracle event trace? [N]: Default N = No or Y = Yes Path to redo or archive log file []: -
表示される出力を調べて、関連する読み取りパフォーマンス情報を探します。例えば、次の例は、オプション番号 2 [Read using LogMiner] を選択した結果得られる出力を示しています。
-
ユーティリティを終了するには、[0] (ゼロ) を入力します。
次のステップ
-
読み取り速度が許容可能なしきい値を下回っていることが結果で示されたら、エンドポイントで「Oracle diagnostic support script」を実行し、「待機時間」、「ロードプロファイル」、「IO プロファイル」セクションを確認します。次に、読み取りパフォーマンスの改善に向けて、正常でない設定を調整します。例えば、REDO ログファイルが最大 2 GB の場合は、パフォーマンスを向上させるために LOG_BUFFER を 200 MB に増やしてみます。
-
「AWS DMS のベストプラクティス」を確認して、DMS レプリケーションインスタンス、タスク、エンドポイントが最適に設定されていることを確認します。
MySQL に関する問題のトラブルシューティング
以下では、AWS DMS を MySQL データベースと使用する際に固有の問題のトラブルシューティングについて学習できます。
トピック
- バイナリログ作成が無効化されるため、Amazon RDS DB インスタンスのエンドポイントの CDC タスクが失敗する
- ターゲット MySQL のインスタンスへの接続は、タスクの実行中に接続が切断されます
- MySQL 互換エンドポイントへの自動コミットを追加する
- MySQL 互換ターゲットエンドポイントで外部キーを無効化する
- 文字が疑問符に置き換えられる
- [Bad event](不良イベント) ログのエントリ
- MySQL 5.5 の変更データキャプチャ
- Amazon RDS DB インスタンスのバイナリログ保持を延長する
- ログメッセージ: ソースデータベースからの一部の変更は、ターゲットデータベースに適用されても効果がありません。
- エラー: 識別子が長すぎます
- エラー: サポートされていない文字セットによりフィールドデータ変換が失敗しました
- Error: Codepage 1252 to UTF8 [120112] A field data conversion failed
- インデックス、外部キー、カスケード更新、または削除が移行されない
バイナリログ作成が無効化されるため、Amazon RDS DB インスタンスのエンドポイントの CDC タスクが失敗する
自動バックアップが無効化されているためにこの問題が Amazon RDS DB インスタンスに発生します。バックアップ保持期間を 0 以外の値に設定することで自動バックアップを有効にすることができます。
ターゲット MySQL のインスタンスへの接続は、タスクの実行中に接続が切断されます
MySQL ターゲットからの接続が切断されている LOB のタスクがあるとき、タスクログに以下のようなエラーが表示されます。
[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.
この場合、一部のタスク設定の調整が必要になる場合があります。
タスクが MySQL ターゲットから切断される問題を解決するには、以下を実行します。
最大の LOB を保持するために、十分に大きい値に設定された データベース変数
max_allowed_packet
があることを確認します。以下の変数が大きいタイムアウト値に設定されていることを確認します。これらの変数ごとに、少なくとも 5 分の値を使用することをお勧めします。
net_read_timeout
net_write_timeout
wait_timeout
MySQL システム変数の設定については、MySQL ドキュメント
MySQL 互換エンドポイントへの自動コミットを追加する
MySQL 互換ターゲットエンドポイントに自動コミットを追加するには
-
AWS Management Console にサインインし、AWS DMS コンソール (https://console.aws.amazon.com/dms/v2/
) を開きます。 [Endpoints] (エンドポイント) を選択します。
自動コミットを追加したい MySQL 互換ターゲット エンドポイントを選択します。
Modify を選択します。
[Advanced] (詳細) を選択し、[Extra connection attributes] (追加の接続属性) テキストボックスに以下のコードを追加します。
Initstmt= SET AUTOCOMMIT=1
Modify を選択します。
MySQL 互換ターゲットエンドポイントで外部キーを無効化する
MySQL または Amazon Aurora MySQL 互換エディション、 MariaDB エンドポイントの [Advanced] (詳細) セクションの [Extra Connection Attributes] (追加接続属性) に以下を追加して、MySQL の外部キー チェックを無効化できます。
MySQL 互換ターゲットエンドポイントで外部キーを無効化するには
-
AWS Management Console にサインインし、AWS DMS コンソール (https://console.aws.amazon.com/dms/v2/
) を開きます。 [Endpoints] (エンドポイント) を選択します。
外部キーを無効にしたい MySQL または Aurora MySQL、 MariaDB のターゲット エンドポイントを選択します。
Modify を選択します。
[Advanced] (詳細) を選択し、[Extra connection attributes] (追加の接続属性) テキストボックスに以下のコードを追加します。
Initstmt=SET FOREIGN_KEY_CHECKS=0
Modify を選択します。
文字が疑問符に置き換えられる
この問題を引き起こす可能性がある最も一般的な状況は、AWS DMS がサポートしない文字セットでソースエンドポイントの文字がエンコードされている場合です。
[Bad event](不良イベント) ログのエントリ
移行ログの [Bad event](不良イベント) のエントリは通常、ソース データベース エンドポイントで、サポートされていないデータ定義言語(DDL) オペレーションが試行されたことを指します。サポートされていない DDL オペレーションは、レプリケーション インスタンスが省略できないイベントを発生させ、不良イベントが記録されます。
この問題を解決するには、タスクを最初から再起動します。これにより、テーブルがリロードされ、サポートされていない 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 時間に延長します。
call mysql.rds_set_configuration('binlog retention hours', 24);
ログメッセージ: ソースデータベースからの一部の変更は、ターゲットデータベースに適用されても効果がありません。
AWS DMS が MySQL データベースの列の値を既存の値に更新すると、MySQL は zero rows affected
のメッセージを返します。この動作は、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 はテーブル名に基づいてプライマリ キー名を作成します。テーブル名が長いと、自動作成された識別子が、MySQL に許可されている制限よりも長くなる場合があります。
この問題の当面解決策として、まずターゲットデータベースでテーブルとプライマリキーを事前に作成します。次に、タスク設定[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%';
Error: Codepage 1252 to UTF8 [120112] A field data conversion failed
以下のエラーは、ソース MySQL データベースにコードページ 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)
回避策として、ソースの MySQL エンドポイントで追加の接続属性 (CharsetMapping
) を使用して、文字セットのマッピングを指定します。このエンドポイント設定を追加する場合は、AWS DMS 移行タスクを最初からやり直す必要がある場合があります。
例えば、次のエンドポイント設定は、ソース文字セットが Utf8
または latin1
である MySQL ソースエンドポイントに使用できます。ここで 65001 は UTF8 コードページ識別子です。
CharsetMapping=utf8,65001 CharsetMapping=latin1,65001
インデックス、外部キー、カスケード更新、または削除が移行されない
AWS DMS は、インデックスや外部キーなどのセカンダリオブジェクトの移行をサポートしていません。カスケード更新または削除オペレーションから子テーブルに加えられた変更をレプリケートするには、ターゲットテーブルでトリガーを実行する外部キー制約をアクティブにする必要があります。この制限を回避するには、ターゲットテーブルに外部キーを手動で作成します。次に、以下の説明のとおり、フルロードと CDC 向けに単一のタスクを作成するか、フルロードと CDC 向けに 2 つの別々のタスクを作成します。
フルロードと CDC をサポートする単一タスクを作成する
この手順では、フルロードと CDC 向けの単一タスクを使用して外部キーとインデックスを移行する方法について説明します。
フルロードと CDC タスクを作成します。
ソーステーブルと一致するように、ターゲットで外部キーとインデックスを含むテーブルを手動で作成します。
次の ECA を AWS DMS ターゲットエンドポイントに追加します。
Initstmt=SET FOREIGN_KEY_CHECKS=0;
TargetTablePrepMode
をDO_NOTHING
に設定して AWS DMS タスクを作成します。Stop task after full load completes
設定を「StopTaskCachedChangesApplied
」に設定します。タスクを開始します。AWS DMS はフルロードが完了したらタスクを自動的に停止し、キャッシュされた変更を適用します。
以前追加した
SET FOREIGN_KEY_CHECKS
ECA を削除します。タスクを再開します。タスクは CDC フェーズに入り、ソースデータベースからの継続的な変更がターゲットに適用されます。
フルロードタスクと CDC タスクを個別に作成する
次の手順では、フルロードと CDC に別々のタスクを使用して外部キーとインデックスを移行する方法について説明します。
フルロードタスクを作成します。
ソーステーブルと一致するように、ターゲットで外部キーとインデックスを含むテーブルを手動で作成します。
次の ECA を AWS DMS ターゲットエンドポイントに追加します。
Initstmt=SET FOREIGN_KEY_CHECKS=0;
TargetTablePrepMode
パラメータをDO_NOTHING
、EnableValidation
をFALSE
に設定して、AWS DMS タスクを作成します。タスクを開始します。AWS DMS はフルロードが完了したらタスクを自動的に停止し、キャッシュされた変更を適用します。
タスクが完了したら、CDC のみのタスクを開始するために、フルロードタスクの UTC での開始時刻、またはバイナリログファイルの名前と位置をメモしておきます。ログを参照して、最初のフルロード開始時刻からの UTC 単位のタイムスタンプを取得します。
CDC のみのタスクを作成する
以前に設定した
SET FOREIGN_KEY_CHECKS
ECA を削除します。開始位置を前の手順でメモしておいたフルロード開始時刻に設定して、CDC のみのタスクを作成します。前のステップで記録しておいたバイナリログ位置を使用することもできます。
TargetTablePrepMode
設定を「DO_NOTHING
」に設定します。必要に応じて、EnableValidation
設定をTRUE
に設定して、データ検証を有効にします。CDC のみのタスクを開始し、ログでエラーをモニタリングします。
注記
この回避策は MySQL 間移行にのみ適用されます。バッチ適用の場合は、ターゲットテーブルにアクティブな外部キーがない必要があるため、この方法はバッチ適用機能では使用できません。
PostgreSQL に関する問題のトラブルシューティング
以下では、AWS DMS を PostgreSQL データベースと使用する際に固有の問題のトラブルシューティングについて学習できます。
トピック
- 切り捨てられる JSON データ型
- ユーザー定義のデータ型の列が正しく移行されない
- エラー: 作成用のスキーマが選択されていません
- CDC を使用してテーブルへの削除や更新がレプリケートされない
- TRUNCATE ステートメントが反映されない
- PostgreSQL の DDL キャプチャを防止する
- DDL キャプチャ用のデータベースオブジェクトを作成するスキーマの選択
- PostgreSQL に移行した後 Oracle テーブルが存在しない
- [ReplicationSlotDiskUsage] (スロットディスク使用度レプレリケーション) が増加し、restart_lsn は ETL ワークロードなどの長いトランザクション中に前進を停止します
- ソースとしてビューを使用したタスクで行がコピーされない
切り捨てられる JSON データ型
AWS DMS では、PostgreSQL の JSON データ型は LOB データ型の列として処理されます。つまり、制限付き LOB モードを使用するときの LOB のサイズ制限が、JSON データに適用されます。
例えば、制限付き LOB モードが 4,096 KB に設定されているとします。この場合、4,096 KB よりも大きい JSON データは 4,096 KB の制限で切り捨てられ、PostgreSQL での検証テストに失格します。
以下のログ情報は、制限付き LOB モードにより切り捨てられた JSON と、失敗した検証を示しています。
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] (SQL_ERROR SqlState: 3F000 NativeError: 7 メッセージ: エラー:作成用のスキーマが選択されていません) が表示されることがあります。
このエラーは、JSON テーブルマッピングがスキーマのワイルドカード値を含み、ソースデータベースがその値をサポートしていない時に発生することがあります。
CDC を使用してテーブルへの削除や更新がレプリケートされない
変更データ キャプチャ (CDC) 中の削除オペレーションと更新オペレーションは、ソーステーブルにプライマリ キーがない場合は無視されます。AWS DMS は、プライマリ キーを持つ PostgreSQL テーブルの変更データ キャプチャ (CDC) をサポートしています。
テーブルにプライマリ キーがない場合、先書きログ (WAL) にはデータベース行の前イメージが含まれていません。この場合は、AWS DMS はテーブルを更新できません。削除オペレーションをレプリケートする場合は、ソーステーブルにプライマリ キーを作成します。
TRUNCATE ステートメントが反映されない
変更データ キャプチャ (CDC) を使用する場合、AWS DMS は TRUNCATE オペレーションをサポートしません。
PostgreSQL の DDL キャプチャを防止する
PostgreSQL ターゲットエンドポイントが DDL ステートメントをキャプチャしないようにするには、次の [エンドポイント設定] ステートメントを追加します。
"CaptureDDLs": "N"
DDL キャプチャ用のデータベースオブジェクトを作成するスキーマの選択
DDL キャプチャに関連したデータベースオブジェクトをどのスキーマで作成するかを制御できます。次の [エンドポイント設定] ステートメントを追加します。この [エンドポイント設定] パラメータは、ソースエンドポイントのタブで提供されています。
"DdlArtifactsSchema: "xyzddlschema"
PostgreSQL に移行した後 Oracle テーブルが存在しない
この場合、通常、テーブルとデータには引き続きアクセスできます。
Oracle のデフォルトは大文字テーブル名ですが、PostgreSQL のデフォルトは小文字テーブル名です。Oracle から PostgreSQL に移行するときは、タスクのテーブル マッピングセクションの下に特定の変換ルールを指定することをお勧めします。これらは、テーブル名の大文字と小文字を変換するための変換ルールです。
テーブル名のケースを変換する変換ルールを使わずにテーブルを移行した場合、それらを参照するときテーブル名を引用符で囲みます。
[ReplicationSlotDiskUsage] (スロットディスク使用度レプレリケーション) が増加し、restart_lsn は ETL ワークロードなどの長いトランザクション中に前進を停止します
論理レプリケーションが有効な場合、トランザクションあたりのメモリに保持される変更の最大数は 4MB です。その後、変更がディスクにこぼれます。その結果 ReplicationSlotDiskUsage
が増加し、restart_lsn
は、トランザクションが完了/中止され、ロールバックが完了するまで進みません。トランザクションが長いので、ロールバックに長時間かかることがあります。
従って、論理レプリケーションが有効になっている場合は、トランザクションの長期実行を避けてください。代わりに、トランザクションをいくつかの小さなトランザクションに分割してください。
ソースとしてビューを使用したタスクで行がコピーされない
ビューを移行するには、table-type
を all
または view
に設定します。詳細については、「 コンソールからテーブル選択および変換を指定する」を参照してください。
ビューをサポートするソースには、次のようなものがあります。
-
Oracle
-
Microsoft SQL Server
-
MySQL
-
PostgreSQL
-
IBM Db2 LUW
-
SAP Adaptive Server Enterprise (ASE)
Microsoft SQL Server 問題のトラブルシューティング
以下では、AWS DMS を Microsoft SQL Server データベースと使用する際に固有の問題のトラブルシューティングについて学習できます。
トピック
RDS for SQL Server がセカンダリにフェイルオーバーした後、継続的なレプリケーションが失敗する
ソース SQL Server インスタンスがセカンダリにフェイルオーバーした場合、AWS DMS の継続的なレプリケーションは接続を再試行し、ソースがオンラインに戻ったらレプリケートを続行します。ただし、RDS for SQL Server MAZ インスタンスの場合、特定の状況では、セカンダリデータベースの所有者を 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 の Amazon RDS for SQL Server データベースの rdsa アカウントへの変更」の手順に従い、DMS タスクを再開します。
SQL Server データベースの変更キャプチャエラー
変更データ キャプチャ (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)
Microsoft SQL Server データベースの AWS DMS のソースとしての使用 で、SQL Server をソースとして使用するための前提条件を確認します。
IDENTITY 列が存在しない
AWS DMS では、ターゲットスキーマを作成する場合の IDENTITY 列がサポートされていません。初期ロードの完了後に追加する必要があります。
エラー: SQL Server は公開をサポートしていません
以下のエラーは、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 Server データベースが「FULL」または「BULK LOGGED」データ復旧モデルのいずれかであることが必要です。「SIMPLE」モデルはサポートされていません。
SIMPLE 復旧モデルは、ユーザーがデータベースを復旧するのに必要な最低限の情報を記録します。すべての非アクティブのログエントリは、チェックポイントが発生すると自動的に切り捨てられます。
すべてのオペレーションは引き続きログに記録されます。ただし、チェックポイントが発生するとすぐに、ログは自動的に切り捨てられます。この切り捨ては、ログが再利用可能になり、古いログエントリを上書きできることを意味します。ログエントリが上書きされると、変更をキャプチャできません。この問題は AWS DMS が、SIMPLE データ復旧モデルをサポートしていないのが理由です。SQL Server をソースとして使用するためのその他の前提条件については、「Microsoft SQL Server データベースの AWS DMS のソースとしての使用」をご参照ください。
パーティションにまたがってマッピングされる不均一テーブル
変更データ キャプチャ (CDC) 中に、AWS DMS がテーブルで CDC を適切に実行できない場合、特殊な構造を持つテーブルの移行は中断されます。次のようなメッセージが発行されます。
[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 Server テーブルで CDC を実行する場合、AWS DMS は SQL Server の tlog を解析します。各 tlog レコードで、AWS DMS は変更中に挿入、更新、または削除されたカラムのデータを含む 16 進値を解析します。
16 進レコードを解析するために、AWS DMS は SQL Server システムテーブルからテーブルメタデータを読み取ります。これらのシステムテーブルは、特別に構造化されたテーブルカラムが何であるかを識別し、「xoffset」や「null bit position」などの内部プロパティの一部を表示します。
AWS DMS では、メタデータがテーブルのすべての未加工パーティションで同じであることを想定しています。しかし、場合によっては、特別に構造化されたテーブルのすべてのパーティションで同じメタデータが保持されないことがあります。この場合、AWS DMS は、そのテーブルの CDC を中断して、変更を誤って解析したり、ターゲットに誤ったデータを提供したりするのを防ぐことができます。回避策には、次のものが含まれます:
テーブルにクラスター化されたインデックスがある場合は、インデックスの再構築を実行します。
テーブルにクラスター化されたインデックスがない場合は、クラスター化されたインデックスをテーブルに追加します (必要に応じて後で削除できます)。
Amazon Redshift に関する問題のトラブルシューティング
以下では、AWS DMS を Amazon Redshift データベースと使用際に固有の問題のトラブルシューティングについて学習できます。
トピック
異なる AWS リージョンの Amazon Redshift クラスターにロードする
AWS DMS レプリケーション インスタンスとは異なる AWS リージョンの Amazon Redshift クラスターにロードすることはできません。DMS では、レプリケーション インスタンスと Amazon Redshift クラスターが同じリージョンにあることが前提です。
エラー: リレーション「awsdms_apply_exceptions」がすでに存在します
エラー "リレーション「awsdms_apply_exceptions」がすでに存在します" は、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 にアクセスするのに使うユーザーアカウントは、以下のアクセス許可を必要とします:
CRUD (選択、挿入、更新、削除)
[BULK Load] (一括ロード)
CREATE、ALTER、DROP (タスクの定義によって必要な場合)
Amazon Redshift をターゲットとして使用するための前提条件を確認するには、「AWS Database Migration Serviceのターゲットとしての Amazon Redshift データベースの使用」をご参照ください。
Amazon Aurora MySQL に関する問題のトラブルシューティング
以下では、AWS DMS を Amazon Aurora MySQL データベースと使用する際に固有の問題のトラブルシューティングについて学習できます。
エラー: CHARACTER SET UTF8 フィールドが「,」で切り取られています。行が「\n」で切り取られています
ターゲットとして Amazon Aurora MySQL を使用している場合、ログに次のようなエラーが表示されることがあります。通常、このタイプのエラーは SQL_MODE パラメータの一部に ANSI_QUOTES があることを示しています。SQL_MODE パラメータの一部として ANSI_QUOTES がある場合、二重引用符が引用符として処理され、タスクの実行時に問題が起きることがあります。
このエラーを修正するには、SQL_MODE パラメータから ANSI_QUOTES を削除します。
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 に関する問題のトラブルシューティング
以下では、AWS DMS を SAP ASE データベースと使用する際に固有の問題のトラブルシューティングについて学習できます。
エラー:ソースに NULL 値を持つコンポジット一意インデックスがある場合、LOB 列には NULL 値があります
NULL 値を許可する複合一意インデックスで構成されたテーブルで SAP ASE をソースとして使用すると、進行中のレプリケーション中に LOB 値が移行されないことがあります。通常、この動作は、DMS レプリケーション インスタンス クライアントで ANSI_NULL をデフォルトで 1 に設定した結果です。
LOB フィールドが正しく移行されるようにするには、タスクの AWS DMS ソースエンドポイントにエンドポイント設定 'AnsiNull=0'
を含めます。
IBM Db2 に関する問題のトラブルシューティング
AWS DMS で IBM Db2 データベースを使用する場合に特有の問題のトラブルシューティングについての説明は次のとおりです。
エラー: Resume from timestamp is not supported Task
継続的なレプリケーション (CDC) で、特定のタイムスタンプからレプリケーションを開始する場合は、StartFromContext
接続属性を必要なタイムスタンプに設定する必要があります。詳細については、「Endpoint settings when using 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.