Oracle Net是负责实现从客户端到服务器的重要组件。在连接和保持通信过程中，Oracle Net都是担负着重要的职责。在实际运维环境中，一些连接和通信故障，都需要对于Oracle Net进行相应的调整控制工作。

进入11g之后，Oracle的alert log职能是在不断的强化过程。ADR（Automatic Diagnostic Repository）的引入，将Oracle各个关键组件，如监听器、数据库日志和Grid等告警跟踪信息进行重组，以信息库的形式加以组织。同时，除了原有的运行过程核心信息，一些提示内容也会出现在alert log中。所以，作为运维人员，定期关注或者监控alert log中的关键信息，可以帮助我们提高性能，解决日常运维问题。

 

1、问题说明

 

笔者管理的一套业务系统，尚在开发测试阶段。系统本身架构比较简单，属于CS两层架构，客户端程序直接连接数据库服务器进行数据交互。Oracle数据库版本为11.2.0.4。

 

 

Starting up:

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

With the Partitioning, OLAP, Data Mining and Real Application Testing options.

Windows NT Version V6.1 

CPU                 : 4 - type 8664, 4 Physical Cores

Process Affinity    : 0x0x0000000000000000

 

 

在数据库巡检过程中，看到alert log中反复出现Oracle Net报错提示。

 

 

Mon Jul 14 17:15:54 2014

 

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

Fatal NI connect error 12170.

 

  VERSION INFORMATION:

   TNS for 64-bit Windows: Version 11.2.0.4.0 - Production

   Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.2.0.4.0 - Production

   Windows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.2.0.4.0 - Production

  Time: 14-JUL-2014 17:15:54

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

    nt OS err code: 0

  Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=172.17.22.43)(PORT=58793))

 

 

该类型提示不断出现在alert log中，区别在于每次的client对象IP地址端口有区别。

 

2、问题分析

 

提示信息出现的主要时间段就是白天工作时间，提示的主机IP地址经查就是测试用户IP。系统客户端非IE，以JDBC方式连入到数据库中。Oracle ADR在11g中会自动将很多警告信息写入到alert log中。

从报错信息看，Fatal NI connect error 12170是与Oracle Net和TCP/IP网络相关。这个报错信息内容上，是Oracle强制断开了与客户端的连接关系，终止会话过程。

Oracle Client Process与Server Process是典型的一对一关系。在独占连接模式下，Client Process发起连接请求，通过监听器建立起与Server Process的关系，此后两者的关系就是“同生共死”管理。正常情况下，只有在Client Process主动终止连接的情况下，Server Process才会进行连接断开动作。在主动中断的过程中，Client Process会存在一个终止信息回写的动作。

在一些特殊的情况下，是可能出现异常中断情况的。例如Client Process异常中断、无响应或者在网络层面切断。此外，一些网络防火墙设置也会自动的将长期闲置（或者认为闲置）的连接切断。

如果客户端与服务器长期保持连接关系，比如使用PL/SQL Developer或者CS客户端直连，两者之间没有数据传递。一些防火墙会自动监控这些闲置连接，如果闲置时间很长，防火墙会将这些连接自动打断。而且，长期运行的查询语句和JDBC方式连入的连接，出现断开的几率更高。

以随机从alert log中找到的一条报警记录为例进行分析。

 

Mon Jul 14 17:21:38 2014

 

 

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

 

Fatal NI connect error 12170.

 

  VERSION INFORMATION:

   TNS for 64-bit Windows: Version 11.2.0.4.0 - Production

   Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.2.0.4.0 - Production

   Windows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.2.0.4.0 - Production

  Time: 14-JUL-2014 17:21:38

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

    nt OS err code: 0

  Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=172.18.9.4)(PORT=3067))

 

 

几个关键信息需要注意，首先系统报错信息是在下午五点二十分左右发生的。也就是说，这个死链接是Oracle在这个时间点发现的。那么这个链接是什么时候建立起来的呢？

Oracle监听器是负责所有远程连接的中介组件。在运行日志listener.log中，我们可以发现连接信息。

 

14-JUL-2014 14:29:12 * (CONNECT_DATA=(CID=(PROGRAM=JDBC Thin Client)(HOST=__jdbc__)(USER=zhangsan))(SERVICE_NAME=sicsdb)(CID=(PROGRAM=JDBC Thin Client)(HOST=__jdbc__)(USER=zhangsan))) * (ADDRESS=(PROTOCOL=tcp)(HOST=172.18.9.4)(PORT=3067)) * establish * sicsdb * 0

 

 

注意：进行这种查询操作，使用host IP地址外加端口号是最简单快速的方法。这里面，我们需要澄清一下这个port端口。我们连入服务器的时候，也有一个端口号，那个是监听器端口。Oracle服务器端，监听器伺候在特定端口等待请求连接。这个端口默认是1521。

但是，我们检查listener.log信息，可以发现确定的连接端口却没有事1521的。这个说明：在监听器起到中介作用，通知Oracle实例Instance建立Server Process与Client Process之间关系之后，监听器就不再承担职责了。后续如身份验证等操作，都是Client与Server直接进行沟通。两者之间的端口，就不是1521了，而是重新分配的一个端口。

在一些Oracle古老版本中，还有对于1521端口共用的一些特性。随着防火墙技术的发展和Oracle自身的变化，这个特性已经不需要了。

从listener.log信息片段看，这个链接是从下午14:29创建出的。也就是说，链接持续了三个小时后，被异常中断。

分析其他连接轨迹，的确可以发现所有连接均是维持2-3小时之后，被强制断开。这种情况，就有理由认为是客户端主机或者网络中防火墙自动清理连接功能的作用。

在Oracle端，解决方法就是采用Oracle Net DCD（Dead Connection Detect）来进行症状缓解。

 

3、Oracle DCD

 

Oracle DCD是一种通信查探技术，引入特性的初衷是解决死链接标记回收问题。一个Server Process对应一个Client Process，如果出现异常中断的情况或者Client Process异常死亡。Server Process就需要进行事务回滚和资源回收。

DCD的原理很简单，就是在Server与Client建立连接之后，以一个固定的周期从Server端给Client发送一个空消息。如果通信线路正常，并且Client Process状态正常，会自动回复，这样就确定了当前连接状态正常。如果连接失败，Oracle会将这个Server Process进行标记，交由服务器端进行回收。

DCD对于长时间连接被断开现象的意义在于：以固定的频率维持Client与Server的通信，这样让防火墙的等网络保护设备不会将这个连接认为为死链接强制断开。

配置DCD的方法比较简单，也是围绕sqlnet.ora参数文件进行。

 

 

--sqlnet.ora

# This file is actually generated by netca. But if customers choose to

# install "Software Only", this file wont exist and without the native

# authentication, they will not be able to connect to the database on NT.

 

SQLNET.AUTHENTICATION_SERVICES = (NTS)

SQLNET.EXPIRE_TIME = 5

 

 

重新加载监听器参数，之后启动生效。默认情况下，我们是不能看到发送空消息记录的。通过启动Oracle Net Service的监听机制，我们是可以查看到空数据包发送动作的。

 

4、结论

 

配置DCD，可以在一定程度上缓解由于长时间连接中断造成的报错问题。同时也可以排除发现潜在前端应用在数据库连接方面的故障和问题。

http://blog.itpub.net/17203031/viewspace-1227656