If you are using (or are planning to use) DB2 AUDITING, please help me as I look for clues and try to find the 'truth' about setting the audit_buf_sz DBM CFG parameter.
Long ago in my youth, I read and heard that setting audit_buf_sz to zero was reported to cause
some serious performance degradation on audited DB2 systems. I believed the claim. It certainly seemed plausible.
But, being a security junkie, my job was SECURITY not PERFORMANCE....boy was that a bad assessment on my part.
If security has to battle performance in an enterprise, security is going to be at a distinct disadvantage, right?
(Note to self: Buy Boxing Gloves before the next battle)
But then, I actually had a performance tuning exercise and I was REQUIRED to set the audit_buf_sz to ZERO
so that, at most, only one audit record was ever at risk of loss. I was auditing for everything except CONTEXT. Even without auditing CONTEXT events, I was concerned (actually terrified) that this
would cause a HUGE problem.
Ok, at first, it appeared my fears may have been valid. The entire system looked
over tasked, overworked and just plain old unhappy (a technical term). But then, some tuning changes were made,
some code re-written, some OS parms tuned and before I knew it, I had forgotten all about the audit_buf_sz being
zero....oh....and our performance tuning exercise was so successful that management was "shocked" at what we
had accomplished.
So, what had I discovered? I'm still not quite sure about the audit_buf_sz, but in at least one environment,
during at least one tuning exercise, I can say that setting audit_buf_sz to zero did NOT cause enough performance degradation to be
noticeable.
I'd be very interested in hearing from you about your experiences with DB2 Auditing. If you'd like to have
a query that you can run to check the value of your audit_buf_sz (and some other DBM values), tune in for the
DB2Night Show # 5 on November 12 at 10:00 am CST. I'll be there with a sweet surprise and some SQL for you.
I WELCOME YOUR EMAILS TO: