Crash recovery - information wanted

Dear reader,

The following happened today at my current customers site. See below for environment details.

A batch was running, over 2 hours. It was running a single transaction (so no commits in between) of about 1Gb in size(in a rollback segment), causing about 100 archived redo log files, each about 130 Mb.

After 2 hours the database crashed (a dispatched dumped core - which is another problem).

When the instance was started again, normal crash recovery took place. Recovery_parallelism has been set to 16, so 16 slaves were busy rolling back the transaction.

This lead to a period lasting over 5 hours now (still not finished!), producing over 400 redo log files to archive (which causes the filesystem to become full - the tape drives cannot keep up).

So far, I investigated systemstate dumps, undo headers, v$rollstat, v$transaction, x$ktuxe, without finding any answers of hints.

I know, that if a session rollbacks its transaction 'normally', one can query v$transaction and check the columns used_ublk / used_urec. Those 2 numbers are decreasing - at 0 the rollback is complete. During transaction, the values increase.
Unfortunately, there is no entry in v$transaction:(

I would appreciate any help to answer the following question:

1. Is there a way to determine - during crash recovery:
   * how big a transaction - which should be rollbacked - is
   
   • how much of the rollback has been performed, or
   • how much of the transaction to rollback?
2. Anyone experienced such behaviour, and changed settings in order to avoid such a long time for crash recovery?

Kind Regards,

Herman de Boer.

Environment:
RDBMS 8.1.7.1
2G real memory
1 quad, 4 cpu (pentium III)
IBM Dynix/PTX
database size about 100 Gb. Received on Tue Aug 21 2001 - 12:43:12 CDT