A shadow database is a consistent copy of the database in which all database file names have the suffix copy-name.
The shadow database can be concurrently used with the original database being processed as follows:
It can be read, e.g. to generate information or statistics, without hindering database operation.
It can be updated continually with the after-images of the completed ALOG file(s) of the original database. This provides you with relatively current data resources in the event of an error.
You can create a shadow database by copying the files of the original database (without the ALOG files) or by renaming another backup that was read. The file names of the database files of a shadow database are given a freely selectable suffix copy-name. The following general rules apply to the shadow database:
db-file-name.copy-name
db-file-name
Name of the database file (e.g. dbname.realm-name)
The specification :catid:$userid.dbname.realm-name.copy-name may be no more than 54 characters long.
copy-name
Suffix ("name") of the shadow database. copy-name may be no more than seven characters long.
If the online backup capability was set for the original database, you should note the comments set out in section “Online backup capability of a database copy” in chapter "Saving a database online".
The shadow database has no separate ALOG files. It is updated using the ALOG files of the original database.
If you modify the DBDIR of the shadow database by administrative measures (e.g. with the ENABLE, DISABLE, ADD and REMOVE statements) and then make this DBDIR the original, you are responsible for its status (attached/detached realms, activated/deactivated online backup capability).
The subschema name must be unique within a multi-DB configuration, i.e. you cannot use both the original and shadow database of the same database within a configuration. You can, however, use the original and shadow databases of different databases within a configuration.
The shadow database is handled by RETRIEVAL in the same way as an original database without AFIM logging. Application programs cannot make a distinction between original and shadow databases; they address them via the same subschema names.
If you use an older status of a shadow database, you may need to provide the old user modules, SSITAB modules, etc.
Read-only application programs and read-only UDS/SQL utility routines (e.g. BCHECK, copy routine BOUTLOAD, BPRECORD, BPSIA, BPSQLSIA and BSTATUS) can work with the shadow database concurrently. Of the updating utility routines, only BMEND can access the shadow database. Deactivated realms can also be reconstructed by BMEND in parallel with shadow database operation.