等待时间说明二

一、free buffer inspected

当有新的对象需要请求分配buffer时，会通过内存管理模块请求分配空闲的或者可重用的buffer。“free buffer requested”就是产生这种请求的次数；
当请求分配buffer时，已经没有适合大小的空闲buffer时，需要从LRU链表上获取到可重用的buffer。但是，LRU链表上的buffer并非都是立即可重用的，还会存在一些块正在被读写或者已经被别的用户所等待。根据LRU算法，查找可重用的buffer是从链表的LRU端开始查找的，如果这一段的前面存在这种不能理解被重用的buffer，则需要跳过去，查找链表中的下一个buffer。“free buffer inspected”就是被跳过去的buffer的数目。

表示在将数据读入数据告诉缓冲区的时候等待进程找到足够大的内存空间。通常这种等待表示数据缓冲区偏小。

 

二、free buffer waits

在将一个块读入到缓冲区存储器之前，Oracle进程必须发现并获得用于这个块的空闲空间缓冲区。如果找不到LRU列表上的空闲缓冲区，或者缓冲区不可用，那么会话就会在free buffer waits事件上等待。DBWR进程负责在LRU列表上建立清洁缓冲区。

通常是由于如下5种原因的一种或几种：
    ◆ 低效率的SQL语句
       在v$SQL视图中查找执行许多物理读取(DISK_READS)的语句。这些语句可能正在执行全表扫描，或者通过为选择的索引访问表。调整这些语句以降低物理读取的需求。
   
    ◆ 不充足的DBWR进程
       SELECT Set_Id,
              Dbwr_Num
         FROM X$kcbwds
        ORDER BY Set_Id;
       
    ◆ 缓慢的IO子系统
       如果db file parallel write等待事件的平均等待时间教高，它就可以对前台产生负面影响，造成在free buffer waits事件上等待。
   
    ◆ 延迟的块清除
   
    ◆ 较小的缓冲区存储器
       如果缓冲存储器因为过小而无法处理空闲缓冲区的要求，进程就可能经历free buffer waits争用。

 

三、latch free

ORACLE使用锁存器来保护SGA中的内存结构，即，锁存器只保护临时的内存对象，不应用于数据库对象，ORALCE中锁存器的存在是为了保护SGA中的各种内存结构不会由于并发访问而产生潜在的破坏，执行对SGA中共享数据结构的排它性访问。锁存器是按不会受到死锁的方式实现。

ORACLE9i中latch free代表所有的等待锁存器的事件。ORACLE10g开始，常见的锁存器被单独取出。

锁存器是简单的锁设备，是由3个部分组成的内存元素：PID(进程ID)、内存地址、长度。

可以通过两种模式请求锁存：愿意等待和不等待(立即)模式。

>> 不等待模式只用于少数锁存器，通常用于带有多个子锁存器的锁存器，进程第一次尝试获得一个子锁存器，如果无法获得，它以不等待模式再次请求下一个子锁存，当所有的子锁存器均无法获得后，只是对最近的子锁存器采用愿意等待模式。以不等待模式获取的锁存器在immediate_gets和immediate_misses列中有统计数据。

>> 以愿意等待模式(短期等待和长期等待)获得的锁存器，在gets和misses列有统计数据。在愿意等待模式中，如果锁存器可用，在修改受保护的数据结构之前，进程将恢复信息写入到锁存器的恢复区域中，从而让PMON知道当持有锁存器的进程死亡时需要清除什么；如果锁存器不可用，那么进程会在CPU上自旋(spin)一小段时间，重新尝试获取该锁存器。参数_SPIN_COUNT决定自旋次数，缺省为20000.如果自旋_SPIN_COUNT次数后，仍然不能获得锁存，进程则在视图(v$session_wait)中提交latch free等待事件，让出CPU，然后睡眠。在睡眠周期结束后，进程醒来并重新尝试该锁存器，尝试次数为另一个_SPIN_COUNT次数，直到获得该锁存器。(如果多次请求、睡眠、唤醒仍无法获取，该进程将向PMON提交，以期PMON查明持有锁存的进程是否死亡，如果持有该锁存的进程已经死亡，那么PMON将清除并释放该锁存。)

