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
Awr Report Analysis

Awr Report Analysis

Ratings: (0)|Views: 6,770 |Likes:
Published by maheshsrikakula1162

More info:

Published by: maheshsrikakula1162 on Nov 07, 2009
Copyright:Attribution Non-commercial


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





Statspack/AWR analysis
In stead of using ratios, such as the buffer cache hit ratio, or single figures taken out of context thisdocuments shall focus on the following the equation:response time = service time + wait timeR = S + Wwhich basically says that the
response time
perceived by the user consist of 
service time
and waittime
.The service time is the time
spent by the CPU actively working
on your request, and the wait time isthe time
you spend waiting for some resource to respond or become available
. When you e.g.execute a SQL statement that is doing some index lookup, the CPU time involved may be inprocessing blocks in the buffer cache, scanning an index block for a certain value and getting your requested row out of the data block. To do this, Oracle may have to read the data block from the disk,which incurs a wait time until the disk responds. In more complex cases, you may spend CPUprocessing PL/SQL and you may wait for a lock or for Oracle to write data to the redo log file when youdo a commit.The general idea behind this method is to identify in some detail what the components of the servicetime and the wait time are and simply order these. The component at the top is the one that should bethe first one to tune. As a result, you will not make conclusions like “My buffer cache hit ratio is too low,so I better increase the cache”, if I/O is not causing any trouble. And you will not say, “I must reducemy 20 second latch wait time”, if you are using 20 minutes of CPU processing SQL. A secondobservation in the method is that tuning something that is taking long time can be done both byreducing the time (such as using faster disks) or reducing the number of times (such as making fewer disk reads). Hence, the steps involved in this method that we will refer to as
time based tuning
, aresimply:
1. Identify the service time and the wait time and the components of these2. Order all time components3. Start your tuning effort from the top of this list4. For each entry in the list, either reduce the cost per execution, or the number of executions
Remember to separate OLTP and Batch activity when you run STATSPACK, since they usuallygenerate different types of waits.Since every system is different, the above list is a general list of things you should
check in your STATSPACK output:
Top 5 wait events (timed events)
Load profile
Instance efficiency hit ratios
Wait events
Latch waits
Instance activity
File I/O and segment statistics
Memory allocation
Buffer waits
Hit ratios
are good indicators of the health of your system. A large increase or dropfrom day to day is an indicator of a major change that needs to be investigated.Generally,
buffer and library cache hit ratios
should be greater than 95 percent for OLTP, but they could be lower for a data warehouse that genrally do many full table scans.
Tuning by wait events
is one of the best possible reactive tuning methods.
The top 5 wait events
reveal to you the largest issues on your system at the macro level.Rarely do they point you to a specific problem. Other parts of AWR will tell youwhy you are receiving the top 5 waits.Tuning
the top 25 buffer get
top 25 physical get queries
has yielded systemperformance gains of anywhere from 5 to 5000 percent. The SQL section of theSTATSPACK report tells you which queries to potentially tune first.The top 10 percent of your SQL statements should not be more than 10 percent of your buffer gets or disk reads.If the
free buffers inspected
divided by the
free buffer scans
equals less than 1, the
parameter may need to be increased.The “
sorts (disk)
” statistic divided by the “
sorts (memory)
” should not be above 1–5percent. If it is, you should increase the
)parameter in the initialization file (given that physical memory is availableto do this). Remember that the memory allocated for Sort_Area_Size is a per-user valueand PGA_AGGREGATE_TARGET is across all sessions.Latches are like locks on pieces of memory (or memory buffers). If the latch
hit ratio isbelow 99 percent
, there is a serious issue, since not even the lock to get memorycould be gotten.Segment statistics are a great way to pinpoint performance problem to a given table,index, or partition. Oracle 10gR2 contains many segment-level statistics in both theAWR Report and STATSPACK.If the PINHITRATIO is less than 95 percent when the report is run for an extendedperiod of time, the SHARED_POOL_SIZE is probably too small for your best systemperformance. If the reloads are greater than 1 percent, this also points to aSHARED_POOL_SIZE that is too small.You do not set maxtrans in 10g (it defaults to 255).Never go to the block level unless you absolutely have to go there. The block level is agreat place to find hot block and ITL issues, but it takes a lot of time and energy on thepart of an advanced DBA to pinpoint problems at this level.The ADDM Report can be a helpful tuning utility, but ADDM is better used throughOracle’s Grid Control for maximum benefits.
Time Model Statistics
In both Oracle 10.2 and Oracle 11.1 there are
19 time model statistics
.There are no differences between the time model statistics in the aforementioned versions.
The following table shows the 19 time model statistics in Oracle 11.1:
 background cpu time background elapsed timeconnection management call elapsed timeDB CPU
DB time
failed parse (out of shared memory) elapsed timefailed parse elapsed timehard parse (bind mismatch) elapsed timehard parse (sharing criteria) elapsed timehard parse elapsed timeinbound PL/SQL rpc elapsed timeJava execution elapsed time parse time elapsedPL/SQL compilation elapsed timePL/SQL execution elapsed timerepeated bind elapsed timeRMAN cpu time (backup/restore)sequence load elapsed timesql execute elapsed time
Time model statistics show the amount of CPU time that has been required to complete each type of database processing work.( see above table )These statistics can be obtained by
StatisticsViewsThe time model views differ from each other in that the V$
 _TIME_MODEL view stores timinginformation for 
individual sessions
while the V$
 _TIME_MODEL view provides information at
instance level
. As a result, you won't find the column for SESSION_ID in the V$SYS_TIME_MODELview. In addition, V$SYS_TIME_MODEL records information historically from instance startup, sodon't be concerned if you add up all of the time spent by the current indiviudal sessions and it doesn'tmatch the DBTIME value in V$SYS_TIME_MODEL view. One last thing, use the timings as a relativereference, they may not add up exactly because of the way they are recorded by Oracle.The most important time model statistic is
DB time
, which represents the total time spent by Oracle toprocess all database calls. In fact, it describes the total database workload. DB time is calculated byaggregating the CPU and all non-idle wait times for all sessions in the database after the last startup.

Activity (99)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
vishaalkumar liked this
mkghai liked this
Victor Bulychev liked this
Amit Khosla liked this
drummerr liked this
jelopez_2000 liked this
Marcio Souza 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)//-->