看板 Database 關於我們 聯絡資訊
※ 引述《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改寫 以上簡單回應目前的處理狀況 如果已知用火 還請各位高抬貴手 笑笑就好 (不然還要掃玻璃 會很麻煩... -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 120.126.47.13 ※ 文章網址: https://www.ptt.cc/bbs/Database/M.1496462611.A.4AA.html
chefou: 感謝分享,4跟5的部分,要注意統計資訊的收集 06/03 13:20
LINGZ: 推分享 06/04 22:39
kobedisel: 第四點 不建議,除非該table 為hash partition, 且經過 06/06 22:17
kobedisel: 壓測,否則prod使用parallel通常效果會更差 90%以上(p 06/06 22:17
kobedisel: arallel是一把刀),單一測試效果可能好,多人使用時就 06/06 22:17
kobedisel: 會resource消耗更兇而得到更差的結果。 06/06 22:17
kobedisel: 尤其在parallel時的execution plan 有多個P->S時 效果 06/06 22:20
kobedisel: 可能跟想像的相反。 06/06 22:20
oscaroec: 感謝提醒~ 06/07 13:04