RE: ORA-00600: internal error code, arguments: [4412] (ORA-02002: error while writing to audit trail)

From: Mark W. Farnham <mwf_at_rsiz.com>
Date: Mon, 2 Jul 2007 17:59:13 -0400
Message-ID: <015a01c7bcf4$3d4dcee0$1100a8c0@rsiz.com>

   

---

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Fowler, Kenneth R
<snip>

Subject: ORA-00600: internal error code, arguments: [4412] (ORA-02002: error while writing to audit trail)

<snip>This problem pertains to Oracle 10.2.0.3, Solaris 2.9 running on an
E15K domain. Many of our 10.2.0.3 databases see frequent errors while trying to write to audit.<snip>
Errors in file /app/oracle/admin/enip12/trace/udump/enip12_ora_247229.trc: ORA-00600: internal error code, arguments: [4412], [0x3C5FDB348], [0x3C5F9E2E8], [], [], [], [], []

ORA-02002: error while writing to audit trail
ORA-00604: error occurred at recursive SQL level 3
ORA-02002: error while writing to audit trail
ORA-00600: internal error code, arguments: [4412], [0x3C5FDB348],

[0x3C5F9E2E8], [], [], [], [], []

There is a bug report in metalink (5592308) with no solution but the following suggested workarounds.

1. Turn off auditing.
2. Keep sys.aud$ table below 50,000 records.

Neither of these "solutions" is any good for us due to legal requirements to have auditing turned on and the high level of activity on the database making it difficult if not impossible to keep sys.aud$ below 50,000 records. This is a production database and we have a TAR/SR on the issue that has been open since 31-MAY. Oracle wants us to supply scripts and data to them so that they can recreate the issue and even though we supplied an export taken when the condition occurred (at Oracle's request) they have not been successful in recreating the issue (no surprise to me). Needless to say we are less than happy with the situation which has been giving us problems for over a month.

So, has anyone seen the issue? Any solutions? Is there some event tracing that I could use that would shed some light on this?<snip>  

mwf: Haven't seen this particular one. I haven't seen any legislation that matches "sys.aud$" by name, though I suppose you might see something specifically dictating an audit method in a contract somewhere, but that aside you might consider whether some scheme to very quickly copy and delete rows from sys.aud$ will at least meet the 50,000 row challenge so even if that does not solve your problem the ball is back in Oracle's court. You might hash off some column in the sys.aud$ table and fan out the destinations to, say, ten targets and use the synonym game to rotate those on some schedule to make them row sources for your long term history or warehouse for audit records, quite possibly in a separate database. A trigger on commit on sys.aud$, perhaps. Fanning out would reduce any chance this is an insert split race condition. The ten destinations may well not need indexes at all, since they will be transient way stations to be rotated, copied complete while otherwise cold, and then presumably truncated. I'm very curious what your end result is, and quite disappointed that Oracle support left you holding the bag on something so serious as an internal bug writing AUDIT information with nary a workaround except a dysfunctional recipe for preventing the 600 error without even a nod toward achieving your clearly supported functional goal. If I know Larry, blowing someone off on such basic issue as database auditing will cause great annoyance. No tuxedo will fit this bug.  

Regards,  

mwf

--
http://www.freelists.org/webpage/oracle-l

Received on Mon Jul 02 2007 - 16:59:13 CDT