DFS lock handle & inactive transaction branch


Event
Waits
Time(s)
Avg wait (ms)
% DB time
Wait Class

DFS lock handle
2,214
6,157
2781
66.08
Other

DB CPU
2,107
22.62

inactive transaction branch
1,046
1,046
1000
11.23
Other

cell smart table scan
4,910
8
2
0.09
User I/O

SQL*Net more data to client
356,561
7
0
0.07
Network

SQL> select session_id, user_id, sql_id, event,blocking_session ,count(event)

2    from v$active_session_history

3   where event = ‘DFS lock handle‘

4   group by session_id, user_id, sql_id, event,blocking_session

5  ;

SESSION_ID    USER_ID SQL_ID        EVENT                                                            BLOCKING_SESSION COUNT(EVENT)

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

24          0 fpmrt9q566pwj DFS lock handle                                                                              1

1430        161               DFS lock handle                                                               918        35906

2209        161               DFS lock handle                                                              1949        35906

1563         57 6br3bdp02sujd DFS lock handle                                                                              1

SQL> select sql_text from v$sql where sql_id=‘6br3bdp02sujd‘

2  ;

SQL_TEXT

SELECT ATTACHED_SESSIONS FROM SYS.USER_DATAPUMP_JOBS WHERE JOB_NAME = :1

SELECT ATTACHED_SESSIONS FROM SYS.USER_DATAPUMP_JOBS WHERE JOB_NAME = :1

SQL> select  distinct event,sql_id,session_id,blocking_session from v$active_session_history where session_id in (1949,918);

EVENT                                                            SQL_ID        SESSION_ID BLOCKING_SESSION

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

SQL*Net more data to client                                      3vtg8xc58vsux        918

SQL*Net more data to client                                      3vtg8xc58vsux       1949

SQL> select username,event,status,program,sql_id from v$session where sid in (1949,918);

USERNAME                       EVENT                                                            STATUS   PROGRAM                                          SQL_ID

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

DCDB_FOCENTER                  SQL*Net more data to client                                      ACTIVE  
[email protected]************b1 (TNS V1-V3)                   3vtg8xc58vsux

DCDB_FOCENTER                  SQL*Net more data to client                                      ACTIVE  
[email protected]************b1 (TNS V1-V3)                   3vtg8xc58vsux

两个会话的状态基本上没变过，该语句也很简单，所以判断两个会话有问题，经确认两个会话的应用已经关闭，决定kill 调，（需进一步关注该问题）；；

inactive transaction branch

SQL> select session_id, user_id, sql_id, event,blocking_session ,count(event)

2    from v$active_session_history

3   where event = ‘inactive transaction branch‘

4   group by session_id, user_id, sql_id, event,blocking_session;

SESSION_ID    USER_ID SQL_ID        EVENT                                                            BLOCKING_SESSION COUNT(EVENT)

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

1430        161               inactive transaction branch                                                               6345

2209        161               inactive transaction branch                                                               6345

SQL> /

USERNAME                       EVENT                                                            STATUS   SQL_ID        BLOCKING_SESSION

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

DCDB_FOCENTER                  DFS lock handle                                                  ACTIVE                              918

DCDB_FOCENTER                  DFS lock handle                                                  ACTIVE                             1949

SQL>

SQL> /

USERNAME                       EVENT                                                            STATUS   SQL_ID        BLOCKING_SESSION

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

DCDB_FOCENTER                  inactive transaction branch                                      ACTIVE

DCDB_FOCENTER                  inactive transaction branch                                      ACTIVE

--进一步跟踪文件分析

SQL> oradebug setospid 81605

Oracle pid: 227, Unix process pid: 81605, image: [email protected]

SQL> oradebug unlimit

Statement processed.

SQL>  oradebug dump processstate 10

Statement processed.

SQL> oradebug tracefile_name

/u01/app/oracle/diag/rdbms/primary/foc2/trace/foc2_ora_81605.trc

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

[5 samples,                                          14:10:08 - 14:10:12]

waited for ‘DFS lock handle‘, seq_num: 126

p1: ‘type|mode‘=0x44580005

p2: ‘id1‘=0xd06e3e25

p3: ‘id2‘=0x0

time_waited: >= 4 sec (still in wait)

[1 sample,                                                      14:10:07]

waited for ‘inactive transaction branch‘, seq_num: 125

p1: ‘branch#‘=0x0

