II09017: DB2 RECOVERY -COMMON PROBLEMS, HINTS & TIPS

APAR status

• Closed as canceled.

Error description

• 5740XYR00 DB2 R230 R310 R410  (Last Update 08/15/97 JBW)
  (1) This error was encountered by a user while testing a
  a disaster recovery procedure.  The user accidentally used
  a conditional restart record (CRCR) with a lower RBA than the
  RBA listed in his SYSCOPY records.  A subsequent RECOVER TOCOPY
  (using the image copy with the RBA larger than the CRCR RBA)
  received message msgDSNU519i TOCOPY dataset not found RC8.
     This message is valid, since the TOCOPY SYSCOPY record has
  a higher RBA than what is listed in the BSDS.Verify that CRCR
  (conditional restart record) is not lower than the STARTRBA for
  the SYSCOPY records.
  
  (2)  Many times a user will do a DB2 restart, DB2 will fall
  into BACKWARD recovery and seem to just sit there with
  nothing happening.  Now if the user is archiving to tape,
  eventually he will see an MVS tape MOUNT request message,
  and he will get an indication that DB2 is calling up LOG
  records to resolve a UR.  But, if he is archiving to DASD,
  there is no indication whatsoever of what is occurring.  If
  he has an activity monitor (OMEGAMON), he may be able to
  notice the occassional channel activity and CPU usage
  associated with the DB2 MSTR and DBM1 asids.  In R410, a
  message has been added that will be issued every 2 minutes
  during FORWARD and BACKWARD restart phases.  MSGDSNR031i
  will inform the user that DB2 is processing LOG records.
  As long as the user sees that the RBA value associated
  with this message is properly changing, he should assume
  that all is working correctly, and allow DB2 to finish.
  Note: the DSNR032i message shows 2 RBA values.  The first
        RBA value shows your current position in the LOG, the
        second RBA value points to the end of the current LOG.
  
     If user notices that the associated RBA value is NOT
  changing, then user should assume that the DB2 RESTART
  process is looping while processing this LOG record.  In
  as such user should setup a conditional restart.  There
  are 3 options to consider, depending upon the DB2 restart
  cycle that was looping.  The CRESTART could specify
  FORWARD=NO or BACKOUT=NO, or, if user does NOT know, he
  could set STARTRBA and ENDRBA equal to a higher RBA value
  and perform a COLDSTART.
  
  (3) It has been reported that a hang in HSM during a request
  for an archive log could cause the rba value to be the
  same for a long period of time. Be sure to check the console
  log for messages that may indicate a problem in this area.
  In the case of a tape there may be an outstanding mount
  request that did not get satisfied.
  
  (4) If a job runs for hours, continuously making updates
  to a TS without COMMITs and then is canceled,  it will now
  take DB2 'hours' to read through the LOG tapes and remove
  these uncommitted updates.  If DB2 is forced down while this
  backout is being performed, then the subsequent DB2 restart
  will take 'hours' to abort these updates.  Inlieu of waiting
  hours for DB2 restart to complete, user might consider
  performing a CONDITIONAL DB2 restart with BACKOUT=NO, then
  RECOVER this TS manually:  CRESTART CREATE,BACKOUT=NO
  
  (5) During normal recovery of a UR, DB2 may fully recover
  the UR without ever calling for an ARCHIVE log.  This can
  be normal operation.  DB2 will first check the BSDS for
  ACTIVE logs that are in the REUSABLE state.  If wanted
  information (RBA range) is available in that DASD log,
  DB2 will use this source inlieu of calling in the
  ARCHIVE log volume.
  
  (6) It has been reported that many jobs hang and DB2
  can be hung during restart processing because of IRLM
  being hung. MSGDSNR031I is repeated over and over with
  notice being that the RBA value does not change. This
  msg is timer driven and comes about because of a serial
  process for DB2 under a restart task. Basically restart
  processing is stuck in IRLM. This msg provides info as
  to where we are in the log and will often occur on behalf
  of processing lengthy UR's. The msg only reports the
  current RBA. DB2 and IRLM dumps are needed to diagnose
  the hang condition. IRLM apars pn92451 and pn92563
  may be useful here. This has been reported during
  DB2 warmstarts. A CR coldstart was needed to start
  DB2 successfully.  DB2 DataSharing users beware.
  ---------------------------------------------------------------
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

• closed for DB2INFO retention
  

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels