Re: Oracle Audit Trail Repository Advice

From: Mark Zehner <zehner_at_averstar.com>
Date: Tue, 19 Dec 2000 06:27:37 -0800
Message-ID: <3A3F7057.BD7D7F30_at_averstar.com>


Mike, et al,

But doesn't the database have to be shut down in order to change the init parameter to "none"? If so, in my case, the DBA doesn't have permission to shut down the database. Perhaps you're suggesting that the auditing options could be changed (deleted)? Is this approach just as effective as changing the init parameter? Thanks in advance.

Mark

"Michael J. Moore" wrote:

> Even if the audit goes to a system file, the DBA can turn auditing off at
> any time,
> so I think that they are just going to have to learn to trust the DBA.
>
> Mike
>
> "Mark Zehner" <zehner_at_averstar.com> wrote in message
> news:3A3E5746.2535E70_at_averstar.com...
> > I'm attempting to define requirements for Oracle database auditing and
> > do not appreciate the merits of using an OS file as the location for the
> > audit trail. Most of what I read in the literature seems to assume the
> > audit trail is stored in the SYS.AUD$ table. That is, the auditing
> > views created with the CATALOG.SQL scripts as well as Oracle Reports
> > seems to use this table. I can't find any references regarding what one
> > does if an O/S file is used instead. How is the O/S file interpreted
> > and with what?
> >
> > Also, there is some sentiment among my associates that the database
> > table approach should not be used because the DBA can delete it. My
> > counter is that the deletion event will in turn be stored. This is
> > countered with, but the details of previous activity are lost. At this
> > point I give up.
> >
> > Can anyone help me with 1) detailed advice as to the pros and cons
> > regarding the two approaches to the auditing repository, 2) is the
> > concern over the DBA deleting the SYS.AUD$ table real and 3) if O/S
> > auditing is used, how is the O/S interpreted
> >
> > Thanks in advance for your help, and please send responses to:
> >
> > zehner_at_averstar.com
> >
> >
> >
Received on Tue Dec 19 2000 - 15:27:37 CET

Original text of this message