oracle+资源忙,Oracle 等待事件之三:常见的常规等待事件

诊断第一步先要概率系统事件次数排名

select event,count(*)  from

V$ACTIVE_SESSION_HISTORY group by event  having

count(*)   >

10000  order by count(*) ;

EVENT

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

SQL*Net break/reset to client​

.​

..​

....​

......

Direct path

read

During Direct Path operations the data is asynchronously

read from the database files. At some stage the session needs to

make sure that all outstanding asynchronous I/O have been completed

to disk. This can also happen if during a direct read no more slots

are available to store outstanding load requests (a load request

could consist of multiple I/Os).

在直接路径操作期间,数据是异步读取数据库文件。在某些阶段,会话需要确保所有未完成的异步IO已完成。这也可以发生在一个直接的读没有更多的插槽来处理突出的负载请求(负载请求可能包括多个IO)。

Wait Time: 10 seconds. The session will be posted by the

completing asynchronous I/O. It will never wait the entire 10

seconds. The session waits in a tight loop until all outstanding

I/Os have completed.

等待时间:10秒。该会话收到post的消息在完成异步IO。它将永远不会等待整个10秒。会话在一个轮训中等待,直到所有大型IO处理操作已经完成。​

​情景解释:这个等待事件多发生在会话将数据块直接读取到PGA当中而不是SGA中的情况,这些被读取的数据通常是会话私有的数据,所以不需要放到SGA作为共享数据。这些数据通常是来自与临时段上的数据,比如一个会话中SQL的排序数据,并行执行过程中间产生的数据,以及Hash

Join,merge

join产生的排序数据,因为这些数据只对当前的会话的SQL操作有意义,如果大量会话产生这种等待事件,要小心侦查,可能会导致IO带宽大量占用,导致整体IO响应下降。

latch free

The process waits for a latch that is currently busy (held by

another process).

该进程等待一个锁存器,目前正忙着(由另一个进程持有)。

Wait Time: The wait time increases exponentially and does not

include spinning on the latch (active waiting). The maximum wait

time also depends on the number of latches that the process is

holding. There is an incremental wait of up to 2 seconds.

等待时间:等待时间呈指数增加,不包括旋转的锁存(主动等待)。的最大等待时间也取决于被进程持有的锁存器的数目。有一个增量等待长达2秒。

Parameter Description

address   The

address of the latch for which the process is waiting

number

The latch number that indexes in the V$LATCHNAME

view.To find more information on the latch, use the following SQL

statement:

select *

from v$latchname

where latch# = number;

tries

A count of the number of times the process tried

to get the latch (slow with spinning) and the process has to

sleep

buffer latch

The session waits on the buffer hash chain latch. Primarily used

in the dump routines.

会话在缓冲哈希链锁存器上等待。主要用于转储例程。

Wait Time: 1 second

Parameter Description

latch addrThe virtual address in the SGA where this

latch is located. Use the following statement to find the name of

this latch:

select *

from v$latch a, v$latchname b

where addr = latch addr

and a.latch# = b.latch#;

chain#The

index into array of buffer hash chains. When the chain is

0xfffffff, the foreground waits on the LRU latch.

cursor: mutex S

A session waits on this event when it is requesting a mutex in

shared mode, when another session is currently holding a this mutex

in exclusive mode on the same cursor object.

一个会话等待此事件发生在share模式请求一个互斥锁,当另一个会话正在以exclusive模式持有相同cursor上互斥锁。

cursor: mutex X

The session requests the mutex for a cursor object in exclusive

mode, and it must wait because the resource is busy. The mutex is

busy because either the mutex is being held in exclusive mode by

another session or the mutex is being held shared by one or more

sessions. The existing mutex holder(s) must release the mutex

before the mutex can be granted exclusively.

会话请求x独占模式下对游标对象的互斥锁,它等待,因为资源忙。互斥锁忙:要么是在另几个会话x互斥或s共享方式持有这个锁。在持有者释放之前,会话必须一直等待。​

一个例子:​

top 5 events​

Library cache

mutex

17

63570s     3739540ms

94.1%

Statistic Name Time (s) % of DB Time

failed parse elapsed time 162,259.78 240.17

parse time elapsed 63,119.97 93.43​

