• 白鳝（徐戟），国内最早的互联网用户之一，QQ:62565

• 子衿技术团队 首席架构师

• 从事IT行业20余年，曾供职于DEC、赛格、长天、联想等

• 从事过10多年软件开发，主持开发了国内第一套电信级联机计费系统，国内第一套三检合一的检验检疫综合管理系统、IPP银行大前置系统等大型系统

• 写过三本书《ORACLE 优化日记》《Oracle RAC日记》《DBA的思想天空》

• 信息无障碍研究会专职顾问

性能优化理论是不断发展的，很多人把优化看作是一个十分高大上的东西，只有高手才能进行优化工作。实际上优化是DBA日常工作的一部分。今天给大家分享一些这几年老白在系统优化方面的经验。我们从一个案例出发，这个案例是子衿技术团队在2013年实施的一个实际的案例。参与这个项目的技术人员都是刚刚进入优化领域不到2年的新手，而这个案例最终结果是做出了大师级的调整。通过这个案例我们再继续探讨，优化是什么？优化该怎么做？

这套系统用户反映经常出问题，特别是在一些关键的时候总是掉链子。被最终用户和领导多次批评。

不过我们从系统的监控数据看，RAC的两个节点的CPU使用率还算正常，偶尔有达到100%的情况。

从AWR报告上看，我们采集的业务高峰期的AWR报告上看到的负载也不是很大。每秒的执行数量才1878。

各个命中率的指标也不算差。软解析虽然比例低了点，不过每秒的解析数量也不过32，解析占用CPU也就4.5%左右。

从TOP EVENT上看，也没有明显有问题的地方，单块读的平均响应时间是9毫秒，虽然不太好，不过也可以接受。

从AWR上看，似乎并没有特别明显得问题。而且项目组进场时看到的系统状态，也没有出现客户所说的大量模块无法使用的情况，有可能那是一种非常态化的故障，只是在某些业务高峰才出现的。根据用户的描述，似乎也不是周期性出现的，并不是在每个月某个时段固定出现问题，只是隔三差五的偶发性出现问题。对于项目实施时间有限，无法长期值守的优化项目组来说，如何尽快定位问题，走出困境呢？

其实对于性能优化而言，我们以前一直存在一个误区，把优化看作是一个纯粹技术的工作。曾经不止一个企业的IT主管和我讨论过优化，他们都说你们做完优化后，从报告上看，确实效果很好，很多SQL都得到了优化，系统的性能指标也有了很大的提升。但是问起业务部门，他们都觉得没啥感觉，这是什么道理呢？

其实这个问题很好回答，我们的优化都是技术驱动的，不是业务驱动的。曾经和一个DBA讨论过一个优化案例，他告诉我，通过优化，把某个每小时执行几千次的SQL的执行时间从100毫秒优化到30毫秒，效果十分明显。这种优化工作，从整体上可以大幅度减少资源开销，在10年前，资源及其匮乏的案例中，可以起到十分重要的作用，通过这个优化，可能客户可以明显得感受到优化的效果。而如果这个优化是在一个系统资源十分充足的环境中，那么30毫秒到100毫秒，对于一个业务人员来说，他是感受不到优化的效果的。

作为日常运维工作，对这样的SQL进行一定的优化，对于系统的长期稳定运行是有相当大的作用的，不过对于一个优化项目，如果我们只是局限在这些SQL上面，我们的工作不一定能够得到最终用户的认可。

而真正要想达到用户所要求的效果，是离不开最终用户调研的。最终用户调研分为IT部门调研、运维人员调研和业务人员调研三个方面。

优化小组马不停蹄，立即展开深入调研工作，在客户那边，获得了大量的一手资料。在用户的直接操作下，我们也发现了很多存在问题的功能模块。有些功能模块由于经常出不来结果，甚至用户平时都已经不用了，改用其他的方式来实现类似的功能。

