1.7.7 降低等待时间就可以提高业务系统性能

Oracle Wait Interface（OWI）方法是如此之有效，因而有广大的用户，尤其是其类似于故障排除的思维方式，更是在DBA中成为金科玉律。OWI对于大部分DBA来说是一个福音，使其不需要去关心真正的性能优化科学方法论，就可以延用故障排除的思路来完成性能优化，不断积累的性能优化场景可以在OWI方法中获得价值的最大化。

因为response time=service time+queue time，所以OWI方法的拥护者认为只要降低queue time就可以提高业务系统性能。这个观点在吞吐量压力达到一定程度的业务系统中具有相当的正确性，不过并不是真理。采用OWI方法的用户必须要注意方法适用的场景，不要越界。OWI方法在面临下面的场景时将不再适用：

❑ 在低吞吐量的系统中，因为在此系统中很难观察到所谓的等待。

❑ 当Oracle等待时间目前无法评估CPU Queue时间，而是简单地标记为CPU时间时。

❑ 当Oracle等待时间目前无法评估无效的CPU操作，比如latch spin和mutex spin操作，这些操作都被评估为CPU时间而不是等待时间时。

下面来看一个简单的queue time和latch/mutex事件示例。

某业务系统性能响应缓慢，表现为大量cache buffer chain latch wait。有相当多的性能优化者把增加spin count作为优化的首选措施。但spin操作并非是有效的操作，它仅仅是将标记为wait的时间转移到了CPU的消耗中，变成了service time。这个参数增加之后，很多性能优化者会发现latch等待时间减少了甚至不见了，但是业务系统性能并没有改善。

再次看一下公式：response time=service time+queue time。增加spin count的结果就是：queue time大幅度减少，service time增加（甚至是不成比例的增加）。当然，相当多的性能优化者发现增加这个参数确实能改善性能，甚至会把这种改善方法作为一种灵丹妙药，从而用来优化让人讨厌的latch等待时间。不幸的是，在很多场景下增加这个参数的效果并不好，甚至可能会使性能问题进一步恶化。spin count的唯一作用在于压榨CPU的使用，在CPU有一定空闲的前提下，spin count的增加常会带来好处。但实际情况是，若真正有大面积的latch等待事件，那么CPU资源往往是同步紧张的，这种情况下增加spin count通常会带来反作用，也许正确的做法可能是降低spin count，释放CPU资源在latch上的占用。