使用Dead Connection Detection（DCD）避免Oracle會話被防火牆強制斷開

sundog315發表於2013-03-08
Oracle會話防火牆
1個系統，採用了Oracle的分散式事務來保證分散式系統的事務一致性，但是，該系統在某次搬遷之後，經常出現分散式事務鎖，必須手工查詢
select local_tran_id||||state,1 from dba_2pc_pending
來查詢發生錯誤的事務，然後進行強制提交或強制回滾
架構的問題先不說，單單是因為一次搬遷，就導致大量的問題。那必須要找到問題，應用才能恢復正常。
問題可能出在網路防火牆，為了降低防火牆的資源利用率，網路部門設定瞭如果連線超過半小時，則斷開該連線。透過標準程式，已經可以確認此問題。但是，DBLINK是否使用長連線？超時時間是多少？
這裡需要引入一個Oralce的功能DCD，具體內容請參見:
Resolving Problems with Connection Idle Timeout With Firewall [ID 257650.1]
Dead Connection Detection (DCD) Explained [ID 151972.1]
其實，就是在sqlnet.ora檔案中配置：
sqlnet.expire_time = 10
數字單位為分鐘，上面的配置即空閒10分鐘後檢測連線狀態，這個檢測是從伺服器端主動發起，傳送一個10位元組的空包。
配置好了，如何測試呢？可以按照Oralce的文件
How to Check if Dead Connection Detection (DCD) is Enabled in 9i ,10g and 11g [ID 395505.1]
來檢測，當然，也可以用簡單的方式來檢測，這裡我用tcpdump來從網路層面檢測資料庫傳遞情況
tcpdump host 10.199.81.33(伺服器IP)
14:14:51.592696 IP 10.199.81.33.ncube-lm > BJS1-012.13179: P 4066:4076(10) ack 3491 win 154
14:14:51.592739 IP BJS1-012.13179 > 10.199.81.33.ncube-lm: . ack 4076 win 176
14:24:51.660498 IP 10.199.81.33.ncube-lm > BJS1-012.13179: P 4076:4086(10) ack 3491 win 154
14:24:51.660540 IP BJS1-012.13179 > 10.199.81.33.ncube-lm: . ack 4086 win 176
14:34:51.736100 IP 10.199.81.33.ncube-lm > BJS1-012.13179: P 4086:4096(10) ack 3491 win 154
14:34:51.736152 IP BJS1-012.13179 > 10.199.81.33.ncube-lm: . ack 4096 win 176
從這幾行可以看出，每隔10分鐘，伺服器端主動傳送探測包，這樣就可以讓連線處於活動狀態，避免被防火牆強制斷開。
[@more@]

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/19423/viewspace-1060271/，如需轉載，請註明出處，否則將追究法律責任。

相關文章