My first suggestion here is not to do a cold backup at all. Cold backups should be used to take a baseline before and after major database changes. Otherwise all backups should be hot. There is no recovery advantage to having routine cold backups in addition to hot backups.

If you don't like that bit of lateral thinking, then you do have the option of aborting the instance instead of shutting down cleanly. That will not avoid the sort segment cleanup by SMON, but it will be done after the start up instead. Although that will reduce the time for which the database is completely unavailable, you will not be able to do any sorting until SMON has finished the cleanup, so you may not gain much really.

Switching to a PERMANENT contents tablespace for temporary segments will not help much. SMON will still do the cleanup during a clean shutdown, or during startup after an abort. However, new sorts will be able to start when cleaning up after an abort, but they will contend with SMON and each other for the ST enqueue, which of course is why you should use a tablespace with TEMPORARY contents in the first place.

Also, if you have read the Ixora web tip on Planning Extents you will be aware of the damage that you have done to the data dictionary clusters by having too many extents previously when the extent size was smaller. You cannot undo all that damage without rebuilding the database, but you can get some relief by dropping the temporary tablespace and creating it again with a new name, like TEMP_26_OCT_2000. That way you'll be using a clean part of the C_TS# cluster. Also, to avoid ever getting more than 500 extents in the 3.5G, specify a MINIMUM EXTENT size of 8M when creating the tablespace. This assumes that you have an 8K database block size. If not, the extent size should be adjusted accordingly.

Our Oracle HR application has a 3.5 gig temporary tablespace (initial 4m next 4m pctincrease 0) which is used a LOT. Upon shutdown - it sometimes takes 1-2 hours for SMON to clean this up as we can see by TX message in alert log.

This adds time to an already long weekly cold backup of 7 hours and the users are missing processing time.

Metalink doc advises making extents larger, etc. to speed up this cleanup time. I moved from 2m to 4m with a decrease in time but 1-2 hours is still too much. I cannot reduce the size since space errors on TEMP start popping up.

I opened a tar with Oracle about the safety of using event 10061 to disable cleanup and they replied that it will not solve my problem and SMON will still try to do the cleanup at shutdown.

I am reluctant to change the tablespace to PERMANENT which would hurt perfomance but I am being pressured to do so. Any advice or solution?

The platform is HP-UX 11.0 and Oracle 8.0.5.1 64-bit.