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.
Note: Separate physical disk subsystem consists of a separate I/O channel, disk controller, and at least one disk drive.
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.
Journal Close Action |
Processing |
None |
No action taken. |
Remove |
Removes the journal file. |
Copy |
Uses the operating system to copy the file to the archive directory. |
Move |
Uses the operating system to move the file to the archive directory. |
CopyAndCompress |
Programmatically creates a compressed copy of the file in the archive directory (using ZLIB compression). |
MoveAndCompress |
Programmatically creates a compressed copy of the file in the archive directory (using ZLIB compression) and then removes it. |
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:
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.
If the answer to this question is yes, then the option to use archival recovery should be enabled.
If the answer to this question is yes, then the option to use archival recovery should be enabled.
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.
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.
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:
Action |
What it does |
None |
Nothing |
Remove |
Removes the log files |
Copy |
Copies the log files to the JournalArchiveDirectory path |
Move |
Moves the log files to the JournalArchiveDirectory path |
CopyAndCompress |
Same as copy but compresses in the process using ZLIB |
MoveAndCompress |
Same as move but compresses in the process using ZLIB |
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. You can verify restored log files.
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.