Re: [討論] oracle 效能問題

作者: oscaroec (OEC)   2017-06-03 12:03:26
※ 引述《oscaroec (OEC)》之銘言:
: 最近在進行災難演練
: 但是oracle資料庫的部分有個大問題
: 就是用了更好spec的硬體
: 更多的ram 更多core的CPU 較多的SGA & PGA
: 但是AP在load資料的速度反而更慢(差距幾分鐘以上)
: 原本DB是在8GB ram的VM(CentOS 5.5)上
: 新的我給了16GB(CentOS6.8 or Ubuntu 16)
: 前端搭配的是同個tomcat (code版本也都一樣)
: 請問可能是哪個環節出錯了嗎?
: 請大家不吝指教 謝謝
後續針對版友建議做了一些處理
過程中也有一些心得
一起和大家分享
1.運用ORACLE內建的awrrpt.sql可以產生詳細的報表
須注意他是以每一個小時(整點)為一個單位
使用方法:
a.切換到該目錄,確認有無該sql檔
$cd $ORACLE_HOME/rdbms/admin
b.進入SQL
SQL>@awrrpt.sql
c.後續照著提示做,就會有一份精美的html報表
2.透過報表了解SGA, I/O or network wait等數據都正常
僅CPU loading高
把重點放在SQL statement的調整
3.雖然用virtual index有看到query速度改善
但實際建上去並不是這麼一回事
google了一下有幾個原因
資料分佈極端、statement內有一些導致index失效的語法
4.用hint的方式下參數強迫ORACLE用較多的CPU core去跑
在execute plan裡有看到明顯改善
目前還就研究相關設定
5.因為是用exp/imp方式 可能參數沒下好 analyzed date沒有更新
這個沒有直接解決我的問題
但是應該是重要且必須要做的事情
結果: 目前還在努力中,也認命的乖乖開始將awrrpt提到的top 5 busy SQL改寫
以上簡單回應目前的處理狀況
如果已知用火 還請各位高抬貴手
笑笑就好 (不然還要掃玻璃 會很麻煩...
作者: chefou (Ivan5)   2017-06-03 13:20:00
感謝分享,4跟5的部分,要注意統計資訊的收集
作者: LINGZ (肥兔小欽)   2017-06-04 22:39:00
推分享
作者: kobedisel (NO)   2017-06-06 22:17:00
第四點 不建議,除非該table 為hash partition, 且經過壓測,否則prod使用parallel通常效果會更差 90%以上(parallel是一把刀),單一測試效果可能好,多人使用時就會resource消耗更兇而得到更差的結果。尤其在parallel時的execution plan 有多個P->S時 效果可能跟想像的相反。
作者: oscaroec (OEC)   2017-06-07 13:04:00
感謝提醒~

Links booklink

Contact Us: admin [ a t ] ucptt.com