oracle死锁超时配置

我有以下疑问：

select col from tbl where id in (....) for update

所以这个查询从表中选择一些行并锁定它们

其中一些行已被其他客户端锁定（

sqldeveloper

，如果这很重要的话），因此此查询在等待sqldeveloper释放锁定的行时被阻止

经过一段时间（大约2小时）后，执行第一个查询的会话得到了

ORA-01002:fetch-out-of-sequence异常

。我检查了跟踪文件，oracle将这种情况视为死锁

在跟踪文件中，我发现了以下内容

DUMP LOCAL BLOCKER: initiate state dump for TIMEOUT

因此，锁似乎有一些超时，在此之后它们被视为死锁。我可以配置它吗

跟踪文件

*** 2013-09-06 15:32:07.204
*** SESSION ID:(971.57585) 2013-09-06 15:32:07.204
*** CLIENT ID:() 2013-09-06 15:32:07.204
*** SERVICE NAME:(asd) 2013-09-06 15:32:07.204
*** MODULE NAME:(JDBC Thin Client) 2013-09-06 15:32:07.204
*** ACTION NAME:() 2013-09-06 15:32:07.204

DUMP LOCAL BLOCKER/HOLDER: block level 5 res [0x60004][0x2729b9],[TX][ext 0x2,0x0]
----------resource 0x85e8435c0----------------------
resname       : [0x60004][0x2729b9],[TX][ext 0x2,0x0]
hash mask     : x3
Local inst    : 2
dir_inst      : 2
master_inst   : 2
hv idx        : 17
hv last r.inc : 54
current inc   : 54
hv status     : 0
hv master     : 0
open options  : dd
grant_bits    : KJUSERNL KJUSEREX
grant mode    : KJUSERNL  KJUSERCR  KJUSERCW  KJUSERPR  KJUSERPW  KJUSEREX
count         : 1         0         0         0         0         1
val_state     : KJUSERVS_NOVALUE
valblk        : 0x2000483508000000b01e483508000000  H5H5
access_inst   : 2
vbreq_state   : 0
state         : x0
resp          : 0x85e8435c0
On Scan_q?    : N
Total accesses: 3589
Imm.  accesses: 3151
Granted_locks : 1
Cvting_locks  : 1
value_block:  20 00 48 35 08 00 00 00 b0 1e 48 35 08 00 00 00
GRANTED_Q :
lp 0x853b8d380 gl KJUSEREX rp 0x85e8435c0 [0x60004][0x2729b9],[TX][ext 0x2,0x0]
  master 2 gl owner 0x85d645fc8 possible pid 17202 xid 45000-0002-000019AC bast 0 rseq 46 mseq 0 history 0x14951495
  open opt KJUSERDEADLOCK
CONVERT_Q:
lp 0x853b8d8f0 gl KJUSERNL rl KJUSEREX rp 0x85e8435c0 [0x60004][0x2729b9],[TX][ext 0x2,0x0]
  master 2 gl owner 0x85d63d0e8 possible pid 17571 xid 65000-0002-00001383 bast 0 rseq 46 mseq 0 history 0x1495149a
  convert opt KJUSERGETVALUE
----------enqueue 0x853b8d380------------------------
lock version     : 987233
Owner inst       : 2
grant_level      : KJUSEREX
req_level        : KJUSEREX
bast_level       : KJUSERNL
notify_func      : (nil)
resp             : 0x85e8435c0
procp            : 0x8523993e8
pid              : 17571
proc version     : 281
oprocp           : (nil)
opid             : 17571
group lock owner : 0x85d645fc8
possible pid     : 17202
xid              : 45000-0002-000019AC
dd_time          : 0.0 secs
dd_count         : 0
timeout          : 0.0 secs
On_timer_q?      : N
On_dd_q?         : N
lock_state       : GRANTED
ast_flag         : 0x0
Open Options     : KJUSERDEADLOCK
Convert options  : KJUSERNOQUEUE KJUSERNODEADLOCKWAIT
History          : 0x14951495
Msg_Seq          : 0x0
res_seq          : 46
valblk           : 0x68f4c180ff7f00000100000000000000 h
user session for deadlock lock 0x853b8d380
  sid: 965 ser: 10351 audsid: 13432555 user: 500/asd
    flags: (0x8100045) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
    flags2: (0x40009) -/-/INC
  pid: 69 O/S info: user: oracle, term: UNKNOWN, ospid: 17202
    image: oracle@asd
  client details:
    O/S info: user: jboss, term: unknown, ospid: 1234
    machine: asd.asd.com program: JDBC Thin Client
    application name: JDBC Thin Client, hash value=2546894660
  current SQL:
  <sql query omitted>
DUMP LOCAL BLOCKER: initiate state dump for TIMEOUT
  possible owner[69.17202] on resource TX-00060004-002729B9

*** 2013-09-06 15:32:07.204
Submitting asynchronized dump request [28]. summary=[ges process stack dump (kjdglblkrdm1)].

