Oracle STARTUP GIVES ORA-1172 AND ORA-600[3020]

PROBLEM:

Received ora-1172: recovery of thread %s stuck at block 15902 of file 6
during a startup of their database after a backup.
It looks like their database was NOT shutdown normal before the
backup, but instead was aborted.
On trying to issue: recover datafile '<file 6>',
ct then receives ora-600[3020][402669086][1][64][1]......
402669086 being the dba mentioend in ora-1172 above.
=========================
DIAGNOSTIC ANALYSIS:
We received ct's database and tried the recover it.
We got the same problems and did got a dd for block 15902.
Beginning of the block dump shows:
0000000 0601 0000 1800 3e1c 0000 007b 0000 000a  <<======
0000020 0000 0000 0100 0000 0000 0509 4000 65e5
0000040 0001 7b88 0001 0200 0000 0000 0002 0016
0000060 0000 05c7 0800 1055 004c 01df 8000 0001
0000100 4000 65e4 0001 0005 ffff 001c 01d7 01bb
0000120 01bb 0000 0005 068b 055e 0431 0304 01d7
0000140 0000 0000 0000 0000 0000 0000 0000 0000
 
traced recovery process:
received the following in the trace file:
RECOVERY OF THREAD 1 STUCK AT BLOCK 15902 OF FILE 6
REDO RECORD - Thread:1 RBA:0x000040:0x00000402:0x0076 LEN:0x0260 VLD:0x01
CONTINUE SCN scn: 1.40006607 02/24/97 14:19:12
CHANGE #3 CLASS:1 DBA:0x18003e1e INC:0x0000007b SEQ:0x00400007 OPCODE 11.2
buffer dba: 18003E1E inc: 7B seq: A ver: 1 type: 6=trans data
.... (rest of the trace file is included)
Also dumped the logfile ....
CHANGE #1 CLASS:1 DBA:0x18003e1e INC:0x0000007b SEQ:0x00000001 OPCODE 13.6
ktsnb redo: seg:0x509 typ:1 inx:1
Can see changes being made all the way to SEQ:0x00000009.
 
QUESTION:  why is recovery stuck then on
CHANGE #3 CLASS:1 DBA:0x18003e1e INC:0x0000007b SEQ:0x00400007???
Where is this coming from?
=========================

=========================
REPRODUCIBLE?:
Yes, with 7.1.3 and 7.1.6.  I have ct's database
if needed.  Tried to recover in 7.1.3 and 7.1.6 and got the
same exact RECOVERY OF THREAD 1 STUCK AT BLOCK 15902 OF FILE 6
problem.

CUSTOMER IMPACT:
Ct needs to know why his recovery did NOT go through.
Although they did a shutdown abort, how could it have
messed up his database from doing normal crash recovery.
Ct needs to know what has happened to cause the
recovery to get "stuck".

=========================

WORKAROUND:
Ct had to rebuild his database, but because of export problems,
customer ended up using DUL.

=========================

For More Oracle DUL (data unloader) information :
Refer  http://parnassusdata.com/en/emergency-services  

If you cannot recover the data by yourself, ask Parnassusdata, the professional ORACLE database recovery team for help.

Parnassusdata Software Database Recovery Team

Service Hotline:  +86 13764045638

E-mail: service@parnassusdata.com