Contents Index A backup scheme for when disk space is plentiful A backup scheme for databases involved in replication

ASA Database Administration Guide
  Backup and Data Recovery
    Designing backup procedures

A backup scheme for databases not involved in replication


In many circumstances, disk space limitations make it impractical to let the transaction log grow indefinitely. In this case, you can choose to delete the contents of the transaction log when the backup is complete, freeing the disk space. You should not choose this option if the database is involved in replication because replication requires access to the transaction log.

A full backup, which truncates the log file, is illustrated in the figure below. In an incremental backup, only the transaction log is backed up.

In a full backup where the log file is truncated, the database file and log file are copied to the backup directory. Once the backup is complete, the log file is truncated. The backup leaves the database file in place.

Deleting the transaction log after each incremental backup makes recovery from a media failure on the database file a more complex task as there may then be several different transaction logs since the last full backup. Each transaction log needs to be applied in sequence to bring the database up to date.

You can use this kind of backup at a database that is operating as a MobiLink consolidated database because MobiLink does not rely on the transaction log. If you are running SQL Remote or the MobiLink dbmlsync.exe application, you must use a scheme suitable for preserving old transaction logs, as described in the following section.

For more information on how to carry out a backup of this type, see Making a backup, deleting the original transaction log.


Contents Index A backup scheme for when disk space is plentiful A backup scheme for databases involved in replication