Troubleshoot destination database connectivity precheck failures DTS-Data Transmission Service(DTS)-阿里云帮助中心

During the precheck, DTS verifies connectivity to the destination database. If this check fails, identify the cause below and apply the corresponding fix.

The destination database connectivity precheck can fail for the following reasons.

Incorrect database account or password

Detection method

From any device that can reach the destination database, connect using the account and password specified in the migration task to verify the credentials.

Note

You can also verify credentials directly on the destination database server.

Solution

In the DTS console, update the migration task with the correct account and password, then rerun the precheck.

Important

If the destination is a Tair or Redis instance, enter the password for the selected account. The account must have read and write permissions.

Default account (named with the instance ID): Enter the password directly.
New account: The password format is <custom_username>:<password>. For example, if the username for the Redis instance is admin and the password is Rp829dlwa, enter admin:Rp829dlwa as the database password.

Source IP restricted by the destination database

Detection method:

Connect to the destination database from its host server using the migration task credentials. If this succeeds, the database may be restricting the DTS source IP.
If the destination database is MySQL, connect with a MySQL client and run the following command.
```
SELECT HOST FROM mysql.user WHERE user='username',password='password';
```
Note
Replace username and password with the credentials configured in the migration task.

Check whether the authorized IP addresses include the DTS server IPs listed in IP address whitelist for on-premises sources.
If the destination database is SQL Server, check for a firewall on the host server and for any endpoints or triggers that restrict source IP addresses.
If the destination database is Oracle, check whether TCP.VALIDNODE_CHECKING is set to yes in the sqlnet.ora file. A value of yes means the database restricts source IP access.

Solution

If the destination database is MySQL, run the following command to grant permissions to the migration account.
```
GRANT ALL ON *.* TO 'username'@'%' IDENTIFIED BY 'password';
```
Note
Replace username and password with the credentials configured in the migration task.
If the destination database is SQL Server, disable the firewall or the trigger.
If the destination database is Oracle, change TCP.VALIDNODE_CHECKING to no and restart the process.

After applying the fix, rerun the precheck in the DTS console.

Firewall configured on the destination database server

Detection method:

If the server runs Windows, open Control Panel and check the Windows Firewall configuration.
If the server runs Linux, run iptables -L to check firewall rules.

Solution

Disable the firewall, then rerun the precheck in the DTS console.

Network connectivity issues

If the check still fails after you address the preceding causes, a network issue may exist between the DTS servers and your destination database.