buffer cache 內部機制深入探索【一】

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部落格 ” ，連結：http://blog.itpub.net/29990276/viewspace-1455014/，如需轉載，請註明出處，否則將追究法律責任。

buffer cache 內部機制深入探索【一】

相關文章