This is expected behaviour. It is not due to the rollback activity. Rather, SMON is deallocating the old sort segment, one extent at a time, and until it is finished no other disk sorts can occur. The time taken depends of course on the number of extents in the old sort segment. The db_writer_processes and db_block_buffers parameters also affect the time taken, because before each extent can be dropped SMON has to wait for the DBWn processes to checkpoint any dirty blocks of the target extent from their respective working sets.

However, it is improved in 8.1.7 - I guess by using the "checkpoint object" call once instead of checkpointing the block range for each extent individually. Until then, you can minimize the impact by using big temporary tablespace extents and doing an intermediate startup in restricted mode if necessary using small db_writer_processes and db_block_buffers values. Also, using a tempfile temporary tablespace will help.

During the rollback phase of recovery and until the rollback completes, we are unable to allocate any sort space nor do any DML. Sorts give sort segment request wait events, while DML statements give row cache lock waits. Do you have any ideas or thoughts on whether this is expected behavior or more likely a bug? This occurs irrespective of whether we are doing instance or media recovery. We have recovery_parallelism set to 16. Any ideas to avert this situation would be appreciated as it sometimes delays our availability by several hours.