Re: Rollback and slow delete

You are using 8i, you may as well implement paritioning. In your table design add a DAYC (day created) column, or something similar, in which you can use to partition your data on. Your removal of records will complete in a matter of seconds.. rather than hours, cause you'll use TRUNCATE rather than DELETE.

Cheer,

Greg.

"Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message news:<GrSC9.80661$g9.227306_at_newsfeeds.bigpond.com>...
> Fair enough. Dynamically expanding the RBS will certainly slow things down a
> bit (locally managed tablespace is recommended for rollback segments), but
> it's not going to make a huge difference.
>
> I would have thought, however, that you would have only encountered the 1555
> problem as a result of someone else modifying the rows your transaction is
> hoping to delete some time later. Sounds a bit weird to be allowing
> modifications of data which you are about to blow away.
>
> If that's the case, have you considered selecting all the rows "for update"
> (and hence locking them exclusively) before then going ahead and deleting
> them?
>
> As in:
>
> SQL> select * from emp for update;
> 14 rows selected.
>
> SQL> delete from emp;
> 14 rows deleted.
>
> SQL> commit;
>
> Regards
> HJR
>
Received on Thu Nov 21 2002 - 00:46:52 CST