TUXEDO超時控制全功略(zt)

背景：

 

解決客戶以下問題：

資料庫版本9206，中介軟體BEA tuxedu。客戶反映在業務中有分散式事務的時候，查詢dba_pending_transactions檢視會被hang住，直到分散式事務處理完成，這樣造成資料庫連線堵塞，影響業務的正常使用。

參考以下資料：

 

連結：http://dev2dev.bea.com.cn/bbs/yuanch/ArticleShow.jsp?Id=39

作者：姜曉亮 (dev2dev ID: xljiang)
摘要：
本《功略》集中了TUXEDO應用中，可能涉及到的所有時間引數，並分別對其進行詳細描述，不但對其出處、取值等基本屬性進行查證，而且，通過分析其內在的控制機制，給出設定建議，以期能夠達到透徹理解、方便查閱、準確使用的目的。

1 前言
金融、電信等眾多行業的綜合營業系統中，廣泛使用了TUXEDO交易中介軟體，用來處理大量併發的聯機事務處理（OLTP）業務。典型的OLTP業務，每筆業務的資訊量較小，而且，具有一定的實時性，對時間的要求非常嚴格。
TUXEDO，聯絡著DATABASE和客戶端軟體，憑藉其多層次的超時控制機制，達到客戶端快速響應，伺服器端穩定可靠的效果。
TUXEDO的多層次的超時控制機制中，涉及到的時間引數不少於10個，再加上與之緊密聯絡的DATABASE中的幾個超時引數，確實比較複雜。遺憾的是，目前還沒有的專門的文件對它們進行詳細說明，而是分散在不同的專題中分別說明，而且，不同的專題中，解釋的詳細程度也不一樣，在查閱過程中，多有不便。
本文試圖將這些引數集中起來，對每一個都加以詳細說明，並試圖解釋每個引數存在的原因。大部分引數時間長短的設定，除個別外，基本沒有固定的模式，只要瞭解它們的具體含義，並結合具體應用系統的實際要求，相信大家都能夠作出合理的配置。

2 全功略解讀
2.1 SCANUNIT
2.1.1 引數出處
UBBCONFIG配置檔案 -> RESOURCES -> SCANUNIT 。
2.1.2 時間單位
秒,且必須為5的倍數。
2.1.3 取值範圍
大於0小於等於60中5的倍數，即｛5，10，15，20，25，30，35，40，45，50，55，60｝。
2.1.4 預設取值
10 。
2.1.5 用途解釋 ⑴
這個引數大家都會用，比較好理解，TUXEDO中，BBL是用來對Bulletin Board進行管理和監控的系統程式，它基於時間片的輪詢方式，時間片的大小就是SCANUNIT的值，SCANUNIT是Tuxedo對系統進行管理的最基本時間單位。每隔SCANUNIT，BBL對Bulletin Board進行一次檢查，看看有沒有超時的事務或阻塞的服務請求。後面講到的很多時間引數都是以SCANUNIT為單位。
2.1.6 超時後果
僅僅是個輪詢時間單位而已，到時間就輪詢，如此而已。
2.1.7 設定考慮
作為一個涉及到整個TUXDO系統的基本單位時間，如果業務需要，對時間引數控制比較嚴格，設定為5也不算小。如果系統業務對時間要求不嚴格，那就大點兒，60也沒什麼不可以；畢竟頻繁輪詢是要耗費更多系統資源的，而任何對資源的不必要的消耗都是浪費。

2.2 SANITYSCAN
2.2.1 引數出處
UBBCONFIG配置檔案 -> RESOURCES -> SANITYSCAN 。
2.2.2 時間單位
SCANUNIT 。
2.2.3 取值範圍
1 ～32767 。
2.2.4 預設取值
大約120/SCANUNIT。
2.2.5 用途解釋 ⑵
進行系統健全性檢查，主要包括Server程式狀態和Bulletin Board資料結構，檢查Server程式是否存活，如果已經不存在，會清理Bulletin Board中相應的資料項及IPC資源，並根據引數配置決定是否重新啟動，如果設了RESTART=Y，所佔的Message Queue不會被清除，Queue中的Request得到保留，仍會被處理。如果是MP模式，BBL還會給DBBL髮狀態訊息。
2.2.6 超時後果
僅僅是個系統健康檢查的間隔時間而已，到時間就檢查，如此而已。
2.2.7 設定考慮
作為一個涉及到整個TUXDO系統健康檢查的間隔時間，如果系統處在一個穩定的執行環境中，網路、資料庫、應用都很穩定，那這個引數可以大一些；如果執行環境不穩定，系統繁忙，而且Server程式經常因異常（如超時）而死掉，那就設定小一些。設定的原則和SCANUNIT一樣：不要隨意浪費系統資源。

