Re: Urgent - Question on Auditing

"Dave Weeks" <dweeks_at_nospam.gnseurope.com> wrote in message news:9dof9a$h1s$1_at_reader-00.news.insnet.cw.net...
> Hi Howard,
>
> The powers that be wanted Oracle on an A1000 with bags of memory for their
> piss-poor application that will be doing 1 sort every blue moon.
 Therefore,
> our TEMP tablespace is not of the 'temporary' variety at all but just a
> dumping ground for storing DBA-temporary objects (like sys.aud$ and
> dba.random_experiments).
>
> Yes, you are correct that it's the norm to have a proper temporary
> tablespace for sorts (where else would Oracle do large sorts?)

Er, SYSTEM is a prime candidate if you forget to set up your Users properly!!

Sorts will happily swap down to any old tablespace (and the default is indeed SYSTEM), regardless of size. But it's not pretty when it happens!

> and sys.aud$
> should be moved to a new tablespace (e.g. audit_tab).
>
> Incidentally, the article I linked to says:
>
> "You cannot move SYS.AUD$ to another tablespace as a means of
> controlling the growth and size of the audit trail."
>

God knows what they mean. Perhaps they are trying to say, rather obscurely, that the fact that you've moved the table won't influence how much or how often audit records get written to it? Hence growth and size are detmined by your auditing options, not its location?? Statement of the bleedin' obvious if so, I would have thought.

If they mean "you can't set intitial, next or other storage parameters" for it, well, I confess I haven't tried. It remains a SYS table, wherever it's moved to, of course, so that might cause trouble. The standard advice is (in 8i) to issue the 'move table' command, which would mean that the storage parameters don't change, of course. For earlier version, it was to do a 'create table new_aud as select * from aud$ where 1=2' -and again, the existing storage parameters would simply have gone along for the ride without alteration.

But I've just tested moving the table into a locally managed tablespace with uniform extents of 50K -and the thing (naturally) picks up the new tablespace settings (not as if it had much choice in the matter, I agree). So to suggest (if that is what they are doing) that you can *never* alter the storage parameters is just simply wrong.

Regards
HJR
> Hmmm.....
>
> Dave Weeks.
>
>
> Howard J. Rogers <howardjr_at_www.com> wrote in message
> news:3afcdfa2_at_news.iprimus.com.au...
> >
> > "Dave Weeks" <dweeks_at_nospam.gnseurope.com> wrote in message
> > news:9dgcne$m5i$1_at_reader-00.news.insnet.cw.net...
> > > Hi there,
> > >
> > > Things about auditing I've done on our 8.1.5. (Solaris 2.7) setup:
> > >
> > > 1) Moved sys.aud$ out of the SYSTEM tablespace and into TEMP.
> >
> > And how, pray, did you manage to house a permanent table in a temporary
> > tablespace?? Nice to move the aud$ table (it's practically obligatory
 if
> > you've any sense, for exactly the reasons you go on to list), but I hope
 you
> > have a proper temporary tablespace somewhere for sorts etc? This one
> > definitely isn't, because otherwise the move would have failed.
> >
> > Regards
> > HJR
> >
> >
> >
> >
> > >This will
> > > prevent SYSTEM from being fragmented by audit records being
> > > inserted/deleted.
> > > 2) Or, set the auditing to write to the OS instead of the database
 (this
> > > superceedes #1)
> > >
> > > 3) Read

 http://w3.uqah.uquebec.ca/ORACLE/server.805/a58397/ch22.htm#1108
> > > (take an hour to read it all)
> > >
> > > Best regards,
> > > Dave Weeks.
> > >
> > >
> > > Balachandra Rao <bprao_at_worldnet.att.net> wrote in message
> > > news:BHBK6.15073$4f7.1182444_at_bgtnsc06-news.ops.worldnet.att.net...
> > > > Hi ,
> > > > We have oracle 8.1.6 running on NT. Our dba started the auditing on
> > > > (connections) but we found the system slowing down. He stopped
 auditing
 by
> > > > changing the parameter in init.ora file to false. Our query in
 sys.aud$
> > > > table shows no increase in records after changing the parameter. Is
 this
> > > > the only step to be taken to stop auditing.
> > > > If not what are the other steps required.
> > > >
> > > > Thanks in advance.
> > > > BPR
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Received on Mon May 14 2001 - 08:34:52 CDT