上面是一些功能点的执行情况，可以看出在系统不是十分高峰的情况下，大量的功能点是执行报错，无法正常工作的。

除了业务调研，我们还需要对IT部门进行调研，了解系统的总体拓扑。由于运维人员对整个系统的IT架构了解的也不是十分清晰，而通过系统一点点去分析又相当耗时，于是在优化小组的一再要求下，IT部门终于找到了一张系统的逻辑架构图。从这张图中，优化组找到了一些系统存在问题的蛛丝马迹。

从系统拓扑中我们也发现了大量的问题。这个系统使用了两个存储，为了确保数据不丢失，当时集成商为客户设计了双存储镜像的方式。由于系统建设比较早，做存储镜像的方式还是比较原始的LVM。

同时这个存储上运行了4个数据库系统，而存储的档次也属于中低端存储，磁盘的数量也有限，所以总体性能指标也不高。

了解了这些情况，优化组把目光盯到了存储的性能上面。从AWR报告上看到的IO性能指标虽然在可接受范围内，不过总体还是偏低的。这种情况下，搞清楚这个系统的逻辑拓扑结构十分重要的。

通过对业务高峰期的OS进行存储性能采样，发现部分磁盘的平均响应时间是偏长的，甚至高于100ms。

通过v$asm_disk视图我们发现这些有问题的磁盘都属于联机库和查询库。而这两个库确实是性能都存在问题的。

从对比看，两个存储的性能指标相差了7倍，从我们的常识来理解，如果两个存储要做LVM，那么存储的性能必须相近，否则IO的性能会接近较差的哪个存储。

为什么会出现这种情况呢？因为这两个存储的档次是十分接近的，甚至CX3-40的配置和性能指标高于HP EVA3000存储。我们需要进一步对存储的详细配置和磁盘组的配置进行分析。

EMC CX3-40配置2个磁盘柜，分别有13块和15块300GB 10K磁盘，划分3个RAID GROUP,R1=0-4，R2=5-11,R4=0-13;不过我们所分析的TC/QC数据库只使用了其中一个磁盘组。实际上使用的磁盘只有5块，明显存在性能瓶颈。

HP EVA3000配置2个磁盘柜，分别有13块和15块73GB 10K磁盘，划分1个RAID GROUP，采用AUTO RAID技术，数据分布更均匀；结合前面的物理读统计结果，造成这些磁盘的响应时间过长的原因是由于TC和QC库的磁盘读取量过大，并且存储设备划分不够合理，各系统之间没有做物理隔离，当其中某个系统的IO请求量大时，是必要影响至其他系统，从而影响系统整体IO性能下降。

我们进一步分析存在问题的那个存储，发现CX3-40合计有4GB的缓冲，其中2500M被划分为写缓冲，516M被划分为读缓冲，其他缓冲被系统占用。

从上述分析我们得到了几个结论，首先存储的配置存在问题，LVM的两个存储的性能存在差异，这导致了IO负载高的时候会存在问题。

另外一个值得我们去关注的问题是，读写缓冲的比例是否合理的问题。CX3-40的存储缓冲区的划分方式是按照EMC工程师的常规施工配置，缓冲主要划给写缓冲，而读缓冲划分的十分小。这样的存储缓冲划分方式是否能适应应用系统的需求呢？优化组进一步分析QC/TC这些应用系统的IO特点，发现数据大多数都是分散写入的，而查询、统计分析才是日常感觉到慢的主要模块，所以说，大量的写缓冲并没有让业务人员感受到系统性能的提升，某个单一写入稍微慢点，也不会影响用户的使用感知。反而是读的性能不佳对用户的使用体验造成了较大的影响。

CX3-40的读缓冲仅有516M,在IO分散较广，IO请求较为集中的业务高峰期，读缓冲极有可能被击穿，导致IO总体性能接近于裸盘的性能。在这种情况下，仅仅由5块盘组成的RAID组的性能就十分有限了。

