Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Sarbaynes-Oxley and the Oracle DBA

Re: Sarbaynes-Oxley and the Oracle DBA

From: Mark D Powell <Mark.Powell_at_eds.com>
Date: 30 Aug 2004 07:14:10 -0700
Message-ID: <2687bb95.0408300614.49d321ac@posting.google.com>


"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message news:<41329c33$0$22855$afc38c87_at_news.optusnet.com.au>...
> Mladen Gogala wrote:
>
> > On Sun, 29 Aug 2004 11:12:11 -0700, Prem K Mehrotra wrote:
> >
> >> I sure admire your wit but not your understanding of logminer.
> >> Logminer can be used to audit databases and database auditing is part
> >> of security.
> >
> > Logminer serves to re-construct transactions. It is hardly suitable for
> > auditing. Logminer is used to re-construct information from redo-logs and
> > is unsuitable for auditing purposes, especially now when there is FGA.
> > Logminer should not be covered in a security book. It belongs to the DBA
> > books.
>
> Interested to know why you are of that opinion, since it's one I
> fundamentally disagree with. FGA is 9i specific (there's still a lot of 8i
> out there, after all). And it doesn't capture values, merely SQL
> statements. You need Flashback to get value-based auditing. And Flashback
> demands large undo segments (undo tablespaces) which have a performance
> impact of their own. FGA is also an 'optional extra', meaning you have to
> actively switch it on by creating policies... and that has a performance
> impact for the table concerned, too. And FGA (I assume we're talking
> Fine-Grained Auditing?) only works for select statements in 9i, and then
> only for select statements on tables for which statistics have been
> calculated (and in 9i, it's legitimate to be using the RBO, where no
> statistics are collected).
>
> But redo is generated regardless of your auditing needs. So suddenly
> deciding to use redo as an auditing mechanism incurs no overhead on the
> database which the database wasn't already suffering (querying from
> v$logminer_contents excepted, obviously). It captures times, usernames and
> sql statements. And it captures precisely the values that were modified by
> DML. It is version independent (to the extent that an 8.0 log can be
> inspected by Log Miner). It doesn't care what optimiser you are using. And
> it audits DML (though I accept it is severely lacking -ie, totally
> non-functional- on the select side of things).
>
> In short, it has a role to play in security management, and as such belongs
> just as much in security books as in DBA books (not that I was aware there
> was an inevitable dichotomy between the two). It is not the be-all and
> end-all. But it's not nothing, either.
>
> Regards
> HJR
I agree with HJR's position on the use of the archived redo logs via logminer as a valid auditing tool. It would be even better if the logminer function could be ran completely separate from the database in batch. The old IBM IMS database has a batch log reporting utility and you can reconstruct data segments with it if you are willing to do a little work. The archived redo logs are a rich potential source of data for many different purposes of which auditing is one. Most sites probably will not need to use the logs for this purpose, but some sites will need to use the logs for audit information.

IMHO -- Mark D Powell -- Received on Mon Aug 30 2004 - 09:14:10 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US