→ LINGZ: database warm up?要比較也要把原本的db restart再比吧!XD 03/29 17:25
→ kb0130: 同一樓,先跑個一陣子讓data進cache 03/30 07:55
→ kb0130: 如果還是慢,監控新DB觀察wait event,可能是有些設定變了 03/30 07:56
→ kb0130: 再來你的災難還原的手法是?雖然差別不大.... 03/30 07:57
→ oscaroec: 雖然db已經開了好幾天 但我會試著再朝這方向試看看 03/30 11:09
→ oscaroec: 還原手法就是new一個Oracle 再把平常備份export的import 03/30 11:10
→ oscaroec: 其實我好奇的是CPU有辦法指定嗎? 給8core 都只吃1core 03/30 11:12
→ oscaroec: 觀察到的就CPU loading > 90% 03/30 11:12
→ chefou: 改用 data pump 03/30 11:50
→ kb0130: 用exp/imp或pump都會讓DB快些,看來問題在CPU LOADING HIG 03/30 19:57
→ kb0130: 幾個問題,舊SERVER的EM CPU狀況如何?Parallel相關的參數 03/30 19:58
→ kb0130: 為何?EM CPU的地方再點進去,哪些SQL在作怪? 03/30 19:59
→ kb0130: 不過還是建議匯出參數比對新舊DB有何差異 03/30 19:59
→ oscaroec: 舊DB EM pattern差不多 就是高但間距短(SQL是要改善) 03/30 21:39
→ oscaroec: 但新舊DB用的SQL是一樣的 新的spec up 卻不見改善 03/30 21:40
→ oscaroec: 我會再詳細比對一下參數 謝謝樓上幾位大大提供參考方向 03/30 21:40
→ iFEELing: ㄟ你imp完有沒有重算統計值? imp完之後要重算吧 03/30 21:58
→ iFEELing: 實體資料分佈情況已經改變了... 03/30 21:58
→ oscaroec: 沒有 我也不知道那是什麼 ^^" 我會去查看看 謝謝您! 03/30 22:52
→ kobedisel: 請問ap load資料的方式為何? 如果知道單拿一句load資 03/31 08:44
→ kobedisel: 料的語法個別在新舊硬體上跑之前先執行trace(sql trace 03/31 08:44
→ kobedisel: ,autotrace,oradebug,dbms_monitor)皆可,一比較後答 03/31 08:44
→ kobedisel: 案應該很容易就出來了。 03/31 08:44
→ oscaroec: ap load資料的方式=>hibernate, OJB(?) 我會試試單純SQL 03/31 09:16
→ oscaroec: 上面的方法我都會survey一下 然後再回來跟大家分享結果 03/31 09:17
推 chefou: 主機的I/O 還有網路的狀態也要查 有可能跟DB無關 03/31 13:50