基本的应用

      正如前面提到的，当改善基本"开箱即用"的套装应用软件性能时，既有挑战也有机会。我们讨论了硬件升级的方法和常见的底层系统层的调优，像硬件/OS和网络本身。在这段里，我们将提出由DBA进行调优工作。

      沿着系统层相同的方式，通过数据库实例的调优可能影响性能。肯定的是，数据库大师级人物将能够检查数据库的日志，并且查明性能问题。一个有经验的DBA能够指定通常与改变参数和设置有关的解决方案。可能的话，你的底层数据库将允许你这么干，不用停止系统。我们打算确保解决方案比问题本身好。

      如果你的员工没有这种调优专家的能力，你可以选择咨询顾问或者有优势的工具，帮助你提高性能。这些工具能够产生智能报表。

      如果你从事这种参数类型调优，表明你按规则实践了。正如前面讨论的，在线交易处理性能的改善和提高可能不如批处理那么明显。另外，你的性能处理概图将在每星期，每月，每季度和每年都改变。考虑这些时间很重要。在各种压力概图期间回顾你的性能调优将使你能够及时选择最合适你的解决方案。你应该有专业工具，你的参数调优可以是动态的，藉以你能修改任意你原来的设置计划。

      一旦你已经做了基本组件能做的所有调优，你不可避免地会对特有的应用代码进行调优，这意味着底层表的形式逻辑设计和相关索引（和每个查询本身）都已优化。

      例如表和索引，它们有一些选项你可以做别的调整。或许您的整体应用概况是这样, 附加的索引也许改进数据存取性能。你能迅速创造新索引来支持一次特殊查询，但理解它们带来的危险是很重要的。索引的创建和维护是需要成本的。在一个有大量变动数据（一些插入和删除）的表中，维护那些索引的代价往往会大于某些个别SQL语句的性能改善。

      强烈推荐你在确定优化索引策略时，考虑范围更宽的SQL语句。当然，这说起来容易，实施起来是复杂的。对于一个大型的应用，可能真的很难理解源代码和已存在结构的所有查询。这时你应该如何做呢？

      对于这样的过程，SQL调优工具可能是你非常好的的选择。如果你能够使用工具把你所关注的SQL集尽可能关联起来，那么你就能很快地找到正确的解决方案了。

      你应该选择那些SQL用来评估呢？肯定是从你的应用源程序中选择。你怎么确定评估哪个SQL语句呢，那是一个挑战？我们建议你按以下步骤进行：捕获在预定采样时间中运行的SQL语句。典型的一天采样时间应该体现出使用最通常和最频繁的应用程序的用户的使用情况。如果你的应用是利用绑定变量（在Oracle中）写的，那么工具所捕获到最经常使用的值对你很有帮助。在典型的一天采样时间或一个星期采样时间中，你很可能涉及到一些重要的批处理。务必确定捕获这些活动，并且理解这些操作和可能与这些批处理运行相关限制的时间周期。

      搜集完SQL后，你可能发现需要关注的语句很多。这时，考虑每一种语句的单独目标很重要。对于OLTP环境，你可能打算考虑查询的频繁程度，因为有很多的用户可能使用它。对于批处理环境，要考虑的是任务完成的时间长短或资源消耗的多少。

      这时，删除索引存在一些问题。你可能发现你的应用不太需要特定的索引。这可能是一个要解决的难题，如同这可能会代表对产品的原始计划表的变动。正如前面提到的，首先要确定你的供应商。这里存在一些原因，某些索引可能不再需要，你也不必管理它们。但是可能还有一些索引是用来支持一些模块的查询，而你并没有购买这些模块。即使你以后计划购买这些模块，你也肯定能在实施之前创建这些索引。

      这里有一些情况，在套装应用软件代码中写的查询本身需要改善。对于一些数据库，基本上需要重写代码。如果你的数据库是Oracle，还有点希望。"Outline"特征使你能够改变一些SQL的执行计划，而不必要重写SQL本身。。通常，一个查询将送达数据库，并且如果相关的执行计划没有在缓存中，这时优化器将会创建一个执行计划。对于套装应用软件，我们对改善不能变更的源代码比计划稳定性更感兴趣 。你能够创建执行计划的大纲，这个计划比原始地编写查询语句优先级高。

      Oracle提供一些基本的大纲管理，但你必须首先确定SQL的非常好的"重写"计划。有经验的SQL调优人员能够为你做这些工作。你愿意使这个过程自动化吗？市场上有一些工具能帮助你转换SQL，并且提供易用的大纲管理能力。

      在所有的例子中，应该理解你有权改善套装应用软件基本代码的性能。你只需确保你选择的方式没有危及你的应用及供应商的立场。

    客户化

      客户化是供应商提供全套功能的非常好的尝试。你的公司购买的套装应用软件可能没有足够的业务专业知识，但能自动化地进行业务处理。灵活地适合你业务的特有需求是很重要的。

      前面已经讨论了一些客户化的分支：供应商不提供产品支持，客户化需要形成文档，也需要维护这些改变和在改变过程中的投资，使得通过升级保持改变能顺利进行。对于一些公司，根据Gartner，通常客户化的价格是实施套装应用软件的20％以上。

      你着手进行客户化过程时是怎样影响你改善应用性能的能力？选择有很多，可以是你自己内部进行这些一般改变的团队，或者是供应商提供的工具，或者雇佣专门的咨询人员。

      供应商通常是一个"服务"公司，就像应用软件开发商那样。如果这些定制的源代码是供应商自己的雇员做的，那么你的担心就会少点。

      然而，当咨询人员走了，并且过了一段时间之后它们的工作并没达到想象中的那样，那么你可能还是跟以前一样，好像处理原始的源代码。

      简单地理解客户化中哪些部分是你优化的，哪些不是，这项任务可能是一个挑战。我们无法注重那些是重要的或者同你的供应商一起工作以了解这些分界线解。

      让我们假设你处理的是你自己的代码。无论是内部人员或者外面的咨询人员编写代码，这都无关紧要。你制定客户化的需求规范，支付相关的开发费用，，所以你的责任就是确保它能按照你的标准工作。

      这个过程应该是任何一个开发项目都有的。时间、工具和资源应该都是工程计划中的预算。从设计到交付，都必须考虑到性能影响。