Conference orarep::nomahs::rdb_60

4997.0. "Restore bugcheck at RMUIO$REQUEUE" by M5::DMACKENZ () Tue Feb 04 1997 13:17

A customer is trying to restore their Rdb 4.1 archieved database on Rdb 4.2-0
and gets a bugcheck with an exception at RMUIO$REQUEUE + 0000006D followed
by the generic RMU-F-BUGCHECK error.  We're trying to find some way to get
this database restored.  I'm looking for ideas.

He's going to try another TA90E tape drive and another Rdb version to see
if that helps.

The backup command was:
  
  $ RMU/BACKUP/ONLINE/LOG/REWIND/CRC/LOCK_TIMEOUT=120/PROT=(W:W) -
      dbspec  $1$MUA3:X353.RBF

It was backed up to a TA90E tape drive using five volumes.

The restore command is:
  
  $ RMU/RESTORE/NOAFTER/NOCDD/NONEW_VERSION/NODES=8/ROOT=newfilespec -
      /OPTIONS=optionsfile tapedrive:x353.rbf

The options file contains the /FILE= and /SNAP=ALLOC=FILE= qualifiers for
each of the storage areas listed.

The restore log seems odd to me regarding the 2-4th volumes:

... 
%RMU-I-LOGRESSST, restored storage area
SYS$RDB2:[DATA]TMD_TRANS_TYPE_INDEX.RDA;1    
%RMU-I-RESUME, resuming operation on volume 2
%MOUNT-I-WRITELOCK, volume is write locked
%MOUNT-I-MOUNTED, X35302 mounted on _$1$MUA2: (LISZT)
%RMU-I-RESUME, resuming operation on volume 3
%MOUNT-I-WRITELOCK, volume is write locked
%MOUNT-I-MOUNTED, X35303 mounted on _$1$MUA2: (LISZT)
%RMU-I-RESUME, resuming operation on volume 4
%MOUNT-I-WRITELOCK, volume is write locked
%MOUNT-I-MOUNTED, X35304 mounted on _$1$MUA2: (LISZT)
%RMU-I-RESUME, resuming operation on volume 5
%MOUNT-I-WRITELOCK, volume is write locked
%MOUNT-I-MOUNTED, X35305 mounted on _$1$MUA2: (LISZT)
%RMU-I-LOGRESSST, restored storage area SYS$RDB10:[DATA]TMD.RDA;1
%RMU-I-RESTXT_05,     rebuilt 109 space management pages
%RMU-I-RESTXT_06,     restored 12 inventory pages
%RMU-I-RESTXT_07,     rebuilt 306 logical area bitmap pages
%RMU-I-RESTXT_08,     restored 185784 data pages
%RMU-F-BUGCHECK, fatal, unexpected error detected
%RMU-I-BUGCHKDMP, generating bugcheck dump file
WFNIA$DATA7:[RDB_BUGCHKDMP]RMUBUGCHK.DMP;1

The bugcheck also seems odd in that the second S0 address on the stack has
the filespec for the last storage area restored before the second tape volume.
Here's the Saved PCs following the exception.  The bugcheck is only 605 lines
so if it would help to see it, I can provide it at the location you request.

***** Exception at 0008830C : RMUIO$REQUEUE + 0000006D
%RMU-F-BUGCHECK, fatal, unexpected error detected
Saved PC = 80000014 : S0 address
Saved PC = 81485155 : S0 address
Saved PC = 00066856 : RMUCLI$RESTORE + 00002F16
Saved PC = 0002D6C9 : RMU$MAIN + 00000669
Saved PC = 7FF0BDF2 : P1 address
Saved PC = 7FF0BD54 : P1 address

Any ideas?

Diane

    Do you think they could at least try V4.2A, if not a more recent
    version?
    
    I believe the REQUEUE operation is upset because the thread state block
    is trashed.  I do recall there being some RMU/RESTORE memory corruption
    problems fixed in V4.2A (or maybe an ECO to V4.2A).

    >I do recall there being some RMU/RESTORE memory corruption
    >    problems fixed in V4.2A (or maybe an ECO to V4.2A).
    
    Wow!  You have quite a memory!
    
    Steve.

    Yes, well you tend to remember things like this when you burn a weekend
    finding them for a down customer...  :-)

    Thanks Paul.  Your recollection helps.  The customer has more amo. now
    to convince others to upgrade.
    
    Diane

    Paul,
    
    Thanks again.  The customer was able to convince their management to
    upgrade to Rdb 6.0A.  The next RMU/RESTORE attempt was successful.
    Without your memory of this problem, they would be stuck on Rdb 4.2
    for political reasons and they wouldn't have their archive database.
    
    Diane