comment in line.
On 4/20/05, Yongping Yao <yaoyongping@(protected):
> Well, some statements cannot be tuned more. In our design, these kind
> of operations are rare (delete the duplicate rows and due to the load
> speed we do not use unique index). But I did use them these days since
> the application did something wrong :(
if your table is very big , then use partition table will be a must.
then you can use exchange partition to minimize the undo with it.
delete from a big table is a bad idea.
> And by the way, SMON clean the undo tablespace? It also has some
> delay. Some transanctions are commited and they still occupy the undo
> space. Can it be solved? Or just add more space to the undo
if you have a undo tablespace that extended beyond your control. then
create a new undo tablespace . and change the undo tablespace online
may be a better solution than to wait the SMON to clean then undo
within my technical scope. if there were no other transaction request
the undo from the undo tablespace , oracle will not release this undo
> On 4/20/05, jame tong <jametong@(protected):
> > I think you tune the sql statement to minimize the temp space usage.
> > On 4/20/05, Yongping Yao <yaoyongping@(protected):
> > > I have a related question. After I run a statement consuming the
> > > temporary tablespace a lot and commit the transaction, the tablespace
> > > is not cleaned soon. Then other sessions got an error something like
> > > "can't extend ...in ..." which means the temporary tablespace is not
> > > enough. Is there something wrong with the background process?
> > > Do I have to use a separate temporary tablespace or set the temporary
> > > tablespace autoextend (which I think is not safe and hard to control
> > > the datafile size)?
> > >
> > > --
> > > Yao Yongping
> > > Learning Oracle, UNIX/Linux...
> > > Love Reading, Classical Music, Philosophy, Economics etc.
> > > Blog: http://blog.csdn.net/
> > >
> Yao Yongping
> Learning Oracle, UNIX/Linux...
> Love Reading, Classical Music, Philosophy, Economics etc.
> Blog: http://blog.csdn.net/