通过对几个查询响应时间慢的功能点，进行跟踪和分析，发现基本都是通过时间字段进行数据过滤，访问大表对象，而这些大表对象有些没有采用分区表技术，有些虽然采用了分区表技术，但都是按季度进行范围分区，分区粒度偏大，造成扫描的数据块就越多。而经过与业务人员沟通发现，通常用户查询数据以月度为主，季度分区会带来不必要的IO，建议将分区粒度调小，按月度进行分区。

如“销售汇总查询”功能，主要访问B_RP_DeptProductMonthReport表，通过BMONTH 字段进行数据过滤。此表总记录数为51,986,210条，59,136个数据块。未采用分区技术时，不管查询任何时间段的数据，全表扫描方式都需要访问全部的5.9万多个数据块；如果以BMONTH 字段按月分区，利用分区裁剪，全表扫描只需访问查询时间段所在分区的数据块，从而减少不必要的数据块扫描，降低IO负载，提高执行效率。

为了进一步分析表分区对系统的影响，测试组使用一台PC服务器搭建了一个测试环境，用于进行SQL性能的测试。以查询6/1-6/15号的“客户情况汇总分析”为例，将B_OD_OrderDetailTL表的分区粒度调小，由按季分区改为按月分区，生产环境执行计划选择范围索引，测试环境执行计划则采用全表扫描，因为当前分区内都是6月的数据，所以全表扫描比范围索引更有效率，执行时间由原来的42.34秒降为6.62秒。

到此为止，对系统性能的分析告一段落，主要问题都已经经过了分析，并找到了答案。下面我们来看一下整个优化方案是什么样的。

原有的部分数据库参数设置是极不合理的，比如查询库（QC）的KEEP池分配了2000M，但是实际使用不过几十M，而本系统的物理内存使用率相当高，经常出现换页情况，适当减小SGA,释放部分内存是十分必要的。为配合本次优化，将其调整为256M。

在IO性能不佳的系统中，用好KEEP POOL是十分关键的。通过KEEP POOL来大幅度减少IO，提升整体性能能起到相当好的作用。

对于对象的调整也是能够长期有效的，不仅限于某条SQL，因此在做优化项目中，大表分区的设计是十分重要的。

我们可以看到，通过一系列优化手段,IO得到了极大的改善，磁盘IO的响应时间从100毫秒下降为30毫秒。优化组在一个星期后进行了第二次优化，调整了存储的CACHE比例，将读写缓冲的比例调整为各占50%，这次调整使性能得到了进一步的提升，主要磁盘的IO平均响应时间均小于10毫秒。

优化后，各项指标均有较为明显的提升。

我们再来看看KEEP池的优化效果，我们可以看出，优化前，KEEP的两个主要对象产生了本系统中的77%以上的IO,而将其放入KEEP POOL后，这些对象已经从IO较多的TOP对象中消失了，而从KEEP POOL的命中情况看，KEEP POOL上产生了1/3的逻辑读请求，产生了巨大的作用。

优化好不好，还是要看疗效，只有业务部门从应用使用情况方面的反馈才能真正验证数据库优化的效果。从这张表中可以看出，本次优化肯定是会被业务部门所认可的。

前面我们简单回顾了这个优化项目的情况，从中我们能体会到些什么呢？到底什么样的人才能做优化？优化项目到底该怎么做？优化的重点应该放在哪里？优化的效果应该怎么评估？
 

性能优化的重点在哪？我们很多人做优化喜欢上来就找SQL，反正我们的系统大多数开发质量不高，有问题的SQL一抓一大把，随便找出一堆SQL，优化优化，总能取得不错的效果。这好比是我们感冒发烧了，去医院，医生只要给你挂上一瓶水，第二天几本就没问题了。不过下回还照样感冒发烧，照样去医院挂水。而如果你能找到为啥总是感冒发烧，找到预防这些问题的方法，那么对于患者来说，是刚好的事情。我并不反对做SQL优化，而是建议SQL优化放到最后去做，除非你的系统存在严重的问题，必须通过优化个把SQL来解决问题，那么SQL优化放到优化项目的后期去做是比较好的，前期重点是分析更为深层次的问题，找到一些解决通用性问题的方法。

