数据库层
    数据库层又是什么样子了？令人惊奇的是，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 和 系统分析师的角色。