从这里就可以看出,你有解析失败导致大量的等待,如语法错误

当你去试图执行一个错误的SQL的时候,也会发生解析,这时候也需要获得library cache

latch,但是因为错误所以解析没有完成,shared

pool中不会出现这个SQL对应的cursor,当你再次执行这个错误的SQL时,还会发生硬解析,又要尝试获得library cache

mutex

所以你会看到非常高的Library cache mutex X​

1.

select * from DBA_HIST_ACTIVE_SESS_HISTORY where event='library

cache: mutex X';

-取出P1

select * from V$MUTEX_SLEEP_HISTORY a where

A.MUTEX_IDENTIFIER=:P1;​

2.跟踪failed parse的SQL有那些

$ oerr ora 10035

10035, 00000, "Write parse failures to alert log file"

所以应该在system级别上设置10035 evnet level 1

ALTER SYSTEM SET EVENTS '10035 trace name context forever, level

1';

然后查看alert.log

找到解析失败的SQL,定位问题

cursor: pin S

A session waits on this event when it wants to update a shared

mutex pin and another session is currently in the process of

updating a shared mutex pin for the same cursor object.

This wait event should rarely be seen because a

shared mutex pin update is very fast.

一个会话等待这个事件的时候就想更新共享互斥引脚和另一个会话正在进行相同的光标对象更新共享互斥销过程。这个等待事件应该很少会看到因为共享互斥销更新很快。

Wait Time: Microseconds

cursor: pin X

A session waits on this event when it is requesting an exclusive

mutex pin for a cursor object and it must wait because the resource

is busy. The mutex pin for a cursor object can be busy either

because a session is already holding it exclusive, or there are one

or more sessions which are holding shared mutex pin(s). The

exclusive waiter must wait until all holders of the pin for that

cursor object have released it, before it can be granted.

一个会话等待此事件因为请求一个x模式的mutex

pin,因为资源忙。cursor的mutex被其他会话以s或者x的模式持有(mutex pin

)。请求等待着必须等待所有的持有者释放cursor的metux 倍释放,才能取得授权。

Wait Time: Microseconds

cursor: pin S wait on X

A session waits for this event when it is requesting a shared

mutex pin and another session is holding an exclusive mutex pin on

the same cursor object.

一个会话等待此事件,因它请求一个s模式获得一个mutex,另一个会话持有同一个cusor的x模式的mutex

。必须等待持有者释放。

Wait Time: Microseconds

Parameter Description

P1     Hash value of

cursor

P2     Mutex value (top 2

bytes contains SID holding mutex in exclusive mode, and bottom two

bytes usually hold the value 0)

P3     Mutex where (an

internal code locator) OR'd with Mutex Sleeps

library cache lock

This event controls the concurrency between clients of the

library cache. It acquires a lock on the object handle so that

either:

One client can prevent other clients from accessing the same

object

The client can maintain a dependency for a long time (for

example, no other client can change the object)

This lock is also obtained to locate an object in the library

cache.

此事件控制库缓存的客户端之间的并发性。它在对象句柄上获得一个锁,以便:

一个客户端可以阻止其他客户端访问同一个对象

客户端可以维护该库缓存很长一段时间(如,没有其他客户可以改变对象)

该锁也获得了在库缓存中查找对象的位置。

Wait Time: 3 seconds (1 second for PMON)

library cache pin

This event manages library cache concurrency. Pinning an object

causes the heaps to be loaded into memory. If a client wants to

modify or examine the object, the client must acquire a pin after

the lock.

此事件管理库缓存并发。钉住一个对象,使堆装入内存中。如果一个客户要修改或检查对象,这个客户必须在获得pin后锁住这个对象。

Wait Time: 3 seconds (1 second for PMON)

Parameter

Description

handle address Address of the object being loaded

pin address

Address of the load lock being

used. This is not the same thing as a latch or an enqueue, it is

basically a State Object.

mode

Indicates which data pieces of

the object that needs to be loaded

row cache lock

The session is trying to get a data dictionary lock.

会话尝试获得一个数据字典的锁。

Wait Time: Wait up to 60 seconds.

Parameter Description

cache id

The CACHE# column value in the

V$ROWCACHE view

mode

See "mode"

request

The pipe timer set by the

user

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值