Re: RMAN Backups/Recoveries

Hi.

Let`s leave for the moment the issue of the PIT and the views. These features are given by the Storage solution I use (SVM of StoreAge).

What I must understand is wheather the idea of taking incr. backups every day from my source DB and then make an incr. recovery to the target DB will work.
I didn`t understand yet wheather it will work or not. I mean that on my target DB I`ll recover once a full recovery, and afterwards I`ll run an incr. recovery everyday so when I`ll want to open the DB it`ll contain the most lately version and data of my source DB.

Thanks,
Ofer.

"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message news:3fdeefd3$0$18389$afc38c87_at_news.optusnet.com.au...
>
> "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
>
>
Received on Tue Dec 16 2003 - 16:56:06 CST