Destination database connectivity - Data Transmission Service

To ensure successful data migration, Data Transmission Service (DTS) checks whether DTS servers can connect to the destination database during the precheck. This topic describes the causes of check failures and how to troubleshoot the failures.

A data migration task may fail to pass the connectivity check due to the following reasons.

Invalid database account or password

Troubleshooting:

You can check whether the database account and password for the data migration task are valid from a remote host. In this case, make sure that the remote host can establish a connection to the destination database.

Note

You can also perform the check on the server on which the destination database resides.

Solution:

Log on to the DTS console, enter a valid database account and password, and then perform a precheck again.

Important

If the destination database is a Tair instance or an ApsaraDB for Redis instance, you need to enter the password in the correct format based on the type of the account selected. The account must have the read and write permissions on the database.

If you use the default account, whose username is the same as the instance ID, enter only the password.
If you use a custom account, enter the password in the <username>:<password> format. For example, if the custom username of the account for an ApsaraDB for Redis instance is admin and the password is Rp829dlwa, enter admin:Rp829dlwa as the password.

Access restrictions of the destination database

Troubleshooting:

You can enter the database account and password specified for the data migration task on the server on which the destination database resides. This allows you to check whether the database account and password are valid. If the database account and password are valid, the destination database may deny access from the CIDR blocks of DTS servers.
If the destination database is a MySQL database, you can use a MySQL client to connect to the database and execute the following statement:
```
SELECT HOST FROM mysql.user WHERE user='username',password='password';
```
Note
Replace the username and password parameters with the database account and password that are specified for the data migration task.
Check whether the authorized IP address list includes the CIDR blocks of DTS servers. For more information, see Add the CIDR blocks of DTS servers to the security settings of on-premises databases.
If the destination database is an SQL Server database, check whether a firewall is configured for the server on which the destination database resides. You can also check whether endpoints or triggers in the destination database deny access from the CIDR blocks of DTS servers.
If the destination database is an Oracle database, check whether the TCP.VALIDNODE_CHECKING item in the sqlnet.ora configuration file is set to yes. If the item is set to yes, the destination database denies access from the CIDR blocks of DTS servers.

Solution:

If the destination database is a MySQL database, execute the following statement to authorize the database account again:
```
GRANT ALL ON *.* TO 'username'@''%' IDENTIFIED BY 'password';
```
Note
Replace the username and password parameters with the database account and password that are specified for the data migration task.
If the destination database is an SQL Server database, disable the firewall or triggers.
If the destination database is an Oracle database, set the TCP.VALIDNODE_CHECKING item to no and restart the process.

Log on to the DTS console to perform a precheck again.

Firewalls configured for the server on which the destination database resides

Troubleshooting:

If the server on which the destination database resides runs Windows, find Windows Defender Firewall from the Control Panel to check whether a firewall is configured for the server.
If the server on which the destination database resides runs Linux, run the iptables -L command in the shell to check whether a firewall is configured for the server.

Solution:

Disable the firewall, and then log on to the DTS console to perform a precheck again.

Network failures

If the connection to the destination database still fails after the preceding troubleshooting, check the network status between the destination database and DTS servers.