Re: 10046 trace: 'latch free' then 'db file seq. read' waits

Spendius wrote:
> joel garry a écrit:
> >
> > Conversely, maybe you have the same number of very hot blocks that are
> > the last few that the scan needs, and everybody is fighting to get them
> > to see the data in their own consistent way?
>
> That's what I guess too of course, but
> o I'd like to be able to verify it,
> o and answer this question: why are these last records to be displayed
> *always* located in these assumingly hot blocks ?
>
> Thanks.

See metalink Note:163424.1and especially the bug referred to in it.

I haven't tried it, but check out metalink Note:224270.1 scroll down to the bottom there is a link for an 8i version of a trace analyser.

As to why... I think that only can be answered by scrutinizing the app and the buffers. Speculating off in left field, I'm wondering if what you will find hot is undo 'cause it just takes running the whole report while others are updating to ignite it. Or maybe it's just a symptom of something else entirely, perhaps related to the sort. Can you play with your sort area size to rule that out?

jg

--
@home.com is bogus.
'I do my best work when I don't know anything about it.' - Frank Gehry