Re: "Write once-Read many" table ?

From: Frank van Bortel <frank.van.bortel_at_gmail.com>
Date: Wed, 05 Mar 2008 17:05:50 +0100
Message-ID: <30d73$47cec4df$524b5c40$25314@cache2.tilbu1.nb.home.nl>


joel garry wrote:
> On Mar 4, 11:36 am, Frank van Bortel <frank.van.bor..._at_gmail.com>
> wrote:

>> 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
> 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

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 up
Received on Wed Mar 05 2008 - 10:05:50 CST

Original text of this message