Statspack報告分析—第二部分：Load Profile 負載情況

Statspack報告分析—第二部分：Load Profile 負載情況

這一部分統計了資料庫的負載情況，需要和以前的Statspack的報告進行比較，分析資料庫的負載情況是否有所變動。這裡的統計資料基本上以每個事務和每秒鐘。

[@more@]

Statspack報告分析—第二部分：Load Profile 負載情況

這一部分統計了資料庫的負載情況，需要和以前的Statspack的報告進行比較，分析資料庫的負載情況是否有所變動。這裡的統計資料基本上以每個事務和每秒鐘。

Load Profile ~~~~~~~~~~~~ Per Second Per Transaction --------------- --------------- Redo size: 21,023.07 5,799.08 Logical reads: 4,649.83 1,282.63 Block changes: 116.86 32.24 Physical reads: 23.56 6.50 Physical writes: 9.47 2.61 User calls: 14.75 4.07 Parses: 8.16 2.25 Hard parses: 0.87 0.24 Sorts: 44.17 12.18 Transactions: 3.63 Rows per Sort: 90.24 Pct Blocks changed / Read: 2.51 Recursive Call Pct: 92.80 Rollback / transaction Pct: 0.45

每秒鐘的統計資訊展示了在整個統計過程中變化的情況：

l 如果’redo size’, ‘block changes’, ‘pctof blocks changed per read’有顯著的增漲，說明系統有更多的insers/updates/deletes操作

l ‘redo size’有增漲，而’transactions per second’沒有增漲，說明事務的情況有所變化

同樣，看每程式的統計變化情況也可以看出應用的變化。比較2個報告，需要考慮這2個報告的統計時間內系統是否工作在差不多的負載下，如果這2個報告是在完全不同的工作負載下，沒有任何比較的意義。

高負載率

如果拋開基準線（baseline）,很難來來判定一個系統是否處於非常繁忙的狀態。系統處於不同的站點、不同的CPU數量和速度、不同的作業系統、不同的系統IO、不同的Oracle版本下，效能不一樣。但是有一些通常的規則：

• Hard parse： 如果高於每秒100個，那麼處於一個很高的水準。高階別的hard parse容易引起嚴重的系統效能問題，必須要解決的。高的hard parse通常會引起shared pool 和library cache的latch爭用。檢查latch free是否出現在前五位等待事件中，如果有，檢查一下statspack報告中的latch這一節。
• Soft parse ： 高的soft parse可能會大於每秒300次。不必要的soft parse也會限制應用的可測量性（scalability）, 可以在session中，一個SQL語句只進行一次soft parse，而使用多次。

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