App DBA如何参与性能优化？

Posted on June 12, 2009

之前做了个列表：EBS管理员应当掌握的知识，这里的管理员要和应用DBA区分开来，虽然实际上，很多中小型企业里的IT部门并没有对此做出区分。常规的DBA和EBS DBA工作内容有所不同，EBS是OLAP系统，但是又和大多数其他的OLAP系统有所不同，用户需要从这里实时查看报表，但同时后台又运行着大量的任务，在任何一个时间段，都可能有非常耗资源的批处理程序被启动，并且这些任务不在你的控制之中。

你或许已经看过很多有关优化的文章了，但是只有一个环节永远是最可靠的，那就是你的实践。当亲身实践过后，搜索的范围就会大大缩小。记住一句话，不要轻易尝试他人提供的方式，除非你仔细看过自己的系统分析报告。为了节省时间，作为一名没有优化经验的EBS DBA，与常规DBA工作相比，可能更需要关注以下内容：

  1. 熟悉并发管理器。在系统资源耗费比例上，这是绝对值得关注的部分，系统多大部分任务都通过并发请求来执行。对于深入的技术细节，没有任何现成的文档可以帮助你，但是官方文档已足够应付常规的优化工作。
  2. 理解EBS并不是真正意义上的OLAP系统。有大量的用户对数据的处理操作，实际上都在接口中进行，而接口则通过提交并发请求来进行。在日常业务中，你无法知晓何时会出现一个大量数据处理的批处理程序，用户随时可能提交多个非常消耗资源的批处理程序。你应该预估到这种情况对系统运行造成的影响。有时候，理解业务需求，从业务角度来安排此类程序的执行，会让业务和系统都轻松很多。
  3. 不要轻易应用Patch。EBS系统永远存在解决不完的BUG，在充分理解解决BUG的必要性，以及充分而全面的测试后才可以考虑应用到正式环境。否则，你将承受影响业务操作的风险，也可能导致系统其他功能的异常，而这异常会占用你的工作时间。记住，在任何一次应用Patch之前，你都应该预估到可能带来的影响，并提前做好准备。
  4. 记录Patch历史。尽管系统记录了每次Patch应用的时间、操作和内容，但是它并不知道你为什么需要它。需要去记录该Patch期望能解决的问题，应用后出现的新问题以及业务的影响。Oracle Support解决问题时会尝试先了解系统最近有没有什么变动。
  5. 定期重建EBS索引。EBS中存在大量的索引，约有4万个。某些表可能有频繁的DML操作，你需要注意到这种表，并设置相应的索引的重建计划。重建索引可能耗费很多时间，需要安排一个在线用户最少的时间段来进行。
  6. 谨慎添加客户化索引。EBS本身是优化过的，并不是设计来仅供一两年使用的。很多性能问题实际上是IT人员自己造成的。有时候，你可能注意到某个程序执行效率很低，原因是没有走相关的索引，但是记得，索引并非越多越好，除非你非常熟悉相关应用，知道自己在做些什么，不然还是交给Oracle Support为好。一个未经分析的索引，可能导致系统性能出乎意料。
  7. 理解应用Patch是如何进行的。除了理解它本身的工作原理之外，还需要了解它带来的影响，比如Patch是如何改变你本来工作的非常好的某段SQL的执行计划的？你需要知道Patch后，某个批处理程序突然变慢的原因。
  8. 理解预警。理解其工作原理，清楚的知道利弊。比如事件预警会创建什么样的Trigger。
  9. 熟悉Apache、UNIX Server、OAS等，这些一般情况下不会成为性能优化的优先目标，但是在今后更深入的工作中会考虑到。

这里并没有列出一个普通DBA应当参与的工作，比如监控回滚段、分析Statspack报表、捕获并提出性能恶劣的客户化SQL的优化建议以及其他份内工作。App DBA作为专业的工作职位自然有其特殊性，比如为什么你不能使用DBMS_STATS做统计？为什么不允许KEEP Pool？

Oracle EBS 本身的技术架构已经可以让合格的DBA大展身手，不论从数据库层还是应用层。不要把注意力全部集中到SQL优化上，尽管这可能就是90%的问题所在，但是它通常由客户化引起。对于纯标准化的EBS应用而言，运行5年后，在性能优化领域将需要从更高处审视整套系统。

Related Posts

No related posts.

» Filed Under E-Business Suite Print This Post Print This Post

Comments

One Response to “App DBA如何参与性能优化？”

  1. powpeo on June 12th, 2009 22:41

    收益匪浅，有点开窍了

Leave a Reply