The control segment of the satellite environment includes the information that you use to both set up and maintain the entire satellite environment. To be able to fully recover the control segment, you require backup images that you can use to restore the DB2 instances and the DB2 databases:
Whether the database on the model office is recoverable depends on the recovery strategy that you want to implement on your satellites. For additional information, see Recovering the Model Office.
The sections that follow describe how to implement a recovery strategy for the Control Center, the DB2 control server and the satellite control database, and the model office.
When you specify the DB2 servers and DB2 databases that you want to use as execution targets by adding them to the Control Center, information about these DB2 servers and databases (such as the name, alias, and the host on which they reside) is stored in the node, database, and DCS directories of the Control Center instance. For information about setting up execution targets, see Chapter 4, Cataloging Instances and Databases.
You can export the Control Center directories to a file with the db2cfexp command, using the backup parameter as follows:
db2cfexp filename history
You should export these directories to a file every time you add a new DB2 server or database to the Control Center, and save the resulting file to a location other than the Control Center instance (for example, to a diskette). For additional information about the db2cfexp command, refer to the Command Reference.
If you need to re-install the Control Center, you can use the file to import its directories, and obtain the set up on the Control Center that you had before the re-installation. To import the directories from the file, you can use the Import Client Profile window, which is available from the Client Configuration Assistant. For information about performing this task, refer to the online help that is available from the Client Configuration Assistant. You can also use the db2cfimp command to import the file, as follows:
db2cfimp filename
For additional information about the db2cfimp command, refer to the Command Reference.
The availability of the DB2 control server and the satellite control database is critical both to administering the satellite environment, and to the ability of satellites to synchronize. If the DB2 control server or the satellite control database is not available, you cannot administer the satellite environment, nor can satellites synchronize.
To ensure the availability of the DB2 control server, you should consider setting up a high-availability solution for it. For information about performing this task, refer to the Administration Guide.
You should enable the satellite control database for forward recovery. To do this, you can either set the logretain database configuration parameter to Recovery or On, use a user exit to archive log files, or both. With forward recovery, you will be able to reconstruct the satellite control database to either a specific point in time, or to the last update to the database that is recorded in the logs. For a discussion of the issues and how to implement a solution, refer to the Administration Guide.
In addition, you should also keep a copy of the database configuration file SQLnnnnn\SQLDBCON. You should take a copy of this file every time that you change the value of one or more of the database configuration parameters. Changes to database configuration parameters are not recorded in the logs. If you maintain a copy of the database configuration file, you can restore the file after rolling the database forward. In this way, you do not have to use the update database configuration command to update the database configuration after the roll-forward operation is complete. You will, however, have to stop and restart the database so that the configuration values specified in the configuration file are activated for the database.
To protect the satellite control database against media failure, you can use the backup database command to write the backup image of the database to a different physical device than the device on which the database resides. You can also use the newlogpath database configuration parameter to specify that the logs required for forward recovery are stored on a different physical device than the database. For information about this configuration parameter, refer to the Administration Guide.
In addition to storing backup images and logs on a different device than the database, you can further protect against media failure by using disk mirroring or RAID.
The test environment typically contains one model office for each application version supported in the group, and the test satellites. The discussion that follows assumes that you are implementing a model office as part of your satellite environment, and that DB2 Satellite Edition is running on the model office.
When you use a test satellite as your model office, it is the model of all the group satellites, both test and production. You need to be able to recover the model office for two reasons:
An important decision to make when deciding on the configuration of the model office is the type of recovery that you want to use to restore the database on the model office. The recovery method that you decide to implement will apply to all the test and production satellites that are at the same application version as the model office.
Three types of database recovery are available for the model office. You can use refresh recovery, version recovery, or forward recovery to restore the database on the model office:
For more information about version recovery and forward recovery, refer to the Administration Guide. Refresh recovery is unique to the satellite environment. The following description provides more information about the different types of database recovery that you can use:
You can identify whether the model office is configured as a test or a production satellite from the satellite details view, which is available from the Satellite Administration Center. For information on using the Edit Satellite notebook or the Set Execution Starting Point window, refer to the online help that is available from the Satellite Administration Center.
Refresh recovery may be sufficient if none of your production satellites will contain unique data. That is, all of the data on the satellite is a replica of corporate data. If you need to re-create the data on the model office, you can perform a cold start of the Capture program. For information on this task, refer to the description of how to start the Capture program in the Windows and OS/2 environments in the Replication Guide and Reference.
To use refresh recovery, set the logretain database configuration parameter to Capture (if you are using DB2 data replication) or to No. To set a database configuration parameter, you can use either the Configure Database notebook, which is available from the Control Center, or the update database configuration command. For information about this command, refer to the Command Reference.
Development phase considerations:
Before you complete the development of the model office, you will likely not have an install image that you can use for refresh recovery. Instead, you may need to rebuild the model office by performing such tasks as reinstalling the operating system and DB2, and re-creating the database definition. The information that follows provides some guidelines that may help simplify the process of rebuilding the model office.
If a problem occurs during the development phase, you can simplify setting up communication information on the model office by either:
Consider keeping a copy of the database configuration file SQLnnnnn\SQLDBCON for the database on the model office. You can take a copy of this file every time that you change the value of one or more of the database configuration parameters. If you need to rebuild the model office, you can use the file to restore the database configuration without having to use the update database configuration command. You have to stop and restart the database so that the configuration values specified in the configuration file are activated for the database.
If you can easily re-create the database and its data (for example, you have the SQL statements and DB2 commands in a file), you will likely not require a backup image of the database. If, however, this assumption is not true, consider backing up the database, and storing the backup image in a location other than the model office.
You take an offline backup of the database using the backup database command.
| Note: | For an offline backup to succeed, the backup database operation must be the only application that is connected to the database. To ensure that the backup operation is the only application that is connected to the database, you can use the force application all command or the db2stop force command before issuing the backup database command. For information about using these commands, refer to the Command Reference. |
If you need to restore the database, you can restore it using the latest backup image that you have. Taking an offline backup each time that the database is in a consistent state as the result of a change to a batch or the successful application of a fix batch, however, can result in many backup images of the database.
You can identify whether the model office is configured as a test or a production satellite from the satellite details view, which is available from the Satellite Administration Center. For information on using the Edit Satellite notebook or the Set Execution Starting Point window, refer to the online help that is available from the Satellite Administration Center.
To use version recovery, set the logretain database configuration parameter to Capture (if you are using DB2 data replication) or to No. To set a database configuration parameter, you can use either the Configure Database notebook, which is available from the Control Center, or the update database configuration command. For information about this command, refer to the Command Reference.
If you are using version recovery, you should export the database manager configuration file and the node, database, and DCS directories on the model office to a file. This way, if you need to restore the configuration on the model office, you can restore it by importing the file, then restoring the database backup. You can export the directories and database manager configuration to a file using the db2cfexp command with the backup parameter. This command is described in the Command Reference.
With version recovery, you do not need to maintain a separate copy of the database configuration file SQLnnnnn\SQLDBCON. When you back up the database, the configuration file is automatically saved with the backup image. If you always back up the database after making a change to the database definition, you should always be able to restore the database and its configuration. If you only maintain the initial backup image of the database, the database configuration will be updated when the model office re-executes its group batches.
If you take a backup image every time the database is at a consistent state and you store the backup images on the model office, disk space may be an issue. You should decide how many backups that you want to maintain, and consider using a fix batch to delete older backup images that you do not want to retain. Consider deleting the older backups only after the current backup completes; otherwise, if a backup operation fails, your recovery strategy may be compromised. You can use the list backup command to return the list of backups that are available. When you delete a backup image, remember to use the prune history command to remove the record for the backup from the history file.
If you want to protect the database against media failure on the model office, you should consider storing the backup image on a different physical disk than the disk on which the database resides.
If anything happens to the database on the model office, you can restore it to its last consistent state. For example, if the results of a group batch or a fix batch are not satisfactory, instead of applying a fix batch, you can restore the database from the previous backup image, and try the change again. When you obtain the results that you want, then take a backup of the database. To restore the database, you can use the Restore Database notebook or the Restore Database SmartGuide, both of which are available from the Control Center. You can also use the restore database command. For information about this command, refer to the Command Reference.
| Note: | After restoring the database, you may have to cold start the Capture program to refresh the replicated data on the model office. You may have to perform this task because the replication control server contains log information indicating that the model office has already successfully executed the Apply program, so the replication control server assumes that the data on the model office is up-to-date. For information on cold starting the Capture program, refer to the description of how to start the Capture program in the Windows and OS/2 environments in the Replication Guide and Reference. |
You should only consider using forward recovery if your production satellites will contain unique data in the database that supports the end-user application. That is, not all of the data in this database will be a replica of corporate data. Because you will not be able to re-create the data on a production satellite from corporate databases, you should retain the database logs if it is important that this unique data can be recovered. The most likely situation in which you would use forward recovery is to recover the database from an error that cannot be undone by a fix batch, for example, a data replication error. In this situation, you would restore the database and roll it forward to the end of the logs to recover the unique data on the satellite.
To use forward recovery, set the logretain database configuration parameter to Recovery, regardless of whether you are using DB2 data replication. The value of Recovery retains the logs that are required for both forward recovery, and for DB2 data replication. To set a database configuration parameter, you can use either the Configure Database notebook, which is available from the Control Center, or the update database configuration command. For information about this command, refer to the Command Reference.
If you are using forward recovery, you should export the database manager configuration file and the node, database, and DCS directories on the model office to a file. This way, if you need to restore the configuration on the model office, you can restore it by importing the file, then restoring the database backup and rolling forward. You can export the directories and database manager configuration to a file using the db2cfexp command with the backup parameter. This command is described in the Command Reference.
With forward recovery, you may not need to maintain a copy of the database configuration file SQLnnnnn\SQLDBCON. Whenever you back up the database, the configuration file is saved with the backup image. If, however, the database configuration is changed and the database is not backed up when the change occurs, you should take a copy of the configuration file. After you roll the database forward, you can use the file to restore the database configuration without having to use the update database configuration command. You have to stop and restart the database so that the configuration values specified in the configuration file are activated for the database.
If you are storing the backup images and logs on the model office, disk space may be an issue. You should decide how many backups that you want to maintain, and consider using a batch step to delete the older backup images, as well as their associated logs. You can use the list backup command to return the list of backups that are available. This command also displays the name of the first log file that is associated with the backup. Consider deleting the older backups and logs only after the current backup completes; otherwise, if a backup operation fails, your recovery strategy may be compromised. When you delete a backup image, remember to use the prune logfile to delete the logs associated with the backup image, and the prune history command to remove the record for the backup from the history file. For more information about the prune commands, refer to the Command Reference
If you want to protect the database against media failure on the model office, you should consider storing the backup image on a different physical disk than the disk on which the database resides. You should also store the logs on a different physical disk than that of the database. To perform this task, use the newlogpath database configuration parameter. For information about this parameter, refer to the Administration Guide.
Because the test satellite can be installed from the image that you create from the model office, the recovery strategy that applies to the test satellite will be the same as that of the model office. That is, you will use refresh recovery, version recovery, or forward recovery to restore the database on the test satellite. For information about these types of recovery, see Recovering the Model Office.
[ Top of Page ]