Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Oracle AWR Trending - IOUG SELECT Magazine -Quarter 4 2010

Oracle AWR Trending - IOUG SELECT Magazine -Quarter 4 2010

Ratings: (0)|Views: 1,715|Likes:
Published by goyalkapil
Trending is very important for database performance
analysis. It exposes the performance profile of a
database in terms of IO, CPU usage, wait-event response
time, etc. Starting in Oracle Database 10g, AWR performance
data that is collected and stored out of the box is very helpful
in creating historical and comparative trend analysis to
gain insight into critical database performance issues. AWR
provides a rich history of Oracle performance statistics that
shows how an Oracle database system has been trending for
as long as the AWR data is retained.
Trending is very important for database performance
analysis. It exposes the performance profile of a
database in terms of IO, CPU usage, wait-event response
time, etc. Starting in Oracle Database 10g, AWR performance
data that is collected and stored out of the box is very helpful
in creating historical and comparative trend analysis to
gain insight into critical database performance issues. AWR
provides a rich history of Oracle performance statistics that
shows how an Oracle database system has been trending for
as long as the AWR data is retained.

More info:

Published by: goyalkapil on Dec 25, 2010
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Page 4 
4th Qtr 2010 
Oracle AWR (AutomaticWorkload Repository) Trending
By Kapil Goyal 
rending is very important or database perormance analysis. It exposes the perormance profle o a database in terms o IO, CPU usage, wait-event response time, etc. Starting in Oracle Database 10 
 , AWR perormance data that is collected and stored out o the box is very helpul in creating historical and comparative trend analysis to gain insight into critical database perormance issues. AWR provides a rich history o Oracle perormance statistics that shows how an Oracle database system has been trending or as long as the AWR data is retained.
So Where Do We Start?
 Any statistic in AWR can be trended quite easily. The AWR report consists of SQLs running against various “DBA_HIST_%” views taking the differencebetween two snapshots at a time. This implies that we can develop and executesimilar SQL against those views to report the trend for any required statistic ordatabase wait event. When analyzing AWR reports during the time a performance problem manifested,and some wait event or response time gures seem high or a new set of SQLstatements come up, it is always a good idea to go back in history and check how the identied events, statistics, SQL or job behaved during similar timespreviously—it could yesterday or last week or even last month. Of course, this
Side Note:
AWR is not a replacement for real time monitoring; it contains historical dataand can be used to investigate what happened or what caused the performance issue.One important difference between STATSPACK in Oracle9
and AWR in Oracle Database10
is that 9
exposes the source code for statspack while 10
does not. However, youcan use most of the 9
code scripts to understand AWR structures making it less hard towrite queries against 10
DBA_HIST* tables. For your information, STATSPACK sourcecode in 9
can be seen in the $ORACLE_HOME/rdbms/admin/sprepins.sql le. This leprovides a fair idea about the “STATS$_%” tables used to store and generate STATSPACkreports. In most cases, you can use the same SQL and replace the corresponding“STAT$_%” tables with “DBA_HIST_%” tables.
comparison needs to be done when same type of user jobs were running(same load), just to rule out whether that average response time is normal forthis database. If a job had the same response time earlier and users were notcomplaining, it usually means that the problem is somewhere else and we need todig further, probably using specic SQL trace for that portion of the application.
What is AWR?
 AWR takes periodic snapshots of performance statistics (by default every hour)and exposes this using DBA_HIST* views. Please note that AWR is a licensedproduct under Diagnostic Pack; hence, even to access these views directly, requireslicenses needs to be purchased. Oracle Database 11
