从等待事件上看，应该是IO有问题，检查下存储和多路径链路。如果有nmon监控数据，一并分析下这个时间点的IO和网络情况。

你可以在awr报告里，查看下Background Wait Events部分中的log file sync和log file parallel write的等待时间，一般来说，log file sync 等待时间小于20ms算正常，log file parallel write 等待时间小于20ms算正常。

如果log file sync和log file parallel wirte 等待时间很接近，说明就是IO问题，因为大部分时间都花在了log写入到磁盘上。
如果log file sync等待时间如果明显大于log file parallel write，则可能有几方面原因：
（1）CPU资源紧张；（2）同时提交的进程比较多；（3）遭遇Bug.

上传一下sql_id为dfygkqqf3b9xv,328uutabkzcc5语句的执行计划
以及1nnx0wbys2v4w的语句，该语句逻辑读太高

SQL问题确实很多，IO也有问题，但是应该这样子也不是一天两天了，之前没出问题。

所以我感觉出问题时间段问题最大是下面这个pl/sql，看看这个pl/sql跑了哪些东西，下这个下面那个insert是不是也是他的子SQL，你一个小时的时间40个逻辑CPU，总CPU时间也不过就是40cpus60min60s=144000s，这一个没跑完的pl/sql就占了总计算能力的24%左右。