Migration Operation Guide
Download
Focus Mode
Font Size
Scenarios
This document provides operational guidance on migrating data from SQL Server to TencentDB for SQL Server using the DTS data migration feature.
Preparations
DTS migration leverages the native SQL Server log shipping feature. The migration task performs a full backup and continuous log backups (every 2 minutes) on the source instance to ensure incremental synchronization to the target can proceed normally. Therefore, complete the following preparations before migration to ensure the task runs properly.
1. Read the Usage Instructions carefully to learn about feature constraints and must-knows.
2. Establish the access channel between DTS and the database in advance according to the access type you want to use. For details, see Network Preparations.
IDC self-built databases: The access method can be set to Public Network, Direct Connect (DC), VPN Access, and Cloud Connect Network (CCN).
Self-built databases on CVM: Select "Self-built on CVM" as the access method.
Tencent Cloud database instances: The access method can be set to Cloud Database.
3. Open port 445 for file sharing on the service hosting the source database.
4. The source database must be set to the "full recovery mode". It is also recommended that users perform a full backup themselves before migration.
5. The local disk space where the source database resides must be sufficiently large, and the remaining free space must be able to accommodate the size of the database to be migrated.
6. When the source instance is not a Tencent Cloud SQL Server instance (public network/CVM self-built instance) or is a Tencent Cloud SQL Server Basic Edition instance, you must use an account with sysadmin permissions on the target side for migration, and the account must be able to run the xp_cmdshell stored procedure. When the source instance is a Tencent Cloud SQL Server High Availability Edition or Cluster Edition instance, there are no permission restrictions on the target side account.
7. The SQL service startup account on the migration source must be changed to run under the built-in Local System account. There are no restrictions on the database account used for source migration, but it must have sysadmin permissions.
As shown in the figure, start the SQL service on the migration source. In the startup configuration, select Log on as and choose Built-in account, then modify it to run under Local System.
Note:
Restart the SQL Server service after the account is modified.
8. The source instance must have its configurations for full backup and log backup disabled. Otherwise, they will conflict with the automated log backup in the process, resulting in a discontinuous log chain and preventing incremental appends.
Environment Requirements
Note:
The system automatically performs checks against the following environmental requirements before starting a migration task. If a requirement is not met, the system reports an error. If users can identify the issue, they can refer to the Check Item Requirements to make modifications themselves. If they cannot, they should wait for the system check to complete and then modify according to the error message.
Type | Environment Requirements |
Source database requirements | Open port 445 for file sharing on the service hosting the source instance. The networks between the source and target databases can be connected. The server where the source database is located is required to have sufficient outbound bandwidth; otherwise, the migration speed is affected. |
Target database requirements | Only migration from the Basic Edition to High Availability editions (including Two-Node High Availability and Cluster Edition) is supported. Additionally, the version number of the target instance must be greater than that of the source instance. The target database cannot contain any database with the same name as the source database. The disk space of the target database should be larger than the size of the source database, at least 1.5 times the source database size. The target database must not be accessed or have any workload running on it. Otherwise, the migration will fail. |
Performing the Migration
1. Log in to the DTS console, select Data Migration in the left sidebar, and then click Create Migration Task to go to the migration task creation page.
2. On the migration task creation page, select the source instance type and region as well as the target instance type, region, and specification for migration, and then click Buy Now.
Configuration Item | Description |
Source Instance Type | Select based on your source database type. It cannot be modified after purchase. For this scenario, select "SQL Server". |
Source Instance Region | Select the region where the source database is located. If the source database is self-built, select the region closest to it. |
Target Instance Type | Select based on your target database type. It cannot be modified after purchase. For this scenario, select "SQL Server". |
Target Instance Region | Select the region where the target database is located. |
Specification | Only the fixed specification Medium is supported currently. |
3. On the Set Source and Target Databases page, complete the task configuration, source database configuration, and target database configuration. After the connectivity test between the source and target databases passes, click Create.
Note:
If the connectivity test fails, troubleshoot and resolve the issue according to the prompts and Troubleshooting Guide, and then try again.
Setting Type | Configuration Item | Description |
Task configuration | Task name | Specify a business-relevant name to facilitate task identification. |
| Running node | Immediate execution: The task will be started immediately once the task check passes. Scheduled execution: Configure when the task is executed. It will automatically start at the specified time. |
| Tag | Tags are used to categorize and manage resources from different dimensions. If the existing tags do not meet your requirements, go to the console to manage tags. |
Source database settings | Source database type | Source database type selected during purchase. It cannot be modified. |
| Region | Source database region selected during purchase. It cannot be modified. |
| Access type | Select the access type according to your scenario. For this example, set it to Cloud Database. For preparations related to different access types, see Preparation Overview. Public network: The source database is accessible through a public IP address. Self-built on CVM: The source database is deployed on Tencent CVM. DC: The source database can connect to Tencent Cloud Virtual Private Cloud (VPC) through DC. VPN access: The source database can connect to Tencent Cloud VPC through VPN Access. Cloud database: The source database is a TencentDB instance. CCN: The source database can connect to Tencent Cloud VPC through CCN. |
| Cross-account/intra-account | Intra account: The Tencent Cloud root account for both the source and target database instances is the same. Cross account: The Tencent Cloud root accounts for the source and target database instances are different. The following example uses migration within the same account. For cross-account operations, see Cloud Database Cross-Account Migration Guide. |
| Database instance | Select the ID of the source database instance. |
| Account | Database account for the source SQL Server. The account permissions must meet the requirements. |
| Password | Password for the source SQL Server database account. |
Target database settings | Target database type | Target database type selected during purchase. It cannot be modified. |
| Region | Target database region selected during purchase. It cannot be modified. |
| Access Type | Select the access type based on your scenario. For this scenario, set it to Cloud Database. |
| Database instance | Select the ID of the target database. |
| Account | Target database account. The account permissions should meet the requirements. |
| Password | The password for the account of the target database. |
4. On the Set Migration Options and Select Migration Objects page, configure the migration type and objects, and then click Save.
Configuration Item | Description |
Migration type | Select the migration type based on your scenario. Full migration: The entire database will be migrated. The migration includes only the data that exists in the source database when the task starts and excludes any new data written after the migration begins. Full + incremental migration: Both existing data in the source database at the start of the task and any new data written during the migration process are migrated. You can select this option if data is continuously written to the source database during migration, and a non-stop, hitless migration is required. |
Migration object | Only database-level migration is supported, meaning all objects in a specified database must be migrated together. Select the database to be migrated from the source database objects, and then move it to the selected objects box. |
5. On the check task page, perform the check. After the check task passes, click Start Task.
If the check task fails, you can see Pre-check Failure Handling to fix the issue and reinitiate a check task.
Failed: indicates that a check item fails and the task is blocked. Fix the issue and execute the check task again.
Warning: indicates that a check item does not completely meet the requirements, and the task can be continued, but the business may be affected. Users are required to assess whether to ignore the warning or fix the issue before continuing to execute the task based on the prompt.
6. Return to the data migration task list. The task enters the Ready-to-run status. After running for 1 to 2 minutes, the data migration task will officially start.
To view or delete a task, click the corresponding task and perform the operation in the Operation column. For details, see Task Management.
If a task reports an error, see Error Handling.
7. Assess whether the task needs to be ended.
Select Full Migration: The task automatically ends upon completion and does not need to be manually ended.
Select Full + incremental Migration: After the full migration is completed, the task automatically enters the incremental data synchronization phase. Incremental data synchronization does not end automatically. You need to manually click Complete to end incremental data synchronization after you verify that the migration results are correct. If service switching is required, see Switchover Instructions.
Post-Migration Operations
After the migration is completed using DTS, it is recommended that you perform the following checks on the target database:
Check permission integrity. Permissions affect the database plan. The migration only completes data recovery. Database users are restored. Other service-level permissions, such as logins, need to be recreated and associated with database accounts.
Rebuild indexes. After migration, the physical environment of data files is altered, and database index statistics are not updated promptly. Rebuild indexes to prevent potential database performance degradation.
Check instance-level objects. After migration, users need to rebuild them themselves.
Related APIs
Help and Support
Was this page helpful?
You can also Contact sales or Submit a Ticket for help.
Help us improve! Rate your documentation experience in 5 mins.
Feedback