1)Shared pool 和 library cache latch争用原因一   ――    分析
Oracle的共享池由不同的结构组成。主要包括：数据字典缓存，sql区和库缓存。Shared pool latch主要用来保护共享池的内存结构，当分配或者释放共享池内存时需要先获得该latch。例如，为一个新的sql语句或pl/sql过程、函数、包，触发器等分配空间（硬解析）时，或者为换出、清除某些内存块，以便为新的对象腾出足够的空间时，都需要获取shared pool latch。shared pool和library cache latch争用通常是由于硬分析引起。硬分析需要分配新的游标，或者将已经换出的游标重新执行。硬分析过多说明sql语句没有充分绑定变量。硬分析是代价十分昂贵的操作，在分析期间需要一直持有ibrary cache latch。

当一个新的sql语句到达时，oracle首先在库缓存中检查是否已经有相同的语句存在。如果已经存在，则可以花费较小的代价执行该语句，这就是所谓的软分析。硬分析通常意味着较坏的性能，而软分析过多也不是什么好事。在软分析期间，需要持有library cache latch，并且oracle依然需要对语句进行语法和语义检查，除非该语句已经在会话的游标缓存中。你可以通过设置参数session_cached_cursors来减少library cache latch的持有时间（具体信息请查看oracle metalin，编号#30804.1和 #62143.1）。但是，减少软分析的最佳方法还是优化应用程序。最好是分析一次，执行多次（很像java的宣传口号），而不要分析一次，执行一次。你可以通过v$sqlarea的parse_calls列来查找分析过多的sql语句。

Oracle对此sql将进行几个步骤的处理过程：
1、语法检查(syntax check)

检查此sql的拼写是否语法。

2、语义检查(semantic check)

诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。

3、对sql语句进行解析(prase)

利用内部算法对sql进行解析，生成解析树(parse tree)及执行计划(execution plan)。

4、执行sql，返回结果(execute and return)

其中，软、硬解析就发生在第三个过程里。
Oracle利用内部的hash算法来取得该sql的hash值，然后在library cache里查找是否存在该hash值；

2)Shared pool latch争用原因二    ――   过大的共享池
共享池中可用内存分成不同的内存块(chunk)，不同大小范围的块由不同的可用列表(freelist)来管理。在共享池中分配空间时，需要扫描可用列表，扫描期间，需要持有shared pool latch。过大的共享池会使得可用列表过长，从而使得shared pool latch的持有时间变长。在高并发环境中，latch持有时间过长就可能造成latch争用（表现为较高的sleeps和misses值），尤其是大量使用常量sql的系统，对这样的系统，不要一味想着加大共享池，更重要的是想一想你为什么会需要保存这么多不能共享的语句到共享池中。

3)Library cache latch争用原因三   ――    语句版本数过多
对于字符完全一致但是由于引用不同的对象而不能共享的sql语句，oracle使用多个子游标来指向该语句的不同版本。例如，系统中有三个名叫customer的表，但是属于不同的模式。则对于语句select * from customer，不同的模式执行该语句，语句字符上完全一样，其hash值完全一样，但是该语句无法共享，因为它引用的对象不同。所以会生成该语句的不同子版本。当一个sql语句有多个子版本时，oracle需要比较该语句的所有存在的子版本，在此期间需要持有library cache latch，这样可能导致library cache latch争用。解决这种情况也很简单，在系统中，尽量不要使用相同的对象名。

Cache buffers chains latch
当一个数据块读入到sga中时，该块的缓冲区头(buffer header)会放置在一个hash bucket的链表(hash chain)中。该内存结构由一系列cache buffers chains子latch保护（又名hash latch或者cbc latch）

 

1)Cache buffers chains latch争用原因一 ―― 低效的sql语句
低效的sql语句是导致cache buffers chains latch争用的主要原因。在高并发系统中， latch free时间可能因此非常明显。典型的情况是，应用程序开启多个并发会话执行相同的低效sql，并且访问同样的数据集。

