Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: ora-1652 on *undo* tablespace?

Re: ora-1652 on *undo* tablespace?

From: Anurag Varma <avoracle_at_gmail.com>
Date: 6 Mar 2007 15:50:50 -0800
Message-ID: <1173225050.278796.54010@8g2000cwh.googlegroups.com>


On Mar 6, 5:31 pm, Chuck <skilover_nos..._at_bluebottle.com> wrote:
> 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.

This is strange. So according to you the active extents showed up as 1M
and oracle returns an out of space error? Is this a RAC instance?
How is undo tablespace created? LMT or DMT? Are the datafiles in undo tablespace set to autoextend? What was the transaction running? A big insert/update/delete?

It just seems like a bug that you find active undo segments using only 1M of space in a 7G tablespace and get an out of space error?

Try checking metalink for bugs related to AUM in 9i.

Anurag Received on Tue Mar 06 2007 - 17:50:50 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US