Database backup and recovery

Note: The information in this section is specific to Db2®. If you use a different database manager product, see the information provided with the product for details about database backup and recovery.

Db2 table spaces

Db2 table space support provides enhanced flexibility and improved performance for your application group data. For example, after you store a report in Content Manager OnDemand, you can create a backup image of the table that changed during the load process, rather than creating a backup image of the entire database. You can also create an incremental backup image of the database, which contains only those tables that changed since the last backup image. Because the backup image only contains the changes made to the database, the backup process typically runs much faster than a full backup.

Content Manager OnDemand creates one table space for each segment of application group data. After Content Manager OnDemand closes the segment and you back up the table space, you do not need to back up the table space again, unless it is recovered or restored.

When you use the incremental table space backup capability, backup the Content Manager OnDemand database each time that you load a report into the system. If your schedule does not permit you to run the backup command after each load, backup the database once a day (assuming that you load multiple reports each day). While you can use incremental backup images to recover the database, you should periodically create a full backup image of the database. A full backup image of the database is the quickest way to recover the database in the event that you need to do so. However, if your Content Manager OnDemand database is very large and cannot be backed up in a reasonable amount of time or requires many storage volumes to back up, then you may find that maintaining full backup images of the database is not possible.

The IBM Content Manager OnDemand for Multiplatforms: Installation and Configuration Guide provides information to help you configure the system for table spaces.

Database backup

Back up your database file systems using the data recovery facilities provided by Db2 or Oracle. See the SQL Server documentation for details on a backup strategy.

Backup to a tape device

If you plan to backup the database to a tape device, then you may need to configure the Buffer Size Limit in Db2. If you plan to backup the database to a tape device and specify a variable block size, then you must configure the Db2 buffer size to a value that is less than or equal to the maximum block size limit for the backup device. For maximum performance, you should set the buffer size to the maximum block size for the backup device. See the Db2 documentation for details. Contact the IBM® support center if you have questions.

Database backup in Windows

The OnDemand Configurator program that is provided for Windows servers allows for the scheduling of database backups. You can perform a backup while the database is either online or offline.
  • If the backup is to be performed online, other applications or processes can continue to connect to the database, as well as read and modify data while the backup operation is running.
  • If the backup is to be performed offline, only the backup operation can be connected to the database; other Content Manager OnDemand services and the rest of your organization cannot connect to the database while the backup task is running.

To schedule an offline backup with the configurator program, you must do the following:

  1. Manually disconnect all other processes from the database before the backup task is scheduled to begin. This includes stopping the Content Manager OnDemand LibSrvr, MVSD Server, Load Data, and Distribution Facility services on the library server. In addition, if you load data to the library server from another object server, then you should manually stop the Content Manager OnDemand ObjSrvr and Load Data services on the object server.
  2. Run the offline backup.
  3. Verify that the offline backup completed successfully.
  4. Manually restart the Content Manager OnDemand LibSrvr service and the Content Manager OnDemand MVSD Server and Content Manager OnDemand Load Data services on the library server. If you stopped Content Manager OnDemand services on an object server, manually restart the services.

Database logging

Db2 uses transaction logging to record changes to the Content Manager OnDemand database. The information in the log file is used to recover from corruption of data in the database. Logging ensures that no data is lost. By combining the information in the log files with a backup copy of the database, the Content Manager OnDemand database can be recovered to any point in time.

The Content Manager OnDemand database and the Db2 log files should reside on different physical volumes. The database backup image should be written to removable media. Unless multiple disk and tape volumes are damaged or lost at the same time, there is no possibility of losing the information contained in the Content Manager OnDemand database.

The Db2 Administration Guide provides details about the database logs.

Database recovery

This section provides an overview of the different recovery methods that you can use in the event that there is a problem involving the database.

Note: Before you begin using the system, ask your IBM representative about the strategies that are available to you when there are problems with the database. You should also speak with a Db2 specialist to help implement a backup and recovery plan that is best suited to your business and operating environment. The Db2 Administration Guide provides details about database backup and recovery.
Typically you will need to recover the Content Manager OnDemand database because of media and storage problems, power interruptions, and application failures. When a problem occurs that damages or corrupts the database in some way, you must rebuild the database. The rebuilding of the database is called recovery. There are two types of database recovery:
  • The first type recovers from failures that occur while update transactions are taking place. For example, a system failure occurs while update transactions are taking place. The database is left in an inconsistent and unusable state and must be moved to a consistent and usable state before you can permit users to access the system.

    The log files help correct this type of failure by allowing the transactions received before the failure to either be reapplied to the database or to be rolled-out. Rolling-out transactions is a way to return the database to the state it was in before the transaction that caused the failure.

    This type of recovery is done with the Db2 RESTART DATABASE command. If you want this type of recovery to occur in every case of a failure, you can use the AUTOMATIC RESTART ENABLE database configuration parameter. The default for this configuration parameter is that the RESTART DATABASE routine will be started every time it is needed. Once enabled, you do not need to do anything to have this command done at the time of a failure.

  • The second type of recovery deals with corruption of the Content Manager OnDemand database and is usually caused by media failure. For example, one of the disk storage volumes that belongs to the database volume group becomes damaged and unusable. To recover from this type of failure, an administrator must intervene to recover the database.

    The combination of the Db2 log files and a full backup copy of the database can be used to re-create the Content Manager OnDemand database to any particular point in time. First, the latest full backup image of the database rebuilds the database to a point in time. Then, a roll-forward recovery restores all of the units of work that occurred since the backup image was created. This allows you to restore the database to a state identical to the time of the failure.

    The Content Manager OnDemand database and the Db2 log files should reside on different physical volumes. The database backup image should be written to removable media. Unless multiple disk and tape volumes are damaged or lost at the same time, there is no possibility of losing the information contained in the Content Manager OnDemand database.

Factors affecting recovery

To decide which database recovery method to use, you should consider the following:
  • How near to the time of failure you will need to recover the database?

    When you restore a full backup copy of the database, the database is only as current as the time that the last backup was made.

    To restore the database to the time of a failure, you must use the log files to reapply changes that were made to the database since the backup copy was created. You can reapply the changes to the end of the logs or to a point in time. A point in time recovery may be useful if an application corrupts the database and you do not want to reapply its changes.

  • How much time is spent associated with recovery?

    Your recovery plan should allow for regularly scheduled backups, since backing up the database requires time and system resource.

    You can take a backup while the database is either online or offline. If it is online, users can access the system and other processes can connect to the database and read and modify data while the backup task is running. If the backup is performed offline, only the backup task can be connected to the database. Users cannot access the system and other processes cannot connect to the database while the offline backup task is running.

  • How much storage space can you allocate for backup copies and archived log files?

    To restore the database, you must allocate enough free disk space to hold the backup copy of the database and the restored database. To roll-forward transactions, you must allocate enough space to hold the backup copy of the database, the restored database, and all of the archived log files created between backup copies of the database.

  • Table space level or full database level backup.

    With a table space backup, you can specify one or more tables spaces to be backed up, rather than the entire database. You can then restore selected table spaces to a state identical to the time the backup was made. However, those table spaces not selected at the time of the backup will not be in the same state as those that were restored.

    IBM recommends that you contact the IBM support center to help you with a backup and recovery plan that includes table space backup and recovery.

The Db2 Administration Guide provides details about recovering a database.