listener 突发连接超时 业务都连接不上 Fatal NI connect error 12170

错误描述：

客户反应昨晚开始，所有应用都连不上库。偶在下lsnrctl指令返回的都是超时。

listener.log 的日志有4G大小，不过是去年的产生的，说明listener日志没有打开，这次连不上应该和监听日志过大没关系。这个时10g的版本，所以还在用listener.log ,11g后默认存放在 log.xml中超过10M会存放一个新的文件。

sqlnet.net中很这种信息如下，而且这个错误不是从昨晚开始的，以前一直有，每天都会产生一些，说明这个和突然连接不上没有直接关系.

Fatal NI connect error 12170.
  VERSION INFORMATION:
        TNS for IBM/AIX RISC System/6000: Version 10.2.0.4
.0 - Production
        TCP/IP NT Protocol Adapter for IBM/AIX RISC System/6000: Version 10.2.0.4
.0 - Production
  Time: 17-JUL-2018 09:38:58
  Tracing not turned on.
  Tns error struct:
    ns main err code: 12535
    TNS-12535: TNS:operation timed out
    ns secondary err code: 12560
    nt main err code: 505
    TNS-00505: Operation timed out
    nt secondary err code: 78
    nt OS err code: 0

状况：

ping 192.168.101.2 5  OK的

telnet 192.168.101.25 1521 不通

tnsping  xxx  是等待很久后显示超时

lsnrctl status  也是 等待很久后显示超时， 监听没有反应

lsnrctl stop  也是 等待很久后显示超时

看来lsnrctl 进程处于僵死状态了。

ps -ef|grep lsnrctl  监听进程存在，并传说中的没有两个进程问题

netstat -an| find "1521"

lsof -i tcp:1521 或者 ps -ef|grep ora|grep ora_|wc -l 看到有115个连接，说明已存在的连接时OK的，数据库本身服务正常，这和用户反馈的不一样。

处理：

1.先解决listener 无反应，不能新建连接的问题

os上杀掉监听进程，重新启动监听。可以连接上了, 需要观察这种情况是否还会再发生。

ps -ef|grep lsnr

kill -9 xxxx

lsnrctl start 

ps -ef|grep tns|grep -v grep |cut -c 9-15|xargs kill -9|lsnrctl start

2.sqlnet.log中的每天都有的超时错误（“Fatal NI connect error 12170”）


两中策略，分别为使用DCD和禁用ADR。

DCD全称Dead Connection Detection，是一种基于主动测探方式检查Oracle僵尸客户端进程Client Process的策略。配置DCD的关键是设置sqlnet.expire_time参数在SQL Net体系下，Oracle会依据这个时间间隔给所有的Client Process发送网络通信包，用来确定Client是否存活。

正是借助这个包通信，可以让防火墙认为这个网络连接还是处在active状态，不会进行强制断开动作。类似的机制还有Linux上的tcp keep live机制，也是使用类似的策略进行检查。

 [oracle@localhost admin]$ cat sqlnet.ora
sqlnet.expire_time=10

另一种方式也是Oracle推荐的，就是关闭11g的ADR机制。ADR（Automatic Diagnostic Repository）是Oracle进行自动诊断、自动提醒的工具组件。Oracle认为如果用户不需要在SQL Net组件中应用ADR，可以再sqlnet.ora中进行配置关闭。

 [oracle@localhost admin]$ cat sqlnet.ora
sqlnet.expire_time=10
DIAG_ADR_ENABLED = OFF
DIAG_ADR_ENABLED_LISTENER=OFF


之后，重新reload监听器配置，或者重启监听器。
数据库“Fatal NI connect error 12170”问题，从本质上是由于长连接数据库交互方式造成的，严格意义上不应算什么错误问题。如果是一些三层架构体系应用，可以考虑使用连接池进行动态资源调配的方式，对问题进行缓解。

备注:  listener 日志的开启、关闭与转存

      Oracle 监听日志有两种格式，一种是 xml 格式，一种是文本文件格式。 xml 格式的日志是 10M 一个，所以不存在单个文件过大的问题。

lsnrctl status 监听名称        # 查看监听日志位置

[oracle@tqsrv121 orcl]$ lsnrctl status

LSNRCTL for Linux: Version 12.2.0.1.0 - Production on 17-JUL-2018 11:09:50
Copyright (c) 1991, 2016, Oracle.  All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=172.17.59.150)(PORT=1522)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 12.2.0.1.0 - Production
Start Date                17-AUG-2017 13:53:02
Uptime                    333 days 21 hr. 16 min. 47 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /u01/oracle/orahomes/product/12.2.0/db_1/network/admin/listener.ora
Listener Log File         /u01/oracle/orahomes/diag/tnslsnr/tqsrv121/listener/alert/log.xml
Listening Endpoints Summary...                   

停止/开启监听日志记录功能

lsnrctl
set current_listener监听名称
set log_status off/on
exit

 转储文件
  可以切换到监听日志文件位置，直接重命名（如果确认不需要保留历史日志记录，可以删除）。
  然后重新打开日志记录功能，文件会自动生成。  

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/807718/viewspace-2157965/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/807718/viewspace-2157965/