Journaling
Global journaling preserves changes in the database since the last backup. While a backup is the cor-nerstone of physical recovery, it is not the complete answer. Restoring the database from a backup does not recover changes made since that backup. Typically, this is a number of hours before the point at which physical integrity was lost. What happens to all the database changes that occurred since then? The answer lies with journaling.
This chapter discusses the following topics:
• Journaling Overview
• Configuring Journaling
• Journaling Operation Tasks
• Journaling Utilities
• Journal I/O Errors
• Special Considerations for Journaling — includes information regarding UNIX file systems and performance.
3.1 Journaling Overview
Each instance of Caché keeps a journal. The journal is a set of files that keeps a time-sequenced log of changes that have been made to the databases since the last backup. The process is redundant and logical and does not use the Caché Write daemon. Caché transaction processing works with journaling to maintain the logical integrity of data.
When Caché starts, it reapplies all journal entries since the last Write daemon pass. Since user processes update the journal concurrently, rather than through the Write daemon, this approach provides added assurance that updates prior to a crash are preserved.
The configuration and management of Caché journaling provides a safe and consistent approach to supporting highly available systems. The journaling state is a property of the database, not individual globals. A database can have only one of two global journaling states: Yes or No.
The journal contains global update operations (primarily Set and Kill operations) for globals in trans-actions regardless of the setting of the databases in which the affected globals reside, as well as all update operations for globals in databases whose Global Journal State is Yes. This greatly improves the reliability of the system; it avoids inconsistencies (after crash recovery) due to updates to globals that may or may not be journaled, and that may or may not be involved in transactions.
Journaling global operations in databases mounted on a cluster depends on the database setting. The local Caché instance does not journal transaction operations to globals on remote nodes. In a network configuration, journaling is the responsibility of the node on which the global actually resides, not the one that requests the Set or Kill. Thus, if node B performs a Set at the request of node A, the journal entry appears in the journal on node B, not node A.
Backups and journaling are daily operations that allow you to recreate your database. If any problem arises that renders your database inaccessible or unusable, you can restore the backups and apply the changes in the journal to recreate your database. This method of recovering from a loss of physical integrity is known as “roll forward” recovery. The journal is also used for rolling back incomplete transactions.
The default Global Journal State for a new database is Yes. New Caché instances have the journaling property set to Yes for the CACHEAUDIT, CACHESYS, and USER databases. The CACHELIB, CACHETEMP, DOCBOOK, and SAMPLES databases have the property set to No. Operations to globals in CACHETEMP are never journaled. Map temporary globals to the Caché temporary database,
CACHETEMP.
The following topics provide greater detail of how journaling works:
• Differences Between Journaling and Write Image Journaling
• Protecting Database Integrity
• Automatic Journaling of Transactions
• Rolling Back Incomplete Transactions
• Using Temporary Globals and CACHETEMP
• Journal Management Classes and Globals
3.1.1 Differences Between Journaling and Write Image Journaling
In this chapter, “the journal” refers to the journal file; “journaling” refers to the writing of global update operations to the journal file.
Do not confuse the Caché journal described in this chapter with write image journaling, which is described in the “Write Image Journaling and Recovery” chapter of this guide. Journaling provides a complete record of all database changes, as long as you have journaling enabled for the database. In the event of database loss or degradation, you restore the contents of the journal file to the database.
Write image journaling provides a copy of any database modifications that are not actually written to the database when a system crash occurs. In such a case, Caché automatically writes the contents of the write image journal to the database when it restarts.
3.1.2 Protecting Database Integrity
The Caché recovery process is designed to provide maximal protection:
• It uses the “roll forward” approach. If a system crash occurs, the recovery mechanism completes the updates that were in progress. By contrast, other systems employ a “roll back” approach, undoing updates to recover. While both approaches protect internal integrity, the roll forward approach used by Caché does so with reduced data loss.
• It protects the sequence of updates; if an update is present in the database following recovery, all preceding updates are also present. Other systems which do not correctly preserve update sequence may yield a database that is internally consistent but logically invalid.
• It protects the incremental backup file structures, as well as the database. You can run a valid incremental backup following recovery from a crash.
3.1.3 Automatic Journaling of Transactions
In a Caché application, you can define a unit of work, called a transaction. Caché transaction processing uses the journal to store transactions. Caché journals any global update that is part of a transaction regardless of the global journal state setting for the database in which the affected global resides.
You use commands to:
• Indicate the beginning of a transaction.
• Commit the transaction, if the transaction completes normally.
• Roll back the transaction, if an error is encountered during the transaction.
Caché supports many SQL transaction processing commands. See the “Transaction Processing”
chapter of Using Caché ObjectScript for details on these commands.
3.1.4 Rolling Back Incomplete Transactions
If a transaction does not complete, Caché rolls back the transaction using the journal entries, returning the globals involved to their pre-transaction values. As part of updating the database, Caché rolls back incomplete transactions by applying the changes in the journal, that is, by performing a journal restore.
This happens in the following situations:
• During recovery, which occurs as part of Caché startup after a system crash.
• When you halt your process while transactions are in progress.
• When you use the Terminate option to terminate a process from the [Home] > [Process Details]
page of the System Management Portal. If you terminate a process initiated by the Job command, the system automatically rolls back any incomplete transactions in it. If you terminate a user process, the system sends a message to the user asking whether it should commit or roll back incomplete transactions.
You can write roll back code into your applications. The application itself may detect a problem and request a rollback. Often this is done from an error-handling routine following an application-level error.
See the Managing Transactions Within Applications section of the “Transaction Processing” chapter of Using Caché ObjectScript for more information.
3.1.5 Using Temporary Globals and CACHETEMP
Nothing mapped to the CACHETEMP database is ever journaled.
Since the globals in a namespace may be mapped to different databases, some may be journaled and some may not be. It is the journal property for the database to which the global is mapped that determines if Caché journals the global operation. The difference between CACHETEMP and a database with the journal property set to No, is that nothing in CACHETEMP, not even transactional updates, are journaled.
If you need to exclude new z/Z* globals from journaling, map the globals to a database with the journal property set to No. To always exclude z/Z* globals from journaling, you must map them in every namespace to the CACHETEMP database.
Caché does not journal temporary globals. Some of the system globals designated by Caché as temporary and contained in CACHETEMP are:
• ^%cspSession
• ^CacheTemp*
• ^mtemp
3.1.6 Journal Management Classes and Globals
See the class documentation for %SYS.Journal.System in the Caché Class Reference for information on available journaling methods and queries. It is part of the %SYS.Journal package.
Also, Caché uses the ^%SYS(“JOURNAL”) global node to store information about the journal file.
For example:
• ^%SYS("JOURNAL","ALTDIR") stores the name of the alternate journal directory.
• ^%SYS("JOURNAL","CURDIR") stores the name of the current journal directory.
• ^%SYS("JOURNAL","CURRENT") stores journal status and the journal file name.
You can view this information from the [Home] > [Globals] page of the System Management Portal.