4.生产数据库 db file sequential read 过高造成的性能问题

⦁ 故障描述
数据库近期(5月30日)每天9点至10点之间会出现性能问题，业务层面反映性能缓慢，从系统上看，此时I/O大幅增加，耗尽数据库I/O资源使数据库处于HANG住状态。

下图中蓝色部分为I/O活动百分比，此图为30日的数据

⦁ 故障原因
抓取5月30日9点至10点间数据库AWR报告分析：
在负载简要中可以看出此时数据库有比较高的逻辑读并且物理读也较高

在TOP5等待事件中，可以看到数据库最大的等待在db file sequential read 这个等待事件上占据50%的时间，此等待事件一般由索引的随机读取造成，并且还伴有叫高的read by other session等待事件，此等待事件是由于某个会话正在读取磁盘中的数据块到内存中时另一个会话也要读取此数据块造成的。由此猜测可能由于不合适的索引访问造成大量的随机读，在读取这些数据块的过程中产生了read by other session的等待。

可以看到CSS_INVADJUST_D和CSS_WORK_ORDER逻辑读都比较高，并且CSS_WORK_ORDER表还有较高的物理读

抓取9点至10点ASH报告分析：
也可看到db file sequential read等待事件的占比很高，从等待事件参数中可以查到占比最高的数据块（11号文件514294块）属于表CSS_WORK_ORDER

db file sequential read等待事件较主要由不合适的索引访问造成，观察上面几个SQL的执行计划，看是否存在嵌套循环连接中大表做为驱动表，使得被驱动表的访问剧增造成db file sequential read过高
上图SQL中，排名靠前的两个SQL是类似的，排名靠后的三个SQL也是类似的，所以各抓取了两个SQL的执行计划进行分析

SQL_ID: 5xp85mqq8s7v7执行计划：

SQL_ID:c9r9hc9ujp20y 执行计划：

两个执行计划中都没有发现大表做为驱动表的现象，但是都共同有范围扫描集簇因子过高的索引的问题，第一个SQL中索引CSS_INVADJUST_D_PK2为表CSS_INVADJUST_D字段CID_ITEM、CID_ORG的组合索引，此索引的集簇影子已经非常高，说明CID_ITEM的值在表中数据块的存放非常分散，使得数据库通过索引再读出表中其它数据时要读取更多的数据块。第二个SQL中索引CWO_HUIFANG也存在这样的问题。由于这两个SQL中，访问此索引的表都是嵌套循环的被驱动表，这更加剧了数据块的随机读取，特别第一个SQL还是由几个UNION ALL组成，所以前面可以看到表CSS_INVADJUST_D和CSS_WORK_ORDER的逻辑读较高。

⦁ 解决方法
找出db file sequential read 等待事件高的SQL，并找出此SQL中以索引范围扫描方式访问的集簇因子过高的索引，对这些索引的表的数据进行重新整合降低这些索引的集簇因子。
调整步骤：
⦁ 对表Css_Invadjust_d按照字段CID_ITEM和CID_ORG进行排序后再重新导入，建立CID_ITEM和CID_ORG字段的组合索引。
⦁ 对表CSS_WORK_ORDER按照字段CC_ID和CSS_ID进行排序后再重新导入，原索引CWO_HUIFANG由四个字段组成（CC_ID,CSS_ID,CSP_ID,CWO_SETTLEID），现拆分为两个组合索引CC_ID、CSS_ID为一个，CSP_ID、CWO_SETTLEID为另一个组合索引。
⦁ 对表CSS_ITEM_LOT按照字段CIL_ITEM和CIL_CODE 进行排序后再重新导入，建立CIL_ITEM和CIL_CODE字段的组合索引。
以上排序的先后顺序和组合索引字段的先后顺序都按照描述时字段出现的先后顺序进行。

⦁ 优化后前后性能对比

可以看到I/O活动已经大幅降低