Fans Or Not

当我面对一个并发请求优化的需求时，常常先问自己，为什么我又要面对这个情况？我们为什么不能在设计时就避免出现今天这种情况？我深刻理解优化是持续的过程，但是问题关键常常在于，程序在设计时并不考虑将来是否需要优化，或者就是留了一个很小的余地。 大家已经知道，Oracle Apps对各组件都可以进行相应的Trace（具体方式可自行搜索本站归档文章），即跟踪SQL执行情况。对于并发请求的跟踪方式曾经在《跟踪(Trace)并发请求》介绍过，操作方式很简单，就是在运行并发请求前先设置为“启用跟踪”。此处介绍一个实际的并发请求诊断案例。 操作步骤： 启用跟踪(并发 -> 方案 -> 定义)。在并发程序定义界面，找到目标并发程序，选上“启用跟踪”选项。 提交并发请求。 在UDUMP目录下找到对应的trace输出文件。 此时生成的trc文件有很多工具可以分析，根据目标不同选择适用的工具。这里介绍四种常用工具和方式： 使用tkprof。这是Oracle官方工具，简单、有效而强大。 tkprof test_ora_1239_XZB_CR7665696.trc xzb.txt sort=fchela 关键是这里的排序参数sort，比较常用的排序方式是按照消耗时间倒序。通常，查到消耗时间最大的那句SQL，基本上就找到了问题所在。   这是第一句SQL的统计数据，看上去，解决了它，问题就基本解决了。 使用TVD$XTAT。由《TOP》作者开发，在性能诊断方面非常著名、实用的工具。具体使用可以参考工具说明文档，或者《TOP》一书中的介绍。   这是一个概览界面，可以再深入分析各部分数据。 使用SwingBench Trace Analyzer。这是我所见的最傻瓜化的有GUI界面的trc分析工具，只要打开trc文件，你就可以知道问题出在哪里了。当然，傻瓜式自然有傻瓜式的局限，该工具的强大在于方便，也仅仅在于方便，强烈推荐给初级用户使用。 本站以前推荐过这个工具，请参考文章：《Trace分析工具：SwingBench Trace Analyzer》。 使用Oracle Trace Analyzer。这个工具实际上是tkprof的另一个版本，以一种更简单、直观的方式来分析trc文件，同样的，也推荐给初级用户使用。 本站以前推荐过这个工具，请参考文章：《Trace Analyzer》。 到此，你基本上已经找到了问题所在，至于如何让你的程序更有效率，则是另外更深的领域了。 在这个案例中，将运行时间从3小时降到6分钟，而所有修改的代码加起来不到20个字符。事实上，分析trc文件的工具本身并不是最重要的，重要的是找到问题症结所在，然后是你所采取的优化手段。有些时候，优化一句SQL就可以了，但是很多时候，可能需要重新设计你的程序，尤其是那些超大的SQL，它们真的有必要这样设计吗？ 我一直说，优化是系统工程，大处从业务着手（如何设计功能和数据流直接关系到后面的优化余地），小处从架构着手（2-tier？N-tier？），微处从程序着手。业务(功能)顾问、技术顾问和DBA，都应该参与进来。当然，目前国内，这样具备各角色充分协作能力的团队很少，但是必须首先培养这样的意识。