further expands on this.For example, there are 79 DBA_HIST* views available in Oracle 10
SQL> select count (*) from dictionary where table_name like ‘DBA_HIST%’;COUNT(*)----------79
On the other hand, there are 100 DBA_HIST* views available in Oracle 11g(
Select count(*) from dictionary where table_name like ‘DBA_HIST%’;COUNT(*)----------------100
How Much Space Does AWR Use?
The following query can be used to see the current occupied space by AWR data.
Select SPACE_USAGE_KBYTES from v$sysaux_occupants where occupant_name like‘%AWR%’;SPACE_USAGE_KBYTES------------------4,384,6401 row selected.
Note that this size will vary depending on retention period, the snapshotfrequency, the number of datales, etc. You can monitor this space in adevelopment/test instance to project space requirements in case you want toincrease the retention period in production.
 You can use the following query to see the current retention policy.
Selectextract( day from snap_interval) *24*60+extract( hour from snap_interval) *60+extract( minute from snap_interval ) “Snapshot Interval”,extract( day from retention) *24*60+extract( hour from retention) *60+extract( minute from retention ) “Retention Interval(in Minutes)” ,extract(day from retention) “Retention (in Days)” from dba_hist_wr_control;Snapshot Interval Retention Interval(in Minutes) Retention (in Days)----------------- ------------------------------ -------------------30 129,600 90
4th Qtr 201
Page 5 
I personally prefer to have 35 days retention, so that it can cover the wholemonth. If you can afford to store this data for longer periods, then I wouldstrongly suggest you do that. In any case, to trend data for a specied period, you will need to retain the AWR data for that period.
Benefts o AWR?
The following list includes some key benets of Automatic Workload repository:
Easy to nd recent spike in load
Helpful in capacity planning
Design Load testing based on current capacity and load
Easy to write queries against AWR tables
SQL statistics history 
Easy to nd if the SQL execution plan for particular SQL statement thatchanged recently I have detailed the following AWR scripts that I use in my day-to-day tasks.These are based upon DBA_HIST* tables and trends that same data that a setof AWR reports would have otherwise provided. You can modify the script totrend the data for particular hours, days, weeks or for the whole data availablebased on the AWR retention you have set for that database.
System Event Trending
The following script can be very helpful when you want to see how an event trended
over a period of time. The script takes two arguments—date and event name.
alter session set nls_date_format=’dd-mon-yy’;set lines 150 pages 100 echo off feedback offcol date_time heading ‘Date time|mm/dd/yy_hh_mi_hh_mi’ for a25col event_name for a26col waits for 99,999,999,999 heading ‘Waits’col time for 99,999 heading ‘Total Wait|Time(sec)’col avg_wait_ms for 99,999 heading ‘Avg Wait|(ms)’prompt “Enter the date in DD-Mon-YY Format:”WITH system_event AS (selectsn.begin_interval_time begin_interval_time,sn.end_interval_time end_interval_time,se.event_name event_name,se.total_waits e_total_waits,lag(se.total_waits,1) over (order by se.snap_id) b_total_waits,se.total_timeouts e_total_timeouts,lag(se.total_timeouts,1) over (order by se.snap_id) b_total_timeouts,se.time_waited_micro e_time_waited_micro,lag(se.time_waited_micro,1) over (order by se.snap_id) b_time_waited_microfrom dba_hist_system_event se,dba_hist_snapshot snwhere 
and se.snap_id = sn.snap_idand se.dbid = sn.dbidand se.instance_number = sn.instance_numberand se.dbid = (select dbid from v$database)and se.instance_number = (select instance_number from v$instance) 
and se.event_name=’&event_name’
)selectto_char(se1.BEGIN_INTERVAL_TIME,’mm/dd/yy_hh24_mi’)||to_char(se1.END_INTERVAL_TIME,’_hh24_mi’) date_time,se1.event_name,se1.e_total_waits-nvl(se1.b_total_waits,0) waits,(se1.e_time_waited_micro - nvl(se1.b_time_waited_micro,0)) / 1000000 time,((se1.e_time_waited_micro - nvl(se1.b_time_waited_micro,0)) / 1000) /(se1.e_total_waits - nvl(se1.b_total_waits,0)) avg_wait_msfrom system_event se1where (se1.e_total_waits-nvl(se1.b_total_waits,0)) > 0and nvl(se1.b_total_waits,0) > 0/
Sample Output
SQL> @event_response“Enter the date in DD-Mon-YY Format:”Enter value for date: 29-jan-10old 15: trunc(sn.begin_interval_time) =’&Date’new 15: trunc(sn.begin_interval_time) =’29-jan-10’Enter value for event_name: db file sequential readold 21: and se.event_name=’&event_name’new 21: and se.event_name=’db file sequential read’Total AvgDate time Wait Time Waitmm/dd/yy_hh_mi_hh_mi EVENT_NAME Waits (sec) (ms)----------------------- ------------------------- ---------- ---------- -------01/29/10_01_00_02_00 db file sequential read 551,356 4,500 801/29/10_02_00_03_00 db file sequential read 1,114,616 7,921 701/29/10_03_00_04_00 db file sequential read 764,481 5,926 801/29/10_04_00_05_00 db file sequential read 845,195 6,633 801/29/10_05_00_06_00 db file sequential read 1,385,501 8,501 601/29/10_06_00_07_00 db file sequential read 3,785,824 14,703 401/29/10_07_00_08_00 db file sequential read 2,393,513 6,996 301/29/10_08_00_09_00 db file sequential read 2,590,092 6,273 201/29/10_09_00_10_00 db file sequential read 2,322,715 5,390 201/29/10_10_00_11_00 db file sequential read 2,806,934 6,913 201/29/10_11_00_12_00 db file sequential read 2,691,573 3,501 101/29/10_12_00_13_00 db file sequential read 1,737,420 3,349 201/29/10_13_00_14_00 db file sequential read 489,453 2,297 501/29/10_14_00_15_00 db file sequential read 791,114 2,842 4
Load Profle Trending
The rst page of the AWR report gives us lot of information about databasebehavior such as whether database is more read intensive or write intensive(depending upon Physical Reads/sec or Physical Writes/Sec statistics), whetherit does lots of logical IO/sec, has a high OLTP component (as derived fromhigher number of Transactions/Sec), or does a lot of parsing (Hard or soft).By looking at a one-hour-interval report you can get some idea, but if you canlook at the trend for the whole day, you will get a broader picture as somedatabases trend from an OLTP workload during the day and DSS workloadduring off hours.The Load Prole section also helps to determine if load has changed over timecompared to the baseline (i.e., an AWR report when the system was healthy).There is no good or best value for these statistics. Although these numbers varies by database and application, when the number of Logons/sec more than10 or the database has a higher hard parse/sec (>100 or so), this could be anindication of an underlying conguration or application design issue thatimplements itself as a performance issue. In this regard, the number of Logical Reads/sec is also a good statistics to look at.The script below trends the physical reads/sec.
alter session set nls_date_format=’dd-mon-yy’;set lines 130 pages 1000 echo off feedback offcol stat_name for a25col date_time for a20col BEGIN_INTERVAL_TIME for a20col END_INTERVAL_TIME for a20prompt “Enter the date in DD-Mon-YY Format and Stats you want to trend like‘redo size’,’physical reads’,’physical writes’,’session logical reads’ etc.”WITH sysstat AS (selectsn.begin_interval_time begin_interval_time,
Page 6 
4th Qtr 2010 
sn.end_interval_time end_interval_time,ss.stat_name stat_name,ss.value e_value,lag(ss.value,1) over (order by ss.snap_id) b_valuefrom dba_hist_sysstat ss,dba_hist_snapshot snwhere 
and ss.snap_id = sn.snap_idand ss.dbid = sn.dbidand ss.instance_number = sn.instance_numberand ss.dbid = (select dbid from v$database)and ss.instance_number = (select instance_number from v$instance) 
and ss.stat_name=’&stat_name’
)selectto_char(BEGIN_INTERVAL_TIME,’mm/dd/yy_hh24_mi’)|| to_char(END_INTERVAL_TIME,’_hh24_mi’) date_time,stat_name,round((e_value-nvl(b_value,0))/(extract( day from (end_interval_time-begin_interval_time) )*24*60*60+extract( hour from (end_interval_time-begin_interval_time) )*60*60+extract( minute from (end_interval_time-begin_interval_time) )*60+extract( second from (end_interval_time-begin_interval_time)) ), 0) per_secfrom sysstatwhere (e_value-nvl(b_value,0)) > 0and nvl(b_value,0) > 0/
Oracle AWR (Automatic Workload Repository) Trending 
Sample Output
SQL> @lpSession altered.“Enter the date in DD-Mon-YY Format and Stats you want to trend like ‘redosize’,’physical reads’,’physical writes’,’session logical reads’ etc.”Enter value for date: 29-jan-10old 11: trunc(sn.begin_interval_time) =’&Date’new 11: trunc(sn.begin_interval_time) =’29-jan-10’Enter value for stat_name: physical readsold 17: and ss.stat_name=’&stat_name’new 17: and ss.stat_name=’physical reads’DATE_TIME STAT_NAME PER_SEC-------------------- ------------------------- ----------01/29/10_01_00_02_00 physical reads 434701/29/10_02_00_03_00 physical reads 455401/29/10_03_00_04_00 physical reads 470801/29/10_04_00_05_00 physical reads 497201/29/10_05_00_06_00 physical reads 679601/29/10_06_00_07_00 physical reads 668501/29/10_07_00_08_00 physical reads 475801/29/10_08_00_09_00 physical reads 583201/29/10_09_00_10_00 physical reads 521701/29/10_10_00_11_00 physical reads 486701/29/10_11_00_12_00 physical reads 5685

Activity (7)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads
kmufasa liked this
sartison4271 liked this
madhuparak liked this
goyalkapil liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->