Chinaunix首页 | 论坛 | 博客
  • 博客访问: 191114
  • 博文数量: 50
  • 博客积分: 2500
  • 博客等级: 少校
  • 技术积分: 641
  • 用 户 组: 普通用户
  • 注册时间: 2008-04-11 19:48
文章分类

全部博文(50)

文章存档

2011年(2)

2010年(1)

2009年(5)

2008年(42)

我的朋友

分类: Oracle

2008-04-15 18:01:00

 ADDM简介
 
 

Oracle9i及之前,DBA已经拥有了很多很好用的性能分析工具,比如,tkprofsql_tracestatspackset event 10046&10053等等。这些工具能够帮助DBA很快的定位性能问题。但这些工具都只给出一些统计数据,然后再由DBA们根据自己的经验进行优化。

那能不能由机器自动统计数据的基础上给出优化建议呢?Oracle10g中就推出了新的优化诊断工具:数据库自动诊断监视工具(Automatic Database Diagnostic Monitor ADDM)和SQL优化建议工具(SQL Tuning Advisor STA)。这两个工具的结合使用,能使DBA节省大量优化时间,也大大减少了系统宕机的危险。简单点说,ADDM就是收集相关的统计数据到自动工作量知识库(Automatic Workload Repository AWR)中,而STA则根据这些数据,给出优化建议。例如,一个系统资源紧张,出现了明显的性能问题,由以往的办法,做个一个statspack快照,等30分钟,再做一次。查看报告,发现 db file scattered read事件在top 5 events里面。根据经验,这个事件一般可能是因为缺少索引、统计分析信息不够新、热表都放在一个数据文件上导致IO争用等原因引起的。根据这些经验,我们需要逐个来定位排除,比如查看语句的查询计划、查看user_tableslast_analysed子段,检查热块等等步骤来最后定位出原因,并给出优化建议。但是,有了STA以后,它就可以根据ADDM采集到的数据直接给出优化建议,甚至给出优化后的语句

ADDM能发现定位的问包括:

·         操作系统内存页入页出问题
·         由于Oracle负载和非Oracle负载导致的CPU瓶颈问题
·         导致不同资源负载的Top SQL语句和对象——CPU消耗、IO带宽占用、潜在IO问题、RAC内部通讯繁忙
·         按照PLSQLJAVA执行时间排的Top SQL语句.
·         过多地连接 (login/logoff).
·         过多硬解析问题——由于shared pool过小、书写问题、绑定大小不适应、解析失败原因引起的。
·         过多软解析问题
·         索引查询过多导致资源争用.
·         由于用户锁导致的过多的等待时间 (通过包dbms_lock加的锁)
·         由于DML锁导致的过多等待时间(例如锁住表了)
·         由于管道输出导致的过多等待时间(如通过包dbms_pipe.put进行管道输出)
·         由于并发更新同一个记录导致的过多等待时间(行级锁等待)
·         由于ITL不够导致的过多等待时间(大量的事务操作同一个数据块)
·         系统中过多的commitrollback(logfile sync事件).
·         由于磁盘带宽太小和其他潜在问题(如由于logfile太小导致过多的checkpointMTTR设置问题,过多的undo操作等等)导致的IO性能问题I
·         对于DBWR进程写数据块,磁盘IO吞吐量不足
·         由于归档进程无法跟上redo日至产生的速度,导致系统变慢
·         redo数据文件太小导致的问题
·         由于扩展磁盘分配导致的争用
·         由于移动一个对象的高水位导致的争用问题
·         内存太小问题——SGA Target, PGA, Buffer Cache, Shared Pool
·         在一个实例或者一个机群环境中存在频繁读写争用的热块
·         在一个实例或者一个机群环境中存在频繁读写争用的热对象
·         RAC环境中内部通讯问题
·         LMS进程无法跟上导致锁请求阻塞
·         RAC环境中由于阻塞和争用导致的实例倾斜
·         RMAN导致的IOCPU问题
·         StreamsAQ问题
·         资源管理等待事件
   有一点要记住:AWR集的数据时放到内存中(share pool),通过一个新的后台进程MMON定期写到磁盘中。所以10gshare pool要求比以前版本更大,一般推荐比以前大15-20%。另外,还要求系统参数STATISTICS_LEVEL设置为TYPICAL(推荐)或ALL;
 ALTER SESSION SET STATISTICS_LEVEL= TYPICAL;
 接执行$ORACLE_HOME/rdbms/admin/addmrpt.sql来得到,这个脚本的执行过程和statspack脚本执行过程类似:
 此外,如果是RAC环境下,可以执行$ORACLE_HOME/rdbms/admin/addmrpti.sql,这脚本的执行,会多出要求输入DB ID和instance ID的要求.
诊断结果分析
我们从上面的建议结果看到了,ADDM Report的结果Statspack Report的结果大不相同。Statspack Report的结果给出的都是统计数据、各种事件,然后由DBA根据这些数据给出优化建议,而ADDM Report的结果包含就已经是给出的优化建议了。

第一部分:       这一部分包括一些基础信息,分析时间段、DBinstance ID&名字、主机名字、Oracle版本、快照范围、数据库消耗时间、多少个活动会话。
第二部分:下面就是ADDM发现的问题,并给出的相应建议。
阅读(587) | 评论(0) | 转发(0) |
0

上一篇:logminer的使用

下一篇:oracle参数解释

给主人留下些什么吧!~~