2.3 BBLQUERY
2.3.1 引數出處
UBBCONFIG配置檔案 -> RESOURCES -> BBLQUERY。
2.3.2 時間單位
SCANUNIT
2.3.3 取值範圍 ⑶
BBLQUERY必須大於等於SANITYSCAN，tmloadcf 時會強制檢查，如果設的值小於SANITYSCAN，tmloadcf會自動調整為SANITYSCAN。
2.3.4 預設取值
大約300/SCANUNIT。
2.3.5 用途解釋 ⑷
BBL檢查，在MP模式下，BBL會每隔一段時間都傳送了" I am ok "心跳資訊給DBBL，這個間隔就是BBLQUERY。
2.3.6 超時後果 ⑸
如果DBBL在規定時間間隔內沒有收到某個BBL的資訊，DBBL它會主動傳送Request給那個BBL，判斷其是否正常。（如果等了DBBLWAIT後仍然沒有回覆，DBBL會認為那臺機器有問題，然後，將其隔離。）
2.3.7 設定考慮
此設定僅僅在MP模式下才起作用。
在MP模式下，如果TUXEDO系統需要對不穩定的執行環境可能發生的故障作出快速的反應，那麼BBLQUERY要設定小一些，讓系統快速的自我檢查。考慮網路傳輸時間、系統反應速度等因素，網路速度越慢，系統負載越重，取值越大；反之亦然。
如果系統執行環境很穩定，利用其預設值即可，甚至可以更大數值。

2.4 DBBLWAIT
2.4.1 引數出處
UBBCONFIG配置檔案 -> RESOURCES -> DBBLWAIT。
2.4.2 時間單位
SCANUNIT。
2.4.3 取值範圍
大於0。
2.4.4 預設取值
1和20/SCANUNIT中的較大者 。
2.4.5 用途解釋 ⑹
如果DBBL在規定時間間隔BBLQUERY內沒有收到某個BBL的"I AM OK"資訊，它會發Request給那個BBL，其等待回覆的時間就是DBBLWAIT。
2.4.6 超時後果 ⑺
DBBL等了DBBLWAIT後仍然沒有回覆，DBBL會認為相關BBL的機器有問題，然後，將其隔離（partation）。
2.4.7 設定考慮
此設定僅僅在MP模式下才起作用。
在MP模式下，考慮網路傳輸時間、系統反應速度等因素，網路速率越大，系統負載越輕，此數值越小；反之亦然。

2.5 BLOCKTIME
2.5.1 引數出處
UBBCONFIG配置檔案 -> RESOURCES -> BLOCKTIME。
2.5.2 時間單位
SCANUNIT。
2.5.3 取值範圍
大於0。
2.5.4 預設取值
大約60/SCANUNIT。
2.5.5 用途解釋
Client端阻塞請求（Blocking call）服務的超時值，BBL發現有超時的Request時，會給相應的Client端發超時資訊。
此引數僅僅在"阻塞請求"的情況下起作用，因此，理解它，關鍵要理解什麼是阻塞請求（Blocking call）？習慣上，我們將"阻塞請求"理解為"同步請求"，將"非同步請求"理解為"非阻塞請求"，是源於將""這一過程看成為一個整體。如果是整體的同步操作，就認為是"阻塞請求"；如果是分開非同步的操作，就認為是"非阻塞請求"。
其實，非同步操作中，同樣存在"阻塞請求"，tuxedo中，tpacall和tpgetrply這兩個非同步操作各自本身就是"阻塞請求"，tpacall是將請求傳送到請求佇列，tpgetrply是將從結果佇列中取出結果，如果沒有特殊的設定，這兩個操作本身都是阻塞的，BLOCKTIME將起作用。
以Request/Reply方式為例，將成功傳送請求的時長設定為T1，將請求處理的時長(含排隊等待)設定為T2,將成功取得結果的時長設定為T3，那麼在下面不同的情況下，將觸發BLOCKTIME，引起超時：
（1） tpcall（）不在transaction中，flag為0，當T1+T2+T3 > BLOCKTIME時，發生超時 ;
（2） tpcall（）不在transaction中，flag為TPNOBLOCK，只有當一次呼叫即成功完成T1階段傳送請求的任務後，T2+T3 > BLOCKTIME時，發生超時 ;
（3） tpacall（）不在transaction中，flag為0，當T1 > BLOCKTIME時，發生超時 ;
（4） tpgetrply（）不在transaction中，flag為0，當T2+T3 > BLOCKTIME時，發生超時 ;
（5） tpcall，tpacall,tpgetrply,在其他任何情況，BLOCKTIME都將不起作用。
（6） 如果請求處於事務交易（transaction）中，此引數不起作用，取代它的是 TransactionTimeOut。
2.5.6 超時後果
在上面描述的四種情況下，Server端 BBL返回Client端超時錯誤：tperrno ＝ 13 （TPETIME）。同時，client端和Server端已經建立的聯接不受任何影響，繼續保持聯接。
2.5.7 設定考慮
此引數涉及整個TUXEDO系統，不能夠直接適應業務系統中不同場合的不同時間等待要求，而且在應用過程中，存在誤差，不適合進行精確到秒的時間控制。
準確有效的使用這個引數，需要考慮好以下幾個問題：
（1） 應用中是否完全依賴這個引數進行時間控制？
（2） 有哪些業務依賴這個引數進行時間控制？
（3） 平衡各種業務，此引數設定為多少？
（4） 除此引數外，是否需要利用其他的超時控制機制？

