一次大量Library Cache lock的处理

上周六一个项目反馈数据查询非常慢,单个数据索引查询平时只需要几秒,进行查询时1个小时还未出结果.

登陆项目数据库服务器,查看em,等待事件中大量的Library Cache lock;

第一次遇到比较荒,网上查等待的原因:

1.包,存储过程等运行时编译时会引起该等待,如运行时整进行ddl操作;

2.一个session在对SQL语句进行硬解析的时候.share pool的问题也可能出现该问题;

开始第一次遇到不太清楚原因.直接请教了新入职 的同事,看有没有较快的处理.

然后自己进行研究.

思路清晰是关键因素:

1.确认引起该等待的语句或操作

 em或者查询v$lock结合v$sql_text视图可以很清晰的看出是数据库的入库软件执行的sqlldr引起的

停止入库软件的运行也可以看出等待基本消失,确认问题的所在为sqlplr入库语句

2.针对入库语句做检查,停止入库,手动执行一条语句 报错:ora-01658,ORA-14400.

入库分区无法分配初始的分段,asm自动管理不存在最大单个文件16T的问题,检查asm磁盘组

果然磁盘组基本被塞满 只剩余1G左右.系统在表的分区第一次存储数据时分配空间 应当也属于ddl操作.产生了该等待

锁死各表,造成查询也很慢,几个loader进行入库每个表都被锁定,造成查询非常慢的问题.

问题定位,剩下的就比较好解决了.

思路一定要清晰,首先遇到问题一定不能怕.搞清楚问题是什么,可能引起问题的原因,进一步对问题的各个可能起因排查确定原因.

确定引起问题的原因后针对该错误进行处理就简单了