介绍
这篇文章讨论了一些优化商业套装软件的机会。负责可接受应用性能的应用管理团队成员可能是这篇文章讨论受益最多的。这篇文章中主要集中在数据库调优，所以数据库管理员（DBA）和开发者可能发现这篇文章很有价值。我们将讨论与这些产品和所考虑策略相关的基本调优问题，还有可能帮助你进行成功调优的技术建议。
首先，我们将指出套装应用软件在企业中发挥越来越重要的作用，和因此对信息技术组织意味着什么。我们这时将分析特有的调优挑战，这些挑战是由这些产品体现出来的，在后面我们将简单地看看供应商提供的解决方案。下一部分回顾常见的性能提高策略，依次跟着最佳调优这些产品的建议。
套装应用软件的增长
多年以来，商业上已经开始使用套装应用软件自动化他们的业务流程。早期介绍的套装应用软件通常是从财务和金融应用开始，然后到库存管理和制造业。到了90年代中期，一些供应商像SAP和Baan快速发展。对于这些软件供应商，真正的转折点是千年虫问题的到来。许多公司，担心他们内部开发的应用失败，选择购买有保证的解决方案，而不是试图重写已有的应用系统。紧接着，ERP市场爆炸性地出现了不可计数的服务和附加产品。
结果，定制业务应用系统的开发急剧萎缩。加上经济的低迷，应用开发人员的作用减少了，在一些情况下，重点转移到外包和离岸解决方案。在这些外力的作用下，2003年美国程序员出现最高的失业率就一点也不奇怪了，因此人们不再创建新的应用，而更倾向于像传统那样维护现有的应用。
近几年的经济低迷不仅打击了程序员劳动力，对供应商也有一定的打击，使其不能呈强劲的增长趋势。但是像SAP这样的供应商还是有一定的增幅，而且Microsoft Great Plains和Navision的购买给中小企业创造了效益。比起90年代和2000年初期，市场还是比较低迷的。然而，可以预见，尽管市场低迷，我们将看到ERP市场仍有大体上6％的增长。特别地这个激发因素是渴望满足灵活的调整需求，并且购买这些有适应能力的产品变成了流行的作法。尽管有一定的增长，客户应该仍然谨慎。根据调查，50％损失惨重的IT失败是跟商业的ERP失败有关的。
外包和避免定制开发的相结合慢慢形成一个新的有趣现象。在这种情况下，业务应用的外包像CRM或者由应用供应商套装应用软件集已经慢慢地增长。
商业应用的常见问题
对于IT部门，实施重要的商业应用这个行为是一个非常关键的事情。
通常，实施企业ERP或者CRM应用是昂贵的。它的花销不仅区限于套装应用软件license，还包括购买附带硬件，进行系统升级和人力成本等。
在这种情况下，人力成本指的是给咨询人员的钱，你必须依靠这些咨询人员才能成功部署应用。根据AMR的研究，75％的ERP市场开销或利润是跟编程和咨询服务有关的。由于实现应用所需要的知识，这些钱通常投资给部门外的咨询人员。
你所购买软件的公司可能有一个咨询队伍，他们很乐意帮助你实施具体业务的改变，风险是他们的产品是写给通常的商业团体，而且你的业务需求可能有改变。这对于技术分类来说可能是相当有问题的观点。
通常，你有两个选择。你或者试图改变应用适合业务的需要，或者继续使用已购买的应用而不管业务是否满足。后者听起来不是很顺耳，但对于供应商来说这个肯定是它们喜欢的选项，并且不断被很多公司采纳。对于一些领域，公司的运作已经非常规范（例如财务系统），一些必要的变化可能是很小。如果你的公司由于运作方式具有独特的优势，那将面临更多挑战。
你决定迎接这些挑战吗？你必须回到一些定制的应用上来。不总是不一样，Gartner集团的研究发现大部分的ERP实施的20％是定制功能的。定制伴随着一些挑战和风险。你必须首先确定特定的供应商对客户化的态度。供应商将为应用的一些领域提供比较少的支持，因为一旦代码修改了他们就不能控制代码了。在一些情况中，这可能明确地禁止。
这篇文章的重点是调优应用的性能，你应该注意到，转移到套装应用软件并没有减小你对应用的控制。首先，你不能 "拥有"供应商创建的代码。第二，你可能不能访问用于定制的源代码。第三，通常不赞成改变系统，即使是为了调优。然而，基于前面三点的假设，这篇文章的后面将帮助你找到克服这些挑战的方式。
供应商工具
在管理应用的时候必须有辅助工具。大部分供应商给你提供了可能用来管理应用环境的各种各样工具。
通常地，这些工具主要集中于基本的管理。对于所有的应用，用户管理，参数设置和类似的功能都是一样的。越成熟的产品能使你更好地理解增强应用能力的组件，但很少强调性能调优（你可能需要第三方供应商）。
这个行业历史最老的供应商SAP提供了一个最昂贵的工具集。SAP提供了数据库管理，SQL Studio，DB Loader等其它工具。
Oracle有一系列基本的企业管理功能（OEM）工具，并且很乐意以Management Pack（也有其它的管理包）的这种形式卖这些工具给你。
PeopleSoft有一套完整的以Peopletools为形式的定制和管理工具，用于帮助你开发，部署，维护和升级系统。
Siebel有一个最简单并且数量最少的管理工具。像其它提到的大部分工具一样，使用Server Manager管理应用。
典型的性能策略
一般人们认为对于改善套装应用软件的性能几乎无事可作，这观点是错误的。通常地，这种假设导致了部门不能从问题的根源出发解决问题。
客户首先趋向于寻找硬件升级的方式提高应用的性能。通常对于客户来说，在供应商或相关的咨询人员的强烈建议下，配置更大的和/或更快的硬件。最强大的计算平台经常是基于快速增长或使用假设购买的。网络硬件升级到最新的路由器和网桥，购买更新更快的存储设备。当应用第一次投入生产时，它运行良好。在早期这段时间中，应用响应可能处于最佳状态，数据装载是轻量级的，并且应用的所有表现都没问题。由于处理能力，通信能力和访问速度不可思议的强大，任何真正的问题可能是看不出来的。
只要系统运行良好，可能就没必要强调性能了。然而，随着时间的流逝，系统开始发现变化，这时你将可能会想到调优。最后，你可能看是否还能升级硬件。在这种情况下，你可能手工调整操作系统或与应用组件相关网络层的配置。大部分的供应商在他们的文档里面都提供了建议性的设置，但它们不是必须的，并且不被看作技术支持或维护协议的一部分。
如果情况没有改善，下一阶段将调优应用组件本身。然而，这并不意味着实际的应用代码，而是调整用于Web服务器，单独缓冲机制，应用服务器，数据库服务器或者存储系统的相关参数。这种多层的结合非常复杂，确定它的问题来源不太容易。
当我们关注数据库时，你的数据库中有太多的方面可以调整。只在Oracle中，你就有好几百个参数可以利用，并且有很多数据用于检查确定究竟是什么引起了性能问题。就像其它组件一样，这种参数的调整也是一个复杂且综合的问题。
调优数据库实例的值几乎在你的控制中，虽然你的应用供应商可能提一些建议，并且在这些地方可能有一些要求。除了有权利用这些变量，另一个优点是它们没有相关的明确成本。对于特定挑战条件，当这个是真的时候，你可能需要求助于咨询专家，你只能寻求他们的建议了。在这个层面上，确实有一些真正独特的应用。可能的话，你的部门有一些预算给你或专家调优。你可能缺少深度的知识用于这些不同的层，或者没有足够的预算用于寻求外部的帮助，市场上肯定有一些工具和知识帮助你优化特定实例。
数据存储跟数据库是紧紧绑定在一起的。在这个层次上，你会留下数据库参数的安全限制，并且致力于物理层的低层次处理。在这一点上，你需要一个安全和被检验了的方法优化你的存储系统而不中断应用流程。存储是远离数据库直接控制的一个步骤。通常不容易发现数据库和在这些存储设备上数据段之间的关系，并且你可能再次需要一些特定的工具。
你可能遇到的最大问题来自异构组件。例如，你的Oracle数据库服务器可能是Solaris box，而Apache Web服务器在Linux上。在它们之间，可能是运行在AIX上的WebSphere应用服务器。把它们所有的参数捆绑在一起（并且可能还有它们所有单独工具）是一种挑战。
打包应用实现的分析
在某种程度上，我们已经谈了一些关于标准套装应用软件。我们也讨论了这些应用的客户化，但是理解应用比理解基本应用和客户化更重要。其它的应用组件也影响数据库性能。
首先是供应商的基本代码。我们或多或少已经谈了一些。稍后的文章中我们将讨论，在不改变代码的情况下，如何改变数据库实例中的性能。
在讨论的第二部分中我们将继续探讨定制。定制指的是为了打包应用能够满足组织特有的需求，而采取的一些调整，这当中有一些特别的挑战。
讨论的第三部分将集成已存在的业务系统。在应用性能调优的上下文中，我们看到一些特有的和有意思的挑战。
在一些自动化的业务应用中，还有各种各样的辅助工具一起工作，保证业务的成功执行。最常见的辅助功能是企业报表解决方案。它们提供很大的价值，但也能给数据库性能带来了至关重要的挑战。
关注的最后一个区域是应用升级和升级对于业务意味着什么。典型的需求经常和可用性，意义相关联，"我们得把系统停多长时间进行升级？"我们将讨论用于调优的机会最小化停机时间
在这些所有区域中，首先所有这些讨论的改变和其中的任何一部分在测试环境中都应该是稳定的。知道调优决不是一个单独的事件是很重要的。当压力和用例模式改变时，你调优的值也将改变。为了看到这些值是如何改变，对压力模拟进行试验将是明智的。
基本的应用
正如前面提到的，当改善基本"开箱即用"的套装应用软件性能时，既有挑战也有机会。我们讨论了硬件升级的方法和常见的底层系统层的调优，像硬件/OS和网络本身。在这段里，我们将提出由DBA进行调优工作。
沿着系统层相同的方式，通过数据库实例的调优可能影响性能。肯定的是，数据库大师级人物将能够检查数据库的日志，并且查明性能问题。一个有经验的DBA能够指定通常与改变参数和设置有关的解决方案。可能的话，你的底层数据库将允许你这么干，不用停止系统。我们打算确保解决方案比问题本身好。
如果你的员工没有这种调优专家的能力，你可以选择咨询顾问或者有优势的工具，帮助你提高性能。这些工具能够产生智能报表。
如果你从事这种参数类型调优，表明你按规则实践了。正如前面讨论的，在线交易处理性能的改善和提高可能不如批处理那么明显。另外，你的性能处理概图将在每星期，每月，每季度和每年都改变。考虑这些时间很重要。在各种压力概图期间回顾你的性能调优将使你能够及时选择最合适你的解决方案。你应该有专业工具，你的参数调优可以是动态的，藉以你能修改任意你原来的设置计划。
一旦你已经做了基本组件能做的所有调优，你不可避免地会对特有的应用代码进行调优，这意味着底层表的形式逻辑设计和相关索引（和每个查询本身）都已优化。
例如表和索引，它们有一些选项你可以做别的调整。或许您的整体应用概况是这样, 附加的索引也许改进数据存取性能。你能迅速创造新索引来支持一次特殊查询，但理解它们带来的危险是很重要的。索引的创建和维护是需要成本的。在一个有大量变动数据（一些插入和删除）的表中，维护那些索引的代价往往会大于某些个别SQL语句的性能改善。
强烈推荐你在确定优化索引策略时，考虑范围更宽的SQL语句。当然，这说起来容易，实施起来是复杂的。对于一个大型的应用，可能真的很难理解源代码和已存在结构的所有查询。这时你应该如何做呢？
对于这样的过程，SQL调优工具可能是你最佳的选择。如果你能够使用工具把你所关注的SQL集尽可能关联起来，那么你就能很快地找到正确的解决方案了。
你应该选择那些SQL用来评估呢？肯定是从你的应用源程序中选择。你怎么确定评估哪个SQL语句呢，那是一个挑战？我们建议你按以下步骤进行：捕获在预定采样时间中运行的SQL语句。典型的一天采样时间应该体现出使用最通常和最频繁的应用程序的用户的使用情况。如果你的应用是利用绑定变量（在Oracle中）写的，那么工具所捕获到最经常使用的值对你很有帮助。在典型的一天采样时间或一个星期采样时间中，你很可能涉及到一些重要的批处理。务必确定捕获这些活动，并且理解这些操作和可能与这些批处理运行相关限制的时间周期。
搜集完SQL后，你可能发现需要关注的语句很多。这时，考虑每一种语句的单独目标很重要。对于OLTP环境，你可能打算考虑查询的频繁程度，因为有很多的用户可能使用它。对于批处理环境，要考虑的是任务完成的时间长短或资源消耗的多少。
这时，删除索引存在一些问题。你可能发现你的应用不太需要特定的索引。这可能是一个要解决的难题，如同这可能会代表对产品的原始计划表的变动。正如前面提到的，首先要确定你的供应商。这里存在一些原因，某些索引可能不再需要，你也不必管理它们。但是可能还有一些索引是用来支持一些模块的查询，而你并没有购买这些模块。即使你以后计划购买这些模块，你也肯定能在实施之前创建这些索引。
这里有一些情况，在套装应用软件代码中写的查询本身需要改善。对于一些数据库，基本上需要重写代码。如果你的数据库是Oracle，还有点希望。"Outline"特征使你能够改变一些SQL的执行计划，而不必要重写SQL本身。。通常，一个查询将送达数据库，并且如果相关的执行计划没有在缓存中，这时优化器将会创建一个执行计划。对于套装应用软件，我们对改善不能变更的源代码比计划稳定性更感兴趣 。你能够创建执行计划的大纲，这个计划比原始地编写查询语句优先级高。
文章来源于领测软件测试网 https://www.ltesting.net/
