数据库优化项目的流程之方案 zt

http://blog.oraclefans.cn/baishan1/entry/dba%E6%97%A5%E8%AE%B0_%E7%AC%AC%E4%B8%80%E9%83%A8_%E5%90%8E%E8%AE%B0_2_%E4%BC%98%E5%8C%96%E9%A1%B9%E7%9B%AE%E7%9A%84%E6%B5%81%E7%A8%8B%E4%B9%8B%E6%96%B9%E6%A1%88[@more@]zy

0.1.1. 优化项目的流程之方案

优化方案的设计是整个优化项目成败的关键，通过对系统的全面分析，为系统设计合理的优化方案，需要方案的设计者对系统有很强的理解，并且能够针对每个可能的性能问题提出针对性的优化方案。

编 写优化方案分为两个阶段，第一阶段是通过分析数据提出优化的整体思路与方案。针对一个性能问题，可能存在多种优化方案，但是最终采取哪种方案是十分值得仔 细斟酌的。很多DBA在有多种优化方案可以选择的情况下经常会选择一些能够充分体现出其技术能力的方案，而往往缺乏对这些实施方案可能存在的风险的评估。 经常有些DBA让我帮他们审核优化方案。这些优化方案往往都是提出一系列系统存在的问题，然后针对这些问题，一对一的提出优化方案。这种优化方案实际上是 很粗糙的，仅仅是针对某个问题提出相应的方案。这些方案是否可行，是否存在风险，就没有人关心了。事实上，我们是在做一个整体优化项目，而不是做一个局部 的优化。我们在做数据库维护的时候经常会碰到需要做局部优化的情况，某个系统出现了性能问题，而这个性能问题的原因是由某个原因导致的，只要解决了这个问 题，那么这个系统优化的工作就完成了。对于整体优化的项目，是基于某个目标的，而不是基于某个系统症状，因此我们需要的是实现优化目标，而不是罗列优化技 术。

因 此在设计优化方案的时候，我们要考虑我们的优化目标，如何通过针对某些问题的调整，来实现我们的优化目标，才是我们再做优化方案设计的时候的关键点。因此 在做性能分析的时候，我们必须明确什么是本系统的系统性能问题的关键，我们在设计优化方案的时候，也要围绕这些关键点来展开。如果某个等待事件，占系统总 等待事件的5%，那么我们在解决这个问题的时候，就要考虑解决这个问题可能给我们带来的风险有多大，实施方案的难度有多大，我们解决这个问题所花的代价是 否和收益成正比。如果实施这个优化存在较大的风险，那么我们甚至可以放弃对这个问题的优化。反过来，如果我们碰到了一个占整个等待事件超过50%的问题， 那么这个性能问题将作为我们本次优化的重点，无论花费怎样的代价，我们都必须解决这个问题，否则我们就很难达成我们预期的优化目标。有经验的DBA在进行 优化的时候，都能够很好的识别主要矛盾和次要矛盾，把有限的精力都放在解决主要矛盾上，这样才能够提高项目成功的机会，同时避免不必要的风险。

在 设计优化方案的时候，如何合理的规避风险也是十分关键的，绝大多数优化方案都不是唯一的，往往我们都会有多个方案可选，如何选取一个合理的优化方案将十分 关键。这一点也往往成为有经验的DBA和经验不足的DBA之间最大的不同。在有多个方案可以选择的时候，往往需要有资深的DBA参与审定，才能够保证优化 工作不会出现严重的偏差，在这个时候，需要通过评审会的方式来对优化方案把关。当然如果项目组里有一些资深的优化专家坐镇或者提供顾问支持，那也是降低项 目风险的有力保障。尽管这些专家并不是项目组的常驻成员，但是以他们的经验往往会对优化计划提出合理的建议。

