翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # AWS DMS データ検証 **Topics** + [レプリケーションタスクの統計](#CHAP_Validating.TaskStatistics) + [Amazon CloudWatch を使用したレプリケーション タスクの統計](#CHAP_Validating.TaskStatistics.CloudWatch) + [タスク実行中のテーブル再検証](#CHAP_Validating.Revalidating) + [JSON エディタを使用して検証ルールを変更する](#CHAP_Validating.JSONEditor) + [検証のみのタスク](#CHAP_Validating.ValidationOnly) + [トラブルシューティング](#CHAP_Validating.Troubleshooting) + [Redshift 検証パフォーマンス](#CHAP_Validating.Redshift) + [の拡張データ検証 AWS Database Migration Service](#CHAP_Validating_Enhanced) + [制限事項](#CHAP_Validating.Limitations) + [Amazon S3 ターゲットのデータ検証](CHAP_Validating_S3.md) + [AWS DMS データの再同期](CHAP_Validating.DataResync.md) AWS DMS は、データの検証をサポートして、データがソースからターゲットに正確に移行されたことを確認します。有効な場合、テーブルに対して全ロードが実行された後で、検証がすぐに開始します。検証では、CDC が有効なタスクの増分変更が発生したときに比較されます。 データ検証中、 はソースの各行をターゲットの対応する行 AWS DMS と比較し、行に同じデータが含まれていることを確認し、不一致があれば報告します。これを実現するには、データを取得するための AWS DMS 適切なクエリを実行します。これらのクエリは、ソースとターゲットで追加リソースと、追加ネットワークリソースを消費します。 CDC のみのタスクで検証が有効になっている場合、新しいデータの検証を開始する前に、テーブル内のすべての既存データが検証されます。 データ検証は、 がソースエンドポイントとして AWS DMS サポートしている場合、次のソースデータベースと連携します。 + Oracle + PostgreSQL 互換データベース（PostgreSQL または Aurora PostgreSQL、Aurora Serverless for PostgreSQL） + MySQL 互換データベース (MySQL または MariaDB、Aurora MySQL、Aurora Serverless for MySQL) + Microsoft SQL Server + IBM Db2 LUW データ検証は、 がターゲットエンドポイントとして AWS DMS サポートしている場合、次のターゲットデータベースで機能します。 + Oracle + PostgreSQL 互換データベース（PostgreSQL または Aurora PostgreSQL、Aurora Serverless for PostgreSQL） + MySQL 互換データベース (MySQL または MariaDB、Aurora MySQL、Aurora Serverless for MySQL) + Microsoft SQL Server + IBM Db2 LUW + Amazon Redshift + Amazon S3。Amazon S3 ターゲットデータの検証については、「[Amazon S3 ターゲットのデータ検証](CHAP_Validating_S3.md)」を参照してください。 サポートされているエンドポイントの詳細については、「[DMS AWS エンドポイントの使用](CHAP_Endpoints.md)」をご参照ください。 データの検証には、移行自体に必要な時間以外にも、さらに時間がかかります。必要な追加の時間は、移行されたデータの量によって異なります。 これらの設定の詳細については、「[データ検証タスクの設定](CHAP_Tasks.CustomizingTasks.TaskSettings.DataValidation.md)」をご参照ください。 JSON ファイル内の `ValidationSettings` タスク設定の例については、[タスク設定例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example) を参照してください。 ## レプリケーションタスクの統計 データ検証が有効になっている場合、 はテーブルレベルで次の統計 AWS DMS を提供します。 + **[ValidationState]** (検証状態) — テーブルの検証状態。このパラメータには以下の値があります。 + **Not enabled** — 移行タスクでテーブルに対して検証が有効化されていません。 + **Pending records** — テーブル内の一部のレコードが、検証を待機しています。 + **[Mismatched records]** (不一致レコード) – テーブル内の一部のレコードが、ソースとターゲット間で一致しません。さまざまな理由により、不一致が発生することがあります。詳細については、ターゲットエンドポイントの `awsdms_control.awsdms_validation_failures_v1` を確認してください。 + **Suspended records** – テーブル内に検証できないレコードがあります。 + **No primary key** – テーブルにプライマリキーがないため、検証できません。 + **[Table error]** (テーブルエラー)– テーブルがエラー状態で一部のデータが移行されなかったため、テーブルは検証されませんでした。 + **[Validated]** (検証済み) – テーブル内のすべての行が検証されます。テーブルが更新された場合、ステータスは [Validated] から変わる可能性があります。 + **Error** – 予期しないエラーが発生したため、テーブルを検証できません。 + **[Pending validation]** (検証保留中) — テーブルは検証を待っています。 + **[Preparing table]** (テーブルの準備) — 移行タスクで有効になっているテーブルの検証を準備します。 + **[Pending revalidation]** (保留中の再検証) —テーブルが更新された後で、テーブル内のすべての行が検証を保留します。 + **ValidationPending** – ターゲットに移行されたが、まだ検証されていないレコードの数。 + **ValidationSuspended** — 比較 AWS DMS できないレコードの数。たとえば、ソースのレコードが常に更新されている場合、 AWS DMS はソースとターゲットを比較できません。 + **[ValidationFailed]** (検証失敗) – データの検証フェーズに合格しなかったレコードの数。 JSON ファイル内の `ValidationSettings` タスク設定の例については、[タスク設定例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example) を参照してください。 コンソール、、または AWS DMS API を使用して AWS CLI、データ検証情報を表示できます。 + コンソールで、タスクを作成または変更するときにタスクの検証を選択できます。コンソールを使用してデータ検証レポートを表示するには、[**Tasks**] ページでタスクを選択し、詳細セクションの [**Table statistics**] タブを選択します。 + CLI を使用して、タスク作成時または変更時にデータ検証を開始する場合は、`EnableValidation` パラメータを `true` に設定します。以下の例では、タスクを作成し、データ検証を有効にします。 ``` create-replication-task --replication-task-settings '{"ValidationSettings":{"EnableValidation":true}}' --replication-instance-arn arn:aws:dms:us-east-1:5731014: rep:36KWVMB7Q --source-endpoint-arn arn:aws:dms:us-east-1:5731014: endpoint:CSZAEFQURFYMM --target-endpoint-arn arn:aws:dms:us-east-1:5731014: endpoint:CGPP7MF6WT4JQ --migration-type full-load-and-cdc --table-mappings '{"rules": [{"rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": {"schema-name": "data_types", "table-name": "%"}, "rule-action": "include"}]}' ``` `describe-table-statistics` コマンドを使用して、JSON 形式でデータ検証レポートを受け取ります。以下のコマンドでは、データ検証レポートを表示します。 ``` aws dms describe-table-statistics --replication-task-arn arn:aws:dms:us-east-1:5731014: rep:36KWVMB7Q ``` このレポートは以下の例のようになります。 ``` { "ReplicationTaskArn": "arn:aws:dms:us-west-2:5731014:task:VFPFTYKK2RYSI", "TableStatistics": [ { "ValidationPendingRecords": 2, "Inserts": 25, "ValidationState": "Pending records", "ValidationSuspendedRecords": 0, "LastUpdateTime": 1510181065.349, "FullLoadErrorRows": 0, "FullLoadCondtnlChkFailedRows": 0, "Ddls": 0, "TableName": "t_binary", "ValidationFailedRecords": 0, "Updates": 0, "FullLoadRows": 10, "TableState": "Table completed", "SchemaName": "d_types_s_sqlserver", "Deletes": 0 } } ``` + AWS DMS API を使用して、**CreateReplicationTask** アクションを使用してタスクを作成し、 `EnableValidation`パラメータを **true** に設定して、タスクによって移行されたデータを検証します。**DescribeTableStatistics** アクションを使用して、JSON 形式でデータ検証レポートを受け取ります。 ## Amazon CloudWatch を使用したレプリケーション タスクの統計 Amazon CloudWatch が有効になっている場合、 は次のレプリケーションタスク統計 AWS DMS を提供します。 + **ValidationSucceededRecordCount** — が AWS DMS 検証した 1 分あたりの行数。 + **ValidationAttemptedRecordCount** - 検証が試行された行の 1 分あたりの数。 + **ValidationFailedOverallCount** - 検証が失敗した行の数。 + **ValidationSuspendedOverallCount** - 検証が停止された行の数。 + **ValidationPendingOverallCount** - 検証がまだ保留中の行の数。 + **ValidationBulkQuerySourceLatency** — AWS DMS は、特に多くの変更がある場合、全ロードまたは継続的レプリケーション中の特定のシナリオで、データ検証を一括実行できます。このメトリックスは、ソースエンドポイントから大量のデータを読み取るために必要なレイテンシーを示します。 + **ValidationBulkQueryTargetLatency** — AWS DMS は、特に多くの変更がある場合、ロードまたは継続的レプリケーション中の特定のシナリオで、データ検証を一括実行できます。このメトリックスは、ターゲットエンドポイントの大量のデータを読み取るために必要なレイテンシーを示します。 + **ValidationItemQuerySourceLatency** - 継続的レプリケーションでは、データ検証によって継続的変更を識別し、それらの変更を検証できます。このメトリックスは、変更をソースから読み取る際のレイテンシーを示します。検証中にエラーが発生した場合、検証では必要な数以上のクエリを実行できます。 + **ValidationItemQueryTargetLatency** - 継続的レプリケーションでは、データ検証によって継続的変更を識別し、それらの変更を行ごとに検証できます。このメトリックスは、変更をターゲットから読み取る際のレイテンシーを示します。検証中にエラーが発生した場合、検証では必要な数以上のクエリが実行される場合があります。 CloudWatch が有効な統計情報からデータ検証情報を収集するには、タスクを作成または変更するとき、**[Enable CloudWatch logs]** (CloudWatch ログを有効にする) コンソールを使用します。次に、データ検証情報を確認し、データがソースからターゲットに正確に移行されたことを確認するため、以下を行います。 1. **[Database migration tasks]** (データベース移行タスク) ページでタスクを選択します。 1. **[CloudWatch metrics]** (CloudWatch メトリクス) タブ。 1. CloudWatch が有効な統計情報からデータ検証情報を収集するには、タスクを作成または変更するとき、**[Enable CloudWatch logs]** (CloudWatch ログを有効にする) コンソールを使用します。 ## タスク実行中のテーブル再検証 タスクの実行中に、 AWS DMS にデータ検証の実行をリクエストできます。 ### AWS マネジメントコンソール 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/) で AWS DMS コンソールを開きます。 AWS Identity and Access Management (IAM) ユーザーとしてサインインしている場合は、 にアクセスするための適切なアクセス許可があることを確認してください AWS DMS。必要なアクセス許可については、「」を参照してください[を使用するために必要な IAM アクセス許可 AWS DMS](security-iam.md#CHAP_Security.IAMPermissions)。 1. ナビゲーションペインから [**Tasks**] を選択します。 1. 再検証するテーブルを含む実行中のタスクを選択します。 1. [**テーブル統計**] タブを選択します。 1. 再検証するテーブルを選択します (一度に最大 10 個のテーブルを選択できます)。タスクがすでに実行されていない場合は、テーブルを再検証できません。 1. [**Revalidate (再検証)**] を選択します。 ## JSON エディタを使用して検証ルールを変更する AWS DMS コンソールの JSON エディタを使用してタスクに検証ルールを追加するには、次の手順を実行します。 1. **[Database migration tasks]** (データベース移行タスク) を選択します。 1. 移行タスクの一覧からタスクを選択します。 1. タスクが実行中の場合には、**[Actions]** (アクション) ドロップダウンメニューから**[Stop]** (停止) を選択します。 1. タスクが停止したら、タスクを変更するには、**[Actions]** (アクション) ドロップダウンメニューから**[Modify]** (変更) を選択します。 1. **[Table mappings]** (テーブルマッピング) セクションで、**[JSON editor]** (JSON エディター) を選択し、検証ルールをテーブルマッピングに追加します。 たとえば、次の検証ルールを追加して、ソースで置換関数を実行できます。この場合、検証ルールがヌルバイトを検出すると、それをスペースとして検証します。 ``` { "rule-type": "validation", "rule-id": "1", "rule-name": "1", "rule-target": "column", "object-locator": { "schema-name": "Test-Schema", "table-name": "Test-Table", "column-name": "Test-Column" }, "rule-action": "override-validation-function", "source-function": "REPLACE(${column-name}, chr(0), chr(32))", "target-function": "${column-name}" } ``` **注記** 列がプライマリキーの一部である場合、`override-validation-function` は有効になりません。 ## 検証のみのタスク 検証専用タスクを作成して、移行やデータレプリケーションを実行せずにデータをプレビューしたり検証したりできます。検証のみのタスクを作成するには、`EnableValidation` 設定と `ValidationOnly` 設定を `true` に設定します。`ValidationOnly` を有効にすると、追加の要件が適用されます。詳細については、「[データ検証タスクの設定](CHAP_Tasks.CustomizingTasks.TaskSettings.DataValidation.md)」を参照してください。 フルロードのみの移行タイプで多くの障害がレポートされた場合、検証のみのタスクでは CDC の同等のタスクよりもはるかに速く完了します ただし、ソースエンドポイントまたはターゲットエンドポイントへの変更は、フルロードモードの障害としてレポートされることが不利な点となる可能性があります。 CDC 検証のみのタスクは、平均レイテンシーに基づいて検証を遅らせ、障害を報告する前に複数回再試行します。データ比較の大部分が障害付きで完了する場合、CDC モードの検証のみタスクは非常に遅く、不利となる可能性があります。 検証のみのタスクは、特に CDC の場合、レプリケーションタスクと同じ方向に設定する必要があります。これは、CDC 検証のみのタスクが、ソースの変更ログに基づいて変更され、再検証が必要な行を検出するためです。ターゲットがソースとして指定されている場合、ターゲットは DMS がターゲットに送信した変更についてのみ認識するため、レプリケーションエラーが検出される保証はありません。 ### フルロード検証のみ AWS DMS バージョン 3.4.6 以降では、全ロード検証のみのタスクは、ソーステーブルとターゲットテーブルのすべての行を 1 回のパスですばやく比較し、障害があればすぐに報告してからシャットダウンします。このモードでは障害が発生しても検証が中断されることはなく、速度が最適化されます。ただし、ソースまたはターゲットエンドポイントへの変更は失敗として報告されます。 **注記** AWS DMS バージョン 3.4.6 以降では、この検証動作は、検証が有効になっている全ロード移行タスクにも適用されます。 ### CDC 検証のみ CDC 検証のみのタスクでは、新たな開始時にソーステーブルとターゲットテーブル間の既存のすべての行を検証します。さらに、CDC 検証のみのタスクは継続的に実行され、継続的なレプリケーションの変更は再検証され、各パスで報告される失敗の数は制限され、不一致の行は失敗する前に再試行されます。誤検出を防ぐように最適化されています。 ` FailureMaxCount` または `TableFailureMaxCount` のしきい値を超えると、テーブル (またはタスク全体) の検証が中断されます。これは、検証が有効になっている CDC またはフルロード \+ CDC 移行タスクにも適用されます。また、検証が有効になっている CDC タスクでは、ソースとターゲットの平均レイテンシーにより、変更された各行の再検証が遅延します。 ただし、CDC **検証のみのタスクではデータは移行されず、レイテンシーもありません。デフォルトでは、`ValidationQueryCdcDelaySeconds` は 180 に設定されます。レイテンシーが高い環境のアカウントではこの量を増やし、誤検出を防ぐこともできます。 ### 検証のみのユースケース 移行またはレプリケーションタスクのデータ検証部分を別の**検証のみのタスクに分割するユースケースには、次がありますが、これらに限定されません。 + **検証がいつ行われるかを正確に制御する — 検証クエリを使用すると、ソースエンドポイントとターゲットエンドポイントの両方に追加の負荷がかかります。そのため、最初に 1 つのタスクでデータを移行またはレプリケートして、次に別のタスクで結果を検証すると、有益な場合があります。 + **レプリケーションインスタンスの負荷を軽減する — データ検証を分割して独自のインスタンスで実行すると、利点が得られる場合があります。 + **特定の時点で一致しない行の数を迅速に取得する — 例えば、ターゲットエンドポイントへのメンテナンスウィンドウの本番環境のカットオーバーの直前または最中に、フルロード検証のみのタスクを作成すると、質問への回答を得られます。 + **CDC コンポーネントを使用した移行タスクで検証の失敗が予想される場合 — 例えば、Oracle の `varchar2` を PostgreSQL の `jsonb` に移行する場合、CDC 検証は、このような失敗した行の再試行を引き続き行い、毎回レポートされる障害の数を制限します。ただし、フルロード検証のみのタスクを作成すると、より迅速に回答を得ることができます。 + **検証に失敗したテーブルを読み取るデータ修復スクリプトまたはユーティリティを開発する — ([トラブルシューティング](#CHAP_Validating.Troubleshooting) も参照)。フルロード検証のみのタスクでは、データ修復スクリプトが対応できるように障害を迅速にレポートします。 JSON ファイル内の `ValidationSettings` タスク設定の例については、「[タスク設定例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)」を参照してください)。 ## トラブルシューティング 検証中、 はターゲットエンドポイント に新しいテーブル AWS DMS を作成します`awsdms_control.awsdms_validation_failures_v1`。レコードが *ValidationSuspended* または *ValidationFailed* 状態になると、 は診断情報を に AWS DMS 書き込みます`awsdms_control.awsdms_validation_failures_v1`。このテーブルをクエリすることで、検証エラーをトラブルシューティングすることができます。 ターゲット上でテーブルが作成されるデフォルトスキーマの変更については、「[制御テーブルタスク設定](CHAP_Tasks.CustomizingTasks.TaskSettings.ControlTable.md)」をご参照ください。 以下に、`awsdms_control.awsdms_validation_failures_v1` テーブルの説明を示します。 | [列名] | データ型 | 説明 | | --- | --- | --- | | `TASK_NAME` | `VARCHAR(128) NOT NULL` | AWS DMS タスク識別子。 | | TABLE\_OWNER | VARCHAR(128) NOT NULL | テーブルのスキーマ (所有者)。 | | `TABLE_NAME` | VARCHAR(128) NOT NULL | テーブル名。 | | FAILURE\_TIME | DATETIME(3) NOT NULL | イベントが失敗した時刻。 | | KEY\_TYPE | VARCHAR(128) NOT NULL | 将来の使用のために予約済み (値は常に [Row](行)) | | KEY | TEXT NOT NULL | これは行レコードタイプのプライマリキーです。 | | FAILURE\_TYPE | VARCHAR(128) NOT NULL | 検証エラーの重大度。`RECORD_DIFF`、`MISSING_SOURCE`、`MISSING_TARGET`、または `TABLE_WARNING` のいずれかになります。 | | DETAILS | VARCHAR(8000) NOT NULL | 所与のキーと一致しないすべてのソース/ターゲット列の値を含む JSON 形式の文字列です。 | 以下のサンプルクエリでは、MySQL ターゲットが `awsdms_control.awsdms_validation_failures_v1` テーブルに対してクエリを実行して、タスクのすべての失敗を表示します。スキーマ名とクエリ構文は、ターゲットのエンジンバージョンによって異なることに注意してください。タスク名は、タスクの外部リソース ID である必要があります。タスクの外部リソース ID は、タスク ARN の最後の値です。たとえば、ARN 値が arn:aws:dms:us-west-2:5599:task: VFPFKH4FJR3FTYKK2RYSI のタスクの場合、タスクの外部リソース ID は VFPFKH4FJR3FTYKK2RYSI となります。 ``` select * from awsdms_validation_failures_v1 where TASK_NAME = 'VFPFKH4FJR3FTYKK2RYSI' TASK_NAME VFPFKH4FJR3FTYKK2RYSI TABLE_OWNER DB2PERF TABLE_NAME PERFTEST FAILURE_TIME 2020-06-11 21:58:44 KEY_TYPE Row KEY {"key": ["3451491"]} FAILURE_TYPE RECORD_DIFF DETAILS [[{'MYREAL': '+1.10106036e-01'}, {'MYREAL': '+1.10106044e-01'}],] ``` `DETAILS` フィールドを参照し、一致しない列を特定します。失敗したレコードのプライマリ キーを入手したら、ソース エンドポイントとターゲット エンドポイントをクエリし、レコードの不一致部分を確認できます。 ### `awsdms_validation_failures_v2` コントロールテーブル 検証中、 AWS DMS バージョン 3.6.1 以降では、DMS は PostgreSQL ターゲットエンドポイント に新しいテーブルを作成します`awsdms_validation_failures_v2`。このテーブルは、データ検証が有効になっているすべての DMS タスクの失敗で構成されます。`awsdms_validation_failures_v2` テーブルを作成するときは、検証と再同期が有効になっているタスクではエラーが発生する可能性があるため、テーブルを削除または切り捨てないでください。`awsdms_validation_failures_v2` テーブルには自動増分プライマリキー機能があります。このテーブルは、データの再同期機能をサポートする新しい列で構成されます。具体的には次の 2 つです。 `RESYNC_RESULT` **値**: `SUCCESS` または `FAILURE`。 **`RESYNC_TIME`** ミリ秒精度のタイムスタンプ。この失敗でデータの再同期が試行されない場合、デフォルト値は `NULL` です。 **`RESYNC_ACTION`** **値**: `UPSERT` または `DELETE`。 `RESYNC_ID` 自動増分が有効になっているプライマリキー列。 `awsdms_validation_failures_v2` テーブルでは、インデックスが `TASK_NAME`、`TABLE_OWNER`、`TABLE_NAME`、`FAILURE_TYPE`、および `FAILURE_TIME` 列に追加され、ターゲットデータベースで特定のテーブルに関する失敗の読み取りが効率的に行われます。以下は、`awsdms_validation_failures_v2` テーブルを作成するための create ステートメントの例です。 ``` CREATE TABLE public.awsdms_validation_failures_v2 ( "RESYNC_ID" int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL, "TASK_NAME" varchar(128) NOT NULL, "TABLE_OWNER" varchar(128) NOT NULL, "TABLE_NAME" varchar(128) NOT NULL, "FAILURE_TIME" timestamp NOT NULL, "KEY_TYPE" varchar(128) NOT NULL, "KEY" varchar(7800) NOT NULL, "FAILURE_TYPE" varchar(128) NOT NULL, "DETAILS" varchar(7000) NOT NULL, "RESYNC_RESULT" varchar(128) NULL, "RESYNC_TIME" timestamp NULL, "RESYNC_ACTION" varchar(128) NULL, CONSTRAINT awsdms_validation_failures_v2_pkey PRIMARY KEY ("RESYNC_ID") ); ``` ## Redshift 検証パフォーマンス Amazon Redshift は、いくつかの点 (列指向ストレージ、MPP、データ圧縮、その他の要因など) でリレーショナルデータベースとは異なります。これらの違いにより、Redshift はリレーショナルデータベースとは異なるパフォーマンスプロファイルを持ちます。 フルロードレプリケーションフェーズでは、検証で範囲クエリを使用し、データサイズは `PartitionSize` 設定によって決まります。これらの範囲ベースのクエリは、ソーステーブルからすべてのレコードを選択します。 継続的なレプリケーションの場合、クエリは範囲ベースのフェッチと個別レコードのフェッチを切り替えます。クエリタイプは、次のような複数の要因に基づいて動的に決定されます。 + クエリボリューム + ソーステーブルの DML クエリのタイプ + タスクレイテンシー + レコード総数 + 検証設定 (`PartitionSize` など) 検証クエリにより、Amazon Redshift クラスターに追加の負荷がかかる場合があります。上記の要因はユースケースによって異なるため、検証クエリのパフォーマンスを確認してクラスターとテーブルを相応に調整する必要があります。パフォーマンスの問題を軽減するためのオプションには、次のようなものがあります。 + `PartitionSize` および `ThreadCount` の設定を減らして、フルロード検証中のワークロードを軽減します。これにより、データ検証が遅くなることに注意してください。 + Redshift はプライマリキーを強制しませんが、 AWS DMS はプライマリキーに依存して、データ検証のためにターゲット上のレコードを一意に識別します。可能であれば、ソートキーをミラーリングするようにプライマリキーを設定し、フルロード検証クエリの実行を迅速化します。 ## の拡張データ検証 AWS Database Migration Service AWS Database Migration Service は、データベース移行のデータ検証パフォーマンスを強化し、処理時間を大幅に短縮して大規模なデータセットを検証できるようにします。この拡張データ検証は、フルロードとCDC 移行タスクによるフルロードの両方で、レプリケーションエンジンのバージョン 3.5.4 で利用可能になりました。この機能強化では現在、Oracle から PostgreSQL、SQL Server から PostgreSQL、Oracle から Oracle、SQL Server から SQL Server への移行パスがサポートされており、今後のリリースで追加の移行パスが予定されています。 ### 前提条件 + *Oracle:* Oracle エンドポイントにアクセスするユーザーアカウントに `SYS.DBMS_CRYPTO` に対する `EXECUTE` アクセス許可を付与します。 ``` GRANT EXECUTE ON SYS.DBMS_CRYPTO TO dms_endpoint_user; ``` + PostgreSQL データベースに `pgcrypto` 拡張機能をインストールします。 セルフマネージド PostgreSQL インスタンスの場合は、`contrib` モジュールライブラリをインストールして拡張機能を作成する必要があります。 + `contrib` モジュールライブラリをインストールします。例えば、Amazon Linux および PostgreSQL 15 を使用する Amazon EC2 インスタンスの場合: ``` sudo dnf install postgresql15-contrib ``` + `pgcrypto` エクステンションを作成します。 ``` CREATE EXTENSION IF NOT EXISTS pgcrypto; ``` + Amazon RDS for PostgreSQL インスタンスの場合、 AWS DMS エンドポイントの SSL モードを設定します。 + デフォルトでは、Amazon RDS は SSL 接続を強制します。Amazon RDS for PostgreSQL インスタンスの AWS DMS エンドポイントを作成するときは、「SSL モード」オプション =「必須」を使用します。 + [SSL モード] オプション = [なし] を使用する場合は、RDS パラメータグループで `rds.force_ssl` パラメータを 0 に設定します。 + PostgreSQL 12 および 13 の場合は、`BIT_XOR` 集計を作成します。 ``` CREATE OR REPLACE AGGREGATE BIT_XOR(IN v bit) (SFUNC = bitxor, STYPE = bit); ``` ### データ検証の制限の強化 この拡張データ検証機能には、次の制限があります。 + データベースエンドポイントの要件: この改善は、次の条件を満たすデータベースエンドポイントでのみ有効になります。 + AWS Secrets Manager を使用して認証情報を保存します。 + Microsoft SQL Server では、Kerberos 認証もサポートされています。 + データベースバージョンのサポート: + PostgreSQL 12 以上 + Oracle 12.1 以降 + 2019 年以前の Microsoft SQL Server バージョンでは、NCHAR および NVARCHAR データ型での検証はサポートされていません。 ## 制限事項 + データ検証では、テーブルにプライマリキーまたは一意のインデックスがなければなりません。 + プライマリキー列の型を `CLOB`、`BLOB`、`BINARY`、または `BYTE` に設定することはできません。 + 型が `VARCHAR` または `CHAR` であるプライマリキー列の場合、長さは 1024 未満にする必要があります。データ型の長さを指定する必要があります。無制限のデータ型をデータ検証のプライマリキーとして使用することはできません。 + `NOVALIDATE` 句を使用して作成された Oracle キーは、プライマリ キーまたは一意のインデックスと見なされ*ません*。 + プライマリキーがなく一意キーのみを持つ Oracle テーブルの場合、一意制約のある列にも `NOT NULL` 制約が必要です。 + NULL PK/UK 値の検証はサポートされていません。 + ターゲット PostgreSQL インスタンスのプライマリキー列の照合が「C」に設定されていない場合、プライマリキーと Oracle ではソート順が異なります。PostgreSQL と Oracle でソート順序が異なる場合、データ検証でレコードの検証に失敗します。 + データ検証では、ソースデータベースとターゲットデータベースに対して追加のクエリが生成されます。両方のデータベースに、この追加の負荷を処理するための十分なリソースがあることを確認する必要があります。これは特に Redshift ターゲットに当てはまります。詳細については、「[Redshift 検証パフォーマンス](#CHAP_Validating.Redshift)」を参照してください。 + 複数のデータベースを 1 つに統合する場合、データ検証はサポートされません。 + ソースまたはターゲット Oracle エンドポイントの場合、 は AWS DMS を使用します`DBMS_CRYPTO`。Oracle エンドポイントでデータ検証を使用する場合は、Oracle エンドポイントにアクセスするために使用されるユーザーアカウントに、`dbms_crypto` での実行権限を付与する必要があります。これを行うには、以下のステートメントを実行します。 ``` grant execute on sys.dbms_crypto to {{dms_endpoint_user}}; ``` + 検証 AWS DMS 中にターゲットデータベースが の外部で変更された場合、不一致は正確に報告されない可能性があります。この結果は、アプリケーションの 1 つがターゲットテーブルにデータを書き込み、 AWS DMS が同じテーブルで検証を実行している場合に発生する可能性があります。 + 検証中に 1 つ以上の行が継続的に変更されている場合、 AWS DMS はそれらの行を検証できません。 + が 10,000 件を超える失敗したレコードまたは中断されたレコード AWS DMS を検出すると、検証が停止します。先に進む前に、データの根本的な問題を解決する必要があります。 + AWS DMS はビューのデータ検証をサポートしていません。 + AWS DMS は、文字置換タスク設定を使用する場合のデータ検証をサポートしていません。 + AWS DMS は Oracle LONG タイプの検証をサポートしていません。 + AWS DMS は、異種移行中の Oracle Spatial タイプの検証をサポートしていません。 + データ検証では、テーブルマッピングにデータマスキング変換が存在するテーブルの列は無視されます。 + PK/UK 列のデータマスキング変換ルールがある場合、データ検証はテーブル全体をスキップします。検証状態では、このようなテーブルに対してプライマリキーなしと表示されます。 + データ検証は Amazon Aurora PostgreSQL Limitless では機能しません。Limitless Database でテーブルを検証しようとすると、これらのテーブルで「プライマリキーなし」が検証状態に表示されます。 S3 ターゲット検証を使用する際の制限については、「[ターゲットの S3 の検証を使用する場合の制限](CHAP_Validating_S3.md#CHAP_Validating_S3_limitations)」を参照してください。