laozhu、zhulch，提到这两个ID，相信大家已经知道谁了吧？不必多言，收藏吧。

Oracle Blog上的地址：http://blogs.oracle.com/longchun/

大家已经知道，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，与常规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年后，在性能优化领域将需要从更高处审视整套系统。

当您的团队开始谈论BPM时，您可能会想起BPEL。是的，在R12中，有一种更独特的流程管理技术被推荐给用户，但是Workflow依旧处于一个非常关键的位置。我之前曾罗列过11i中的几个标准的工作流，它们在控制业务流程方面起到了有效的作用。如果光看到这些，您可能把工作流等同于审批流程了，事实上这是非常片面的理解。现在，请打开你的浏览器（我是指11i中的），进入采购超级用户（或者其它职责），选择“流程”，如下图：

直接将流程和操作有机集成了。这也是一种工作流的应用。当然，也许您早知道这个功能并开始使用了。我也认同，把一些需要控制点的业务流程放在浏览器中，是一种不错的主意。这个和单据等审批流程类似，可以控制各个功能的执行时机。这些流程和审批层次一样，都是需要IT部门预先分析、设计并定义好的，但是如果用户，他可能刚入职，也可能子公司给他分配了新的角色，作为集团总部的您如何管理子公司各用户权限的分配呢？点击Web页面右上角的首选项，看到如下的内容：

如文字所示，“请求访问”就是用于自行申请权限（职责）的。回忆之前介绍用户层级管理时提到的，Provision Services和Self-Service and Approvals同样也用到了工作流。

以上都是除了审批之外的非典型工作流应用。只要您的业务中存在规则（rule-based），那么就可以使用工作流。还有很多地方可以发现工作流的应用，这里不一一举例了。大致划分的话，可以发现下面几个领域会用到工作流：

1. 审批。比如采购订单审批，另有一些场合会使用AME。
2. 任何有规则，需要控制流程的场所。比如进行复杂数据处理时，利用工作流非常直观的设计界面来设计处理流程，而不是塞到一段冗长的PL/SQL代码中。
3. 业务事件。比如某些删除或更新操作可能需要通知其他系统，这时可以考虑订阅该事件，并实施特殊的逻辑。
4. 异构系统的同步。可以将工作流和业务事件组合使用，在处理异构系统的数据同步时非常有用。比如您可能需要某个关键点触发一条手机短信。
5. 发邮件。工作流的邮件功能已经非常强大，可以发HTML格式的邮件，也可以发附件。
6. 投票。

如果您有心去统计，会发现11i中工作流的影子遍布在每个角落。工作流并不难懂，掌握了它，对理解11i内部工作机制有非常大的帮助。

相比于11i，R12在专家资格认证上并没有太多变化，依旧有财务顾问和分销顾问，新增了ASCP（高级供应链）专家认证，但是在系统方面取消了工作流专家认证。事实上，在功能本身上并没有太大的区别，所以熟悉11i的也可以很快适应R12。

目前在国内，OCE(Oracle Certified Expert，Oracle认证领域专家)认证并不流行，至少在市场上和OCP没法比，甚至对于Partner，也取消了实施资格的要求。不过在国外，倒是经常看到很多人谈及OCE。价钱上，OCE认证倒是比OCP贵出不少。

证书样例：

这是我的11i OCE证书，手机拍的，效果不是很好。和OCP一样，也是一张证书和一张名片大小的卡片。

Logo:

拿到证书后，就可以将OCE的Logo放到名片、履历、网站或者其它你想放的地方了。

等R12的专家认证正式发布后，我再去弄一张来秀秀。不过，供应链和财务顾问两项专家认证也需要Hand-On Course，目前不知道价格，如果也上万就算了，便宜的话可以考虑去吃吃螃蟹的。

Just for fun

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应用的整体运行性能，并且操作简便，从这个角度来讲，是绝对的不可多得的好工具。

1. 定义请求类型(可选)

Navigate: Concurrent -> Program -> Types

并发请求根据执行时间，大致可以分为：快速响应和长时间执行两种。对于要求快速响应的并发请求，如果目前系统中的标准管理器同时处理数量已达上限，则不论新的请求响应时间有多短暂，它必然地处于待定状态，只有等有空闲资源时，根据预先定义的规则才可能开始被执行。

将并发请求人为分组，可以为之后制定满足需求的执行规则。比如定义两种并发请求类型：

• Quick， 快速响应的并发请求
• Long-Time， 长时间运行的并发请求

2. 定义组合规则(可选)

Navigate: Concurrent -> Manager -> Rule

管理器定义窗口可以定义特殊规则，但是组合规则更方便、简洁。两者的定义方式是相同的。

