死联接检测(DCD)

死联接检测(DCD)

                                             Yikaikai
死联接检测DCD(Dead Connection Detection)是 SQL*NetV2.1 和此版本以后的一个新特性, 当它检测到对方 c/s 或者s/s 联接意外终止时, 释放相关占用的资源.

DCD 起初是专为客户机没有从会话中断开联接的情况下断电的环境设计的.
DCD由服务端开始建立联接. 这时候SQL*Net 从参数文件中读取变量, 设置一个定时器定时产生信号. 这个时间间隔是sqlnet.ora文件中的SQLNET.EXPIRE_TIME提供的.

  当定时器设定的时间到了之后, 服务器上的SQL*Net 发送一个探测包到客户端.(假如是数据库联接, 目的端的服务器发送探测包到另一端). 探测包是由空的SQL*Net包组成, 不体现SQL*Net层任何数据, 但会在下一层的网络协议中产生数据流量.
  假如客户端的联接仍然是活动的, 探测包被丢弃. 计时装置复位. 假如客户端异常断掉. 服务器将收到由发送探测包的调用发出的错误. SQL*Net 将会通知操作系统释放联接占用的资源.
在Unix服务器上 sqlnet.ora 文件必须存在$TNS_ADMIN 或者 $Oracle_HOME/network/admin目录下.   而不是/etc 或者 /var/opt/oracle
同时也应该注重, SQL*Net 2.1.x中一个活动的孤儿进程(例如, 单独的查询进程) 在查询完成之前不会被杀掉. SQL*Net 2.2中孤儿进程占用的资源将会被无条件释放.
这只是服务器的特性,  客户端将会支持任何SQL*Net V2 的发行版

  协议栈的功能
---------------------------

虽然死联接检测是在SQL*Net层的, 但要成功执行在很大程度上要依靠下层协议栈. 例如, 假如在sqlnet.ora文件中设置SQLNET.EXPIRE_TIME=1, 但是一个孤儿进程很有可能在间隔到了之后被清除掉.
TCP/IP协议是一个面向联接的协议, 同样的, 这个协议在超时时执行重传数据包的操作, 确保数据的安全和数据包的顺序. 假如对探测包没有及时回应, TCP/IP栈将在一段时间内重传这个包. 当TCP/IP放弃重传之后, SQL*Net 将会收到探测失败的通知.
  TCP/IP超时的时间取决于 TCP/IP栈,  超时很多分钟是很常见的, 这个涉及到很多客户, 许多协议层的重传会造成孤儿进程被杀掉之前要等很长时间.
  最简单的办法检测协议栈有这个延迟需要测试不同的DCD间隔.

测试协议栈
----------------------
设置参数SQLNET.EXPIRE_TIME = 1 min，注重清除孤儿进程需要的时间. 然后设置为 5min,
再次观察这个时间. 假如服务器没有释放资源是由于TCP/IP超时造成的, 清除影子的时间需要增加到4min.
假如TCP/IP超时重传是造成问题的所在, 操作系统的内核参数应该调整一下, 在Unix平台下, /usr/include/netinet/tcp_timer.h 中包含着配置参数.
减小重传间隔可能会影响系统的其它部分, 因为实际上减小了联接处理数据的窗口, 可能会在系统重负荷的情况下丢失联接, 远程慢的联接会受到这个更改的影响。
系统参数会影响超时重传的有 TCP_TTL, TCPTV_PERSMIN, TCPTV_MAX, 和 TCP_LINGERTIME等。

********************
为了防止对系统其他进程产生影响, 在调整系统参数时最好向相关的厂家咨询
*******************

监控死联接检测
------------------------
检测DCD是否打开和运行正常最好的方法就是产生一个服务跟踪文件, 查找 DCD探测包.
要产生一个服务跟踪文件, 在sqlnet.ora文件中设置TRACE_LEVEL_SERVER=16, TACE_DirectorY_SERVER=<路径>, 跟踪文件svr_<PID>.trc文件会在那个目录下产生.

DCD 是否打开？
在跟踪文件中查找:

        osntns: Enabling dead connection detection (1 min)
时间间隔应该和SQLNET.EXPIRE_TIME的一样.
DCD是否正常工作?
在跟踪文件中应该有类似:

        nstimexp: entry
        nstimexp: timer expired at 05-OCT-95 12:15:05
        nsdo: entry
        nsdo: cid=0, opcode=67, *bl=0, *what=1, uflgs=0x2, cflgs=0x3
        nsdo: nsctx: state=8, flg=0x621c, mvd=0
        nsdo: gtn=93, gtc=93, ptn=10, ptc=2048
        nsdoacts: entry
        nsdofls: entry
        nsdofls: DATA flags: 0x0
        nsdofls: sending NSPTDA packet
        nspsend: entry
        nspsend: plen=10, type=6
        nttwr: entry
        nttwr: socket 4 had bytes written=10
        nttwr: exit
        nspsend: 10 bytes to transport
        nspsend:packet dump
        nspsend:00 0A 00 00 06 00 00 00  ........
        nspsend:00 00 00 00 00 00 00 00  ........
        nspsend: normal exit
        nsdofls: exit (0)

        nsdoacts: flushing transport
        nttctl: entry
        nsdoacts: normal exit
        nsdo: normal exit
        nstimexp: normal exit

其中:

        nspsend:00 0A 00 00 06 00 00 00  ........
        nspsend:00 00 00 00 00 00 00 00  ........

代表探测包, 是由10个字节组成, 当协议头和尾被加上后，这个包大概有70个字节长,
假如DCD是打开的, 当定时器的时间到了之后，在跟踪文件里会看到探测包. 在Unix系统下，可以用:
tail -f svr_<PID>.trc 查看.

了解DCD的问题和局限
------------------------------
在很少的问题报告中，最值得注重的是DCD在windosNT下很差的性能, 死联接只有在服务起重启或者数据库重启的情况下被清除. DCD在NT下怎样正确的工作依靠客户端的协议. SQL*Net v2.3 比其他发行版改进了一些性能。
见bug#303578

在SCO Unix下, 有个问题是当DCD定时器到时后, 服务进程死循环, 消耗了大量的CPU资源, 这个问题是由于不正确的信号处理造成的,  可以禁止DCD来解决
见bug#293264
假如只是客户应用结束，孤儿进程的资源不会被释放, 只有当客户端重启之后, DCD才是放这些资源, 例如， windows应用被杀掉, 客户端仍在运行, 探测包可以被收到, 像进程仍然活动着一样被丢掉. 看起来似乎DCD检测客户端机器，而不是客户端进程.
见bug#280848

DCD依靠探测包来检测联接，所以在半双工的网络协议中, 这是不可能的, 所以DCD在APPC/LU6.2 等半双工协议下不能用.

内网联接是用BEQ协议不能支持DCD, IPC协议可以使用

DCD 在协议层是很消耗资源的, 所以假如要用DCD来清除死进程, 会加重系统的负担, 任何时候, 干净的退出系统，这是首要的.