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_;.trc文件會在那個目錄下產生.
DCD 是否打開？
在跟蹤文件中查找:
osntns: Enabling dead connection detection (1 min)
時間間隔應該和SQLNET.EXPIRE_TIME的一樣.
DCD是否正常工作?
在跟蹤文件中應該有類似： nstimexp: entrynstimexp: timer expired at 05-OCT-95 12:15:05nsdo: entrynsdo: cid=0, opcode=67, *bl=0, *what=1, uflgs=0nsdo: nsctx: state=8, flg=0x621c, mvd=0nsdo: gtn=93, gtc=93, ptn=10, ptc=2048nsdoacts: entrynsdofls: entrynsdofls: DATA flags: 0x0nsdofls: sending NSPTDA packetnspsend: entrynspsend: plen=10, type=6nttwr: entrynttwr: socket 4 had bytes written=10nttwr: exitnspsend: 10 bytes to transportnspsend:packet dumpnspsend:00 0A 00 00 06 00 00 00 ........nspsend:00 00 00 00 00 00 00 00 ........nspsend: normal exitnsdofls: exit (0)nsdoacts: flushing transportnttctl: entrynsdoacts: normal exitnsdo: normal exitnstimexp: 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的問題和局限
在很少的問題報告中， 最值得注重的是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來清除死進程, 會加重系統的負擔, 任何時候, 干凈的退出系統， 這是首要的。
