User I/O Wait class in Top 5 Timed Foreground Events

Question

Hi Mates
In my awr report in Top 5 Timed Foreground Events, i get the below event list
Event     Waits     Time(s)     Avg wait (ms)     % DB time     Wait Class
DB CPU          25,721          58.29     
db file sequential read     67,491,952     7,710     0     17.47     User I/O
db file scattered read     7,147,112     2,560     0     5.8     User I/O
log file sync     2,926,748     1,526     1     3.46     Commit
direct path read     342,745     834     2     1.89     User I/O
So does it means that there is a issue with disk I/O on my box. since the wait class is showing as User I/O.
I am running the single instance database with oracle version 11.2 on IBM AIX server.

Answer 1

huzaifa wrote:
Hi Mates
In my awr report in Top 5 Timed Foreground Events, i get the below event list
Event                              Waits       Time(s)       Avg wait (ms)     % DB time      Wait Class
DB CPU                                             25,721                               58.29     
db file sequential read           67,491,952        7,710          0                         17.47      User I/O
db file scattered read           7,147,112        2,560          0                          5.8      User I/O
log file sync                           2,926,748        1,526          1                          3.46      Commit
direct path read                   342,745        834          2                          1.89      User I/OSo does it means that there is a issue with disk I/O on my box. since the wait class is showing as User I/O.
I am running the single instance database with oracle version 11.2 on IBM AIX server.Is this a standard one hour report on a machine with at least 8 CPUs available ?
If so then take a look at Dom Brooks comment - your average read times are in the range of 0.1 to 0.3 milliseconds - they're mostly coming out of filesystem cache (but maybe you have some very good database flashcache installed).
Your first move should probably be to take some of the memory from your file system cache and increase your buffer cache - this will probably decrease the number of reads reported and the amount of CPU used. I'd also look for statements that seem to be doing an unreasonable amount of I/O to get their end results, and check the "Segments by ... " section of the report to see which objects are seeing most I/O.
Before you mess about with ASM, you should simply check for easy ways to do less work.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Author: <b><em>Oracle Core</em></b>