p2: ‘waited‘=0x0

p3: ‘‘=0x0

time_waited: 1.000897 sec (sample interval: 0 sec)

[6 samples,                                          14:10:01 - 14:10:06]

waited for ‘DFS lock handle‘, seq_num: 124

p1: ‘type|mode‘=0x44580005

p2: ‘id1‘=0xd06e3e25

p3: ‘id2‘=0x0

time_waited: 6.084005 sec (sample interval: 5 sec)

[1 sample,                                                      14:10:00]

waited for ‘inactive transaction branch‘, seq_num: 123

p1: ‘branch#‘=0x0

p2: ‘waited‘=0x0

p3: ‘‘=0x0

time_waited: 1.000656 sec (sample interval: 0 sec)

[6 samples,                                          14:09:54 - 14:09:59]

waited for ‘DFS lock handle‘, seq_num: 122

p1: ‘type|mode‘=0x44580005

p2: ‘id1‘=0xd06e3e25

p3: ‘id2‘=0x0

time_waited: 5.919257 sec (sample interval: 5 sec)

[1 sample,                                                      14:09:53]

waited for ‘inactive transaction branch‘, seq_num: 121   【这个等待还不太清楚】

p1: ‘branch#‘=0x0

p2: ‘waited‘=0x0

p3: ‘‘=0x0

time_waited: 1.001862 sec (sample interval: 0 sec)

[6 samples,                                          14:09:47 - 14:09:52]

waited for ‘DFS lock handle‘, seq_num: 120

p1: ‘type|mode‘=0x44580005

p2: ‘id1‘=0xd06e3e25

p3: ‘id2‘=0x0

time_waited: 6.031084 sec (sample interval: 5 sec)

[1 sample,                                                      14:09:46]

waited for ‘inactive transaction branch‘, seq_num: 119

p1: ‘branch#‘=0x0

p2: ‘waited‘=0x0

p3: ‘‘=0x0

time_waited: 1.000598 sec (sample interval: 0 sec)

[6 samples,                                          14:09:40 - 14:09:45]

PENDING_Q:

lp 0x7b1f6ab20 gl KJUSERNL rl KJUSEREX rp 0x7b5a38280 [0xd06e3e25][0x0],[DX][ext 0x0,0x0]

master 2 gl owner 0x7dce529a0 possible pid 81605 xid 0000-0000-00000000 bast 0 rseq 4030 mseq 0 history 0x49ab549a

convert opt KJUSERGETVALUE KJUSERNODEADLOCKWAIT KJUSERNODEADLOCKBLOCK

GRANTED_Q :

lp 0x7b9cabe30 gl KJUSERPR rp 0x7b5a38280 [0xd06e3e25][0x0],[DX][ext 0x0,0x0]

master 2 gl owner 0x7bcd44380 possible pid 81601
xid 0000-0000-00000000 bast 0 rseq 4030 mseq 0 history 0x95514955

open opt  KJUSERNO_XID

CONVERT_Q:

lp 0x7b1f6ab20 gl KJUSERNL rl KJUSEREX rp 0x7b5a38280 [0xd06e3e25][0x0],[DX][ext 0x0,0x0]

master 2 gl owner 0x7dce529a0 possible pid 81605
xid 0000-0000-00000000 bast 0 rseq 4030 mseq 0 history 0x49ab549a

convert opt KJUSERGETVALUE KJUSERNODEADLOCKWAIT KJUSERNODEADLOCKBLOCK

SQL> select sid from v$session where paddr in (select addr from v$process where spid=81601);

SID

----------

918

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

SO: 0x7b12b6a38, type: 17, owner: 0x7b4a7e860, flag: INIT/-/-/0x00 if: 0x3 c: 0x3

proc=0x7b4a7e860, name=ksxp IPC state object, file=ksxp2.h LINE:1509, pg=0

KSXP Context allocated

Dumping ksxp state

ksxppg=0x2b57d69553d8 ksxpsg=0x7b57f9620 ksxpsg_a=0x7b57f9620ksxpssg=0x7b57f9368 rm=0x7b94080d8

proc state: (pid: 227) [flg: 1 sg: 1]（不存在）

curts 1407305412 wtctr 0

Dumping ksxp contexts

Context[2] 0x2b57d6a0aea0 GES state 1

Context[1] 0x2b57d6a0fcc0 gc ksxp component context state 1  （已经不存在，两个节点都不存在）

