To select the recovery concept that meets your own requirements, you must consider various criteria and their relative importance. This section describes some of the concepts available, taking into account the following criteria:
The update level of the data (e.g. whether data already modified is lost)
The overhead involved (e.g. memory and storage requirements, cost of making a backup)
Availability (reconstruction time following an error)
The concepts are listed in increasing order of availability of the database.
No saving
Database operation takes place without any saving or AFIM logging.
Update level
Following an error, all data - both the original data and data that has just been modified - is lost.
Overhead
None.
Availability
None. The database must be generated and loaded again.
Saving the database periodically
The entire database is saved periodically. Database operation takes place without AFIM logging (e.g. to enhance performance). If an error occurs, the database is reset to the last database backup.
Update level
Data that has been modified since the last backup is lost.
Overhead
The database must be saved and archived. If in the event of an error the modified data is to be regenerated, e.g. by repeating the update transaction after saving, the update transactions must be saved separately in the correct chronological order and executed again.
Availability
The availability of the database in the event of an error is very limited. It is determined by the time taken to reset the database to the last backup status and, in some cases, by the time taken to restore data (by repeating the saved transactions). Database operation is not possible while the database is being saved.
Periodic saving and AFIM logging
The database is saved periodically. The changes are recorded in the ALOG file(s) during database operation.
Update level
No data is lost, although the different statuses between backups must be reconstructed.
Overhead
Creation of the backup (during which time no database operation is possible).
Archiving of the saved database and the ALOG files.
Memory and device requirements for AFIM logging.
Slightly longer duration of transactions due to I/O for AFIM logging.
Availability
The availability of the database in the event of an error is limited.
Time is required to reset the database to the backup.
Time is required to update the backup status with ALOG files. The time depends on the number and size of the ALOG files to be applied.
No database operation is possible while the database is being saved.
Online backup and AFIM logging
Online backup is performed at the backup times during database operation. Database operation is possible only if AFIM logging is activated.
Update level
No data is lost, but intermediate statuses may need to be reconstructed.
Overhead
Memory and device requirements for online saving (depending on the size of the database).
Archiving of the saved database and the ALOG files.
Memory and device requirements for AFIM logging.
Slightly longer duration of transactions due to AFIM logging.
Availability
The availability of the database is increased even more because the backup can be made during database operation.In the event of an error, the availability depends on the time required
to read in the online backup again
to make the backup status consistent using ALOG files and to update it, if necessary.
Shadow database and AFIM logging
A shadow database is maintained parallel to the original database. When the ALOG file is switched (e.g. using the DAL command CHECKPOINT), the completed ALOG file can be applied to the shadow database immediately.
Update level
The backup has a high update level even in the event of an error; only the data of the current ALOG file must be applied.
Overhead
Creation of the shadow database.
Memory and device requirements for the shadow database (particularly for large databases).
Memory and device requirements for AFIM logging.
Slightly longer duration of transactions due to AFIM logging.
Immediate updating of the shadow database following an ALOG file switch.
Availability
The availability of the database is very high, even in the event of errors.
The shadow database can be created - by means of online saving - and updated during normal database operation.
If errors occur, database operation can be resumed as soon as the defective parts of the database have been replaced (e.g. by renaming the parts of the shadow database) and the current ALOG file has been applied.