Lengthy offline application or database maintenance operations
    can pose a significant problem in high-availability production
    environments. The LogMiner for Rdb feature can help reduce the
    length of downtime to a matter of minutes.

    If a back up of the database is used for maintenance operations,
    the application can continue to be modified during lengthy
    maintenance operations. Once the maintenance is complete,
    the application can be shut down, the production system .aij
    file or files can be backed up, and LogMiner for Rdb can be
    used to extract changes made to production tables since the
    database was backed up. These changes can then be applied (using
    an application program or the trigger technique previously
    described) to the new database. Once the new database has been
    updated, the application can be restarted using the new database.

    The sequence of events required would be similar to the
    following:

    1. Perform a full online, quiet-point database backup of the
       production database.

    2. Restore the backup to create a new database that will
       eventually become the production database.

    3. Perform maintenance operations on the new database. (Note that
       the production system continues to run.)

    4. Perform an online, quiet-point after-image journal backup of
       the production database.

    5. Use the RMU Unload After_Journal command to unload all
       database tables into individual output files from the .aij
       backup file.

    6. Using either the trigger technique or an application program,
       update the tables in the new database with the changed data.

    7. Shut down the production application and close the database.

    8. Perform an offline, quiet-point after-image journal backup of
       the production database.

    9. Use the RMU Unload After_Journal command to unload all
       database tables into individual output files from the .aij
       backup file.

   10. Using either the trigger technique or an application program,
       update the tables in the new database with the changed data.

   11. Start an online, quiet-point backup of the new database.

   12. Change logical names or the environment to specify the new
       database root file as the production database.

   13. Restart the application on the new database.

    Depending on the amount of application database activity, steps
    4, 5, and 6 can be repeated to limit the amount of data that
    needs to be applied (and the amount of downtime required) during
    the final after-image journal backup and apply stage in steps 8,
    9, and 10.