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: Back to the future

Re: Back to the future

From: TurkBear <noone_at_nowhere.com>
Date: Wed, 05 Sep 2001 09:38:35 -0500
Message-ID: <71ecptsf61ism1p21ijh32c3dibpgmtt50@4ax.com>

You could, if you really need to enable users to delete stuff, have a set of triggers for each table that , prior to an insert,update or delete , copies the current state of that data to another table(s) with a transaction timestamp and any other audit-type data you may need like PID or User id added so that you could use that table(s) for recovery of incorrectly changed or removed data..

Dino Hsu <dino1.nospam_at_ms1.hinet.net> wrote:

>On Wed, 05 Sep 2001 14:04:24 GMT, nsouto_at_optushome.com.au.nospam (Nuno
>Souto) wrote:
>
>>On Wed, 05 Sep 2001 20:44:25 +0800, Dino Hsu
>><dino1.nospam_at_ms1.hinet.net> wrote:
>>
>>>I am bothered by this thought, anyone enlightens me? Thanks in
>>>advance.
>>>
>>
>>You can use log miner to find out when things happened. But what is
>>relevant here is:
>>
>>The whole purpose of recovery with redo logs is to let you get things
>>back after *storage hardware* failure. Not software or user error.
>>
>>If you want to get just one object back, you're going the wrong way
>>about it by relying on redo log based, point in time recovery. It was
>>not designed to do that.
>>
>>Let's look at your case: what business does a user have in "dropping
>>a table" or even "deleting its entire contents", in a production
>>environment? What, we let users have that kind of access now? See
>>what I mean?
>>
>>
>>Cheers
>>Nuno Souto
>>nsouto_at_optushome.com.au.nospam
>
>Dear Nuno,
>
>I partly agree with you, but there are occasions when this is needed.
>The 'dropping a table' is just an example, the user can probably give
>wrong parameters in running a batch job or mistakenly delete important
>purchase orders and cannot find any paper copies, which requires us to
>get to the point in time to savage the data.
>
>On the other hand, the point-in-time approach does have the problem of
>losing all transations happening after that 'point'. Therefore, I
>wonder whether we have to rebuild the point-in-time database somewhere
>else, and copy the necessary pieces back to the production database.
>
>Dino

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World!  Check out our new Unlimited Server. No Download or Time Limits! -----== Over 80,000 Newsgroups - 19 Different Servers! ==----- Received on Wed Sep 05 2001 - 09:38:35 CDT

Original text of this message

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