expdp慢的一次處理思路,最後發現原來遇到了bug
1、檢查expdp時,資料庫是否負載太高,可以使用工具OSWatcher捕獲歷史的硬體資源使用情況,如果在負載低時,expdp還是很慢,繼續下面步驟2
2、檢查是否有大表或LOB欄位,如果沒有,繼續下面步驟3
3、expdp命令增加引數metrics、trace,檢視每個步驟的時間和trace檔案資訊中dm到dw的消耗時間,如果發現不了問題,繼續下面步驟4
METRICS=Y TRACE=480300
4、使用oradebug和10046 level 8捕獲expdp時的等待事件,tkprof格式化oradebug生成的trace檔案,檢視格式化後的檔案的最後資訊,是否出現Streams AQ: enqueue blocked on low memory等待時間很長,如果是,那麼是Bug 27634991,解決方法
connect / as sysdba
alter system set events 'immediate trace name mman_create_def_request level 6';
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/30126024/viewspace-2218794/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 「日常開發」記一次因使用Date引起的線上BUG處理
- RabbitMQ 處理過慢,原來是一個 SQL 快取框架導致的 GC 頻繁觸發MQSQL快取框架GC
- 記一次處理達夢慢SQL問題SQL
- 處理高併發的一般思路
- Oracle 12.1.0.2 expdp匯出分割槽表資料遇到BUG慢的原因和解決方法Oracle
- 處理生產bug
- MySQL 記一次 Bug發現過程MySql
- PGA引發的ORA-04030報錯的處理思路
- expdp/impdp變慢 (Doc ID 2469587.1)
- 遇見bug
- 高併發處理思路與手段(一):擴容
- 分割槽表truncate慢處理
- C#MVC基類實現事務處理思路C#MVC
- 在原神FES,發現最懂《原神》的玩家
- 解Bug之路-記一次線上請求偶爾變慢的排查
- mysqlconnect bug 處理一例。MySql
- bug及異常處理1
- ORACLE for aix 11.2.0.1 DATAPUMP expdp之BUG 9470768OracleAI
- MySQL分表後原分割槽表處理方案MySql
- 未來十年最後一次的財富週期(下)
- win10優化後開機慢怎麼解決_win10優化後開機慢如何處理Win10優化
- 處理VM的一種特殊方法和思路
- 解bug的幾種思路
- 探索TiDB Lightning的原始碼來解決發現的bugTiDB原始碼
- log file sync等待事件處理思路事件
- 高效能四核處理器開發的閘道器原來是這樣的
- Spark的危機與機遇:未來必然是AI框架倒推資料處理框架SparkAI框架
- A Inspire | 從敏捷軟體開發宣言中學到了處理危機的方法敏捷
- 慢Sql優化思路SQL優化
- 一次併發處理過程, 基於 RedisRedis
- win10最佳化後開機慢怎麼解決_win10最佳化後開機慢如何處理Win10
- 解Bug之路-記一次中介軟體導致的慢SQL排查過程SQL
- 後臺處理
- bug處理--antdesign中umi升級後無法載入子頁面
- 記一次業務人員誤刪資料後的處理方法
- 記一次手機刷成磚後的處理(非折騰部分)
- 最後一次搞懂 Event LoopOOP
- 常見佇列等待事件處理思路佇列事件