从一个
普通
的Oracle DBA（Oracle数据库管理员）转变为Oracle Applications DBA（Oracle应用程序数据库管理员）
有两个内容你必须去弄清楚
第一个内容是如何成为一个Oracle Applications DBA（Oracle应用程序数据库管理员）
第二个内容是你要搞清楚Oracle应用程序背后的架构体系
也就是说你要明白诸如以下产品的结构体系
Oracle电子商务套件
Oracle
i数据库
Siebel产品等
本文首先讲述如何从一个普通的Oracle DBA转变为一个Oracle Applications DBA（Oracle应用程序数据库管理员）接着讲述一些Oracle应用软件架构方面的内容
如何成为Oracle应用程序数据库管理员
首先是角色的转变 Oracle Applications DBA（Oracle应用程序数据库管理员）对普通的Oracle DBA（Oracle数据库管理员）来说是一个很大的挑战拿Oracle EBS DBA（Oracle 电子商务套件DBA）来说不仅需要了解EBS的各个组件服务而且还要更主动和其他相关人员接触 一个Oracle Applications DBA（Oracle应用程序数据库管理员）不仅需要和其他DBA一样去负责managing sizingmaintaining和 tuning database这些日常的数据库管理的工作如果他的Apps database是OLTP系统的话他还需要监察wait和lock Oracle EBusiness Suite还有一些特性需要DBA去完成比如从外部资源里灌数据到Apps database里或支持开发人员从已有数据中提取数据
接着工作内容的转变 作为一个Oracle Applications DBA（Oracle应用程序数据库管理员）要想更好的对Oracle Application database做支持需要仔细记住以下几项
．网络上没有什么比较容易简单的文档让你去熟悉Apps DBA所以我建议去看帮助
．在你没有经过多次测试并且得到客户认可的时候不要去打补丁并且你要确信这个补丁解决了现有的问题而且没有带来其它新的问题
．记住Oracle Applications会有很多索引定期rebuild index会对性能有好处当然做这项工作应该在系统的空闲时间
．不要为了提高性能而在没有询问oracle Support前试着去增加额外的indexes如果你一定要去做那千万记住要有文档作记录因为在这之后你再打patch的时候它可能会把你做的修改自动复原
．知道怎么样是正确的打patch先计划打哪个patch然后取得patch接着打patch测试最后文档记录
．要知道任何时刻数据库都可能会有一些object 是invalid的你的一些操作也会增加invalid objects定期检查这些invalid objects的数量然后定期用utlrp去重新编译utlrpsqu在ORACLE HOME的rdbms/admin下需要用SYS运行在你的DB运行过程中如果碰到错误就可以先重新编译invalid objects如果没有解决问题再去递交iTAR(Internet created Technical Assistance Request)
．能看懂日志
．了解Apps database的环境包括操作系统和DB的当你对你的工作环境了如指掌后一切也就变得容易了那时你就是一个悠闲的Apps DBA了
另外对于APPS DB（应用程序数据库）来说你可能需要创建或拷贝（克隆）多个生产库以外的数据库比如测试和开发数据库当然需要多少数据库是由你的商业需求所决定的开发环境数据库是供开发人员进行reportPL/SQL等开发的这个环境可以在开发人员觉得数据已经不再满足开发需求的时候当然也可以在这个环境测试补丁（patches）当然最终使用patch的时候还需要在测试环境做测试因为测试数据库是和生产数据库环境最接近的（上面说的克隆cloning是一种将applications layer和database layer完全复制的一种方法）所以当你拥有这三个数据库的时候打patch的步骤是先development database再test database最后才在production database环境应用
构架应用体系
如果你研究过Oracle Forms使用过Application Server和Developer Suite来开发配置部署form和report并且曾经作为一名Oracle DBA经历过许多管理和维护的工作如patching和cloning的话那么你就已经能够掌握了OA %的内容Oracle Apps应该是这样的应用软件高速度低拖延的ERP应用软件使用Oracle所能提供的最好的web和数据库组件我说的对吗？实际上不完全对在的版本里你能看到应用服务器最早期的一个版本并且Oracle的版本还是
EBS环境最简单配置也包括两个服务器这两个服务器也就是我们熟知的两层数据库层和中间层也叫应用层数据库层就如字面的意思就是应用程序的后端数据库中间层就类似Application Server（应用程序服务器）
中间层
在中间层更确切的说运行在中间层上的还有几种服务所有的服务都不相同有OCJreport engineform等你能看到应用服务器(Application Server)存在于中间层另外还有Oracle应用程序具体的服务器总的来说有六种服务器存在于中间层和应用层它们是
&#; Web 服务器
&#; Forms服务器
&#; Reports 服务器
&#; Discoverer服务器
&#; 并发处理服务器
&#; Admin服务器
至于Application Server上面列举的其它服务器和Application Server性质不同的就是并发处理服务器了对于并发处理服务器我们可以认为它是一个助手的角色在EBS用户请求和数据处理过程中协调作业和过程另外如现代的Application Server上面列举的服务并不是每个都必须在相同的服务器上
我们可以类似的认为Oracle Apps配置就是对Forms 和 Reports 服务以及后端数据库的配置在app server 和数据库之间物理或者逻辑关系是什么样的？在Oracle应用程序世界里在中间层生成的文件能够有时是需要放到数据库层这些文件大多以文本文件的形式存在包括配置信息其他文件是与cloning相关的
下面的图标有助于说明每层的主要组成部分该图标来自Oracle Applications Concepts Release i的图如下图所示
在中间层有许多的父级目录特别要提到其中的两个这个两个在文档中一次又一次的看到它们就是APPL_TOP 和COMMON_TOP
数据库层
数据库层又是什么样子了？令人惊奇的是Oracle Apps数据库文件格式或许令人难以置信并不是由于它的复杂性而恰恰是一点都不复杂同样在父级结构中数据库有四种数据他们分别是数据索引系统和临时表空间位置你或许能看到所有的和数据库文件相关的数据都放在一个路径或者分区里所有的索引也是在一个路径下同样系统和临时表空间也是如此重做日志能够放在两个位置你或许看到上百的表空间都有一到两个文件你能看到四个表空间模型
说到重做日志和一般的重做操作我们肯定知道的一件事情就是在真实的DBA世界里我们希望重做日志存在快速磁盘中由于写入量的缘故你曾经在磁盘中放置一个控制文件吗？如果你没有看到控制文件在事务等待过程中并行写入那么看一看Oracle Apps安装过程情况就是这样的当前文档声称或者说分配重做日志缓沖区大小最好是MBOracle在MetaLink上有一个注释推荐Oracle Apps DBA将重做日志缓沖区设为MB
另外一个和一般数据库不同的地方就是必须要设置初始参数在初始文件中设置初始参数还不常见
在使用Oracle Apps时你不得不向你的OLTP或者DSS数据库打补丁的时候如何保证个的可靠性呢个的可靠性意味着每年只有分钟的停机时间好了虽然说没有这么严格但是仍旧有许多测试工作和质量保证工作需要完成为了更好的服务于最终用户你还需要了解些Apps的结构并且掌握专有名词的含义比如虽然你不需要掌握财务模块是如何实现的但是还是需要知道AR是借AP是贷GL是总帐这样你在遇到问题的时候就可能及时知道数据是怎么来的是那个模块该找什么人去沟通
你如何备份你的数据库？在EBS中数据库备份时非常直接的中间层组件就有一些复杂了庆幸的是Oracle开发了一个叫做Rapid Clone的工具步骤归纳如下
&#; 在每层运行基于perl的脚本语言（创建一个XML文件里面包含了配置信息不过对源系统不影响）
&#; 将每层的相关部分复制到目标系统
&#; 运行基于perl语言的config/clone脚本来重新配置环境或者每层的context文件
Applicationmiddle tierdatabase之间有着复杂的连接常常某一个地方出了问题却在其他地方上表现出来（有点象中医）或者说在一个地方出的问题影响到另一个地方又影响到其他然后最终影响到整体性能比如一个FORM 没有被正确执行而你作为一个DBA可能最先发现的是性能的下降这会让你很头疼另外在打补丁后原有的forms 或 reports也可能在执行上与打补丁之前有所不同了
最后我要说你现在接触和管理的是比你以前复杂的多的系统这套系统的每一个部分都不能单独来看一叶障目不见泰山遇到问题应该从整体思考一个Apps DBA是一个对这套系统每一部分都有所了解的人
结论
Oracle Applications DBA（Oracle应用程序数据库管理员）比普通的Oracle DBA（Oracle数据库管理员）门槛高了很了很多不仅要有处理数据库问题的能力还需要了解整个应用程序的构架从大处着眼整体考虑问题总之扮演者DBA 和 系统分析师的角色