在 这个阶段还有一点需要注意的问题就是，我们在设计优化方案的时候往往过于集中在项目组内部，而忽视了外部的资源，我们提出的优化方案有可能对于客户来说不 具备实施条件。老白就碰到过一个项目，由于buffer busy waits十分严重，导致了系统性能急剧下降，影响了业务系统。经过分析，发现问题很 明确，就是某个SQL对一张表进行了过于频繁的扫描，导致了cache buffer chains等待十分严重。实际上这个问题优化起来也很简单，只要 调整一些缓冲池的大小就可以了，但是由于本月已经没有停机时间了，这个方案就无法实施，在这种情况下和应用开发厂商进行了协调，最后应用开发厂商决定把这 张表的数据直接载入到共享内存中，需要访问这个数据的进程直接在应用服务器的共享内存里进行读取，而避开了对这张表的扫描，从而解决了这个问题。

不 好的优化方案都有共同点，就是过于的一厢情愿，而没有充分考虑到实际情况。我也看过很多优化方案，其中不乏一些闭门造车的方案，提出一些不切实际的建议， 虽然从技术上来看，这些建议都很有道理，但是这些方案缺乏可操作性，因此往往很难被客户接受。比如说，我们如果一发现CPU使用率很高，就要求客户扩 CPU，这种优化方案虽然正确，但是没有多大的价值。如果某个系统确实是除了扩容CPU，没有其他方法了，那么这个建议就可能是一个很好的建议。

优化方案完成后一定要经过评审，刚才老白所说的内部评审是第一轮的评审，而更重要的是通过客户和开发商、集成商的评审。在评审的时候我们往往会遇到很多问题，最常见的问题包括：

l 开发商不愿意修改应用，而对优化方案提出质疑

l 客户的能力有限，无法区分各种意见的正确性

l 由于实施条件不具备，某些方案无法落实

在 这种情况下，就需要优化实施者对优化方案又很深入的了解和把握。将优化方案的的原理、风险、效果一一向其他人解释，甚至必要的时候优化实施者还需要做出某 些承诺和保证，承担优化失败后的后果。实际上任何优化方案都是存在一定的风险的，但是有风险不等于该方案不具备实施的可行性，如果能够对风险有准确的评 估，并且针对风险有合理的处理预案，那么这个方案就是可行的。

当 优化方案经过评审后，我们下一步就需要针对优化方案设计详细的实施方案。实际上，实施方案的编写是优化成功的关键，实施方案将选择我们处理问题的技术路 线，并且为每个风险设计规避方案和应急预案。在设计实施方案的时候，还需要对实施的每个步骤进行评估，确定每个步骤的实施时间，从而为合理的安排停机窗口 提供依据。如果一次试试的内容过多，无法保证在停机窗口内完成的话，我们就必须在实施方案中将这些操作分配到两个停机窗口里完成。

合 理的评估实施时间是十分关键的，老白参加过的优化项目中，很大比例的项目在实施时间的评估上存在不足的情况，最终导致实施的时间十分紧张，严重的时候甚至 可能导致项目失败回退。而实施时间评估不足的最主要的原因是我们没有给问题规避和回退预留足够的时间。在设计优化方案和实施方案的时候，我们往往会遇到一 个问题，就是我们无法在测试环境中对我们的方案进行验证，这往往会导致我们的优化方案中存在一些无法预料的问题。比如老白和老于在沈阳这个项目的第一次实 施的时候，就碰到了调整cursor_sharing参数后部分模块无法正常运行的问题，最终导致这个优化操作回退，实际上在这个项目中，在碰到这个问题 之前，我们都一直很顺利，原本计划3点钟就可以完成所有的操作的，不过这个问题出现后，我们通过近一个小时的分析，才确定是一个BUG导致，我们无法避 开。所以那次实施直到4点多才完成，基本上用完了我们预定的停机窗口。

实 施方案编写的时候，还有一点要注意的是我们采用的技术路线，很多DBA都喜欢在自己的优化项目中采用一些看似很高深的技术，实际上，技术路线越大众化，实 施的风险越小，而那些看似高深的技术，往往都带有较大的风险。比如我们将普通表转分区表的时候，我们只是采用了最普通的技术，首先rename原来的表， 然后创建分区表，再把数据插回新表。这个方案看上去虽然技术含量不高，没有使用在线表重定义等技术，但是这个方案是十分“安全”的。一旦优化中出现什么问 题，只需要简单的把原来的表rename回来，就可以实现回退了。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/82387/viewspace-1027018/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/82387/viewspace-1027018/