To ensure successful data migration, DTS checks whether DTS servers can connect to the destination database during 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.

The database account or password is invalid

Troubleshooting:

You can check whether the database account and password for the data migration task are valid from a remote host. However, 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.

The destination database disallows access from external IP addresses

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 disallow 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 run the following command:
    SELECT HOST FROM mysql.user WHERE user='username',password='password';
    Note Replace the username and password 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 disallow 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 disallows access from external IP addresses.

Solution:

  • If the destination database is a MySQL database, run the following command to authorize the database account again:
    GRANT ALL ON *. * TO 'username'@''%' IDENTIFIED BY 'password';
    Note Replace the username and password 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.

A firewall is 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 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.

The network is unavailable

If the task still fails to pass the connectivity check after the troubleshooting, the network between DTS servers and the destination database may be unavailable. You can contact technical support by submitting a ticket.