Dumping region queue

region count: 1

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

SQL>  select sid from v$session where paddr in (select addr from v$process where spid=227);

no rows selected

SQL>

DFS lock handle & inactive transaction branch

时间： 2024-11-08 13:27:06

DFS lock handle & inactive transaction branch的相关文章

Oracle等待事件DFS lock handle

在做性能压力测试,测试结果不能通过,获取现场一个小时的AWR报告,发现大量的等待事件,数据库是RAC,版本是11.2.0.4.0. Snap Id Snap Time Sessions Cursors/Session Instances Begin Snap: 1607 21-10月-14 20:00:03 560 67.9 2 End Snap: 1608 21-10月-14 21:00:11 573 12.4 2 Elapsed:   60.13 (mins)       DB Time:

【翻译自mos文章】在12c中Create or Truncate Table时非常慢，等待事件为 DFS Lock Handle wait

来源于: Create or Truncate Table Slow in 12c While Waiting for DFS Lock Handle wait (文档 ID 2085308.1) APPLIES TO: Oracle Database - Enterprise Edition - Version 12.1.0.2 and later Information in this document applies to any platform. SYMPTOMS In 12c dat

Deadlock found when trying to get lock; try restarting transaction

1.错误描述 [ERROR:]2015-06-09 16:56:19,481 [抄送失败] org.hibernate.exception.LockAcquisitionException: error executing work at org.hibernate.dialect.MySQLDialect$1.convert(MySQLDialect.java:451) at org.hibernate.exception.internal.StandardSQLExceptionConver

MySQL error : Deadlock found when trying to get lock; try restarting transaction

在使用 MySQL 时,我们有时会遇到这样的报错:"Deadlock found when trying to get lock; try restarting transaction". 在 14.5.5.3 How to Minimize and Handle Deadlocks 中有这样一句话: Deadlocks are not dangerous. Just try again. 死锁不危险,重试一下就行. 实际上这个建议非常实用. 我们回顾一下死锁发生的四个条件: 资源的独

Exception: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction

我在update数据库的时候出现的死锁 数据库表死锁 这是在网上看到的文章:: 由于InnoDB预设是Row-Level Lock,所以只有「明确」的指定主键,MySQL才会执行Row lock (只锁住被选取的资料例) ,否则MySQL将会执行Table Lock (将整个资料表单给锁住). 举个例子: 假设有个表单products ,里面有id跟name二个栏位,id是主键. 例1: (明确指定主键,并且有此笔资料,row lock) SELECT * FROM products WHERE

library cache lock和cursor: pin S wait on X等待

1.现象: 客户10.2.0.4 RAC环境,出现大量的library cache lock和cursor: pin S wait on X等待,经分析是由于统计信息收集僵死导致的.数据库在8点到9点期间,数据库两个节点都存在明显的cursor: pin S wait on X和library cache lock的等待: TOP 5 EVENT: Event Waits Time(s) Avg   Wait(ms) %   Total Call Time Wait   Class cursor

【等待事件】等待事件系列（5.1）--Enqueue(队列等待)

[等待事件]等待事件系列(5.1)--Enqueue(队列等待)   1  BLOG文档结构图   2  前言部分   2.1  导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~: ① Enqueue队列等待 ② Enq数据字典 ③ enq: AE - lock ④ enq: MR锁 ⑤ enq: DX - contention ⑥ enq: SQ - contention 序列等待     2.2  相关参考文章链接 [推

（转载）Oracle AWR报告指标全解析

Oracle AWR报告指标全解析 2014-10-16 14:48:04 分类: Oracle [性能调优]Oracle AWR报告指标全解析 2013/08/31 BY MACLEAN LIU 26条评论 [性能调优]Oracle AWR报告指标全解析 开Oracle调优鹰眼,深入理解AWR性能报告:http://www.askmaclean.com/archives/awr-hawk-eyes-training.html 开Oracle调优鹰眼,深入理解AWR性能报告 第二讲: http:

Oracle AWR报告指标解析一例

啥是AWR? ===================================================================================================== AWR (Automatic Workload Repository) 一堆历史性能数据,放在SYSAUX表空间上, AWR和SYSAUX都是10g出现的,是Oracle调优的关键特性: 大约1999年左右开始开发,已经有15年历史 默认快照间隔1小时,10g保存7天.11g保存8