Journaling is the primary mechanism used by logical software replication tools such as Rocket iCluster and other products. Products such as IBM SystemMirror for IBM i or PowerHA use a combination of disk level mirroring done by the SAN or operating system based mirroring at the page level using IASPs (Independent Auxiliary Storage Pools). So if you are currently using a software replication tool, you need to understand journaling and what is in your journals.
If you have been an IBM i customer since it was the good old AS/400 and came in a white box, you are probably intimately familiar with the basics of journaling. This blog post is NOT for you. Go practice your REXX coding or cobble together a neat new CL using an unknown API and come back next week! If you are new to the platform, or are more familiar with other databases like SQL or Oracle, take a few minutes and hang around.
So what is a journal? A journal is a logical operating system construct which along with the attached journal receivers, knows what is going on in your database before the database itself! There is a single audit journal called QAUDJRN in library QSYS which captures changes to everything that isn’t data areas, data queues, IFS or physical files. Changes to physical files are captured in “database journals” of which you can have as many as you want or need and can be stored in any library.
Think of a journal as the database equivalent of a point and shoot digital camera. What the journal does is take pictures of every single change that occurs to your physical files or in the case of the system audit journal, changes to all other objects. So every file rename, file move, user profile creation, record insert or record update – SNAP, a picture is taken by the journal. In other databases this is sometimes called a database log. The SD card in the camera is the journal receiver. I can have one receiver attached to a journal at any one time – similar to having 1 SD card in the camera. When the receiver is full, the operating system (or you manually) can detach the receiver and attach a new one (i.e. swap SD cards). Once the transaction is captured by the journal, the operating system automatically applies that change to the object or physical file.
Journals and journal receivers can be queried and examined, and since everything that happens is captured, it makes a great audit trail for determining who did what to what file/object and when. It also can be configured to capture both the before and the after image of the record. Have you ever experienced this….
If you have, you NEED journaling.
In our next post we will look at what is actually in the journal. Stay tuned!
iCluster Tech Tuesday
Latest posts by iCluster Tech Tuesday (see all)
- iCluster and Mobility Part 4: Deploying the Mobile Monitor - July 28, 2015
- iCluster and Mobility Part 3: Apache Tomcat for Dummies - July 21, 2015
- iCluster and Mobility Part 2 Getting Started - July 14, 2015