PTT數位生活區 / Database (資料庫)

[討論] oracle 效能問題

看板Database (資料庫)作者 (OEC)時間7年前 (2017/03/29 15:14), 7年前編輯推噓1(1推 0噓 26→)
留言27則, 6人參與, 最新討論串1/2 (看更多)
最近在進行災難演練 但是oracle資料庫的部分有個大問題 就是用了更好spec的硬體 更多的ram 更多core的CPU 較多的SGA & PGA 但是AP在load資料的速度反而更慢(差距幾分鐘以上) 原本DB是在8GB ram的VM(CentOS 5.5)上 新的我給了16GB(CentOS6.8 or Ubuntu 16) 前端搭配的是同個tomcat (code版本也都一樣) 請問可能是哪個環節出錯了嗎? 請大家不吝指教 謝謝 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 120.126.47.13 ※ 文章網址: https://www.ptt.cc/bbs/Database/M.1490771698.A.A28.html ※ 編輯: oscaroec (120.126.47.13), 03/29/2017 15:16:28
→
03/29 17:25, , 1F
database warm up?要比較也要把原本的db restart再比吧!XD
03/29 17:25, 1F
→
03/30 07:55, , 2F
同一樓，先跑個一陣子讓data進cache
03/30 07:55, 2F
→
03/30 07:56, , 3F
如果還是慢，監控新DB觀察wait event，可能是有些設定變了
03/30 07:56, 3F
→
03/30 07:57, , 4F
再來你的災難還原的手法是?雖然差別不大....
03/30 07:57, 4F
→
03/30 11:09, , 5F
雖然db已經開了好幾天 但我會試著再朝這方向試看看
03/30 11:09, 5F
→
03/30 11:10, , 6F
還原手法就是new一個Oracle 再把平常備份export的import
03/30 11:10, 6F
→
03/30 11:12, , 7F
其實我好奇的是CPU有辦法指定嗎? 給8core 都只吃1core
03/30 11:12, 7F
→
03/30 11:12, , 8F
觀察到的就CPU loading > 90%
03/30 11:12, 8F
→
03/30 11:20, , 9F
http://imgur.com/a/aZFVs EM 擷取CPU loading
03/30 11:20, 9F
→
03/30 11:50, , 10F
改用 data pump
03/30 11:50, 10F
→
03/30 19:57, , 11F
用exp/imp或pump都會讓DB快些，看來問題在CPU LOADING HIG
03/30 19:57, 11F
→
03/30 19:58, , 12F
幾個問題，舊SERVER的EM CPU狀況如何?Parallel相關的參數
03/30 19:58, 12F
→
03/30 19:59, , 13F
為何?EM CPU的地方再點進去，哪些SQL在作怪?
03/30 19:59, 13F
→
03/30 19:59, , 14F
不過還是建議匯出參數比對新舊DB有何差異
03/30 19:59, 14F
→
03/30 21:39, , 15F
舊DB EM pattern差不多 就是高但間距短(SQL是要改善)
03/30 21:39, 15F
→
03/30 21:40, , 16F
但新舊DB用的SQL是一樣的 新的spec up 卻不見改善
03/30 21:40, 16F
→
03/30 21:40, , 17F
我會再詳細比對一下參數 謝謝樓上幾位大大提供參考方向
03/30 21:40, 17F
→
03/30 21:58, , 18F
ㄟ你imp完有沒有重算統計值? imp完之後要重算吧
03/30 21:58, 18F
→
03/30 21:58, , 19F
實體資料分佈情況已經改變了...
03/30 21:58, 19F
→
03/30 22:52, , 20F
沒有 我也不知道那是什麼 ^^" 我會去查看看 謝謝您!
03/30 22:52, 20F
→
03/31 08:44, , 21F
請問ap load資料的方式為何？ 如果知道單拿一句load資
03/31 08:44, 21F
→
03/31 08:44, , 22F
料的語法個別在新舊硬體上跑之前先執行trace(sql trace
03/31 08:44, 22F
→
03/31 08:44, , 23F
,autotrace,oradebug,dbms_monitor)皆可，一比較後答
03/31 08:44, 23F
→
03/31 08:44, , 24F
案應該很容易就出來了。
03/31 08:44, 24F
→
03/31 09:16, , 25F
ap load資料的方式=>hibernate, OJB(?) 我會試試單純SQL
03/31 09:16, 25F
→
03/31 09:17, , 26F
上面的方法我都會survey一下 然後再回來跟大家分享結果
03/31 09:17, 26F
推
03/31 13:50, , 27F
主機的I/O 還有網路的狀態也要查 有可能跟DB無關
03/31 13:50, 27F
‣ 更多 oscaroec 的文章
文章代碼(AID): #1Osrxoee (Database)
討論串 (同標題文章)
以下文章回應了本文：
完整討論串 (本文為第 1 之 2 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共2篇)
Database 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 oscaroec 的文章
文章代碼(AID): #1Osrxoee (Database)