RE: ORA-00600: internal error code, arguments: [4412] (ORA-02002: error while writing to audit trail)
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <Kenneth.R.Fowler@xxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Mon, 2 Jul 2007 17:59:13 -0400
_____
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
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
Other related posts:
