Oracle Fans

当我面对一个并发请求优化的需求时，常常先问自己，为什么我又要面对这个情况？我们为什么不能在设计时就避免出现今天这种情况？我深刻理解优化是持续的过程，但是问题关键常常在于，程序在设计时并不考虑将来是否需要优化，或者就是留了一个很小的余地。

大家已经知道，Oracle Apps对各组件都可以进行相应的Trace（具体方式可自行搜索本站归档文章），即跟踪SQL执行情况。对于并发请求的跟踪方式曾经在《跟踪(Trace)并发请求》介绍过，操作方式很简单，就是在运行并发请求前先设置为“启用跟踪”。此处介绍一个实际的并发请求诊断案例。

操作步骤：

1. 启用跟踪(并发 -> 方案 -> 定义)。在并发程序定义界面，找到目标并发程序，选上“启用跟踪”选项。
2. 提交并发请求。
3. 在UDUMP目录下找到对应的trace输出文件。

此时生成的trc文件有很多工具可以分析，根据目标不同选择适用的工具。这里介绍四种常用工具和方式：

1. 使用tkprof。这是Oracle官方工具，简单、有效而强大。

   tkprof test_ora_1239_XZB_CR7665696.trc xzb.txt sort=fchela

   关键是这里的排序参数sort，比较常用的排序方式是按照消耗时间倒序。通常，查到消耗时间最大的那句SQL，基本上就找到了问题所在。

    
   这是第一句SQL的统计数据，看上去，解决了它，问题就基本解决了。

2. 使用TVD$XTAT。由《TOP》作者开发，在性能诊断方面非常著名、实用的工具。具体使用可以参考工具说明文档，或者《TOP》一书中的介绍。

    
   这是一个概览界面，可以再深入分析各部分数据。

3. 使用SwingBench Trace Analyzer。这是我所见的最傻瓜化的有GUI界面的trc分析工具，只要打开trc文件，你就可以知道问题出在哪里了。当然，傻瓜式自然有傻瓜式的局限，该工具的强大在于方便，也仅仅在于方便，强烈推荐给初级用户使用。

   本站以前推荐过这个工具，请参考文章：《Trace分析工具：SwingBench Trace Analyzer》。

4. 使用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工作相比，可能更需要关注以下内容：

1. 熟悉并发管理器。在系统资源耗费比例上，这是绝对值得关注的部分，系统多大部分任务都通过并发请求来执行。对于深入的技术细节，没有任何现成的文档可以帮助你，但是官方文档已足够应付常规的优化工作。
2. 理解EBS并不是真正意义上的OLAP系统。有大量的用户对数据的处理操作，实际上都在接口中进行，而接口则通过提交并发请求来进行。在日常业务中，你无法知晓何时会出现一个大量数据处理的批处理程序，用户随时可能提交多个非常消耗资源的批处理程序。你应该预估到这种情况对系统运行造成的影响。有时候，理解业务需求，从业务角度来安排此类程序的执行，会让业务和系统都轻松很多。
3. 不要轻易应用Patch。EBS系统永远存在解决不完的BUG，在充分理解解决BUG的必要性，以及充分而全面的测试后才可以考虑应用到正式环境。否则，你将承受影响业务操作的风险，也可能导致系统其他功能的异常，而这异常会占用你的工作时间。记住，在任何一次应用Patch之前，你都应该预估到可能带来的影响，并提前做好准备。
4. 记录Patch历史。尽管系统记录了每次Patch应用的时间、操作和内容，但是它并不知道你为什么需要它。需要去记录该Patch期望能解决的问题，应用后出现的新问题以及业务的影响。Oracle Support解决问题时会尝试先了解系统最近有没有什么变动。
5. 定期重建EBS索引。EBS中存在大量的索引，约有4万个。某些表可能有频繁的DML操作，你需要注意到这种表，并设置相应的索引的重建计划。重建索引可能耗费很多时间，需要安排一个在线用户最少的时间段来进行。
6. 谨慎添加客户化索引。EBS本身是优化过的，并不是设计来仅供一两年使用的。很多性能问题实际上是IT人员自己造成的。有时候，你可能注意到某个程序执行效率很低，原因是没有走相关的索引，但是记得，索引并非越多越好，除非你非常熟悉相关应用，知道自己在做些什么，不然还是交给Oracle Support为好。一个未经分析的索引，可能导致系统性能出乎意料。
7. 理解应用Patch是如何进行的。除了理解它本身的工作原理之外，还需要了解它带来的影响，比如Patch是如何改变你本来工作的非常好的某段SQL的执行计划的？你需要知道Patch后，某个批处理程序突然变慢的原因。
8. 理解预警。理解其工作原理，清楚的知道利弊。比如事件预警会创建什么样的Trigger。
9. 熟悉Apache、UNIX Server、OAS等，这些一般情况下不会成为性能优化的优先目标，但是在今后更深入的工作中会考虑到。

这里并没有列出一个普通DBA应当参与的工作，比如监控回滚段、分析Statspack报表、捕获并提出性能恶劣的客户化SQL的优化建议以及其他份内工作。App DBA作为专业的工作职位自然有其特殊性，比如为什么你不能使用DBMS_STATS做统计？为什么不允许KEEP Pool？

Oracle EBS 本身的技术架构已经可以让合格的DBA大展身手，不论从数据库层还是应用层。不要把注意力全部集中到SQL优化上，尽管这可能就是90%的问题所在，但是它通常由客户化引起。对于纯标准化的EBS应用而言，运行5年后，在性能优化领域将需要从更高处审视整套系统。

RDA，Oracle Remote Diagnostic Agent，是Oracle提供的一个系统信息收集和性能诊断工具，与之前介绍过的AWR和Statspack不同，它虽然也同样提供了数据库相关性能诊断信息，但主要还是用于其应用产品，提供了包括操作系统、网络、RDBMS和数据库运行信息等，因而它非常适用于Oracle应用产品的实施人员，可以快速地了解整个系统的关键性能数据。在提交SR时，Oracle也建议同时提交RDA诊断数据（RDA.RDA_<appname>.zip）。

RDA用Perl语言编写，可以在shell下以命令行方式执行。它拥有和OCM集成的版本，也有独立版本。OCM集成版本通过Oracle提供的一个补丁包来安装，独立版本则更为方便，解压后通过简单的步骤即可执行，它不需要安装到数据库。目前的最新版本是4.15，版本号经常更新，在Metalink上搜索Oracle Remote Diagnostic即可出现所有相关文档。

使用方式(以standalone版本为例)：

1. 解压rda.zip (也可能是rda.tar.gz，视你所下载的压缩档格式为定)。
2. 验证: rda.pl -cv
3. 安装: rda.pl -S （该步骤提供各项检测项，可以一路Enter使用默认值）
4. 执行: rda.pl -v
   

执行完毕后，output目录下将生成HTML格式的诊断报告，和一个zip格式的压缩包，该压缩包用于提交到Oracle支持中心。

虽然在数据库性能专项诊断上它和statspack相比可能还有不小差距，但是它的设计出发点是提供一种概览式报表来了解Oracle应用的整体运行性能，并且操作简便，从这个角度来讲，是绝对的不可多得的好工具。