Anurag Varma wrote:
> On Mar 5, 5:04 pm, Chuck <skilover_nos..._at_bluebottle.com> wrote:
>> ORA-1652: unable to extend temp segment by 8 in tablespace UNDO1
>>
>> Today I saw in my alert log the above error. How does one create a
>> *temp* segment in an *undo* tablespace? I've tried setting my temporary
>> tablespace to UNDO1 and it failed with an error. I tried creating an
>> index in UNDO1 and it failed with an error. So what caused this message
>> in the alert log?
>>
>> RDBMS version is 9.2.0.5.
>>
>> Then about an hour later I user got an ora-30036 on the UNDO1
>> tablespace. The tablespace should have been no where near full. It has
>> 7g of datafiles assigned to it. DBA_UNDO_EXTENTS was reporting about
>> 2.5g unexpired, 60m expired, and < 1m active. Yet Grid control (10g r2)
>> was saying the tablespace was 100% full. It was actually only about 35%
>> full. What am I missing?
>
> I'm not sure why you got ORA-1652 on the undo tablespace. Its probably
> referring
> to some temporary segment being created in the undo tablespace. And
> no, I'm
> not referring to temporary tablespace type segments, instead some
> temporary
> segment related to undo tablespace.
>
> Did you query dba_undo_extents while the transaction which failed was
> going on?
> Do you think its not possible that the transaction which failed was
> actually
> trying to use more than 7G of undo (or all active transactions
> combined were
> using that much undo).
>
> If you think you might be hitting bugs in undo management, maybe its
> a good reason to finally patch to 9.2.0.8?
>
> Anurag
>
Yes, I did query it while the transaction that failed was occurring. It
was pretty much the same as stated above. 2.5g unexpired, 60m expired,
and < 1m active.
Received on Tue Mar 06 2007 - 16:31:56 CST
