Oracle alert日志中出现：‘Fatal NI connect error 12170’

按期检查数据库alert log信息，是咱们进行数据库平常维护、巡检和故障排除的重要工做手段。数据库系统“带病运行”、“负伤运行”每每是“小病致死”的主要杀手。所谓“防患于未然”就须要数据库管理员从平常的小事微情入手，时刻了解系统运行状况，并尽早进行处理。

本文主要介绍笔者使用Oracle 11gR2过程当中日志巡检中出现的问题，虽然最后没有获得圆满解决。记录下来，留待须要朋友待查。

一、问题说明

笔者使用的一套开发环境，数据库版本是11gR2，小版本号为11.2.0.4。

SQL> select * from v$version;

BANNER

--------------------------------------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

PL/SQL Release 11.2.0.4.0 - Production

CORE    11.2.0.4.0 Production

TNS for Linux: Version 11.2.0.4.0 - Production

NLSRTL Version 11.2.0.4.0 – Production

在巡检数据库alert log过程当中，发现一些错误提示。

Tue May 19 23:04:55 2015

*************************************

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

        TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production

  Time: 19-MAY-2015 23:04:55

  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: 110

    nt OS err code: 0

  Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=172.xx.xx.xx)(PORT=50741))

相同类型错误在日志中反复出现，天天出现频率在10条左右，区别在于每次的Host对应IP地址不一样。

二、问题分析

这类型错误在11gR2版本中常常出现。笔者以前的一些投产系统中，也经常出现这样的问题。当前进行开发的系统架构比较传统，是一个典型CS架构方式。客户端桌面应用是一个富客户端软件，全部业务逻辑都在客户端。客户端直接链接数据库。

这种架构方式是比较传统的方式，行业内对于这种方式的缺陷已经讨论不少年了。单从数据库角度看，这样的架构方式意味着更加多的数据库链接数量和更加频繁的访问结构。

利用IP地址，咱们能够从监听器日志listener.log中，能够定位到这个IP地址链接是何时链接过来的。

[oracle@localhost trace]$ pwd

/u01/app/diag/tnslsnr/localhost/listener/trace

[oracle@localhost trace]$ cat listener.log | grep 172. xx.xx.xx

19-MAY-2015 13:51:10 * (CONNECT_DATA=(CID=(PROGRAM=JDBC Thin Client)(HOST=__jdbc__)(USER=visvim))(SERVICE_NAME=sicsdb)) * (ADDRESS=(PROTOCOL=tcp)(HOST=172.xx.xx.xx)(PORT=50741)) * establish * sicsdb * 0

从MOS上的信息反馈看，这个类型错误提示是一种正常的Oracle工做机制。当客户端进程Client Process与服务器进程Server Process创建联系以后，二者就造成了“同生共死”的关系（专有链接模式）。除非客户端主动发起中断或者Server Process被异常kill。

在实际运行环境中，这种理想状态经常被打破。若是Client Process只是保持链接，不执行语句，会话就处于idle状态。这种链接很容易被诸如防火墙等网络层面设备切断。

在Oracle11gR2中，若是长期没有链接动做的Server Process被外力切断，Oracle就会自动将信息做为提示错误写入到alert log中，做为一种提示。在11R1版本中，这种信息是会写入到sqlnet.log中。

三、问题解决措施

概括MOS和网络中的各类方法，大致有两重策略，分别为使用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 trace]$ cd /u01/app/oracle/network/admin/

[oracle@localhost admin]$ ls -l

total 16

-rw-r--r--. 1 oracle oinstall  343 Sep  2  2014 listener.ora

drwxr-xr-x. 2 oracle oinstall 4096 Jun 16  2014 samples

-rw-r--r--. 1 oracle oinstall  381 Dec 17  2012 shrept.lst

-rw-r--r--. 1 oracle oinstall    0 Sep  2  2014 sqlnet.ora

-rw-r-----. 1 oracle oinstall  308 Sep  5  2014 tnsnames.ora

[oracle@localhost admin]$ cat sqlnet.ora 

[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监听器配置，或者重启监听器。

[oracle@localhost admin]$ lsnrctl reload

LSNRCTL for Linux: Version 11.2.0.4.0 - Production on 21-MAY-2015 10:13:34

Copyright (c) 1991, 2013, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521)))

四、结论

数据库“Fatal NI connect error 12170”问题，从本质上是因为长链接数据库交互方式形成的，严格意义上不该算什么错误问题。若是是一些三层架构体系应用，能够考虑使用链接池进行动态资源调配的方式，对问题进行缓解。

 

转发自：https://www.linuxidc.com/Linux/2015-05/118004.html