2.6 WSL CLOPT [-T Client_timeout]
2.6.1 引數出處
UBBCONFIG配置檔案 -> SERVERS -> WSL -> CLOPT "-T"。
2.6.2 時間單位
秒。
2.6.3 取值範圍
大於等於0。
2.6.4 預設取值
0 ，意味著無限等待時間。
2.6.5 用途解釋 ⑻
系統允許的Client靜默時長，即Client和WSH建立聯接後，如果在此指定的時間內客戶端沒有傳送任何請求，WSH會自動回收與此Client端相關的資源。
2.6.6 超時後果 ⑼
WSH會自動釋放和這個Client端的聯接，並將此Client在Bulletin Board中的資料項清空，RollBack它未完成的事務 。
2.6.7 設定考慮
此引數的設定目的，主要是從Server的角度進行考慮，防止在Client端意外失效的情況下仍然耗費Server端的資源。
如果設定太小，那麼頻繁的檢測同樣要消耗Server端一定的資源，而且，在使用長聯接的系統中，系統空閒時，容易造成已經建立的長聯接頻繁的釋放，影響正常業務的提供。
如果設定為0，不管發生什麼狀況，哪怕是Client端系統真的崩潰了，也不會觸發此超時，這將造成Server端資源的無謂浪費。
建議：在業務負載不均衡的長聯接業務系統中，根據業務實際空閒時間，適當加大此數值。

2.7 WSL CLOPT [-t timeout]
2.7.1 引數出處
UBBCONFIG配置檔案 -> SERVERS -> WSL -> CLOPT "-t"。
2.7.2 時間單位
SCANUNIT。
2.7.3 取值範圍
大於0。
2.7.4 預設取值
非安全應用為3，安全應用為6 。
2.7.5 用途解釋
建立聯接時長，指workstation Client建立與server端WSH建立聯接允許的最長時間，因為非安全應用建立聯接時不需要進行使用者校驗等步驟，因此，建立聯接需要的時間較短。同理，安全應用需要的時間較長。
2.7.6 超時後果
建立聯接失敗。
2.7.7 設定考慮
設定此引數，要分析業務系統中，網路頻寬因素、使用者驗證的複雜程度等。

2.8 WSL CLOPT [-I init_timeout]
2.8.1 引數出處
UBBCONFIG配置檔案 -> SERVERS -> WSL -> CLOPT "-I"。
2.8.2 時間單位
秒。
2.8.3 取值範圍
大於0。
2.8.4 預設取值
60 。
2.8.5 用途解釋 ⑽
WorkStation Client端和後臺建立聯接的超時引數值。
（注：感覺上此引數和 WSL CLOPT [-t timeout]功能類似）
2.8.6 超時後果
不確定，現有的文件沒有一點兒解釋。按照字面解釋，應該是tpinit的超時時間，但是，在tpinit所有的錯誤中，只有TPESYSTEM可能承擔這個超時後果，而且僅僅是可能。
2.8.7 設定考慮
在使用過程中，沒有感覺到這個引數的存在，也從來沒有專門設定過。

