我刚接触EBS就想从DBA的角度来理解和我原来所做的工作有什么不同,以便尽快适应工作的变化。外事不决问GOOGLE,但是我却没有从GOOGLE里得到答案,大家对Apps DBA和DB DBA的看法不尽相同,有些人认为两者没有区别。但是我觉得Apps 对传统DBA来说是一个很大的挑战,不仅需要了解EBS的各个组件,服务,而且还要更主动和其他相关人员接触。
一个Applications DBA需要和其他DBA一样去负责managing, sizing, maintaining和 tuning database,他的Apps database是OLTP系统,所以也需要监察wait和lock 。Oracle E-Business Suite还有一些特性需要DBA去完成,比如从外部资源里灌数据到Apps database里,或支持开发人员从已有数据中提取数据。他需要仔细记住以下几项,来更好的对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环境应用。
当你成为一个applications administrator,你会发现你一人身兼众多rolse:
1, Oracle Applications DBA
2, DISK空间使用计划和调整
3, Applications system 的Architecture和 design
4, Installation & Upgrade Applications 11i
5, 克隆Applications 11i
6, Split 或merge node,单node变多nodes.
7, Workflow 的安装和配置,准备测试workflow.
8, 优化Oracle WebServer(OWS)
9, 优化Oracle Application Server(OAS)
10, 优化Apache
11, 确保Application安全。
12, 优化UNIX
13, 优化Applicationscripts
14, 解决Application出现的各种问题。
15, Backup & recover (时间,冷备还是热备,要测试恢复计划)
除了以上这些,你还可能被要求去管理Apps的其他组件,比如Discover,Forms,Reports等的创建,修改,上传,注册。如果你的工作真包括这些,那你还需要有版本控制的思维和技术。
中间表及其上的程序,比如你的财务数据是从外部资源来获取的,就可能需要通过建立中间表的方式来实现。
Application,middle tier,database之间有着复杂的连接,常常某一个地方出了问题却在其他地方上表现出来(有点象中医),或者说在一个地方出的问题,影响到另一个地方,又影响到其他,然后最终影响到整体性能。比如一个FORM. 没有被正确执行,而你作为一个DBA可能最先发现的是性能的下降,这会让你很头疼。另外,在打补丁后,原有的forms 或 reports也可能在执行上与打补丁之前有所不同了。
为了更好的服务与最终用户,你还需要了解些Apps的结构,并且掌握专有名词的含义,比如虽然你不需要掌握财务模块是如何实现的,但是还是需要知道AR是借,AP是贷,GL是总帐,这样你在遇到问题的时候就可能及时知道数据是怎么来的,是那个模块,该找什么人去沟通。
最后,我要说,你现在接触和管理的是比你以前复杂的多的系统,这套系统的每一个部分都不能单独来看,一叶障目,不见泰山,遇到问题应该从整体思考。一个Apps DBA是一个对这套系统每一部分都有所了解的人。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/8203880/viewspace-352009/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/8203880/viewspace-352009/