你应该时刻铭记下面三点：
A)每次逻辑读都需要请求一次latch。
B)只有获得某个latch之后才会停止对该latch的不断请求。
C)在某个时刻，只有一个进程可以获得cache buffers chains latch，而该latch可能用于保护很多的数据块，其中的某些块可能正在被其他进程请求（当然，前面也已经提过，oracle9i允许只读性质的cache buffers chains latch共享）。

一般而言，较少的逻辑读意味着较少的latch请求，也就意味着较少的latch争用和更好的系统性能。所以，你应该找出导致cache buffers chains latch争用的低效sql语句，优化这些语句，尽量降低其逻辑读。那些buffers_get/executions比值较大的sql可能就是你需要调整的语句。

2)Cache buffers chains latch争用原因二 ―― 热点块
热点块是导致cache buffers chains latch争用的另外一个主要原因。当多个进程重复访问一个或多个由同一个cache buffers chains latch保护的块时会导致该问题。这通常是应用程序引起的。在这种情况下，增加cache buffers chains latch的个数对热点块导致的争用没有什么作用。因为数据块分布在哪个hash bucket和hash chain上是由块地址(dba:data block address)和hash bucket的个数决定的，和hash latch的个数没有关系。只要块地址和hash bucket数没有改变，这些热点块还是会分布在原来的hash bucket和hash chain上，还是由原来的hash latch保护，那么就还会对这些hash latch产生争用。除非系统中latch数目显著的增加（这样每个latch管理的hash bucket就会很少，甚至一个latch管理一个hash bucket，这样原来的热点块可能就会有其他的几个latch来管理，而不再需要争用原来的那个latch）。

3)Cache buffers chains latch争用原因三 ―― 过长的hash chain
多个数据块可能分配到同一个hash bucket上。这些块组成一个链表(hash chain)。在一个大型系统中，一个hash bucket中可能有上百个数据块。从一个hash chain链表中搜索某个块，需要获得cache buffers chains latch，串行的进行。如果链表太长，使得latch持有时间相应增加，可能导致其他进程请求cache buffers chains latch失败。

 

四、library cache load lock

这是把对象装入库缓存所要求的。此等待事件可在发生大量重新装载/装载（一般由缺乏重用SQL语句或尺寸不合适的shared_pool引起）时产生。

 

五、library cache lock/library cache pin

一）概述
一个实例中的library cache包括了不同类型对象的描述,如:游标,索引,表,视图,过程,等等.
这些对象不能在他们被使用的时候改变,他们在被使用的时候会被一种library locks and pins的机制锁住.
一个会话中,需要使用一个对象,会在该对象上先得到一个library lock(null, shared or exclusive模式的)
这是为了,防止其他会话也访问这个对象(例如:重编译一个包或视图的时候,会加上exclusive类型的锁)或更改对象的定义.

总的来说，library cache pin和library cache lock都是用于share pool的并发控制的。pin和lock都可以看作是一种锁。
locks/pins会在SQL语句执行期间一直保持,在结束的时候才释放。

 

每个想使用或修改已经locked/pin的对象的SQL语句,将会等待事件'library cache pin'或'library cache lock'直到超时.
超时,通常发生在5分钟后,然后SQL语句会出现ORA-4021的错误.如果发现死锁,则会出现ORA-4020错误。

二）library cache pin和library cache lock成因
lock主要有三种模式: Null,share(2),Exclusive(3).
在读取访问对象时,通常需要获取Null(空)模式以及share(共享)模式的锁定.
在修改对象时,需要获得Exclusive(排他)锁定.

同样pin有三种模式,Null,shared(2)和exclusive(3).
只读模式时获得共享pin,修改模式获得排他pin.

模式为shared(2)的pin会阻塞任何exclusive(3)的pin请求。
模式为shared(3)的pin也会阻塞任何exclusive(2)的pin请求。

不同的操作会对对象请求不同的lock/pin
1、所有的DDL都会对被处理的对象请求排他类型的lock和pin
2、当要对一个过程或者函数进行编译时，需要在library cache中pin该对象。在pin该对象以前，需要获得该对象handle的锁定，如果获取失败，就会产生library cache lock等待。如果成功获取handle的lock，则继续在library cache中pin该对象，如果pin对象失败，则会产生library cache pin等待。
如果是存储过程或者函数，可以这样认为：如果存在library cache lock等待，则一定存在library cache pin等待；反过来，如果存在library cache pin等待，不一定会存在library cache lock等待；
但如果是表引起的，则一般只有library cache lock等待，则不一定存在library cache pin。

