Check Details
Check objective
Verify that the source partitioned table meets the prerequisites for DTS synchronization, and ensure that the partition function parameter types, partition column constraints, and definitions of objects with the same name on the target side are consistent to avoid target-side table creation failures caused by unsupported types, missing constraints, or object conflicts.
Check content
|
Partition key type | Whether the partition function parameter type is within the supported range. | If not supported, the operation is blocked, and the system prompts to adjust the source partition key or exclude the table. |
Partition column inclusion | Whether the primary key/unique constraint of a partitioned table includes the partition column. | If the check fails, the operation is blocked, and the specific schema.table is located. |
Target same-name object conflict | When a partition function with the same name already exists in the target database, compare the parameter type, RANGE direction, and all boundary values. | If the definitions are consistent, the existing object is automatically reused. If the definitions are inconsistent, the operation is blocked without overwriting the customer's existing object, and a prompt is displayed to delete/rename the object, or align the definitions and retry. |
Potential issue
The partition key type is not supported. Adjust the partition key on the source side or exclude this table from the synchronization objects.
The primary key/unique constraint of the partitioned table does not include the partition column, so table creation on the target side will fail (schema.table).
A partition function with the same name already exists in the target database with an inconsistent definition, so the operation has been blocked to avoid overwriting existing customer objects.
Description
All partitions on the target side are placed in the PRIMARY filegroup, and the custom filegroup layout from the source side is not retained.
During migration/synchronization, suspend partition maintenance operations such as SPLIT/MERGE/SWITCH, because these operations do not go through row-level incremental replication.
Fixing Method
The partition key type is not supported: adjust the source partition key type to a supported type, or exclude the corresponding table from the synchronization objects and retry.
Partition column inclusion violation: Add the partition column to the primary key/unique constraint of the partitioned table on the source side (a SQL Server mandatory requirement), and then re-initiate the check after the constraint includes the partition column.
Target object name conflict: If the definitions are consistent, the existing object can be automatically reused and no action is required. If the definitions are inconsistent, delete or rename the existing partition function with the same name on the target side, or align the source partition function definition with the target side and retry. DTS does not overwrite existing customer objects.
Custom filegroup layout: Accept the unified use of the PRIMARY filegroup on the target side, or manually migrate partitions to the desired filegroup after synchronization is complete.
Partition maintenance operations: Suspend SPLIT/MERGE/SWITCH operations during migration/synchronization, and perform them only after synchronization is complete and stable.