oracle11g连接服务器失败怎么解决？，常见原因有哪些？

Oracle 11g连接服务器失败，绝大多数情况下问题出在监听器、防火墙和客户端解析这三个环节，按顺序排查基本都能解决。

不少人在使用Oracle 11g的时候遇到过同样的场景：数据库装在服务器上跑得好好的，客户端这边一连接就报错，要么是Ora-12541无监听程序，要么是Ora-12560协议适配器错误，还有的是连接超时，今天把这类问题从头到尾拆开讲清楚，照着步骤一步步来，比盲目重启数据库管用得多。

加载中

连不上 Oracle？问题就在 listener.ora！

IT微工场

218019-

原视频地址

oracle11g连接服务器失败的常见原因

连接失败这件事,业内专家指出，80%以上的情况并不是数据库本身崩了，而是监听器或者网络路径出了问题，先分清故障是“服务器端”还是“客户端”造成的，能省下大量排查时间。

先分清是“连不上”还是“连完就断”

• 客户端一敲连接命令,马上报错，多数是监听器没起来或者端口不通。
• 客户端等待很久之后才报错,通常是网络层面被拦截，比如防火墙丢包、安全组规则漏配。
• 连接成功后执行SQL时报错,才是数据库实例本身的问题，和“连接失败”是两个范畴。

服务端监听器的地位不能忽视

Oracle 11g的监听器是一个独立进程，它负责“接电话”，然后把请求转给数据库实例，如果监听器没有启动，客户端连接进来当然找不到入口，用lsnrctl status看一眼就能确认监听器的状态，这是排查工作的第一步，也是后续所有操作的基础。

网络层的隐性拦截

即便监听器正常运行,服务器防火墙、云安全策略也可能把1521端口挡在外面，尤其是现在越来越多公司把Oracle 11g部署在云服务器上，安全组规则与操作系统防火墙两道关卡都要检查，少了任何一处，连接依旧失败。

oracle11g连接超时的网络排查方法

连接超时,比报“无监听”更让人头疼，因为它不直接告诉你哪里被堵住了，这类问题要逐层剥离，从客户端到服务器的每一条链路都验证一遍。

tnsping的速度比你想象中更有用

在客户端命令行执行tnsping 服务器IP，如果返回“OK”且耗时很低，说明网络是通的，问题不在网络层，如果耗时超过几百毫秒甚至直接超时，那就要继续往下查。

telnet 1521端口是关键判断依据

拿Windows命令提示符举例,执行telnet 服务器IP 1521，如果光标停留在黑窗口中不动，说明TCP连接已经成功建立，如果提示“无法打开到主机的连接”，则意味着1521端口根本不可达，此时集中排查防火墙和安全组规则，这个方法能精准帮助判断“oracle11g连接超时”是因为端口被关还是服务没起来。

服务器本机验证防火墙策略

Linux服务器上先执行iptables -L -n | grep 1521，没有输出就说明没有放行1521端口，Firewalld体系下，用firewall-cmd --add-port=1521/tcp --permanent再重新加载，云服务器则要到控制台检查安全组入方向规则，添加上1521端口的TCP放行，多数情况下，安全组漏配是oracle11g连接超时的主要元凶。

oracle11g监听配置文件与常见修复

监听器的问题,很大比例集中在listener.ora这个文件上，Oracle 11g的监听配置文件位于$ORACLE_HOME/network/admin/目录下，内容并不复杂，但一个IP地址写错就能让所有客户端连接不到。

监听器起不来的报错为什么大多集中在listener.ora

如果用lsnrctl start启动监听时提示“监听程序未启动或服务未注册”，先打开listener.ora，重点看这四行：

• HOST指向的IP是否为服务器当前实际IP
• PORT是否为1521,而不是被人改成了其他端口
• GLOBAL_DBNAME是否与数据库实例名一致
• ORACLE_HOME路径是否配置正确

把HOST改成服务器实际IP后保存,执行lsnrctl reload重新加载配置，行业共识认为，修改监听地址后最好重启监听器，不要只执行reload，因为有时候监听器不重新读取全部参数。

hosts文件里的“隐藏坑”

服务器上的/etc/hosts（Windows是C:WindowsSystem32driversetchosts）如果存在错误映射，监听器对外公布的地址就会变成127.0.0.1，客户端根本找不到真正的服务器，用srvctl config listener或者直接看监听器日志就能发现这个问题，修复方法很简单，把主机名对应的IP改成服务器实际内网IP即可。

plsql无法远程连接oracle的客户端排查

