如果使用 telnet 打开连接，但在客户端中挂起，则可能的问题是堡垒 IP 地址路由。在虚拟机上，于终端中输入 ip route。查看是否可以找到使用辅助 nic（nic1，即 DB_SUBNETWORK_GATEWAY IP 地址）将连接路由到 Cloud SQL 实例专用 IP 地址的路由规则。
可能的原因：服务连接不接受来自 Database Migration Service 的端点连接。服务连接包含一个已接受的项目列表，但 Database Migration Service 项目未包含在该列表中。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-03。"],[[["\u003cp\u003eMigration jobs can encounter recoverable errors, such as incorrect source database passwords, which allow for automatic resumption upon correction.\u003c/p\u003e\n"],["\u003cp\u003eUnrecoverable errors, like those related to data replication, require a manual restart of the migration job after the issues are resolved.\u003c/p\u003e\n"],["\u003cp\u003eWhen a migration job fails, its status changes to \u003ccode\u003eFailed\u003c/code\u003e, with a substatus reflecting the point of failure, and troubleshooting involves reviewing error messages and consulting Cloud Monitoring logs.\u003c/p\u003e\n"],["\u003cp\u003eConnectivity issues with either the source or destination databases are common errors, often stemming from incorrect settings or the inability to reach the bastion host.\u003c/p\u003e\n"],["\u003cp\u003eMany errors occur due to an incorrectly configured source, therefore consulting the documentation for "Configure your source Oracle database" is recommended when troubleshooting.\u003c/p\u003e\n"]]],[],null,["# Diagnose issues in Oracle to Cloud SQL for PostgreSQL migrations\n\nThis page lists known errors and recommended troubleshooting steps for:\n\n- [Errors encountered during the migration job](#mj-errors)\n\n- [Issues encountered when establishing network connectivity](#connectivity-issues)\n\n- [Errors encountered when working with Oracle SCAN](#troubleshoot-scan)\n\nMigration job errors\n--------------------\n\nThe migration job process might incur errors during runtime.\n\n- Some errors, such as a bad password on the source database, are recoverable. The migration job resumes automatically after these errors are fixed.\n- Some errors are unrecoverable, such as errors in data replication. You must restart the migration job after these errors are fixed.\n\nWhen an error occurs, the migration job status changes to `Failed`, and the\nsubstatus reflects the last status before failure.\nTo troubleshoot an error, navigate to the failed migration job to view the\nerror, and follow the steps outlined in the error message.\nTo view more details about the error, navigate to Cloud Monitoring by using\nthe link on the migration job. The logs are filtered to the specific migration job.\n\nIn the following table, you can find some examples of issues and how they can be solved:\n\nConnectivity issues\n-------------------\n\nThis section lists and describes troubleshooting steps for potential\nnetwork connectivity issues.\n\n### Unable to connect to the destination database: EOF\n\nRunning a connectivity test returns the `[DATABASE] unable to connect to the destination database: EOF` error message.\n\n**Possible cause:** The service attachment is configured incorrectly.\n\n**Things to try:** Make sure that `enable_proxy_protocol` is set to\n`false` in the\n[service attachment Terraform configuration file](/database-migration/docs/oracle-to-postgresql/configure-dst-connection-private-ip#non-psc).\nProxy protocol is supported only for HTTP servers such as NGINX and Apache.\n\nWhen using `gcloud` to create the Private Service Connect setup, the proxy protocol is disabled by default.\n\n### Connection timeout, connection refused\n\nRunning the connectivity test fails or times out. This is most likely caused by\nmisconfigured routing within the Private Service Connect setup.\nThere can be several reasons for this problem.\n\n**Possible cause:** There's a missing firewall rule that allows the\nPrivate Service Connect NAT CIDR range to access the\nPrivate Service Connect subnet where the bastion is located,\nspecifically the bastion VM `nic0` interface.\n\n**Things to try:** Make sure your organization policy doesn't restrict internal\nfirewall rules, such as the `psc_sp_in_fw` firewall rule defined in\nthe example Terraform script for\n[configuring destination private IP connectivity for non-PSC enabled Cloud SQL instances](/database-migration/docs/oracle-to-postgresql/configure-dst-connection-private-ip#non-psc).\n\n**Possible cause:** The proxy is down. There is no listener on the supplied port,\nand therefore the connection hangs.\n\n**Things to try:** You can try to establish an SSH connection to the bastion VM,\nand search for the proxy using the following command:\n\n- `netstat -tunalp | grep PORT`\n\nAnalyze the responses to the command:\n\n- If you get an empty response, the proxy is down. Try running the following\n commands:\n\n `sudo su; cd /` and check if the Dante server is installed by\n running `sudo dpkg -s dante-server`:\n - If the proxy is installed, you get the following message:\n\n `Status: install ok installed`\n - If the proxy isn't installed, the probable issue is a missing router. Add a router and check if you can download the proxy by running `apt-get install dante-server`.\n\n | To learn how to add a router, check how the `psc_sp_ex_router` and `psc_sp_ex_router_nat` resources are added in the `main.tf` file in [Configuring destination private IP connectivity for non-PSC enabled\n | Cloud SQL instances](/database-migration/docs/oracle-to-postgresql/configure-dst-connection-private-ip#non-psc).\n- If the proxy is running and listening on the supplied port, try opening a connection to it by doing the following:\n\n 1. Install the PostgreSQL client:\n\n `sudo apt-get install postgresql-client`.\n 2. Connect to the PostgreSQL database:\n\n `psql -h 127.0.0.1 -p `\u003cvar translate=\"no\"\u003ePORT\u003c/var\u003e` -U `\u003cvar translate=\"no\"\u003eDBUSERNAME\u003c/var\u003e` -W` (you will be prompted to enter the password).\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003ePORT\u003c/var\u003e: the database port number.\n - \u003cvar translate=\"no\"\u003eDBUSERNAME\u003c/var\u003e: the username used to connect to the PostgreSQL database.\n 3. Install the telnet client:\n\n `sudo apt-get install telnet`\n 4. Connect to the telnet client:\n\n `telnet 127.0.0.1 `\u003cvar translate=\"no\"\u003ePORT\u003c/var\u003e\n\n Replace \u003cvar translate=\"no\"\u003ePORT\u003c/var\u003e with the database port number.\n\n Depending on the results of the commands:\n - If the commands fail to open a connection, try looking at the proxy logs to locate the root cause. The root cause can vary depending on the Cloud SQL instance setup.\n\n - If the connection is opened using telnet but hangs in the client, the probable issue is the bastion IP address routing. On your VM, type `ip route` in the terminal. See if you can locate a routing rule that routes connections to the Cloud SQL instance private IP address using the secondary `nic` (`nic1`, the `DB_SUBNETWORK_GATEWAY` IP address).\n\n**Possible cause:** The service attachment doesn't accept the endpoint connection coming from Database Migration Service. The service attachment holds a list of projects which are accepted, and the Database Migration Service project isn't included in the list.\n\n**Things to try:** To resolve the issue, try either of the following:\n\n- In the Google Cloud console, go to **Private Service Connect**.\n\n [Go to Private Service Connect](https://console.cloud.google.com/net-services/psc)\n\n On the **Published services** tab, accept the connection from Database Migration Service\n for your service attachment (if it's pending).\n- Add the requesting project to the allowlisted projects on the service attachment\n (if it's rejected).\n\n - For more information about adding an allowlisted project in Terraform, see\n [Terraform documentation](https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/compute_service_attachment#consumer_reject_lists).\n\n - For more information about adding an allowlisted project in `gcloud`,\n see\n [Google Cloud CLI reference documentation](/sdk/gcloud/reference/alpha/compute/service-attachments/create#--consumer-accept-list).\n\n If this doesn't solve the issue, recreate the connection profile.\n- [Delete the connection profile](/database-migration/docs/oracle-to-postgresql/manage-connection-profiles#delete_a_connection_profile) associated with the\n Private Service Connect connectivity, and recreate it.\n\nTroubleshoot Oracle SCAN errors\n-------------------------------\n\nThis section describes potential issues you might have when migrating from Oracle Real Application Clusters (RAC) sources using the Single Client Access Name (SCAN) feature.\n\n### Unable to establish connectivity to an Oracle SCAN database\n\nRunning the connectivity test fails or times out.\n\n**Possible cause:** You might be trying to establish connectivity directly to your Oracle SCAN source database. Database Migration Service doesn't support direct connectivity to databases using the SCAN feature in Oracle RAC environments.\n\n**Things to try:** To resolve the issue, try either of the following:\n\n- Connect directly to one of the nodes.\n\n- Use the [Oracle Connection Manager](https://docs.oracle.com/en/database/oracle/oracle-database/19/netag/configuring-oracle-connection-manager.html#GUID-E599547C-2AE3-4383-93A4-DC45C707467D).\n\n- Create a private connectivity configuration using a reverse proxy solution such as HAProxy."]]
