記一次expdp匯出任務中某張大表報錯問題的解決過程

問題現象：

解決過程Level1：

1. 出現ORA-01555錯誤，通常有2種情況：

（1）SQL語句執行時間太長，或者UNDO表空間過小，或者事務量過大，或者過於頻繁的提交，導致執行SQL過程中進行一致性讀時，SQL執行後修改的前映象（即UNDO資料）在UNDO表空間中已經被覆蓋，不能構造一致性讀塊（CR blocks）。  這種情況最多。

（2）SQL語句執行過程中，訪問到的塊，在進行延遲塊清除時，不能確定該塊的事務提交時間與SQL執行開始時間的先後次序。 這種情況很少。

2. 第1種情況解決的辦法：

（1）增加UNDO表空間大小

（2）增加undo_retention 時間，預設只有15分鐘

資料庫undo表空間使用率極低，將undo_retention由預設的900秒調整到5400秒，報錯解決。

解決過程Level2：

       一張不到10G的表，匯出耗時了一小時還多，肯定是有異常的，決定深挖這個問題。執行了單表資料泵匯出，發現耗時為1小時（多次執行誤差在5分鐘內），執行以下sql進行具體分析：

select count(*),avg(time_waited)/1000,event,program,blocking_session from v$active_session_history where sample_time between to_date('2021-02-19 08:30','yyyy-mm-dd hh24:mi) and to_date('2021-02-19 09:45','yyyy-mm-dd hh24:mi) and blocking_session is not null group by event,program order by 2

發現事件裡面有報記憶體不足，遂調整stream pool大小，由64m增加到128m，再次執行單表資料泵匯出，發現耗時減少至50分鐘左右。

解決過程Level3：

       一張不到10G的表，匯出耗時近1一小時，肯定依舊存在問題，繼續挖！

目標轉移至系統備庫，測試同樣的表匯出耗時，不測不知道一測嚇一跳，相同效能相同資料量的備庫，同樣的表匯出只用了5分鐘，主備庫差異主要為主庫執行著系統程式，備庫什麼程式都沒跑，遂找到視窗期將主庫所有連庫程式停掉，再次測試，發現耗時縮短至40分鐘，有改善，但根源問題依舊沒有解決！

解決過程Level4：

       分析主備庫AWR報告，發現執行資料泵匯出時段，效能差異主要區別在IO上，主庫比備庫多出了太多的IO讀寫操作，好了，此刻似乎可以帥鍋給作業系統了，硬體問題、作業系統安裝問題、作業系統配置問題……總之就是跟我資料庫沒有關係了。

解決過程Level5：

       本著根源挖到底的原則，繼續查閱資料，發現有如下概念會影響IO：行遷移（參考連結： https://blog.csdn.net/hotye393/article/details/6226471）

主備庫依次執行以下操作：@/home/oracle/product/11.2.0/rdbms/admin/utlchain.sql

analyze table ***.************ list chained rows;

比對結果數量：select count(*) from chained_rows，最終發現根源原因，主庫比備庫多出了近十倍的行遷移！！！

問題根源找到了，解決方法就水到渠成了：

1. alter table ***.******** move nologging parallel 4;
   

2. alter table ***.******** logging noparallel;

3. select index_name from dba_indexes where table_name='*******';

4. alter index ***.******** rebuild;

表匯出耗時2分鐘，已超越備庫，至此問題得到徹底解決！