Clear those audit logs before it’s too late!

WebCenter Interaction Audit Logs are decent for tracking what’s going on in your portal, but they can grow really quickly.  So, you should make sure to configure the Audit Log to regularly purge rows from the database and write them to disk using the “Audit Manager” in the WCI portal administration page (under “Select Utility”):

audit-manager

(By the way, for that network path, remember to make sure there are no extraneous files in that directory.)

This isn’t just good practice, but it could save you some huge headaches down the line.  In particular, I’ve seen two “worst-case scenarios”:

  1. At one client with an Oracle database, there was a limit on how big the tablespace could grow for audit logs.  So as soon as this limit was hit, noone could visit the portal.  Because the portal was trying and failing to record the guest users’ “login” to the portal, it ended up throwing an exception and not allowing anyone in.
  2. The Audit Log Management job has some wildly inefficient code, which appears to load ALL rows into memory before writing them out to disk.  If the audit log in the DB grows to a certain threshold, the job to actually clear out those rows will fail with an OutOfMemory exception:

wci-audit-job1

wci-audit-job2

If you find yourself stuck in the predicament, where the audit log is too big to even clear it out through traditional means – with the Audit Log Management job – your Last Great Hope is to simply purge the DB through SQL:

delete from ptauditmsgs where auditmsgtime < '30-DEC-09'

So schedule your audit job archives now, and let’s hope you never have to resort to just dropping those records just to get users logging in and events archived again.

Tags: ,

2 Responses to “Clear those audit logs before it’s too late!”

  1. Joel Collins says:

    DON’T run that sql! I tried the ‘delete from ptauditmsgs’…advice a few years back. learned my lesson the hard way. that sql blocks all traffic to your portal, and that statement can easily take a few minutes to run.

    unless you really need your audit messages, just use
    truncate table ptauditmsgs

  2. Matt Chiste says:

    Great point Joel – for the issue that I wrote this article on, we were using Oracle, which worked really quickly (even though it does “freeze’ the portal during this 1 second time frame). But, if you’re OK with dropping ALL audit messages, TRUNC is a better way to go because it doesn’t save transaction history, which is why deleting millions of rows takes forever. See http://www.function1.com/2008/09/crazy-database-growth-check-your-ptjoblogs-table/ for another example (Job Logs) where this can be a challenge and TRUNC is better than DELETE: “if you run an amateur update like “delete * from ptjoblogs“, the update will take forever because all transactions will be logged. If you run “truncate table ptjoblogs“, on the other hand, you’re just dropping the table and don’t have to wait ridiculous amounts of time for the update to happen (not to mention the amount of database log space you’d be consuming).”

Leave a Reply