Recovering from errors during dynamic backout

Different kinds of failure require different recovery procedures.

Specifically:

  • If a database is unavailable during dynamic backout or emergency restart, but subsequently becomes available (for example, you bring it back online or repair a physical device), use a /START DB or UPDATE DB START(ACCESS) command to reschedule dynamic backout to back out the (now available) database.
  • If the database remains unavailable (because, for example, the database has an error that you must recover), you must run the Database Recovery utility before you allow further processing against the database in error, and then run the Batch Backout utility. Batch backout recognizes the X'4C01' log records and does not try to back out changes for databases that were backed out successfully.
  • In the online environment, dynamic backout can fail if the log records are not available. If the only log records available are from SLDS, the performance of dynamic backout is poor. Slow dynamic backout can happen in the following cases:
    • The OLDS containing the log record has been archived and reused.
      Recommendation: Make sure that you have defined enough OLDS space, and that programs reach sync points (using GU or CHKP calls) frequently enough to ensure that records needed for backout are available from OLDSs.
    • IMS stops a database during dynamic backout if a nonrecoverable read error occurs on the logs when single or dual logging is in effect.

      In this case, you must run the Log Recovery utility to get a valid log. The output log must terminate normally; use it as input to the Database Change Accumulation utility or the Database Recovery utility. After you have corrected the input error, execute the Batch Backout utility again to correct the databases.