Re: Urgent - Question on Auditing

If the audit table fills up, you can still connect as SYS to deal with it. If the SYSTEM tablespace is full, you'll have trouble connecting whoever you try logging on as.

As for the references, chapter 21 of the Oracle 8 DBA Course Notes (Page 21, unless I'm very much mistaken), and off-hand, I think it's in Chapter 16 of the current, 8i, DBA Part 1 Course Notes.

The actual line reads "Because the AUD$ table grows and shrinks, it should be stored outside of the system tablespace".

Regards
HJR

--
=============================!!=============================
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:3B0003A8.E533CEBB_at_bms.com...


> "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?