可能发生library cache pin和library cache lock的情况：
1、在存储过程或者函数正在运行时被编译。
2、在存储过程或者函数正在运行时被对它们进行授权、或者移除权限等操作。
3、对某个表执行DDL期间，有另外的会话对该表执行DML或者DDL。
4、PL/SQL对象之间存在复杂的依赖性

每个想使用或修改已经locked/pin的对象的SQL语句,将会等待事件'library cache pin'或'library cache lock'直到超时.
超时,通常发生在5分钟后,然后SQL语句会出现ORA-4021的错误.如果发现死锁,则会出现ORA-4020错误。

例如：
SES1:
执行：exec p_sleep;
假设存储过程p正在运行，且运行时间很长
SES2:
执行：grant execute on p_sleep to system
对p进行编译，如果之前没有其他会话lock存储过程p的handle，则本会话会将获取p的handle锁定；但会话pin p时会失败，此时在SES2上产生library cache pin等待。如果超过5分钟仍然不能完成pin p，则会报错：
ORA-04021: 等待锁定对象 SUK.P_SLEEP 时发生超时。此时，本会话会释放p的handle lock。(也可能是ORA-04020错误)
SES3:
执行：grant execute on p_sleep to system
在这个会话中继续编译p，则该会话在获取p的handle锁定时会失败，在本会话产生library cache lock等待。如果SES2超时，则本会话会获取p的handle lock，v$session_wait上的等待事件也由library cache lock变成ibrary cache pin，直到超时。

library cache pin
查询v$session_wait视图中library cache pin对应的P1、P2、P3
P1 = Handle address
这个就是引起library cache pin等待的对象被pin到library cache中的handle。一般用P1RAW(十六进制)代替p1(十进制)
可以用以下sql查询那个用户下的那个对象正在被请求pin：
SELECT kglnaown "Owner", kglnaobj "Object"
FROM x$kglob
WHERE kglhdadr='&P1RAW'
;
返回的OBJECT可能是具体的对象，也可能是一段SQL。

P2 = Pin address
自身的pin地址。一般用P2RAW(十六进制)代替P2(十进制)

P3 = Encoded Mode & Namespace

在library cache pin和library cache lock(一)我们简单介绍了介绍library cache pin和library cache lock的成因，下面介绍如何解决library cache pin和library cache lock等待。

三）解决方法

有两种方法可以查询library cache pin的相关信息，推荐使用第二种。

使用这种方法前，有必要先了解以下表或视图：x$kglob、x$kgllk、x$kglpn、DBA_KGLLOCK

1) x$kglob
该基表主要是library cache object的相关信息。
X$KGLOB--[K]ernel [G]eneric [L]ibrary Cache Manager [OB]ject
引用该基表的视图有﹕GV$ACCESS、GV$OBJECT_DEPENDENCY、GV$DB_OBJECT_CACHE、GV$DB_PIPES、DBA_LOCK_INTERNAL﹑DBA_DDL_LOCKS

2) x$kgllk
该基表保存了library cache中对象的锁信息，主要用于解决library cache lock。
其名称含义是：
[K]ernel Layer
[G]eneric Layer
[L]ibrary Cache Manager ( defined and mapped from kqlf )
Object Locks
X$KGLLK - Object [L]oc[K]s

引用该基表的视图有﹕
DBA_DDL_LOCKS ﹑DBA_KGLLOCK ﹑GV$ACCESS ﹑GV$OPEN_CURSOR

