Question

如何成为一名Oracle应用DBA

Answer 1

从一个 普通 的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 sizing maintaining和 tuning database这些日常的数据库管理的工作 如果他的Apps database是OLTP系统的话 他还需要监察wait和lock Oracle E Business 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去重新编译 utlrp squ在ORACLE HOME的rdbms/admin下 需要用SYS运行 在你的DB运行过程中如果碰到错误 就可以先重新编译invalid objects 如果没有解决问题再去递交iTAR(Internet created Technical Assistance Request)    ．能看懂日志   ．了解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 %的内容 Oracle Apps应该是这样的应用软件 高速度 低拖延的ERP应用软件 使用Oracle所能提供的最好的web和数据库组件 我说的对吗？实际上不完全对 在 的版本里 你能看到应用服务器最早期的一个版本 并且Oracle的版本还是     EBS环境最简单配置也包括两个服务器 这两个服务器也就是我们熟知的两层 数据库层 和中间层 也叫应用层 数据库层就如字面的意思 就是应用程序的后端数据库 中间层就类似Application Server（应用程序服务器） 中间层    在中间层 更确切的说运行在中间层上的还有几种服务 所有的服务都不相同 有OC J 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 i的图 如下图所示            在中间层有许多的 父级 目录 特别要提到其中的两个 这个两个在文档中一次又一次的看到 它们就是APPL_TOP 和MON_TOP 数据库层     数据库层又是什么样子了？令人惊奇的是 Oracle Apps数据库文件格式或许令人难以置信 并不是由于它的复杂性 而恰恰是一点都不复杂 同样在 父级 结构中 数据库有四种数据 他们分别是数据 索引 系统和临时表空间位置 你或许能看到所有的和数据库文件相关的数据都放在一个路径 或者分区里 所有的索引也是在一个路径下 同样系统和临时表空间也是如此 重做日志能够放在两个位置 你或许看到上百的表空间都有一到两个文件 你能看到四个表空间模型     说到重做日志和一般的重做操作 我们肯定知道的一件事情就是在真实的DBA世界里 我们希望重做日志存在快速磁盘中 由于写入量的缘故 你曾经在磁盘中放置一个控制文件吗？如果你没有看到控制文件在事务等待过程中并行写入 那么看一看Oracle Apps安装过程 情况就是这样的 当前文档声称或者说分配重做日志缓冲区大小最好是 MB Oracle在MetaLink上有一个注释 推荐Oracle Apps DBA将重做日志缓冲区设为 MB         另外一个和一般数据库不同的地方就是必须要设置初始参数 在初始文件中设置初始参数还不常见         在使用Oracle Apps时 你不得不向你的OLTP或者DSS数据库打补丁的时候 如何保证 个 的可靠性呢 个 的可靠性意味着每年只有 分钟的停机时间 好了 虽然说没有这么严格 但是仍旧有许多测试工作和质量保证工作需要完成 为了更好的服务于最终用户 你还需要了解些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 和 系统分析师的角色   lishixinzhi/Article/program/Oracle/201311/16510