2.9 WSL CLOPT [-N network_timeout]
2.9.1 引數出處
UBBCONFIG配置檔案 -> SERVERS -> WSL -> CLOPT "-N"。
2.9.2 時間單位
秒。
2.9.3 取值範圍
大於等於0。
2.9.4 預設取值
0 。
2.9.5 用途解釋
網路超時，指Workstation client利用網路接收資料（receive data）的等待時間。
我們同樣需要分析觸發Network Timeout的不同條件。
以Request/Reply方式中的tpcall為例，將成功傳送請求的時長設定為T1，將請求處理的時長(含排隊等待)設定為T2,將成功取得結果的時長設定為T3，那麼在如下情況下，將觸發Network Timeout，引起超時：
（1） tpcall（）不在transaction中，flag為0，當 BLOCKTIME> T1+T2+T3 > NetworkTimeout時，觸發此超時 ;
（2） tpcall（） 在transaction中，flag為0，當TranactionTimeout> TI+T2+T3 > NetworkTimeout時，觸發此超時 ;
（3） tpcall（）不在transaction中，flag為TPNOBLOCK，只有當一次呼叫即成功完成T1階段傳送請求的任務後，當 BLOCKTIME> T2+T3 > NetworkTimeout時，觸發此超時 ;
（4） tpcall（）在transaction中，flag為TPNOBLOCK，只有當一次呼叫即成功完成T1階段傳送請求的任務後，當 TranactionTimeout> T2+T3 > NetworkTimeout時，觸發此超時 ;
（5） tpcall（）不在transaction中，flag為TPNOTIME，當 T1+T2+T3 > NetworkTimeout時，觸發此超時 ;
（6） tpcall（）在transaction中，flag為TPNOTIME，當 TranactionTimeout> TI+T2+T3 > NetworkTimeout時，觸發此超時 ;
（7） tpcall在其他任何情況，NetworkTimeout都將不起作用。
（8） 同理，可以確定NetworkTimeout在tpacall和tpgetrply中起的作用。
2.9.6 超時後果
在上面描述的六種情況下， Client端操作失敗，同時，client端斷開與Server端已經建立的聯接。Server端已經為此Client完成的操作和分配的資源不能立刻回滾和釋放，Server端需要等待前面介紹過的Client_timeout時間後，再釋放相關的資源。
2.9.7 設定考慮
此引數的設定目的，主要是從Client的角度進行考慮，防止在Server端意外失效的情況下，仍然消耗Client端的資源。
設定引數，必須避免小於BLOCKTIME或TransactionTimeout的情況，因為在這種情況下，會出現業務正常等待中，聯接卻中斷的現象，這是一定要避免的。
同時，由於此超時觸發的聯接中斷，並不能立刻釋放Server端的資源，帶來業務執行過程中的不確定性，因此，此引數要謹慎使用。

2.10 SVCTIMOUT
2.10.1 引數出處
UBBCONFIG配置檔案 -> SERVICES -> SVCTIMEOUT 。

2.10.2 時間單位
秒
2.10.3 取值範圍
大於等於0。
2.10.4 預設取值
0，表示無限時長 。
2.10.5 用途解釋
服務處理時長（Service Processing Time），表示系統允許服務處理請求的時間長度。
此引數主要是維護Server端系統安全的角度，防止由於系統異常引起的失控服務佔據系統資源，阻礙正常的後續業務請求。它起到了一個清道夫的作用，將不能有效提供服務的Services清除出系統，並依靠系統的其他機制，重新產生具有活力的Services。
2.10.6 超時後果
超時後，此Service所屬的Server將被系統的SIGKILL訊號清除；此操作不會影響與此Server相關的其他正在執行的副本Servers。
如果系統設定SERVERS->RESTART=Y，那麼，被清除的Server將立刻自動重新啟動。重新啟動的次數受隨後介紹的MAXGEN和GRACE兩個引數聯合限制。
如果系統設定SERVERS->RCMD為有效命令檔案，那麼，在重啟此Server時，將同時執行此命令，如向管理員傳送通知郵件等。
如果SERVER沒有RESTART＝Y設定，那麼Server將不會自動重新啟動。
2.10.7 設定考慮
此引數不是系統全域性引數，而是涉及到單個Service，可以根據不同的Service的處理時間進行設定。由於其主要起到系統清道夫的角色，因此，建議設定為正常Service處理時長的3倍較合適，以避免清除正常執行的Service，使正常執行的業務受到影響。
如果系統執行環境基本穩定，一旦出現底層網路或資料庫系統故障，不是在短時間內能夠恢復，建議將此引數增大，至少為平均恢復時間，甚至可以利用預設值0，無限等待，避免此自動機制，而用人工介入的方法進行服務恢復。因為系統自動的、頻繁的SIGKILL將影響到整個TUXEDO系統的穩定。

2.11 GRACE
2.11.1 引數出處
UBBCONFIG配置檔案 -> SERVERS -> GRACE 。
2.11.2 時間單位
秒。
2.11.3 取值範圍
0-2147,483,647。
2.11.4 預設取值
86400（24小時）。
2.11.5 用途解釋
此時間引數與其他兩個引數緊密相關RESTART, MAXGEN。
關聯起來解釋就是，當Server異常終止時，如果RESTART=Y，那麼此SERVER可立即自動重新啟動，這個重新啟動的次數被限制為在GRACE指定的時間間隔內，重啟不超過MAXGEN-1 次。
如果RESTART這個引數為N，其他的相關引數將都無效。
2.11.6 超時後果
此引數不僅僅是時間的限制，如果在GRACE時間段內，此SERVER重啟次數已經達到MAXGEN-1，後續重啟將不能執行。
2.11.7 設定考慮
此組引數設定的綜合目的是避免執行Server無限的重啟，重啟次數說明了系統目前異常狀況的嚴重程度，如果在一定時間內，Server重啟次數達到了一定的數量，說明這個Server相關的資源已經出現較嚴重的故障，需要人工進行干預了。
另外，經過調優的生產系統是不需要自動重啟的，因此，RESTART這個引數更多是應用在系統測試版本中，在正常執行的生產系統中，應該有不同引數設定，謹慎使用，因為過多的重啟將有可能嚴重影響Server端的整體穩定性。