SQL> desc x$kgllk;
名称 类型
---------- -----------
ADDR RAW(4)
INDX NUMBER
INST_ID NUMBER
KGLLKADR RAW(4)
KGLLKUSE RAW(4) ---会话地址(对应v$session的saddr)
KGLLKSES RAW(4) ---owner地址
KGLLKSNM NUMBER ---SID
KGLLKHDL RAW(4) ---句柄
KGLLKPNC RAW(4) ---the address of the call pin
KGLLKPNS RAW(4) ---对应跟踪文件中的session pin值
KGLLKCNT NUMBER
KGLLKMOD NUMBER ---持有锁的模式(0为no lock/pin held﹐1为null,2为share﹐3为exclusive)
KGLLKREQ NUMBER ---请求锁的模式(0为no lock/pin held﹐1为null,2为share﹐3为exclusive)
KGLLKFLG NUMBER ---cursor的状态﹐8(10g前)或2048(10g)表示这个sql正在运行﹐
KGLLKSPN NUMBER ---对应跟踪文件的savepoint的值
KGLLKHTB RAW(4)
KGLNAHSH NUMBER ---sql的hash值(对应v$session的sql_hash_value)
KGLLKSQLID VARCHAR2(13) ---sql ID，sql标识符
KGLHDPAR RAW(4) ---sql地址(对应v$session的sql_address)
KGLHDNSP NUMBER
USER_NAME VARCHAR2(30) ---会话的用戶名
KGLNAOBJ VARCHAR2(60) ---对象名称或者已分析并打开cursor的sql的前60个字符

3) x$kglpn
X$KGLPN--[K]ernel [G]eneric [L]ibrary Cache Manager object [P]i[N]s
它是与x$kgllk相对应的表﹐是关于pin的相关信息。它主要用于解决library cache pin
引用该表的视图有﹕
DBA_KGLLOCK

SQL> desc x$kglpn;
名称 类型
------------ ----------------------------
ADDR RAW(4)
INDX NUMBER
INST_ID NUMBER
KGLPNADR RAW(4)
KGLPNUSE RAW(4) ---会话地址(对应v$session的saddr)
KGLPNSES RAW(4) ---owner地址
KGLPNHDL RAW(4) ---句柄
KGLPNLCK RAW(4)
KGLPNCNT NUMBER
KGLPNMOD NUMBER ---持有pin的模式(0为no lock/pin held﹐1为null,2为share﹐3为exclusive)
KGLPNREQ NUMBER ---请求pin的模式(0为no lock/pin held﹐1为null,2为share﹐3为exclusive)
KGLPNDMK NUMBER
KGLPNSPN NUMBER ---对应跟踪文件的savepoint的值

4) DBA_KGLLOCK
DBA_KGLLOCK是一个视图，它联合了x$kgllk和x$kglpn的部分信息。
通过查询，我们可以知道DBA_KGLLOCK视图的构建语句：
SQL> SELECT * FROM DBA_VIEWS WHERE VIEW_NAME='DBA_KGLLOCK';

select kgllkuse, kgllkhdl, kgllkmod, kgllkreq, 'Lock' kgllktype from x$kgllk
union all
select kglpnuse, kglpnhdl, kglpnmod, kglpnreq, 'Pin' kgllktype from x$kglpn


了解了用到的几个主要视图或表的结构，我们就可以写出编写查询来查看相关信息：

方法一、只能查询library cache pin相关信息

SQL> SELECT distinct decode(kglpnreq,0,'holding_session: '||s.sid,'waiting_session: '||s.sid) sid,
2 s.SERIAL#, kglpnmod "Pin Mode", kglpnreq "Req Pin",a.sql_text,kglnaown "Owner", kglnaobj "Object"
3 FROM x$kglpn p, v$session s,v$sqlarea a,v$session_wait sw,x$kglob x
4 WHERE p.kglpnuse=s.saddr
5 AND kglpnhdl=sw.p1raw
6 and kglhdadr=sw.p1raw
7 and event like 'library cache%'
8 and (a.hash_value, a.address) IN (
9 select
10 DECODE (sql_hash_value,
11 0,
12 prev_hash_value,
13 sql_hash_value
14 ),
15 DECODE (sql_hash_value, 0, prev_sql_addr, sql_address)
16 from v$session s2
17 where s2.sid=s.sid
18 )
19 ;

