Spendius wrote:
> "Haximus" <e_at_t.me> wrote...
>>
>> Just a thought... latch contention? 'db file seq. read' is for control
>> file and datafile header access, a latch must be required to access these
>> areas, the process might be requesting one in willing-to-wait mode, not
>> getting it and retrying... retrying... etc
> What is funny is that I either get this 'db file seq. read' event
> or 'latch free' on the same number (106 = library cache) with the
> number of tries staying at 0 (ZERO), for hours too, until I kill
> the session. But 9 times/10 we get the db file sequential read wait.
>
> I've dbverified the file returned by this event, everything's fine,
> I've checked V$SESS_IO, from the moment the session stalls the
> values in this view no more change, I've launched the first SQL
> on V$LOCK someone gave me in the 1rst reply: I get no row (I've
> run anyway ALL my scripts related to locking, including catblock.sql
> to create all these relevant views, but it never returns me anything
> helpful). It *really* looks as if the session suddenly gets suspended,
> everything looks frozen.
>
> A 'tail -f' of 10046 trace file always stops at the same line:
> a SELECT FOR UPDATE statement. I'm beginning to suspect the data
> in the tables involved must cause this procedure to conk out
> (because the same module exists on 22 different databases -they
> are replicated to the same master- but it only fails on this one)...
Just another thought... check if another session is accessing the same file#
and block#... could be a possible source of blocking.
Received on Tue Mar 01 2005 - 14:02:32 CST
