資料泵匯入分割槽表統計資訊報錯（二）
今天在進行資料泵匯入操作時，發現一個bug。
上一篇記錄了問題的現象，這一篇繼續深入研究。
資料泵匯入分割槽表統計資訊報錯（一）：http://yangtingkun.itpub.net/post/468/456176
上一篇文章已經描述了問題的產生，而且提到了這個問題很難重現。無論如何去模擬實際的情況，都無法重現問題。
為了重現這個問題，在RAC資料庫環境中，仿照問題表建立了分割槽表、並仿照問題資料庫收集了統計資訊的方式進行了統計資訊的收集，都無法重現問題。
但是，利用問題資料庫匯出的統計資訊，就可以重現問題。上週五發現的問題，但是由於資料不方便帶回家，因此由於時間的限制僅僅測試了這麼多。
今天一早到了公司，就繼續這個問題的測試。週末的時候仔細思考了一下，既然在測試的資料庫上無法重現問題，但是利用源資料庫的資料可以重現問題，那麼問題是否和資料本身有關，也就是說，是資料本身的問題導致了bug。
於是今天測試的時候嘗試使用問題資料，在多個不同平臺的Oracle10203的rac和單例項資料庫上嘗試執行資料泵匯入，錯誤屢試不爽。這樣看來，問題是源資料庫本身造成的，也與源資料庫目前的資料、統計資訊有關。
這樣將問題的目標從測試資料庫轉到的執行匯出的源資料庫中。
首先對比源資料庫和匯入資料庫中表分析情況，可以發現只有分割槽表的統計資訊沒有匯入，這就進一步確定了問題是發生在分割槽表中。
下面查詢一下源資料庫中表的分析情況：
SQL> SELECT TABLE_NAME, PARTITIONED, TEMPORARY, LAST_ANALYZED
2 FROM USER_TABLES
3 ORDER BY 4 DESC;
TABLE_NAME PAR T LAST_ANALYZED
------------------------------ --- - -------------------
ORD_HIT_COMM_TMP NO Y
CON_LIST_ITEM_SHARE_TMP NO Y
JOB_MONTH_STATS NO Y
ZZZ_PURCHASE_BUYER NO N 2008-03-02 02:14:45
ZZZ_YANGS_PRO NO N 2008-03-02 02:14:45
ZZZ_YANGS_ORDER3 NO N 2008-03-02 02:14:45
ZZZ_YANGS_ORDER2 NO N 2008-03-02 02:14:45
.
.
.
ASS_BBS_CATALOG NO N 2008-03-02 01:00:10
ASS_BBS_ARTICLE NO N 2008-03-02 01:00:09
A NO N 2008-03-02 01:00:08
ORD_LOG_HIT_COMM YES N 2007-05-03 15:33:45
CON_LOG_LIST_ITEM YES N 2007-05-03 15:33:19
ORD_PURCHASE_ITEM YES N 2007-05-03 15:33:17
ORD_ORDER_ITEM YES N 2007-05-03 15:30:25
ORD_ORDER YES N 2007-05-03 15:23:42
已選擇450行。
從這裡就可以看到分割槽表的資料分析存在問題，其他表的分析都是近期的，只有分割槽表的分析已經很長時間沒有更新了。
檢查分割槽表的分析方法：
SQL> SELECT WHAT, LAST_DATE FROM USER_JOBS WHERE JOB = 291;
WHAT LAST_DATE
-------------------------------------------------------- -------------------
dbms_stats.gather_schema_stats(user, cascade => true); 2008-03-02 01:00:02
採用這種方式進行分析，預設應該分析分割槽表才對，接著檢查分割槽表的各個分割槽是否分析過：
SQL> SELECT TABLE_NAME, PARTITION_NAME, LAST_ANALYZED
2 FROM USER_TAB_PARTITIONS
3 ORDER BY 1, 2;
TABLE_NAME PARTITION_NAME LAST_ANALYZED
------------------------------ ------------------------------ --------------
CON_LOG_LIST_ITEM CON0610
CON_LOG_LIST_ITEM CON0611
CON_LOG_LIST_ITEM CON0612
CON_LOG_LIST_ITEM CON0701
CON_LOG_LIST_ITEM CON_MAX
ORD_LOG_HIT_COMM HLG0610
ORD_LOG_HIT_COMM HLG0611
.
.
.
ORD_PURCHASE_ITEM ORD0804
ORD_PURCHASE_ITEM ORD0807
ORD_PURCHASE_ITEM ORD0810
ORD_PURCHASE_ITEM ORD0901
已選擇97行。
所有的分割槽都沒有分析過。檢查資料庫中其他SCHEMA下的分割槽表是否也存在相同的問題：
SQL> SELECT A.OWNER, A.TABLE_NAME, LAST_ANALYZED
2 FROM ALL_TABLES A, ALL_PART_TABLES B
3 WHERE A.TABLE_NAME = B.TABLE_NAME
4 AND A.OWNER = B.OWNER
5 AND A.OWNER IN ('ZHEJIANG', 'ANHUI', 'BEIJING')
6 ORDER BY 3;
OWNER TABLE_NAME LAST_ANALYZED
---------- ------------------------------ -------------------
ZHEJIANG ORD_ORDER 2007-05-03 15:23:42
ZHEJIANG ORD_ORDER_ITEM 2007-05-03 15:30:25
ZHEJIANG ORD_PURCHASE_ITEM 2007-05-03 15:33:17
ZHEJIANG CON_LOG_LIST_ITEM 2007-05-03 15:33:19
ZHEJIANG ORD_LOG_HIT_COMM 2007-05-03 15:33:45
ANHUI CON_LOG_LIST_ITEM 2008-03-02 22:00:53
ANHUI ORD_LOG_HIT_COMM 2008-03-02 22:04:22
ANHUI ORD_ORDER 2008-03-02 22:04:52
ANHUI ORD_ORDER_ITEM 2008-03-02 22:05:38
ANHUI ORD_PURCHASE_ITEM 2008-03-02 22:06:39
BEIJING CON_LOG_LIST_ITEM 2008-03-03 16:07:10
BEIJING ORD_LOG_HIT_COMM 2008-03-03 16:37:01
BEIJING ORD_ORDER 2008-03-03 16:40:18
BEIJING ORD_ORDER_ITEM 2008-03-03 16:57:56
BEIJING ORD_ORDER_RECEIVE 2008-03-03 17:03:52
BEIJING ORD_ORDER_RETURN 2008-03-03 17:05:24
BEIJING ORD_PURCHASE_ITEM 2008-03-03 17:14:41
17 rows selected.
其他使用者下的分割槽表最近都進行過分析，檢查一下分割槽的分析情況：
SQL> SELECT A.TABLE_OWNER OWNER, A.TABLE_NAME, A.PARTITION_NAME, LAST_ANALYZED
2 FROM ALL_TAB_PARTITIONS A, ALL_PART_TABLES B
3 WHERE A.TABLE_NAME = B.TABLE_NAME
4 AND A.TABLE_OWNER = B.OWNER
5 AND B.OWNER IN ('ZHEJIANG', 'ANHUI', 'BEIJING')
6 AND A.TABLE_NAME = 'ORD_ORDER'
7 ORDER BY 4;
OWNER TABLE_NAME PARTITION_ LAST_ANALYZED
---------- ---------- ---------- -------------------
ANHUI ORD_ORDER ORD0201 2008-03-02 22:04:32
ANHUI ORD_ORDER ORD0204 2008-03-02 22:04:32
ANHUI ORD_ORDER ORD0610 2008-03-02 22:04:32
ANHUI ORD_ORDER ORD0607 2008-03-02 22:04:32
ANHUI ORD_ORDER ORD0207 2008-03-02 22:04:32
ANHUI ORD_ORDER ORD0210 2008-03-02 22:04:32
ANHUI ORD_ORDER ORD0301 2008-03-02 22:04:32
ANHUI ORD_ORDER ORD0304 2008-03-02 22:04:32
ANHUI ORD_ORDER ORD0307 2008-03-02 22:04:32
ANHUI ORD_ORDER ORD0310 2008-03-02 22:04:32
ANHUI ORD_ORDER ORD0401 2008-03-02 22:04:32
ANHUI ORD_ORDER ORD0404 2008-03-02 22:04:32
ANHUI ORD_ORDER ORD0407 2008-03-02 22:04:32
ANHUI ORD_ORDER ORD0410 2008-03-02 22:04:32
ANHUI ORD_ORDER ORD0501 2008-03-02 22:04:32
ANHUI ORD_ORDER ORD0504 2008-03-02 22:04:32
ANHUI ORD_ORDER ORD0507 2008-03-02 22:04:32
ANHUI ORD_ORDER ORD0510 2008-03-02 22:04:32
ANHUI ORD_ORDER ORD0601 2008-03-02 22:04:32
ANHUI ORD_ORDER ORD0604 2008-03-02 22:04:32
ANHUI ORD_ORDER ORD0701 2008-03-02 22:04:33
ANHUI ORD_ORDER ORD0704 2008-03-02 22:04:35
ANHUI ORD_ORDER ORD0707 2008-03-02 22:04:43
ANHUI ORD_ORDER ORD0710 2008-03-02 22:04:48
ANHUI ORD_ORDER ORD0901 2008-03-02 22:04:48
ANHUI ORD_ORDER ORD0810 2008-03-02 22:04:48
ANHUI ORD_ORDER ORD0807 2008-03-02 22:04:48
ANHUI ORD_ORDER ORD0804 2008-03-02 22:04:48
ANHUI ORD_ORDER ORD0801 2008-03-02 22:04:48
BEIJING ORD_ORDER ORD0201 2008-03-03 16:37:09
BEIJING ORD_ORDER ORD0204 2008-03-03 16:37:10
BEIJING ORD_ORDER ORD0207 2008-03-03 16:37:12
BEIJING ORD_ORDER ORD0210 2008-03-03 16:37:17
BEIJING ORD_ORDER ORD0301 2008-03-03 16:37:20
BEIJING ORD_ORDER ORD0304 2008-03-03 16:37:24
BEIJING ORD_ORDER ORD0307 2008-03-03 16:37:27
BEIJING ORD_ORDER ORD0310 2008-03-03 16:37:35
BEIJING ORD_ORDER ORD0401 2008-03-03 16:37:38
BEIJING ORD_ORDER ORD0404 2008-03-03 16:37:43
BEIJING ORD_ORDER ORD0407 2008-03-03 16:37:48
BEIJING ORD_ORDER ORD0410 2008-03-03 16:38:00
BEIJING ORD_ORDER ORD0501 2008-03-03 16:38:08
BEIJING ORD_ORDER ORD0504 2008-03-03 16:38:16
BEIJING ORD_ORDER ORD0507 2008-03-03 16:38:24
BEIJING ORD_ORDER ORD0510 2008-03-03 16:38:38
BEIJING ORD_ORDER ORD0601 2008-03-03 16:38:47
BEIJING ORD_ORDER ORD0604 2008-03-03 16:38:56
BEIJING ORD_ORDER ORD0607 2008-03-03 16:39:07
BEIJING ORD_ORDER ORD0610 2008-03-03 16:39:16
BEIJING ORD_ORDER ORD0701 2008-03-03 16:39:25
BEIJING ORD_ORDER ORD0704 2008-03-03 16:39:34
BEIJING ORD_ORDER ORD0707 2008-03-03 16:39:43
BEIJING ORD_ORDER ORD0801 2008-03-03 16:39:46
BEIJING ORD_ORDER ORD0710 2008-03-03 16:39:46
BEIJING ORD_ORDER ORD0901 2008-03-03 16:39:46
BEIJING ORD_ORDER ORD0812 2008-03-03 16:39:46
BEIJING ORD_ORDER ORD0811 2008-03-03 16:39:46
BEIJING ORD_ORDER ORD0810 2008-03-03 16:39:46
BEIJING ORD_ORDER ORD0809 2008-03-03 16:39:46
BEIJING ORD_ORDER ORD0808 2008-03-03 16:39:46
BEIJING ORD_ORDER ORD0807 2008-03-03 16:39:46
BEIJING ORD_ORDER ORD0802 2008-03-03 16:39:46
BEIJING ORD_ORDER ORD0803 2008-03-03 16:39:46
BEIJING ORD_ORDER ORD0806 2008-03-03 16:39:46
BEIJING ORD_ORDER ORD0805 2008-03-03 16:39:46
BEIJING ORD_ORDER ORD0804 2008-03-03 16:39:46
ZHEJIANG ORD_ORDER ORD0607
ZHEJIANG ORD_ORDER ORD0610
ZHEJIANG ORD_ORDER ORD0701
ZHEJIANG ORD_ORDER ORD0704
ZHEJIANG ORD_ORDER ORD0707
ZHEJIANG ORD_ORDER ORD0710
ZHEJIANG ORD_ORDER ORD0801
ZHEJIANG ORD_ORDER ORD0804
ZHEJIANG ORD_ORDER ORD0807
ZHEJIANG ORD_ORDER ORD0810
ZHEJIANG ORD_ORDER ORD0604
ZHEJIANG ORD_ORDER ORD0601
ZHEJIANG ORD_ORDER ORD0510
ZHEJIANG ORD_ORDER ORD0507
ZHEJIANG ORD_ORDER ORD0504
ZHEJIANG ORD_ORDER ORD0501
ZHEJIANG ORD_ORDER ORD0410
ZHEJIANG ORD_ORDER ORD0407
ZHEJIANG ORD_ORDER ORD0404
ZHEJIANG ORD_ORDER ORD0401
ZHEJIANG ORD_ORDER ORD0310
ZHEJIANG ORD_ORDER ORD0307
ZHEJIANG ORD_ORDER ORD0901
ZHEJIANG ORD_ORDER ORD0301
ZHEJIANG ORD_ORDER ORD0210
ZHEJIANG ORD_ORDER ORD0207
ZHEJIANG ORD_ORDER ORD0204
ZHEJIANG ORD_ORDER ORD0201
ZHEJIANG ORD_ORDER ORD0304
95 rows selected.
這個結果更加說明，其他SCHEMA中的分割槽表沒有問題，而只有問題使用者的分割槽表才出現錯誤。
莫非是收集統計資訊的方法有差異：
SQL> SELECT LOG_USER, WHAT FROM DBA_JOBS
2 WHERE UPPER(WHAT) LIKE '%DBMS_STATS%'
3 AND LOG_USER IN ('ANHUI', 'BEIJING', 'ZHEJIANG');
LOG_USER WHAT
-------------------- --------------------------------------------------------
ANHUI dbms_stats.gather_schema_stats(user, cascade => true);
ZHEJIANG dbms_stats.gather_schema_stats(user, cascade => true);
BEIJING dbms_stats.gather_schema_stats(user, cascade => true);
可以看到三個SCHEMA採用完全相同的方法來收集統計資訊，但是得到的結果確不相同，問題變得越來越有意思了。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/4227/viewspace-199243/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 資料泵匯入分割槽表統計資訊報錯（七）
- 資料泵匯入分割槽表統計資訊報錯（四）
- 資料泵匯入分割槽表統計資訊報錯（三）
- 資料泵匯入分割槽表統計資訊報錯（六）
- 資料泵匯入分割槽表統計資訊報錯（五）
- 資料泵匯入分割槽表長時間HANG住
- 使用PARTITION_OPTIONS引數控制資料泵分割槽表匯入
- 分割槽表匯入資料庫資料庫
- 匯入匯出 Oracle 分割槽表資料Oracle
- 資料泵匯出匯入表
- 大資料量分割槽表統計資訊的管理大資料
- 分割槽表入無分割槽的資料庫資料庫
- Oracle使用資料泵匯出匯入表Oracle
- 使用expdp匯出分割槽表中的部分分割槽資料
- 資料泵匯出匯入
- 資料泵匯出索引資料和統計資訊嗎索引
- 資料泵避免個別表資料的匯出（二）
- 【實驗】【PARTITION】exp匯出分割槽表資料
- Impdp資料泵匯入
- [oracle] expdp 匯出分割槽表的分割槽Oracle
- 資料泵的匯入匯出
- 表統計資訊匯出匯入指令碼指令碼
- Oracle資料泵－schema匯入匯出Oracle
- 使用資料泵impdp匯入資料
- 學習筆記】分割槽表和分割槽索引——新增表分割槽（二）筆記索引
- 交流（二）--分割槽表統計分析耗時太長
- 資料泵匯出匯入資料標準文件
- 10g資料泵和匯入匯出效能對比（二）
- Oracle使用資料泵在異機之間匯出匯入表Oracle
- Oracle資料泵的匯入和匯出Oracle
- Oracle資料泵匯出匯入（expdp/impdp）Oracle
- 資料泵取匯出和匯入（一）
- 資料庫系統設計：分割槽資料庫
- 11g解決imp匯入資料時報錯：插入資料找不到相應分割槽
- 資料泵無法匯入JOB
- 資料泵匯出資料包錯處理
- 轉oracle資料泵匯出時報錯Oracle
- 自動備份、截斷分割槽表分割槽資料