如果问一个Oracle DBA在学习Oracle的过程中，什么最难，估计十之八九会回答优化。的确，Oracle的优化是一门高深的学问，不仅仅是要深刻的理解Oracle的体系结构、运行机制，还要对硬件、OS等周边环境了如指掌。高级的优化者还要有丰富的编程与应用经验，能从应用上结合Oracle来做优化。
为了能更方便的优化Oracle数据库，Oracle从817开始推出了Statspack，一个被DBA广泛使用的优化工具。包括在我的职业生涯中，Statspack一直是我的主要帮手，它直观的数据统计，给我带来了很大的便捷性。但是，随着数据库越来越多，环境越来越复杂，Statspack也开始表现出它的不足，如在几十个数据库的环境中，每个数据库都看上一遍Statspack报表的话，DBA已经累个半死了。
如果说Statspack是8i-9i时代最强大的Oracle优化工具，那么在后9i时代（10g-11g），随着系统越来越多，环境越来越复杂，我们该怎么调优呢？新的监控工具会是什么样子？它们应当具备如下的特点：
◆集中的图形化管理、监控与优化
◆自动化的、实时的报警与处理
◆历史数据的对照与分析
在这种新的需求下，各种各样图形化的集中管理与监控的工具就出现了，如Veritas I3、quest Central等等。甚至还包括很多公司（如我们团队）自己也开发一些集中的图形化管理与监控界面来配合Statspack使用。当然，Oracle公司也看到了这里潜在的问题与未来的市场，Oracle Enterprise Manager（OEM）就是这种情况下应运而生的产物。
如果说9i的OEM还是个鸡肋的话，从10g起的OEM已经是好多了，在我之前的Blog：Oracle 11g EM–重返图形界面中，也描述了现有的OEM+Grid Control强大的集中化管理功能，使得Oracle 数据库的管理门槛与管理成本大幅度下降。
其实，从Oracle 10g起的OEM不仅仅是具备方便与集中的管理功能，其监控与优化功能也不可小视。通过OEM，我们方便的通过图形界面就可以看到更多的数据库性能指标信息，并且能够诊断数据库存在的问题并提出建议，甚至可以具体到优化存在性能问题的SQL。所以，对于DBA来说，从10g开始，OEM将是一个非常重要的性能诊断工具，使得一个DBA 甚至不需要具备高深的技能，动动鼠标，就可以完成一个在10g之前高难度的优化工作。如果再加上Grid Control，DBA甚至可以方便的管理与优化非常多的Oracle数据库。
这里我不打算介绍OEM强大的集中化管理功能，而是通过一个小小的案例来说明后9i时代怎么样通过OEM完成一个历史问题的跟踪与SQL的优化。在正式分析案例之前，我们先熟悉一下几个名词：
AWR：自动负载信息库 (Automatic Workload Repository)，从Oracle 10g开始也采用AWR用于取代以前的Statspack。相比Statspack，AWR报告不需要安装配置，默认就已经集成安装好了，并且不需要写脚本定期采集和删除信息，Oracle默认情况下每一小时采集一次AWR信息，保留最近一个星期的AWR信息。
ADDM：自动数据库诊断监控程序(Autometic Database Diagnostic Monitor)，可以借助AWR定期从数据库中收集详细的与性能相关的度量标准。每次快照后，调用 ADDM 来彻底分析源自快照间差异的数据和度量标准，然后就必要的操作提出建议。
ASH：活动会话历史（Active Session History），作为ADDM的一个补充，ASH可以动态的随时收集当前的关键性能数据并保存在Shared pool的ASH buffers中，被引入用以保留最近的会话活动的详细历史信息。通过ASH，可以方便的分析最近的SQL与会话信息，本次案例的分析，其实数据就是基于ASH的。
DB Time：这个也是从10g开始出现的一个新概念，表示一个请求(call)在数据库中花费的所有时间，包括CPU time,IO time,以及非空闲等待时间。但是，DB time不等于Response time。DB Time反应了数据库中所消耗的整体时间，不管是CPU问题，还是IO问题，还是其它等待事件，都是可能有优化空间的。
Average Active Sessions：平均活动会话数，这个是一个很绕口的概念，表示当前统计时间段内，活动会话的使用率的一个累计。对于单个进程而言，这个使用率是一个百分比（%Active），表示DB Time/总体时间的一个比率；对于多个进程而言，就这这些进程的累加，如果值越大，也表示了活动的Session很多，或者是活动的Session很忙。
下面，我们开始分析，假定我（DBA）接到一个报告，说Oracle 10g的一个数据库刚才有几分钟时间很慢，但是，现在已经恢复正常了，需要我查找其中的原因。当然，我可以通过Statspack或者是AWR做一个报告，但是，现在，我选择登陆OEM，登陆进去之后，选择Performance标签，看到如下的画面：
可以看到，在10：30左右的时候，对比其它时间段，有一个异常的突起，平均活动会话数到了20左右，而平常一般5都不能达到。另外，通过HOST进程的分析（图上面）以及DB IO与Transaction都没有大的变化，应当表示当前的会话突然变忙了。我点击Top Activity（页面的下面）进入顶级活动页面。
在这个页面中，我可以拖拉阴影框到指定的位置，也就是我要分析的时间点，下面就实时的显示了这个时间范围之内的所有Top Sql以及Top Session，我可以点击任何SQL ID或者是Session ID了解详细情况。在这里，我点击Top 1的SQL ID，看看这个最耗费性能的SQL到底是什么SQL：
这里也有好几个标签页，不同的标签页就可以看到SQL不同的信息，如统计信息，活动信息，执行计划预计调优信息。在Activity标签中，我看到了具体的SQL活动信息，通过Plan标签，能看到它执行时候的具体执行计划，判断它是否走错了执行计划。甚至可以通过SQL调优顾问（SQL Tuning Advisor）给出具体的优化建议，如增加一个合适的索引。
通过以上的一个小案例，演示了Oracle 后9i时代，通过Oracle Web化的图形管理工具–OEM，在优化方面的强大功能。实际上，上面也说过了，OEM的功能远远不止如此，可以说，Oracle 9i之后的OEM是众多DBA 的一个福音。
不过，要真正的精通优化，不是靠一个完善的工具就能解决的。工具最终仅仅还是工具，最多是一个方便管理，节约成本，能给我们多一点休息时间的好东西，至于DBA本身的技能，并不能指望通过工具来获得提升，还是需要各位DBA苦练内功才能获得的。
最后，强大的监控仅仅是能及时的发现问题以及处理问题，为什么会出现了问题，怎么样把问题消灭在萌芽之中，这才是每个DBA所需要思考的：
◆我们应当怎么样合理、有效的规划与设计我们的数据库，避免不必要的设计失误以及意外的Bug。
◆我们应当通过什么样的流程来审核开发人员的Query以及DBA的日常操作，避免各种各样的操作失误。
◆我们应当通过什么样的文档与规范来标准化日常的DDL以及DML操作，让每个操作都有据可循？
上一篇： « 觉得我的书写的不错的话，可以去投个票
下一篇： 招聘监控主管、监控开发工程师、监控轮班工程师 »
- 发表评论
