Fatal NI connect error 12170 TNS-12535 TNS-00505

                  Fatal NI connect error 12170 TNS-12535 TNS-00505

今天一位朋友遇到这个错误,每2个小时长时间运行的存储过程就断开,一开始怀疑PROFILE或者RESOURCE PLAN限制。
但是大家都明白,一般很少用这些,特别是资源计划,拿到报错后如下:
Fatal NI connect error 12170.

  VERSION INFORMATION:
TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
Windows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
  Time: 27-1月 -2015 15:43:45
  Tracing not turned on.
  Tns error struct:
    ns main err code: 12535
    TNS-12535: TNS: 操作超时
    ns secondary err code: 12560
    nt main err code: 505
    TNS-00505: 操作超时
    nt secondary err code: 60
    nt OS err code: 0
  Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.47.98.172)(PORT=60611))
  这里的
  nt secondary err code: 60 可能随着系统的不同而不同
Linux x86 or Linux x86-64: "nt secondary err code: 110"
HP-UX : "nt secondary err code: 238"
AIX: "nt secondary err code: 78"
Solaris: "nt secondary err code: 145"

对于这样的错误在11G以前是不计入alert日志的,但是11G后 Automatic Diagnostic Repository (ADR)记录,其实可以通过如下方法进行屏蔽掉:
To revert to Oracle Net Server tracing/logging, set following parameter in the server's sqlnet.ora :
DIAG_ADR_ENABLED = OFF
Also, to back out the ADR diag for the Listener component, set following parameter in the server's listener.ora:
DIAG_ADR_ENABLED_ = OFF
   - Where the would be replaced with the actual name of the configured listener(s) in the listener.ora configuration file.  For example, if the listener name is 'LISTENER', the parameter would read:
DIAG_ADR_ENABLED_LISTENER = OFF

上述报错原因如下:
This issue can arise during a long running query or when using JDBC Thin connection pooling. 
If there is no data 'on the wire' for lengthy,This would indicate an issue with a firewall 
here a maximum idle time setting is in place.
The alert.log message indicates that a connection was terminated AFTER it was established to the instance.  
In this case, it was terminated 2 hours and 3 minutes after the listener handed the connection to the database. 
 也就是他出现在长期的操作或者使用连接池的时候,并且设置了防火墙,并且2小时会进行中断一次。
解决办法如下:
The non-Oracle solution would be to remove or increase the firewall setting for maximum idle time.  
In cases where this is not feasible, Oracle offers the following suggestion:
The following parameter, set at the **RDBMS_HOME/network/admin/sqlnet.ora, can resolve this kind of problem.  
DCD or SQLNET.EXPIRE_TIME can mimic data transmission between the server and the client during long periods of idle time. 
SQLNET.EXPIRE_TIME=n  Where is a non-zero value set in minutes.  
在ORACLE级别可以设置SQLNET.EXPIRE_TIME参数,如果设置为2,可以2分钟发起一次探测,发送最小的探测包来保证连接之间有流量,
而不至于被防火墙中断。当然也可以设置防火墙的最大IDLE TIME。

参考:
Fatal NI Connect Error 12170, 'TNS-12535: TNS:operation timed out' Reported in 11g Alert Log (文档 ID 1286376.1)
Alert Log Errors: 12170 TNS-12535/TNS-00505: Operation Timed Out (文档 ID 1628949.1)

时间: 2024-10-23 10:27:33

Fatal NI connect error 12170 TNS-12535 TNS-00505的相关文章

Alert Log中“Fatal NI connect error 12170”错误

Alert Log中"Fatal NI connect error 12170"错误 Fatal NI connect error 12170.     VERSION INFORMATION:         TNS for Linux: Version 11.2.0.4.0 - Production         Oracle Bequeath NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production      

Alert Log中“Fatal NI connect error 12170”错误问题

  定期检查数据库alert log信息,是我们进行数据库日常维护.巡检和故障排除的重要工作手段.数据库系统"带病运行"."负伤运行"往往是"小病致死"的主要杀手.所谓"防患于未然"就需要数据库管理员从日常的小事微情入手,时刻了解系统运行情况,并尽早进行处理. 本文主要介绍笔者使用Oracle 11gR2过程中日志巡检中出现的问题,虽然最后没有得到圆满解决.记录下来,留待需要朋友待查.   1.问题说明   笔者使用的一套开发

TNS - 12516 TNS : 解决

报错 TNS - 12516 TNS : listener could not find instance with matching protocol stack   根据官方的文档说是processes和sessions参数设置的问题.已经达到了最大值.索引监听拒绝连接,这个时候监听例程是blocked的,确实如此如下: 服务 "libaodb" 包含 1 个例程.   例程 "libaodb", 状态 READY, 包含此服务的 1 个处理程序...    

oracle提示Alert Log Errors: 12170 TNS-12535/TNS-00505: Operation Timed Out

客户反馈系统经常报会话超时,导致应用测试无法正常进行,经检查alert日志发现 Fatal NI connect error 12170.     VERSION INFORMATION:         TNS for HPUX: Version 11.2.0.4.0 - Production         Oracle Bequeath NT Protocol Adapter for HPUX: Version 11.2.0.4.0 - Production         TCP/IP

【Oracle】 inbound connection timed out (ORA-3136)

早上突然接到监控报警WARNING: inbound connection timed out (ORA-3136). ora-3136 连接超时在大部分情况下是可以忽略的,这个错误一般是由于客户端由于没有使用正确登录的密码,连接超时导致. 比如下面的例子: oracle@rac1:/home/oracle>sqlplus yang/yan@yangdbstd  SQL*Plus: Release 11.2.0.1.0 Production on Wed Sep 21 10:47:35 2011

oracle中ORA-3136,ORA-609

Fatal NI connect error 12170.   VERSION INFORMATION: TNS for 64-bit Windows: Version 11.2.0.1.0 - Production Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production Windows NT TCP/IP NT Protocol Adapter for 64-bit Wind

20171120关于INBOUND_CONNECT_TIMEOUT设置

[20171120]关于INBOUND_CONNECT_TIMEOUT设置.txt --//上午翻看以前我的发的帖子,发现链接:http://www.itpub.net/thread-2066758-1-1.html --//今天再仔细看了一下,注意看了一下别人的回复,才发现一些细节问题,原始链接: --//http://www.cnblogs.com/kerrycode/p/5224483.html 关于sqlnet.ora的参数SQLNET.INBOUND_CONNECT_TIMEOUT,它

TNS-12535 TNS-00505的处理方法

硬件说明: 操作系统版本:ORACLE LINUX 6.3  64位 数据库版本:11.2.0.3   64位   问题说明: 在检查数据库的alert日志的时候,发现大量的12170和TNS-12535的错误: Fatal NI connect error 12170.     VERSION INFORMATION:     TNS for Linux: Version 11.2.0.3.0 - Production     Oracle Bequeath NT Protocol Adapt

小麦苗BLOG文章索引

小麦苗BLOG文章索引            自从2014年7月1号开始写blog到2015年5月5日,历时10个月的时间,大概写了90篇文章,这blog多了就乱了,今天抽空出来整理整理,方便大家也方便自己阅读,本文将一直更新,另外,最后我把所有的blog文章全列出来,可能会有用.    小麦苗的所有文章:itpub文章链接-小麦苗.zip     2015年06月03日更新一次,我写的blog数量:109 篇    2015年07月03日更新一次,我写的blog数量:126 篇    2016