今天上午碰到一个报错：

ORA-02049:timeout:distributed transaction waiting for lock

但是并未对业务造成实际影响，过了一段时间后好了。因为那段时间，用户连续做了100笔的核销业务。

【经查】

ORA-02049错误说明如下:

ORA-02049:timeout:distributed transaction waiting for lock

cause:exceeded INIT.ORA distributed_lock_timeout seconds waiting for lock.

action:treat as a deadlock.

【解决】

1、先查是否又死锁出现：

SELECT l.session_id sid, s.serial#, l.locked_mode,l.oracle_username,

l.os_user_name,s.machine, s.terminal, o.object_name, s.logon_time

FROM v$locked_object l, all_objects o, v$session s

WHERE l.object_id = o.object_id

AND l.session_id = s.sid

ORDER BY sid, s.serial#;

有的话可以根据业务实际情况考虑杀掉，恢复正常业务

alter system kill session 'sid,serial#';

2、再查一个参数distributed_lock_timeout，可以考虑是否需要调优

最好不要去调这个参数，除非业务被影响到，并且通过应用程序无法避免这个问题

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。

因此，不分析业务特点，一味的增大和减小是不恰当的。

【这篇文章前面的部分也可以看一下的】