CentOS 7配置同网段Oracle连接遇ORA-12170 TNS超时问题求助

Hey there, let's work through that ORA-12170 timeout error you're hitting when connecting to your Oracle DB from CentOS 7. I’ve tackled this exact scenario a bunch of times, so here’s a step-by-step breakdown of what to check:

1. Verify Basic Network Connectivity First #

Timeout errors almost always start with network issues, so let’s rule those out first:

• Ping the Oracle DB server to confirm your client can reach it:
  ping 192.167.10.100
  If this fails, you’ve got a routing/subnet problem—check your server’s subnet mask, VLAN settings, or physical network links between the two servers.
• Test if the default Oracle listener port (1521) is open and reachable:
  nc -zv 192.167.10.100 1521
  If this times out, either the listener isn’t running on the DB server, or a firewall is blocking traffic to that port.

2. Check the Oracle Listener on the DB Server #

Reach out to your DB admin (or log into the DB server if you have access) to verify the listener is up and configured correctly:

• Run this to check listener status:
  lsnrctl status
  Look for two key things:
  • The listener shows as READY (not stopped or blocked)
  • The "Listening Endpoints Summary" includes the DB’s IP (192.167.10.100) and port 1521
• If the listener is down, start it with:
  lsnrctl start

3. Confirm Your Client Environment Variables Are Active #

You mentioned setting the variables, but let’s make sure they’re actually loaded in your current shell session:

• Run these commands to validate:
  echo $ORACLE_HOME (should return /usr/lib/oracle/12.2/client64)
  echo $PATH (should include $ORACLE_HOME/bin)
  echo $LD_LIBRARY_PATH (should have $ORACLE_HOME/lib)
  echo $TNS_ADMIN (should point to /usr/lib/oracle/12.2/client64/network/admin)
• If any variable is missing, re-source your profile file (e.g., source ~/.bashrc or source /etc/profile depending on where you set them) and recheck.

4. Fix the SQL*Plus Implicit Connection String Syntax #

A common mistake with EZConnect (implicit) strings is missing the // prefix or using the wrong service name. Use this exact format:
sqlplus your_username/your_password@//192.167.10.100:1521/your_db_service_name

• Critical note: Use the database’s service name, not the SID. To get the correct service name, have the DB admin run:
  SELECT name FROM v$database;
  Or check the listener status output under "Services Summary".

5. Check Firewall and SELinux Settings on Both Servers #

Firewalls and SELinux are frequent culprits for timeout errors:

On your CentOS 7 client server: #

• Check if firewalld is blocking outbound traffic to port 1521:
  sudo firewall-cmd --list-all
• If no rule allows traffic to 192.167.10.100:1521, add a temporary rule to test:
  sudo firewall-cmd --add-port=1521/tcp --add-source=192.167.10.100/32
sudo firewall-cmd --runtime-to-permanent (to make it permanent if it works)
• Check SELinux status:
  sestatus
  If it’s enforcing, temporarily set it to permissive to test:
  sudo setenforce 0
  If this fixes the issue, you can add a permanent SELinux rule (though allowing the port via firewalld is usually sufficient for most setups).

On the Oracle DB server (192.167.10.100): #

• Ensure the firewall allows inbound traffic on port 1521 from your client IP (192.167.15.123):
  sudo firewall-cmd --add-port=1521/tcp --add-source=192.167.15.123/32
sudo firewall-cmd --runtime-to-permanent
• Also verify SELinux isn’t blocking listener connections if the DB server runs CentOS/RHEL.

6. Test with a TNSNAMES.ORA File (Optional but Diagnostic) #

If EZConnect still fails, creating a tnsnames.ora file can help isolate syntax issues. Create the file in your $TNS_ADMIN directory with this content:

ORCL_CONNECTION =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.167.10.100)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = your_db_service_name)
    )
  )

Then connect using:
sqlplus your_username/your_password@ORCL_CONNECTION
If this works, the issue was likely with your EZConnect string format.

Start with the network and listener checks first—9 times out of 10, ORA-12170 is a network/firewall/listener problem, not a client configuration issue.

内容的提问来源于stack exchange，提问作者Andres Felipe Polo