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

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_at_pfizer.com> 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.
>

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