When formulating your strategy, try to answer the following questions.
How much data can I lose? (committed transactions recovery point)
You can minimize the chances of losing journal data (and where practicable, you should) using various techniques such as mirroring to a separate physical volume. You cannot, however, eliminate the possibility that an event will occur that makes immediate access to the journal data on your drives impossible.
Generally, the frequency with which you want the transaction journal to switch, be verified, and transferred to a backup medium and re‑verified is governed by the number of transactions on the database and the acceptable amount of journal data that can be lost if the system has a critical failure. The upper limit of journal data that may be lost is proportional to the number of transactions that occur in the period between journal switches.
The JADE initialization file [
It is common to view the issue in terms of time. A database may have a specified
It isn’t true that you always lose this data, but in the worst case, is it acceptable to require the re‑entry of about an hour’s worth of business operation? Halve the journal file size and it is half the re‑entry work. The cost of establishing what exactly requires re‑entry is the same, in any case.
If the maximum amount of data loss that can be tolerated is close to zero, you should give serious consideration to implementation of an SDS environment. (See "Synchronized Database Service", later in this document.)
How much data will you risk losing?
How quickly must I complete the recovery? (recovery time)
The frequency of database backups has some bearing on the length of time it takes to recover from a failure. If a database with a high rate of transactions is backed up offline only once a week, it can take a significant amount of time to restore and verify the database and to restore and verify the transaction journals in preparation for recovery from a crash occurring late in the week. The recovery processing itself is normally only a fraction of the total overall time it takes to get the database back online.
Supplementing the weekly offline backups mentioned above with mid‑week overnight online backups would approximately halve the number of transaction journals requiring reloading, verification, and reapplication.
If the maximum down‑time that can be tolerated is measured in minutes rather than hours, you should give serious consideration to implementation of an SDS environment. (See "Synchronized Database Service", later in this document.)
How long can your system be down?