oracle10g之后dump文件比之前丰富很多。

oracle调优排故一般方法
1、告警日志及trace文件。当oracle宕机或者要宕机并没宕机的时候会生成trc文件，首先去看告警日志，有没有trc文件等说明。

1、等待事件（注意时间积累问题、状态问题）EVENT 时间单位是微秒 10046里面就有哦。
产生机制有两种：
（1）阻塞产生等待（更具体的说是争用产生的等待）：latch、mutex、mutex是对latch的补充、10g之后出来的。（持有时间很短纳秒级别的，持有时间很短，访问共享池比如sga中的即便1个字节，那么oracle也会产生latch或mutex进行保护，公共资源主要是SGA），征用才会产生等待。什么时候会产生latch的等待呢？是不是我获取latch的锁的时间特别长了，才会有latch等待。想要获取的时候，找不到了才会等待。buffer pin 、library cache lock 写控制文件也会有。
（2）自动产生（预感到某个操作可能缓慢，基本上都是IO问题的）：oracle会注册这些事件，IO 的 db file sequential read、db file scattered read。存储差的10ms以上

下面我们做个试验，关注下latch的行为

sys@TESTDB12>select addr , name from v$latch_children where rownum =1;
ADDR             NAME
---------------- ----------------------------------------------------------------
000000009186D430 post/wait queue

通过 dbms_rowid包，我们找到某行数据所对应的文件号，块号

buffer cache中有个非常重要的东西 x$bh 视图，这个视图可以显示buffer cache中使用的绝大部分的信息。当然x$bh显示的是buffer cache内存中的信息，当数据文件的块没有load到内存中的时是不会在这个视图中显示的。

HLADDR是latch的地址，我们可以根据v$latch_children找到latch的名字。

这个latch被申请了3754次。我在一次读（逻辑读）oracle会在这个块上的latch申请两次latch锁。这就是一种保护机制。地址为00000000913FEE28这个latch不单单保护4号文件151这个块，他会保护很多的块的。当oracle发生 cache buffers chains争用后，有两种情况，1、可能是某个buffer被访问的太多了（热快竞争）。2、不是访问一个buffer，而是访问一批buffer，这些buffer正好被一个latch保护（热链竞争），oracle的等待事件没有一个说是超时（完成一个操作太慢了）产生的，有种情况cpu紧张的时候，可能导致操作很慢，这种时候会产生很奇怪的现象，看不到等待事件或者等待事件都不些不相关的等待。慢了不一定等待，可能是cpu紧张了。


sys@TESTDB12>select sid from v$mystat where rownum =1;




    SID


----------


    38


sys@TESTDB12>select spid from v$session a , v$process b where a.paddr=b.addr and a.sid =38;




SPID


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


18013

当前会话spid18013

出现waiting才是等待呢

下面窝们做个试验，读同一个块

点击( 此处 )折叠或打开

declare
id number;
begin
for i in 1..1000000000 loop
select empno into id from scott.emp where rowid='AAASZHAAEAAAACXAAA';
end loop;
end;
/

我们在两个会话上执行查询的同事查看等待事件

