Re: DB2/400 logging of read only access

[CRPence <CRPbottle@xxxxxxxxx>]

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