http://kimva.blogbus.com/logs/10795776.html
http://kimva.blogbus.com/logs/10795836.html
摘要：
本《功略》集中了TUXEDO應(yīng)用中，可能涉及到的所有時(shí)間參數(shù)，并分別對其進(jìn)行詳細(xì)描述，不但對其出處、取值等基本屬性進(jìn)行查證，而且，通過分析其內(nèi)在的控制機(jī)制，給出設(shè)置建議，以期能夠達(dá)到透徹理解、方便查閱、準(zhǔn)確使用的目的。
1 前言
金融、電信等眾多行業(yè)的綜合營業(yè)系統(tǒng)中，廣泛使用了TUXEDO交易中間件，用來處理大量并發(fā)的聯(lián)機(jī)事務(wù)處理（OLTP）業(yè)務(wù)。典型的OLTP業(yè)務(wù)，每筆業(yè)務(wù)的信息量較小，而且，具有一定的實(shí)時(shí)性，對時(shí)間的要求非常嚴(yán)格。
TUXEDO，聯(lián)系著DATABASE和客戶端軟件，憑借其多層次的超時(shí)控制機(jī)制，達(dá)到客戶端快速響應(yīng)，服務(wù)器端穩(wěn)定可靠的效果。
TUXEDO的多層次的超時(shí)控制機(jī)制中，涉及到的時(shí)間參數(shù)不少于10個(gè)，再加上與之緊密聯(lián)系的DATABASE中的幾個(gè)超時(shí)參數(shù)，確實(shí)比較復(fù)雜。遺憾的是，目前還沒有的專門的文檔對它們進(jìn)行詳細(xì)說明，而是分散在不同的專題中分別說明，而且，不同的專題中，解釋的詳細(xì)程度也不一樣，在查閱過程中，多有不便。
本文試圖將這些參數(shù)集中起來，對每一個(gè)都加以詳細(xì)說明，并試圖解釋每個(gè)參數(shù)存在的原因。大部分參數(shù)時(shí)間長短的設(shè)置，除個(gè)別外，基本沒有固定的模式，只要了解它們的具體含義，并結(jié)合具體應(yīng)用系統(tǒng)的實(shí)際要求，相信大家都能夠作出合理的配置。
2 全功略解讀
2.1 SCANUNIT
2.1.1 參數(shù)出處
UBBCONFIG配置文件 -> RESOURCES -> SCANUNIT 。
2.1.2 時(shí)間單位
秒,且必須為5的倍數(shù)。
2.1.3 取值范圍
大于0小于等于60中5的倍數(shù)，即｛5，10，15，20，25，30，35，40，45，50，55，60｝。
2.1.4 默認(rèn)取值
10 。
2.1.5 用途解釋 ⑴
這個(gè)參數(shù)大家都會用，比較好理解，TUXEDO中，BBL是用來對Bulletin Board進(jìn)行管理和監(jiān)控的系統(tǒng)進(jìn)程，它基于時(shí)間片的輪詢方式，時(shí)間片的大小就是SCANUNIT的值，SCANUNIT是Tuxedo對系統(tǒng)進(jìn)行管理的最基本時(shí)間單位。每隔SCANUNIT，BBL對Bulletin Board進(jìn)行一次檢查，看看有沒有超時(shí)的事務(wù)或阻塞的服務(wù)請求。后面講到的很多時(shí)間參數(shù)都是以SCANUNIT為單位。
2.1.6 超時(shí)后果
僅僅是個(gè)輪詢時(shí)間單位而已，到時(shí)間就輪詢，如此而已。
2.1.7 設(shè)置考慮
作為一個(gè)涉及到整個(gè)TUXDO系統(tǒng)的基本單位時(shí)間，如果業(yè)務(wù)需要，對時(shí)間參數(shù)控制比較嚴(yán)格，設(shè)置為5也不算小。如果系統(tǒng)業(yè)務(wù)對時(shí)間要求不嚴(yán)格，那就大點(diǎn)兒，60也沒什么不可以；畢竟頻繁輪詢是要耗費(fèi)更多系統(tǒng)資源的，而任何對資源的不必要的消耗都是浪費(fèi)。
2.2 SANITYSCAN
2.2.1 參數(shù)出處
UBBCONFIG配置文件 -> RESOURCES -> SANITYSCAN 。
2.2.2 時(shí)間單位
SCANUNIT 。
2.2.3 取值范圍
1 ～32767 。
2.2.4 默認(rèn)取值
大約120/SCANUNIT。
2.2.5 用途解釋 ⑵
進(jìn)行系統(tǒng)健全性檢查，主要包括Server進(jìn)程狀態(tài)和Bulletin Board數(shù)據(jù)結(jié)構(gòu)，檢查Server進(jìn)程是否存活，如果已經(jīng)不存在，會清理Bulletin Board中相應(yīng)的數(shù)據(jù)項(xiàng)及IPC資源，并根據(jù)參數(shù)配置決定是否重新啟動，如果設(shè)了RESTART=Y，所占的Message Queue不會被清除，Queue中的Request得到保留，仍會被處理。如果是MP模式，BBL還會給DBBL發(fā)狀態(tài)消息。
2.2.6 超時(shí)后果
僅僅是個(gè)系統(tǒng)健康檢查的間隔時(shí)間而已，到時(shí)間就檢查，如此而已。
2.2.7 設(shè)置考慮
作為一個(gè)涉及到整個(gè)TUXDO系統(tǒng)健康檢查的間隔時(shí)間，如果系統(tǒng)處在一個(gè)穩(wěn)定的運(yùn)行環(huán)境中，網(wǎng)絡(luò)、數(shù)據(jù)庫、應(yīng)用都很穩(wěn)定，那這個(gè)參數(shù)可以大一些；如果運(yùn)行環(huán)境不穩(wěn)定，系統(tǒng)繁忙，而且Server進(jìn)程經(jīng)常因異常（如超時(shí)）而死掉，那就設(shè)置小一些。設(shè)置的原則和SCANUNIT一樣：不要隨意浪費(fèi)系統(tǒng)資源。
2.3 BBLQUERY
2.3.1 參數(shù)出處
UBBCONFIG配置文件 -> RESOURCES -> BBLQUERY。
2.3.2 時(shí)間單位
SCANUNIT
2.3.3 取值范圍 ⑶
BBLQUERY必須大于等于SANITYSCAN，tmloadcf 時(shí)會強(qiáng)制檢查，如果設(shè)的值小于SANITYSCAN，tmloadcf會自動調(diào)整為SANITYSCAN。
2.3.4 默認(rèn)取值
大約300/SCANUNIT。
2.3.5 用途解釋 ⑷
BBL檢查，在MP模式下，BBL會每隔一段時(shí)間都發(fā)送了" I am ok "心跳信息給DBBL，這個(gè)間隔就是BBLQUERY。
2.3.6 超時(shí)后果 ⑸
如果DBBL在規(guī)定時(shí)間間隔內(nèi)沒有收到某個(gè)BBL的信息，DBBL它會主動發(fā)送Request給那個(gè)BBL，判斷其是否正常。（如果等了DBBLWAIT后仍然沒有回復(fù)，DBBL會認(rèn)為那臺機(jī)器有問題，然后，將其隔離。）
2.3.7 設(shè)置考慮
此設(shè)置僅僅在MP模式下才起作用。
在MP模式下，如果TUXEDO系統(tǒng)需要對不穩(wěn)定的運(yùn)行環(huán)境可能發(fā)生的故障作出快速的反應(yīng)，那么BBLQUERY要設(shè)置小一些，讓系統(tǒng)快速的自我檢查?？紤]網(wǎng)絡(luò)傳輸時(shí)間、系統(tǒng)反應(yīng)速度等因素，網(wǎng)絡(luò)速度越慢，系統(tǒng)負(fù)載越重，取值越大；反之亦然。
如果系統(tǒng)運(yùn)行環(huán)境很穩(wěn)定，利用其默認(rèn)值即可，甚至可以更大數(shù)值。
2.4 DBBLWAIT
2.4.1 參數(shù)出處
UBBCONFIG配置文件 -> RESOURCES -> DBBLWAIT。
2.4.2 時(shí)間單位
SCANUNIT。
2.4.3 取值范圍
大于0。
2.4.4 默認(rèn)取值
1和20/SCANUNIT中的較大者 。
2.4.5 用途解釋 ⑹
如果DBBL在規(guī)定時(shí)間間隔BBLQUERY內(nèi)沒有收到某個(gè)BBL的"I AM OK"信息，它會發(fā)Request給那個(gè)BBL，其等待回復(fù)的時(shí)間就是DBBLWAIT。
2.4.6 超時(shí)后果 ⑺
DBBL等了DBBLWAIT后仍然沒有回復(fù)，DBBL會認(rèn)為相關(guān)BBL的機(jī)器有問題，然后，將其隔離（partation）。
2.4.7 設(shè)置考慮
此設(shè)置僅僅在MP模式下才起作用。
在MP模式下，考慮網(wǎng)絡(luò)傳輸時(shí)間、系統(tǒng)反應(yīng)速度等因素，網(wǎng)絡(luò)速率越大，系統(tǒng)負(fù)載越輕，此數(shù)值越?。环粗嗳?。
2.5 BLOCKTIME
2.5.1 參數(shù)出處
UBBCONFIG配置文件 -> RESOURCES -> BLOCKTIME。
2.5.2 時(shí)間單位
SCANUNIT。
2.5.3 取值范圍
大于0。
2.5.4 默認(rèn)取值
大約60/SCANUNIT。
2.5.5 用途解釋
Client端阻塞請求（Blocking call）服務(wù)的超時(shí)值，BBL發(fā)現(xiàn)有超時(shí)的Request時(shí)，會給相應(yīng)的Client端發(fā)超時(shí)信息。
此參數(shù)僅僅在"阻塞請求"的情況下起作用，因此，理解它，關(guān)鍵要理解什么是阻塞請求（Blocking call）？習(xí)慣上，我們將"阻塞請求"理解為"同步請求"，將"異步請求"理解為"非阻塞請求"，是源于將"<發(fā)送請求－得到結(jié)果>"這一過程看成為一個(gè)整體。如果是整體的同步操作，就認(rèn)為是"阻塞請求"；如果是分開異步的操作，就認(rèn)為是"非阻塞請求"。
其實(shí)，異步操作中，同樣存在"阻塞請求"，tuxedo中，tpacall和tpgetrply這兩個(gè)異步操作各自本身就是"阻塞請求"，tpacall是將請求發(fā)送到請求隊(duì)列，tpgetrply是將從結(jié)果隊(duì)列中取出結(jié)果，如果沒有特殊的設(shè)置，這兩個(gè)操作本身都是阻塞的，BLOCKTIME將起作用。
以Request/Reply方式為例，將成功發(fā)送請求的時(shí)長設(shè)置為T1，將請求處理的時(shí)長(含排隊(duì)等待)設(shè)置為T2,將成功取得結(jié)果的時(shí)長設(shè)置為T3，那么在下面不同的情況下，將觸發(fā)BLOCKTIME，引起超時(shí)：
（1） tpcall（）不在transaction中，flag為0，當(dāng)T1+T2+T3 > BLOCKTIME時(shí)，發(fā)生超時(shí) ;
?。?） tpcall（）不在transaction中，flag為TPNOBLOCK，只有當(dāng)一次調(diào)用即成功完成T1階段發(fā)送請求的任務(wù)后，T2+T3 > BLOCKTIME時(shí)，發(fā)生超時(shí) ;
（3） tpacall（）不在transaction中，flag為0，當(dāng)T1 > BLOCKTIME時(shí)，發(fā)生超時(shí) ;
?。?） tpgetrply（）不在transaction中，flag為0，當(dāng)T2+T3 > BLOCKTIME時(shí)，發(fā)生超時(shí) ;
?。?） tpcall，tpacall,tpgetrply,在其他任何情況，BLOCKTIME都將不起作用。
?。?） 如果請求處于事務(wù)交易（transaction）中，此參數(shù)不起作用，取代它的是 TransactionTimeOut。
2.5.6 超時(shí)后果
在上面描述的四種情況下，Server端 BBL返回Client端超時(shí)錯(cuò)誤：tperrno ＝ 13 （TPETIME）。同時(shí)，client端和Server端已經(jīng)建立的聯(lián)接不受任何影響，繼續(xù)保持聯(lián)接。
2.5.7 設(shè)置考慮
此參數(shù)涉及整個(gè)TUXEDO系統(tǒng)，不能夠直接適應(yīng)業(yè)務(wù)系統(tǒng)中不同場合的不同時(shí)間等待要求，而且在應(yīng)用過程中，存在誤差，不適合進(jìn)行精確到秒的時(shí)間控制。
準(zhǔn)確有效的使用這個(gè)參數(shù)，需要考慮好以下幾個(gè)問題：
?。?） 應(yīng)用中是否完全依賴這個(gè)參數(shù)進(jìn)行時(shí)間控制？
?。?） 有哪些業(yè)務(wù)依賴這個(gè)參數(shù)進(jìn)行時(shí)間控制？
（3） 平衡各種業(yè)務(wù)，此參數(shù)設(shè)置為多少？
?。?） 除此參數(shù)外，是否需要利用其他的超時(shí)控制機(jī)制？
2.6 WSL CLOPT [-T Client_timeout]
2.6.1 參數(shù)出處
UBBCONFIG配置文件 -> SERVERS -> WSL -> CLOPT "-T"。
2.*** 默認(rèn)取值
0 ，意味著無限等待時(shí)間。
2.6.5 用途解釋 ⑻
系統(tǒng)允許的Client靜默時(shí)長，即Client和WSH建立聯(lián)接后，如果在此指定的時(shí)間內(nèi)客戶端沒有發(fā)送任何請求，WSH會自動回收與此Client端相關(guān)的資源。
2.6.6 超時(shí)后果 ⑼
WSH會自動釋放和這個(gè)Client端的聯(lián)接，并將此Client在Bulletin Board中的數(shù)據(jù)項(xiàng)清空，RollBack它未完成的事務(wù) 。
2.6.7 設(shè)置考慮
此參數(shù)的設(shè)置目的，主要是從Server的角度進(jìn)行考慮，防止在Client端意外失效的情況下仍然耗費(fèi)Server端的資源。
如果設(shè)置太小，那么頻繁的檢測同樣要消耗Server端一定的資源，而且，在使用長聯(lián)接的系統(tǒng)中，系統(tǒng)空閑時(shí)，容易造成已經(jīng)建立的長聯(lián)接頻繁的釋放，影響正常業(yè)務(wù)的提供。
如果設(shè)置為0，不管發(fā)生什么狀況，哪怕是Client端系統(tǒng)真的崩潰了，也不會觸發(fā)此超時(shí)，這將造成Server端資源的無謂浪費(fèi)。
建議：在業(yè)務(wù)負(fù)載不均衡的長聯(lián)接業(yè)務(wù)系統(tǒng)中，根據(jù)業(yè)務(wù)實(shí)際空閑時(shí)間，適當(dāng)加大此數(shù)值。
2.7 WSL CLOPT [-t timeout]
2.7.1 參數(shù)出處
UBBCONFIG配置文件 -> SERVERS -> WSL -> CLOPT "-t"。
2.7.2 時(shí)間單位
SCANUNIT。
2.7.3 取值范圍
大于0。
2.7.4 默認(rèn)取值
非安全應(yīng)用為3，安全應(yīng)用為6 。
2.7.5 用途解釋
建立聯(lián)接時(shí)長，指workstation Client建立與server端WSH建立聯(lián)接允許的最長時(shí)間，因?yàn)榉前踩珣?yīng)用建立聯(lián)接時(shí)不需要進(jìn)行用戶校驗(yàn)等步驟，因此，建立聯(lián)接需要的時(shí)間較短。同理，安全應(yīng)用需要的時(shí)間較長。
2.7.6 超時(shí)后果
建立聯(lián)接失敗。
2.7.7 設(shè)置考慮
設(shè)置此參數(shù)，要分析業(yè)務(wù)系統(tǒng)中，網(wǎng)絡(luò)帶寬因素、用戶驗(yàn)證的復(fù)雜程度等。
2.8 WSL CLOPT [-I init_timeout]
2.8.1 參數(shù)出處
UBBCONFIG配置文件 -> SERVERS -> WSL -> CLOPT "-I"。
2.8.2 時(shí)間單位
秒。
2.8.3 取值范圍
大于0。
2.8.4 默認(rèn)取值
60 。
2.8.5 用途解釋 ⑽
WorkStation Client端和后臺建立聯(lián)接的超時(shí)參數(shù)值。
?。ㄗⅲ焊杏X上此參數(shù)和 WSL CLOPT [-t timeout]功能類似）
2.8.6 超時(shí)后果
不確定，現(xiàn)有的文檔沒有一點(diǎn)兒解釋。按照字面解釋，應(yīng)該是tpinit的超時(shí)時(shí)間，但是，在tpinit所有的錯(cuò)誤中，只有TPESYSTEM可能承擔(dān)這個(gè)超時(shí)后果，而且僅僅是可能。
2.8.7 設(shè)置考慮
在使用過程中，沒有感覺到這個(gè)參數(shù)的存在，也從來沒有專門設(shè)置過。
2.9 WSL CLOPT [-N network_timeout]
2.9.1 參數(shù)出處
UBBCONFIG配置文件 -> SERVERS -> WSL -> CLOPT "-N"。
2.9.2 時(shí)間單位
秒。
2.9.3 取值范圍
大于等于0。
2.9.4 默認(rèn)取值
0 。
2.9.5 用途解釋
網(wǎng)絡(luò)超時(shí)，指Workstation client利用網(wǎng)絡(luò)接收數(shù)據(jù)（receive data）的等待時(shí)間。
我們同樣需要分析觸發(fā)Network Timeout的不同條件。
以Request/Reply方式中的tpcall為例，將成功發(fā)送請求的時(shí)長設(shè)置為T1，將請求處理的時(shí)長(含排隊(duì)等待)設(shè)置為T2,將成功取得結(jié)果的時(shí)長設(shè)置為T3，那么在如下情況下，將觸發(fā)Network Timeout，引起超時(shí)：
?。?） tpcall（）不在transaction中，flag為0，當(dāng) BLOCKTIME> T1+T2+T3 > NetworkTimeout時(shí)，觸發(fā)此超時(shí) ;
?。?） tpcall（） 在transaction中，flag為0，當(dāng)TranactionTimeout> TI+T2+T3 > NetworkTimeout時(shí)，觸發(fā)此超時(shí) ;
?。?） tpcall（）不在transaction中，flag為TPNOBLOCK，只有當(dāng)一次調(diào)用即成功完成T1階段發(fā)送請求的任務(wù)后，當(dāng) BLOCKTIME> T2+T3 > NetworkTimeout時(shí)，觸發(fā)此超時(shí) ;
?。?） tpcall（）在transaction中，flag為TPNOBLOCK，只有當(dāng)一次調(diào)用即成功完成T1階段發(fā)送請求的任務(wù)后，當(dāng) TranactionTimeout> T2+T3 > NetworkTimeout時(shí)，觸發(fā)此超時(shí) ;
?。?） tpcall（）不在transaction中，flag為TPNOTIME，當(dāng) T1+T2+T3 > NetworkTimeout時(shí)，觸發(fā)此超時(shí) ;
（6） tpcall（）在transaction中，flag為TPNOTIME，當(dāng) TranactionTimeout> TI+T2+T3 > NetworkTimeout時(shí)，觸發(fā)此超時(shí) ;
?。?） tpcall在其他任何情況，NetworkTimeout都將不起作用。
?。?） 同理，可以確定NetworkTimeout在tpacall和tpgetrply中起的作用。
2.9.6 超時(shí)后果
在上面描述的六種情況下， Client端操作失敗，同時(shí)，client端斷開與Server端已經(jīng)建立的聯(lián)接。Server端已經(jīng)為此Client完成的操作和分配的資源不能立刻回滾和釋放，Server端需要等待前面介紹過的Client_timeout時(shí)間后，再釋放相關(guān)的資源。
2.9.7 設(shè)置考慮
此參數(shù)的設(shè)置目的，主要是從Client的角度進(jìn)行考慮，防止在Server端意外失效的情況下，仍然消耗Client端的資源。
設(shè)置參數(shù)，必須避免小于BLOCKTIME或TransactionTimeout的情況，因?yàn)樵谶@種情況下，會出現(xiàn)業(yè)務(wù)正常等待中，聯(lián)接卻中斷的現(xiàn)象，這是一定要避免的。
同時(shí)，由于此超時(shí)觸發(fā)的聯(lián)接中斷，并不能立刻釋放Server端的資源，帶來業(yè)務(wù)執(zhí)行過程中的不確定性，因此，此參數(shù)要謹(jǐn)慎使用。
2.10 SVCTIMOUT
2.10.1 參數(shù)出處
UBBCONFIG配置文件 -> SERVICES -> SVCTIMEOUT 。
2.10.2 時(shí)間單位
秒
2.10.3 取值范圍
大于等于0。
2.10.4 默認(rèn)取值
0，表示無限時(shí)長 。
2.10.5 用途解釋
服務(wù)處理時(shí)長（Service Processing Time），表示系統(tǒng)允許服務(wù)處理請求的時(shí)間長度。
此參數(shù)主要是維護(hù)Server端系統(tǒng)安全的角度，防止由于系統(tǒng)異常引起的失控服務(wù)占據(jù)系統(tǒng)資源，阻礙正常的后續(xù)業(yè)務(wù)請求。它起到了一個(gè)清道夫的作用，將不能有效提供服務(wù)的Services清除出系統(tǒng)，并依靠系統(tǒng)的其他機(jī)制，重新產(chǎn)生具有活力的Services。
2.10.6 超時(shí)后果
超時(shí)后，此Service所屬的Server將被系統(tǒng)的SIGKILL信號清除；此操作不會影響與此Server相關(guān)的其他正在運(yùn)行的副本Servers。
如果系統(tǒng)設(shè)置SERVERS->RESTART=Y，那么，被清除的Server將立刻自動重新啟動。重新啟動的次數(shù)受隨后介紹的MAXGEN和GRACE兩個(gè)參數(shù)聯(lián)合限制。
如果系統(tǒng)設(shè)置SERVERS->RCMD為有效命令文件，那么，在重啟此Server時(shí)，將同時(shí)執(zhí)行此命令，如向管理員發(fā)送通知郵件等。
如果SERVER沒有RESTART＝Y(jié)設(shè)置，那么Server將不會自動重新啟動。
2.10.7 設(shè)置考慮
此參數(shù)不是系統(tǒng)全局參數(shù)，而是涉及到單個(gè)Service，可以根據(jù)不同的Service的處理時(shí)間進(jìn)行設(shè)置。由于其主要起到系統(tǒng)清道夫的角色，因此，建議設(shè)置為正常Service處理時(shí)長的3倍較合適，以避免清除正常運(yùn)行的Service，使正常運(yùn)行的業(yè)務(wù)受到影響。
如果系統(tǒng)運(yùn)行環(huán)境基本穩(wěn)定，一旦出現(xiàn)底層網(wǎng)絡(luò)或數(shù)據(jù)庫系統(tǒng)故障，不是在短時(shí)間內(nèi)能夠恢復(fù)，建議將此參數(shù)增大，至少為平均恢復(fù)時(shí)間，甚至可以利用默認(rèn)值0，無限等待，避免此自動機(jī)制，而用人工介入的方法進(jìn)行服務(wù)恢復(fù)。因?yàn)橄到y(tǒng)自動的、頻繁的SIGKILL將影響到整個(gè)TUXEDO系統(tǒng)的穩(wěn)定。
2.11 GRACE
2.11.1 參數(shù)出處
UBBCONFIG配置文件 -> SERVERS -> GRACE 。
2.11.2 時(shí)間單位
秒。
2.11.3 取值范圍
0-2147,483,647。
2.11.4 默認(rèn)取值
86400（24小時(shí)）。
2.11.5 用途解釋
此時(shí)間參數(shù)與其他兩個(gè)參數(shù)緊密相關(guān)RESTART, MAXGEN。
關(guān)聯(lián)起來解釋就是，當(dāng)Server異常終止時(shí)，如果RESTART=Y，那么此SERVER可立即自動重新啟動，這個(gè)重新啟動的次數(shù)被限制為在GRACE指定的時(shí)間間隔內(nèi)，重啟不超過MAXGEN-1 次。
如果RESTART這個(gè)參數(shù)為N，其他的相關(guān)參數(shù)將都無效。
2.11.6 超時(shí)后果
此參數(shù)不僅僅是時(shí)間的限制，如果在GRACE時(shí)間段內(nèi)，此SERVER重啟次數(shù)已經(jīng)達(dá)到MAXGEN-1，后續(xù)重啟將不能執(zhí)行。
2.11.7 設(shè)置考慮
此組參數(shù)設(shè)置的綜合目的是避免運(yùn)行Server無限的重啟，重啟次數(shù)說明了系統(tǒng)目前異常狀況的嚴(yán)重程度，如果在一定時(shí)間內(nèi)，Server重啟次數(shù)達(dá)到了一定的數(shù)量，說明這個(gè)Server相關(guān)的資源已經(jīng)出現(xiàn)較嚴(yán)重的故障，需要人工進(jìn)行干預(yù)了。
另外，經(jīng)過調(diào)優(yōu)的生產(chǎn)系統(tǒng)是不需要自動重啟的，因此，RESTART這個(gè)參數(shù)更多是應(yīng)用在系統(tǒng)測試版本中，在正常運(yùn)行的生產(chǎn)系統(tǒng)中，應(yīng)該有不同參數(shù)設(shè)置，謹(jǐn)慎使用，因?yàn)檫^多的重啟將有可能嚴(yán)重影響Server端的整體穩(wěn)定性。
2.12 Transaction TimeOut
2.12.1 參數(shù)出處
tpbegin(timeout,0)。
2.12.2 時(shí)間單位
秒,且必須為SCANUINT的倍數(shù)。
2.12.3 取值范圍
大于等于0。
2.12.4 默認(rèn)取值
無，使用時(shí)必須明確指定。
2.12.5 用途解釋
交易時(shí)長，確定交易（transaction）的持續(xù)時(shí)間，如果超過此時(shí)間，系統(tǒng)將返回超時(shí)錯(cuò)誤。
分析其觸發(fā)條件，分兩種情況：
?。?） Server端發(fā)起交易，
對Client而言，因?yàn)镃lient不在交易范圍內(nèi)，即使BLOCKTIME設(shè)置小于此參數(shù)，起有效作用的仍然將是BLOCKTIME，而不是此參數(shù)。
（2） Client端發(fā)起交易。
對Client而言，因?yàn)镃lient在交易范圍內(nèi)，此時(shí)，BLOCKTIME將失效，此參數(shù)取而代之。只要處理時(shí)間超過此參數(shù)，將觸發(fā)此超時(shí)，交易處理將隨時(shí)中斷。
2.12.6 超時(shí)后果
相關(guān)交易將被標(biāo)識為abort only。注意，僅僅是標(biāo)識為abort only，而不是系統(tǒng)自動執(zhí)行tpabort進(jìn)行交易恢復(fù)。隨后必須主動執(zhí)行tpabort，恢復(fù)交易，保障交易完整性。如果沒有執(zhí)行tpabort，系統(tǒng)將通過其他機(jī)制，恢復(fù)交易，保障交易完整性。
2.12.7 設(shè)置考慮
此參數(shù)的主要目的是將交易處理過程限制在合理的時(shí)間范圍內(nèi)，如果確實(shí)是完成交易的條件不具備，系統(tǒng)也能夠作出反應(yīng)，避免系統(tǒng)資源的長時(shí)間占用。因此，不管交易由Client還是由Server發(fā)起，此參數(shù)都要按照業(yè)務(wù)的實(shí)際狀況進(jìn)行設(shè)置。如果設(shè)置為0，就基本相當(dāng)于無限時(shí)長。（系統(tǒng)unsigned long數(shù)據(jù)類型的最大值）
2.13 TRANTIME
2.13.1 參數(shù)出處
UBBCONFIG配置文件 -> SERVICES -> TRANTIME/AUTOTRAN。
2.13.2 時(shí)間單位
秒,且必須為SCANUNIT的倍數(shù)。
2.13.3 取值范圍
0-2147,483,647。
2.13.4 默認(rèn)取值
30 。
2.13.5 用途解釋
此參數(shù)必須與AUTOTRAN配合使用，表示不需要調(diào)用tpbegin，就可自動發(fā)起的隱含交易（AUTOTRAN implicitly transactions）處理持續(xù)時(shí)長。其實(shí)，起到與tpbegin（timeout,0）中的timeout相同的作用。
其實(shí)，AUTOTRAN這個(gè)參數(shù)更為重要，其默認(rèn)值為N, 其作用描述如下：
?。?） 請求發(fā)起方不在交易模式，AUTOTRAN＝Y(jié)，Service將自動發(fā)起一個(gè)交易，TRANTIME將起作用；
（2） 請求發(fā)起方在交易模式，而且，其中的標(biāo)記參數(shù)（flags）不是TPNOTRAN，那么，無論AUTOTRAN如何，Service將自動加入請求方交易中，TRANTIME將不起作用；
?。?） 請求發(fā)起方在交易模式，而且，其中的標(biāo)記參數(shù)（flags）是TPNOTRAN，如果AUTOTRAN＝N，Service將自動加入請求方交易中，TRANTIME將不起作用；
?。?） 請求發(fā)起方在交易模式，而且，其中的標(biāo)記參數(shù)（flags）是TPNOTRAN，如果AUTOTRAN＝Y(jié)，Service將不加入請求方交易中，而是產(chǎn)生一個(gè)新的交易，TRANTIME將在新交易中起作用；
2.13.6 超時(shí)后果
與tpbegin(timeout,0)中的timeout相同。
2.13.7 設(shè)置考慮
與tpbegin(timeout,0)中的timeout相同。
2.14 ORACLE XA OPENINFO參數(shù)：SESTM
2.14.1 參數(shù)出處
UBBCONFIG配置文件 -> GROUPS -> OPENINFO ->SESTM 。
2.14.2 時(shí)間單位
秒。
2.14.3 取值范圍
大于等于0，0表示無限時(shí)長。
2.14.4 默認(rèn)取值
無，使用時(shí)必須明確設(shè)置 。
2.14.5 用途解釋
會話靜默等待時(shí)長，即全局交易中，作為資源管理器（resource manager）已經(jīng)參與交易并完成相應(yīng)的數(shù)據(jù)操作的數(shù)據(jù)庫，等待全局交易中的其他參與方操作完成的時(shí)間長度。
舉例說明：
假設(shè)一個(gè)全局交易由以下幾個(gè)部分組成：
?。?）tpbegin（T,0） ->
?。?）tpcall(S1) -> DB1 完成耗時(shí) T1;
?。?）tpcall(S2) -> DB2 完成耗時(shí) T2;
?。?）其他操作 耗時(shí) T3
?。?）tpcommit()
其中，tpcall(S1)訪問數(shù)據(jù)庫DB1, tpcall(S2)訪問數(shù)據(jù)庫DB2。
對DB1而言，如果T-T1> T2+T3 > SESTM1,則觸發(fā)超時(shí)；
對DB2而言，如果T-T1-T2 > T3 > SESTM2,則觸發(fā)超時(shí)；
由此可以看出，此參數(shù)的主要目的是對數(shù)據(jù)庫進(jìn)行資源保護(hù)，避免在全局交易中，已經(jīng)完成任務(wù)的數(shù)據(jù)庫，為等待其他參與方耗費(fèi)過多的資源，畢竟ORACLE中并發(fā)全局交易的數(shù)量是很有限的。
2.14.6 超時(shí)后果
觸發(fā)此超時(shí)后，數(shù)據(jù)庫將自己主動回滾已經(jīng)完成的任務(wù)，釋放全局交易資源。TUXEDO控制的全局交易進(jìn)行TPCOMMIT時(shí)，如果總時(shí)間仍沒有超過Transaction TimeOut，那么TPCOMMIT將失敗，XALOG會記錄下ORACLE錯(cuò)誤："ORA-24756: Transaction does not exist"。確實(shí)如此，拿上面的例子來說，等到最后TPCOMMIT的時(shí)候，DB1已經(jīng)主動回滾了所有的數(shù)據(jù)，不難理解，對DB1而言，它好像根本沒有參加過這個(gè)全局交易，自然就會有這樣的錯(cuò)誤提示。
2.14.7 設(shè)置考慮
這個(gè)參數(shù)是從數(shù)據(jù)庫自我保護(hù)的角度設(shè)計(jì)的，對數(shù)據(jù)庫而言，是不得已的辦法。最好的措施還是TUXEDO能夠控制時(shí)間，趕在SESTM之前，進(jìn)行TPABORT，主動通知數(shù)據(jù)庫進(jìn)行數(shù)據(jù)回滾。
用一個(gè)簡單的比方：冬天，客人出門時(shí)沒有關(guān)門，SESTM時(shí)間后，客人還沒有回來，主人感覺到冷了，只好自己去關(guān)門，不管什么理由，這樣總是不太好。如果在SESTM時(shí)間內(nèi)，客人能及時(shí)回來關(guān)門，主人就不會感覺那么差。
從前面的超時(shí)觸發(fā)分析，我們也能發(fā)現(xiàn)，只要設(shè)置SESTM 能夠大于 TransactionTimeOut的話，就能夠盡量的不觸發(fā)此超時(shí)機(jī)制，達(dá)到較好的效果。
2.15 ORACLE XA OPENINFO參數(shù)：SESWT
2.15.1 參數(shù)出處
UBBCONFIG配置文件 -> GROUPS -> OPENINFO -> SESWT。
2.15.2 時(shí)間單位
秒。
2.15.3 取值范圍
大于0。
2.15.4 默認(rèn)取值
60 。
2.15.5 用途解釋
會話繁忙等待時(shí)長，指全局交易中的一個(gè)交易分支（transaction branch）正在一個(gè)會話（session）中處理數(shù)據(jù)過程中，如果第二個(gè)會話也要對此交易分支進(jìn)行操作，那么第二個(gè)會話必須等待第一個(gè)會話完成，如果在等待SESWT后，第一個(gè)會話仍然沒有完成，那么第二個(gè)分支將觸發(fā)此超時(shí)。
舉例說明：
假設(shè)一個(gè)全局交易由以下幾個(gè)部分組成：
?。?）tpbegin（T,0） ->
?。?）tpcall(S1) -> DB1 完成數(shù)據(jù)操作耗時(shí) T1;
（3）tpcall(S2) -> DB2 完成數(shù)據(jù)操作耗時(shí) T2;
?。?）其他操作 耗時(shí) T3
?。?）tpcommit()
其中，tpcall(S1)訪問數(shù)據(jù)庫DB1, tpcall(S2)訪問數(shù)據(jù)庫DB2，任何操作失敗后，將調(diào)用tpabort。
假設(shè) T1+T2 > T > T1，也就是說，在成功執(zhí)行第二步tpcall(S1)后，應(yīng)用執(zhí)行到第三步tpcall(S2)，在執(zhí)行過程中，將觸發(fā)TransactionTimeout，tpcall（S2）將返回錯(cuò)誤，應(yīng)用將立即調(diào)用tpabort進(jìn)行交易回滾，DB1的數(shù)據(jù)將立刻回滾；而DB2并不能中斷tpcall(S2)引起的數(shù)據(jù)操作，對于ORACLE DB2而言，tpcall(S2)引起的數(shù)據(jù)操作屬于第一個(gè)會話，而tpabort引起的數(shù)據(jù)庫回滾操作是通過XA接口，屬于第二個(gè)會話，所以，tpabort作用到DB2上，只有等待第一個(gè)會話完成，如果等待SESWT后，第一個(gè)會話仍然沒有完成，即SESTM
2.15.6 超時(shí)后果
系統(tǒng)將返回XA_RETRY錯(cuò)誤，提示TMS此操作不能完成，需再試一次。如果應(yīng)用程序?qū)Υ藳]有再次嘗試的話，仍以上例說明，DB2只能利用SESTM2，觸發(fā)超時(shí)，自動回滾。
2.15.7 設(shè)置考慮
查閱ORACLE相關(guān)資源，發(fā)現(xiàn)oracal9.2與以前版本效果不同，以前的版本都是第二個(gè)會話在等待SESWT后，如果第一個(gè)會話操作仍然沒有結(jié)束，第二個(gè)會話能夠使第一個(gè)會話操作立即進(jìn)行有效的回滾，使第一個(gè)會話返回錯(cuò)誤：ORA-24761。
不難理解，兩者的區(qū)別是，打個(gè)簡單比方說，A正在用杯子喝水時(shí)，B要A放下杯子，B等待SESWT后：
oracle9.2的做法很民主，A還沒有用完，通知B，A還在用杯子，不能放下，還想讓A放下杯子，可以，再來一次；也就是說，只要A在用，B就不能讓人家放下杯子，某種程度上，A代表了強(qiáng)權(quán)。
Oracle9.2之前版本的做法很粗暴，通知A不能使用這個(gè)杯子了，必須放下，因?yàn)锽讓你放下，而且已經(jīng)等很久了，某種程度上，B代表了強(qiáng)權(quán)。
因此，如果是ORACLE9.2后的版本，SESWT適當(dāng)放長一些，畢竟還是希望能夠等到能做事的時(shí)候，把想做的事情做了。如果是以前的版本，SESWT適當(dāng)放短一些，反正一定能等到，為什么不少等一會兒呢？
2.16 ORACLE sqlnet.expire_time
2.16.1 參數(shù)出處
$ORACLE_HOME/network/admin/sqlnet.ora -> expire_time 。
2.16.2 時(shí)間單位
分鐘。
2.16.3 取值范圍
大于0。
2.1*** 默認(rèn)取值
無 。
2.16.5 用途解釋 ⑾
死聯(lián)接檢測DCD(Dead Connection Detection)是 SQL*NetV2.1 和此版本以后的一個(gè)新特性, 當(dāng)它檢測到對方 c/s 或者s/s 聯(lián)接意外終止時(shí), 釋放相關(guān)占用的資源。
DCD 起初是專為客戶機(jī)沒有從會話中斷開聯(lián)接的情況下斷電的環(huán)境設(shè)計(jì)的。
DCD由服務(wù)端開始建立聯(lián)接。 這時(shí)候SQL*Net 從參數(shù)文件中讀取變量, 設(shè)置一個(gè)定時(shí)器定時(shí)產(chǎn)生信號。 這個(gè)時(shí)間間隔是sqlnet.ora文件中的SQLNET.EXPIRE_TIME提供的。
當(dāng)定時(shí)器設(shè)定的時(shí)間到了之后, 服務(wù)器上的SQL*Net 發(fā)送一個(gè)探測包到客戶端。(如果是數(shù)據(jù)庫聯(lián)接, 目的端的服務(wù)器發(fā)送探測包到另一端)。 探測包是由空的SQL*Net包組成, 不體現(xiàn)SQL*Net層任何數(shù)據(jù), 但會在下一層的網(wǎng)絡(luò)協(xié)議中產(chǎn)生數(shù)據(jù)流量。
如果客戶端的聯(lián)接仍然是活動的, 探測包被丟棄,計(jì)時(shí)裝置復(fù)位。 如果客戶端異常斷掉，服務(wù)器將收到由發(fā)送探測包的調(diào)用發(fā)出的錯(cuò)誤。
2.16.6 超時(shí)后果
服務(wù)器將收到由發(fā)送探測包的調(diào)用發(fā)出的錯(cuò)誤，SQL*Net 將會通知操作系統(tǒng)釋放聯(lián)接占用的資源。
需要說明的是, SQL*Net 2.1.x中 一個(gè)活動的孤兒進(jìn)程（active orphan process） ，如單獨(dú)的查詢進(jìn)程，在查詢完成之前不會被殺掉。 在SQL*Net 2.2中，孤兒進(jìn)程占用的資源將會被無條件釋放，不管查詢是否結(jié)束。
2.16.7 設(shè)置考慮
ORACLE 在NT操作系統(tǒng)上，此功能表現(xiàn)很差，檢測出的無效聯(lián)接（dead connection）不能被盡快釋放，而必須等到數(shù)據(jù)庫重新啟動時(shí)才釋放。SQL*Net v2.3以后版本改善了以上問題。
此功能只是服務(wù)器的特性，如果不設(shè)置此參數(shù)，此功能將不啟動。按照ORACLE的建議，對大多數(shù)應(yīng)用來說，設(shè)置10分鐘較合適，其實(shí)關(guān)鍵還是分析應(yīng)用系統(tǒng)的實(shí)際情況。
同時(shí)，不難理解，作為一個(gè)數(shù)據(jù)庫自我管理的機(jī)制，也是要占用數(shù)據(jù)庫資源和網(wǎng)絡(luò)資源的，太頻繁的探測同樣會降低系統(tǒng)和網(wǎng)絡(luò)的性能。在低速網(wǎng)絡(luò)上，設(shè)置此參數(shù)，就需更為慎重。
客戶端不需要設(shè)置此參數(shù)。
2.17 ORACLE distributed_lock_timeout
2.17.1 參數(shù)出處
ORACLE初始參數(shù)文件：init.ora -> distributed_lock_timeout。
2.17.2 時(shí)間單位
秒。
2.17.3 取值范圍
大于0。
2.17.4 默認(rèn)取值
60 。
2.17.5 用途解釋
分布式事務(wù)鎖等待超時(shí)（distributed transaction waiting for lock），指第二個(gè)事務(wù)處理需要的數(shù)據(jù)庫資源，正被第一個(gè)分布式事務(wù)占用而鎖定，那么，第二個(gè)事務(wù)將等待第一個(gè)分布式事務(wù)釋放此資源，等待distributed_lock_timeout時(shí)間后，如果第一分布式事務(wù)仍然沒有釋放此資源，第二個(gè)事務(wù)觸發(fā)此超時(shí)。
2.17.6 超時(shí)后果
如果資源被第一個(gè)事務(wù)正常使用鎖定，ORACLE回滾第二個(gè)事務(wù)，并返回錯(cuò)誤："ORA-02049: time-out: distributed transaction waiting for lock "。
如果第一個(gè)事務(wù)處理完成，資源釋放后，再嘗試第二個(gè)事務(wù)，就會成功。如果第二個(gè)事務(wù)不能等待資源自動釋放，那么可以采用處理數(shù)據(jù)庫死鎖（deadlock）的措施，人工介入，清除第一個(gè)事務(wù)，但一般不建議采用這種方式，因?yàn)榈谝粋€(gè)事務(wù)一般會正常結(jié)束的。
如果資源被第一個(gè)事務(wù)因?yàn)樘幱诓淮_定分布事務(wù)狀態(tài)（in-doubt distributed transaction）而鎖定，ORACLE回滾第二個(gè)事務(wù)，并返回錯(cuò)誤："ORA-01591: lock held by in-doubt distributed transaction identifier "。
這種錯(cuò)誤遇到的可能性較小，一般只有在分布事務(wù)的關(guān)鍵提交階段出現(xiàn)網(wǎng)絡(luò)、系統(tǒng)故障，才可能出現(xiàn)此故障，而且，當(dāng)網(wǎng)絡(luò)、系統(tǒng)故障恢復(fù)后，ORACLE一般可以自己解決此問題，不需要人工介入。如果一定要人工介入，可以查閱ORACLE專門的手冊。
2.17.7 設(shè)置考慮
出現(xiàn)這樣的超時(shí)，是因?yàn)樘囟〝?shù)據(jù)庫資源的使用碰撞，要分析應(yīng)用系統(tǒng)的業(yè)務(wù)特點(diǎn)，確定碰撞可能發(fā)生的條件，在此條件下，資源可能被先來者鎖定多長時(shí)間（T1），后來者又能夠等多長時(shí)間（T2），再來設(shè)置此參數(shù)（T）的大小。如果在大多數(shù)情況下，T1 < T2, 那么就設(shè)置T1 < T < T2；反之，大多數(shù)情況下，T1 > T2，那么，就設(shè)置T < T2。
因此，不分析業(yè)務(wù)特點(diǎn)，一味的增大和減小是不恰當(dāng)?shù)摹?/p>
2.18 ORACLE Max_commit_propagation_delay
2.18.1 參數(shù)出處
ORACLE初始文件:init.ora -> Max_commit_propagation_delay。
2.18.2 時(shí)間單位
0.01秒。
2.18.3 取值范圍
0 ～ 90000。
2.18.4 默認(rèn)取值
700 。
2.18.5 用途解釋
最大提交傳播時(shí)延（MAX_COMMIT_PROPAGATION_DELAY，簡稱MCPD），在ORACLE RAC(或OPS)環(huán)境中才使用，表示在RAC系統(tǒng)中，一個(gè)instance系統(tǒng)提交產(chǎn)生的最新系統(tǒng)改變碼（SCN），能夠以多快的速度反應(yīng)到另一個(gè)instance中。
舉例說明，RAC系統(tǒng)，有A,B兩個(gè)實(shí)例（instance），A、B本地系統(tǒng)改變碼為SCN1，A更新數(shù)據(jù)DATA1提交， LGWR操作完成后，A本地系統(tǒng)改變碼為SCN2，經(jīng)過不大于MAX_COMMIT_PROPAGATION_DELAY時(shí)間后，B系統(tǒng)本地改變碼才變?yōu)镾CN2。
2.18.6 超時(shí)后果
Global Cache Services 將刷新RAC中的SCN。不管SCN是否及時(shí)刷新，后續(xù)的數(shù)據(jù)查詢都不會因此產(chǎn)生數(shù)據(jù)庫錯(cuò)誤。但，在此時(shí)間內(nèi)，有可能查詢結(jié)果不是最新數(shù)據(jù)，產(chǎn)生讀一致性（read consistency）問題。
2.18.7 設(shè)置考慮
RAC環(huán)境中的所有實(shí)例，此參數(shù)值必須相同。
ORACLE8i后，建議常用的兩個(gè)值是0和700（默認(rèn)），其他數(shù)值皆不建議。其實(shí)，這兩個(gè)數(shù)值就代表了RAC環(huán)境中，兩種SCN 產(chǎn)生機(jī)制：
Lamport Scheme和 Broadcast on Commit scheme。
設(shè)置為默認(rèn)值700，表示采用Lamport Scheme，SCN改變不會完全同步，同步將在 7秒鐘內(nèi)完成，而不是總等待7秒鐘后才完成。如果系統(tǒng)比較空閑，同步可能在0.5秒（甚至更短時(shí)間）內(nèi)完成；不管系統(tǒng)多繁忙，同步時(shí)間也不可能超過7秒。不難理解，采用此模式，整個(gè)RAC系統(tǒng)的運(yùn)行效率較高。
設(shè)置為0，表示采用Broadcast on Commit scheme，SCN改變完全同步。每當(dāng)commit時(shí)（即LGWR 寫redo log時(shí)）：
?。?LGWR發(fā)送消息更新全局SCN（global SCN），
－ LGWR 發(fā)送消息給每個(gè)活動的實(shí)例更新其本地SCN（local SCN）。
有資料說，只要MCPD < 700，系統(tǒng)將采用Broadcast on Commit scheme。
Lamport Scheme能夠適應(yīng)絕大部分應(yīng)用的要求，只有個(gè)別實(shí)時(shí)性特別高的業(yè)務(wù)，才需要Broadcast on Commit scheme。通過分析，不難理解，Broadcast on Commit scheme將需要更多的系統(tǒng)資源。
3 總結(jié)
以上所有時(shí)間參數(shù)，都是tuxedo系統(tǒng)或ORACLE數(shù)據(jù)庫系統(tǒng)提供的時(shí)間控制機(jī)制，更多的是從維護(hù)本系統(tǒng)自身安全的角度，建立起相互之間溝通的規(guī)則。在Client 端，中間件服務(wù)器，數(shù)據(jù)服務(wù)器這相互聯(lián)系的三者之間，用一個(gè)簡單的比方，就是先保證自己盡量不給相關(guān)人帶來麻煩；一旦相關(guān)人出了麻煩，自己能夠自我保障，不受別人干擾。
這些時(shí)間參數(shù)還有的一個(gè)共性的特點(diǎn)就是"不精確"，如果業(yè)務(wù)需要要精確到1秒，則必須依靠業(yè)務(wù)程序中更精確的時(shí)間編程。
總之，要保障整個(gè)業(yè)務(wù)系統(tǒng)的有效性和健壯性，必須了解都有哪些時(shí)間參數(shù)？都表示什么意思？都起哪些作用？自己的業(yè)務(wù)應(yīng)用對時(shí)間要求是怎樣的？這些參數(shù)該如何配置才能滿足應(yīng)用的要求？希望本文能夠在以上方面給大家?guī)硪稽c(diǎn)方便。
4 后記
自2002年真正在項(xiàng)目中利用TUXEDO起，就發(fā)現(xiàn)已有資料在時(shí)間參數(shù)解釋方面的缺憾，那時(shí)，就有寫這樣一個(gè)專題的打算，開始收集這方面的資料。由于后來工作內(nèi)容的變化，也就沒有精力再作整理，但心里一直惦記著這件事情。直到前些天知道了BEA的這個(gè)活動，再到網(wǎng)絡(luò)上搜集資料，發(fā)現(xiàn)已經(jīng)有了一些類似的資料，但感覺仍然不夠完整，不夠透徹，因此，我認(rèn)為整理這樣一個(gè)專題資料，還是有必要的，便下決心借此機(jī)會做完這件事情。經(jīng)過近十天的查閱、整理，終于完成，算是了我多年夙愿。
文中的參數(shù)，我僅僅使用過其中的12個(gè)，其他未用參數(shù)，主要是靠查閱資料和邏輯分析，根據(jù)我自己的理解進(jìn)行解釋，再加上時(shí)間倉促，或遺漏、不妥之處，敬請指正，讓我們一起來使此《功略》更準(zhǔn)確、更全面，讓更多的人從中受益。
5 參考文獻(xiàn)
http://e-docs.bea.com BEA TUXEDO RELEASE 7.1 。
http://dev2dev.bea.com.cn/techdoc/tuxedo/20030230.html 《Tuxedo 中關(guān)于時(shí)間的參數(shù)的說明》作者：不詳 。
《ORACLE8i Reference》。
《ORACLE9i Reference》。
《ORACLE8i Parallel Server Concepts and Administration》。
《ORACLE8i Application Developers Guide - Fundamentals》。
http://metalink.oracle.com 相關(guān)問題解決資料。
http://www.chinaunix.net 《DCD死聯(lián)接檢測》作者：yukaikai
注：文章中標(biāo)注⑴～⑽涉及的內(nèi)容，引自參考文獻(xiàn)-2 ，標(biāo)注⑾涉及的內(nèi)容，引自參考文獻(xiàn)-8 。