Re: DB2/400 logging of read only access

MichaelQuigley wrote:

A word of caution, my understanding is that read triggers drastically
impact performance. With a read trigger things like blocked reads,
etc. are not available.

Blocking to the program is lost, but the database paging is still in effect. Random access via a unique index both prior to and after the addition of a read trigger sees the least but consistently measurable impact.

The recommendation I've heard is to at least double memory and CPU
resources to handle the triggers.

Only if based on FUD; e.g. by someone selling that hardware. It should be obvious that for lack of blocking, the memory requirements actually reduce in the program for its input. In most cases the only way to reduce the impact would be to get a faster CPU, not more CPU. Regardless, it is easy to test the true impact, by designing a trigger that does absolutely nothing; if ILE then with a named activation group. That fake read trigger can measure the minimal impact. Any additional [e.g. memory and real time] overhead in the actual read trigger program, beyond that for the fake read trigger program, will depend of course on what the real trigger program does; it should be designed for minimal impact to real time.

This may not be so big if the file *REALLY* is not accessed often

And that is best investigated for each situation. That is, the decision to avoid the read trigger should not be based on some implication of what the impact *might* be.

I think the recommendation to do object auditing generally makes more
sense.

So true, if read auditing [via *ALL object auditing; chgobjaud] is sufficient. If the requirement is to record accesses to any specific row versus the file.mbr, then only a read trigger would generically suffice [i.e. for access outside of application control]. For other situations the open\close entries for the journaled file might be a better option, and for some rare applications the /database open/ exit might be of value.

Regards, Chuck