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.