后9i时代的数据库调优[转载]

后9i时代的数据库调优[转载]

关于进入后9i时代的DBA们,如何处理数据库调优的问题,我找到了一篇精彩的博文。发出来大家共享。原文地址是:
http://www.ixdba.com/html/y2008/ ... er-performance.html

原文转载:

如果问一个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操作,让每个操作都有据可循?      
关于Oracle 的数据库有很多新资料现在可以在官网下载,还有官方提供的试用软件:http://wmdata.com.cn/oracle/iwom-DBO/index.asp?frm=16      
这些都没什么可怕,最可怕是干着DBA的活,却领着普通网管的工资。      
如果真如楼上所说,不如换一家公司做,DBA可比普通网管强多了.      
oracle 能消除人为错误造成的故障.      
文章写的不错,从中可以看到oracle 数据库的日益强大的功能.      
oracle 数据库是数据库领域的领导者,很闻名的.      
oracle 数据库利用唯一的最大可用性架构,每周7天、每天24小时开展业务。      
OEM是通过一组Oracle程序,为治理分布式环境提供了治理服务。      
数据库的优化对DBA来说确实不是非常容易的,需要有充分的数据库知识和经验。