健康系统的优化应该是问题导向的

健康系统的优化是
比较困难的
，
就像
想让一个强壮的人更强壮肯定比
把让一个瘦小枯干的人长点肌肉要难得多。正是如此，为了节约不必要的浪费，对于健康的系统的优化，还是应该坚持问题导向。首先明确要解决的问题，然后再去做优化分析，为了优化而优化，缺乏明确的目标导向，会造成运维资源的巨大浪费。我们来看一个例子。

对于这样一个系统，如果我不明确一个优化目标，我们该怎么入手去做优化呢？似乎有点头痛，这个系统负载很高，每秒23M的REDO量，5300+的事务数，逻辑读似乎不算高，300多万每秒。看上去，OS负载也不会太高。

确实是的，这个96核的服务器，平均Load 30左右，CPU负载并不高。如果我们漫无目的的去做优化，该向哪个方向去做呢？建议用户减少提交的数量采用批量提交？这可能是一个正确而无用的建议。去优化IO？IO的性能已经够好了，如下图，大部分的数据库IO是在1毫秒以内完成的，大于8毫秒的数据库IO几乎没有。

为什么我们会遇到这样的困境呢？就是因为我们没有问题导向。优化是有成本的，对于相对健康的系统，漫无目的的优化会造成资源浪费。如果我告诉你，用户希望进一步提升高峰期的并发事务量，想从5000+/秒提高到6000+/秒，那么你是不是就没那么迷茫了呢？

如果有了这个目标，那么事情就简单多了，首先我们可以看看哪些因素导致了并发量上不去的问题。我们首先去看LOAD PROFILE中每个事务的情况

降低红框中的这些等待，肯定能降低每个事务的开销，从而提高每个事务的响应时间，从某些方面提高总体并发的能力。不过我们看得出，哪怕把这些全优化了，也还不够15%-20%提升这个目标。因此除此之外，我们还要再去分析如何提高并发处理能力的问题。比如闩锁的等待、共享池的等待、锁等待、BBW、GES/GCS等待等。同时提高一些关键缓冲池的命中率也有助于提高并发处理能力。

从上面的数据来看，LIBRARY HIT，LATCH HIT，SOFT PARSE的比例提升应该也是有效的。后续可以对这些做针对性的优化。当然SQL优化也是行之有效的，对有问题的SQL也可以做一定的优化工作。虽然让人缺乏一击必中的绝招，整个优化工作仍然需要十分细致的工作。但是总的来说，似乎优化还是有方向的，完成20%的目标虽然有一定的困难，需要较大的投入，但是完成10%以上还是很可能的。