如何成为一名Oracle应用DBA

  今天在ITPUB上看了一篇文章“如何成为一名Oracle应用DBA”。文章简单的讲述了怎样从普通的DBA转变为应用DBA。其实对这个过程我也有些感触，毕竟亲自经过这个转换过程。跟确切的说应该是从UNIX系统管理员-》ORACLE DBA-》APPLICATION DBA。这里没有说是EBS DBA，因为除了EBS应用外还有WINDCHILL应用需要管理，所以统称APPLICATION DBA。刚进公司的时候我主要负责IBM小型机的管理，而当时跑在小型机上的应用是PTC的WINDCHILL系统，自然而然对WINDCHILL的架构及系统管理的部分就熟悉了。当时公司没有专门的DBA，而自己以前对ORACLE还算熟悉，所以DBA干的事情也是我来处理了。有了这些环境之后，学习的动力很大，进步的速度也较快。一年后，AIX系统管理知识，存储知识，ORACLE数据库管理知识，WINDCHILL的一些系统知识都算比较熟悉了。之后的日子开始打算学windchill的业务知识，也就是WINDCHILL业务管理员的那部分内容。还没学几天公司的ERP项目开始了，自己马上有个新的角色EBS DBA。因为有了前面的基础，在理解TSM,HACMP的知识没花了什么时间（其实之前就开始关注和自学了），很大一部份时间应该是跟着EBS技术顾问了解这个系统的架构，其中包括安装配置，clone，打PATCH，然后是一些应用DBA经常需要关注的事情。因为技术顾问不经常来（跟功能顾问不一样），所以自己大部分时候在看官方文档。其实自学能力应该算是自己最大的一个优点了，这时侯派上了很大的用场，虽然阅读官方文档进度慢了点，但坚持下来就好了。看第一遍的时候很多东西不理解，我都跳过。看第二遍的时候有些东西自然就明白了，但期间一定不要忘记多跟负责功能的管理员和一些关键用户多交流（顾问已经撤走了）。目前来讲，我最迫切熟悉一些业务功能方面的东西。这样才能把底层技术跟业务功能连接起来，对整个系统的理解会更深刻！EBS是个庞大的系统想学全凭个人的精力恐怕很难做到。给自己定位很重要，EBS DBA?哈哈，我已经是了。我相信我一定能做好做优秀！最后我想说的是：有了扎实的基础，学什么东西都是很快的。当然兴趣很重要。什么，没兴趣？那还玩什么。

 

 

作者：IT168 胡磊编译  2008-05-15

 

从一个“普通”的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 和 系统分析师的角色。