您的位置：首页 > 数据库 > Oracle

Oracle10g数据库自动诊断监视工具(ADDM)使用指南

2013-11-26 13:22 363 查看

第一章ADDM简介

在Oracle9i及之前，DBA们已经拥有了很多很好用的性能分析工具，比如，tkprof、sql_trace、statspack、setevent10046&10053等等。这些工具能够帮助DBA很快的定位性能问题。但这些工具都只给出一些统计数据，然后再由DBA们根据自己的经验进行优化。那能不能由机器自动在统计数据的基础上给出优化建议呢？Oracle10g中就推出了新的优化诊断工具：数据库自动诊断监视工具（AutomaticDatabaseDiagnosticMonitorADDM）和SQL优化建议工具（SQLTuningAdvisorSTA）。这两个工具的结合使用，能使DBA节省大量优化时间，也大大减少了系统宕机的危险。简单点说，ADDM就是收集相关的统计数据到自动工作量知识库(AutomaticWorkloadRepositoryAWR)中，而STA则根据这些数据，给出优化建议。例如，一个系统资源紧张，出现了明显的性能问题，由以往的办法，做个一个statspack快照，等30分钟，再做一次。查看报告，发现’dbfilescatteredread’事件在top5events里面。根据经验，这个事件一般可能是因为缺少索引、统计分析信息不够新、热表都放在一个数据文件上导致IO争用等原因引起的。根据这些经验，我们需要逐个来定位排除，比如查看语句的查询计划、查看user_tables的last_analysed子段，检查热块等等步骤来最后定位出原因，并给出优化建议。但是，有了STA以后，它就可以根据ADDM采集到的数据直接给出优化建议，甚至给出优化后的语句（抢了DBA的饭碗喽）。ADDM能发现定位的问题包括：
·操作系统内存页入页出问题
·由于Oracle负载和非Oracle负载导致的CPU瓶颈问题
·导致不同资源负载的TopSQL语句和对象——CPU消耗、IO带宽占用、潜在IO问题、RAC内部通讯繁忙
·按照PLSQL和JAVA执行时间排的TopSQL语句.
·过多地连接(login/logoff).
·过多硬解析问题——由于sharedpool过小、书写问题、绑定大小不适应、解析失败原因引起的。
·过多软解析问题
·索引查询过多导致资源争用.
·由于用户锁导致的过多的等待时间(通过包dbms_lock加的锁)
·由于DML锁导致的过多等待时间(例如锁住表了)
·由于管道输出导致的过多等待时间(如通过包dbms_pipe.put进行管道输出)
·由于并发更新同一个记录导致的过多等待时间(行级锁等待)
·由于ITL不够导致的过多等待时间（大量的事务操作同一个数据块）
·系统中过多的commit和rollback(logfilesync事件).
·由于磁盘带宽太小和其他潜在问题（如由于logfile太小导致过多的checkpoint，MTTR设置问题，过多的undo操作等等）导致的IO性能问题I
·对于DBWR进程写数据块，磁盘IO吞吐量不足
·由于归档进程无法跟上redo日至产生的速度，导致系统变慢
·redo数据文件太小导致的问题
·由于扩展磁盘分配导致的争用
·由于移动一个对象的高水位导致的争用问题
·内存太小问题——SGATarget,PGA,BufferCache,SharedPool
·在一个实例或者一个机群环境中存在频繁读写争用的热块
·在一个实例或者一个机群环境中存在频繁读写争用的热对象
·RAC环境中内部通讯问题
·LMS进程无法跟上导致锁请求阻塞
·在RAC环境中由于阻塞和争用导致的实例倾斜
·RMAN导致的IO和CPU问题
·Streams和AQ问题
·资源管理等待事件
有一点要记住：AWR收集的数据时放到内存中（sharepool），通过一个新的后台进程MMON定期写到磁盘中。所以10g的sharepool要求比以前版本更大，一般推荐比以前大15-20%。另外，还要求系统参数STATISTICS_LEVEL设置为TYPICAL（推荐）或ALL;
ALTERSESSIONSETSTATISTICS_LEVEL=TYPICAL;
第二章工作采集、诊断过程
Oracle10g提供了一个图形化的界面（通过OEM），使这个工具使用起来非常简单。下面这里介绍一下如何通过sqlplus使用这个工具。这个工具的使用非常简单，它是不需要安装的。
第一步：创建测试用的表
SQL>CREATETABLEbigtabASSELECTrownumas"id",a.*FROMdba_objectsa;
Tablecreated.SQL>createtablesmalltabasselectrownumas"id",a.*FROMdba_tablesa;
Tablecreated.
DECLAREnNUMBER;BEGINFORnIN1..100LOOPINSERTINTObigtabSELECTrownumas"id",a.*FROMdba_objectsa;COMMIT;ENDLOOP;END;/
PL/SQLproceduresuccessfullycompleted.
第二步：采集一次工作量快照
SQL>begin
2dbms_workload_repository.create_snapshot('TYPICAL');
3end;
4/
PL/SQLproceduresuccessfullycompleted.
第三步：进行一些高负荷操作
DECLAREv_varnumber;BEGINFORnIN1..6LOOPselectcount(*)intov_varfrombigtabb,smalltaba;ENDLOOP;END;/
PL/SQLproceduresuccessfullycompleted.
第四步：再次采集一次工作量快照
要注意的是：两次快照之间的间隔时间必须足够（一般推荐30分钟左右），否则得到的ADDM报告中就会提示：THEREWASNOTENOUGHDATABASETIMEFORADDMANALYSIS.
SQL>begin
2dbms_workload_repository.create_snapshot('TYPICAL');
3end;
4/
PL/SQLproceduresuccessfullycompleted.
第五步：创建一个优化诊断任务并执行
先获取到两次快照的ID:
SQL>selectsnap_idfrom
2(SELECT*FROMdba_hist_snapshot
3ORDERBYsnap_iddesc)
4whererownum<=2;
SNAP_ID
--------
66
65
然后创建优化任务，并执行。
DECLAREtask_nameVARCHAR2(30):='DEMO_ADDM01';task_descVARCHAR2(30):='ADDMFeatureTest';task_idNUMBER;BEGINdbms_advisor.create_task('ADDM',task_id,task_name,task_desc,null);dbms_advisor.set_task_parameter(task_name,'START_SNAPSHOT',65);dbms_advisor.set_task_parameter(task_name,'END_SNAPSHOT',66);dbms_advisor.set_task_parameter(task_name,'INSTANCE',1);dbms_advisor.set_task_parameter(task_name,'DB_ID',1712582900);dbms_advisor.execute_task(task_name);END;/
PL/SQLproceduresuccessfullycompleted.
其中，set_task_parameter是用来设置任务参数的。START_SNAPSHOT是起始快照ID，END_SNAPSHOT是结束快照ID，INSTANCE是实例号，对于单实例，一般是1，在RAC环境下，可以通过查询视图v$instance得到，DB_ID是数据库的唯一识别号，可以通过查询v$database查到。
第六步：查看优化建议结果
通知函数dbms_advisor.get_task_report可以得到优化建议结果。
SQL>SETLONG1000000PAGESIZE0LONGCHUNKSIZE1000
SQL>COLUMNget_clobFORMATa80
SQL>SELECTdbms_advisor.get_task_report('DEMO_ADDM01','TEXT','ALL')FROMDUAL;
DBMS_ADVISOR.GET_TASK_REPORT('
--------------------------------------------------------------------------------
DETAILEDADDMREPORTFORTASK'DEMO_ADDM01'WITHID243
-------------------------------------------------------
AnalysisPeriod:23-NOV-2005from15:02:27to16:06:42
DatabaseID/Instance:1712582900/1
Database/InstanceNames:EDGAR/edgar
HostName:HUANGED
DatabaseVersion:10.2.0.1.0
SnapshotRange:from65to66
DatabaseTime:1463seconds
AverageDatabaseLoad:.4activesessions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
FINDING1:100%impact(1463seconds)
-------------------------------------
Significantvirtualmemorypagingwasdetectedonthehostoperatingsystem.
RECOMMENDATION1:HostConfiguration,100%benefit(1463seconds)
ACTION:Hostoperatingsystemwasexperiencingsignificantpagingbutno
particularrootcausecouldbedetected.Investigateprocessesthat
donotbelongtothisinstancerunningonthehostthatareconsuming
significantamountofvirtualmemory.Alsoconsideraddingmore
physicalmemorytothehost.
FINDING2:100%impact(1463seconds)
-------------------------------------
SQLstatementsconsumingsignificantdatabasetimewerefound.
RECOMMENDATION1:SQLTuning,68%benefit(998seconds)
ACTION:TunethePL/SQLblockwithSQL_ID"064wqx7c5b81z".Refertothe
"TuningPL/SQLApplications"chapterofOracle's"PL/SQLUser'sGuide
andReference"
RELEVANTOBJECT:SQLstatementwithSQL_ID064wqx7c5b81z
DECLARE
v_varnumber;
BEGIN
FORnIN1..10000
LOOP
selectcount(*)intov_varfrombigtabb,smalltaba;
ENDLOOP;
END;
RECOMMENDATION2:SQLTuning,67%benefit(986seconds)
ACTION:RunSQLTuningAdvisorontheSQLstatementwithSQL_ID
"fvqfghq71cqns".
RELEVANTOBJECT:SQLstatementwithSQL_IDfvqfghq71cqnsand
PLAN_HASH3281046854
SELECTCOUNT(*)FROMBIGTABB,SMALLTABA
RATIONALE:SQLstatementwithSQL_ID"fvqfghq71cqns"wasexecuted6
timesandhadanaverageelapsedtimeof166seconds.
FINDING3:69%impact(1002seconds)
------------------------------------
TimespentontheCPUbytheinstancewasresponsibleforasubstantialpart
ofdatabasetime.
RECOMMENDATION1:SQLTuning,67%benefit(986seconds)
ACTION:RunSQLTuningAdvisorontheSQLstatementwithSQL_ID
"fvqfghq71cqns".
RELEVANTOBJECT:SQLstatementwithSQL_IDfvqfghq71cqnsand
PLAN_HASH3281046854
SELECTCOUNT(*)FROMBIGTABB,SMALLTABA
RATIONALE:SQLstatementwithSQL_ID"fvqfghq71cqns"wasexecuted6
timesandhadanaverageelapsedtimeof166seconds.
RATIONALE:AverageCPUusedperexecutionwas162seconds.
RECOMMENDATION2:SQLTuning,2.1%benefit(30seconds)
ACTION:TunethePL/SQLblockwithSQL_ID"2b064ybzkwf1y".Refertothe
"TuningPL/SQLApplications"chapterofOracle's"PL/SQLUser'sGuide
andReference"
RELEVANTOBJECT:SQLstatementwithSQL_ID2b064ybzkwf1y
BEGINEMD_NOTIFICATION.QUEUE_READY(:1,:2,:3);END;
RATIONALE:SQLstatementwithSQL_ID"2b064ybzkwf1y"wasexecuted125
timesandhadanaverageelapsedtimeof0.26seconds.
RATIONALE:AverageCPUusedperexecutionwas0.24seconds.
FINDING4:2.2%impact(33seconds)
-----------------------------------
PL/SQLexecutionconsumedsignificantdatabasetime.
RECOMMENDATION1:SQLTuning,2.2%benefit(33seconds)
ACTION:TunethePL/SQLblockwithSQL_ID"2b064ybzkwf1y".Refertothe
"TuningPL/SQLApplications"chapterofOracle's"PL/SQLUser'sGuide
andReference"
RELEVANTOBJECT:SQLstatementwithSQL_ID2b064ybzkwf1y
BEGINEMD_NOTIFICATION.QUEUE_READY(:1,:2,:3);END;
RATIONALE:SQLstatementwithSQL_ID"2b064ybzkwf1y"wasexecuted125
timesandhadanaverageelapsedtimeof0.26seconds.
RATIONALE:AveragetimespentinPL/SQLexecutionwas0.26seconds.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ADDITIONALINFORMATION
----------------------
Waitclass"Application"wasnotconsumingsignificantdatabasetime.
Waitclass"Commit"wasnotconsumingsignificantdatabasetime.
Waitclass"Concurrency"wasnotconsumingsignificantdatabasetime.
Waitclass"Configuration"wasnotconsumingsignificantdatabasetime.
Waitclass"Network"wasnotconsumingsignificantdatabasetime.
Waitclass"UserI/O"wasnotconsumingsignificantdatabasetime.
Sessionconnectanddisconnectcallswerenotconsumingsignificantdatabase
time.
HardparsingofSQLstatementswasnotconsumingsignificantdatabasetime.
TheanalysisofI/Operformanceisbasedonthedefaultassumptionthatthe
averagereadtimeforonedatabaseblockis10000micro-seconds.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TERMINOLOGY
-----------
DATABASETIME:ThisistheADDM'smeasurementofthroughput.Fromtheuser's
pointofview:thisisthetotalamountoftimespentbyuserswaitingfor
aresponsefromthedatabaseafterissuingacall(notincluding
networking).Fromthedatabaseinstancepointofview:thisisthetotal
timespentbyforgroundprocesseswaitingforadatabaseresource(e.g.,
readI/O),runningontheCPUandwaitingforafreeCPU(run-queue).The
targetofADDManalysisistoreducethismetricasmuchaspossible,
therebyreducingtheinstance'sresponsetime.
AVERAGEDATABASELOAD:Atanygiventimewecancounthowmanyusers(also
called'ActiveSessions')arewaitingforananswerfromtheinstance.This
istheADDM'smeasurementforinstanceload.The'AverageDatabaseLoad'is
theaverageofthetheloadmeasurementtakenovertheentireanalysis
period.Wegetthisnumberbydividingthe'DatabaseTime'bytheanalysis
period.Forexample,iftheanalysisperiodis30minutesandthe'Database
Time'is90minutes,wehaveanaverageof3userswaitingforaresponse.
IMPACT:Eachfindinghasan'Impact'associatedwithit.Theimpactisthe
portionofthe'DatabaseTime'thefindingdealswith.Ifweassumethat
theproblemdescribedbythefindingiscompletelysolved,thenthe
'DatabaseTime'willbereducedbytheamountofthe'Impact'.
BENEFIT:Eachrecommendationhasa'benefit'associatedwithit.TheADDM
analysisestimatesthatthe'DatabaseTime'canbereducedbythe'benefit'
amountifalltheactionsoftherecommendationareperformed.
说明：
其中第五步到第六步可以直接执行$ORACLE_HOME/rdbms/admin/addmrpt.sql来得到，这个脚本的执行过程和statspack脚本执行过程类似：
SQL>@addmrpt
CurrentInstance
~~~~~~~~~~~~~~~~
DBIdDBNameInstNumInstance
-------------------------------------------
1712582900EDGAR1edgar
InstancesinthisWorkloadRepositoryschema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DBIdInstNumDBNameInstanceHost
--------------------------------------------------------
*17125829001EDGARedgarHUANGED
Using1712582900fordatabaseId
Using1forinstancenumber
Specifythenumberofdaysofsnapshotstochoosefrom
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enteringthenumberofdays(n)willresultinthemostrecent
(n)daysofsnapshotsbeinglisted.Pressing<return>without
specifyinganumberlistsallcompletedsnapshots.
Listingthelast3daysofCompletedSnapshots
Snap
InstanceDBNameSnapIdSnapStartedLevel
--------------------------------------------------------
edgarEDGAR722Nov200500:001
......
6423Nov200515:021
6523Nov200516:001
6623Nov200516:061
SpecifytheBeginandEndSnapshotIds
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entervalueforbegin_snap:65
BeginSnapshotIdspecified:66
Entervalueforend_snap:66
EndSnapshotIdspecified:66
SpecifytheReportName
~~~~~~~~~~~~~~~~~~~~~~~
Thedefaultreportfilenameisaddmrpt_1_65_66.txt.Tousethisname,
press<return>tocontinue,otherwiseenteranalternative.
Entervalueforreport_name:
Usingthereportnameaddmrpt_1_65_66.txt
RunningtheADDManalysisonthespecifiedpairofsnapshots...
GeneratingtheADDMreportforthisanalysis...
......
此外，如果是RAC环境下，可以执行$ORACLE_HOME/rdbms/admin/addmrpti.sql，这脚本的执行，会多出要求输入DBID和instanceID的要求。
第三章诊断结果分析
我们从上面的建议结果看到了，ADDMReport的结果与StatspackReport的结果大不相同。StatspackReport的结果给出的都是统计数据、各种事件，然后由DBA根据这些数据给出优化建议，而ADDMReport的结果包含就已经是给出的优化建议了（汗！DBA以后要失业了！）
第一部分：
AnalysisPeriod:23-NOV-2005from15:02:27to16:06:42
DatabaseID/Instance:1712582900/1
Database/InstanceNames:EDGAR/edgar
HostName:HUANGED
DatabaseVersion:10.2.0.1.0
SnapshotRange:from65to66
DatabaseTime:1463seconds
AverageDatabaseLoad:.4activesessions
这一部分包括一些基础信息，分析时间段、DB和instanceID&名字、主机名字、Oracle版本、快照范围、数据库消耗时间、多少个活动会话。
第二部分：
下面就是ADDM发现的问题，并给出的相应建议。在我们这个例子中总共发现4个问题，下面一一解释一下。第一个问题：
FINDING1:100%impact(1463seconds)
-------------------------------------
Significantvirtualmemorypagingwasdetectedonthehostoperatingsystem.
RECOMMENDATION1:HostConfiguration,100%benefit(1463seconds)
ACTION:Hostoperatingsystemwasexperiencingsignificantpagingbutno
particularrootcausecouldbedetected.Investigateprocessesthat
donotbelongtothisinstancerunningonthehostthatareconsuming
significantamountofvirtualmemory.Alsoconsideraddingmore
physicalmemorytothehost.
先看第一行：100%impact(1463seconds)，这是这个问题所持续的实践及其对系统的影响，它的时间是1463秒，和分析期间的数据库消耗时间（在第一部分中）是一样（1463秒），所以对系统的影响是1463/1463*100=100%的。再看第二行：Significantvirtualmemorypagingwasdetectedonthehostoperatingsystem.，这是ADDM发现的这个问题的具体描述：在操作系统中发现有显著的虚拟内存页入页出的问题。然后看ADDM给出的建议及其作用：HostConfiguration,100%benefit(1463seconds)——更改主机配置，100%有效。最后是具体该如何操作：略——在主机的操作系统上发现了明显的页入页出，但是没有发现明显导致内存频繁换如换出的根本原因。需要仔细检查那些消耗大量虚拟内存的进程（除Oracle实例外）。此外，还可以考虑增大主机的物理内存。说明一下：我的这个实例是跑在我自己的PC机上，Oracle运行的同时有大量的其他消耗内存的程序（word等）在运行，所以肯定有大量的内存交换存在。再看第二个问题：
FINDING2:100%impact(1463seconds)
-------------------------------------
SQLstatementsconsumingsignificantdatabasetimewerefound.
RECOMMENDATION1:SQLTuning,68%benefit(998seconds)
ACTION:TunethePL/SQLblockwithSQL_ID"064wqx7c5b81z".Refertothe
"TuningPL/SQLApplications"chapterofOracle's"PL/SQLUser'sGuide
andReference"
RELEVANTOBJECT:SQLstatementwithSQL_ID064wqx7c5b81z
DECLARE
v_varnumber;
BEGIN
FORnIN1..10000
LOOP
selectcount(*)intov_varfrombigtabb,smalltaba;
ENDLOOP;
END;
ADDM发现有SQL语句在消耗大量数据库时间，它的影响是100%的。给出的建议是优化SQL，能取得68%的效果。具体操作是优化ADDM找到的PL/SQL块，它的SQL_ID是"064wqx7c5b81z"（可以通过selectsql_textfromv$sqlwheresql_id=’064wqx7c5b81z’;查到）。至于如何优化SQL语句，可以参考Oracle文档PL/SQLUser'sGuideandReference中的TuningPL/SQLApplications章节。下面的内容便是我们用来插入数据的测试语句。下面是ADDM发现的其他问题语句：
FINDING3:69%impact(1002seconds)
------------------------------------
TimespentontheCPUbytheinstancewasresponsibleforasubstantialpart
ofdatabasetime.
RECOMMENDATION1:SQLTuning,67%benefit(986seconds)
ACTION:RunSQLTuningAdvisorontheSQLstatementwithSQL_ID
"fvqfghq71cqns".
RELEVANTOBJECT:SQLstatementwithSQL_IDfvqfghq71cqnsand
PLAN_HASH3281046854
SELECTCOUNT(*)FROMBIGTABB,SMALLTABA
RATIONALE:SQLstatementwithSQL_ID"fvqfghq71cqns"wasexecuted6
timesandhadanaverageelapsedtimeof166seconds.
RATIONALE:AverageCPUusedperexecutionwas162seconds.
RECOMMENDATION2:SQLTuning,2.1%benefit(30seconds)
ACTION:TunethePL/SQLblockwithSQL_ID"2b064ybzkwf1y".Refertothe
"TuningPL/SQLApplications"chapterofOracle's"PL/SQLUser'sGuide
andReference"
RELEVANTOBJECT:SQLstatementwithSQL_ID2b064ybzkwf1y
BEGINEMD_NOTIFICATION.QUEUE_READY(:1,:2,:3);END;
RATIONALE:SQLstatementwithSQL_ID"2b064ybzkwf1y"wasexecuted125
timesandhadanaverageelapsedtimeof0.26seconds.
RATIONALE:AverageCPUusedperexecutionwas0.24seconds.
这个问题的描述是，实例消耗的CPU事件占据了大量的数据库运行时间。由于发现了两条问题语句，所以这里有两个建议。第一个建议就是优化我们的测试语句。并且说明了这个问题的根本原因：这条语句总共执行过6次，平均每次消耗了166秒。平均这个问题消耗的CPU时间是162秒。第二个建议实际上是针对一个系统过程，这个过程是用来读取队列信息的，消耗的资源比较小，我们这里就不需要关心了。再看最后一个问题：
FINDING4:2.2%impact(33seconds)
-----------------------------------
PL/SQLexecutionconsumedsignificantdatabasetime.
RECOMMENDATION1:SQLTuning,2.2%benefit(33seconds)
ACTION:TunethePL/SQLblockwithSQL_ID"2b064ybzkwf1y".Refertothe
"TuningPL/SQLApplications"chapterofOracle's"PL/SQLUser'sGuide
andReference"
RELEVANTOBJECT:SQLstatementwithSQL_ID2b064ybzkwf1y
BEGINEMD_NOTIFICATION.QUEUE_READY(:1,:2,:3);END;
RATIONALE:SQLstatementwithSQL_ID"2b064ybzkwf1y"wasexecuted125
timesandhadanaverageelapsedtimeof0.26seconds.
RATIONALE:AveragetimespentinPL/SQLexecutionwas0.26seconds.
从内容上看，这个问题就是上一个问题中的第二个建议。但是，它导致的结果是不一样的。看这个问题的描述：PL/SQL的执行次数消耗了大量的数据库时间。它的根本原因是因为执行次数太多（125次）。可见ADDM的问题检查相当全面。
第三部分：
这一部分的内容是关于此次优化建议的一些附加信息：
ADDITIONALINFORMATION
----------------------
Waitclass"Application"wasnotconsumingsignificantdatabasetime.
Waitclass"Commit"wasnotconsumingsignificantdatabasetime.
Waitclass"Concurrency"wasnotconsumingsignificantdatabasetime.
Waitclass"Configuration"wasnotconsumingsignificantdatabasetime.
Waitclass"Network"wasnotconsumingsignificantdatabasetime.
Waitclass"UserI/O"wasnotconsumingsignificantdatabasetime.
Sessionconnectanddisconnectcallswerenotconsumingsignificantdatabase
time.
HardparsingofSQLstatementswasnotconsumingsignificantdatabasetime.
TheanalysisofI/Operformanceisbasedonthedefaultassumptionthatthe
averagereadtimeforonedatabaseblockis10000micro-seconds.
这是关于这次优化诊断对各类事件（在Oracle10g，新增了很多新的事件，主要是将原先一些较含糊的事件细化了，同时将所有事件进行了归类。可以查看视图V$SYSTEM_WAIT_CLASS）的一些总结：Application、Commit、Concurrency、Configuration、Network、UserI/O类等待事件没有显著消耗数据库时间；会话连接、断连请求没有消耗大量数据库时间；对SQL语句的硬解析没有消耗大量数据库时间；对IO性能的分析是基于默认假设每次读一个数据块的时间是10000微秒的。
第四部分：
这部分是对诊断报告中用到的术语的解释：
TERMINOLOGY
-----------
DATABASETIME:ThisistheADDM'smeasurementofthroughput.Fromtheuser's
pointofview:thisisthetotalamountoftimespentbyuserswaitingfor
aresponsefromthedatabaseafterissuingacall(notincluding
networking).Fromthedatabaseinstancepointofview:thisisthetotal
timespentbyforgroundprocesseswaitingforadatabaseresource(e.g.,
readI/O),runningontheCPUandwaitingforafreeCPU(run-queue).The
targetofADDManalysisistoreducethismetricasmuchaspossible,
therebyreducingtheinstance'sresponsetime.
AVERAGEDATABASELOAD:Atanygiventimewecancounthowmanyusers(also
called'ActiveSessions')arewaitingforananswerfromtheinstance.This
istheADDM'smeasurementforinstanceload.The'AverageDatabaseLoad'is
theaverageofthetheloadmeasurementtakenovertheentireanalysis
period.Wegetthisnumberbydividingthe'DatabaseTime'bytheanalysis
period.Forexample,iftheanalysisperiodis30minutesandthe'Database
Time'is90minutes,wehaveanaverageof3userswaitingforaresponse.
IMPACT:Eachfindinghasan'Impact'associatedwithit.Theimpactisthe
portionofthe'DatabaseTime'thefindingdealswith.Ifweassumethat
theproblemdescribedbythefindingiscompletelysolved,thenthe
'DatabaseTime'willbereducedbytheamountofthe'Impact'.
BENEFIT:Eachrecommendationhasa'benefit'associatedwithit.TheADDM
analysisestimatesthatthe'DatabaseTime'canbereducedbythe'benefit'
amountifalltheactionsoftherecommendationareperformed.
DATABASETIME：是ADDM的度量数据。从用户角度看：这是从向数据库请求开始，消耗在用户等待响应上的全部时间（不包括网络响应时间）；从数据库实例角度看：前台进程消耗在等待一种数据库资源（例如，IO读）、CPU运行和等待CPU释放（队列等待）的总共时间。ADDM分析的目标就尽量降低这个数字，也就是减少实例响应时间。AVERAGEDATABASELOAD：所有能统计到的有多少用户（也称为“活动会话”）等待实例响应。这是实例负荷的度量指标。平均数据库负荷是由整个分析计算出来的平均负荷。通过“DatabaseTime”除以分析周期时间得到。例如，分析周期时30分钟，而数据库运行消耗时间是90分钟，那就说明平均有3个用户在等待响应。IMPACT：每一个找到的问题都有“影响”这一项。“影响”是数据库消耗时间用于处理这个问题的时间不分。假定我们所找到的这个问题完全解决，那么数据库消耗时间就会相应减少“影响”时间。BENEFIT：每一个找到的问题都“受益”这一项。如果所有建议操作得到实施，ADDM分析估计数据库消耗时间能减少“受益”的全部时间。
第四章使用STA来优化语句
ADDM得出了诊断结果，并给出了优化建议。通常90%的性能问题都是由于应用引起的，而应用问题肯定离不开问题语句。那么如何优化这些语句呢，以前靠的是DBA的经验，现在就可以使用STA了。备注：关于STA的使用，请参考我的另一篇文章《利用SQL优化器（STA）优化语句》STA的使用非常简单，从ADDM诊断报告中，发现有一个与句很影响系统性能，我们就对这条语句进行优化：
第一步：创建优化任务并执行
SQL>DECLARE
2my_task_nameVARCHAR2(30);
3my_sqltextCLOB;
4BEGIN
5my_sqltext:='selecta.table_name,b.object_idfrombigtabb,smalltaba';
6
7my_task_name:=DBMS_SQLTUNE.CREATE_TUNING_TASK(
8sql_text=>my_sqltext,
9user_name=>'DEMO',
10scope=>'COMPREHENSIVE',
11time_limit=>60,
12task_name=>'TEST_sql_tuning_task',
13description=>'TasktotuneaqueryonaspecifiedPRODUCT');
14
15dbms_sqltune.Execute_tuning_task(task_name=>'TEST_sql_tuning_task');
16END;
17/
PL/SQLproceduresuccessfullycompleted
DBMS_SQLTUNE.CREATE_TUNING_TASK就是用来创建优化任务的函数。其中，sql_text是需要优化的语句，user_name是该语句通过哪个用户执行，scope是优化范围（limited或comprehensive），time_limit优化过程的时间限制，task_name优化任务名称，description优化任务描述。dbms_sqltune.Execute_tuning_task是执行优化的函数。
第二步：查看优化建议结果
SQL>setlong10000
SQL>setlongchunksize1000
CannotSETLONGCHUNKSIZE
SQL>setlinesize100
SQL>SELECTDBMS_SQLTUNE.REPORT_TUNING_TASK('TEST_sql_tuning_task')FROMDUAL;
DBMS_SQLTUNE.REPORT_TUNING_TAS
--------------------------------------------------------------------------------
GENERALINFORMATIONSECTION
-------------------------------------------------------------------------------
TuningTaskName:TEST_sql_tuning_task
TuningTaskOwner:DEMO
Scope:COMPREHENSIVE
TimeLimit(seconds):60
CompletionStatus:COMPLETED
Startedat:11/24/200514:46:23
Completedat:11/24/200514:46:24
NumberofSQLRestructureFindings:1
-------------------------------------------------------------------------------
SchemaName:DEMO
SQLID:f5k29d73zdpsd
SQLText:selecta.table_name,b.object_idfrombigtabb,smalltaba
-------------------------------------------------------------------------------
FINDINGSSECTION(1finding)
-------------------------------------------------------------------------------
1-RestructureSQLfinding(seeplan1inexplainplanssection)
----------------------------------------------------------------
AnexpensivecartesianproductoperationwasfoundatlineID1ofthe
executionplan.
Recommendation
--------------
-Considerremovingthedisconnectedtableorviewfromthisstatementor
addajoinconditionwhichreferstoit.
Rationale
---------
Acartesianproductshouldbeavoidedwheneverpossiblebecauseitisan
expensiveoperationandmightproducealargeamountofdata.
-------------------------------------------------------------------------------
EXPLAINPLANSSECTION
-------------------------------------------------------------------------------
1-Original
-----------
Planhashvalue:3479921507
--------------------------------------------------------------------------------
|Id|Operation|Name|Rows|Bytes|Cost(%CPU)|Time
--------------------------------------------------------------------------------
|0|SELECTSTATEMENT||1474M|32G|4316K(2)|14:23:21
|1|MERGEJOINCARTESIAN||1474M|32G|4316K(2)|14:23:21
|2|TABLEACCESSFULL|SMALLTAB|1223|23237|11(0)|00:00:01
|3|BUFFERSORT||1205K|5887K|4316K(2)|14:23:21
|4|TABLEACCESSFULL|BIGTAB|1205K|5887K|3530(2)|00:00:43
--------------------------------------------------------------------------------
-------------------------------------------------------------------------------
优化建议结果分为三部分，下面简单介绍一下每个部分。
第一部分：
和所有Oracle的报告一样，第一部分总是基础信息J。
GENERALINFORMATIONSECTION
-------------------------------------------------------------------------------
TuningTaskName:TEST_sql_tuning_task
TuningTaskOwner:DEMO
Scope:COMPREHENSIVE
TimeLimit(seconds):60
CompletionStatus:COMPLETED
Startedat:11/24/200514:46:23
Completedat:11/24/200514:46:24
NumberofSQLRestructureFindings:1
-------------------------------------------------------------------------------
SchemaName:DEMO
SQLID:f5k29d73zdpsd
SQLText:selecta.table_name,b.object_idfrombigtabb,smalltaba
这部分信息包括：任务名称、任务所有者、任务范围、任务执行时间限制（前面几个信息实际上就是我们创建任务时指定的参数）、任务状态、任务开始时间、完成时间、发现的需要重新构造的问题语句数量。接下来就是schema名称、SQLID和SQL内容。
第二部分：
这部分是优化器发现的需要优化的语句，在我们的例子中，肯定只有一条：
-------------------------------------------------------------------------------
FINDINGSSECTION(1finding)
-------------------------------------------------------------------------------
1-RestructureSQLfinding(seeplan1inexplainplanssection)
----------------------------------------------------------------
AnexpensivecartesianproductoperationwasfoundatlineID1ofthe
executionplan.
Recommendation
--------------
-Considerremovingthedisconnectedtableorviewfromthisstatementor
addajoinconditionwhichreferstoit.
Rationale
---------
Acartesianproductshouldbeavoidedwheneverpossiblebecauseitisan
expensiveoperationandmightproducealargeamountofdata.
首先是在查询计划中发现的问题：在语句1的查询计划中发现有很大的笛卡尔积操作（显然，我们的语句是一个外连接操作，做的就是迪卡尔积操作）；其次是针对问题给出的建议：考虑将不需要做连接查询的表或视图去掉，或者增加一个连接条件；最后导致问题的根本原因：由于迪卡尔积是一个会产生很大数据量的消耗资源的操作，所以需要尽量避免迪卡尔积操作。
第三部分：
这一部分是SQL语句的查询计划。
-------------------------------------------------------------------------------
EXPLAINPLANSSECTION
-------------------------------------------------------------------------------
1-Original
-----------
Planhashvalue:3479921507
--------------------------------------------------------------------------------
|Id|Operation|Name|Rows|Bytes|Cost(%CPU)|Time
--------------------------------------------------------------------------------
|0|SELECTSTATEMENT||1474M|32G|4316K(2)|14:23:21
|1|MERGEJOINCARTESIAN||1474M|32G|4316K(2)|14:23:21
|2|TABLEACCESSFULL|SMALLTAB|1223|23237|11(0)|00:00:01
|3|BUFFERSORT||1205K|5887K|4316K(2)|14:23:21
|4|TABLEACCESSFULL|BIGTAB|1205K|5887K|3530(2)|00:00:43
--------------------------------------------------------------------------------
-------------------------------------------------------------------------------
这里给出的是语句优化前的原始查询计划。如果优化器认为这条语句需要重写，它还会给出重写后的查询计划。
第五章总结
哎，不多说了，总之一个字：简单！如果Oracle在这样下去，这个世界上谁都是DBA，谁都不需要DBA了。转载自：http://www.hellodba.com/reader.php?ID=160&lang=CN
                                            

                                        

                        
                        内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 点击这里给我发消息 
                    

                    

                    

                        

                         标签： 
                                                

                        

                    


                

            


            

                
相关文章推荐

                

                
            

        

        

            

            
            

                

                    
新的分享

                    

                        
                    

                

            


            

                

                    
章节导航