本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 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)。