oracle 10g性能调优

原文http://www.oracle.com/technetwork/articles/schumacher-analysis-099313.html

数据库Oracle 10 g,许多以前难以得到的响应时间指标马上就可以获得了。

历史上,为了获得最大的数据库性能,Oracle dba和性能分析人士为获得可靠的响应时间指标体系以及用户会话活动打了一场艰苦的战斗。dba一直面临的问题有两个方面:第一,确定数据库或用户会话花费他们的时间到底在哪里;第二,确定客观自然的用户体验。

考虑到在数据库中所有可能的活动和互动,这些任务是非比寻常的。Oracle等待接口,介绍了许多版本以前对于指导怎么使用它的管理员来说一直是一个伟大的启动,即使它缺乏告诉DBA系统或用户会话如何有效地处理事务或查询的理想能力。启用和研读跟踪文件可以获得这种层次的细节,但对大多数劳累的dba需要管理大型的数据库集群,这种练习是一种奢侈。

幸运的是,那些已经升级到Oracle dba 10 g的DBA们会发现主要响应时间系统的改进提供一个更好的图片展示系统和会话级响应时间指标系统。最重要的是,Oracle数据库自动诊断监控系统(ADDM)提供了洞察响应时间和更多信息通过自动收集统计分析,识别问题域,甚至通过Oracle Enterprise Manager Grid Control GUI提供建议。

此外,这儿最值得我们讨论的是,Oracle数据库10g的历史机制它允许dba回看之前的结果以实现自己的响应时间趋势分析,这有助于他们确定峰值和非高峰时间的事务/系统时间以及通过延长批周期或ETL作业定位流氓程序和SQL。

在这篇文章中,我将探讨在系统,会议,和SQL的水平使用其中的一些历史机制。关于ADDM的更多信息,请参阅甲骨文文档以及在”Arup Nanda's "Oracle Database 10g: Top 20 Features for DBAs”的“ADDM和SQL调优顾问“分期。

系统级响应时间分析

从全局或系统级别考虑,dba通常希望得到这些问题的答案:
总的来说,我的数据库运行得怎么样?定义效率的是什么?
我的用户体验平均响应时间是多少?
哪些活动最影响总体响应时间?

在Oracle 10 g数据库之前这些问题的答案对于DBA来说已经相当难以捉摸,但现在这样的指标可以是比较容易捕捉如果你碰巧使用最新和最伟大的Oracle数据库。
首先,部分答案如何,一般来说,运行中的数据库可以通过发送该查询在数据库Oracle 10 g中获得:

selectMETRIC_NAME,VALUE
fromSYS.V_$SYSMETRIC
whereMETRIC_NAMEIN('DatabaseCPUTimeRatio','DatabaseWaitTimeRatio')AND
INTSIZE_CSEC=
(selectmax(INTSIZE_CSEC)fromSYS.V_$SYSMETRIC);

METRIC_NAMEVALUE
----------------------------------------
DatabaseWaitTimeRatio6
DatabaseCPUTimeRatio94

The Oracle Database 10gV$SYSMETRIC view contains several excellent response-time metrics,two of which are the Database Wait Time Ratio and Database CPU Time Ratio. The query above shows the latest snapshot of these two statistics,which help you determine if your database is currently experiencing a high percentage of waits/bottlenecks vs. smoothly running operations. The Database CPU Time Ratio is calculated by dividing the amount of CPU expended in the database by the amount of "database time," which is defined as the time spent by the database on user-level calls (with instance background process activity being excluded). High values (90-95+ percent) are good and indicate few wait/bottleneck actions,but take this threshold only as a general rule of thumb because every system is different.

You can also take a quick look over the last hour to see if the database has experienced any dips in overall performance by using this query:

selectend_time,value
fromsys.v_$sysmetric_history
wheremetric_name='DatabaseCPUTimeRatio'
orderby1;

END_TIMEVALUE
------------------------------
22-NOV-200410:00:3898
22-NOV-200410:01:3996
22-NOV-200410:02:3799
22-NOV-200410:03:38100
22-NOV-200410:04:3799
22-NOV-200410:05:3877
22-NOV-200410:06:36100
22-NOV-200410:07:3796
22-NOV-200410:08:39100
.
.

