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:   2,090.75 (mins)      
Event Waits Total Wait Time (sec) Wait Avg(ms) Wait Class
rdbms ipc reply 32,876,281 44.9K 1 35.8 Other
DB CPU   21.3K   17.0  
direct path read 435,808 18.8K 43 15.0 User I/O
DFS lock handle 4,204,866 7977.9 2 6.4 Other
log file sync 8,541 252.7 30 .2 Commit

1. 排在第一的等待事件是rdbms ipc reply , 解释是The rdbms ipc reply Oracle metric event is used to wait for a reply from one of the background processes.说明lgwr,dbwr等后台进程空闲,等待前台进程给予他们的工作任务。DFS lock handle这个等待事件很可疑,官方解释是:

The session waits for the lock handle of a global lock request. The lock handle identifies a global lock. With this lock handle,
other operations can be performed on this global lock (to identify the global lock in future operations such as conversions or release). The global lock is maintained by the DLM.

大致意思是无法获得global cache lock的handle时候所记录的等待事件。

2. 在网上看了下大家的处理方式,序列的cache过小,数据库服务器CPU过高,做过相应的调整和监控,都不解决问题。在做性能测试的时候,

select chr(bitand(p1,-16777216)/16777215) || chr(bitand(p1, 16711680)/65535) "Lock",

to_char(bitand(p1, 65536)) "Mode",

p2, p3 , seconds_in_wait

from v$session_wait

where event = ‘DFS lock handle‘;

发现了BB锁,意思是:2PC distributed transaction branch across RAC instances DX Serializes tightly coupled distributed transaction branches。

大致意思是分布式事务两个RAC实例中across。我随即做出调整,将weblogic连接改为只是连接一个RAC节点,再进行测试。测试结果如下:

Snap Id Snap Time Sessions Cursors/Session Instances
Begin Snap: 1680 24-10月-14 12:00:13 864 9.5 2
End Snap: 1681 24-10月-14 13:00:17 863 9.9 2
Elapsed:   60.07 (mins)      
DB Time:   80.28 (mins)      
Event Waits Total Wait Time (sec) Wait Avg(ms) Wait Class
DB CPU   2335.6   48.5  
rdbms ipc reply 5,326,201 645.6 0 13.4 Other
gc buffer busy acquire 39,052 226.7 6 4.7 Cluster
DFS lock handle 672,757 225.8 0 4.7 Other

DFS lock handle减少了非常多,但还是存在,不过性能测试结果好了很多。

3. 如何彻底解决呢?先说下DFS lock handle,说简单一点就是一个object在不同的实例中DML,每个实例在自己处理自己的object。这是一个权衡的问题,如果weblogic动态连接实例,就无法保证每次处理自己的object,但这样可以容灾,其他的实例挂了也没问题;如果是指定单独的实例,相对于动态是优、缺点是反的。还有一种说法是metalink中有关于DFS
lock handle的都是bug,目前尚不清楚数据库升级后是不是会好一点。

时间: 2024-10-24 15:47:18

Oracle等待事件DFS lock handle的相关文章

【翻译自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

Oracle Study之--Oracle等待事件(8)

Oracle Study之--Oracle等待事件(8)      库缓存中的对象在库缓存中被切割成多个内存块,另有一个对象句柄记录了各个内存块的地址和其他的一些信息.当你要修改句柄中的信息时,需要在句柄上加独占锁,而如果另一个进程恰好在这时要求读.写句柄中的信息,它就必须等待.此时的等待就被Oracle记入Library cache lock事件.而读.写对象内存块也是无法同时进行的,有人如果正在写,你的读操作就必须等待,读写内存块的等待事件就是Library cache pin.如果这两个等

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

Oracle Study之--Oracle等待事件(1)

Oracle Study之--Oracle等待事件(1) 一. 等待事件的相关知识1.1 等待事件主要可以分为两类: 即空闲(IDLE)等待事件和非空闲(NON-IDLE)等待事件.1). 空闲等待事件指ORACLE正等待某种工作,在诊断和优化数据库的时候,不用过多注意这部分事件.2). 非空闲等待事件专门针对ORACLE的活动,指数据库任务或应用运行过程中发生的等待,这些等待事件 是在调整数据库的时候需要关注与研究的.在Oracle 10g中的等待事件有874个,11g中等待事件1118个.

Oracle Study之--Oracle等待事件(9)

Oracle Study之--Oracle等待事件(9)  Log buffer space当log buffer 中没有可用空间来存放新产生的redo log数据时,就会发生log buffer space等待事件.如果数据库中新产生的redo log的数量大于LGWR 写入到磁盘中的redo log 数量,必须等待LGWR 完成写入磁盘的操作,LGWR必须确保redo log写到磁盘成功之后,才能在redo buffer当中重用这部分信息.如果数据库中出现大量的log buffer spac

Oracle Study之--Oracle等待事件(6)

什么是enqueue enqueue可以做名词,也可以做动词来解释.做名词时,指的的是一种锁的类型,比如Tx enqueue.做动词时,则是指将锁请求放入到请求队列的操作. 我们知道,lock是一种需要排队的锁实现机制,这和latch是不一样的,latch是一种轻量级的锁,是不需要排队得.Enqueue就是lock的排队机制的实现. lock是用来实现对于共享资源的并发访问的.如果两个session请求的lock是兼容的,则可以同时锁定资源,如果两个session请求的lock是不兼容的,则其中

Oracle Study之--Oracle等待事件(7)

Oracle Study之--Oracle等待事件(7)  Free buffer waits    当一个会话将数据块从磁盘读到内存中时,它需要到内存中找到空闲的内存空间来存放这些数据块,当内存中没有空闲的空间时,就会产生这个等待:除此之外,还有一种情况就是会话在做一致性读时,需要构造数据块在某个时刻的前映像(image),此时需要申请内存来存放这些新构造的数据块,如果内存中无法找到这样的内存块,也会发生这个等待事件.当数据库中出现比较严重的free buffer waits等待事件时,可能的

Oracle Study之--Oracle等待事件(5)

Oracle Study之--Oracle等待事件(5)  Db file single write这个等待事件通常只发生在一种情况下,就是Oracle 更新数据文件头信息时(比如发生Checkpoint).当这个等待事件很明显时,需要考虑是不是数据库中的数据文件数量太大,导致Oracle 需要花较长的时间来做所有文件头的更新操作(checkpoint).这个等待事件有三个参数:File#: 需要更新的数据块所在的数据文件的文件号.Block#: 需要更新的数据块号.Blocks: 需要更新的数

Oracle Study之--Oracle等待事件(3)

Oracle Study之--Oracle等待事件(3) Db file parallel read这是一个很容易引起误导的等待事件,实际上这个等待事件和并行操作(比如并行查询,并行DML)没有关系. 这个事件发生在数据库恢复的时候,当有一些数据块需要恢复的时候,Oracle会以并行的方式把他们从数据文件中读入到内存中进行恢复操作.这个等待事件包含三个参数:Files: 操作需要读取的文件个数.Blocks: 操作需要读取的数据块个数.Requests: 操作需要执行的I/O次数. 案例分析: