AWR-Avg wait(ms) and the right storage platfom

Question

Dears,
I have just one question to clear relatively to a conclusion I can make or not when reading AWR. Let's take the following Top 5 Timed Events
Top 5 Timed Events                                         Avg %Total
~~~~~~~~~~~~~~~~~~                                        wait   Call
Event                                 Waits    Time (s)   (ms)   Time Wait Class
CPU time                                            356          94.5
CSS initialization                        8          13   1647    3.5      Other
db file sequential READ               2,428           3      1    0.8   User I/O
control file sequential READ          4,547           3      1    0.7 System I/O
log file parallel WRITE                 333           2      6    0.5 System I/O
----------------------------------------------------------------------------------When looking to the 1 ms of Avg wait to read a single leaf block (from disk when not in cache), can I conclude that the machine has a very acceptable storage service that services a physical I/O very quickly?
And when looking to the following second example (where I have deliberately exagerated the Avg Wait(ms) times)
Top 5 Timed Foreground Events
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                            Avg
                                                            wait         % DB
Event                                 Waits     Time(s)   (ms)   time Wait Class
db file sequential read             465,020       3,969    29  47.4 User I/O
DB CPU                                              995         11.9
db file parallel read                 2,251         322    143  3.8 User I/O
db file scattered read               15,268         153     30  1.8 User I/O
gc current block 2-way              108,739         116      1  Could I also "jump" to a conclusion that those average wait time for single I/O(29 ms) or multi block reads(30 ms) are serviced by a slow storage service?
Thanks for your help
Mohamed Houri

Answer 1

Hi Randolf,
I agree that if an AWR looks like this, it doesn't necessarily mean that the database doesn't have any performance problems. Yes, there can still be inefficient plans. But those inefficient plans in this case aren't a global problem. I.e. if the system still has free CPUs available, then tuning them won't have a global effect. Imagine that you have a database with CPU time responsible for 95% of DB time, but only 10% of the host CPU. Imagine that you find a SQL statement that is responsible for a large portion of the CPU usage within the database. There is a good chance that this statement has an inefficient plan which can be improved by tuning -- but in this case it would only make sense if that statement is important on its own. If that is not the case (e.g. the statement is a part of a batch job and no one care whether it completes within 5 minutes or 10 hours) then tuning it would be essentially a waste of time -- in the very best case you would reduce DB CPU usage from 10% to 5% or 1%, which no one will ever notice.
This is very different from cases when DB time is dominated by I/O- or concurrency-related waits (when top-down approach works fine).
So that's one of the reasons that I'm saying that high CPU time is not a problem. Another reason is that people often tend to perceive high CPU time % in the AWR report as an indication that the system is running out of CPU, which is generally wrong.
Best regards,
Nikolay