There are a number of things you can look at

1. Increasing your undo tablespace may allow your operation to complete but it isnt going to make it any quicker. Dont forget index changes are also logged to the undo tablespace. Note undo is like the old rollback tablespace except that oracle manages the size and shrinks of the rollback segments.

2. You redo logs should be on separate disks to the data, indexes and undo(and they should be unstriped but mirrored preferably, avoid RAID 5 at all costs for redo). The undo disks (or stripes) should also be seperate from the data and indexes.

3. Look at your log_buffer (make sure it is a big value say 1M min) and your redo logs should be quite big (say 100M min).

4. If you are deleteing a sizeable portion of the table look at partitioning (if you have that) using your delete criteria. Also look at deleting by creating a new table using direct path inserts,nolooging and without indexes. To do this on a production environment look at dbms_redefinition which can do this online without user interruption .

5. If you are deleting a small percentage of the table is your delete going in on an index, if not maybe create an index (though this will add overhead on the delete).

6. Benchmark on your prod environment before and after using a copy of the actual table, what applies to dev wont neccessarily apply on prod.

7. If it is a heavily loaded system schedule the delete during a quiet period.

Hope these pointer help.

Alan