而从优化的角度来讲，优化是全方位的，我刚才列举的所有层面，都是优化的重点。甚至很多时候，优化要跳出优化本身来讲，才能找到较好的解决方案。

一个成功的优化项目离不开扎实的客户调研，只有理解客户的需求，才能给客户创造价值，黑灯瞎火的的蛮干，可能能获得一些成果，不过很难实现客户的价值。其实我们的很多客户都是花了冤枉钱在做优化。花了不少钱，轰轰烈烈，热热闹闹的做了场优化，当时来看也获得了不错的效果，不过半年后，甚至几个月后，优化的效果就荡然无存了，系统又回归原来的状态，直到系统升级，才算开始一个新的轮回了。

第二个确保优化效果的要素是深入全面的分析，不要急于去做任何实施操作，而是在优化项目的前期要十分认真的分析系统可能存在的最主要的问题。比如系统本来存在某个问题，导致了业务高峰期的问题，这个问题藏的比较深，需要通过深入的分析才可能找到，而你上去就优化了一条SQL，这样这个问题暴露的几率更低了，你就更难找到这个问题了。当项目结束后，客户的应用系统升级了，又有几条类似SQL诱发了这个问题，那么你前面的优化工作又白做了。

充分理解你优化的系统的IT基础架构是十分必要的。你的IT架构中存在什么问题，可能导致你的系统遇到某个瓶颈，这些都应该是DBA去关注的问题。我举个例子，一个客户的一套系统,每到年底做结算的时候就会出现IO性能问题，导致结算速度很慢。我们的优化组看了一下，高峰期一个数据库节点的IO负载在400多M每秒，但是IO性能就很差了。而我们看了下，这台机器插了两块8GB的HBA卡，存储也是十分高端的XP 24000，这套系统使用的硬盘有300多块，按理说不应该存在IO性能问题。当我们进一步分析发现，原来SAN交换机的端口是4G的，8G的HBA卡无法发挥出全部的作用，而更让人感到啼笑皆非的是，这台交换机的背板居然只支持每个端口2GB的吞吐量。至此，我们终于算清楚了，2块HBA卡，每块只能跑2G流量,确实400多M已经达到极限了。弄清楚问题后，解决问题就十分简单了，换台SAN交换机就能彻底解决问题，由于换交换机涉及采购，流程比较长，临时解决方案就是增加两块HBA卡。
 

通过这个案例，我们再来看看在DBA圈流传较为广泛的几个说法。

第一个是性能优化比一过早，字面意思也挺容易理解，就是性能优化做早了，问题还没充分暴露，做了比较浪费。这句话明面上似乎很有道理，等问题充分暴露了再做优化，性价比比较高。不过如果我们的优化工作是类似西医挂吊针的方式去做，那么性能优化太早了确实浪费钱。不过如果我们能深入分析系统，做全面的优化分析，那么这样的优化工作越早越好。甚至我们提出了，性能优化从需求分析开始的理念。

第二个观点是，性能优化是高手的工作，水平不够，做不了优化。当然高水平的DBA可以提高优化工作的水平，但是优化工作不能仅仅依靠某个或者某些高水平的DBA，而应该通过一种制度化的方法来指导优化工作往正确的方向前进。优化效果更多的是取决于优化工作人员的细心和认真坚持的态度。这个优化案例就是一个很好的例证。参与本次优化的人员都是接触优化工作不足1年的新手，在我们很多DBA来看，他们的水平也属于相对平庸的哪些人。为什么他们能够做出了这么一个大师级的优化项目呢？首先是他们认真的工作态度，不放过任何一个蛛丝马迹。其次是他们采用了正确的方法，通过深入的用户调研，终于找到了本次优化的几个关键点。

