Re: RMAN Backups/Recoveries

"Ofer Razon" <orazon_at_dbnet.co.il> wrote in message news:74c5bf11.0312160028.4033b249_at_posting.google.com...
> Hi Howard.
> Thanks for the reply.
>
> I think you didn`t understand me correctly so I`ll ask it in another
> way :
>
> First - Is it possible to work with RMAN in the following way :
> - Make a full backup once
> - From now and on - make only incremental backups
> - On another server - Make a full restore once
> - From now and on (Every 2 days for example) - run all the incremental
> changes.
> I`ll neverf open the recovered database, so practicly it`ll always be
> in recovery mode.

The command you will issue will be 'restore database' or 'restore datafile X'. RMAN will therefore (probably) restore from the only full backup you say you'll have, and then have to apply every incremental backup you've taken since. Even if the end result was useful (see below), it's not exactly going to be very practical after quite a short time.

> What will I do with this always-recovered DB?

See, here's where the fun starts. A database cannot be "always recovered". The idea of continually *restoring* a database (ie, copying back from a backup) might actually be a goer... but you can't continually recover one (ie, apply redo to the restored datafiles).

> My storage allows my to define PITs, and then define a RW view (view =
> in it`s storage meaning) on this PIT so I can work on it without
> interfering the recovery process (on the view I can do the resetlogs
> and it`ll affect only this branch).

None of that made any sense to me, I'm afraid. A point-in-time recovery means you'll apply redo to restored datafiles. That means the database must then be opened with a resetlogs, and that's the end of any further recovery options for that database, unless you chuck it away at the end of it, and restore from the beginning for your next point-in-time recovery. I haven't a clue what a "RW view" is, and am none the wiser either about what a "view in its storage meaning' means either... do you mean a materialized view by any chance? And what 'doing a resetlogs on the view' means, I can't fathom either.

Whatever: you said earlier that "I'll never open the recovered database", so if that's true, you'll never be able to use anything inside that database, be it a view, a materialised view or anything else.

>
> Why do I need it?
> I`m looking for a way to keep an updated copy of my production copy so
> everytime I`ll need to do some tests, I`ll be able to define a PIT and
> a view and work on it.

I can only re-iterate, having understood you the first time round, that RMAN will not do what you require; that no restore-and-recovery mechanism Oracle supports will do what you require; excepting the standby database feature. And even there, once you open the database at a point in time, that's the end of the database for future recovery purposes. It has to be disposed of afterwards and re-created afresh for any further recovery processes.

The fundamental point is that a point in time recovery is a one-way, final process. Once you've done one, you can open the cloned database, extract the information you want, and then dispose of the database altogether. You could of course then do a complete restore and recovery to a different point in time with a second 'clone'... and after that, a third point in time recovery with a third clone and so on. RMAN will certainly make it easy to do the necessary restores and recoveries. But it will be a one-shot process every time. Once the thing is opened, no further recovery will be possible for that instantiation of the cloned database.

The above is pretty much the description of a tablespace point in time recovery, or TSPITR, and you might want to read up on that in the Oracle documentation to see whether it is what you are after. RMAN can certainly do them (though you'll need a catalog database), but it remains a one-shot process.

Regards
HJR

-- 
------------------------------------
Oracle insights at www.dizwell.com
------------------------------------ 








> "Howard J. Rogers" <hjr_at_dizwell.com> wrote in message

news:<3fde1068$0$18692$afc38c87_at_news.optusnet.com.au>...


> > "Ofer Razon" <orazon_at_012.net.il> wrote in message

> > news:brl15q$92s$1_at_news2.netvision.net.il...

> > > Hi All.

> > >

> > > Using Oracle 8.1.7, I am considering the use of RMAN in order to run a

> > > continous recovered DB, so I`ll do a full recovery once and then,

every X


> > > days I`ll run an incremental recovery for this DB.

> >

> >

> > Do you mean recoveries or backups? If you really mean recoveries, then

this


> > isn't going to work. Once you've recovered a database, that's it: Oracle

> > won't permit you to recover the database further. For a database to be

in


> > permanent recovery mode, it needs to be specially created as a standby

> > database (which means mounting it with a standby controlfile).

> >

> > > I know that the DB will never be "open". My actual plans are to use

PIT


> > > disks features and open a copy of the database everytime I`ll need it,

> > > without ruining the recovery process.

> >

> > Yikes. This is a highway to horrors. You can't do point in time recovery

and


> > not 'ruin the recovery process'. A point in time recovery means 'issue a

> > resetlogs', at which point your database is in a new incarnation, and

all


> > prior backups and archives taken from the source database will be

useless.


> > This just isn't going to work.

> >

> > >

> > > At first we considered using a Stand By DB, but then we`ve found that

> >  every

> > > time we`ll add/resize a datafile we`ll have to do it on the standby

too,


> >  so

> > > we dropped this idea.

> >

> > Bad move. This is the only technology that will do what you want (and

even


> > then, every time you activate the standby database, it ceases to be able

to


> > be further recovered, so repeated opening of it would mean a lot of

> > re-cloning work to do each time.

> >

> > >

> > > Will RMAN solve me this problem?

> >

> > No.

> >

> > > Do you think that it is possible to run in a "continous recovery" as I

> > > described?

> >

> > No.

> >

> > > BTW: I`m couting on the feature that every "incremental recovery" will

> > > update only the affected blocks in the DB and won`t create the full

> >  datafile

> > > from scratch.

> >

> > Irrelevant. First of all, when you perform a recovery with RMAN, you

have no


> > say over how RMAN will actually perform the recovery. It uses internal

> > algorithms to work out the best way of effecting a recovery, and that

could


> > mean -as far as it is concerned- the quickest thing might be to restore

the


> > full backup, and then apply all archives produced since then. There's no

> > guarantee that it will restore the full-apply the incrementals-apply

last


> > bit of archives.

> >

> > Second, recovery is a process with a goal in mind: get the database back

up


> > and running. Once it's achieved that, it stops. Forever (or until your

next


> > failure).

> >

> > What's your actual business problem that's led you to this suggestion?

> > Because if we saw that, we might be able to think of something rather

more


> > workable for you.

> >

> > Personally, I can't see this ever working until you upgrade to 9i

Release 2


> > and implement logical standby with Data Guard.

> >

> > Regards

> > HJR