資料泵匯入分割槽表統計資訊報錯（四）
今天在進行資料泵匯入操作時，發現一個bug。
這篇文章描述問題的解決過程。
資料泵匯入分割槽表統計資訊報錯（一）：http://yangtingkun.itpub.net/post/468/456176
資料泵匯入分割槽表統計資訊報錯（二）：http://yangtingkun.itpub.net/post/468/456378
資料泵匯入分割槽表統計資訊報錯（三）：http://yangtingkun.itpub.net/post/468/489067
看來透過檢查資料字典資訊是找不到什麼問題的原因了，只有透過手工執行收集統計資訊的過程來嘗試發現問題。
為了避免bug意外被解決所導致的問題無法重現，同時也為了可以在解決bug的過程中使用一些特別的手段而不影響使用者的使用，這裡透過備份建立了一個測試環境，下面的操作是在測試環境中執行。
首先修改統計資訊對應的JOB的NEXT_DATE，使其在後臺執行，檢查收集統計資訊後，測試資料庫上是否能重現問題：
SQL> SELECT JOB, WHAT FROM USER_JOBS;
JOB WHAT
---------- ------------------------------------------------------------
27 dbms_stats.gather_schema_stats(user, cascade => true);
SQL> EXEC DBMS_JOB.NEXT_DATE(27, SYSDATE)
PL/SQL 過程已成功完成。
SQL> COMMIT;
提交完成。
等待一段時間後檢查USER_TABLES，發現除了3個分割槽表外，其他的物件的統計資訊都收集了：
SQL> SELECT TABLE_NAME, LAST_ANALYZED FROM USER_TABLES;
TABLE_NAME LAST_ANALYZED
------------------------------ -------------------
ORD_ORDER_CHECK 2009-08-07 16:11:55
ORD_ORDER_CHECK_TERM 2009-08-07 16:11:55
ORD_ORDER_ITEM_NO_FOSHAN 2009-08-07 16:11:55
ORD_ORDER_ITEM_NO_SHUDE 2009-08-07 16:11:55
ORD_ORDER_OOS_HISTORY 2009-08-07 16:11:57
ORD_ORDER_PAY 2009-08-07 16:12:02
ORD_ORDER_RETURN 2009-08-07 16:16:24
ORD_ORDER_TOTAL_FOSHAN 2009-08-07 16:16:26
ORD_ORDER_TOTAL_SHUDE 2009-08-07 16:16:26
ORD_PURCHASE 2009-08-07 16:16:37
ORD_PURCHASE_ITEM 2007-05-03 15:33:17
ORD_ORDER_ITEM 2007-05-03 15:30:25
ORD_ORDER 2007-05-03 15:23:42
ORD_ORDER_RECEIVE 2009-08-07 16:15:00
已選擇14行。
SQL> SELECT TABLE_NAME FROM USER_PART_TABLES;
TABLE_NAME
------------------------------
ORD_ORDER
ORD_ORDER_ITEM
ORD_PURCHASE_ITEM
如果JOB自動執行存在問題，那麼嘗試手工呼叫RUN過程：
SQL> EXEC DBMS_JOB.RUN(27)
PL/SQL 過程已成功完成。
SQL> SELECT TABLE_NAME, LAST_ANALYZED FROM USER_TABLES;
TABLE_NAME LAST_ANALYZED
------------------------------ -------------------
ORD_ORDER_CHECK 2009-08-07 16:23:53
ORD_ORDER_CHECK_TERM 2009-08-07 16:23:54
ORD_ORDER_ITEM_NO_FOSHAN 2009-08-07 16:23:54
ORD_ORDER_ITEM_NO_SHUDE 2009-08-07 16:23:54
ORD_ORDER_OOS_HISTORY 2009-08-07 16:23:56
ORD_ORDER_PAY 2009-08-07 16:24:00
ORD_ORDER_RETURN 2009-08-07 16:29:14
ORD_ORDER_TOTAL_FOSHAN 2009-08-07 16:29:16
ORD_ORDER_TOTAL_SHUDE 2009-08-07 16:29:16
ORD_PURCHASE 2009-08-07 16:29:23
ORD_PURCHASE_ITEM 2007-05-03 15:33:17
ORD_ORDER_ITEM 2007-05-03 15:30:25
ORD_ORDER 2007-05-03 15:23:42
ORD_ORDER_RECEIVE 2009-08-07 16:27:04
已選擇14行。
問題依舊，既然透過JOB呼叫存在問題，嘗試手工執行DBMS_STATS包：
SQL> EXEC dbms_stats.gather_schema_stats(user, cascade => true);
PL/SQL 過程已成功完成。
SQL> SELECT TABLE_NAME, LAST_ANALYZED FROM USER_TABLES;
TABLE_NAME LAST_ANALYZED
------------------------------ -------------------
ORD_ORDER_CHECK 2009-08-07 16:39:25
ORD_ORDER_CHECK_TERM 2009-08-07 16:39:26
ORD_ORDER_ITEM_NO_FOSHAN 2009-08-07 16:39:26
ORD_ORDER_ITEM_NO_SHUDE 2009-08-07 16:39:26
ORD_ORDER_OOS_HISTORY 2009-08-07 16:39:28
ORD_ORDER_PAY 2009-08-07 16:39:33
ORD_ORDER_RETURN 2009-08-07 16:44:03
ORD_ORDER_TOTAL_FOSHAN 2009-08-07 16:44:06
ORD_ORDER_TOTAL_SHUDE 2009-08-07 16:44:06
ORD_PURCHASE 2009-08-07 16:44:14
ORD_PURCHASE_ITEM 2007-05-03 15:33:17
ORD_ORDER_ITEM 2007-05-03 15:30:25
ORD_ORDER 2007-05-03 15:23:42
ORD_ORDER_RECEIVE 2009-08-07 16:42:44
已選擇14行。
手工呼叫DBMS_STATS包收集當前SCHEMA的物件同樣會遺漏3個分割槽表，下面直接以表級的方式收集ORD_ORDER表的統計資訊：
SQL> exec dbms_stats.gather_table_stats(user, 'ORD_ORDER')
BEGIN dbms_stats.gather_table_stats(user, 'ORD_ORDER'); END;
*
第 1 行出現錯誤:
ORA-20005: object statistics are locked (stattype = ALL)
ORA-06512: 在 "SYS.DBMS_STATS", line 13182
ORA-06512: 在 "SYS.DBMS_STATS", line 13202
ORA-06512: 在 line 1
SQL> exec dbms_stats.gather_table_stats(user, 'ORD_ORDER_ITEM')
BEGIN dbms_stats.gather_table_stats(user, 'ORD_ORDER_ITEM'); END;
*
第 1 行出現錯誤:
ORA-20005: object statistics are locked (stattype = ALL)
ORA-06512: 在 "SYS.DBMS_STATS", line 13182
ORA-06512: 在 "SYS.DBMS_STATS", line 13202
ORA-06512: 在 line 1
收集統計資訊的過程報錯了。這是一個好訊息，有了錯誤資訊就容易定位問題了，如果沒有報錯且系統還不正常，問題才更難解決。
而且這個錯誤資訊其實已經很明確了，表的統計資訊被鎖住了，而Oracle的DBMS_STATS包就有UNLOCK的過程：
SQL> exec dbms_stats.unlock_table_stats(user, 'ORD_ORDER')
PL/SQL 過程已成功完成。
SQL> exec dbms_stats.gather_table_stats(user, 'ORD_ORDER')
PL/SQL 過程已成功完成。
SQL> SELECT TABLE_NAME, LAST_ANALYZED FROM USER_TABLES;
TABLE_NAME LAST_ANALYZED
------------------------------ -------------------
ORD_ORDER_CHECK 2009-08-07 16:39:25
ORD_ORDER_CHECK_TERM 2009-08-07 16:39:26
ORD_ORDER_ITEM_NO_FOSHAN 2009-08-07 16:39:26
ORD_ORDER_ITEM_NO_SHUDE 2009-08-07 16:39:26
ORD_ORDER_OOS_HISTORY 2009-08-07 16:39:28
ORD_ORDER_PAY 2009-08-07 16:39:33
ORD_ORDER_RETURN 2009-08-07 16:44:03
ORD_ORDER_TOTAL_FOSHAN 2009-08-07 16:44:06
ORD_ORDER_TOTAL_SHUDE 2009-08-07 16:44:06
ORD_PURCHASE 2009-08-07 16:44:14
ORD_PURCHASE_ITEM 2007-05-03 15:33:17
ORD_ORDER_ITEM 2007-05-03 15:30:25
ORD_ORDER 2009-08-07 17:27:32
ORD_ORDER_RECEIVE 2009-08-07 16:42:44
已選擇14行。
對於DBMS_STATS.GATHER_SCHEMA_STATS過程來說，發現一些表的統計資訊被鎖定，自動跳過了這些表的統計資訊的收集過程，因此一致沒有報錯。本來以為要對DBMS_STATS包的執行過程進行TRACE，然後分析TRACE檔案，沒想到問題這麼輕易就解決了。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/4227/viewspace-611938/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 資料泵匯入分割槽表統計資訊報錯（七）
- 資料泵匯入分割槽表統計資訊報錯（二）
- 資料泵匯入分割槽表統計資訊報錯（三）
- 資料泵匯入分割槽表統計資訊報錯（六）
- 資料泵匯入分割槽表統計資訊報錯（五）
- 資料泵匯入分割槽表長時間HANG住
- 使用PARTITION_OPTIONS引數控制資料泵分割槽表匯入
- 分割槽表匯入資料庫資料庫
- 匯入匯出 Oracle 分割槽表資料Oracle
- 資料泵匯出匯入表
- 大資料量分割槽表統計資訊的管理大資料
- 分割槽表入無分割槽的資料庫資料庫
- Oracle使用資料泵匯出匯入表Oracle
- 使用expdp匯出分割槽表中的部分分割槽資料
- 資料泵匯出匯入
- 對比資料泵與原始匯入匯出工具（四）
- 資料泵匯出索引資料和統計資訊嗎索引
- 【實驗】【PARTITION】exp匯出分割槽表資料
- Impdp資料泵匯入
- [oracle] expdp 匯出分割槽表的分割槽Oracle
- 資料泵的匯入匯出
- 表統計資訊匯出匯入指令碼指令碼
- 10g資料泵和匯入匯出效能對比（四）
- Oracle資料泵－schema匯入匯出Oracle
- 使用資料泵impdp匯入資料
- 資料泵匯出匯入資料標準文件
- Oracle使用資料泵在異機之間匯出匯入表Oracle
- Oracle資料泵的匯入和匯出Oracle
- Oracle資料泵匯出匯入（expdp/impdp）Oracle
- 資料泵取匯出和匯入（一）
- 資料庫系統設計：分割槽資料庫
- 11g解決imp匯入資料時報錯：插入資料找不到相應分割槽
- 資料泵無法匯入JOB
- 【學習筆記】分割槽表和分割槽索引——管理索引分割槽（四）筆記索引
- 資料泵匯出資料包錯處理
- 轉oracle資料泵匯出時報錯Oracle
- 自動備份、截斷分割槽表分割槽資料
- oracle分割槽表學習（四）Oracle