buffer busy waits引起的會話突增

作者 楊禹航·沃趣科技高級資料庫技術專家

出品 沃趣科技

某天，客戶反映其監控平台發現其一套資料庫7月20日及24日在早晨7：03分和8：09分兩個時間段節點1出現會話數突增情況，持續時間較短，問題時間段應用並未受到影響，客戶希望幫其查找原因。

環境為11.2.0.4的雙節點RAC。

通過收集的ASH信息我們可以在7月20日的07:03分和7月24日的08: 09分看到會話出現突增情況，其他時間段會話相對較平穩，問題時間點過後，會話數再次恢復平穩。

7月20日：

7月24日：

在對問題時間段等待事件進行查看，該時間段內出現大量的」buffer busy waits」等待事件，等待的會話並無blocking session，語句類型均為INSERT，SQL_ID均為：8qy4f5hpsrmu4，而對象為98866，在7月24日，問題時間段又伴有少量的」latch: cache buffers chains」和大量的」enq: HW -contention」。

7月20日：

7月24日：

對等待事件進行匯總後，等待次數排名第一位的等待事件均為」buffer busy waits」，如下：

7月20日

7月24日

通過上面的信息在表象中看到是由於系統中大量並發INSERT語句同時向98866對象插入數據，而引起的會話數突增，且會話均等待」buffer busy waits」。

那系統中為何同時出現大量INSERT語句的會話？該時間點內應用確實發出如此多的INSERT語句？而又同時向相同的對象中插入數據產生的」buffer busy waits」？還是由於」buffer busy waits」而引起的大量會話出現阻塞？

根據應用反饋，系統中的數據插入較平穩，問題時間段業務量並未發生變化，這樣可以排除第一種可能性。

先看何為」buffer busy waits」，「buffer busy waits」等待事件的發生情況為當會話以獨佔模式持有buffer pin鎖時，其他會話以非兼容模式申請buffer pin鎖，此時申請buffer pin鎖的會話產生的等待事件為buffer busy waits。引起系統」bufferbusy wiats」的原因很多，常見的情況有如下情況：

1.大量的並發DML語句，修改相同的數據塊

2. DML語句慢，導致以排他模式持有bufferpin時間過長（DML語句慢的原因可能由於系統redo量過高或者lgwr慢等原因導致）

另外，通過對等待事件所發生位置進行統計發現」buffer busy waits」均發生在少數的數據塊中。

7月20日

7月24日

大量的會話又為何向同一個數據塊中插入數據？通過對發生大量」buffer busy waits」的數據塊進行dump，有如下發現:

218/4161664

19/8250

其中218/4161664為L1，19/8250為段頭，L1與段頭居然出現了大量的」buffer busy waits」，如果對數據插入時的機制有所了解，問題原因其實已經展現出來，在使用ASSM的段空間管理方式下，正常插入語句在向段中插入數據時，將會根據會話的pid信息計算hash值n，根據計算結果在L3/L2中選擇第n個L1，這裡需要注意插入時所選擇的L1是在高水位線之下的L1，在根據pid計算hash值將數據插入到L1中的第n個數據塊里，會話不同，插入的數據將分散到不同的塊中，當L1中指向的數據塊使用率出現變化(25% 50% 75% FULL)時將會修改L1中對該數據塊空間使用情況標記位的修改，因其為修改，將以獨佔模式持有L1段頭的buffer pin鎖，在問題時間段內同時伴有大量的高水位推進」enq: HW - contention」等待事件，段的高水位線記錄在段頭，這樣也解釋了為什麼段頭會出現大量的」buffer busy waits」，其實根據上面的信息基本可以分析出是由於系統中持續插入數據，由於高水位線低(高水位線的推進是以L1中指向的塊的數量進行推進)，大量的數據插入時聚集在高水位線下L1中指向的數據塊，而引起大量的「buffer busy waits」，導致會話突增，這種問題較少見，如果需要避免該問題，可以採用手工推高高水位的方式，這樣可選擇的L1數量，數據塊的數量也隨著增多，避免插入的數據塊過於集中。

| 作者簡介

楊禹航·沃趣科技高級資料庫技術專家

熟悉Oracle資料庫內部機制，豐富的資料庫及RAC集群層故障診斷、性能調優、OWI、資料庫備份恢復及遷移經驗。

更多乾貨，歡迎來撩~

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！