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
Comment