《优化ERP应用》word版.doc

优化ERP应用概览尽管普遍流行的说法是不大可能优化商业套装软件性能，但仍有一些机会对它进行调优。如果这些高级应用没有满足性能期望和服务等级协议（SLA），那么你的业务可能失去关键的成长机会或者浪费资金。虽然不好理解整个产品给企业和通过它的生命周期所能提供的东西，但有了正确的理解，时间和资源限制，你的团队就能够改善复杂关键应用的性能，而不必威胁到license或供应商的维护协议。介绍这篇文章讨论了一些优化商业套装软件的机会。负责可接受应用性能的应用管理团队成员可能是这篇文章讨论受益最多的。这篇文章中主要集中在数据库调优，所以数据库管理员（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本身。通常，一个查询将送达数据库，并且如果相关的执行计划没有在缓存中，这时优化器将会创建一个执行计划。对于套装应用软件，我们对改善不能变更的源代码比计划稳定性更感兴趣 。你能够创建执行计划的大纲，这个计划比原始地编写查询语句优先级高。Oracle提供一些基本的大纲管理，但你必须首先确定SQL的最佳重写计划。有经验的SQL调优人员能够为你做这些工作。你愿意使这个过程自动化吗？市场上有一些工具能帮助你转换SQL，并且提供易用的大纲管理能力。在所有的例子中，应该理解你有权改善套装应用软件基本代码的性能。你只需确保你选择的方式没有危及你的应用及供应商的立场。客户化客户化是供应商提供全套功能的最佳尝试。你的公司购买的套装应用软件可能没有足够的业务专业知识，但能自动化地进行业务处理。灵活地适合你业务的特有需求是很重要的。前面已经讨论了一些客户化的分支：供应商不提供产品支持，客户化需要形成文档，也需要维护这些改变和在改变过程中的投资，使得通过升级保持改变能顺利进行。对于一些公司，根据Gartner，通常客户化的价格是实施套装应用软件的20以上。你着手进行客户化过程时是怎样影响你改善应用性能的能力？选择有很多，可以是你自己内部进行这些一般改变的团队，或者是供应商提供的工具，或者雇佣专门的咨询人员。供应商通常是一个服务公司，就像应用软件开发商那样。如果这些定制的源代码是供应商自己的雇员做的，那么你的担心就会少点。然而，当咨询人员走了，并且过了一段时间之后它们的工作并没达到想象中的那样，那么你可能还是跟以前一样，好像处理原始的源代码。简单地理解客户化中哪些部分是你优化的，哪些不是，这项任务可能是一个挑战。我们无法注重那些是重要的或者同你的供应商一起工作以了解这些分界线解。让我们假设你处理的是你自己的代码。无论是内部人员或者外面的咨询人员编写代码，这都无关紧要。你制定客户化的需求规范，支付相关的开发费用，所以你的责任就是确保它能按照你的标准工作。这个过程应该是任何一个开发项目都有的。时间、工具和资源应该都是工程计划中的预算。从设计到交付，都必须考虑到性能影响。代码整合套装应用软件很少单独运行。通常地，它必须与其它商业套装应用软件或者已有的应用系统通信。这就意味着它们将是一些集成的形式，与应用数据库交互。这能通过各种各样的方法实现，并且所选的方法将影响到系统的性能。你将怎样把这些不同的应用连接在一起呢？你能够选择企业应用集成（EAI）和面向服务架构（Service Oriented Architecture）。最后的选择当然是自己完全创建一个了。对于EAI解决方案，你要做的大部分是不同的客户化代码。尽管EAI供应商花费了巨大的努力，对于它们真的没有办法预测应用间交互的复杂性。对于外部整合，唯一真正可能的是应用安装了不同的解决方法，而完全没有客户化。这种情况很少，但我们应该假设将花费相当多时间和成本用于把这些应用绑定在一起。正如客户化的例子，实施路径能够从内部团队或咨询人员来进行。所有关心的和涉及的调优问题都在这里。而特别有意思的挑战是你可能处理两个或更多的不同供应商。它应该及时注意到，这些供应商经常互相竞争，并且通常不会融洽地相处。如果事情还不够有意思，考虑你还要把EAI供应商的咨询顾问包括进来。在所有的情况中，团队管理者和供应商的关系是关键。对于大部分情况来说，我们必须继续强调性能管理仍然是个人的挑战。应用整合的影响最能支持这种论点。如果它方的团队不太好管理，那么转向你自己的团队。比较常见的情况是需要整喝套装应用软件和内部已有应用程序。当你的SAP和PeopleSoft应用有很完善的文挡，内部开发应用的文挡却残缺不全。在这个混合中，你可能有一个比较好的机会，跟内部的人一起工作。既然你要负责性能影响，严格的和受过训练的实施团队很关键。建立性能基准指标，并且确保你的团队理解它们的重要性。这个建议对于内部和外部的整合团队都适用。对于性能，理解调优目标很关键。最关键的问题是确定交互的种类。编码和用于日常事务数据上传的性能优化目标明显是批处理工作的类型。获得整个结果集和移动它是关键。另一边，如果你需要实时更新不同的系统，你可能打算在每个事务发生时继续工作。两阶段提交是否有顺序？通常老的系统没有新系统的底层硬件能力强大。在这些情况中，你应该清楚地知道哪种性能问题跟哪种平台相关。对于早期信息系统的应用，给数据集编写查询可能不合适，这些数据集可能是在内存中发现的，而早期应用系统是在存储速度缓慢的设备中发现的。调优性能是你的权力，所以坚持正确的方法交付系统给相关团体。报表从性能的角度出发，商业智能（BI）和报表解决方案是你应用架构具有挑战的一部分。这些工具的特点是它们体现了一些非常强大的方式，用于捕获有意义的关系和信息。不幸的是，捕获这些有意义的关系的过程对于你的应用性能可能是致命的。通常地，人们将使用从BI供应商获得的工具连接目标数据库，并且搜索所需的信息。我们需要理解的是报表产生过程大部分由手工完成，独立于所需的数据库种类。换句话说，不可能有那么多的优化用于各种数据库。另一个挑战是捕获表的过程，这个表是报表工具用户需要查询的。因为一些套装应用软件有大量的复杂表，在查询过程中用户需要等待非常长时间。现在，如果每个人只是简单地运行数据仓库或数据中心，那么没什么难的，这些数据仓库或数据中心间接地跟你的主要应用绑定在一起。不幸的是，通常不是这种情况，繁忙的执行请求访问大部分最新的数据。而且，我们看到组织作为应用性能挑战知道它本身。尽管你负责维护应用性能，如果执行请求实时访问这些数据，这时你必须响应它的请求。很有可能，这些随机点击只能引起很短的业务中断，而会获得重要的返回结果。这种特别的报表情况几乎不可能调优，但它们能够控制。有工具能够捕获和最小化这些影响，但这可能终止查询或延迟查询。对它的性能改善微乎其微。有可能通过计划任务和命令行重复运行报表。要这么做，我们将访问报表里的代码。一些供应商会允许你查看它们的报表，并且自己可以手工修改。在这些实例中，你或你的团队可能需要一定的技巧、工具和时间来做这项工作。你不能直接改变那些查询吗？如果在Oracle运行，想想那些与大纲一起工作的工具的使用。前面已经讨论了大纲的工作情况和优势。当使用报表和BI解决方案，考虑它们存储报表和可修改查询的能力。如果不是这样的话，看看Oracle数据库的大纲。版本升级除了主要套装应用软件的初始化，几乎没什么事主要组件的升级如此有影响。你的组织越依赖应用，对业务影响的改变越重要。而升级不总是在你的控制范围之内。作为一个很好的藉口，供应商可能需要你作一定的升级用于保护里面的数据。也可能因为供应商希望节省技术支持和维护成本。不管什么情况，你公司之外的人决定你将需要做的一些重要的改变。这意味着你需要做很多事。其中的一些可能是好的，它非常可能意味着大量投资于你的IT小组。它体现在时间花费、高昂的咨询成本和它可能意味着业务过程的中断，而这些业务过程是你一直在努力进行改善的。这篇文章之前讨论的每个地方可能是紧密的。最大的挑战是业务的发展变化和应用的客户化，对升级中的下一步没有多少负面影响。强烈推荐你推行一个正确的策略，涉及过程，培