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

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, you must make sure that the remote host can establish a connection to the destination database.
Note You can also perform the check on the server where the destination database resides.

Solution:

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

Access restrictions of the destination database

Troubleshooting:

  • You can enter the database account and password specified for the data migration task on the server where the destination database resides. This allows you to check whether the server can connect to the destination database. If the server can connect to the destination database, the destination database may deny access from external IP addresses.
  • 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 where the database resides. You can also check whether endpoints or triggers in the destination database deny access from external IP addresses.
  • 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 external IP addresses.

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 where the destination database resides

Troubleshooting:

  • If the server where the destination database resides runs on Windows, find Windows Defender Firewall from the Control Panel to check whether a firewall is configured for the server.
  • If the server where the destination database resides runs on Linux, run the iptables -L command in the shell script 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 fails again after the preceding troubleshooting, check the network state between the destination database and the DTS server.