***2013-09-06 15:32:07.204
***会话ID:（971.57585）2013-09-06 15:32:07.204
***客户ID:（）2013-09-06 15:32:07.204
***服务名称：（asd）2013-09-06 15:32:07.204
***模块名称：（JDBC瘦客户端）2013-09-06 15:32:07.204
***动作名称：（）2013-09-06 15:32:07.204
转储本地阻止程序/保持器：块级别5分辨率[0x60004][0x2729b9]，[TX][ext 0x2,0x0]
----------资源0x85e8435c0----------------------
resname:[0x60004][0x2729b9]，[TX][ext 0x2,0x0]
哈希掩码：x3
本地研究所：2
主任：2
硕士研究所：2
hv-idx:17
hv last r.inc:54
现任公司：54
高压状态：0
高压主机：0
开放选项：dd
赠款：KJUSERNL KJUSEREX
授予方式：KJUSERNL KJUSERCR KJUSERCW KJUSERPR KJUSERPW KJUSEREX
计数：1 0 0 1
瓦卢州：KJUSERVS_NOVALUE
valblk:0x200048350800000B01E48350800000H5
访问说明：2
vbreq_状态：0
州：x0
响应：0x85e8435c0
在扫描时N
访问总数：3589
伊姆。访问：3151
已授予的锁定：1
CVU锁：1
值块：20 00 48 35 08 00 00 b0 1e 48 35 08 00 00
授予(Q):
lp 0x853b8d380 gl KJUSEREX rp 0x85e8435c0[0x60004][0x2729b9]，[TX][ext 0x2,0x0]
主2总账所有者0x85d645fc8可能pid 17202 xid 45000-0002-000019AC bast 0 rseq 46 mseq 0历史0x14951495
打开opt KJUSERDEADLOCK
转换为：
lp 0x853b8d8f0 gl KJUSERNL rl KJUSEREX rp 0x85e8435c0[0x60004][0x2729b9]，[TX][ext 0x2,0x0]
主2总账所有者0x85d63d0e8可能的pid 17571 xid 65000-0002-00001383 bast 0 rseq 46 mseq 0历史0x1495149a
转换opt KJUSERGETVALUE
----------排队0x853b8d380------------------------
锁定版本：987233
业主说明：2
授予等级：KJUSEREX
需求级别：KJUSEREX
基本等级：KJUSERNL
通知职能：（无）
响应：0x85e8435c0
程序：0x8523993e8
pid:17571
程序版本：281
oprocp：（无）
opid:17571
组锁所有者：0x85d645fc8
可能的pid:17202
xid:45000-0002-000019AC
dd_时间：0.0秒
dd_计数：0
超时：0.0秒
在计时器上N
关于什么N
锁定状态：已授予
ast_标志：0x0
打开选项：KJUSERDEADLOCK
转换选项：KJUSERNOQUEUE KJUSERNODEADLOCKWAIT
历史记录：0x14951495
消息顺序：0x0
决议如下：46
valblk:0x68F4C180FF7F00000000000000小时
死锁锁0x853b8d380的用户会话
sid:965 ser:10351 audsid:13432555用户：500/asd
标志：（0x8100045）USR/-flags\u idl：（0x1）BSY/-/-/-/-/-
flags2：（0x40009）-/-/INC
pid:69 O/S信息：用户：oracle，术语：未知，ospid:17202
图片：oracle@asd
客户详细信息：
O/S信息：用户：jboss，术语：未知，ospid:1234
machine:asd.asd.com程序：JDBC瘦客户端
应用程序名称：JDBC瘦客户端，哈希值=2546894660
当前SQL：
转储本地阻止程序：为超时启动状态转储
资源TX-00060004-002729B9上的可能所有者[69.17202]
*** 2013-09-06 15:32:07.204
提交异步转储请求[28]。summary=[ges进程堆栈转储（kjdglblkrdm1）]。

我没有看到任何迹象表明Oracle将这种情况视为死锁。如果Oracle发现存在死锁，它将引发ORA-00060错误并生成死锁跟踪文件

默认情况下，Oracle将允许简单的阻止锁永久阻止，而不终止阻止程序或服务程序。但是，您可以通过使用

wait

子句来控制要等待的时间。比如说

select col 
  from tbl 
 where id in (....) 
   for update wait 30

指定要等待最多30秒才能锁定行。如果行在此之后保持锁定，您将收到ORA-30006错误“资源繁忙；获取时等待超时已过期”

---

我的猜测是，您看到的行为表明您的DBA使用了。您可以与DBA讨论更改该计划，但如果您发现希望不同的查询和不同的应用程序具有不同的超时，则通常会更加复杂，更难进行微调。

只需使用跟踪文件内容更新查询，以防可能提供任何其他信息

DBA\u RSRC\u PLAN\u指令

其中

MAX\u IDLE\u BLOCKER\u TIME

和

MAX\u IDLE\u TIME

均为空