Printable View
I am reading on TOm Kyte performance tuning workshop and I am not on this on top 5 events on statspack report:
Code:events wait time %Total elapsed
Direct path write 5168 279 20.5
and he mentioned that there was 120 waits for direct path writes, totalling three thousandth second (as opposed to 279 seconds)
the question is how does he get 120 waits and 3,000 second???
link?Quote:
Originally posted by learning_bee
I am reading on TOm Kyte performance tuning workshop and I am not on this on top 5 events on statspack report:
Code:events wait time %Total elapsed
Direct path write 5168 279 20.5
and he mentioned that there was 120 waits for direct path writes, totalling three thousandth second (as opposed to 279 seconds)
the question is how does he get 120 waits and 3,000 second???
Davey,
I found the PFD file from one of the thread in this forum and unfortunately, I don't remember which thread it's on; however I have the PDF file and please see the attached file on STATSPACK portion.
thanks,
unfortunately, I can't upload pdf neither the zip file b/c it's too big. Anyway, attached is the snapshot of what he said
NEVER EVER LOOK INTO THE TOP 5 EVENTS OF STATSPACK REPORT.
THEY ARE ALL WRONG
Tamil
tamilselvan,
I am confused, I read so many docs and even Tom Kyte mentioned that top 5 events is one of the most important areas, plus some of the guys who really knows what they are doing in here would say the same thing.
Please let me know b/c I don't want to keep doing the wrong thing.
These were the values after making changes (pga_aggregate_taget) - he does not show the new report.Quote:
Originally posted by learning_bee
and he mentioned that there was 120 waits for direct path writes, totalling three thousandth second (as opposed to 279 seconds)
the question is how does he get 120 waits and 3,000 second???
you can't say that and not qualify your statements with examplesQuote:
Originally posted by tamilselvan
NEVER EVER LOOK INTO THE TOP 5 EVENTS OF STATSPACK REPORT.
THEY ARE ALL WRONG
Tamil
I can't update the whole pdf file for your guys and it's so annoying to capture and miss some other part, any way, I captured the 5 events after making the changes.
I still like to undertand how to calculate those numbers
Read it very carefully: three reports are mentioned, he prints #1 and #3. You'll just have to take his word about report #2.
=====
davey23uk
you can't say that and not qualify your statements with examples
====
First of all statspack report is not telling the true picture. Statspack collects statistics from all processes - foreground (user processes) and background (DBWR, LGWR, PMON, etc).
The "TOP 5 WAIT EVENTS" is now changed to "Top 5 Timed Events" in 9i b/c Oracle now realized they are not "Top 5 Wait Events" anymore and the existing statspack code is not excluding background processing time that really does not directly slowdown the foreground processes.
Most of the time waht you see in the Top 5 Timed Events will mislead you to wrong direction of tuning.
2nd Reason:
Statspack does not exclude the processes that are not finished during the interval. Example, a process starts at time T0.
I take a statspack snap for the interval T1 and T2. If I look into the report, I get a different picture and I don't even see the SQL started at time T0.
If you really want to measure and see where the real waits are happening, then you must query from v$session_event and v$session_wait when the application is running.
Can the statspack tell you exactly whether my SGA is oversized or undersized?
NO.
Can the statspack tell you how many buffers are hot buffers due to be cooled, how many buffers to be heated, and how much are free?
NO.
I can write so many questions about the statspack, but the above points are enough.
Only one thing I like in Statspack is: Top N SQL. This is the section one must concentrate initially to tune the application.
Tamil