很多用户最常问的“plsql无法远程连接oracle怎么排查”，其实答案并不在PL/SQL Developer这个工具本身，而在客户端网络配置文件tnsnames.ora中。

tnsnames.ora格式对不上，半天找不出来

打开客户端的tnsnames.ora，必须确保服务名、协议、主机、端口这四要素完全正确，经常有人把HOST写成服务器主机名而客户端DNS解析不了，或者SERVICE_NAME写成了SIDOracle 11g里两者并不总是相等，SERVICE_NAME多用于连接，SID是实例唯一标识。

正确格式大致长这样：

ORCL =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.100)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = orcl)
    )
  )

连接报Ora-12514无监听服务名时，优先检查SERVICE_NAME是否真的在服务器端存在，以sysdba登录服务器执行show parameter service_names，看到的值就是客户端应该填写的名称。

PL/SQL Developer设置里的“连接为”

在PL/SQL Developer登录界面，数据库栏位填的是tnsnames中的服务名别名，而不是IP加端口，有人把IP+端口直接塞进Database字段，反而引发连接报错，正确的做法是在下拉列表中选择事先配置好的服务名，用户名列写系统账号，角色选Normal或者SYSDBA，按实际权限判断。

Oracle 11g客户端与服务端的版本差异也比较常见，客户端是11g，服务器也是11g，基本没有问题，但如果客户端是较早的10g版本连11g服务器，协议版本不一致会导致PL/SQL Developer卡在登录界面，这时升级客户端驱动往往能直接解决问题。

本地连接oracle失败怎么解决？先看这三个快速兜底手段

如果服务端和客户端配置都检查过了,连接还是失败，以下三招能在短时间内定位出问题根源。

第一步：在服务器本机用sqlplus验证

直接登录到服务器,执行sqlplus / as sysdba，能成功进入说明实例正常，如果本机都无法登录，那就不是客户端网络问题，需要检查数据库进程是否存活、监听是否注册了实例服务。

第二步：查看监听器是否注册了实例

执行lsnrctl services，输出中应该能看到实例名称以及状态字段为READY的信息，如果实例在监听器中没有注册，客户端就连不上数据库，此时可以用alter system register手动触发实例向监听器注册。

第三步：检查sqlnet.ora的认证设置

Oracle 11g在某些服务器环境中，sqlnet.ora中的SQLNET.AUTHENTICATION_SERVICES配置值只写了NTS，而服务端未以Windows服务方式运行，就会导致本地连接都失败，把它注释掉或者改为NONE，重试即可。

常见报错查询对照表如下：

• ORA-12541 TNS：无监听程序，说明客户端根本访问不到监听器，检查监听是否启动、防火墙是否放行。
• ORA-12560 TNS：协议适配器错误，本机连接时实例未启动，或者Oracle服务未运行。
• ORA-12514 TNS：监听程序当前无法识别连接描述符中请求的服务，表明服务名写错或者未注册。

Oracle 11g连接服务器失败怎么办，最后还有一个笨办法

如果时间紧迫,把监听器重启一次能解决相当一部分疑难问题。lsnrctl stop然后lsnrctl start，虽粗暴但不少场景下确实管用，之后再在客户端执行tnsping，通过与否的结果就清晰了很多。

常见问题解答

问：oracle11g连接服务器失败，客户端要改哪些文件？

答：客户端关键文件是tnsnames.ora和sqlnet.ora，位置一般在Oracle客户端安装目录的network/admin下，tnsnames中定义服务名，sqlnet中配置连接方式，服务器端要改的是listener.ora和sqlnet.ora，绝大多数连接失败，修改tnsnames中的HOST和SERVICE_NAME就能解决。

问：跨网段连接Oracle 11g数据库总是不稳定，怎么处理？

答：跨网段场景下，先确认服务器和客户端之间是否存在防火墙策略限制，然后检查两端网络是否启用了TCP延时应答，必要时修改监听器配置，在其中加入SDU和TDU参数的调整，更直接的验证方式是使用tnsping测试网络往返时间，如果延迟持续过高，连接不稳定的问题通常不在数据库配置上，而在网络链路上需要协调网络管理员处理。

问：监听器状态显示已启动，但客户端报无监听器，是什么原因？

答：最可能的原因是监听器注册的IP地址和客户端访问的IP地址不一致，或者监听器只监听了IPv6地址，查看lsnrctl status中“Listening Endpoints Summary”部分，确认监听接口IP与客户端访问的IP一致，如果不一致，修改listener.ora中的HOST为实际IP并重启监听器。