您当前位置: 圣才学习网首页 >> IT类 >> Oracle专题

详解Oracle中的死联接检测技术

扫码手机阅读
用圣才电子书APP或微信扫一扫,在手机上阅读本文,也可分享给你的朋友。
评论(0
   
来源:网络 作者:未知
 
  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_TIME1但是一个孤儿进程很有可能在间隔到了之后被清除掉.
 
  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_SERVER16 TACE_DIRECTORY_SERVER<路径>;,跟踪文件svr_.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: cid0 opcode67 *bl0 *what1 uflgs0
 
  nsdo: nsctx: state8 flg0x621c mvd0
 
  nsdo: gtn93 gtc93 ptn10 ptc2048
 
  nsdoacts: entry
 
  nsdofls: entry
 
  nsdofls: DATA flags: 0x0
 
  nsdofls: sending NSPTDA packet
 
  nspsend: entry
 
  nspsend: plen10 type6
 
  nttwr: entry
 
  nttwr: socket 4 had bytes written10
 
  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_.trc 查看.
 
  了解DCD的问题和局限
 
  在很少的问题报告中,最值得注意的是DCDwindosNT下很差的性能,死联接只有在服务起重启或者数据库重启的情况下被清除. DCDNT下怎样正确的工作依靠客户端的协议. SQL*Net v2.3 比其他发行版改进了一些性能。
 
  见bug#303578
 
  在SCO Unix下,有个问题是DCD定时器到时后,服务进程死循环,消耗了大量的CPU资源,这个问题是由于不正确的信号处理造成的, 可以禁止DCD来解决
 
  见bug#293264
 
  如果只是客户应用结束,孤儿进程的资源不会被释放,只有当客户端重启之后, DCD才是放这些资源,例如, windows应用被杀掉,客户端仍在运行,探测包可以被收到,像进程仍然活动着一样被丢掉. 看起来好像DCD检测客户端机器,而不是客户端进程.
 
  见bug#280848
 
  DCD依靠探测包来检测联接,所以在半双工的网络协议中,这是不可能的,所以DCDAPPC/LU6.2 等半双工协议下不能用.
 
  内网联接是用BEQ协议不能支持DCD IPC协议可以使用
 
  DCD 在协议层是很消耗资源的,所以如果要用DCD来清除死进程,会加重系统的负担,任何时候,干净的退出系统,这是首要的。
 

小编工资已与此挂钩!一一分钱!求打赏↓ ↓ ↓

如果你喜欢本文章,请赐赏:

已赐赏的人
最新评论(共0条)评论一句