最近几天对客户的一个核心数据库进行了优化，将资源消耗较高的SQL优化完成之后，物理读和逻辑读总量得到了降低。客户反馈优化后性能有提升，但仍然在某些工作日的业务高峰时段存在性能问题。 我们通过将性能不佳的业务高峰时段（即问题时段）与性能正常的业务
最近几天对客户的一个核心数据库进行了优化，将资源消耗较高的SQL优化完成之后，物理读和逻辑读总量得到了降低。客户反馈优化后性能有提升，但仍然在某些工作日的业务高峰时段存在性能问题。我们通过将性能不佳的业务高峰时段（即问题时段）与性能正常的业务高峰时段（即基线时段）的性能数据进行了对比，发现了一些问题：
基线时段为2014-1-15日上午8:00-上午9:00，此时段TPS（每秒事务量）为：46T/s，该时段的总DB Time为：626.2 (mins)
问题时段为2014-1-20日上午8:00-上午9:00，此时段TPS为：47T/s（仅比基线时段多1T/s，可认为两者业务量相当），该时段的总DB Time为2361.4 (mins)
同样均为1小时的取样时间段，问题段的总DB Time是基线的近4倍，而通过对比两者的性能视图，发现问题时段的单次IO延迟非常高，如下：
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
DB CPU 2,082 55.42
db file sequential read 62,140 774 12 20.61 User I/O
direct path read 177,440 575 3 15.31 User I/O
log file sync 17,486 145 8 3.86 Commit
gc cr block 2-way 98,519 30 0 0.80 Cluster
基线时段单次序列读延时为12ms,单次直接读延时为3ms，单次redolog写延时为8ms，
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
direct path read 180,200 4,643 26 32.77 User I/O
db file sequential read 55,483 2,286 41 16.13 User I/O
DB CPU 1,917 13.53
gc buffer busy acquire 5,513 1,474 267 10.40 Cluster
log file sync 17,541 1,298 74 9.16 Commit
而问题时段单次序列读延时为41ms,单次直接读延时为26ms，单次redolog写延时为74ms
（Oracle文档中建议的单次IO正常延时应为0-20ms，否则需升级硬件），
即相比基线时段，在业务量不变的情况下，问题时段的IO效率下降非常明显，怀疑是存储层面的同一个RAID组中有其他业务系统有可能恰好在问题时段有大量的IO操作，
导致我们正在优化的系统的IO延迟较大。跟客户的存储人员确认发现确实如此，存储人员并没有结合数据库对存储做出合理规划，仅仅从容量管理上对自己工作的方便性出发，划分并分配LUN。由此导致性能问题，我想这种问题在很多企业都是存在的，跨部门之间的沟通不畅导致没有从整体上的规划出现，最终出现问题由DB买单。
因此建议客户进行存储改善：
1.将这种关键系统在存储层面与其他系统隔离，避免互相影响IO；
2.有预算的情况下升级存储。
声明：本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系admin@php.cn核实处理。
上一篇：Hive.分组排序和TOP
下一篇：分区表的基本操作
