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

  • From: "David Barbour" <david.barbour1@xxxxxxxxx>
  • To: Kenneth.R.Fowler@xxxxxxxxxx
  • Date: Mon, 2 Jul 2007 18:10:13 -0400

Okay, it's a little hokey, but why don't you just create a procedure/package
to check the number of records in the table.  If it gets over something like
40,000, do something like "create table as select *"  or have an archive
table to which you write the records.  In any case, when the  create/copy
piece is done, you're going to have to check the last record written (since
you say your environment is pretty dynamic) and delete all the records in
sys.aud$ up to that point.

Schedule the procedure as a job (database or cron).  If you run a create
daily, you could schedule a drop of the oldest table at the same time, so
you'd alway have x days available.  If you have one big archive table, you
can schedule a delete from the archive in the same procedure so you always
keep x days avaialable.


On 7/2/07, Fowler, Kenneth R <Kenneth.R.Fowler@xxxxxxxxxx> wrote:


 Hi,

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…

Thu Jun 14 10:36:39 2007
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?

Thanks,
Ken.
*

*
*Database Services - Infrastructure, Platform and Systems Engineering*
*Worldwide Technology Engineering
Phone: (860) 686-1749*
------------------------------
LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential and may be
privileged. It is intended for the addressee(s) only. Access to this E-mail
by anyone else is unauthorized. If you are not an addressee, any disclosure
or copying of the contents of this E-mail or any action taken (or not taken)
in reliance on it is unauthorized and may be unlawful. If you are not an
addressee, please inform the sender immediately.

Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 07-2007