您好

library cache类的等待根因比较多，比如过多的ddl、sql verison count、收集统计信息等。

能不能提供一下完整的问题时段awr和正常时段的awr，以及通过以下方法将问题时段ash元数据导出以便进一步分析

create table setmp as

select *

  from dba_hist_active_sess_history a

 where a.sample_time between

       to_date('20171020 19:00:00', 'yyyymmdd hh24:mi:ss') and

       to_date('20171020 19:30:00', 'yyyymmdd hh24:mi:ss')

;

exp setmp

期间是否执行过DDL或者刷shared_pool的操作，目前看是大量sql失效导致硬解析，shared pool期间5次自动增长。如下因素需要深入调查：

1、连接及事务回滚率很高，是否有大量短连接风暴（或者连续密码错误）？

2、大量共享sql失效，是否刷过shared pool或者DDL、表分析等导致?

3、直方图占用数据字典很高，是否过度收集？

在上述分析基础上，建议：

1、设置shared_pool_size为固定值，建议50GB+，避免动态调整导致的抖动；

2、alter system set parallel_force_local=TRUE

3、alter system set "_optimizer_use_feedback"=FALSE

4、alter system set event='28401 trace name context forever,level 1','10949 trace name context forever,level 1' sid='*' scope=spfile;

1现已确定为应用程序配置的数据库密码错误，导致大量library cache lock

2我把详细分析过程，写在自己博客

https://blog.csdn.net/kiral07/article/details/90178220