Re: statspack comment is needed

hopehope_123 wrote:
> Hi ,
>
> Thanks for your responses. I just try to understand the values , sorry
> here is another statspack :
>
> 54.55 min.
>
> Top 5 Timed Events
> ~~~~~~~~~~~~~~~~~~
> % Total
> Event Waits Time (s)
> Ela Time
> -------------------------------------------- ------------ -----------
> --------
> log file sync 302,886 14,774
> 32.54
> CPU time 12,714
> 28.00
> global cache busy 8,510 6,011
> 13.24
> latch free 1,201,647 4,713
> 10.38
> db file sequential read 74,150 2,579
> 5.68
> -------------------------------------------------------------
>
> Based on the values shown above :
>
> 48msec. for single log file sync ( 14774/302886)
> 34msec for single db file seq read ( 2579/74150)
> 706 msec for single globacl cache busy (6011/8510)
>
> Considering a good fibre channel , 2-20 msec. disk io times are good
> but these values are very high , so disk io system my be slow.

Those timings ( if you calculated them correctly ) don't look good at all.

The behavior with the "log file sync" might be caused by an application that is doing a huge number of updates and/or inserts and/or deletes and committing on every single row. So an application that's not coded well may potentially be a huge aggravating factor. Is it possible you had a bad application that started swamping storage devices?

You should be able to go lower in the stats pack output and look at the IO stats on a file and/or tablespace level and see avg read times. Are those figures close to what you calculated?

Do some more double checking on this stuff and then "politely" try to work with your system administrator and/or storage administrator. What's going on here? Received on Thu Dec 14 2006 - 09:44:30 CST