2.12 Transaction TimeOut
2.12.1 引數出處
tpbegin(timeout,0)。
2.12.2 時間單位
秒,且必須為SCANUINT的倍數。
2.12.3 取值範圍
大於等於0。
2.12.4 預設取值
無，使用時必須明確指定。
2.12.5 用途解釋
交易時長，確定交易（transaction）的持續時間，如果超過此時間，系統將返回超時錯誤。
分析其觸發條件，分兩種情況：
（1） Server端發起交易，
對Client而言，因為Client不在交易範圍內，即使BLOCKTIME設定小於此引數，起有效作用的仍然將是BLOCKTIME，而不是此引數。
（2） Client端發起交易。
對Client而言，因為Client在交易範圍內，此時，BLOCKTIME將失效，此引數取而代之。只要處理時間超過此引數，將觸發此超時，交易處理將隨時中斷。
2.12.6 超時後果
相關交易將被標識為abort only。注意，僅僅是標識為abort only，而不是系統自動執行tpabort進行交易恢復。隨後必須主動執行tpabort，恢復交易，保障交易完整性。如果沒有執行tpabort，系統將通過其他機制，恢復交易，保障交易完整性。
2.12.7 設定考慮
此引數的主要目的是將交易處理過程限制在合理的時間範圍內，如果確實是完成交易的條件不具備，系統也能夠作出反應，避免系統資源的長時間佔用。因此，不管交易由Client還是由Server發起，此引數都要按照業務的實際狀況進行設定。如果設定為0，就基本相當於無限時長。（系統unsigned long資料型別的最大值）

2.13 TRANTIME
2.13.1 引數出處
UBBCONFIG配置檔案 -> SERVICES -> TRANTIME/AUTOTRAN。
2.13.2 時間單位
秒,且必須為SCANUNIT的倍數。
2.13.3 取值範圍
0-2147,483,647。
2.13.4 預設取值
30 。
2.13.5 用途解釋
此引數必須與AUTOTRAN配合使用，表示不需要呼叫tpbegin，就可自動發起的隱含交易（AUTOTRAN implicitly transactions）處理持續時長。其實，起到與tpbegin（timeout,0）中的timeout相同的作用。
其實，AUTOTRAN這個引數更為重要，其預設值為N, 其作用描述如下：
（1） 請求發起方不在交易模式，AUTOTRAN＝Y，Service將自動發起一個交易，TRANTIME將起作用；
（2） 請求發起方在交易模式，而且，其中的標記引數（flags）不是TPNOTRAN，那麼，無論AUTOTRAN如何，Service將自動加入請求方交易中，TRANTIME將不起作用；
（3） 請求發起方在交易模式，而且，其中的標記引數（flags）是TPNOTRAN，如果AUTOTRAN＝N，Service將自動加入請求方交易中，TRANTIME將不起作用；
（4） 請求發起方在交易模式，而且，其中的標記引數（flags）是TPNOTRAN，如果AUTOTRAN＝Y，Service將不加入請求方交易中，而是產生一個新的交易，TRANTIME將在新交易中起作用；
2.13.6 超時後果
與tpbegin(timeout,0)中的timeout相同。
2.13.7 設定考慮
與tpbegin(timeout,0)中的timeout相同。

