玉面飞龙的BLOG

数据库优化是DBA的主要工作之一，包括优化数据库逻辑和物理设计，优化应用程序设计和编码，优化网络，SQL调优等等。在优化过程中，你是否遇见如下问题:

优化应用中的某些SQL后，应用程序并没有性能提高。而公司为此项工作支付了你工资。
又或者通过修改初始化参数使某个模块得到性能提高，但应用程序性能反而更慢，消耗更多的系统资源和时间。
又或者优化了某个模块后，该应用程序得到了性能改进，而其他的应用程序受到影响导致性能下降？
又或者投入资金购买供应商promise的更popular的硬件，而应用程序依旧如此，客户并不领情。
大部分情况可能是，你认为数据库运行良好，而客户却在抱怨他们缓慢的application.于是你去抱怨给developer,network admin,storage admin etc.大家开了半天会也找不到问题的所在。
又或者你很好学而且工作努力，优化了某些SQL后，降低了数据库50%的buffer gets，然后你报告给你的Manager“通过XXX,我们的数据库快了50%”;可是你不够幸运，客户并没有感觉到他们的应用有什么变化。

那我们如何去做去优化，才能实现“Faster system”？

首先，“Faster system”从来没有存在过，存在的只有faster (application) task , scalable system.

faster (application) task 是针对某一个end user来说的。比方说，用户在访问taobao.com登陆物品的时候，他所感知的就是submit以后，多长时间后返回确认信息；用户的这一个操作，涉及到网络传输，应用服务器business逻辑处理，数据库记录的插入等很多模块；每个模块都是一个child task;只有每个child task都得到高效的处理，用户才能获得faster task的体验。

让用户感觉到faster task，我们必须有针对性进行调整，找到task的主要瓶颈，然后step by sub task地进行优化。最终实现整个User task的faster. 作为DBA,优化数据库，我们所追求的应该是以最小的成本实现最佳的系统吞吐量，最佳的应用response time和客户的满意。但优化数据库只能优化到数据库这个sub task，如果系统主要瓶颈不在数据库，又或者我们怎么去判断/怎么去找到task不能faster的瓶颈到底在哪里？

这就需要这个User Task有类似Oracle的“Wait Events”的task profile了。Task profile说白了就是log,记录User Task在各个sub task上的资源&时间分配：sub task作了什么（event name），执行了多少次(executions)，多长时间（event time）etc. 这就需要User task在设计的时候，就有明确的蓝图:为sub task添加必要的Instrumentation。这就是Profile.

instrumentation 对DBA来说，当然很好的就是，一眼就能看到User Task的流程，很容易找到它的瓶颈;出问题的时候不但有alert.log，还有application log。

instrumentation 对QA来说，当然很好的就是，测试的时候能够更好地了解User Task，更符合实际的测试用例。

instrumentation 对Developer来说，当然是添加一点麻烦，但同样方便了debug.

对Oracle PL/SQL code的instrumentation ，我们可以用dbms_output,debug.f,Log4plsql等。

有了类似Oracle Wait Event的User Profile，我们就可以像优化Oracle一样去优化User Task，我们就可以给manager报告，经过优化XXX后，用户的task提高了XX时间($$).

最后再简单说一下Scalable system，它和faster (application) task有区别。faster (application) task是针对某个用户来说的；而Scalable system是真对使用这个系统的所有User (application) task来说的。有可能的情况是，为了faster某个用户的(application) task，分配更多的资源给这个用户，从而降低了其他用户的可用资源，影响到其他用户的(application) task性能，导致系统不能Scalable. 当然faster (application) task是Scalable system的前提。我将会在以后介绍Scalable system。

可参考hotsos_profile.pdf。