The term “shadow database” refers to a replication of an original database that is maintained in parallel with the original. Using shadow databases, you can:
free a DBH from pure read accesses during OLTP operation
repair an original database
reset an original database
create an independent database
In this section, the illustration below will be used to describe how you can maintain a replication as a shadow database. For an explanation of the individual steps, refer to the next page.
Figure 23: Using a replication as a shadow database
Use CREATE REPLICATION to create a replication from a SESAM backup copy or a foreign copy of the original database.
If you want to use a replication as a shadow database you must update it at regular intervals. This process is described in steps 2 to 4:
Start a transfer of the log files from the original database at appropriate intervals.
Use the utility statement REFRESH REPLICATION to apply the modifications to the log files in the replication.
If the original database is defective, repair it using the replication:
Use the utility statement RECOVER CATALOG..USING REPLICATION to repair the original database. When you do this, the replication serves as the backup copy. With this operation the modifications are applied to the log files created since the last update of the replication.
You can shorten the down time of the original database by using the RENAME parameter. When you do this, the replication is renamed and thus becomes an original database. The original database thus continues to be fully available and you can now create a new replication to be used as the shadow database.
You can further reduce the down time by repairing only the defective spaces with the utility statement RECOVER SPACE USING REPLICATION RENAME or the catalog space with RECOVER CATALOG_SPACE USING REPLICATION RENAME.
The user spaces will then be missing from the replication. These can be added to the replication with REFRESH SPACE. Alternatively, you can also recreate the replication.