在跟踪文件中应该有类似:
   

nstimexp: entry
nstimexp: timer expired at 05-OCT-95 12:15:05
nsdo: entry
nsdo: cid=0, opcode=67, *bl=0, *what=1, uflgs=0
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_<ID>;.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来清除死进程, 会加重系统的负担, 任何时候, 干净的退出系统， 这是首要的.