When CONTROL starts a backup operation, the database kernel first generates a checkpoint and then delivers all pages of the database in the state valid at that checkpoint. Any ongoing modifying activity does not write to these pages, so a consistent save is produced without shutting down modifying activities. However, this checkpoint can only be generated when all modifying transactions that are already running have come to an end. The time needed cannot be determined beforehand as it depends on the transactions running. This unknown delay may cause an archiver tool involved to detect a timeout if such a feature is provided and the transactions running take too long. If this delay causes problems, the ADABAS mechanisms to display lock manager information must be used to identify the transaction(s) holding "exclusive" locks and thus causing the delay.
When CONTROL starts a restore operation, the database kernel first accesses the devspaces involved and then initializes a mapping of the database pages to disk blocks (the system devspace). This causes a delay between reading the first pages (containing the configuration information) and the bulk of the data. The time needed depends on the size of the database and on the speed of the machine. This delay may cause an archiver tool involved to detect a timeout if such a feature is provided and it is configured too small. Based on current customer information, a period of ten minutes should be sufficient.