Re: "Write once-Read many" table ?

On Mar 4, 11:36 am, Frank van Bortel <frank.van.bor..._at_gmail.com> wrote:
> jm.scheiwi..._at_gmail.com wrote:
> > On Feb 28, 2:46 pm, Mladen Gogala <mgog..._at_yahoo.com> wrote:
> >> On Thu, 28 Feb 2008 03:17:19 -0800, jm.scheiwiler wrote:
> >>>> You have to trust your DBA. That's the bottom line.
> >>>> --http://mgogala.freehostia.com
> >>> The thing is, I am the dba.
> >>> I trust myself but that's not enough
> >> So, who else, besides you, can do grants & revokes?
>
> >> --
> >> Mladen Gogalahttp://mgogala.freehostia.com
>
> > In fact, business management want to be sure that a line inserted will
> > never be changed, by anyone.
> > They would like a feature to ensure that.
> > Something that would be guaranteed by construction in the database,
> > guaranteed by oracle ...
>
> > I ask the question on their behalf.
>
> > Thanks
>
> Create a tablespace (e.g. "jms") with an associated (new!) datafile.
> Create your table (e.g. "ro_table") in tablespace "jms".
> Put tablespace "jms" in read-only mode.
> Burn a copy of the datafile onto a good-quality
> read-only media (e.g. WORM).
> Mount the read-only (WORM?) device
> Tell Oracle the datafile has been moved.
> Drop the original datafile.
>
> Unless you reverse the process, and mount a new copy,
> changes are impossible. Costs a whole lot less than
> Data Vault :)
>

But isn't that the problem: isn't it trivial to reverse the process, given DBA SYS and root SA access and another machine. You can wind up with two cd's - which one is lying? For that matter, how do you know the original data file is really gone? Aren't there going to be preRO  backups? And what about all these newfangled flashback and replay features?

I think Niall and Dan are both right, the important points are auditing and legal proof. Somewhere a long time ago I saw a presentation that stated you have to have a remote secure worm to really get trustable auditing.

jg

--
@home.com is bogus.
http://books.google.com/books?id=wuNImmQufGsC