2.14 ORACLE XA OPENINFO引數：SESTM
2.14.1 引數出處
UBBCONFIG配置檔案 -> GROUPS -> OPENINFO ->SESTM 。
2.14.2 時間單位
秒。
2.14.3 取值範圍
大於等於0，0表示無限時長。
2.14.4 預設取值
無，使用時必須明確設定 。
2.14.5 用途解釋
會話靜默等待時長，即全域性交易中，作為資源管理器（resource manager）已經參與交易並完成相應的資料操作的資料庫，等待全域性交易中的其他參與方操作完成的時間長度。
舉例說明：
假設一個全域性交易由以下幾個部分組成：
（1）tpbegin（T,0） ->
（2）tpcall(S1) -> DB1 完成耗時 T1;
（3）tpcall(S2) -> DB2 完成耗時 T2;
（4）其他操作 耗時 T3
（5）tpcommit()
其中，tpcall(S1)訪問資料庫DB1, tpcall(S2)訪問資料庫DB2。
對DB1而言，如果T-T1> T2+T3 > SESTM1,則觸發超時；
對DB2而言，如果T-T1-T2 > T3 > SESTM2,則觸發超時；
由此可以看出，此引數的主要目的是對資料庫進行資源保護，避免在全域性交易中，已經完成任務的資料庫，為等待其他參與方耗費過多的資源，畢竟ORACLE中併發全域性交易的數量是很有限的。
2.14.6 超時後果
觸發此超時後，資料庫將自己主動回滾已經完成的任務，釋放全域性交易資源。TUXEDO控制的全域性交易進行TPCOMMIT時，如果總時間仍沒有超過Transaction TimeOut，那麼TPCOMMIT將失敗，XALOG會記錄下ORACLE錯誤："ORA-24756: Transaction does not exist"。確實如此，拿上面的例子來說，等到最後TPCOMMIT的時候，DB1已經主動回滾了所有的資料，不難理解，對DB1而言，它好像根本沒有參加過這個全域性交易，自然就會有這樣的錯誤提示。
2.14.7 設定考慮
這個引數是從資料庫自我保護的角度設計的，對資料庫而言，是不得已的辦法。最好的措施還是TUXEDO能夠控制時間，趕在SESTM之前，進行TPABORT，主動通知資料庫進行資料回滾。
用一個簡單的比方：冬天，客人出門時沒有關門，SESTM時間後，客人還沒有回來，主人感覺到冷了，只好自己去關門，不管什麼理由，這樣總是不太好。如果在SESTM時間內，客人能及時回來關門，主人就不會感覺那麼差。
從前面的超時觸發分析，我們也能發現，只要設定SESTM 能夠大於 TransactionTimeOut的話，就能夠儘量的不觸發此超時機制，達到較好的效果。

2.15 ORACLE XA OPENINFO引數：SESWT
2.15.1 引數出處
UBBCONFIG配置檔案 -> GROUPS -> OPENINFO -> SESWT。
2.15.2 時間單位
秒。
2.15.3 取值範圍
大於0。
2.15.4 預設取值
60 。
2.15.5 用途解釋
會話繁忙等待時長，指全域性交易中的一個交易分支（transaction branch）正在一個會話（session）中處理資料過程中，如果第二個會話也要對此交易分支進行操作，那麼第二個會話必須等待第一個會話完成，如果在等待SESWT後，第一個會話仍然沒有完成，那麼第二個分支將觸發此超時。
舉例說明：
假設一個全域性交易由以下幾個部分組成：
（1）tpbegin（T,0） ->
（2）tpcall(S1) -> DB1 完成資料操作耗時 T1;
（3）tpcall(S2) -> DB2 完成資料操作耗時 T2;
（4）其他操作 耗時 T3
（5）tpcommit()
其中，tpcall(S1)訪問資料庫DB1, tpcall(S2)訪問資料庫DB2，任何操作失敗後，將呼叫tpabort。
假設 T1+T2 > T > T1，也就是說，在成功執行第二步tpcall(S1)後，應用執行到第三步tpcall(S2)，在執行過程中，將觸發TransactionTimeout，tpcall（S2）將返回錯誤，應用將立即呼叫tpabort進行交易回滾，DB1的資料將立刻回滾；而DB2並不能中斷tpcall(S2)引起的資料操作，對於ORACLE DB2而言，tpcall(S2)引起的資料操作屬於第一個會話，而tpabort引起的資料庫回滾操作是通過XA介面，屬於第二個會話，所以，tpabort作用到DB2上，只有等待第一個會話完成，如果等待SESWT後，第一個會話仍然沒有完成，即SESTM2.15.6 超時後果
系統將返回XA_RETRY錯誤，提示TMS此操作不能完成，需再試一次。如果應用程式對此沒有再次嘗試的話，仍以上例說明，DB2只能利用SESTM2，觸發超時，自動回滾。
2.15.7 設定考慮
查閱ORACLE相關資源，發現oracal9.2與以前版本效果不同，以前的版本都是第二個會話在等待SESWT後，如果第一個會話操作仍然沒有結束，第二個會話能夠使第一個會話操作立即進行有效的回滾，使第一個會話返回錯誤：ORA-24761。
不難理解，兩者的區別是，打個簡單比方說，A正在用杯子喝水時，B要A放下杯子，B等待SESWT後：
oracle9.2的做法很民主，A還沒有用完，通知B，A還在用杯子，不能放下，還想讓A放下杯子，可以，再來一次；也就是說，只要A在用，B就不能讓人家放下杯子，某種程度上，A代表了強權。
Oracle9.2之前版本的做法很粗暴，通知A不能使用這個杯子了，必須放下，因為B讓你放下，而且已經等很久了，某種程度上，B代表了強權。
因此，如果是ORACLE9.2後的版本，SESWT適當放長一些，畢竟還是希望能夠等到能做事的時候，把想做的事情做了。如果是以前的版本，SESWT適當放短一些，反正一定能等到，為什麼不少等一會兒呢？

