Wait events Oracle 11g – enqueues | DBAORA查看: 2240|回复: 16
一个有关enqueue的奇怪问题
论坛徽章:1
有个oracle9i数据库最近出过这么个问题:
有个并行批量系统的多个数据库进程无法退出。
检查数据库后，发现存在enqueue等待，结合检查v$session_wait,v$lock,v$session,v$sqlarea等视图找到了处于enqueue的对象（通过TM 的id1得到），也找到了操作这些对象的sql语句。
在v$lock中的表现为 sesssion 的TX＋TM lock.到这里可以简单的理解为有个session update该对象的某条记录没有执行commit也没退出，其他session update这条记录时就等在那里。
奇怪的问题来了。再开一个session，对该表（表不大，几千条记录）做了个全表的update，竟然成功的。而那几个处理enqueue等待状态的session还是等在那里。
不知道如何解释这个现象。
认证徽章论坛徽章:131
Re: 一个有关enqueue的奇怪问题
Check PK or UK
最初由 longbow 发布
[B]有个oracle9i数据库最近出过这么个问题:
有个并行批量系统的多个数据库进程无法退出。
检查数据库后，发现存在enqueue等待，结合检查v$session_wait,v$lock,v$session,v$sqlarea等视图找到了处于enqueue的对象（通过TM 的id1得到），也找到了操作这些对象的sql语句。
在v$lock中的表现为 sesssion 的TX＋TM lock.到这里可以简单的理解为有个session update该对象的某条记录没有执行commit也没退出，其他session update这条记录时就等在那里。
奇怪的问题来了。再开一个session，对该表（表不大，几千条记录）做了个全表的update，竟然成功的。而那几个处理enqueue等待状态的session还是等在那里。
不知道如何解释这个现象。 [/B]
认证徽章论坛徽章:131
Primary key or Unique index
论坛徽章:18
贴一下session_wait和v$lock吧，注意格式
论坛徽章:92
还有一种情况
time 1 : A update table t1 row r1
time 2:A set a savepoint
time 3:A update table t1 row r2
time 4:B update table t1 row r2&&&------- got block by A
time 5:A rollback to its savepoint , but B still will blocked by A ;&&becuase it's a TX enqueue
time 6:C update table t1 row r2 successfully.
论坛徽章:52
Re: 一个有关enqueue的奇怪问题
最初由 longbow 发布
[B]有个oracle9i数据库最近出过这么个问题:
有个并行批量系统的多个数据库进程无法退出。
检查数据库后，发现存在enqueue等待，结合检查v$session_wait,v$lock,v$session,v$sqlarea等视图找到了处于enqueue的对象（通过TM 的id1得到），也找到了操作这些对象的sql语句。
在v$lock中的表现为 sesssion 的TX＋TM lock.到这里可以简单的理解为有个session update该对象的某条记录没有执行commit也没退出，其他session update这条记录时就等在那里。
奇怪的问题来了。再开一个session，对该表（表不大，几千条记录）做了个全表的update，竟然成功的。而那几个处理enqueue等待状态的session还是等在那里。
不知道如何解释这个现象。 [/B]
给你一个sql找到引起enqueue wait的blocker的sid,看一下它的状态及其等待事待，如果急于处理，将其alter system kill session。。掉enqueue锁就解除了。
SELECT DECODE(request,0,'Holder: ','Waiter: ')||sid
& && && &sess, id1, id2, lmode, request,
& & type FROM
& &V$LOCK WHERE (id1, id2, type)
& && && && & IN (SELECT id1, id2, type FROM V$LOCK WHERE request&0)
& &ORDER BY id1, request
你的全表的update不会是所有列*行都做了吧？最简单的测试是delet * from&&。。，怎么可能有enqueue还会成功？Fk？
论坛徽章:6
Re: Re: 一个有关enqueue的奇怪问题
最初由 hrb_qiuyb 发布
给你一个sql找到引起enqueue wait的blocker的sid,看一下它的状态及其等待事待，如果急于处理，将其alter system kill session。。掉enqueue锁就解除了。
SELECT DECODE(request,0,'Holder: ','Waiter: ')||sid
& && && &sess, id1, id2, lmode, request,
& & type FROM
& &V$LOCK WHERE (id1, id2, type)
& && && && & IN (SELECT id1, id2, type FROM V$LOCK WHERE request&0)
& &ORDER BY id1, request
请教一下，enqueue wait event 都有什么原因引起的呀？
论坛徽章:170
Re: Re: Re: 一个有关enqueue的奇怪问题
最初由 ok_zhixiang 发布
请教一下，enqueue wait event 都有什么原因引起的呀？ [/B]
多数是程序的问题，比如索引，主外键，还有就是ITL槽不足。
招聘 : 论坛徽章:25
把这个sql的output列一下：
column Username format A15
column Sid format 9990 heading SID
column Type format A4
column Lmode format 990 heading 'HELD'
column Request format 990 heading 'REQ'
column Id1 format 9999990
column Id2 format 9999990
break on Id1 skip 1 dup
SELECT /*+rule */ SN.Username, M.Sid, M.Type,
& && &&&DECODE(M.Lmode, 0, 'None', 1, 'Null', 2, 'Row Share', 3, 'Row
& && &&&Excl.', 4, 'Share', 5, 'S/Row Excl.', 6, 'Exclusive',
& && &&&LTRIM(TO_CHAR(Lmode,'990'))) Lmode,
& && &&&DECODE(M.Request, 0, 'None', 1, 'Null', 2, 'Row Share', 3, 'Row
& && &&&Excl.', 4, 'Share', 5, 'S/Row Excl.', 6, 'Exclusive',
& && &&&LTRIM(TO_CHAR(M.Request, '990'))) Request,
& && &&&M.Id1, M.Id2
& & FROM V$SESSION SN, V$LOCK M
& & WHERE (SN.Sid = M.Sid and M.Request ! = 0)
& && &&&or (SN.Sid = M.Sid and M.Request = 0 and Lmode != 4 and (id1, id2)
& && &&&in (select S.Id1, S.Id2 from V$LOCK S where Request != 0 and S.Id1
& && &&&= M.Id1 and S.Id2 = M.Id2) ) order by Id1, Id2, M.R
论坛徽章:2
9I，直接察看下
select *From db_waiters
itpub.net All Right Reserved. 北京皓辰网域网络信息技术有限公司版权所有　　　　
　北京市公安局海淀分局网监中心备案编号：　广播电视节目制作经营许可证：编号（京）字第1149号V$LOCK视图相关知识
1、V$LOCK视图结构
RAW（4 | 8）
of lock state object
RAW（4|8）
会话的sid，可以和v$session 关联
VARCHAR2(2)
区分该锁保护对象的类型（表4）
– DML enqueue
– Transaction enqueue
UL – User supplied
–我们主要关注TX和TM两种类型的锁
–UL锁用户自己定义的，一般很少会定义，基本不用关注
–其它均为系统锁，会很快自动释放，不用关注
ID1,ID2的取值含义根据type的取值而有所不同
ID1表示被锁定表的object_id 可以和dba_objects视图关联取得具体表信息，ID2 值为0
ID1以十进制数值表示该事务所占用的回滚段号和事务槽slot number号,其组形式:
0xRRRRSSSS,RRRR=RBS/UNDO NUMBER,SSSS=SLOT
ID2 以十进制数值表示环绕wrap的次数，即事务槽被重用的次数
0 – none
1 – null (NULL)
2 – row-S (SS)
3 – row-X (SX)
4 – share (S)
5 – S/Row-X (SSX)
6 – exclusive (X)
–大于0时，表示当前会话被阻塞，其它会话占有改锁的模式
已持有或者等待锁的时间
是否阻塞其他会话锁申请 1:阻塞 0:不阻塞
2、其它相关视图说明
主要字段说明
查询会话的信息和锁的信息。
sid,serial#：表示会话信息。
program：表示会话的应用程序信息。
row_wait_obj#：表示等待的对象,和dba_objects中的object_id相对应。
lockwait :该会话等待的锁的地址,与v$lock的kaddr对应.
v$session_wait
查询等待的会话信息。
sid：表示持有锁的会话信息。
Seconds_in_wait：表示等待持续的时间信息
Event：表示会话等待的事件，锁等于enqueue
对v$lock的格式化视图。
Session_id：和v$lock中的Sid对应。
Lock_type：和v$lock中的type对应。
Lock_ID1： 和v$lock中的ID1对应。
Mode_held,mode_requested：和v$lock中的lmode,request相对应。
v$locked_object
只包含DML的锁信息，包括回滚段和会话信息。
Xidusn,xidslot,xidsqn：表示回滚段信息。和v$transaction相关联。
Object_id：表示被锁对象标识。
Session_id：表示持有锁的会话信息。
Locked_mode：表示会话等待的锁模式的信息，和v$lock中的lmode一致。
行级共享锁，其他对象只能查询这些数据行
Select for update
Lock for update
Lock row share
行级排它锁,在提交前不允许做DML操作
Insert/update/Delete
Lock row share
Create index
Lock share
SSX(S/Row-X)
共享行级排它锁
Lock share row exclusive
X(Exclusive)
Alter table
Drop index
Truncate table
Lock exclusive
System Type
Description
System Type
Description
Buffer hash table instance
Library cache pin instance (A..Z =
namespace)
Control file schema global enqueue
Password File
Cross-instance function invocation instance
Parallel operation
Cursor bind
Process startup
datafile instance
Row cache instance (A..Z = cache)
Direct loader parallel index create
Redo thread global enqueue
Mount/startup db primary/secondary instance
System change number instance
Distributed recovery process
Distributed transaction entry
Sequence number instance
Sequence number enqueue
Space management operations on a specific segment
Sort segment
Instance number
Space transaction enqueue
Instance recovery serialization global enqueue
Sequence number value
Instance state
Generic enqueue
Library cache invalidation instance
Temporary segment enqueue (ID2=0)
New block allocation enqueue (ID2=1)
Thread kick
Temporary table enqueue
Library cache lock instance lock (A..P = namespace)
Mount definition global enqueue
Undo segment DDL
Media recovery
Being-written redo log instance
此条目发表在
分类目录。将加入收藏夹。
&&北京-小鹏&&
加我微信(xifenfei88)
WP Cumulus Flash tag cloud by
9 or better.博客访问： 446941
博文数量： 1429
注册时间：
ITPUB论坛APP
ITPUB论坛APP
APP发帖 享双倍积分
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： Linux
Enqueue介绍
enqueue是oracle中一种保护共享资源，应用于数据库对象、重做线程、后台工作的锁机制，用来控制多个并发会话在锁模式相容/不相容时如何共享相同的资源。排队是事务的，由应用程序初始化。
事件参数(oracle& 9i环境，在oracle 10g中参数2,3有所变化)
事件编号：15
事件名：enqueue
参数1：name|mode(不同的锁类型，id1与id2有不同的含义)
参数2：id1
参数3：id2
ORACLE使用内部数组结构来处理受到排队锁影响的数据库资源，可以通过x$ksqrs(内核服务排队资源)或v$resource视图来查看。
select s.ADDR as "资源对象地址", s.TYPE, s.ID1, s.ID2 from v$resource s
初始化参数enqueue_resources控制被锁管理器并发锁定的最大排队资源数（在EAPR1中，该值为21400）
NAME&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& TYPE&&&&&&& VALUE
------------------------------------ ----------- ------------------------------
enqueue_resources&&&&&&&&&&&&&&&&&&& integer&&&& 21400
查询系统资源的使用情况：
SELECT s.resource_name,
&&&&&& s.current_utilization AS "当前使用数",
&&&&&& s.max_utilization AS "系统最大使用数",
&&&&&& s.initial_allocation AS "系统初始化参数分配数",
&&&&&& s.limit_value
& FROM v$resource_limit s
&WHERE s.resource_name IN ('enqueue_resources', 'enqueue_locks', 'dml_locks',
&&&&&&& 'processes', 'processes')
RESOURCE_NAME&&&&&&& 当前使用数 系统最大使用数 系统初始化参数分配数&&&&&&&&&&&&&&&& LIMIT_VALUE
-------------------- ---------- -------------- -----------------------------------------------------
processes&&&&&&&&&&&&&&&&& 2329&&&&&&&&&& 3722&&&&&& 4000&&&&&&&&&&&&&&&&&&&&&&&&&&&&& &4000
enqueue_locks&&&&&&&&&&&&&& 372&&&&&&&&&& 1129&&&&& 54090&& &&&&&&&&&&&&&&&&&&&&&&&&&&&&54090
enqueue_resources&&&&&&&&&& 430&&&&&&&&&&& 812&&&&& 21400&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& UNLIMITED
dml_locks&&&&&&&&&&&&&&&&&&& 83&&&&&&&&&& 2168&&&&& 19380&&&&&&&&&&&&&&&&&&&& &&&&&&&&&&UNLIMITED
各种排队锁类型下，ID1和ID2的含义：
出现enqueue锁的处理：
监控事例的等待，查看是否有enqueue锁产生：
SELECT event,SUM(DECODE(wait_Time,0,0,1)) "Prev",
SUM(DECODE(wait_Time,0,1,0)) "Curr",COUNT(*) "Tot"
FROM v$session_Wait
GROUP BY event ORDER BY 4;
结果类似如下：
EVENT&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Prev&&&&&& Curr&&&&&&& Tot
------------------------------ ---------- ---------- ----------
SQL*Net message to client &&&&&&&&&&&&&&1&&&&&&&&& 0&&&&&&&&& 1
db file scattered read&&&&&&&&&&&&&&&&& 0&&&&&&&&& 1&&&&&&&&& 1
db file sequential read&&&&&&&&&&&&&&&& 0&&&&&&&&& 1&&&&&&&&& 1
pmon timer&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 0&&&&&&&&& 1&&&&&&&&& 1
smon timer&&&&&&&&&&&&&&& &&&&&&&&&&&&&&0&&&&&&&&& 1&&&&&&&&& 1
enqueue&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 0&&&&&&&&& 1&&&&&&&&& 1
rdbms ipc message&&&&&&&&&&&&&&&&&&&&&& 0&&&&&&&&& 8&&&&&&&&& 8
SQL*Net message from client&&&&&&&&&&&& 1&&&&&& 2411&&&&&& 2412
从上面结果中看出有1个enqueue的等待
查看等待的session信息
SQL> SELECT sid,seq#,event,p1,p2,p3,state FROM v$session_wait WHERE event = 'enqueue';
&&&&&& SID&&&&&& SEQ# EVENT&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& P1&&&&&&&& P2&&&&&&&& P3 STATE
---------- ---------- ------------------------------ ---------- ---------- ---------- -------------------
&&&&& 3505&&&&&& 1389 enqueue&&&&&&&&&&&&&&&&&&&&&&& &&& 2293783&&& 1111708 WAITING
可知目前在等待的session id为3505
通过查询下面视图，获知是谁在holding等待的资源：
SELECT * FROM dba_waiters
WAITING_SESSION &&&&&&&&&&&HOLDING_SESSION &&&LOCK_TYPE&&& MODE_HELD& MODE_REQUE&& LOCK_ID1&& LOCK_ID2
--------------- --------------- ------------ ---------- ---------- ---------- ----------
&&&&&&&&&& 3505&&&&&&&&&&&& 764 &&&&&&&&&&&&&&&Transaction& &&&Exclusive& Exclusive&&&& &&&&2293783&&& 1111708
从以上的查询中知道，session 3505在等待session 764 holding的资源
进一步，我们可以查询enqueue等待操作的语句：
FROM v$session_wait WHERE event = 'enqueue');
结果发现语句为：
处理：和EAI沟通后确认是否Kill掉阻塞的会话：
Enqueue类型
从enqueue等待事件中，解码排队类型及模式：
SELECT s.sid,
&&&&&& s.event,
&&& &&&s.p1,
&&&&&& s.p1raw,
&&&&&& chr(bitand(s.p1, -) / ) ||
&&&&&& chr(bitand(s.p1, ) / 65535) AS "TYPE",
&&&&&& MOD(s.p1, 16) AS "MODE"
& FROM v$session_wait s
&WHERE s.event = 'enqueue'
&&&&&& SID EVENT&&&&&&&&&&&&&&& P1 P1RAW&&&&&&&&&&& TYPE&&&&&&&& MODE
---------- ------------ ---------- ---------------- ------ ----------
&&&&& 3505 enqueue&&&&&
0006 &TX&&&&&&&&&&&&& 6
以上查询结果青表明，此时的enqueue锁类型为模式6的TX锁
同时，我们也可以从下列视图查询到enqueue的总体等待情况：
select * from& v$enqueue_
&& INST_ID EQ TOTAL_REQ# TOTAL_WAIT#& SUCC_REQ# FAILED_REQ# CUM_WAIT_TIME
---------- -- ---------- ----------- ---------- ----------- -------------
&&&&&&&& 1 TT&& &&&&&&&&&& 0&& &&&&&&&&&& 0&&&&&&&&&&&& 0
&&&&&&&& 1 TX& &&&& 1747438& &&&&&& 60038&&&
&&&&&&&& 1 US&& &&&&&&& 9698&& &&&&&&&&&& 0&&&&&&& 201940
&&&&&&&& 1 WL&&&&&& 4947&&&&&&&&&& 6&&&&&& 1611&&&&&&& 3336&&&&&&& 390928
&&&&&&&& 1 XR&&&&&&&&& 2&&&&&&&&&& 0&&&&&&&&& 2&&&&&&&&&& 0&&&&&&&& &&&&0
另外：在EAPR1中，目前deploy了抓取enqueue等待的脚本：
其中插入中结果表的语句为：
insert into perfstat.enqueue_wait select event,sql_hash_value,count(*) ,max(username) user1,min(username) user2 ,max(machine) machin
e1,min(machine) machine2,date1,time1 from& (select event,username,sql_hash_value,machine ,(select to_char(sysdate,'YYYY-MM-DD') from
&dual) date1,(select to_char(sysdate,'HH24:MI:SS') from dual) time1 from gv$session_wait a,gv$session b where a.inst_id=b.inst_id an
d a.sid=b.sid and a.event ='enqueue') group by event,sql_hash_value order by count(*)
该脚本以定时任务的方式每5分钟抓取一次：
###insert enqueue information to perfstat.enqueue_wait#####
0,5,10,15,20,25,30,35,40,45,50,55 *&& *&& *&& *&& /app/oracle/utils/zzg/enqueue_wait.sh >/dev/null
可以从以下查询中获知过去的一段时间出现的enqueue等待：
EVENT&&&&& SQL_HASH_VALUE&&&&& COUNT USER1&&&&& USER2&&&&& MACHINE1&& MACHINE2&& DATE1&&&&&&&&&&&&&&& TIME1
---------- -------------- ---------- ---------- ---------- ---------- ---------- -------------------- --------------------
enqueue&&&&&&&& &&&&&&&&& 1 HZBUILD&&& HZBUILD&&& eint-p02&& eint-p02&& &&&&&&&&&& 03:30:00
enqueue&&&&&&& &&&&&&&&& 6 HZBUILD&&& HZBUILD&&& eint-p03&& eint-p01&& &&&&&&&&&& 03:30:00
enqueue&&&&&&& &&&&&&&& 72 HZBUILD&&& HZBUILD&&& eint-p03&& eint-p01&& &&&&&&&&&& 03:30:00
enqueue&&&&&&&& &&&&&&&&& 1 HZBUILD&&& HZBUILD&&& eint-p03&& eint-p03&& &&&&&&&&&& 03:25:00
enqueue&&&&&&& &&&&&&&&& 3 HZBUILD&&& HZBUILD&&& eint-p03&& eint-p01&& &&&&&&&&&& 03:25:00
enqueue&&&&&&& &&&&&&&& 71 HZBUILD&&& HZBUILD&&& eint-p03&& eint-p01&& &&&&&&&&&& 03:25:00
enqueue&&&& &&&&&&&&&&&& 8 HZBUILD&&& HZBUILD&&& eint-p03&& eint-p01&& &&&&&&&&&& 02:45:01
enqueue&&&&&&& &&&&&&&& 79 HZBUILD&&& HZBUILD&&& eint-p03&& eint-p01&& &&&&&&&&&& 02:45:01
enqueue&&&&&&&& &&&&&&&&& 1 HZBUILD& &&HZBUILD&&& eint-p02&& eint-p02&& &&&&&&&&&& 02:35:00
enqueue&&&&&&& &&&&&&&&& 8 HZBUILD&&& HZBUILD&&& eint-p03&& eint-p02&& &&&&&&&&&& 02:35:00
enqueue&&&&&&& &&&&&&&& 84 HZBUILD&&& HZBUILD&&& eint-p03&& eint-p01&& &&&&&&&&&& 02:35:00
模式6中的TX enqueue等待原因分析：
(ORACLE10g enq:TX-row lock contention)
&v$lock视图中的TYPE=TX并且REQUEST=6。
原因：发生在一个事务尝试更新或删除当前被另一个事务锁定的行时发生该等待事件。
查询"谁是阻塞者以及是否存在相同资源的多个等待者"可以用以下语句：
SELECT /*+ ORDERED */
&&&&&& a.sid blocker_sid,
&&&&&& a.username blocker_username,
&&&&&& a.serial#,
&&&&&& a.logon_time,
&&&&&& b.TYPE,
&&&&&& b.lmode mode_held,
&&&&&& b.ctime time_held,
&&&&&& c.sid waiter_sid,
&&&&&& c.request request_mode,
&&&&&& c.ctime time_waited
& FROM v$lock b, v$enqueue_lock c, v$session a
&WHERE a.sid = b.sid
&& AND b.id1 = c.id1(+)
&& AND b.id2 = c.id2(+)
&& AND c.TYPE(+) = 'TX'
&& AND b.TYPE = 'TX'
&& AND b.BLOCK = 1
&ORDER BY time_held, time_waited
&&BLOCKER_SID BLOCKER_US&&& SERIAL# LOGON_TIM TY& MODE_HELD& TIME_HELD WAITER_SID REQUEST_MODE TIME_WAITED
----------- ---------- ---------- --------- -- ---------- ---------- ---------- ------------ -----------
&&&&&&& 764 &&&HZBUILD&&&&&&&& 47702 21-APR-08 TX&&&&&&&&& 6&&&&& 27371&&&&&& 3505&&&&&&&&&&& 6&&&&&&& 3509
在上面，我们已经通过查询“SELECT * FROM dba_waiters”得知阻塞者为session id 为764的会话，可以看出，两个查询的结果是一致的。
SELECT * FROM dba_waiters
WAITING_SESSION HOLDING_SESSION LOCK_TYPE&&& MODE_HELD& MODE_REQUE&& LOCK_ID1&& LOCK_ID2
--------------- --------------- ------------ ---------- ---------- ---------- ----------
&&&&&&&&&& 3505&&&&&&&&&&&& 764 T& ransaction& Exclusive& Exclusive&&&& 2293783&&& 1111708
以下查询enqueue事件等待的资源：
SELECT c.sid waiter_sid, a.object_name, a.object_type
& FROM dba_objects a, v$session b, v$session_wait c
&WHERE (a.object_id = b.row_wait_obj# OR a.data_object_id = b.row_wait_obj#)
&& AND b.sid = c.sid
&& AND chr(bitand(c.p1, -) / ) || chr(bitand(c.p1, ) / 65535) = 'TX'
&& AND c.event = 'enqueue'
WAITER_SID &&&&OBJECT_NAME&&&&&&&&& OBJECT_TYPE
---------- -------------------- ------------------
&&&&& 3505 &&&EA_TIMER_STATUS_TBL& &&&TABLE
可知等待的资源为表EA_TIMER_STATUS_TBL
模式4中的TX enqueue等待原因分析
原因1. ITL不足
如果session正在等待某个数据块中的ITL槽，将会产生模式４中的TX enqueue等待。这种情形发生在该session希望锁定该数据块中的一行但却有其它一个或多个session已经获得该数据块的行锁，且该数据块已没有空闲的ITL槽。通常Oracle会动态增加ITL槽，这可能是因为该数据块上已经没有足够的空闲空间来增加一个ITL槽。解决办法是提高可用ITL的数量，可以通过改变表上的INITTRANS 或者 MAXTRANS值（采用alter语句或以较高的值重建表）。
可以使用alter system dump datafile
block 命令来查看ITL的使用情况，ITL的--U-标识该ITL正在使用。
alter system dump datafile 9 block 50
在/udump下面可从trc文件中看到该block的详细信息：
10:38:37.521
Start dump data blocks tsn: 4 file#: 9 minblk 50 maxblk 50
buffer tsn: 4 rdba: 0x/50)
scn: 0x082b.74c6fb09 seq: 0x02 flg: 0x04 tail: 0xfb090602
frmt: 0x02 chkval: 0xc272 type: 0x06=trans data
Block header dump:& 0x
&Object id on Block? Y
&seg/obj: 0x9b5c& csc: 0x82b.74c6fad8& itc: 3& flg: E& typ: 1 - DATA
&&&& brn: 0& bdba: 0x2400009 ver: 0x01
&&&& inc: 0& exflg: 0
&Itl&&&&&&&&&& Xid&&&&&&&&&&&&&&&&& Uba&&&&&&&& Flag& Lck&&&&&&& Scn/Fsc
0x01&& 0xffff.000.& 0x0.00& C---&&& 0& scn 0x082b.74c6fad8
0x02&& 0x00000& 0x0.00& ----&&& 0& fsc 0x0
0x03&& 0x00000& 0x0.00& ----&&& 0& fsc 0x0
data_block_dump,data header at 0x987c
===============
tsiz: 0x1f80
hsiz: 0x46
pbl: 0x987c
flag=--------
……………………………
查询系统所有对象的ITL等待状态，可以使用查询
SELECT s.owner,
&&&&&& s.object_name,
&&&&&& s.subobject_name,
&&&&&& s.object_type,
&&&&&& s.tablespace_name,
&&&&&& s.VALUE,
&&&&&& s.statistic_name
& FROM v$segment_statistics s
&WHERE s.statistic_name = 'ITL waits'
&& AND s.VALUE > 0
&ORDER by VALUE DESC;
OWNER&&&&&&&&&& OBJECT_NAME&&&&&&&&&&&&&&&&&&& SUBOBJECT_ OBJECT_T TABLESPACE&&&&& &&&&&&&&&&&&&&&&&VALUE &&STATISTIC_
--------------- ------------------------------ ---------- -------- ---------- ---------- ----------
CTZJWLI&&&&&&&& JPD_COUNT_MANAGEACCTPROCESS_PK SYS_P7024& INDEX PA EAPR1_WLI_ RTITION& INDEX&&&&&&&&& 1 ITL &&&waits
CTZJWLI&&&&&&&& JPD_COUNT_MANAGEACCTPROCESS_PK SYS_P7027& INDEX PA EAPR1_WLI_ RTITION& INDEX&&&&&&&&& 1 ITL&& &waits
原因二：唯一键实施
如果一个session等待潜在的UNIQUE index复制，那么也会产生模式４中的TX enqueue等待。如果有两个session试图将同一个键值，那么第二个session则会等待，看是否会产生ORA-0001错误。解决的方法是持有该锁的第一个session执行COMMIT 或者 ROLLBACK。
原因三：位映射索引条目
在模式４中的TX　enqueue等待也有可能因为某个session由于共享的位图索引碎片而产生。如果两个session试图更新跨同一位图索引碎片的行，则第二个session将在模式４中的TX锁上等待之前的事务commit或者rollback。
ST enqueue等待
由于表空间都是本地化管理，所以不存在此问题。
Statpack报告中的enqueue等待：
在生成的statspack报告中也记录了15分钟内出现的enqueue等待：
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& % Total
Event&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Waits&&& &&&&&&Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
enqueue&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 5,362&&&&&&&& &880&&& 38.04
db file sequential read&&&&&&&&&&&&&&&&&&&&&&&&&& &&&&&&&100,359&&&&&&&& 488&&& 21.08
CPU time&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& &270&&& 11.68
db file scattered read&&&&&&&&&&&&&&&&&&&&&&&&&&&& &&&&&&25,754&&&&&&&& 236&&& 10.19
buffer busy waits&&&&&&&&&&&&&&&&&&&& &&&&&&&&&&&&&&&&&26,828&&&&&&&& 150&&&& 6.48
Wait Events for DB: EAPR1& Instance: EAPR1& Snaps: begin_snap -end_snap
-> s& - second
-> cs - centisecond -&&&& 100th of a second
-> ms - millisecond -&&& 1000th of a second
-> us - microsecond - 1000000th of a second
-> ordered by wait time desc, waits desc (idle events last)
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& &&&&&&&&&&&&&Avg
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Total Wait&& wait&&& Waits
Event&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Waits&& Timeouts&& Time (s)&& (ms)&&&& /txn
---------------------------- ------------ ---------- ---------- ------ --------
enqueue&&&&&&&&&&&&&&&&&&&&&&&&&&&& 5,362&&&&&&& 299&&&&&&& 880&&& 164&&&&& 0.1
db file sequential read&&&&&&&&&& 100,359&&&&&&&&& 0&&&&&&& 488&&&&& 5&&&&& 1.8
db file scattered read&&&&&&&&&&&& 25,754&&&&&&&&& 0&&&&&&& 236&&&&& 9&&&&& 0.5
Instance Activity Stats for DB: EAPR1& Instance: EAPR1& Snaps: begin_snap -end_s
Statistic&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Total&&&& per Second&&& per Trans
--------------------------------- ------------------ -------------- ------------
enqueue conversions&&&&&&&&&&&&&&&&&&&&&&&&& 911,851&&&&&&& 1,014.3&&&&&&&& 16.6
enqueue deadlocks&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 0&&&&&&&&&&& 0.0&&&&&&&&& 0.0
enqueue releases&&&&&&&&&&&&&&&&&&&&&&&&&& 1,715,544&&&&&&& 1,908.3&&&&&&&& 31.1
Enqueue activity for DB: EAPR1& Instance: EAPR1& Snaps: begin_snap -end_snap
-> Enqueue stats gathered prior to 9i should not be compared with 9i data
-> ordered by Wait Time desc, Waits desc
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Avg Wt&&&&&&&& Wait
Eq&&&& Requests&&& Succ Gets Failed Gets&&&&&& Waits&& Time (ms)&&&& Time (s)
-- ------------ ------------ ----------- ----------- ------------- ------------
TX&&&&& 151,100&&&&& 151,099&&&&&&&&&& 0&&&&&&&& 184&&&&&&&&& 5.19&&&&&&&&&&& 1
HW&&&&&& 14,126&& &&&&14,005&&&&&&&& 121&&&&&&&&& 29&&&&&&&&& 7.90&&&&&&&&&&& 0
&&&&&&&&& -------------------------------------------------------------
从以上statspack报告，看出出现的enqueue等待主要是TX锁的等待。
阅读(503) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。