GT.M's extensive journaling capabilities are optional. You may choose to journal some, all, or none of your database files.
Use the following descriptions of journaling functionality to choose the best approach for your organization.
M database management ensures that multiple concurrent updates and retrievals of the same information (or information "close together" in ordered sequence) are handled in a predictable and logical fashion. Sometimes the database manager may have to change multiple records, usually indices, as a result of a single update. Interrupting a process that is performing such a "multi-point" update violates a design assumption of the M implementation and also results in a malformed database. Under normal operation, the database logic handles interruptions by deferring their recognition until the update is complete. However, occurrences such as power failures can cause such interruptions.
When a computer system crashes, the database can be left in a transient state that is damaged. Continuing to use such a database can result in unexpected and undesirable results; including system hangs, incorrect results, the faulty application of business logic, as well as further damage to the database. Journaling can provide for automated recovery and repair of the database, eventually eliminating the need for manual repair.
Advantages of journaling options include:
Automatic "replay" of work to the last committed update recorded in a journal file. Note that with the use of transaction processing and journaling, GT.M provides full ACID properties.
Quick recovery options, such as processing only the information recorded immediately prior to failure.
For example, you can recover just the last minute of work instead of replaying the entire journal file.
Recorded database updates formatted appropriately for processing by an M program.
For example, MUPIP JOURNAL /EXTRACT outputs records specified by time, user, the process identification number, global variable, process name, and transaction type.
Identification of processes active when the system failed.
The /SHOW qualifier identifies these processes, as well as what transactions were not completed, and other information about the database updates and processes contained in the journal file.
While journaling is generally a valuable safeguard in protecting your work, there are issues that may deter you from invoking it.
Journaling requires additional CPU cycles, memory, and disk access. This can impact application performance.
Journaling may duplicate features already built into your applications. In that case journaling provides no additional value to your organization.
A journal file has questionable value in the case where the database and the journal share a common point of failure that affects the information in both over a significant period of time. This can be addressed by using different disks and different disk controllers (where possible) for the journal and the associated database files.
Without journaling, the most common method of recovery is to load a backup copy of the database and then re-enter the work completed since the backup was made.
Most of the overhead costs associated with recovering from a failure usually derive from maintaining a state of preparedness for the manual recovery, and the potential risk to the organization from damage to the information during the relatively infrequent and "abnormal" handling of a recovery. Therefore, you must weigh the cost of reduced computer throughput or, alternatively, the additional hardware to support journaling with the same level of performance, against the reduced likelihood of a prolonged manual re-entry with its associated drawbacks.
Some users may journal only heavily updated globals. However, since infrequently changed globals generate little additional load and may present significant control problems if not journaled, you may decide that these globals should also be journaled to maintain application integrity.
You can use other means to recreate those globals that contain only static information or process-local (temporary) information. Given the disk space and disk channel overheads associated with journaling, there is a significant performance benefit to separating globals that fit either of these categories into separate database files that do not require journaling.
When databases contain only temporary information, they can be deleted and recreated with MUPIP CREATE during a recovery. In the unlikely event that a failure damages truly static files, the files can be restored from backups without journal recovery.