2.16 ORACLE sqlnet.expire_time
2.16.1 引數出處
$ORACLE_HOME/network/admin/sqlnet.ora -> expire_time 。
2.16.2 時間單位
分鐘。
2.16.3 取值範圍
大於0。
2.16.4 預設取值
無 。
2.16.5 用途解釋 ⑾
死聯接檢測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層任何資料, 但會在下一層的網路協議中產生資料流量。
如果客戶端的聯接仍然是活動的, 探測包被丟棄,計時裝置復位。 如果客戶端異常斷掉，伺服器將收到由傳送探測包的呼叫發出的錯誤。
2.16.6 超時後果
伺服器將收到由傳送探測包的呼叫發出的錯誤，SQL*Net 將會通知作業系統釋放聯接佔用的資源。
需要說明的是, SQL*Net 2.1.x中 一個活動的孤兒程式（active orphan process） ，如單獨的查詢程式，在查詢完成之前不會被殺掉。 在SQL*Net 2.2中，孤兒程式佔用的資源將會被無條件釋放，不管查詢是否結束。
2.16.7 設定考慮
ORACLE 在NT作業系統上，此功能表現很差，檢測出的無效聯接（dead connection）不能被儘快釋放，而必須等到資料庫重新啟動時才釋放。SQL*Net v2.3以後版本改善了以上問題。
此功能只是伺服器的特性，如果不設定此引數，此功能將不啟動。按照ORACLE的建議，對大多數應用來說，設定10分鐘較合適，其實關鍵還是分析應用系統的實際情況。
同時，不難理解，作為一個資料庫自我管理的機制，也是要佔用資料庫資源和網路資源的，太頻繁的探測同樣會降低系統和網路的效能。在低速網路上，設定此引數，就需更為慎重。
客戶端不需要設定此引數。

2.17 ORACLE distributed_lock_timeout
2.17.1 引數出處
ORACLE初始引數檔案：init.ora -> distributed_lock_timeout。
2.17.2 時間單位
秒。
2.17.3 取值範圍
大於0。
2.17.4 預設取值
60 。
2.17.5 用途解釋
分散式事務鎖等待超時（distributed transaction waiting for lock），指第二個事務處理需要的資料庫資源，正被第一個分散式事務佔用而鎖定，那麼，第二個事務將等待第一個分散式事務釋放此資源，等待distributed_lock_timeout時間後，如果第一分散式事務仍然沒有釋放此資源，第二個事務觸發此超時。
2.17.6 超時後果
如果資源被第一個事務正常使用鎖定，ORACLE回滾第二個事務，並返回錯誤："ORA-02049: time-out: distributed transaction waiting for lock "。
如果第一個事務處理完成，資源釋放後，再嘗試第二個事務，就會成功。如果第二個事務不能等待資源自動釋放，那麼可以採用處理資料庫死鎖（deadlock）的措施，人工介入，清除第一個事務，但一般不建議採用這種方式，因為第一個事務一般會正常結束的。
如果資源被第一個事務因為處於不確定分佈事務狀態（in-doubt distributed transaction）而鎖定，ORACLE回滾第二個事務，並返回錯誤："ORA-01591: lock held by in-doubt distributed transaction identifier "。
這種錯誤遇到的可能性較小，一般只有在分佈事務的關鍵提交階段出現網路、系統故障，才可能出現此故障，而且，當網路、系統故障恢復後，ORACLE一般可以自己解決此問題，不需要人工介入。如果一定要人工介入，可以查閱ORACLE專門的手冊。
2.17.7 設定考慮
出現這樣的超時，是因為特定資料庫資源的使用碰撞，要分析應用系統的業務特點，確定碰撞可能發生的條件，在此條件下，資源可能被先來者鎖定多長時間（T1），後來者又能夠等多長時間（T2），再來設定此引數（T）的大小。如果在大多數情況下，T1 < T2, 那麼就設定T1 < T < T2；反之，大多數情況下，T1 > T2，那麼，就設定T < T2。
因此，不分析業務特點，一味的增大和減小是不恰當的。

