1、从数据库日志上看，数据库无ORA-类报错或告警，因可以排除因数据库报错导致的性能缓慢问题

2、抽取相关时段AWR分析如下：

http://s13/mw690/001N2SGigy6WzPu7MHq4c&690file sync" TITLE="AWR实战分析----log file sync" />

从AWR上看，数据库负载相对较高，数据库响应缓慢

http://s7/bmiddle/001N2SGigy6WzPxwV1Ab6&690file sync" />

从数据库关键命中率指标来看，关键指标命中率都在99%左右，数据库配置不存在问题，程序不存在硬解析问题

http://s15/bmiddle/001N2SGigy6WzPzXNeK0e&690file sync" />

从AWR TOP 5等待事件来看，数据库的主要问题在log file sync等待事件上，因数据库是先写日志后写数据文件，因log file sync是提交等待，会导致整个系统运行缓慢，从Avg wait(ms)指标来看，数据库redo file sync等待时间极度严重,此时数据库该值为136ms，并且数据库并没有大量的IO操作，直接反馈操作系统IO存在严重问题，需要进一步确认操作系统IO是否异常。

3、通过top和iostat等命令查看操作系统性能，发现cpu使用率较低，但IO极度繁忙

        http://s8/bmiddle/001N2SGigy6WzPC4B5d77&690file sync" />  

ASM磁盘组BOSSDATA对应磁盘IO指标b%一直是100%，存在严重的IO瓶颈，因数据库无大量IO操作，可以确定是存储IO有问题

4、去机房现场观察存储情况，发现生产库pillar存储控制器告警，外观信息如下：

        http://s9/bmiddle/001N2SGigy6WzPE4VoA98&690file sync" />

5、从pillar日志上看，该告警在10月15日就已经发生，收集日志，联系pillar原厂售后，确定是pillar内部报错，需要pillar工程师用内部工具进行错误清理，10月22号晚pillar工程师到现场，清理错误后无法解决告警问题，再次联系pillar原厂工程师，确认是pillar控制器主板问题，并确认是因pillar主板问题导致cache关闭，导致IO性能严重下降，如下是pillar原厂工程师给的回复

        http://s12/bmiddle/001N2SGigy6WzPFI04j9b&690file sync" />

6、10月25日23：30分，pillar控制器主板更换完成，经过26、27、28三天的观察，数据库IO恢复，数据库负载下降明显，如下是pillar主板列换后数据库负载及等待事件信息

       http://s8/bmiddle/001N2SGigy6WzPHnK0T47&690file sync" />

   经过对比pillar主板更换前后两个相同时间段AWR报告，结果显示，更换主板后数据库负载下降了62.7%

      http://s13/bmiddle/001N2SGigy6WzPJJsmMbc&690file sync" />

对比等待事件及平均等待时间来看，更换主板后，Avg Time(ms)指示有由来的峰值136.55ms下降至1.00ms

7、更换pillar主板后，经观察两的天的业务情况，已完全恢复，无指令堆积和业务模块缓慢问题发生,问题得到解决。