And,you can get a good idea of the minimum,maximum,and average values of overall database efficiency by querying the V$SYSMETRIC_SUMMARY view with a query such as this:selectCASEMETRIC_NAME WHEN'SQLServiceResponseTime'then'SQLServiceResponseTime(secs)' WHEN'ResponseTimePerTxn'then'ResponseTimePerTxn(secs)' ELSEMETRIC_NAME ENDMETRIC_NAME,CASEMETRIC_NAME WHEN'SQLServiceResponseTime'thenROUND((MINVAL/100),2) WHEN'ResponseTimePerTxn'thenROUND((MINVAL/100),2) ELSEMINVAL ENDMININUM,CASEMETRIC_NAME WHEN'SQLServiceResponseTime'thenROUND((MAXVAL/100),2) WHEN'ResponseTimePerTxn'thenROUND((MAXVAL/100),2) ELSEMAXVAL ENDMAXIMUM,CASEMETRIC_NAME WHEN'SQLServiceResponseTime'thenROUND((AVERAGE/100),2) WHEN'ResponseTimePerTxn'thenROUND((AVERAGE/100),2) ELSEAVERAGE ENDAVERAGE fromSYS.V_$SYSMETRIC_SUMMARY whereMETRIC_NAMEin('CPUUsagePerSec','CPUUsagePerTxn','DatabaseCPUTimeRatio','DatabaseWaitTimeRatio','ExecutionsPerSec','ExecutionsPerTxn','ResponseTimePerTxn','SQLServiceResponseTime','UserTransactionPerSec') ORDERBY1 METRIC_NAMEMINIMUMMAXIMUMAVERAGE ------------------------------------------------------------ CPUUsagePerSec071 CPUUsagePerTxn1298 DatabaseCPUTimeRatio6110094 DatabaseWaitTimeRatio0395 ExecutionsPerSec2608 ExecutionsPerTxn1616441 ResponseTimePerTxn(secs)0.28.08 SQLServiceResponseTime(sec000 UserTransactionPerSec010

The query above contains more response-time metrics than simply the Database CPU and Wait Time Ratios (we'll cover those later),but you can see the benefit in being able to acquire this information. For this particular instance,the average Database CPU Time Ratio is 94,which is well within our acceptable limits.The next question DBAs pose at the system level involves the average level of response time that their user community is experiencing. (Prior to Oracle Database 10gthis type of data was difficult to capture,but not anymore.) The query shown above that interrogates the V$SYSMETRIC_SUMMARY view tells us what we need to know. If complaints of unacceptable response times are mounting from users,the DBA can check the Response Time Per Txn and SQL Service Response Time metrics to see if a database issue exists. For example,the statistics shown above report that the maximum response time per user transaction has been only .28 second,with the average response time being a blazing .08 second. Oracle certainly wouldn't be to blame in this case.

If,however,response times are longer than desired,the DBA will then want to know what types of user activities are responsible for making the database work so hard. Again,before Oracle Database 10g,this information was more difficult to acquire,but now the answer is only a query away:

selectcasedb_stat_name
when'parsetimeelapsed'then
'softparsetime'
elsedb_stat_name
enddb_stat_name,casedb_stat_name
when'sqlexecuteelapsedtime'then
time_secs-plsql_time
when'parsetimeelapsed'then
time_secs-hard_parse_time
elsetime_secs
endtime_secs,casedb_stat_name
when'sqlexecuteelapsedtime'then
round(100*(time_secs-plsql_time)/db_time,2)
when'parsetimeelapsed'then
round(100*(time_secs-hard_parse_time)/db_time,2)
elseround(100*time_secs/db_time,2)
endpct_time
from
(selectstat_namedb_stat_name,round((value/1000000),3)time_secs
fromsys.v_$sys_time_model
wherestat_namenotin('DBtime','backgroundelapsedtime','backgroundcputime','DBCPU')),(selectround((value/1000000),3)db_time
fromsys.v_$sys_time_model
wherestat_name='DBtime'),3)plsql_time
fromsys.v_$sys_time_model
wherestat_name='PL/SQLexecutionelapsedtime'),3)hard_parse_time
fromsys.v_$sys_time_model
wherestat_name='hardparseelapsedtime')
orderby2desc;


DB_STATTIME_SECSPCT_TIME
----------------------------------------------
sqlexecuteelapsedtime13263.70745.84
PL/SQLexecutionelapsedtime13234.73845.74
hardparseelapsedtime1943.6876.72
softparsetime520.5841.8
.
.

