Archival Recovery

---

If it is not acceptable to lose committed transactions in the event of a catastrophic failure, the database must operate with archival recovery enabled, with these additional requirements.

Mandatory

• Transaction log volume must be mirrored, and ideally duplexed (dual controller).
• Transaction logs must be on a separate physical disk subsystem or volume to that hosting database files.

Recommended

• Database files should be on a fault-tolerant disk subsystem.
• Configure separate physical disk subsystem for disk-resident transaction log and database backups.
• Local tape backup unit or network backup strategy to enable database and log backups to be moved off the machine that is hosting the database.

Note: Separate physical disk subsystem consists of a separate I/O channel, disk controller, and at least one disk drive.

Relevant Initialization parameters

The EnableArchivalRecovery parameter in the [PersitentDb] section of the JADE initialization file is used to enable or disable the archival recovery option.

You must select this parameter before creating the first archival backup, so that the _control.dat database control file contained in the backup is initialized in the correct way.

The JournalArchiveDirectory parameter in the [PersitentDb] section of the JADE initialization file specifies the fully qualified directory for the location of archived transaction journal files for recovery purposes. If you do not specify a value for this parameter, the JournalRootDirectory\archive directory is used.

The JournalCloseAction parameter in the [PersitentDb] section of the JADE initialization file specifies when a journal file that is no longer required is closed and released. When the EnableArchivalRecovery parameter is set to the default value of false, the specified close action is ignored and unwanted journal files are removed. When archival recovery is enabled, the close actions that you can specify appear in this table.

If you have not specified a directory in the JournalArchiveDirectory parameter, the \archive directory is a subdirectory of the directory specified in the JournalRootDirectory parameter.

The option to enable Archival Recovery depends on the answer to several of the questions:

How much data is the business prepared to lose?

If the answer to this question is that the business cannot afford any data in the event of failure (or as close as practically to it), then the option to use archival recovery should be enabled. You should consider how much effort is required to re-enter data in the event that things do not go to plan.

Will data must be recovered to arbitrary times in the past?

If the answer to this question is yes, then the option to use archival recovery should be enabled.

Does the database must be available times (24 hours a day, 7 days a week)?

If the answer to this question is yes, then the option to use archival recovery should be enabled.

Why Enable Archival Recovery?

Because archival recovery enables a database to be recovered to the status that it was at immediately before the failure, or to an arbitrary time in the past which falls between the last system backup, and the time of Greentree Desktop failure.

Separate archive log files are created in the database system directory, containing recently processed transactions. In effect, they represent the live incremental changes to the database. Each log file is given a unique incremental name, such as db0000001.log, db0000002.log, and the like. Once the log file reaches a pre-defined size, a new log file is created. The current log file that contains information of the latest transactions and processes always have the highest number (and is smaller than the previous files).

These log files may be used in a recovery process which not only restores the latest backup, but also applies the incremental archive logs to roll Greentree Desktop forward into a specific position before the failure.

Archival Recovery Trade-Offs

Given the advantages associated with the archival recovery process, it is natural to assume that archival recovery should be enabled times. However, there is an administrative trade-off for using the archival process that are not warranted in many cases. There are two main trade-offs:

Disk Space

Archive log files are generated (and updated) into a specific directory named in the .ini file. The quantity and size of these files may become an issue.

Log file backups & maintenance

Archive log files must be backed up. The backup processes outlined in this document do not do this for you. You cannot fully recover a database if the consecutively numbered archive log files have not been backed up.

In summary, if archival recovery is enabled, there is some administrative costs of the process. Ensure that you work with archived log files in consecutive order, and are always available in the event of having to restore from a failure.

How to Enable Archival Recovery

Archival recovery is enabled using settings in the database .ini file. These settings are in the [PersistentDb] section of the .ini file. The settings should only be updated when Greentree Desktop and it's services are shut down or stopped on the server. An online backup should be initiated immediately after making any changes to this section and before re-starting the services.

EnableArchivalRecovery=true

This must be set to true to enable archival recovery.

JournalRootDirectory=d:\system\archivelogs

This is the location the logs are stored (whether you are using archival recovery or not). This path should point to a drive that is different to the server path (though it must be on the same machine). For example, if Greentree Desktop is on driver C of the machine, point the log file to driver D of the same machine.

JournalMaxSize=6M

This is the maximum size the log file should get to before it creates a new one. The recommended setting is 12M, however in the event of a disk failure, this may represent a significant amount of data loss. An assessment about the file size should be made on a site by site basis.

JournalArchivalDirectory=\\servername\sharename\Gtree\Logs

This is the location Greentree Desktop will place the above log files into when the have reached the maximum size. These is used to roll the data forward from a backup in the event of a failure.

Note: This location should be included in the Windows backup policy as these files are not backed up by the online backup (only the current log is).

JournalCloseAction=Move

This setting determines what happens to the log files when they have reached their maximum size (those in the JournalArchivalDirectory). These options are available:

Note: If you turn archival recovery on when it has not been used previously, you must change the settings in the .ini file while Greentree Desktop is shut down, and re-start Greentree Desktop before the new settings take effect. The next backup taken will operate with archival recovery in use.

Archival Transaction Log File Backups

A critical factor in using archival recovery is that you must maintain backups of the archival transaction logs. The backup processes outlined in this document do not do this for you.

When archival recovery is in use, the database files from the last backup and all the archived transaction logs created since the last backup must be used in the recovery process. For this reason, you should protect against media failure, and always locate the archived transaction log files on a different physical volume to the live database files.

Archive logs can either be backed up, or by using the jdbutil.exe form and selecting the Backup Transaction Logs option from the Operation menu. You should archive transaction logs are backed up this way as there is an option to verify the files following the backup (which means that restored log files can also be verified).

Note: The .ini file must specified on the command line when you run the jdbutil.exe shortcut.

An independent verification of archive transaction logs may be performed , by selecting the Verify Transaction Logs option from the Operation menu. As with database backup files, always perform verification on files before and after they are moved from one media to another.

• Verify Checksums
• Restoring a Database from Backup

---