DBAM triggers versus Journaling for Auditing

[Eric Lehti]

Hi Luke, You posted a response to my DBAM question, and I am starting this new thread "DBAM triggers versus Journaling for auditing"
You said, "How do you find DBAM? Most companies are using journaling these days rather than triggers."

Please expand on your point.

Can DBAM triggers function similar to Journaling?

We use Journaling (the Vision Solutions iTera Echo2 High-availability product) also. A journal entry is created for every change anywhere in an object (Add/change/delete), and transmits the journal entry to the Target HA machine so that the HA machine is a mirror of production. The Journal Receivers expire and get deleted after 48 hours so that disk space is conserved.

We use DBAM to perform a field-level granular audit of one or several fields in a physical file, not every field in a table. The before-and-after state of the field(s) is written to a physical file.

Are you saying that journaling is typically used in the fashion I describe for DBAM? What commercial solutions use journaling for auditing database changes at the field/column level? My understanding is that journaling tracks changes on all columns in a table.
I do not understand how journaling can provide the functionality that we enjoy with DBAM triggers.

 

[Leith]

Hello Eric

When I first wrote an Audit solution for World I asked the developers at Oracle why they based DBAM on trigger logic as opposed to Journaling and they made the point that you just made.

The trigger program can function intelligently in that it can select specific fields for both monitoring and recording. That is to say you can take a file with a large record format like the address book and monitor for changes to 10 fields in it and record 20 fields excluding the rest. This means that not only do you focus recording on the changes to significant fields but you can also limit the size of the record format you are keeping.

We have extended this functionality to allow update alerting through triggers again, on the DBAM audit receivers.

Triggers can also work pre-emptively, to support E-signature type functionality which cannot be done with a journal.

There are Journaling based audit tools, from companies like RAZLEE but these have usually been designed as generic OS400/IOS solutions, whereas DBAM was written for JDE World and sits within that application layer.

You mentioned cleaning up journal receivers, which are typically kept within an organisation for 2-7 days, which goes to another point. Because of volume issues Journal based solutions sometimes write to a separate “permanent” database, but that seems to simply be duplicating effort.

DBAM also writes to normal OS400/IOS database tables, so there is no need for Journal extraction routines.

Journaling was never designed for audit, it was designed for HA solutions like the Mimix solution your refer to, and transactional integrity by rollback through commitment control.