#Journaling

InterSystems has been at the forefront of database technology since its inception, pioneering innovations that consistently outperform competitors like Oracle, IBM, and Microsoft. By focusing on an efficient kernel design and embracing a no-compromise approach to data performance, InterSystems has carved out a niche in mission-critical applications, ensuring reliability, speed, and scalability.

What is Journaling?

Journaling is a critical IRIS feature and a part of what makes IRIS a reliable database. While journaling is fundamental to IRIS, there are nuances, so I wrote this article to summarize (more briefly than our documentation which has all the details) what you need to know. I realize the irony of saying the 27 minute read is brief.

Every modification to a journaled database (sets and kills) is recorded with its timestamp in a journal file. This runs in parallel with writes to the databases and the write image journal (WIJ) for redundancy.

InterSystems FAQ rubric

If the system does not stop for 24 hours, old journal files will be deleted at 0:30 according to the "Journal file deletion settings".

A possible cause of journal files remaining that are older than the "Journal file deletion settings" is that there are transactions that remain open.

In that case, you will be able to delete the journal file by searching for processes executing transactions and finalizing the transactions.

The sample below checks for the existence of open transactions, and if they exist, outputs the target file name and journal record information.

Hi community!

In this article, I'm excited to introduce my latest application, Journal File Indexer. The development of this application is rooted in the portal idea  DPI-I-270.  

In short, this application lets you load and index a log file in a database.  

Why?

If you've ever used the log file search function in the management portal, you may have encountered a timeout error or even a blank page. This problem usually occurs when searching a large journal file. Journal File Indexer solves this problem by considerably increasing the speed of searches once the file has been loaded into the database.  

Another problem arises during the restoration process. When searching for global entries in a log file to restore old or new values, the management portal doesn't have this specific functionality. A routine must therefore be coded to achieve this. Journal File Indexer comes to the rescue, incorporating a restore function!

Recently I needed to restore a version of a production class, which was overwritten by compilation and running UpdateProduction. As the correct version was unavailable in the source control, I used journals to restore the data. Journals store a plethora of information about what's happening in the system and are quite a powerful tool. This article explains how to work with journals to extract the data you require.

Coming back to the topic of how to minimize journals.

Working in support, I usually get asked how many days I should keep journals. Should it be two days or after two backups? More? Less? Why two?

The correct answer (for most of the environments) is that you should keep the journals since the last validated Backup. I.e., until you don't check if a Backup is valid (restoring the file and checking with the Integrity utility), you can't be sure there is a good copy of your data and can't purge the journals safely.

For example, imagine you need to restore your system after a hardware failure that corrupted some databases.

In this article I'd like to share with you a phenomena that is best you avoid - something you should be aware of when designing your data model (or building your Business Processes) in Caché or in Ensemble (or older HealthShare Health Connect Ensemble-based versions).

Question:

My journal files are growing  rapidly - what could be the cause? How can I minimize the phenomena?

Hi Everyone,

Link to webinar recording: https://learning.intersystems.com/course/view.php?id=623

Thank you for your interest in this webinar!

Please submit questions about the content of the webinar as comments below this article.

The webinar covers two topics: monitoring message activity and volume and monitoring disk space. I summarize and motivate the topics in the following two sections. The information in this webinar and post applies to the Ensemble, Health Connect, and HealthShare products. For simplicity, I am only going to refer to Ensemble in this post.

Following my previous post, some urged me to get to the point – ok, so I found my "star" journaling globals, the ones that take up the most space – but how do I avoid this? How do I minimize the journal's size?

[DISCLAIMER: Some might still be disappointed after this post as well  but wait till the next one... ]