之前做了个列表：EBS管理员应当掌握的知识，这里的管理员要和应用DBA区分开来，虽然实际上，很多中小型企业里的IT部门并没有对此做出区分。常规的DBA和EBS DBA工作内容有所不同，EBS是OLAP系统，但是又和大多数其他的OLAP系统有所不同，用户需要从这里实时查看报表，但同时后台又运行着大量的任务，在任何一个时间段，都可能有非常耗资源的批处理程序被启动，并且这些任务不在你的控制之中。 你或许已经看过很多有关优化的文章了，但是只有一个环节永远是最可靠的，那就是你的实践。当亲身实践过后，搜索的范围就会大大缩小。记住一句话，不要轻易尝试他人提供的方式，除非你仔细看过自己的系统分析报告。为了节省时间，作为一名没有优化经验的EBS DBA，与常规DBA工作相比，可能更需要关注以下内容： 熟悉并发管理器。在系统资源耗费比例上，这是绝对值得关注的部分，系统多大部分任务都通过并发请求来执行。对于深入的技术细节，没有任何现成的文档可以帮助你，但是官方文档已足够应付常规的优化工作。 理解EBS并不是真正意义上的OLAP系统。有大量的用户对数据的处理操作，实际上都在接口中进行，而接口则通过提交并发请求来进行。在日常业务中，你无法知晓何时会出现一个大量数据处理的批处理程序，用户随时可能提交多个非常消耗资源的批处理程序。你应该预估到这种情况对系统运行造成的影响。有时候，理解业务需求，从业务角度来安排此类程序的执行，会让业务和系统都轻松很多。 不要轻易应用Patch。EBS系统永远存在解决不完的BUG，在充分理解解决BUG的必要性，以及充分而全面的测试后才可以考虑应用到正式环境。否则，你将承受影响业务操作的风险，也可能导致系统其他功能的异常，而这异常会占用你的工作时间。记住，在任何一次应用Patch之前，你都应该预估到可能带来的影响，并提前做好准备。 记录Patch历史。尽管系统记录了每次Patch应用的时间、操作和内容，但是它并不知道你为什么需要它。需要去记录该Patch期望能解决的问题，应用后出现的新问题以及业务的影响。Oracle Support解决问题时会尝试先了解系统最近有没有什么变动。 定期重建EBS索引。EBS中存在大量的索引，约有4万个。某些表可能有频繁的DML操作，你需要注意到这种表，并设置相应的索引的重建计划。重建索引可能耗费很多时间，需要安排一个在线用户最少的时间段来进行。 谨慎添加客户化索引。EBS本身是优化过的，并不是设计来仅供一两年使用的。很多性能问题实际上是IT人员自己造成的。有时候，你可能注意到某个程序执行效率很低，原因是没有走相关的索引，但是记得，索引并非越多越好，除非你非常熟悉相关应用，知道自己在做些什么，不然还是交给Oracle Support为好。一个未经分析的索引，可能导致系统性能出乎意料。 理解应用Patch是如何进行的。除了理解它本身的工作原理之外，还需要了解它带来的影响，比如Patch是如何改变你本来工作的非常好的某段SQL的执行计划的？你需要知道Patch后，某个批处理程序突然变慢的原因。 理解预警。理解其工作原理，清楚的知道利弊。比如事件预警会创建什么样的Trigger。 熟悉Apache、UNIX Server、OAS等，这些一般情况下不会成为性能优化的优先目标，但是在今后更深入的工作中会考虑到。 这里并没有列出一个普通DBA应当参与的工作，比如监控回滚段、分析Statspack报表、捕获并提出性能恶劣的客户化SQL的优化建议以及其他份内工作。App DBA作为专业的工作职位自然有其特殊性，比如为什么你不能使用DBMS_STATS做统计？为什么不允许KEEP Pool？ Oracle EBS 本身的技术架构已经可以让合格的DBA大展身手，不论从数据库层还是应用层。不要把注意力全部集中到SQL优化上，尽管这可能就是90%的问题所在，但是它通常由客户化引起。对于纯标准化的EBS应用而言，运行5年后，在性能优化领域将需要从更高处审视整套系统。

很多人经常面对一种场面，就是在查找某环节的问题时，惊奇的发现自己又得面对工作流。虽然有点排斥，但是，您必须面对它，无处可避。本文所言的工作流通常是指Oracle Workflow，这是数据库内置的组件，在EBS系统中它被发扬光大了。不论哪个版本，工作流都是一个核心的组件，在11i系列认证中，它甚至作为独立的一块内容。 当您的团队开始谈论BPM时，您可能会想起BPEL。是的，在R12中，有一种更独特的流程管理技术被推荐给用户，但是Workflow依旧处于一个非常关键的位置。我之前曾罗列过11i中的几个标准的工作流，它们在控制业务流程方面起到了有效的作用。如果光看到这些，您可能把工作流等同于审批流程了，事实上这是非常片面的理解。现在，请打开你的浏览器（我是指11i中的），进入采购超级用户（或者其它职责），选择“流程”，如下图： 直接将流程和操作有机集成了。这也是一种工作流的应用。当然，也许您早知道这个功能并开始使用了。我也认同，把一些需要控制点的业务流程放在浏览器中，是一种不错的主意。这个和单据等审批流程类似，可以控制各个功能的执行时机。这些流程和审批层次一样，都是需要IT部门预先分析、设计并定义好的，但是如果用户，他可能刚入职，也可能子公司给他分配了新的角色，作为集团总部的您如何管理子公司各用户权限的分配呢？点击Web页面右上角的首选项，看到如下的内容： 如文字所示，“请求访问”就是用于自行申请权限（职责）的。回忆之前介绍用户层级管理时提到的，Provision Services和Self-Service and Approvals同样也用到了工作流。