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

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