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 默认取值

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 参数出���

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 默认取值

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 取值范围

2.18.4 默认取值

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 参考文献

http://dev2dev.bea.com.cn/techdoc/tuxedo/20030230.html 《Tuxedo 中关于时间的参数的说明》作者：不详 。

http://metalink.oracle.com 相关问题解决资料。

http://www.chinaunix.net 《DCD死联接检测》作者：yukaikai

  注：文章中标注⑴～⑽涉及的内容，引自参考文献-2 ，标注⑾涉及的内容，引自参考文献-8 。

[文章评论]

原文出处:

作者简介

姜晓亮:（dev2dev ID:xljiang ）北京大唐中联系统集成有限公司 产品拓展部。