第三个观点是性能优化最重要的是SQL优化。十多年前，我们给客户做优化的时候，客户总是抱怨，Oracle公司来做优化，总是扔出一堆烂SQL来，就交差了，好像所有的问题都可以归罪到SQL身上。于是我们向客户说，没关系，我们能帮你们优化SQL.于是能优化SQL成了我们的一种技术优势。不过随着这些年的工作实践来看，SQL优化虽然是每个优化项目必备的科目，但是SQL优化在优化工作中的作用，并没有我们以前想象的那么大。基础架构、数据架构、应用架构的优化，其对系统的长远影响远远高于SQL优化。SQL优化可以治标，解决系统目前的问题，但是由于我们的系统都是动态发展的，不断有新的业务模块和补丁加入进来，SQL总是在动态变化，因此某个单一SQL的优化效果，其持久性往往不够。

那么我们接下来探讨下，到底什么是系统优化呢？

首先系统优化是为了解决系统运行过程中存在的主要问题的，要全面统筹考虑，不能为了解决性能问题而带来其他的问题，比如运维方面的问题。

其次系统优化是一个十分严密的工程，需要有一些具备各种专业技能的人分工协作来完成。系统优化不仅仅是个人的纯技术的工作，而应该按照工程的目标来组织人力资源，组织实施工作。不能完全依靠某个人天马行空的工作。

系统优化需要贯穿整个IT基础架构到应用的全部层面，而不能仅仅限于数据库层面去解决问题。数据库的问题不能仅仅考虑用数据库的方法去解决，而是要通过全面的考虑，选择解决问题的最佳入手点。

虽然系统优化是一个讲究集体协作的工程，但是并不否认高水平的DBA在期间的作用，如果我们在做优化过程中总是循规蹈矩，按照某个流程去实施，那么优化效果也不会好。在优化过程中，需要发挥每个人的能力，创造性的思考问题，才能取得更好的效果。
 

其实在我们今天讨论的问题中有两个词汇“系统优化”和“性能优化”，这两个工作还是有很大的区别的。从优化工作的理论发展来说，我们更喜欢用系统优化这个词。因为优化不仅仅限于性能，优化的目的是让系统跑的更好，更省心，更省钱。

除了性能以外，还有很多东西值得我们去关注，包括系统架构的合理性，系统的可靠性，系统的容量、系统运维的难度、系统建设的造价，等等。在这些方面，都有需要进行优化工作的入手点。在哪个方面获得一些成果，都能为客户创造价值。

在这里，我们要再三重申：性能优化从需求开始，性能优化从需求开始，性能优化从需求开始，重要的话要讲三遍。

在系统生命周期里，优化工作一直贯穿期间。从项目初期的IT管理计划，需求分析，到系统上线后的巡检和系统总结。

在研发阶段，优化工作可以围绕下面几个方面来展开：

需求审计：对客户需求中的一些重大需求进行识别，发现可能存在的对系统性能有较大影响的需求，分析起合理性，对某些危害级别较高的需求，寻求客户可接受的替代方案。

设计审计：系统设计的时候，在应用架构和IT基础架构方面，都需要进行优化设计。应用系统该采用何种架构，是否使用ORM，使用什么ORM技术等等，对数据库的影响都十分大。IT基础架构该如何配合应用系统，用小机好还是PC SERVER好，内存大点还是小点，IO能力该如何设计等，对系统今后长期运行都十分关键。

数据字典建模对后续的数据库性能、SQL性能都十分关键，而建模往往是开发人员在做，开发人员考虑的主要是业务匹配度，而不会更多的去考虑系统的性能。在这里，DBA可以发挥更大的作用。

核心代码走查和SQL审计在银行等行业十分普及，但是绝大多数研发体系中并没有这个环节，而且代码走查往往都是研发队伍内部做单元测试的一个环节，并没有DBA等专业人士参与。DBA参与核心代码的走查可以发现更多的问题。

