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