sys@TESTDB12>select sid ,event,p1,p2 from v$session where wait_class <> 'Idle'; SID EVENT P1 P2 ---------- ---------------------------------------------------------------- ---------- ---------- 53 SQL*Net message to client 1650815232 1 sys@TESTDB12>select sid ,event,p1,p2 from v$session where wait_class <> 'Idle'; SID EVENT P1 P2 ---------- ---------------------------------------------------------------- ---------- ---------- 53 SQL*Net message to client 1650815232 1 sys@TESTDB12>select sid ,event,p1,p2 from v$session where wait_class <> 'Idle'; SID EVENT P1 P2 ---------- ---------------------------------------------------------------- ---------- ---------- 38 cursor: pin S 549715863 2.4481E+11 sys@TESTDB12>select sid ,event,p1,p2 from v$session where wait_class <> 'Idle'; SID EVENT P1 P2 ---------- ---------------------------------------------------------------- ---------- ---------- 38 cursor: pin S 549715863 2.4481E+11 sys@TESTDB12>r 1* select sid ,event,p1,p2 from v$session where wait_class <> 'Idle' SID EVENT P1 P2 ---------- ---------------------------------------------------------------- ---------- ---------- 38 latch: cache buffers chains 2436886056 155 57 cursor: pin S 549715863 1.6321E+11 sys@TESTDB12>r 1* select sid ,event,p1,p2 from v$session where wait_class <> 'Idle' SID EVENT P1 P2 ---------- ---------------------------------------------------------------- ---------- ---------- 38 cursor: pin S 549715863 2.4481E+11 57 cursor: pin S 549715863 1.6321E+11 sys@TESTDB12>r 1* select sid ,event,p1,p2 from v$session where wait_class <> 'Idle' SID EVENT P1 P2 ---------- ---------------------------------------------------------------- ---------- ---------- 38 latch: cache buffers chains 2436886056 155 57 latch: cache buffers chains 2436886056 155 sys@TESTDB12>r 1* select sid ,event,p1,p2 from v$session where wait_class <> 'Idle' SID EVENT P1 P2 ---------- ------------------------------------------- -------------- ---------- 29 os thread startup 0 0 38 cursor: pin S 549715863 2.4481E+11 53 SQL*Net message to client 1650815232 1 57 latch: cache buffers chains 2436886056 155

当我停止一个会话查询的时候等待事件为

停止会话53后 57会话仍 “显示等待”

sys@TESTDB12>r
  1* select sid ,event,p1,p2 from v$session where wait_class<>'Idle'
  SID  EVENT                  P1         P2
--------- ---------------------------------------- ----------- -----------
  53   SQL*Net message to client       1650815232      1
  57   latch: cache buffers chains      2436886056     155
sys@TESTDB12>select sid ,event,p1,p2 ,state from v$session where wait_class<>'Idle';
  SID EVENT                    P1       P2  STATE
-------- ----------------------------------------- --------- ---------- -------------------
  53  SQL*Net message to client       1650815232    1 WAITED SHORT TIME
  57  latch: cache buffers chains      2436886056   155 WAITED KNOWN TIME

正常等待的时候状态是waiting但是这里是 waited known time等过了，只要不是waiting状态就是等待过了。

sys@DB>select sid,event,p1,p2,state,wait_time,SECONDS_IN_WAIT from v$session where wait_class<>'Idle';
   SID EVENT               P1     P2   STATE      WAIT_TIME  SECONDS_IN_WAIT
---- --------------------------- ------------- ------- ------------------- ---------- ---------------
53 SQL*Net message to client   1650815232   1  WAITED SHORT TIME   -1      0
57 latch: cache buffers chains  2436886056  155  WAITED KNOWN TIME   10     647

下面我们说说redo log parallel write与redo log sync

比如同时10个用户发出commit命令，1个lgwr接受到这个需求的时候，lgwr会整合接受到的请求，比如说，log file parallel write的等待事件是1ms并且t1和t2之间时间很短（与1ms比可以忽略不计），那么反馈给每个用户的时间都是1ms。但是我们看log file sync的时候可能是1ms * 10 = 10ms。有时等待事件会被放大，就比如说log file sync 在awr中的值可能很大，但是其中的都是时间一点点的累积，并且很多进程commit，这种累积导致的最终结果变大，可是数据库并没有什么毛病，在我们通过awr入口进行调优的时候，我们要会辨别。

结论：等待事件，有阻塞的时候一定有等待，有IOde时候一定有等待，有的时候没有等待，但是数据库产生问题了，这个时候我们要结合资料视图

2、资料视图

3、时间模型

ITPub博客

buffer cache 内部机制深入探索【一】

最新文章