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: Dino Hsu <dino1.nospam_at_ms1.hinet.net>
Date: Wed, 05 Sep 2001 22:24:14 +0800
Message-ID: <aoccptgqg8a83t9cjilceav81rlnohmigr@4ax.com>


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 Received on Wed Sep 05 2001 - 09:24:14 CDT

Original text of this message

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