著名Oracle ERP技术顾问朱龙春的博客,也是Oracle Blogs历史上第一位中文博客(今日首发)。
laozhu、zhulch,提到这两个ID,相信大家已经知道谁了吧?不必多言,收藏吧。
Oracle Blog上的地址:http://blogs.oracle.com/longchun/
Jun 17 2009
著名Oracle ERP技术顾问朱龙春的博客,也是Oracle Blogs历史上第一位中文博客(今日首发)。
laozhu、zhulch,提到这两个ID,相信大家已经知道谁了吧?不必多言,收藏吧。
Oracle Blog上的地址:http://blogs.oracle.com/longchun/
Jun 17 2009
当我面对一个并发请求优化的需求时,常常先问自己,为什么我又要面对这个情况?我们为什么不能在设计时就避免出现今天这种情况?我深刻理解优化是持续的过程,但是问题关键常常在于,程序在设计时并不考虑将来是否需要优化,或者就是留了一个很小的余地。
大家已经知道,Oracle Apps对各组件都可以进行相应的Trace(具体方式可自行搜索本站归档文章),即跟踪SQL执行情况。对于并发请求的跟踪方式曾经在《跟踪(Trace)并发请求》介绍过,操作方式很简单,就是在运行并发请求前先设置为“启用跟踪”。此处介绍一个实际的并发请求诊断案例。
操作步骤:
此时生成的trc文件有很多工具可以分析,根据目标不同选择适用的工具。这里介绍四种常用工具和方式:
tkprof test_ora_1239_XZB_CR7665696.trc xzb.txt sort=fchela
关键是这里的排序参数sort,比较常用的排序方式是按照消耗时间倒序。通常,查到消耗时间最大的那句SQL,基本上就找到了问题所在。
本站以前推荐过这个工具,请参考文章:《Trace分析工具:SwingBench Trace Analyzer》。
到此,你基本上已经找到了问题所在,至于如何让你的程序更有效率,则是另外更深的领域了。
在这个案例中,将运行时间从3小时降到6分钟,而所有修改的代码加起来不到20个字符。事实上,分析trc文件的工具本身并不是最重要的,重要的是找到问题症结所在,然后是你所采取的优化手段。有些时候,优化一句SQL就可以了,但是很多时候,可能需要重新设计你的程序,尤其是那些超大的SQL,它们真的有必要这样设计吗?
我一直说,优化是系统工程,大处从业务着手(如何设计功能和数据流直接关系到后面的优化余地),小处从架构着手(2-tier?N-tier?),微处从程序着手。业务(功能)顾问、技术顾问和DBA,都应该参与进来。当然,目前国内,这样具备各角色充分协作能力的团队很少,但是必须首先培养这样的意识。
Jun 12 2009
之前做了个列表:EBS管理员应当掌握的知识,这里的管理员要和应用DBA区分开来,虽然实际上,很多中小型企业里的IT部门并没有对此做出区分。常规的DBA和EBS DBA工作内容有所不同,EBS是OLAP系统,但是又和大多数其他的OLAP系统有所不同,用户需要从这里实时查看报表,但同时后台又运行着大量的任务,在任何一个时间段,都可能有非常耗资源的批处理程序被启动,并且这些任务不在你的控制之中。
你或许已经看过很多有关优化的文章了,但是只有一个环节永远是最可靠的,那就是你的实践。当亲身实践过后,搜索的范围就会大大缩小。记住一句话,不要轻易尝试他人提供的方式,除非你仔细看过自己的系统分析报告。为了节省时间,作为一名没有优化经验的EBS DBA,与常规DBA工作相比,可能更需要关注以下内容:
这里并没有列出一个普通DBA应当参与的工作,比如监控回滚段、分析Statspack报表、捕获并提出性能恶劣的客户化SQL的优化建议以及其他份内工作。App DBA作为专业的工作职位自然有其特殊性,比如为什么你不能使用DBMS_STATS做统计?为什么不允许KEEP Pool?
Oracle EBS 本身的技术架构已经可以让合格的DBA大展身手,不论从数据库层还是应用层。不要把注意力全部集中到SQL优化上,尽管这可能就是90%的问题所在,但是它通常由客户化引起。对于纯标准化的EBS应用而言,运行5年后,在性能优化领域将需要从更高处审视整套系统。
Jun 01 2009
很多人经常面对一种场面,就是在查找某环节的问题时,惊奇的发现自己又得面对工作流。虽然有点排斥,但是,您必须面对它,无处可避。本文所言的工作流通常是指Oracle Workflow,这是数据库内置的组件,在EBS系统中它被发扬光大了。不论哪个版本,工作流都是一个核心的组件,在11i系列认证中,它甚至作为独立的一块内容。
当您的团队开始谈论BPM时,您可能会想起BPEL。是的,在R12中,有一种更独特的流程管理技术被推荐给用户,但是Workflow依旧处于一个非常关键的位置。我之前曾罗列过11i中的几个标准的工作流,它们在控制业务流程方面起到了有效的作用。如果光看到这些,您可能把工作流等同于审批流程了,事实上这是非常片面的理解。现在,请打开你的浏览器(我是指11i中的),进入采购超级用户(或者其它职责),选择“流程”,如下图:
直接将流程和操作有机集成了。这也是一种工作流的应用。当然,也许您早知道这个功能并开始使用了。我也认同,把一些需要控制点的业务流程放在浏览器中,是一种不错的主意。这个和单据等审批流程类似,可以控制各个功能的执行时机。这些流程和审批层次一样,都是需要IT部门预先分析、设计并定义好的,但是如果用户,他可能刚入职,也可能子公司给他分配了新的角色,作为集团总部的您如何管理子公司各用户权限的分配呢?点击Web页面右上角的首选项,看到如下的内容:
如文字所示,“请求访问”就是用于自行申请权限(职责)的。回忆之前介绍用户层级管理时提到的,Provision Services和Self-Service and Approvals同样也用到了工作流。
May 23 2009
因为众所周知的原因,R12的部分考试还处于Beta Exam阶段,比如我所关注的系统管理专家认证的测试考试期间将持续到2009年6月30日。按照常例,Beta Exam结束后数周内即可推出正式认证考试(供应链专家认证的测试版考试已在1月31日结束)。
相比于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
May 02 2009
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版本为例):
执行完毕后,output目录下将生成HTML格式的诊断报告,和一个zip格式的压缩包,该压缩包用于提交到Oracle支持中心。
虽然在数据库性能专项诊断上它和statspack相比可能还有不小差距,但是它的设计出发点是提供一种概览式报表来了解Oracle应用的整体运行性能,并且操作简便,从这个角度来讲,是绝对的不可多得的好工具。