Automated Journal Close Actions

You can automate the backing up of transaction journal files as they are closed, to ensure that this operation is not neglected. (The automating of the journal close action is ignored and unwanted journal files are removed when the EnableArchivalRecovery parameter in the [PersistentDb] section of the Jade initialization file is set to the default value of false.)

When archival recovery is enabled, use the JournalCloseAction parameter in the [PersistentDb] section of the Jade initialization file to specify one of the following close actions.

• Copy, which uses the operating system to copy the file to the archive directory

• CopyAndCompress, which programmatically creates a compressed copy of the file in the archive directory (using ZLIB compression mechanisms)

• Move, which uses the operating system to move the file to the archive directory

• MoveAndCompress, which programmatically creates a compressed copy of the file in the archive directory (using ZLIB compression mechanisms) and then removes it

• None, which takes no action

The journal close actions operate in conjunction with the JournalArchiveDirectory parameter, which specifies the destination directory for move and copy operations. The journal close action occurs when the database closes a journal. The database closes a journal when it releases it; that is, when it is no longer required for transaction abort processing or to restart recovery processing. (Switching journals, described under "Journal Switches and Journal Numbers", earlier in this chapter, is an independent activity to that of releasing journals.)

When you set the JournalCloseAction parameter to Move, the journals in the folder of active (live) journals are the current journal set and are held open by the database to prevent accidental removal. The current journal set comprises those journals required to back out the oldest transaction if it aborts or to perform recovery on restart after failure.

The number of the abort journal is not incremented. It changes based upon transaction activity, to reflect the oldest journal required for transaction abort or the restart recovery point established by the last checkpoint (whichever is farthest back in time). If there is no transaction activity, the abort journal number is not incremented.