今天在进行数据泵导入操作时,发现一个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文件,没想到问题这么轻易就解决了。