Re: Urgent - Question on Auditing

"Howard J. Rogers" wrote:
>
> Well, my thought is that if you think the i/o is going to be minimal, you've
> got to be kidding -or you have a database with very little select and update
> activity.

The I/O to SYS.AUD$ is typically inserts and updates, with infrequent selects and deletes. With session auditing, and a few 'dba things' audited, and no object auditing, this might average to 5 I/O's per minute, even on a busy system. Anything greater than that, then the application probably needs tuning because it's doing too many login/logouts. I'd call 5/minute minimal, but I realize that it's subjective. Granted that if object auditing is used, it generates many more audit records, but I've never found continuous object auditing too useful.

> And the one tablespace you don't want clogged down with vast
> quantities of extraneous i/o is, naturally, SYSTEM. I recall a database
> whose aud$ table (though it had been moved) used to generate around 80M of
> inserts a day (I don't say the audit options were set very sensibly -just
> that that quantity of information is not out of the question on even a
> moderately busy database).

Ok, that's not minimal! But for 80M/day, I'd guess that too many options were enabled, and that the application needs some attention.

> The audit records weren't cleared very
> regularly, and that tablespace eventually ran out of room. I wouldn't vouch
> for the openability of your entire database if it was SYSTEM itself that
> ever ran out of room.

The availability of a database with auditing enabled is at risk whenever sys.aud$ can't extend, regardless of where it may have been moved to.

> They didn't put screeds of information in the doco and the course notes
> about the critical need for moving that table for no reason.

To what doco and course notes are you referring? The oracle 8i administrator explicity says "You cannot move SYS.AUD$ to another tablespace as a means of controlling the growth and size of the audit trail." Metalink clearly states that moving this table is unsuported. I've never seen anything saying that moving aud$ out of system is a 'critical need', but many folks do it anyway, hence my questions.

> --
> =============================!!=============================
> The views expressed are my own only, and definitely NOT those of Oracle
> Corporation
> =============================!!=============================
>
> "Joe Kazimierczyk" <joseph.kazimierczyk_at_bms.com> wrote in message
> news:3AFFC9BC.B7633952_at_bms.com...
> > > ... Nice to move the aud$ table [out of SYSTEM]
> > > (it's practically obligatory if
> > > you've any sense...
> >
> > This seems to be a common line of thought, but I'm not sure
> > I agree. If you set the storage parameters for sys.aud$ and
> > it's 1 index properly, there is absolutely no problem with
> > leaving it in SYSTEM, is there? Sure it's probably one of
> > the more active tables in system regarding inserts, but the
> > i/o resulting from that is still pretty minimal. Any other
> > thoughts?
Received on Mon May 14 2001 - 11:11:20 CDT