记一次oracle cpu飚满，原因却是数据库导入问题

最近项目重新部署了，发现经常cpu飚满，服务器压力极大，通过网上各种搜索基本都是订单表的查询语句，占用了系统资源，还导出了awr报告看，也是这样，但是分析这个sql有没有问题也有索引，单独跑着个sql需要出来的时间也是不到1s 。也因为订单表查询较大，所以各种awr报表和sql查询占cpu的高的这些，还有像“latch:cache buffers chains”都是指向那个sql。

我们的导入导出都是有的expdp/impdp这2个工具。

一直找不到问题，突然才想起这个数据库是有测试环境导向正式环境的，而那个测试环境是有原因来项目导到测试环境删数据完成的，我好想记得当时到有原来项目导到测试环境时是有个报错，马上登陆测试环境机器，查看当时导入时的日志文件，果然有如下错误：

Processing object type SCHEMA_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
ORA-39083: Object type INDEX_STATISTICS failed to create with error:
ORA-01821: date format not recognized
Failing sql is:
DECLARE I_N VARCHAR2(60);   I_O VARCHAR2(60);   c DBMS_METADATA.T_VAR_COLL;   df varchar2(21) := 'YYYY-MM-DD:HH24:MI:SS'; BEGIN  DELETE FROM "SYS"."IMPDP_STATS";   i_n := 'YW_IN_ORDER_INDEX1';   i_o := 'GS';   INSERT INTO "SYS"."IMPDP_STATS" (type,version,flags,c1,c2,c3,c5,n1,n2,n3,n4,n5,n6,n7,n8,n9,n10,n11,n12,d1,cl1) VALUES ('I',5,2,I_N,NULL,NULL,I_O,4563931,24028,1369344,1,2,373457
ORA-39083: Object type INDEX_STATISTICS failed to create with error:
ORA-01820: format code cannot appear in date input format
Failing sql is:
DECLARE I_N VARCHAR2(60);   I_O VARCHAR2(60);   c DBMS_METADATA.T_VAR_COLL;   df varchar2(21) := 'YYYY-MM-DD:HH24:MI:SS'; BEGIN  DELETE FROM "SYS"."IMPDP_STATS";   i_n := 'IDX_IN_ORDER_COMPLEX1';   i_o := 'GS';   INSERT INTO "SYS"."IMPDP_STATS" (type,version,flags,c1,c2,c3,c5,n1,n2,n3,n4,n5,n6,n7,n8,n9,n10,n11,n12,d1,cl1) VALUES ('I',5,2,I_N,NULL,NULL,I_O,4336427,1
Processing object type SCHEMA_EXPORT/TABLE/COMMENT
Processing object type SCHEMA_EXPORT/FUNCTION/FUNCTION
Processing object type SCHEMA_EXPORT/PROCEDURE/PROCEDURE
Processing object type SCHEMA_EXPORT/FUNCTION/ALTER_FUNCTION
Processing object type SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE
Processing object type SCHEMA_EXPORT/VIEW/VIEW
Processing object type SCHEMA_EXPORT/TABLE/TRIGGER
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type SCHEMA_EXPORT/JOB

虽然数据没有什么影响，但是这个表的索引状态没有创建成功，虽然导入后索引还是有的，但是这个表状态是被锁住了的，虽然重测试环境导线上导入导出是没任何错误，但是原项目导测试环境出现这个问题就直接导上了现在线上项目去了。

处理过程如下：

1, 查看对象是否被锁住(执行sql)

SQL>exec dbms_stats.gather_table_stats('gs','yw_in_order');

报如下错

在行: 1 上开始执行命令时出错 -
exec dbms_stats.gather_table_stats('gs','yw_in_order')
错误报告 -
ORA-20005: object statistics are locked (stattype = ALL)
ORA-06512: 在 "SYS.DBMS_STATS", line 20337
ORA-06512: 在 "SYS.DBMS_STATS", line 20360
ORA-06512: 在 line 1

还可以通过这个语句来查看被锁着的对象：

select table_name from user_tab_statistics where stattype_locked is not null;
-- 或者下面这个
select owner,table_name,index_name,stattype_locked from dba_ind_statistics where owner='gs';

2, 解锁被锁住的对象(解锁sql)

SQL>exec DBMS_STATS.UNLOCK_schema_STATS('gs');
-- 解锁这个用户
-- exec dbms_stats.unlock_table_stats('gs','yw_in_order');
-- 解锁用户下面的某个表，根据需求来

完成后再次执行查看对象是否被锁住

SQL>exec dbms_stats.gather_table_stats('gs','yw_in_order');

还可以通过下面这个sql来确认：

SQL>select t.num_rows, t.blocks, t.empty_blocks from user_tables t where t.table_name = 'yw_in_order';

3, 重新对着个表的索引在线重建

ALTER INDEX PK_YW_IN_ORDER REBUILD ONLINE;
ALTER INDEX YW_IN_ORDER_INDEX2 REBUILD ONLINE;
ALTER INDEX YW_IN_ORDER_INDEX4 REBUILD ONLINE;
ALTER INDEX IDX_YW_IN_ORDER_PAY_DATE REBUILD ONLINE;
ALTER INDEX IDX_YW_IN_ORDER_MERCHANT_NO REBUILD ONLINE;

commit;

完成后再去看系统就完全恢复正常了。