2.18 ORACLE Max_commit_propagation_delay
2.18.1 引數出處
ORACLE初始檔案:init.ora -> Max_commit_propagation_delay。
2.18.2 時間單位
0.01秒。
2.18.3 取值範圍
0 ～ 90000。
2.18.4 預設取值
700 。
2.18.5 用途解釋
最大提交傳播時延（MAX_COMMIT_PROPAGATION_DELAY，簡稱MCPD），在ORACLE RAC(或OPS)環境中才使用，表示在RAC系統中，一個instance系統提交產生的最新系統改變碼（SCN），能夠以多快的速度反應到另一個instance中。
舉例說明，RAC系統，有A,B兩個例項（instance），A、B本地系統改變碼為SCN1，A更新資料DATA1提交， LGWR操作完成後，A本地系統改變碼為SCN2，經過不大於MAX_COMMIT_PROPAGATION_DELAY時間後，B系統本地改變碼才變為SCN2。
2.18.6 超時後果
Global Cache Services 將重新整理RAC中的SCN。不管SCN是否及時重新整理，後續的資料查詢都不會因此產生資料庫錯誤。但，在此時間內，有可能查詢結果不是最新資料，產生讀一致性（read consistency）問題。
2.18.7 設定考慮
RAC環境中的所有例項，此引數值必須相同。
ORACLE8i後，建議常用的兩個值是0和700（預設），其他數值皆不建議。其實，這兩個數值就代表了RAC環境中，兩種SCN 產生機制：
Lamport Scheme和 Broadcast on Commit scheme。
設定為預設值700，表示採用Lamport Scheme，SCN改變不會完全同步，同步將在 7秒鐘內完成，而不是總等待7秒鐘後才完成。如果系統比較空閒，同步可能在0.5秒（甚至更短時間）內完成；不管系統多繁忙，同步時間也不可能超過7秒。不難理解，採用此模式，整個RAC系統的執行效率較高。
設定為0，表示採用Broadcast on Commit scheme，SCN改變完全同步。每當commit時（即LGWR 寫redo log時）：
－ LGWR傳送訊息更新全域性SCN（global SCN），
－ LGWR 傳送訊息給每個活動的例項更新其本地SCN（local SCN）。
有資料說，只要MCPD < 700，系統將採用Broadcast on Commit scheme。
Lamport Scheme能夠適應絕大部分應用的要求，只有個別實時性特別高的業務，才需要Broadcast on Commit scheme。通過分析，不難理解，Broadcast on Commit scheme將需要更多的系統資源。

3 總結
以上所有時間引數，都是tuxedo系統或ORACLE資料庫系統提供的時間控制機制，更多的是從維護本系統自身安全的角度，建立起相互之間溝通的規則。在Client 端，中介軟體伺服器，資料伺服器這相互聯絡的三者之間，用一個簡單的比方，就是先保證自己儘量不給相關人帶來麻煩；一旦相關人出了麻煩，自己能夠自我保障，不受別人干擾。
這些時間引數還有的一個共性的特點就是"不精確"，如果業務需要要精確到1秒，則必須依靠業務程式中更精確的時間程式設計。
總之，要保障整個業務系統的有效性和健壯性，必須瞭解都有哪些時間引數？都表示什麼意思？都起哪些作用？自己的業務應用對時間要求是怎樣的？這些引數該如何配置才能滿足應用的要求？希望本文能夠在以上方面給大家帶來一點方便。

4 後記
自2002年真正在專案中利用TUXEDO起，就發現已有資料在時間引數解釋方面的缺憾，那時，就有寫這樣一個專題的打算，開始收集這方面的資料。由於後來工作內容的變化，也就沒有精力再作整理，但心裡一直惦記著這件事情。直到前些天知道了BEA的這個活動，再到網路上搜集資料，發現已經有了一些類似的資料，但感覺仍然不夠完整，不夠透徹，因此，我認為整理這樣一個專題資料，還是有必要的，便下決心藉此機會做完這件事情。經過近十天的查閱、整理，終於完成，算是了我多年夙願。
文中的引數，我僅僅使用過其中的12個，其他未用引數，主要是靠查閱資料和邏輯分析，根據我自己的理解進行解釋，再加上時間倉促，或遺漏、不妥之處，敬請指正，讓我們一起來使此《功略》更準確、更全面，讓更多的人從中受益。

5 參考文獻
1. http://e-docs.bea.com BEA TUXEDO RELEASE 7.1 。
2. http://dev2dev.bea.com.cn/techdoc/tuxedo/20030230.html 《Tuxedo 中關於時間的引數的說明》作者：不詳 。
3. 《ORACLE8i Reference》。
4. 《ORACLE9i Reference》。
5. 《ORACLE8i Parallel Server Concepts and Administration》。
6. 《ORACLE8i Application Developers Guide - Fundamentals》。
7. http://metalink.oracle.com 相關問題解決資料。
8. http://www.chinaunix.net 《DCD死聯接檢測》作者：yukaikai
注：文章中標註⑴～⑽涉及的內容，引自參考文獻-2 ，標註⑾涉及的內容，引自參考文獻-8 。

關於作者：
姜曉亮
北京大唐中聯絡統整合有限公司 產品擴充部

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