最近幾天對客戶的一個核心數據庫進行了優化，將資源消耗較高的SQL優化完成之后，物理讀和邏輯讀總量得到了降低?？蛻舴答亙灮笮阅苡刑嵘?，但仍然在某些工作日的業務高峰時段存在性能問題。 我們通過將性能不佳的業務高峰時段（即問題時段）與性能正常的業務
最近幾天對客戶的一個核心數據庫進行了優化，將資源消耗較高的SQL優化完成之后，物理讀和邏輯讀總量得到了降低。客戶反饋優化后性能有提升，但仍然在某些工作日的業務高峰時段存在性能問題。
我們通過將性能不佳的業務高峰時段（即問題時段）與性能正常的業務高峰時段（即基線時段）的性能數據進行了對比，發現了一些問題：
基線時段為2014-1-15日上午8:00-上午9:00，此時段TPS（每秒事務量）為：46T/s，該時段的總DB Time為：626.2 (mins)
問題時段為2014-1-20日上午8:00-上午9:00，此時段TPS為：47T/s（僅比基線時段多1T/s，可認為兩者業務量相當），該時段的總DB Time為2361.4 (mins)
同樣均為1小時的取樣時間段，問題段的總DB Time是基線的近4倍，而通過對比兩者的性能視圖，發現問題時段的單次IO延遲非常高，如下：
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
DB CPU 2,082 55.42
db file sequential read 62,140 774 12 20.61 User I/O
direct path read 177,440 575 3 15.31 User I/O
log file sync 17,486 145 8 3.86 Commit
gc cr block 2-way 98,519 30 0 0.80 Cluster
基線時段單次序列讀延時為12ms,單次直接讀延時為3ms，單次redolog寫延時為8ms，
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
direct path read 180,200 4,643 26 32.77 User I/O
db file sequential read 55,483 2,286 41 16.13 User I/O
DB CPU 1,917 13.53
gc buffer busy acquire 5,513 1,474 267 10.40 Cluster
log file sync 17,541 1,298 74 9.16 Commit
而問題時段單次序列讀延時為41ms,單次直接讀延時為26ms，單次redolog寫延時為74ms
（Oracle文檔中建議的單次IO正常延時應為0-20ms，否則需升級硬件），
即相比基線時段，在業務量不變的情況下，問題時段的IO效率下降非常明顯，懷疑是存儲層面的同一個RAID組中有其他業務系統有可能恰好在問題時段有大量的IO操作，
導致我們正在優化的系統的IO延遲較大。跟客戶的存儲人員確認發現確實如此，存儲人員并沒有結合數據庫對存儲做出合理規劃，僅僅從容量管理上對自己工作的方便性出發，劃分并分配LUN。由此導致性能問題，我想這種問題在很多企業都是存在的，跨部門之間的溝通不暢導致沒有從整體上的規劃出現，最終出現問題由DB買單。
因此建議客戶進行存儲改善：
1.將這種關鍵系統在存儲層面與其他系統隔離，避免互相影響IO；
2.有預算的情況下升級存儲。
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com
