这个是老生产谈的事情，统计信息不准确导致sql执行异常，此次记录的主要是表的统计信息被锁住导致无法正常收集统计信息导致sql执行异常：
收集表的统计信息：
SQL> exec DBMS_STATS.GATHER_TABLE_STATS(OWNNAME => 'crmdb', TABNAME => 'T_ORDER_DELIVERY', CASCADE => TRUE);
BEGIN DBMS_STATS.GATHER_TABLE_STATS(OWNNAME => 'crmdb', TABNAME => 'T_ORDER_DELIVERY', CASCADE => TRUE); END;
在汝城等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供网站设计制作、成都网站制作 网站设计制作定制网站设计,公司网站建设,企业网站建设,成都品牌网站建设,成都全网营销推广,成都外贸网站建设公司,汝城网站建设费用合理。
*
ERROR at line 1:
ORA-20005: object statistics are locked (stattype = ALL)
ORA-06512: at "SYS.DBMS_STATS", line 24281
ORA-06512: at "SYS.DBMS_STATS", line 24332
ORA-06512: at line 1
确认出错信息：
SQL> select table_name,d.stattype_locked,D.LAST_ANALYZED,d.NUM_ROWS from user_tab_statistics d where table_name in ('T_ORDER_DELIVERY');
TABLE_NAME STATTYPE_LOCKED LAST_ANALYZED NUM_ROWS
T_ORDER_DELIVERY ALL 27-APR-2017 22:00:12 0
SQL> select count(*) from T_ORDER_DELIVERY;
1029883
说明该表的统计信息不准确，且自2017年以来都没有收集过；
解决方案：
1)解锁单个表对象：
查出schema下所有被锁定的表：
select table_name from user_tab_statistics where stattype_locked is not null;
查询单个表：
SELECT TABLE_NAME,D.STATTYPE_LOCKED,D.LAST_ANALYZED,D.NUM_ROWS FROM USER_TAB_STATISTICS D WHERE TABLE_NAME IN ('T_ORDER_DELIVERY');
然后解锁对象:
exec dbms_stats.unlock_table_stats('username','table_name');
SQL> exec dbms_stats.unlock_table_stats('crmdb','T_ORDER_DELIVERY');
PL/SQL procedure successfully completed.
再次收集统计信息：
SQL> exec DBMS_STATS.GATHER_TABLE_STATS(OWNNAME => 'crmdb', TABNAME => 'T_ORDER_DELIVERY', CASCADE => TRUE);
PL/SQL procedure successfully completed.
SQL> select table_name,d.stattype_locked,D.LAST_ANALYZED,d.NUM_ROWS from user_tab_statistics d where table_name in ('T_ORDER_DELIVERY');
TABLE_NAME STATTYPE_LOCKED LAST_ANALYZED NUM_ROWS
T_DM_ORDER_DELIVERY 22-JAN-2019 11:07:05 1029884
解锁整个schema：
DBMS_STATS.UNLOCK_SCHEMA_STATS('username');
那么为什么这些表的统计信息会被锁定呢？
有可能是为了稳定执行计划，或者是impdp只导入metadata_only导致，或者是人为手动锁定等。正常在Oracle10g及以上，Oracle默认会根据需要自动收集统计信息，如果想要想手动锁住统计信息，
可以使用DBMS_STATS.LOCK_SCHEMA_STATS和DBMS_STATS.LOCK_TABLE_STATS包进行锁定。