公司報表數據庫優化

報表系統優化

背景：

11.22早晨 剛放下揹包，收到一份郵件，郵件意思是公司報表數據庫慢，讓我幫忙看看。郵件還附帶了一個SQL文本，指出這個SQL慢。隨後電話了開發人員瞭解事情前因後果，原來是在一個月前 DB組幫他們遷移了報表數據庫，如今感受這個新環境比沒遷移前還要慢（因爲老環境已經回收了，到底慢多少已經無從考證了），老環境15分鐘跑完的任務新環境須要1個小時。新環境的硬件資源比老環境高了不少。

環境信息：

DB： oracle 11.2.0.4.0

OS：rhel 6.8

因爲庫被遷移過，詢問實施人員，包括統計信息，執行計劃固定都作過，按理說問題不大。

因爲如今數據庫總體比較慢，並且比老庫慢了4倍，因此初步判定是系統級別沒設置好致使。

我抓取了業務忙時的報告 發現3個問題：

1、Buffer Hit % =  54.32% db cahce命中率太低；

db buffercache hit命中率極低，建議調整大一點，能夠緩解IO的壓力。

 

二、IO延遲；

從awr報告能夠看出 IOPS爲712，顯然偏低。

經過iostat 測試，發現系統IO熱點太集中，詢問系統管理員 得知這個系統使用的是一個低端存儲，且存儲層面和數據庫層面沒有作條帶化。

 

1. redolog日誌切換過於頻繁

Log file switch 切換等待事件，發生這種等待事件要麼是系統太忙，要麼是日誌組太小，要麼是手動發起了切換命令。

查看數據庫日誌文件大小，

 

一看嚇一跳，一個報表系統的日誌組 才256MB？這不是搞笑的嘛！

數據庫redolog日誌 27MB/s產生 ，如今數據庫配置的 redolog 256M，這樣計算一個redolog 256/27=9s ，一個redolog 9s被寫滿。

從查詢來看，切換基本上也是9s，切換頻率過快，這樣會致使IO繁忙，

 

在同步數據的時候我看他們添加了 append ,建議結合使用 +nologging 插入方式。

 

總結：

1. Buffer hit%命中率過低；

---經過增長dbbuffercache 大小，若是是ASMM管理模式，能夠增長SGA大小能夠解決。大小能夠參考 v$db_cache_advice

1. 磁盤IO延遲太嚴重；

   ---須要提升存儲IO能力或者下降系統IO讀寫次數（優化SQL，下降物理讀 邏輯讀，開發不想改SQL）。在系統層面能夠經過dd 、iostat 來測試和監控IO指標。

1. 增長redolog日誌組大小；

----redog log切換推薦15~20分鐘一次，按照業務量計算設置爲2G合適。

 

結果：

週六遷移存儲到閃存，週一早上跑業務 11分鐘執行完成。由一小時到11分鐘，主要優化了 redolog 日誌組大小，dbbuffercache 大小和更換了存儲。

其實還能夠進一步優化系統能力，既然領導能接受現狀，我就不找事了。