背景：
有一项目负责人向我反馈，在今天凌晨，系统有一个作业运行时间慢了30分钟，需要我诊断是那里出了问题。
问题:
是什么原因令这系统作业运行时间比平常慢了30分钟？
核心思想：
看到的并不就是事实的真相及其全部，或许只有现象，或许只是线索。
为追求真相及事实的全部，你需要耐心，有条理地进行科学的分析。
或全面、或主次！
方法论：
问题分析三板斧：
- 具体化用户的感知:发生时间、发生系统、事件描述（不能用、能用但慢，慢多少）
1）数据收集：AWR报告、OS资源使用情况、数据库和OS日志、APP日志
- 数据分析：对比分析、标志分析、层进式推进（递归式因果关系逻辑思维）。
处理经过:
1）具体化用户的感知
1.1 发生时间：凌晨1:30 ——04：00
1.2 发生系统：X运算系统
1.3 事件描述：运算时间比上一个周期慢了30分钟，数据量没有明显的变化，程序代码最的
没有变更过。
2) 数据收集：
2.1 AWR报告：生成01:00 至 04:00的报告。
2.2 OSWATCH: 生成01:00 至 04:00的报告
2.3 收集DB、OS、APP日志
3）数据分析：
3.1 快速处理的常用方法——标志分析：
a) 查看AWR的
DBTIME,DBCPU,load profile,TOP EVENT,TOP SQL,
发现重要标志top event：
Event Waits Time(s) Avg wait (ms) % DB time Wait Class DB CPU
28,103 47.79 log file sync 787 3,187 4049 5.42 Commit
log buffer space 108 3,026 28022 5.15 Configuration
log file switch completion 816 904 1108 1.54 Configuration
log file switch (checkpoint incomplete) 52 767 14745 1.30 Configuration
b) 平均等待时间，最长是28秒，其中log file sync更是4秒，非常重要的可疑之处，
目前我们的数据库存储采用全闪存后，正常时的avg wait(ms)在1ms内，甚至是捕捉不到等待时间。
<<<<<<<<对比分析
c) 思考有那些情况会出现这些等待事件呢？还有平均等待时间这么长。
c-1:常规思维：
redo logfile size不够大>>>进一步确认，发现一小时log switch 70次>>>logfile parallel write avg等待1ms
log buffer不够大>>>每秒产生redo log size 22m，当前的log buffer远少于
22m*600 ,
（1）频繁 commit>>>>检查代码,
（2 ） IO变慢>>>查看awr io stat选项，其中在tablesace io stat一栏中发现system AVG BUFFER WAIT（ms) 为200>>是什么原因导致system出现严重等待，但其它没有>>>>有大量的IO写入到SYSTEM，但是数据显示只有900多个写入请求，明显不成立>>>>>system与其它表空间在同一样磁盘组上，为什么只有system空间的等待这么明显>>>>说明显不是由于其它表空间的读写引发IO竞争的。那么是不是其它节点呢？>>>>查看其它节点同样时间，也看到累似的事件，但是通过生成对awrddrpt对比后，发现没有额外的SQL出现>>>那么到底是什么原因呢？>>>>其它数据辅助分析。
d)分析数据库日志，没有发现明显的ORA错误。分析OS日志(当时由于没有权限查看os日志，没有分析到位)，其实在这里可能看到多路径错误（或者看要存储多路径软件日志）,后来在存储管理员协助下，真的发现有一个光纤交换机出现损坏，当数据库向发出IO请求时，被系统分发到该损坏的交换机时，IO响应就会变慢，因为该交换机端口是通的，就是不能把数据转发到存储上。当它接收到OS发送的数据时，在规定时间内转发不成功，就会采用另一台转发，所以数据库的数据是完整的，但是整体响应时间变慢了。
至此为止，真相已经浮出水面了。。。其实在之真相出现前。。。。。我是走了好多弯路的。
解决方案：
1.存储光纤交换机是有两台采用轮询的方式组成高可用架构的，目前只是损坏一台，另一台正常，于是把损坏的交换机端口关闭，OS自动把数据库的IO请求转发到正常的交换机上，再到存储。
测试验证通过，在生产上实施。
- 通 知厂家更换硬件。
补充：本次事件中本人没有尚有欠缺的地方，没有进行OS与存储路径检查， 这是一大疏忽。希望借此事件引以为戒。