報表系統優化
背景：
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的壓力。
2、IO延遲；
從awr報告可以看出 IOPS爲712，顯然偏低。
通過iostat 測試，發現系統IO熱點太集中，詢問系統管理員 得知這個系統使用的是一個低端存儲，且存儲層面和數據庫層面沒有做條帶化。
- redolog日誌切換過於頻繁
Log file switch 切換等待事件，發生這種等待事件要麼是系統太忙，要麼是日誌組過小，要麼是手動發起了切換命令。
查看數據庫日誌文件大小，
一看嚇一跳，一個報表系統的日誌組 才256MB？這不是搞笑的嘛！
數據庫redolog日誌 27MB/s產生 ，現在數據庫配置的 redolog 256M，這樣計算一個redolog 256/27=9s ，一個redolog 9s被寫滿。
從查詢來看，切換基本上也是9s，切換頻率過快，這樣會導致IO繁忙，
在同步數據的時候我看他們添加了 append ,建議結合使用 +nologging 插入方式。
總結：
- Buffer hit%命中率太低；
---通過增加dbbuffercache 大小，如果是ASMM管理模式，可以增加SGA大小可以解決。大小可以參考 v$db_cache_advice
- 磁盤IO延遲太嚴重；
---需要提高存儲IO能力或者降低系統IO讀寫次數（優化SQL，降低物理讀 邏輯讀，開發不想改SQL）。在系統層面可以通過dd 、iostat 來測試和監控IO指標。
- 增加redolog日誌組大小；
----redog log切換推薦15~20分鐘一次，按照業務量計算設置爲2G合適。
結果：
週六遷移存儲到閃存，週一早上跑業務 11分鐘執行完成。由一小時到11分鐘，主要優化了 redolog 日誌組大小，dbbuffercache 大小和更換了存儲。
其實還可以進一步優化系統能力，既然領導能接受現狀，我就不找事了。