Oracle的資料庫高復原爭用的問題

來源:互聯網
上載者:User

一個客戶的資料庫出現了嚴重的效能問題,根據awr的報告,系統效能問題與復原的爭用有關係。

正常情況下,客戶資料庫的AWR的DB TIME資訊為:

Elapsed: 119.92 (mins)

DB Time: 22.99 (mins)

而出現問題的時刻,DB TIME資訊變成了:

Elapsed: 120.07 (mins)

DB Time: 37,447.52 (mins)

資料庫伺服器存在32顆CPU,可以看到,在採樣期間,這32顆CPU幾乎都是處於100%的工作狀態。

Top 5 Timed Events

Event                          Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class

enq: US – contention      1,995,867 943,404          473              42.0 Other

row cache lock               568,341 699,241        1,230              31.1 Concurrency

gc buffer busy               389,944 227,279          583              10.1 Cluster

enq: TX - index contention   393,340 171,647          436               7.6 Concurrency

buffer busy waits            186,159 107,135          576               4.8 Concurrency

觀察TOP 5等待事件,發現大部分等待發生在enq: US – contention和row cache lock上。根據這些資訊判斷,資料庫可能碰到了bug:7291739。

根據metalink上這個bug的描述,這個bug會出現大量的enq: US – contention等待,而且還是出現latch: row cache objects的等待。而在dc_rollback_segments上會出現比較嚴重的latch鎖。

檢查正常時刻awr報告中dc_rollback_segments統計資訊:

Cache               Get Requests Pct Miss Scan Reqs Pct Miss Mod Reqs Final Usage

dc_rollback_segments     185,406    0.00        0                0      3,615

而對於問題時刻,dc_rollback_segments統計為:

Cache               Get Requests Pct Miss Scan Reqs Pct Miss Mod Reqs Final Usage

dc_rollback_segments   4,805,587    0.01        0            3,073      3,613

顯然,出現問題時刻的dc_rollback_segments是正常時刻的50倍左右。

而另一方面,由於問題時刻之前,系統中出現了長啟動並執行SQL語句,是的系統中復原的爭用大幅度的增長:

Undo Segment Stats

End Time    Num Undo Blocks Number of Transactions Max Qry Len (s) Max Tx Concy

05-May 18:08          7,608                45,560           301        1,748

05-May 17:58          5,187                24,909             0        1,364

05-May 17:48          1,229                 7,471             0          307

05-May 17:38          2,942                16,753             0        1,002

05-May 17:28          1,119                 5,293             0          382

05-May 17:18          2,446                 6,925           898          502

05-May 17:08          2,137                 8,464           349          273

05-May 16:58          2,874                27,562             0            6

05-May 16:48          2,625                25,278             0            7

05-May 16:38          2,496                23,711         1,006            8

05-May 16:28          2,194                21,037           404            6

05-May 16:18          1,877                17,981             0            5

05-May 16:08          1,883                17,215             0            5

唯一的疑問是這個問題在10.2.0.4.4、10.2.0.5、11.2.0.1中被FIXED,而當前資料庫補丁打到了10.2.0.4.7,因此當前問題就是這個bug還存在疑問。

而除了bug:7291739之外,Oracle的Bug 8268775也都存在比較大的可能性。這個資料庫確實是一個RAC環境,而且在bug發生期間,確實存在大配量序會話串連到執行個體的情況發生。

如果要是碰到了這個bug,那麼在10.2中解決這個bug的可能性不大,至少要升級到11g才能解決這個問題。

作者:51cto部落格 Oracle小混子

返回欄目頁:http://www.bianceng.cnhttp://www.bianceng.cn/database/Oracle/

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.