• Include，包含符合条件的请求，可以按Type来区分，比如根据节点，根据并发程序名称，或者按照用户名等。
• Exclude，排除。该优先级高于Include，可以覆盖Include中的条件。

3. 定义工作班次(可选)

Navigate: Concurrent -> Manager -> WorkShifts

根据系统运行状态，可以根据系统繁忙时间和相对空闲时间合理安排系统资源。

4. 定义并发管理器

Navigate: Concurrent -> Manager -> Define

该界面用于定义我们用于处理特殊并发请求的管理器。

• Type：Concurrent Manager
• Program Library: 选择FNDLIBR
• Cache Size: 每次抓取的待处理并发请求数量，默认为3。如果执行时间长，需要及时调整优先级，则将该数值设置为尽量小；如果并发请求执行时间短、数量多，则该数值可以适当调大。
• Specialization Rules: 选择Include步骤2定义过的组合规则。

Work Shifts 界面根据系统资源状况选择合适的进程数：

5. 将并发程序分组

Navigate: Concurrent -> Program -> Define

在并发程序定义界面，将Request Type选择为步骤1定义过的组。

根据之前定义的组合规则，所有分配到该组的并发请求，都将可能由自定义的并发管理器管理。

P.S：只所以说“可能”，是因为标准管理器会处理任意的、所有的并发请求，除非为标准管理器指定了特殊规则，但是Oracle不建议这么做。

服务器信任级别

按用户来分，Web Server可能用于内部管理、普通员工和外部人员，不同的用户的登录方式和用途都可能不同，比如普通员工可能通过公司VPN访问，而外部人员——比如供应商，或其他客户——则可能直接通过公网访问。Oracle应用产品存在一种机制，可以根据不同Web Server来区分访问级别。通过这种划分，可以针对性的提供或屏蔽部分敏感功能和数据。

1. Administrative 授信级别最高，所有的链接都被认为是安全的，并且可以访问高度敏感的信息。
2. Normal 普通级别，通常是公司防火墙内部员工，使用普通的功能。
3. External 外部人员，通常是供应商或客户，也可能处于公司防火墙外部的员工，这些链接被认为是不够安全的。

Web Server通过配置文件Node Trust Level来设置该服务器的信任（安全）级别，中间层通过读取该配置文件来确定当前服务器的信任级别，从而判断哪些职责是允许访问的。该配置文件值默认为Administrative。

职责信任级别

职责的信任级别通过配置文件Responsibility Trust Level来确定，也共有三级：

1. Administrative
2. Normal
3. External

三个职责信任级别分别对应三个服务器信任级别，职责信任级别等于或低于服务器信任级别的才能正常使用。如Administrative信任级别的职责可以用在同样级别的服务器上，但是External信任级别的职责则不行。

通过职责来限制功能和数据访问是最简单的方式，但是当用户群体数量较大时，可以利用信任级别来委派管理。

• 安全控制 (包括功能限制、数据屏蔽）
• 用户管理（自助权限申请、管理权限委派等）
• 审计（审计用户行为和数据变更历史）
• 打印机配置
• OAM(Oracle应用管理器的常规操作，比如系统状态监控）
• 诊断操作
• 管理并发程序和报表
• 维护并发管理器
• 工作流管理（这是专门的领域，包括工作流组件、业务事件等）
• 深刻理解弹性域（包括说明性弹性域和键弹性域）
• 熟悉技术架构和各组件
• 熟悉预警

可能的，你需要接触系统更底层的东西，以下是不一定需要去做，但是要求了解的：

• 基本的系统配置
• 应用Patch和维护应用系统
• 熟悉各类二次开发（如开发工具，个性化）
• 全球化机制
• 各类导入导出工具

以上知识如果不仅仅是作为普通用户，更是作为高级用户来使用，那才可以更深刻的理解EBS的各功能。做为系统管理员，这些都必须非常熟悉，而做为合格的实施顾问，不一定精通这些，但是了解它们也是必要的。

事实上，通过个性化主页，可以让菜单看上去和Form中的效果一样。如下：

EBS主页导航栏有两种模式，分别为“树”和“平板”模式，默认为“平板”模式。调整显示模式需要几步简单的操作：

1. 为用户设置配置文件Personalize Self-Service Defn值为Yes。登录后点击主页右上角的Personalize Page。

2. 启用完整视图。

3. 选择responsibilityRow。

4. 在Function:Applications Home Page级别上将Rendered设置为false，会有警告，不理它，点击Apply。然后将appsNavTreeRow中的Rendered设置为true。

返回主页，就可以看到和Form一样的树状菜单了。