The example output above shows a database that has spent the vast majority of its time handling SQL and PL/SQL requests. Complete descriptions of all the statistics supported by the V$SYS_TIME_MODEL view can be foundhere.In addition to active time,a DBA will want to know the global wait times as well. Prior to Oracle Database 10g,a DBA had to view individual wait events to understand waits and bottlenecks,but now Oracle provides a summary/rollup mechanism for waits via wait classes:

selectWAIT_CLASS,TOTAL_WAITS,round(100*(TOTAL_WAITS/SUM_WAITS),2)PCT_WAITS,ROUND((TIME_WAITED/100),2)TIME_WAITED_SECS,round(100*(TIME_WAITED/SUM_TIME),2)PCT_TIME
from
(selectWAIT_CLASS,TIME_WAITED
fromV$SYSTEM_WAIT_CLASS
whereWAIT_CLASS!='Idle'),(selectsum(TOTAL_WAITS)SUM_WAITS,sum(TIME_WAITED)SUM_TIME
fromV$SYSTEM_WAIT_CLASS
whereWAIT_CLASS!='Idle')
orderby5desc;

WAIT_CLASSTOTAL_WAITSPCT_WAITSTIME_WAITED_SECSPCT_TIME
--------------------------------------------------------------
UserI/O22452047.484839.4354.39
SystemI/O24383878.122486.2127.94
Application9203853.07513.565.77
Other39962.13422.364.75
Commit200872.67284.763.2
Network2413321380.38162.261.82
Concurrency6867.02102.631.15
Configuration39377.1386.21.97

It's much easier to tell now that the bulk of overall wait time is due,for example,to user I/O waits than to try to tally individual wait events to get a global picture. As with response-time metrics,you can also look back in time over the last hour with a query like this one:selectto_char(a.end_time,'DD-MON-YYYYHH:MI:SS')end_time,b.wait_class,round((a.time_waited/100),2)time_waited fromsys.v_$waitclassmetric_historya,sys.v_$system_wait_classb wherea.wait_class#=b.wait_class#and b.wait_class!='Idle' orderby1,2; END_TIMEWAIT_CLASSTIME_WAITED ---------------------------------------------- 22-NOV-200411:28:37Application0 22-NOV-200411:28:37Commit.02 22-NOV-200411:28:37Concurrency0 22-NOV-200411:28:37Configuration0 22-NOV-200411:28:37Network.01 22-NOV-200411:28:37Other0 22-NOV-200411:28:37SystemI/O.05 22-NOV-200411:28:37UserI/O0 . .

You can,of course,just focus on a single SID with the V$SESS_TIME_MODEL view and obtain data for all statistical areas of a session. You can also view current session wait activity using the new wait classes using the following query:selecta.sid,b.username,a.wait_class,a.total_waits,2)time_waited_secs fromsys.v_$session_wait_classa,sys.v_$sessionb whereb.sid=a.sidand b.usernameisnotnulland a.wait_class!='Idle' orderby5desc; SIDUSERNAMEWAIT_CLASSTOTAL_WAITSTIME_WAITED_SECS ------------------------------------------------------- 257SYSMANApplication35610475.22 255SYSMANCommit1450825.76 257SYSMANCommit2502622.02 257SYSMANUserI/O1192419.98 . . .

After this stage,you can check the standard individual wait events as you've been able to do in earlier versions of Oracle with V$SESSION_WAIT and V$SESSION_EVENT. You'll also find the new wait classes in these two modified views with Oracle Database 10g.If you need to look back in time to discover what sessions were logged on and consuming the most resources,you can use the following query. In the example below,we're looking at activity from midnight to 5 a.m. on November 21,2004,that involved user I/O waits:

selectsess_id,username,program,wait_event,sess_time,round(100*(sess_time/total_time),2)pct_time_waited
from
(selecta.session_idsess_id,decode(session_type,'background',session_type,c.username)username,a.programprogram,b.namewait_event,sum(a.time_waited)sess_time
fromsys.v_$active_session_historya,sys.v_$event_nameb,sys.dba_usersc
wherea.event#=b.event#and
a.user_id=c.user_idand
sample_time>'21-NOV-0412:00:00AM'and
sample_time<'21-NOV-0405:00:00AM'and
b.wait_class='UserI/O'
groupbya.session_id,c.username),a.program,b.name),(selectsum(a.time_waited)total_time
fromsys.v_$active_session_historya,sys.v_$event_nameb
wherea.event#=b.event#and
sample_time>'21-NOV-0412:00:00AM'and
sample_time<'21-NOV-0405:00:00AM'and
b.wait_class='UserI/O')
orderby6desc;

