Re: "Write once-Read many" table ?

From: DA Morgan <>
Date: Wed, 05 Mar 2008 04:59:54 -0800
Message-ID: <>

joel garry wrote:
> On Mar 4, 11:36 am, Frank van Bortel <>
> wrote:

>> wrote:
>>> On Feb 28, 2:46 pm, Mladen Gogala <> wrote:
>>>> On Thu, 28 Feb 2008 03:17:19 -0800, jm.scheiwiler wrote:
>>>>>> You have to trust your DBA. That's the bottom line.
>>>>>> --
>>>>> 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 Gogala
>>> 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 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
> --
> is bogus.

You are correct on all points: Especially about the remote secure worm: Preferably one at a location not under your control such as in your auditor's offices/data center.

Audit Vault isn't foolproof. But it would take a remarkably clever fool to beat it given it can simultaneously collect the data from AUD$, FGA, and REDO.

Daniel A. Morgan
Oracle Ace Director & Instructor
University of Washington (replace x with u to respond)
Puget Sound Oracle Users Group
Received on Wed Mar 05 2008 - 06:59:54 CST

Original text of this message