继昨天对系统进行了初步的调优后，效果还是比较显著，DB time从500%降到了100%以内，当然过程还是充满艰辛，期间也是各种工具和分析语句斟酌了再三。
今天也没有收到任何报警，所以感觉问题似乎已经彻底解决了。在下午的时候查看了一下，发现在凌晨的时候有一个大的抖动，然后DB time基本持续在300%~400%左右。比预期的要高很多。
这个时候的第一感觉就是是不是调优出问题了，性能还是不够稳定啊，带着疑问查看了今天的数据归档情况，发现在这段时间内的数据归档频率还是很高的。在短短几个小时之内就会切换十多次。这个频率还是很高的。是不是因为调优导致的这种隐患呢。
带着疑问查看了近一个月以来的数据归档情况，发现还是带有一定的规律性的，按照这个规律今天是刚好碰到高峰期了。所以可以排除调优带来的隐患，而且我的改动也是针对几个具体的sql还没有做大动作。
那么调优之后系统的DB time提高了，那么逻辑读之类的指标是不是也有一定的浮动呢，答案是有，但是浮动很小，和原来相比简直可以忽略不计。可以看到右边的部分是调优之后的逻辑读变化，浮动还是很小的。
那么DB time突然提高的原因是什么呢，结果发现在数据库中有另外几个sql语句在做大批量的update,看来是一个例行维护的任务，因为涉及的表都很大，数据量都在亿级以上，都是些批量操作。
而且还有一个sql会基于db link从另外一个库去查取大量的数据，这个部分从设计上来说，确实依赖性耦合性较高，因为批量任务，不要求实时，所以可以考虑通过物化视图等来代替，通过增量刷新来得到过滤后的数据。这个部分因为改动部分较大，可能需要后期和开发商量一下改动方案。
下面的图形是通过zabbix得到的网卡的繁忙程度。可以看到在问题发生的时间段内还是有大量的数据通信。
但是经过分析还是有几条语句可以做在线调优的，还是结合sqlmonitor和sqlprofile来做，效率还是不错的。可以看到在短时间内DB time就会降下去。
这个案例对自己也是启示，这个调优还是需要做一个宏观的角度来看待，有的问题可能随着业务需求有一定的周期性，可能一周，也可能一月，需要结合详细的数据做一个全面的规划。同时也说明DB time也还是能够反映出一些潜在的问题的，如果在业务需求范围之内，DB time的提高本身就不是问题，因为DB time就算在很稳定的情况下，也不一定就没问题，DB time是一个参考，分析要全面，诊断要及时。
今天也没有收到任何报警，所以感觉问题似乎已经彻底解决了。在下午的时候查看了一下，发现在凌晨的时候有一个大的抖动，然后DB time基本持续在300%~400%左右。比预期的要高很多。
这个时候的第一感觉就是是不是调优出问题了，性能还是不够稳定啊，带着疑问查看了今天的数据归档情况，发现在这段时间内的数据归档频率还是很高的。在短短几个小时之内就会切换十多次。这个频率还是很高的。是不是因为调优导致的这种隐患呢。
带着疑问查看了近一个月以来的数据归档情况，发现还是带有一定的规律性的，按照这个规律今天是刚好碰到高峰期了。所以可以排除调优带来的隐患，而且我的改动也是针对几个具体的sql还没有做大动作。
那么调优之后系统的DB time提高了，那么逻辑读之类的指标是不是也有一定的浮动呢，答案是有，但是浮动很小，和原来相比简直可以忽略不计。可以看到右边的部分是调优之后的逻辑读变化，浮动还是很小的。
那么DB time突然提高的原因是什么呢，结果发现在数据库中有另外几个sql语句在做大批量的update,看来是一个例行维护的任务，因为涉及的表都很大，数据量都在亿级以上，都是些批量操作。
而且还有一个sql会基于db link从另外一个库去查取大量的数据，这个部分从设计上来说，确实依赖性耦合性较高，因为批量任务，不要求实时，所以可以考虑通过物化视图等来代替，通过增量刷新来得到过滤后的数据。这个部分因为改动部分较大，可能需要后期和开发商量一下改动方案。
下面的图形是通过zabbix得到的网卡的繁忙程度。可以看到在问题发生的时间段内还是有大量的数据通信。
但是经过分析还是有几条语句可以做在线调优的，还是结合sqlmonitor和sqlprofile来做，效率还是不错的。可以看到在短时间内DB time就会降下去。
这个案例对自己也是启示，这个调优还是需要做一个宏观的角度来看待，有的问题可能随着业务需求有一定的周期性，可能一周，也可能一月，需要结合详细的数据做一个全面的规划。同时也说明DB time也还是能够反映出一些潜在的问题的，如果在业务需求范围之内，DB time的提高本身就不是问题，因为DB time就算在很稳定的情况下，也不一定就没问题，DB time是一个参考，分析要全面，诊断要及时。
