☰

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

tag-icon • tag-icon oracle
TNS-12535：TNS：操作超时 -- Oracle DB

我发现我维护的 .Net 数据访问服务器中有很多查询超时。这似乎是完全随机的，与数据或数据锁无关。例如，以下查询超时了！

 SELECT NULL FROM DUAL

系统日志显示，发生此问题时 CPU 使用率为 20%，内存使用率为 42%，磁盘使用率为 3%。这是怎么回事？

HPUX 上的 DB 版本为 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

答案1

这个特定的错误以及它发生在所有针对数据库运行的应用程序中的事实强烈地表明网络故障是问题的根源。

  • TNS 别名如何解析？您是否使用本地 tnsnames.ora 文件？

  • 假设您使用的是本地 tnsnames.ora 文件，数据库的 TNS 别名使用的是 IP 地址还是主机名？使用 IP 地址可以省去 DNS 的麻烦，因此，如果问题是您的 DNS 服务器暂时失灵，那么尝试一下也是值得的。

  • 您还可以尝试配置备份侦听器并向 TNS 别名添加故障转移选项。如果问题是网络出现故障并随机丢失从客户端到侦听器通信的数据包，则可以使用可尝试的故障转移选项来解决绝大多数问题，而无需找出网络的哪个部分出现问题。当然，这假设问题能够快速自行纠正，以便下一次连接尝试成功，但这可能是一个合理的假设。如果添加备份侦听器可以解决问题，那么您几乎可以肯定这是网络问题。

答案2

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

事实证明，在将连接放回池之前对其进行了测试，而不是在将其拉出以供后续使用时进行测试。

在好日子里，你会遇到某种错误。在坏日子里，你只能等待使用一个完全混乱且永远无法正常工作的连接。

如果您要使用池，我读到的建议是针对会话执行 alter 命令。（不，我不知道有什么好的。Oracle 在手册中没有更清楚地说明）

布拉德

答案3

当以下条件成立时，我遇到了这个问题： - JDBC 客户端在 IP 为 ZZ.ZZ.ZZ.ZZ 的计算机上运行 - 数据库服务器有两个 NIC - 一个 IP 为 XX.XX.XX.XX，另一个 IP 为 YY.YY.YY.YY - JDBC 客户端 URL 指向 IP XX.XX.XX.XX，端口 1521 - 使用路由表，客户端 ZZ.ZZ.ZZ.ZZ 能够访问 XX.XX.XX.XX - 默认的“LISTENER”正在监听 YY.YY.YY.YY 端口 1521，（主机名解析为此 IP） - SPFILE 中的 LOCAL_LISTENER 参数为 NULL - 也就是说它从未设置过

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

答案4

虽然这只能治标不治本，而不能治愈您所患的网络堆栈疾病，但您可以尝试增加 inbound_connect_timeout 来查看问题是否消失。

要检查您现在正在运行的内容，请在数据库主机上调用 LSNRCTL 并发出以下命令：

显示入站连接超时

您必须在数据库主机的 sqlnet.ora 和 listener.ora 文件中更改此项：

sqlnet.ora：SQLNET.INBOUND_CONNECT_TIMEOUT = 100（假设 100 大于当前超时）

listener.ora: INBOUND_CONNECT_TIMEOUT_yourLIstenerNameGoesHere = 100

相关内容