Re: truncate randomly failing

From: Matthias Rogel <rogel_at_web.de>
Date: Fri, 13 Dec 2002 07:40:57 +0100
Message-ID: <atbvdp$vp9d0$1@ID-86071.news.dfncis.de>

Joel,

I totally agree with you, I had similar ideas ...

that's exactly why I suggested to *explicitly* lock the table before truncating it.

I still think, this could be fixing it ...

Matthias

Joel Garry wrote:
> erika_at_multimodalinc.com (Erika) wrote in message news:<766a32cf.0212120702.7a044b0d_at_posting.google.com>...
>

>>Thank you all for the messages.

>
>
> Some wild speculation:
>
> Multiple users accessing a table, one of whom is attempting to
> truncate.
>
> Oracle has to update sys.tab$ or sys.seg$ or something and associated
> views.
>
> Users view of sys.*$ is confused, because DDL is not transaction
> based.
>
> Oracle throws ORA-942 not on the user table, but perhaps on the
> all_table view or whatever group of things Oracle is looking at to
> determine permissions).
>
> So Erika, does anyone besides the truncator get the 942?
>
> (I've seen many odd 942 situations like this, under many different
> scenarios. I've always [well, since 7.0, when I had a complicated DDL
> script that would sometimes skip creating random tables] suspected an
> Oracle bug as I've speculated, basically an improperly handled race
> condition. Perhaps a detuned test instance set to overwork the DBWR
> could be replicable.)
>
>

>>We are testing this right now (might take as a while because we are
>>not able to replicate this at will, so we just have to see if we can
>>go without the error for a while). I just would like to know if
>>anybody else ran into the same problem before. Or if yo have heard
>>about an Oracle bug like this. I don't know the Oracle version but I
>>will ask and post it later.
>>
>>Thanks again 
>>
>>Erika

>
>
>
> jg
> --
> @home is bogus.
> Time for tubby bye-bye!
> Time for tubby bye-bye!
> Time for tubby bye-bye!
Received on Fri Dec 13 2002 - 00:40:57 CST