系统容量评估实际上是系统建设过程中十分关键的工作，目前我们很少会去做。
 

系统上线阶段的优化工作是十分关键的，大多数运维过程中发现的问题是系统上线阶段遗留下来的。这个阶段往往也是我们DBA介入系统建设的开始阶段，其实也就是在这个阶段，大多数DBA并没有很好的履行其职责，把大量的系统问题带到了运维阶段。
 

这里说的工作内容是在座各位最为擅长的，也是DBA日常最为重要的工作。实际上，作为DBA，我们在日常的运维工作中，并没有很好的实施上述的工作。这也为系统出现严重问题留下了隐患，如果我们能够很好的完成上述的工作，绝大多数的系统问题是可以预先被发现或者整改的。

刚才我们一直在说优化项目是一个严密的工程，不能按照某个人的想法天马行空的去做。而一定要按照一定的工作流程，按部就班的去做，才能不留死角。我们把整个优化项目分为获取优化需求，分析性能瓶颈，制定优化策略，开展优化实施，效果验证等阶段。每个阶段都有相应的工作内容，都有标准化的产出物。

在优化工作中，以前我们总是会向客户说，不需要开发人员配合，我们就能很好的完成优化工作，这也一直是我们做优化项目的时候，当做优势去宣传的内容。实际上，一个很好的优化项目，是离不开开发人员的支持的。在《DBA优化日记》里，我就讲述了要和开发人员搞好关系，以保障优化项目的顺利进行。实际上，这里涉及了白盒优化和黑盒优化的问题。做测试的人都明白，白盒测试肯定质量更高，但是成本也更大。黑盒优化是一种成本较低的优化模式，能够解决一些目前暴露出来的主要问题，但是黑盒优化的目标性不够强，有些隐藏较深的问题无法发现，因此黑盒优化的长期效果一直不佳。在现在IT建设运维一体化的前提下，白盒优化所需的各种资源已经具备，白盒+黑盒的优化模式越来越成为大型优化项目所采取的最佳手段。而一些自动化工具也可以帮助我们在开发人员无法全面协助我们的情况下，实施白盒优化工作。实际上，有些人把这种没有开发人员协助，完全借助技术手段的类似白盒分析的方法称为灰盒优化。

借助这些工具，我们可以实现系统的端到端分析，从而更容易定位问题和评估优化效果。

下面一个问题我们要探讨下优化效果的评估机制问题。10多年前，在我们做一些优化项目中，制定了一套优化效果评估的指标体系。我发现现在不少人都在用这些指标，不过随着这些年我们从事优化工作的实践来看，那些指标都很难真正反映出系统优化的实际效果。比如说CPU使用率下降就说明优化小工好吗？在一个CPU资源不是瓶颈的系统中，CPU使用率的下降并不是优化的根本目标，以此为指标，对优化效果的评估就会产生严重的偏离。平均事务响应时间也不是一个十分准确评估系统性能的指标，因为事务对于不同的系统，差异很大，对于一个封闭环境来说，这个指标还有一定的对比意义，对于一个变化十分复杂的系统，这个指标的准确度就不够高了。

最后我们来探讨下架构对于优化的重大作用。DBA总是希望通过Oracle的手段去解决任何问题。实际上很多问题要跳出ORACLE来考虑才能找到最佳的答案。我们应该用最为适合的技术来做最合适的事情，这才是优化的精髓所在。

30年前，John GAGE说了网络就是计算机，这句话现在已经成为经典，而且已经在IT的各个方面得到了验证。去年年底，吕建院士访问南瑞信息系统应用技术实验室的适合，和我有过深入的探讨，最后吕老师说出了“应用场景就是计算机”这样一句发人深思的话来，确实这句话和子衿技术团队的技术理念十分契合“按需定制，深度集成”，我想把这句话送给大家，来结束我今天的技术分享。