通過重啟資料庫，完成了一次優化

westzq1984發表於2013-04-07
資料庫優化
前段時間跟了一個很有意思的優化專案
解決嚴重的效能問題只需要幹一件事情：重啟資料庫，而且不會復發

Load Profile


Per Second Per Transaction Per Exec Per Call
DB Time(s): 31.1 4.9 0.24 0.09
DB CPU(s): 3.3 0.5 0.03 0.01
Redo size: 19,867.7 3,120.1

Logical reads: 8,721.6 1,369.7

Block changes: 108.2 17.0

Physical reads: 451.1 70.8

Physical writes: 5.8 0.9

User calls: 345.5 54.3

Parses: 79.3 12.5

Hard parses: 0.5 0.1

W/A MB processed: 77,431.2 12,159.9

Logons: 3.1 0.5

Executes: 128.1 20.1

Rollbacks: 2.7 0.4

Transactions: 6.4


Instance Efficiency Percentages (Target 100%)

Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 99.87 In-memory Sort %: 100.00
Library Hit %: 99.57 Soft Parse %: 99.34
Execute to Parse %: 38.10 Latch Hit %: 99.71
Parse CPU to Parse Elapsd %: 0.00 % Non-Parse CPU: 32.80

Shared Pool Statistics


Begin End
Memory Usage %: 86.58 85.75
% SQL with executions>1: 94.44 94.08
% Memory for SQL w/exec>1: 91.11 90.69

Top 5 Timed Foreground Events

Event Waits Time(s) Avg wait (ms) % DB time Wait Class
library cache: mutex X 225,287,761 44,877 0 40.14 Concurrency
latch: shared pool 9,940 37,235 3746 33.30 Concurrency
latch free 3,031 11,828 3902 10.58 Other
DB CPU
11,772
10.53
enq: TX - row lock contention 260 2,190 8425 1.96 Application

系統負載極輕，但是CPU 100%,系統遭遇到了嚴重的latch & mutex 爭用
硬解析也極少，對於一個12C的系統，完全在承受的範圍內
cursor_sharing在系統出現效能問題後，已經在Oracle的建議下修改為force，但是基本沒有好轉

做了個ASH的切片，確認持有library cache: mutex X 的會話，在等待latch: shared pool，而持有SP latch的會話，只是在on cpu,說明SP latch是主因。

先開始懷疑是BUG，畢竟硬解析很少，後來沒找到相關的BUG
檢查了下SP latch的數目，竟然才1個，對於一個12C的系統，應該有3個SP latch才對，和客戶交流，原來他們系統本來只有4C，後來出現了嚴重的效能問題後，動態調了8C過來。

雖然CPU_COUNT從10g開始，可以隨動態調整而增加，但是SP latch的數目，是無法動態增加的，隨著本來系統就有的硬解析問題的積累，導致共享池嚴重碎片化，最終積累成了嚴重的效能問題。

重啟了資料庫後，困擾客戶幾個月的效能問題就這樣解決了

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/8242091/viewspace-757919/，如需轉載，請註明出處，否則將追究法律責任。

相關文章