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