It was actually in Chapter 18 of the 8i notes, page 26
HJR
--
=============================!!=============================
The views expressed are my own only, and definitely NOT those of Oracle
Corporation
=============================!!=============================
"Howard J. Rogers" <howardjr_at_www.com> wrote in message
news:3b00f378_at_news.iprimus.com.au...
> 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?
>
>
Received on Tue May 15 2001 - 05:34:53 CDT
