Re: Inconsistent file IO times on AWR report

  • From: Neil Kodner <nkodner@xxxxxxxxx>
  • To: Marcin Przepiorowski <pioro1@xxxxxxxxx>
  • Date: Mon, 24 May 2010 12:17:31 -0400

That's exactly what's bothering me!  That these numbers have increased so
much.  I think I should have enough table statistics history to look back
on, I'll check that.  I can't think of anything else that would drive those
numbers up so much higher.  From one week to the next, I dont think we have
experienced a dramatic growth in table size.

On Mon, May 24, 2010 at 11:22 AM, Marcin Przepiorowski <pioro1@xxxxxxxxx>wrote:

> On Mon, May 24, 2010 at 12:38 PM, Neil Kodner <nkodner@xxxxxxxxx> wrote:
> > We enabled directIO and set filesystemIO_options to setall last week.
>  Our
> > first real test was this morning and our main batch jobs ran slower.  A
> few
> > things noticed was that there was more physical IO, and by looking at the
> > tkprof (and soon 10046), the cardinality numbers on the explain plans for
> > nearly all statements were much higher.  The same plans were used but the
> > cardinality numbers on the tkprof were much, much higher.
> > I feel that this issue relates to optimizer stats and not a direct result
> of
> > the parameter change but am not 100% sure.  We haven't changed the way we
> > analyze our tables in weeks.
>
> Hi Neil
>
> I doubt that changing filesystemIO_options has direct impact on
> cardinality of joins or
> selections.
>
> Did you have any significant operations on OP_TRANSACTIONS table ?
>
> In "before" example number of consistent reads is
> 72143 for table
> 51674 for index
>
> Physical reads
> 12115 for table
> 1190 for index
>
>
> In "after" example numbers are:
> consistent reads:
> 191111 for table
> 128359 for index
>
> Physical reads:
> 41166 for table
> 7420 for table
>
>
> It look like size of table has been changed or additional CR are
> related to consistent read (UNDO)
> mechanism - is there a lot of transactions ?
>
> regards,
>
> --
> Marcin Przepiorowski
> http://oracleprof.blogspot.com
>

Other related posts: