1、故障概述
客户打电话反馈Exadata上的某个PDB数据库，昨天晚上业务系统出现hang的现象，最终重启PDB后，业务系统慢慢恢复正常。
本文主要进行故障原因分析以及给出解决方案。
2、故障分析过程
(1).让客户收集了故障时间段的AWR报告和ASH报告。 截取故障时间段的部分AWR内容如下：
对比故障时间段的逻辑读比正常时间段高出10倍左右，这通常是SQL语句不够优化所导致。
出现了library cache lock等异常的等待事件, 后面需要查询这些library cache lock等待事件是哪些SQL引发的。
从SQL语句的情况来看，有两个异常情况：
异常1：对回收站recyclebin$的访问时间占了50%的时间。
异常2：大量的Insert into … select语句长时间都未运行成功。而这些insert语句就是业务反馈业务hang住的SQL语句。正常情况下，这些SQL语句大概几秒就执行完成。
查看逻辑读情况，发现这些异常的业务SQL语句，每一个SQL语句的逻辑读竟然高达4亿多，还未执行完，这是非常离谱的。为什么逻辑读这么高？需要单独分析这些SQL语句的执行计划。
(2). 跟客户沟通得知，这些SQL语句没有使用绑定变量，where条件中的过滤值不一样，其他结构几乎一样。该SQL的作用是：“一张实体表（当作临时表来使用，该SQL执行完成后，接着drop该实体表）与多张业务代码表进行关联查询，将查询出来的结果集插入到结果表中”。选择其中的几个SQL_ID，获取AWRSQRPT报告，截取AWRSQRPT报告如下：
从AWRSQRPT报告来看，该业务SQL语句只有一个执行计划，并且客户确定该SQL语句在正常时间段，也是相同的执行计划。
这就很奇怪，为什么相同的SQL语句，正常时间段只需要几秒就执行完成，而异常时却一个小时都无法执行完成，并且逻辑读能高达4亿多。这个SQL语句中的select部分涉及到的表不是很大，执行计划中也没有出现笛卡尔乘积，按理来说，不应该有这么高的逻辑读才对。
(3).分析dba_hist_active_sess_history，看看这些SQL语句在执行过程中，经历了什么等待。
可以看出，这些业务SQL语句在执行的过程中，经历了大量的library cache lock 和row cache lock等待，除了这个SQL_ID之外，其他异常的业务SQL语句基本上也是这种情况。这也说明了前面AWR报告中的TOP10等待事件中的library cache lock就是这些业务SQL语句造成的。
查询业务SQL语句执行的过程中，访问了哪些数据库对象 和 哪些数据文件。如上所示。主要访问的数据库对象ID为：18、40； 访问的数据文件为：10、114、280。进一步检查确认：
对象ID：18、40的数据库对象为：OBJ$（table）、I_OBJ5（index）
数据ID：10、114、280的数据文件所在表空间为：SYSTEM。
(4).这里可能会有一个疑问，明明访问的是业务SQL，怎么就间接访问到了system表空间的obj$对象呢？ 如果结合前面的SQL异常1（异常1：对回收站recyclebin$的访问时间占了50%的CPU时间）就大概想明白原因了。业务SQL语句是一个insert语句，执行insert语句时，如果发现表空间的使用率较高，就会触发自动清理回收站对象，如果回收站清理过程比较慢，则业务层面的insert语句就只能等待。这也就能够解释为什么业务SQL执行异常期间，该SQL的逻辑读会高达4亿多。从AWR报告中也能进行佐证。
对于回收站的基表recyclebin$，逻辑读高达41亿次。
(5).为了验证这一观点。可以在测试环境模拟这一现象。
执行相同的SQL语句:
回收站清理前：逻辑读：58823，执行时间：00:00:02.25
回收站清理后：逻辑读：2314， 执行时间：00:00:00.32
对比可以看出，当回收站中有大量被删除的对象时，执行insert语句会触发回收站的清理工作，此时会额外产生大量的逻辑读，消耗大量的时间。
(6).可以针对insert into…select语句开启10046跟踪事件，当触发回收站清理时，在底层会对大量的数据库基表进行delete操作，具体信息略。。。
3、建议
（1）.关闭回收站功能。或者修改业务代码，在drop临时性的实体表时，加上purge功能。
（2）.建议修改业务框架，不要执行大量的drop table, create table操作。 频繁的drop table, create table操作会导致数据库的object_id快速增长，当object_id到达一定的阈值，可能会导致数据库无法使用。