DTS checks whether DTS servers can connect to the source database during the precheck to ensure successful data migration. This topic describes the possible causes of failed connectivity and how to fix the failure.

The following items show the possible causes of the failed source database connectivity during the precheck.

Invalid database account or password

Troubleshooting:

Find a server that can connect to the source database. On the server, enter the database account and password that are specified in the data migration task to check whether the account and password are valid.
Note You can also check the account and password on the server on which the source database is deployed.

Solution:

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

The IP address that is used to access the source database is disallowed to access the database

Troubleshooting:

  • You can enter the account and password that are specified in the data migration task on the server on which the source database is deployed and connect to the database. If the connection is successful, it indicates that the source database disallows the access from the IP address.
  • If the source 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 IP addresses of the DTS servers. For more information, see Add the CIDR blocks of DTS servers to the security settings of on-premises databases.

  • If the source database is an SQL Server database, check whether a firewall is set up for the server on which the database is deployed. In addition, check whether the endpoint or triggers in the source database disallows the access from the IP address.
  • If the source 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, it means that the source database disallows the access from the IP address.

Solution:

  • If the source database is a MySQL database, execute the following statement to reauthorize the database account. 
    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 source database is an SQL Server database, disable the firewall or triggers.
  • If the source 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 another precheck.

A firewall is configured for the server on which the source database is deployed

Troubleshooting:

  • If the server on which the source database is deployed runs on 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 source database is deployed runs on Linux, run the iptables -L command in the shell script to check whether a firewall is configured for the server.

Solution:

After you disable the firewall, log on to the DTS console to perform another precheck.

Network connections fail

If the connectivity item still cannot pass the precheck after the preceding troubleshooting, network connections between the DTS server and the source database may not function as expected. You can contact technical support in the DingTalk group (ID: 3685018060). To download DingTalk, click download DingTalk.