SID SERIAL# Pin Mode Req Pin SQL_TEXT Owner Object
-------------------- ---------- ---------- ---------- ---------------------------------------- ------------ --------------------
blocked_sid: 16 195 0 3 grant execute on p_s SUK P_SLEEP
blocker_sid: 20 15 2 0 begin p_sleep; end; SUK P_SLEEP

得到这个结果后，你可以根据实际情况kill掉阻塞的会话或者被阻塞的会话。

方法二、可以查询library cache pin和library cache lock 的信息

select Distinct /*+ ordered */ w1.sid waiting_session,
h1.sid holding_session,
w.kgllktype lock_or_pin,
od.to_owner object_owner,
od.to_name object_name,
oc.Type,
decode(h.kgllkmod, 0, 'None', 1, 'Null', 2, 'Share', 3, 'Exclusive',
'Unknown') mode_held,
decode(w.kgllkreq, 0, 'None', 1, 'Null', 2, 'Share', 3, 'Exclusive',
'Unknown') mode_requested,
xw.KGLNAOBJ wait_sql,xh.KGLNAOBJ hold_sql
from dba_kgllock w, dba_kgllock h, v$session w1,
v$session h1,v$object_dependency od,V$DB_OBJECT_CACHE oc,x$kgllk xw,x$kgllk xh
where
(((h.kgllkmod != 0) and (h.kgllkmod != 1)
and ((h.kgllkreq = 0) or (h.kgllkreq = 1)))
and
(((w.kgllkmod = 0) or (w.kgllkmod= 1))
and ((w.kgllkreq != 0) and (w.kgllkreq != 1))))
and w.kgllktype = h.kgllktype
and w.kgllkhdl = h.kgllkhdl
and w.kgllkuse = w1.saddr
and h.kgllkuse = h1.saddr
And od.to_address = w.kgllkhdl
And od.to_name=oc.Name
And od.to_owner=oc.owner
And w1.sid=xw.KGLLKSNM
And h1.sid=xh.KGLLKSNM
And (w1.SQL_ADDRESS=xw.KGLHDPAR And w1.SQL_HASH_VALUE=xw.KGLNAHSH)
And (h1.SQL_ADDRESS=xh.KGLHDPAR And h1.SQL_HASH_VALUE=xh.KGLNAHSH)
;

WAITING_SESSION HOLDING_SESSION LOCK_OR_PIN OBJECT_OWNER OBJECT_NAME TYPE MODE_HELD MODE_REQUESTED WAIT_SQL HOLD_SQL
--------------- --------------- ----------- ---------------------------------------------------------------- -------------------------------------------------------------------------------- ---------------------------- --------- -------------- ------------------------------------------------------------ ------------------------------------------------------------
18 19 Lock SUK P_SLEEP PROCEDURE Exclusive Exclusive grant execute on p_sleep to system grant execute on p_sleep to system
19 12 Pin SUK P_SLEEP PROCEDURE Share Exclusive grant execute on p_sleep to system begin p_sleep; end;
23 25 Lock SUK P_SLEEP2 PROCEDURE Exclusive Exclusive grant execute on p_sleep2 to system grant execute on p_sleep2 to system
25 14 Pin SUK P_SLEEP2 PROCEDURE Share Exclusive grant execute on p_sleep2 to system begin p_sleep2; end;


为了避免这种情况，可以在编译过程或函数等对象时，先查看一下是否有会话正在使用该对象，查询语句如下：

SELECT Distinct sid using_sid,
s.SERIAL#, kglpnmod "Pin Mode", kglpnreq "Req Pin",kglnaown "Owner", kglnaobj "using_Object"
FROM x$kglpn p, v$session s,x$kglob x
WHERE p.kglpnuse=s.saddr
AND kglpnhdl=kglhdadr
And p.KGLPNUSE = s.saddr
And kglpnreq=0
And upper(kglnaobj) = upper('&obj');

如果有结果返回，则等待这些对话的操作执行完毕再重新编译，也可以把这些会话kill。

四）其他解决方法
上面主要是用到SQL查询相关信息的解决方法，也可以使用10046、trace等方法实现。至于用那种方法好，见仁见智。

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/669010/viewspace-664094/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/669010/viewspace-664094/