本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 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 或適用於 PostgreSQL 的 Aurora Serverless) + 與 MySQL 相容的資料庫 (MySQL、MariaDB、Aurora MySQL 或適用於 MySQL 的 Aurora Serverless) + Microsoft SQL Server + IBM Db2 LUW 資料驗證適用於下列目標資料庫，只要 AWS DMS 支援它們做為目標端點： + Oracle + 與 PostgreSQL 相容的資料庫 (PostgreSQL、Aurora PostgreSQL 或適用於 PostgreSQL 的 Aurora Serverless) + 與 MySQL 相容的資料庫 (MySQL、MariaDB、Aurora MySQL 或適用於 MySQL 的 Aurora Serverless) + Microsoft SQL Server + IBM Db2 LUW + Amazon Redshift + Amazon S3 如需驗證 Amazon S3 目標資料的相關資訊，請參閱 [Amazon S3 目標資料驗證](CHAP_Validating_S3.md)。 如需支援的端點的詳細資訊，請參閱[使用 AWS DMS 端點](CHAP_Endpoints.md)。 資料驗證需要額外的時間，超出移轉本身所需的時間量。所需的額外時間取決於遷移的資料量。 如需這些設定的詳細資訊，請參閱 [資料驗證任務設定](CHAP_Tasks.CustomizingTasks.TaskSettings.DataValidation.md)。 如需 JSON 檔案中 `ValidationSettings` 任務設定的範例，請參閱[任務設定範例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)。 ## 複寫任務統計資料 啟用資料驗證時， 會在資料表層級 AWS DMS 提供下列統計資料： + **ValidationState**：資料表的驗證狀態。其參數可能具有下列值： + **未啟用**：未針對遷移任務中的資料表啟用驗證。 + **待處理記錄**：資料表中的某些記錄正在等待驗證。 + **不相符的記錄**：資料表中的某些記錄在來源和目標之間不相符。不相符的原因有幾個；如需詳細資訊，請參閱目標端點上的 `awsdms_control.awsdms_validation_failures_v1` 資料表。 + **暫停的記錄**：無法驗證資料表中的某些記錄。 + **無主索引鍵**：無法驗證資料表，因為其沒有主索引鍵。 + **資料表錯誤**：未驗證資料表，因為資料表處於錯誤狀態，且某些資料未遷移。 + **已驗證**：已驗證資料表中的所有資料列。如果更新資料表，其狀態可能會從 Validated (已驗證) 變更。 + **錯誤**：因為非預期的錯誤，而無法驗證資料表。 + **待驗證**：資料表正在等待驗證。 + **準備資料表**：準備遷移任務中啟用的資料表以進行驗證。 + **待重新驗證**：更新資料表後，資料表中的所有資料列都處於待驗證狀態。 + **ValidationPending**：已遷移至目標、但尚未驗證的記錄數目。 + **ValidationSuspended** - AWS DMS 無法比較的記錄數目。例如，如果來源的記錄持續更新，則 AWS DMS 無法比較來源和目標。 + **ValidationFailed**：未通過資料驗證階段的記錄數目。 如需 JSON 檔案中 `ValidationSettings` 任務設定的範例，請參閱[任務設定範例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)。 您可以使用 主控台 AWS CLI、 或 AWS DMS API 檢視資料驗證資訊。 + 在主控台上，您可以選擇在建立或修改任務時驗證任務。若要使用主控台檢視資料驗證報告，請在 **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 驗證的資料列數。 + **ValidationAttemptedRecordCount**：每分鐘嘗試驗證的資料列數目。 + **ValidationFailedOverallCount**：驗證失敗的資料列數。 + **ValidationSuspendedOverallCount**：已暫停驗證的資料列數。 + **ValidationPendingOverallCount**：驗證仍處於待處理狀態的資料列數。 + **ValidationBulkQuerySourceLatency**： AWS DMS 可以大量執行資料驗證，特別是在完全載入或持續複寫期間發生許多變更的情況下。此指標表示從來源端點讀取一組大量資料所需的延遲。 + **ValidationBulkQueryTargetLatency**： AWS DMS 可以大量執行資料驗證，特別是在完全載入或持續複寫期間發生許多變更的情況下。此指標表示在目標端點上讀取一組大量資料所需的延遲。 + **ValidationItemQuerySourceLatency**：在持續複寫期間，資料驗證可以識別正在進行的變更並驗證那些變更。此指標表示從來源讀取這些變更時的延遲。如果驗證期間發生錯誤，根據變更數量，驗證可能會執行比所需更多的查詢。 + **ValidationItemQueryTargetLatency**：在持續複寫期間，資料驗證可以識別正在進行的變更，並逐列驗證變更。此指標提供從目標讀取這些變更時的延遲。如果驗證期間發生錯誤，根據變更數量，驗證可能會執行比所需更多的查詢。 若要從已啟用 CloudWatch 的統計資料收集資料驗證資訊，請在使用主控台建立或修改任務時選取**啟用 CloudWatch 日誌**。接著，若要檢視資料驗證資訊，並確保資料正確地從來源遷移至目標，請執行以下動作。 1. 在**資料庫遷移任務**頁面上選擇任務。 1. 選擇 **CloudWatch 指標**索引標籤。 1. 從下拉式功能表中選取**驗證**。 ## 在任務期間重新驗證資料表 當任務執行時，您可以請求 AWS DMS 執行資料驗證。 ### AWS 管理主控台 1. 登入 AWS 管理主控台 並在 https：//[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. 選擇 **Table Statistics (資料表統計資料)** 標籤。 1. 選擇您要重新驗證的資料表 (您一次最多可以選擇 10 個資料表)。若任務已不在執行中，您便無法重新驗證資料表。 1. 選擇 **Revalidate (重新驗證)**。 ## 使用 JSON 編輯器修改驗證規則 若要從 AWS DMS 主控台使用 JSON 編輯器將驗證規則新增至任務，請執行下列動作： 1. 選取**資料庫遷移任務**。 1. 從遷移任務清單中選取任務。 1. 如果任務正在執行中，請從**動作**下拉式功能表中選取**停止**。 1. 任務停止後，若要修改任務，請從**動作**下拉式功能表中選取**修改**。 1. 在**資料表對應**區段中，選取 **JSON 編輯器**，然後將驗證規則新增至資料表對應。 例如，您可以新增以下驗證規則，以便在來源上執行取代函數。在這種案例中，如果驗證規則遇到 Null 位元組，則會將其驗證為空格。 ``` { "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 傳送至目標的相關變更，而且無法保證會快取複寫錯誤。 ### 僅限完全載入驗證 從 3.4.6 版及更高 AWS DMS 版本開始，僅限完全載入驗證任務會在單次傳遞中快速比較來源和目標資料表的所有資料列，立即報告任何失敗，然後關閉。驗證永遠不會由於此模式下的失敗而暫停，此驗證的速度已經過最佳化。但是會將對來源或目標端點的變更報告為失敗。 **注意** 從 3.4.6 版及更高 AWS DMS 版本開始，此驗證行為也適用於啟用驗證的完全載入遷移任務。 ### CDC 僅驗證 CDC 僅驗證任務會在全新開始時驗證來源和目標資料表之間的所有現有資料列。此外，「CDC 僅驗證」任務會持續執行、重新驗證進行中複寫變更、限制每次通過報告的失敗次數，以及在失敗之前重試不相符的資料列。其經過最佳化，以防止誤判。 如果違反 ` FailureMaxCount` 或 `TableFailureMaxCount` 閾值，則會暫停資料表 (或整個任務) 的驗證。這也適用於啟用驗證時的 CDC 或完全載入\$1CDC 遷移任務。啟用驗證的 CDC 任務會根據平均來源和目標延時，延遲每個變更資料列的重新驗證。 但是 CDC 僅驗證任務**不會遷移資料，也沒有延時。預設會將 `ValidationQueryCdcDelaySeconds` 設為 180。您還可以提高數量，以因應高延時環境，並協助防止誤判。 ### 僅驗證使用案例 將遷移或複寫任務的資料驗證部分分割為單獨的*僅驗證任務*的使用案例，包括但不限於下列項目： + *確切控制驗證發生時間*：驗證查詢會同時為來源和目標端點新增額外負載。因此，先在某項任務中遷移或複寫資料，然後在另一項任務中驗證結果可能會有所幫助。 + *減少複寫執行個體的負載*：將資料驗證拆分為在其自己的執行個體上執行會更有優勢。 + *快速獲得在給定時間點有多少資料列不相符*：例如，在維護時段生產切換到目標端點之前或期間，您可以建立僅完全載入驗證任務來取得問題的答案。 + *當具有 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` 資料表的說明： | 欄名稱 | 資料類型 | Description | | --- | --- | --- | | `TASK_NAME` | `VARCHAR(128) NOT NULL` | AWS DMS 任務識別符。 | | TABLE\$1OWNER | VARCHAR(128) NOT NULL | 資料表的結構描述 (擁有者)。 | | `TABLE_NAME` | VARCHAR(128) NOT NULL | 資料表名稱 | | FAILURE\$1TIME | DATETIME(3) NOT NULL | 發生失敗的時間。 | | KEY\$1TYPE | VARCHAR(128) NOT NULL | 保留供未來使用 (值始終是「資料列」) | | KEY | TEXT NOT NULL | 這是資料列記錄類型的主索引鍵。 | | FAILURE\$1TYPE | VARCHAR(128) NOT NULL | 驗證錯誤的嚴重性。可以是 `RECORD_DIFF`、`MISSING_TARGET`、 `MISSING_SOURCE`或 `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` 控制資料表 在驗證期間，在 3.6.1 版及更高 AWS DMS 版本中，DMS 會在 PostgreSQL 目標端點建立新的資料表：`awsdms_validation_failures_v2`。此資料表包含已啟用資料驗證的所有 DMS 任務的失敗。建立`awsdms_validation_failures_v2`資料表時，您不應捨棄或截斷資料表，因為這可能會導致驗證和啟用重新同步的任何任務發生錯誤。 `awsdms_validation_failures_v2`資料表具有自動遞增主索引鍵功能。此資料表包含支援資料重新同步功能的新資料欄。這些類別為： `RESYNC_RESULT` **值**： `SUCCESS`或 `FAILURE`。 **`RESYNC_TIME`** 時間戳記與毫秒精確度。如果未嘗試對此失敗進行資料重新同步`NULL`，則預設值為 。 **`RESYNC_ACTION`** **值**： `UPSERT`或 `DELETE`。 `RESYNC_ID` 啟用自動遞增的主索引鍵資料欄。 在 `awsdms_validation_failures_v2`資料表中，索引會新增至 `TASK_NAME`、`TABLE_OWNER`、`FAILURE_TYPE`、 `TABLE_NAME`和 `FAILURE_TIME`資料欄，以有效率地讀取目標資料庫中任何指定資料表的失敗。以下是建立 `awsdms_validation_failures_v2`資料表的範例建立陳述式： ``` 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：*將 的`EXECUTE`許可授予存取 Oracle `SYS.DBMS_CRYPTO` 端點的使用者帳戶： ``` GRANT EXECUTE ON SYS.DBMS_CRYPTO TO dms_endpoint_user; ``` + 在 PostgreSQL 資料庫上安裝`pgcrypto`擴充功能： 對於自我管理的 PostgreSQL 執行個體，您需要安裝`contrib`模組程式庫並建立擴充功能： + 安裝`contrib`模組程式庫。例如，在具有 Amazon Linux 和 PostgreSQL 15 的 Amazon EC2 執行個體上： PostgreSQL ``` 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`、`BINARY`、 `BLOB`或 類型`BYTE`。 + 針對 `VARCHAR` 或 `CHAR` 類型的主索引鍵資料行，長度必須小於 1024。您必須指定資料類型的長度。您無法使用無界資料類型做為資料驗證的主索引鍵。 + 使用 `NOVALIDATE` 子句建立的 Oracle 索引鍵*不*被視為主索引鍵或唯一索引。 + 對於沒有主索引鍵且只有唯一索引鍵的 Oracle 資料表，具有唯一限制的資料欄也必須具有 `NOT NULL` 限制。 + 不支援驗證 NULL PK/UK 值。 + 如果目標 PostgreSQL 執行個體中主索引鍵資料行的定序未設為 "C"，則主索引鍵的排序相較於 Oracle 的排序會有所不同。如果 PostgreSQL 與 Oracle 之間的排序不同，資料驗證將無法驗證記錄。 + 資料驗證會對來源和目標資料庫產生額外的查詢。您必須確保這兩個資料庫有足夠的資源，可處理此額外的負載。Redshift 目標尤其如此。如需詳細資訊，請參閱下列 [Redshift 驗證效能](#CHAP_Validating.Redshift)。 + 將數個資料庫整合成單一資料庫時不支援資料驗證。 + 對於來源或目標 Oracle 端點， AWS DMS 會使用 `DBMS_CRYPTO`。如果您在 Oracle 端點上使用資料驗證，則必須將 的執行許可授予用於存取 Oracle 端點的`dbms_crypto`使用者帳戶。您可以執行下列陳述式來執行此操作 ``` grant execute on sys.dbms_crypto to dms_endpoint_user; ``` + 如果在驗證 AWS DMS 期間在 外部修改目標資料庫，則可能不會準確報告差異。如果其中一個應用程式將資料寫入目標資料表，而 AWS DMS 正在對該相同資料表執行驗證，則可能會發生此結果。 + 如果在驗證期間持續修改一或多個資料列，則 AWS DMS 無法驗證這些資料列。 + 如果 AWS DMS 偵測到超過 10，000 個失敗或暫停的記錄，則會停止驗證。請解決資料的任何基本問題，再繼續進行。 + AWS DMS 不支援檢視的資料驗證。 + AWS DMS 使用字元替換任務設定時， 不支援資料驗證。 + AWS DMS 不支援驗證 Oracle LONG 類型。 + AWS DMS 不支援在異質遷移期間驗證 Oracle Spatial 類型。 + 資料驗證會忽略資料表中資料遮罩轉換存在於資料表映射中的資料欄。 + 如果其 PK/UK 資料欄有資料遮罩轉換規則，資料驗證會略過整個資料表。驗證狀態會顯示為此類資料表沒有主索引鍵。 + 資料驗證不適用於 Amazon Aurora PostgreSQL Limitless。嘗試驗證無限資料庫中的資料表時，驗證狀態會顯示這些資料表的「無主索引鍵」。 如需使用 S3 目標驗證的限制，請參閱[使用 S3 目標驗證的限制](CHAP_Validating_S3.md#CHAP_Validating_S3_limitations)。 # Amazon S3 目標資料驗證 AWS DMS 支援驗證 Amazon S3 目標中的複寫資料。由於 會將複寫的資料 AWS DMS 儲存為 Amazon S3 中的一般檔案，因此我們會使用 [ Amazon Athena](https://docs.aws.amazon.com/athena/latest/ug/what-is.html) `CREATE TABLE AS SELECT`(CTAS) 查詢來驗證資料。 Amazon S3 中儲存之資料上的查詢需要大量運算。因此，在變更資料擷取 (CDC) 期間對 Amazon S3 資料 AWS DMS 執行驗證，每天只會在 UTC 午夜 (00：00) 執行一次。每個 AWS DMS 執行的每日驗證稱為*間隔驗證*。在間隔驗證期間， 會 AWS DMS 驗證過去 24 小時內遷移至目標 Amazon S3 儲存貯體的所有變更記錄。如需間隔驗證限制的詳細資訊，請參閱[使用 S3 目標驗證的限制](#CHAP_Validating_S3_limitations)。 Amazon S3 目標驗證使用 Amazon Athena，因此需支付額外費用。如需詳細資訊，請參閱 [Amazon Athena 定價](https://aws.amazon.com/athena/pricing/)。 **注意** S3 目標驗證需要 3.5.0 AWS DMS 版或更新版本。 **Topics** + [先決條件](#CHAP_Validating_S3_prerequisites) + [許可](#CHAP_Validating_S3_permissions) + [限制](#CHAP_Validating_S3_limitations) + [僅驗證任務](#CHAP_Validating_S3_only) ## S3 目標驗證先決條件 在使用 S3 目標驗證之前，請檢查下列設定和許可： + 將端點 [S3Settings](https://docs.aws.amazon.com/dms/latest/APIReference/API_S3Settings.html) 的 `DataFormat` 值設為 `parquet`。如需詳細資訊，請參閱[S3 的 Parquet 設置](CHAP_Target.S3.md#CHAP_Target.S3.EndpointSettings.Parquet)。 + 對於用來建立遷移任務的使用者帳戶，請確定指派給此帳戶的角色具有正確的許可集。請參閱以下[許可](#CHAP_Validating_S3_permissions)。 對於使用進行中複寫 (CDC) 的任務，請檢查下列設定： + 開啟補充記錄，讓您在 CDC 資料中擁有完整的記錄。如需開啟補充記錄的相關資訊，請參閱本指南中[疑難排解和診斷支援針對延時進行疑難排解](CHAP_Troubleshooting.md)一節中的[自動將補充記錄新增至 Oracle 來源端點](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Oracle.AutoSupplLogging)。 + 設定目標端點的 `TimestampColumnName` 參數。時間戳記的資料欄名稱沒有限制。如需詳細資訊，請參閱 [S3Settings](https://docs.aws.amazon.com/dms/latest/APIReference/API_S3Settings.html)。 + 為目標設定以日期為基礎的資料夾分割。如需詳細資訊，請參閱[使用日期型資料夾分割](CHAP_Target.S3.md#CHAP_Target.S3.DatePartitioning)。 ## 使用 S3 目標驗證的許可 若要為使用 S3 目標驗證設定存取，對於用來建立遷移任務的使用者帳戶，請確定指派給此帳戶的角色具有以下許可集。使用您自己的值來取代範例值。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:CreateWorkGroup" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "glue:CreateDatabase", "glue:DeleteDatabase", "glue:GetDatabase", "glue:GetTables", "glue:CreateTable", "glue:DeleteTable", "glue:GetTable" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetObject", "s3:ListBucketMultipartUploads", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ], "Resource": "*" } ] } ``` ------ ## 使用 S3 目標驗證的限制 檢視使用 S3 目標驗證時適用的下列其他限制。如需了解適用於所有驗證的限制，請參閱[限制](CHAP_Validating.md#CHAP_Validating.Limitations)。 + `DatePartitionSequence` 值需要「天」元件。S3 目標驗證不支援該 `YYYYMM` 格式。 + 當間隔驗證在 CDC 期間執行時，您可能會在 `awsdms_validation_failures_v1` 資料表中看到錯誤的驗證錯誤。發生這些錯誤是因為 會將間隔驗證期間抵達的變更 AWS DMS 遷移到次日的分割區資料夾。通常會將這些變更寫入當天的分割區資料夾中。這些錯誤是驗證從動態來源資料庫複寫到靜態目標 (例如 Amazon S3) 的限制。若要調查這些錯誤，請檢查接近驗證時段 (00:00 UTC) 結束的記錄，也就是通常會出現這些錯誤的時間。 若要將錯誤的數目降到最低，請確定任務的 `CDCLatencySource` 數量很少。如需監控延時的相關資訊，請參閱[複寫任務指標](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.Task)。 + `failed` 或 `stopped` 狀態中的任務不會驗證前一天的變更。若要盡量減少因未預期失敗而導致的驗證錯誤，請建立僅具有相同資料表對應、以及來源和目標端點的個別僅驗證任務。如需僅驗證任務的詳細資訊，請參閱[使用僅驗證任務搭配 S3 目標驗證](#CHAP_Validating_S3_only)。 + 資料表統計資料中的**驗證狀態**資料欄會反映最近一次間隔驗證的狀態。因此，具有不相符項目的資料表可能會在次日的間隔驗證後顯示為已驗證。檢查目標 Amazon S3 儲存貯體中的 `s3_validation_failures folder` 是否有超過一天前發生的不相符項目。 + S3 驗證使用 Amazon Athena 的儲存貯體資料表功能。這可讓 S3 驗證建立目標資料表資料的儲存貯體副本。這表示資料表資料的複本會分為符合 DMS 驗證內部分割的子集。Athena 儲存貯體資料表的限制為 100，000 個儲存貯體。S3 驗證嘗試驗證超過此限制的任何資料表都會驗證失敗。S3 驗證嘗試建立的儲存貯體數目等於下列項目： ``` (#records in the table) / (validation partition size setting) ``` 若要解決此限制，請增加驗證分割區大小設定，讓 S3 驗證建立的儲存貯體數量小於 100，000。如需儲存貯體的詳細資訊，請參閱《*Amazon Athena * [ Athena 使用者指南》中的 Athena 中的分割和儲存貯](https://docs.aws.amazon.com/athena/latest/ug/ctas-partitioning-and-bucketing.html)體。 + 資料表名稱不得包含特殊字元，底線除外。 S3 驗證使用不支援資料表名稱中特殊字元 （底線除外） 的 Amazon Athena。如需詳細資訊，請參閱《*Amazon Athena 使用者指南*》中的 [CREATE TABLE](https://docs.aws.amazon.com/athena/latest/ug/create-table.html) 主題。 + 當 AWS DMS 資料驗證功能與 AWS Lake Formation 管理的 Amazon S3 目標搭配使用時，驗證程序會失敗。這可能會導致資料一致性問題。 ## 使用僅驗證任務搭配 S3 目標驗證 *僅驗證任務*會對要遷移的資料執行驗證，而不執行遷移。 即使遷移任務停止，僅驗證任務仍會繼續執行，這可確保 AWS DMS 不會錯過 00：00 UTC 間隔驗證時段。 使用僅驗證任務搭配 Amazon S3 目標端點時有下列限制： + 支援啟用僅驗證設定的完全載入任務的 Amazon S3 驗證，但運作方式與其他端點的僅完全載入和驗證任務不同。對於將 S3 作為目標，此類型的任務只會根據 S3 目標中的完全載入資料進行驗證，而不會驗證任何在 CDC 遷移過程中遷移的資料。僅使用此功能來驗證僅限完全載入任務所建立的資料。使用此模式來驗證目標中的資料不會產生有效的驗證 (該目標中有執行的作用中 CDC 任務)。 + 僅驗證任務只會驗證自上次間隔驗證時段 (UTC 00:00) 以來的變更。僅驗證任務不會驗證前幾天的完全載入資料或 CDC 資料。 # AWS DMS 資料重新同步 AWS Database Migration Service (AWS DMS) 資料重新同步會自動修正透過來源和目標資料庫之間的資料驗證所識別的資料不一致。此功能可做為現有 DMS 遷移任務的一部分，確保根據您的任務組態、連線設定、資料表映射和轉換進行適當的更新。 資料重新同步功能的運作方式是從目標資料庫上的控制資料表讀取驗證失敗，並執行適當的修正操作。偵測到不相符時，會使用儲存在失敗記錄中的主索引鍵從來源擷取目前的資料，並套用到目標，同時遵守任何設定的轉換。如需詳細資訊，請參閱[`awsdms_validation_failures_v2` 控制資料表](CHAP_Validating.md#CHAP_DataResync.Troubleshooting.v2table)。 行為取決於您的遷移類型。對於full-load-only的任務，資料重新同步會在初始載入和驗證完成後執行一次。對於具有變更資料擷取 (CDC) 的任務，資料重新同步會根據設定的排程運作，在套用修正時暫時暫停複寫和驗證。 在 CDC 重新同步操作期間： + 複寫和驗證會暫時暫停。 + 資料重新同步會處理現有的驗證失敗。 + 正常複寫和驗證會繼續。 + 程序會根據您設定的排程重複執行。 資料重新同步會自動追蹤每個修正操作的狀態，並透過資料表統計資料提供詳細的指標。 **先決條件：** 資料重新同步功能需要下列先決條件： + 您必須擁有 AWS DMS 引擎版本 3.6.1 或更新版本。 + 您必須為正在進行複寫的任務設定排程和計時持續時間設定。僅完全載入任務不需要這些設定。 ## 限制 資料重新同步功能有下列限制： + 資料重新同步僅支援 Oracle 和 SQL Server 做為來源資料庫。 + 資料重新同步支援 PostgreSQL 和 Amazon Aurora PostgreSQL 相容引擎做為目標資料庫。 + 來源和目標資料庫中的所有資料表都必須有主索引鍵。驗證不支援沒有主索引鍵或唯一索引鍵的資料表。任何沒有有效主索引鍵或唯一索引鍵的資料表都會暫停驗證，而且不會報告驗證失敗。 + 執行Full-load-only任務時，必須啟用資料驗證。 + 無法為僅驗證任務啟用資料重新同步，因為它們不會複寫任何資料。您可以透過僅提供驗證 ，在父複寫任務上啟用重新同步`taskID`。如需詳細資訊，請參閱[僅驗證任務](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.ValidationOnly)。 + 如果僅驗證任務在任務設定中設定了`ControlSchema`參數設定，則複寫任務也必須具有相同的參數組態，資料重新同步才能找到正確的驗證失敗。 + 您必須設定 CDC 任務的排程和計時持續時間設定。 + 在重新同步時段期間，資料重新同步可能會影響 DMS 中的複寫延遲。 如需在資料重新同步 AWS DMS 期間對 中的驗證進行故障診斷的詳細資訊，請參閱[AWS DMS 資料驗證](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html)下的[故障診斷](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.Troubleshooting)一節。 ## 排程和計時 對於使用 CDC 的任務，您必須設定資料重新同步操作的時間和持續時間。這有助於防止對正常複寫操作造成影響。您可以指定： + 使用 Cron 格式來定義何時可能發生重新同步操作的排程。 + 確保重新同步操作不會延伸至尖峰使用期間的最大持續時間。 建議在離峰時間或來源資料庫最少或沒有變更的期間排程重新同步操作。 **注意** 排程時間包括等待目標套用串流為空，因為資料重新同步和正常複寫無法同時執行。 ## 使用案例 資料重新同步功能可讓使用者協調來源和目標系統之間的資料不一致。它可識別不相符的記錄並將其同步，以維持分散式環境的資料一致性。下列使用案例示範資料重新同步功能解決資料一致性挑戰的常見案例： **案例 1：完全載入任務 - 使用相同的 DMS 任務執行重新同步** 在現有的 DMS 完全載入遷移任務中，您可以執行下列動作： + 啟用驗證：`Validation with data migration = true`。 + 啟用重新同步： `Data resync = true` **案例 2：完全載入和 CDC，僅限 CDC 任務 - 使用相同的 DMS 任務執行重新同步** 在現有的 DMS CDC 遷移任務中，您可以執行下列動作： + 啟用驗證：`Validation with data migration = true`。 + 啟用重新同步： `Data resync = true` + 指定重新同步排程：`"ResyncSchedule": "0 0,2,4,6 * * *"`。 + 指定重新同步時間： `MaxResyncTime": 60` **案例 3：複寫和重新同步的完全載入和僅限 CDC 或僅限 CDC 任務，以及僅限驗證任務** 若要在使用重新同步時，在另一個 DMS 任務中僅執行驗證操作，您可以執行下列動作： + 僅建立驗證 DMS CDC 任務。 **注意** 在資料重新同步期間，您必須記下並指定此任務的 ID。 + 在主要 CDC 任務中，停用驗證：`Data validation = false`。 + 啟用重新同步： `Data resync = true` + 指定重新同步排程：`"ResyncSchedule": "0 0,2,4,6 * * *"`。 + 指定重新同步時間：`MaxResyncTime": 60`。 + 指定僅驗證 DMS CDC 任務的 ID。僅驗證任務 ID 會附加在 ARN 結尾。範例 ARN： `arn:aws:dms:us-west-2:123456789012:task:6DG4CLGJ5JSJR67CFD7UDXFY7KV6CYGRICL6KWI`和僅限範例驗證任務 ID：`6DG4CLGJ5JSJR67CFD7UDXFY7KV6CYGRICL6KWI`。 ## 最佳實務 您可以在 中利用資料重新同步功能 AWS Database Migration Service ，以提高複寫任務的耐久性並達到一致性。使用資料重新同步功能的一些最佳實務如下： + 作為資料重新同步的一部分，從來源擷取不相符的記錄並將其套用到目標資料庫，以修正不相符的記錄。如果在重新同步視窗期間更新來源資料庫，則重新同步會讀取最新的記錄值，並將其套用至目標。這可能會導致 CDC 套用事件失敗，並在目標資料庫 上引入暫時不一致。若要避免這種情況，您必須在來源資料庫上的變更為零或最小的非上班時間或期間排定重新同步時段。 + 在最少來源資料庫活動期間，以及在可接受的目標延遲閾值內設定重新同步時段。小型重新同步間隔可能會導致未處理的驗證不相符累積，而大型時段可能會在發生許多驗證失敗時增加複寫延遲。監控驗證失敗和重新同步率，以確定來源閒置期間的最佳重新同步時段。設定重新同步視窗的一些範例如下： + 多個短時段組態： ``` "ResyncSchedule": "0 0,2,4,6 * * *", "MaxResyncTime": 60 ``` + 每日單一時段組態： ``` "ResyncSchedule": "0 0 * * *", "MaxResyncTime": 360 ``` + 在重新同步時段期間監控 DMS 中的複寫延遲，並相應地調整排程以緩解大型峰值。 + 您可以透過資料表彈性或查詢目標 databadse 上的`awsdms_validation_failures_v2`資料表來檢閱重新同步結果。如需詳細資訊，請參閱[使用 Amazon CloudWatch 監控複寫任務](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Monitoring.html#CHAP_Monitoring.CloudWatch)。 + 當任務處於持續複寫階段時，請避免在重新同步時段期間啟動個別資料表的重新載入。 + CDC 複寫任務的最佳實務： + 資料庫中的所有資料表都會完成載入程序。 + 在進行中的驗證程序中會識別不相符項目。 + 根據重新同步排程時段，複寫任務會暫停一小段時間。 + 資料重新同步會修正驗證程序期間所引發的問題。 + 複寫程序會繼續並依照排程重複。 ## 資料重新同步組態和範例 **資料重新同步設定組態**： 您可以在 DMS 中為複寫任務設定重新同步。以下是任務中資料重新同步設定組態的範例： ``` "ResyncSettings": { "EnableResync": true, "ResyncSchedule": "0 0,2,4,6 * * *", // Run at 12AM, 2AM, 4AM, and 6AM daily "MaxResyncTime": 60, // Run for maximum of 60 minutes, or 1 hour "ValidationTaskId": "TASK-ID-IF-NEEDED" //Optional, used only if validation is performed as a separate Validation only task } ``` **常見重新同步排程模式的範例**： + `0 0 * * *`：每天午夜執行一次。 + `0 0,12 * * *`：每天午夜和中午執行兩次。 + `0 0,2,4,6, * * *`：在午夜到上午 6 點之間每兩小時執行一次。 + `0 1 * * 1`：每週一上午 1 點執行。 **注意** 您必須指定每天從 0 到 6 的數字。如需詳細資訊，請參閱 [Cron 表達式規則](#CHAP_DataResync.cron)。 **監控重新同步操作**： 您可以透過資料表統計資料監控重新同步操作。以下是輸出範例： ``` { "TableStatistics": { ... "ValidationFailedRecords": 1000, ... "ResyncRowsAttempted": 1000, "ResyncRowsSucceeded": 995, "ResyncRowsFailed": 5, "ResyncProgress": 99.5, // ratio of ResyncRowsSucceeded/ValidationFailedRecords "ResyncState": "Last resync at: 2024-03-14T06:00:00Z" } } ``` 若要在 中設定資料重新同步功能 AWS DMS，您可以檢閱各種重新同步參數及其個別的組態設定。如需詳細資訊，請參閱[資料重新同步設定](CHAP_Tasks.CustomizingTasks.TaskSettings.DataResyncSettings.md)。如需資料重新同步記錄設定的詳細資訊，請參閱 [記錄任務設定](CHAP_Tasks.CustomizingTasks.TaskSettings.Logging.md)。 ## 驗證和故障診斷 **驗證**： 啟用資料評估時， 會使用下列結構在目標資料庫中 AWS DMS 建立驗證失敗資料表： ``` CREATE TABLE awsdms_validation_failures_v2 ( "RESYNC_ID" bigint 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 ); ``` 您可以將查詢寫入此資料表，以了解找到的資料不相符項目，以及如何解決它們。 啟用驗證時， 會在目標資料庫中 AWS DMS 建立驗證失敗資料表。如果您有任何問題，您可以查詢`awsdms_control.awsdms_validation_failures_v2`資料表以了解找到的資料不符情況，以及如何解決。如需詳細資訊，請參閱[AWS DMS 資料驗證](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html)中的[疑難排解](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.Troubleshooting)一節。 **常見工作流程**： 在資料重新同步驗證期間，標準工作流程如下： **僅限完全載入任務**： 1. 資料庫中的所有資料表都會完成載入程序。 1. 在進行中的驗證程序中會識別不相符項目。 1. 資料重新同步會修正驗證程序期間所引發的問題。 1. 驗證程序會驗證更正。 1. 遷移任務已成功完成。 **CDC 任務**： 1. 資料庫中的所有資料表都會完成載入程序。 1. 在進行中的驗證程序中會識別不相符項目。 1. 根據重新同步排程時段，複寫任務會暫停一小段時間。 1. 資料重新同步會修正驗證程序期間所引發的問題。 1. 複寫程序會繼續並依照排程重複。 對任務所做的任何修改，例如在重新同步操作期間停止複寫任務，或重新載入並重新驗證資料表，都可能會影響任務的行為和結果。一些已知的行為變更如下所示： **當您在重新同步操作進行時停止複寫任務時**： + 重新同步操作不會自動繼續。您必須再次重新啟動它。 + 未來的重新同步操作會根據設定的排程進行。 + 任何未完成的修正都會在下一個重新同步排程視窗中嘗試。 **當您在資料庫中重新載入資料表**時： + 重新同步操作會略過任何正在重新載入的資料表。 + 系統會忽略已重新載入之資料表的先前驗證失敗。 + 新的驗證會在重新載入動作完成後開始。 **當您重新驗證資料庫中的資料表時**： + 重新同步操作的所有統計資料都會重設。 + 系統會忽略已重新驗證之資料表的先前驗證失敗。 **注意** 升級或移動任務至 DMS 3.6.1 版及更高版本時，不會重新同步`awsdms_control.awsdms_validation_failures_v1`資料表中的任何失敗。只會重新同步`awsdms_validation_failures_v2`資料表中的失敗。若要在`awsdms_control.awsdms_validation_failures_v2`資料表中重新同步失敗，您必須重新載入任務、重新載入任務中的一或多個資料表，或重新驗證一或多個資料表。如需詳細資訊，請參閱下列連結： 若要重新載入任務，請參閱 [`StartReplicationTask` API 參考](https://docs.aws.amazon.com/dms/latest/APIReference/API_StartReplicationTask.html)。 若要在任務中重新載入一或多個資料表，請參閱 *AWS CLI 命令參考*文件中[https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html)的 。 若要重新驗證一或多個資料表，請參閱 *AWS CLI 命令參考*文件中 [https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html)一節中的 `validate-only`選項。 . ## Cron 表達式規則 若要在 中的複寫任務期間設定資料重新同步操作 AWS DMS ，您可以使用 cron 表達式規則。這些規則可讓您自訂重新同步時段，並根據您的業務需求進行排程。您可以使用各種參數，例如分鐘、小時、天、月和星期幾。每個參數的 cron 表達式規則為： **分鐘**： + 分鐘範圍從 0 到 59。 + 您可以使用 (`-`)、`or`/`and` 來指定範圍。最多 10 個項目，以逗號 () 分隔`,`。 + **範例**： + `2-5` 等於 `2,3,5,5`。 + `1-2,3-4,5,7-10` 是有效的範圍。 + `1,2,3,4,5,6,7,8,9,10` 是有效的範圍。 + `1,2,3,4,5,6,7,8,9,10,11` 不是有效的範圍。重新同步操作會在第 10 個範圍項目之後略過。 + 您可以使用 (`*`)。範例： `*` 等於 `0-59`。 + 您只能將 (`/`) 與 (`-`) 或 () 搭配使用`*`。 **範例**： + `2-7/2` 等於 `2,4,6`。 + `*/15` 等於 `0,15,30,45`。 **小時**： 與「**分鐘**」相同，但有效範圍是從 `0`到 `23`。 **天**： + 與「**分鐘**」相同，但有效範圍是從 `1`到 `31`。 + 重新同步組態`L`支援使用 。它被解譯為當月的最後一天。您不得將其與另一個語法搭配使用。 **月：** 與「**分鐘**」相同，但有效範圍是從 `1`到 `12`。 **星期幾**： + 與「**分鐘**」相同，但有效範圍是從 `0`到 `6`。 + 您無法新增一週名稱的字串值。