SESS_IDUSERNAMEPROGRAMWAIT_EVENTSESS_TIMEPCT_TIME_WAITED
-------------------------------------------------------------------------
242SYSexp@RHAT9Kdbfilescatteredread350297833.49
242SYSoracle@RHAdbfilesequentialread236815322.64
242SYSoracle@RHAdbfilescatteredread111389610.65
243SYSoracle@RHAdbfilesequentialread9921689.49

The Oracle Database 10gV$ACTIVE_SESSION_HISTORY view comes into play here to provide an insightful look back in time at session experiences for a given time period. This view gives you a lot of excellent information without the need for laborious tracing functions. We'll see more use of it in the next section,which deals with analyzing the response times of SQL statements.SQL Response-Time Analysis

Examining the response time of SQL statements became easier in Oracle9i,and with Oracle Database 10g,DBAs have many tools at their disposal to help them track inefficient database code.

Historically the applicable V$ view here has been V$SQLAREA. Starting with Oracle9i,Oracle added the ELAPSED_TIME and CPU_TIME columns,which have been a huge help in determining the actual end user experience of a SQL statement execution (at least,when dividing them by the EXECUTIONS column,which produces the average amount of time per execution).

In Oracle Database 10g,six new wait-related and timing columns have been added to V$SQLAREA:

• APPLICATION_WAIT_TIME

• CONCURRENCY_WAIT_TIME

• CLUSTER_WAIT_TIME

• USER_IO_WAIT_TIME

• PLSQL_EXEC_TIME

• JAVA_EXEC_TIME

The new columns are helpful in determining,the amount of time that a procedure spends in PL/SQL code vs. standard SQL execution,and if a SQL statement has experienced any particular user I/O waits. For example,a query you could use to find the top five SQL statements with the highest user I/O waits would be:select* from (selectsql_text,sql_id,elapsed_time,cpu_time,user_io_wait_time fromsys.v_$sqlarea orderby5desc) whererownum<6; SQL_TEXTSQL_IDELAPSED_TIMECPU_TIMEUSER_IO_WAIT_TIME -------------------------------------------------------------------------- select/*+rule*/bucketdb78fxqxwxt747815369190009393423 SELECT:"SYS_B_0"FROMSYagdpzr94rf6v36182205101702262649 selectobj#,type#,ctime,m04xtrk7uyhkn28815527167680401345 selectgrantee#,privilege2q93zsrvbdw42856575519619114803 select/*+rule*/bucket96g93hntrzjt94110283754542606

Of course,getting the SQL statements with the highest elapsed time or wait time is good,but you need more detail to get to the heart of the matterwhich is where the V$ACTIVE_SESSION_HISTORY view again comes into play. With this view,you can find out what actual wait events delayed the SQL statement along with the actual files,objects,and object blocks that caused the waits (where applicable).For example,let's say you've found a particular SQL statement that appears to be extremely deficient in terms of user I/O wait time. You can issue the following query to get the individual wait events associated with the query along with the corresponding wait times,files,and objects that were the source of those waits:

selectevent,time_waited,owner,object_name,current_file#,current_block#
fromsys.v_$active_session_historya,sys.dba_objectsb
wheresql_id='6gvch1xu9ca3g'and
a.current_obj#=b.object_idand
time_waited<>0;

EVENTTIME_WAITEDOWNEROBJECT_NAMEfileblock
-------------------------------------------------------------------------
dbfilesequentialread27665SYSMANMGMT_METRICS_1HOUR_PK329438
dbfilesequentialread3985SYSMANSEVERITY_PRIMARY_KEY352877

gmakes it a lot easier to conduct response-time analysis on SQL statements with simplified data dictionary views,as opposed to the time-consuming trace-and-digest method.Conclusion

DBAs and performance analysts who manage the performance of Oracle Database 10gwill find many of the response-time metrics they've yearned for over the years now at their fingertips in the latest release of Oracle's flagship database. Such statistics will help accelerate the process of finding the proverbial needle in the haystack of large and complex database performance situations.

Oracle性能调优:时间的有限和无限
http://www.uml.org.cn/sjjm/200606204.htm