Re: Back to the future

Absolutely. Especialy if the problem occurs on a production database at say 3:30pm on a thursday, but doesn't get noticed until 12pm on a friday. You can absolutely gurantee that a recover to 3:30pm will piss off a large number of users just in time for the weekend. For this reason this course of action is only recommended for your favourite developers machine <g>.

More seriously we have been in the state where a point in time recovery was exactly the correct thing to do, however the management decision to OK this course of action took 6 hours, at which point of course I had 'changed my mind' leading to 'how can we rely on your advice if you change it from hour to hour'. ah well.

Point in time recovery is a powerful feature, but like most powerful features it is unlikely to be used very often.

--
Niall Litchfield
Oracle DBA
Audit Commission UK
"Nuno Souto" <nsouto_at_optushome.com.au.nospam> wrote in message
news:3b96375e.5101485_at_news...


> On Wed, 05 Sep 2001 22:24:14 +0800, Dino Hsu

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

>

>

> >On the other hand, the point-in-time approach does have the problem of

> >losing all transations happening after that 'point'.

>

> Bingo!  :-)

>

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

>

> That's one way of doing it, indeed.  One of the reasons too why even

> with archive log on, I still like to take exports daily.  Whenever the

> size of DB and window available lets me.

>

> Many times it's easier to just load an export into a dev or test

> database, find a way of patching up the problem without having to copy

> the lot and then apply the patch to the production data.  Depending on

> type of application, of course.

>

>

> Cheers

> Nuno Souto

> nsouto_at_optushome.com.au.nospam