Tuxedo 超时时间控制（转贴）

以下是转贴：

TUXEDO超时控制全功略

摘要：
本《功略》集中了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.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后，第一个会话仍然没有完成，即SESTM<T1+T2-T时，那么触发此超时。

2.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 参数出处
/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 端，中间件服务器，数据服务器这相互联系的三者之间，用一个简单的比方，就是先保证自己尽量不给相关人带来麻烦；一旦相关人出了麻烦，自己能够自我保障，不受别人干扰。

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

实例补充：db2 -952错误

查询数据库本身锁超时时间为180秒

tuxedo   tpbegin(TIME_OUT,0) 中TIME_OUT时间设置为30秒

生产交易在tps大时，报-952错误

解决方案：将TIME_OUT时间配置大于数据库超时时间