TNS-12535: TNS:超时操作-- Oracle DB

Question

我看到很多来自.Net数据访问服务器的查询，我保持超时。它看起来完全是随机的，与数据或数据锁没有关系。例如，下面的查询超时了！

 SELECT NULL FROM DUAL 

系统日志显示，CPU占CPU的20%，内存占42%，磁盘占3%。怎么一回事？

DB是HPUX上的10.2.0.3.0版本。ODP驱动程序为2.111.6.20 (11g驱动程序)。

我检查了sqlnet.log并发现了大量的错误消息：

***********************************************************************
Fatal NI connect error 12170.

  VERSION INFORMATION:
        TNS for HPUX: Version 10.2.0.3.0 - Production
        Oracle Bequeath NT Protocol Adapter for HPUX: Version 10.2.0.3.0 - Production
        TCP/IP NT Protocol Adapter for HPUX: Version 10.2.0.3.0 - Production
  Time: 29-JUN-2009 06:42:04
  Tracing not turned on.
  Tns error struct:
    ns main err code: 12535
    TNS-12535: TNS:operation timed out
    ns secondary err code: 12606
    nt main err code: 0
    nt secondary err code: 0

Answer 1

特定的错误以及所有针对数据库运行的应用程序都会发生这种情况，这将强烈地指出网络问题是问题的根源。

• TNS别名是如何解决的？您正在使用本地tnsnames.ora文件吗？
• 假设您使用的是本地tnsnames.ora文件，则数据库的TNS别名是否使用IP地址或主机名？使用IP地址不需要访问DNS，因此可能值得尝试一下，以防您的DNS服务器出现短暂故障。
• 还可以尝试配置备份侦听器并向TNS别名添加故障转移选项。如果问题是网络中断并随机丢失了从客户端到侦听器通信的数据包，那么可以尝试的故障转移选项可以解决绝大多数问题，而不需要弄清楚网络的哪个部分会变坏。当然，这假设问题的纠正速度足够快，以便下一次连接尝试成功，但这可能是一个合理的假设。如果添加备份侦听器解决了问题，您几乎可以肯定这是网络问题。

Answer 2

我发现关闭连接池更可靠。我遇到了你描述的几种情况。

结果发现，在将连接放回池之前对其进行了测试，而不是将它们拉回池供后续使用。

在好的一天，你会犯某种错误。在糟糕的一天，你会挂起等待使用一个完全混乱的连接，而且永远不会起作用。

如果要使用池，我阅读了对会话执行alter命令的建议。(不，我不知道有什么好的。甲骨文并没有在手册中说得更清楚)

布拉德

Answer 3

当下列条件成立时，我遇到了这个问题：- JDBC客户端运行在带有IP ZZ.ZZ的机器上-数据库服务器有两个NICs一个带有IP XX.XX，另一个带有YY.YY- JDBC客户机URL指向IP XX.XX，端口1521 -使用路由表，客户端ZZ.ZZ能够到达XX.XX-默认的“侦听器”正在侦听YY.YY端口1521，(主机名解析到此IP) -- SPFILE中的LOCAL_LISTENER参数为NULL --即它从未被设置过。

我通过执行以下操作解决了这个问题：-停止侦听器(lsnrctl stop) -更改LISTENER.ORA以侦听XX.XX(而不是主机名默认的YY.YY)-在TNSNAMES.ORA中添加了一个条目来设置本地侦听器(LISTENER =(.)，本质上是LISTENER.ORA中使用的条目的副本)--在spfile中添加了一个参数LOCAL_LISTENER =侦听器(ALTER .SCOPE=SPFILE) -重新启动侦听器(lsnrctl )-重新启动数据库