This is why statspack is sometimes useless. Your
"db_file_sequential_read" wait is meaningless unless
you know which SQL command(s) cause(s) the largest number
of those read events. Without the particular SQL to tune,
the only advice I can give you is to truncate tables until
the "disk read" problem goes away. On the other hand, you're
checkpointing a lot (control & redo files I/O is indicating
that). How big are redo log files? How many of them do you have?
Is the disk where redo files reside "hot"?
On 02/04/2004 02:25:41 PM, Raghu Kota (WBTQ) wrote:
>
>
> Hi Friends,
>
> I have concern regarding wait events got from statspack, So dilemma
> is
> =
> what action I need to take now?? Any ideas will appreciated. My =
> environment is oracle8174 on AIX51.
>
> Top 5 Wait Events
> ~~~~~~~~~~~~~~~~~ Wait
> % =
> Total
> Event Waits Time (cs)
> =
> Wt Time
> -------------------------------------------- ------------
> ------------
> =
> -------
> db file sequential read 145,479
> 20,055
> =
> 49.21
> log file sync 4,549
> 6,466
> =
> 15.87
> db file parallel write 252
> 5,134
> =
> 12.60
> log file parallel write 4,560
> 4,784
> =
> 11.74
> control file parallel write 326
> 2,165
> =
> 5.31
>
>
> Thanks again
> Raghu.
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
Please see the official ORACLE-L FAQ:
http://www.orafaq.com
To unsubscribe send email to: oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Received on Wed Feb 04 2004 - 13:43:14 CST
