oracle addm 自动诊断监视工具介绍

oracle addm 自动诊断监视工具介绍

ID:6335615

大小:76.00 KB

页数:16页

时间:2018-01-10

oracle addm 自动诊断监视工具介绍_第1页
oracle addm 自动诊断监视工具介绍_第2页
oracle addm 自动诊断监视工具介绍_第3页
oracle addm 自动诊断监视工具介绍_第4页
oracle addm 自动诊断监视工具介绍_第5页
资源描述:

《oracle addm 自动诊断监视工具介绍》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库

1、一.ADDM概述ADDM(AutomaticDatabaseDiagnosticMonitor)是植入Oracle数据库的一个自诊断引擎.ADDM通过检查和分析AWR获取的数据来判断Oracle数据库中可能的问题.在Oracle9i及之前,DBA们已经拥有了很多很好用的性能分析工具,比如,tkprof、sql_trace、statspack、setevent10046&10053等等。这些工具能够帮助DBA很快的定位性能问题。但这些工具都只给出一些统计数据,然后再由DBA们根据自己的经验进行优化。Oracle10g中推出了新的优化诊断工具:数据库自动

2、诊断监视工具(AutomaticDatabaseDiagnosticMonitor:ADDM)和SQL优化建议工具(SQLTuningAdvisor:STA)。这两个工具的结合使用,能使DBA节省大量优化时间,也大大减少了系统宕机的危险。简单点说,ADDM就是收集相关的统计数据到自动工作量知识库(AutomaticWorkloadRepository:AWR)中,而STA则根据这些数据,给出优化建议。例如,一个系统资源紧张,出现了明显的性能问题,由以往的办法,做个一个statspack快照,等30分钟,再做一次。查看报告,发现’dbfilescatt

3、eredread’事件在top5events里面。根据经验,这个事件一般可能是因为缺少索引、统计分析信息不够新、热表都放在一个数据文件上导致IO争用等原因引起的。根据这些经验,我们需要逐个来定位排除,比如查看语句的查询计划、查看user_tables的last_analysed子段,检查热块等等步骤来最后定位出原因,并给出优化建议。但是,有了STA以后,它就可以根据ADDM采集到的数据直接给出优化建议,甚至给出优化后的语句。ADDM能发现定位的问题包括:•操作系统内存页入页出问题•由于Oracle负载和非Oracle负载导致的CPU瓶颈问题•导致不同

4、资源负载的TopSQL语句和对象——CPU消耗、IO带宽占用、潜在IO问题、RAC内部通讯繁忙•按照PLSQL和JAVA执行时间排的TopSQL语句.•过多地连接(login/logoff).•过多硬解析问题——由于sharedpool过小、书写问题、绑定大小不适应、解析失败原因引起的。•过多软解析问题•索引查询过多导致资源争用.•由于用户锁导致的过多的等待时间(通过包dbms_lock加的锁)•由于DML锁导致的过多等待时间(例如锁住表了)•由于管道输出导致的过多等待时间(如通过包dbms_pipe.put进行管道输出)•由于并发更新同一个记录导致

5、的过多等待时间(行级锁等待)•由于ITL不够导致的过多等待时间(大量的事务操作同一个数据块)•系统中过多的commit和rollback(logfilesync事件).•由于磁盘带宽太小和其他潜在问题(如由于logfile太小导致过多的checkpoint,MTTR设置问题,过多的undo操作等等)导致的IO性能问题I•对于DBWR进程写数据块,磁盘IO吞吐量不足•由于归档进程无法跟上redo日至产生的速度,导致系统变慢•redo数据文件太小导致的问题•由于扩展磁盘分配导致的争用•由于移动一个对象的高水位导致的争用问题•内存太小问题——SGATarg

6、et,PGA,BufferCache,SharedPool•在一个实例或者一个机群环境中存在频繁读写争用的热块•在一个实例或者一个机群环境中存在频繁读写争用的热对象•RAC环境中内部通讯问题•LMS进程无法跟上导致锁请求阻塞•在RAC环境中由于阻塞和争用导致的实例倾斜•RMAN导致的IO和CPU问题•Streams和AQ问题•资源管理等待事件ADDM提供了一个整体的优化方案.基于一段时间内的AWRsnapshots(默认一小时一次)可以执行ADDM分析,它可以帮我们诊断在这段期间内数据库可能存在的瓶颈.ADDM分析的目标是减小吞吐量的度量值,在这里我

7、们将它称为"DBTIME".DBTIME是一个累积值(数据库服务器处理用户请求所花费的时间).它包括了等待时间和CPU处理的时间(针对所有活跃的用户进程而言),可以通过查询下面两个视图来获得它的值:V$SESS_TIME_MODEL,V$SYS_TIME_MODEL.AWR收集的数据时放到内存中(sharepool),通过一个新的后台进程MMON定期写到磁盘中。所以10g的sharepool要求比以前版本更大,一般推荐比以前大15-20%。注意:ADDM不会将处理用户响应时间作为调优的目标,你应该使用"TRACE"技术来监控它.通过减小"DBTIME

8、",使用同样多的系统资源,数据库服务器可以处理更多的用户请求,也就是提高了吞吐量.通过ADDM报告的问题是按

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。