今天在进行数据泵导入操作时，发现一个bug。

这篇文章描述问题的解决过程。

看来通过检查数据字典信息是找不到什么问题的原因了，只有通过手工执行收集统计信息的过程来尝试发现问题。

为了避免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文件，没想到问题这么轻易就解决了。