Re: "Write once-Read many" table ?
Date: Wed, 05 Mar 2008 17:05:50 +0100
joel garry wrote:
> On Mar 4, 11:36 am, Frank van Bortel <frank.van.bor..._at_gmail.com>
>> 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 pre-
> RO backups? And what about all these newfangled flashback and replay
> 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.
Apart from the fact this (or a similar answer) was given in
another ng (so much for cross-posting), including the
Metalink note number, of course everybody is correct in
stating that it is impossible.
But it sure can be made hard, and traceable.
To the OP: ask your management how they can guarantee anything to never change - and you'll find a way to change it nevertheless. I wish you wisdom.
-- Regards, Frank van Bortel Top-posting in UseNet newsgroups is one way to shut me upReceived on Wed Mar 05 2008 - 10:05:50 CST