| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: rman incremental merge
This sounds great. So I turned this on for my one test 10.2 database.
Some process comes along and gzips the backup file. So the next Rman
backup cannot update the file with the next increment. I twice went
back and unzipped the file. A new backup ran fine. But the files got
gzipped again.
I turned the damn thing off until I have more time to read about it. Obviously I missed something, and this is a test database.
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Don Seiler
Sent: Tuesday, December 05, 2006 2:23 PM
To: Jared Still
Cc: Randy.Steiner_at_nyct.com; oracle-l_at_freelists.org
Subject: Re: rman incremental merge
http://download-east.oracle.com/docs/cd/B19306_01/backup.102/b14192/bkup 004.htm#BRBSC186
The text of which follows. The term "image copy" echoes throughout:
Oracle's Incrementally Updated Backups feature lets you avoid the overhead of taking full image copy backups of datafiles, while providing the same recovery advantages as image copy backups.
At the beginning of a backup strategy, RMAN creates an image copy backup of the datafile. Then, at regular intervals, such as daily, level 1 incremental backups are taken, and applied to the image copy backup, rolling it forward to the point in time when the level 1 incremental was created.
During restore and recovery of the database, RMAN can restore from this incrementally updated copy and then apply changes from the redo log, with the same results as restoring the database from a full backup taken at the SCN of the most recently applied incremental level 1 backup.
A backup strategy based on incrementally updated backups can help minimize time required for media recovery of your database. For example, if you run scripts to implement this strategy daily, then at recovery time, you never have more than one day of redo to apply.
On 12/5/06, Jared Still <jkstill_at_gmail.com> wrote:
>
> On 12/4/06, Don Seiler <don_at_seiler.us> wrote:
> > The usage that I've seen and used is to start with a level 0, and
from
> > there on out you'd only take level 1 incrementals. Then, based on
> > your recovery window, you could roll your base backup image forward,
> > for example to 7 days ago, if that is your window. It saves you the
> > time of not having to do another level 0, but having a recent level
0
> > image to start with for recovery.
>
> The recovery of course depends on whether the incremental was a
> differential or cumalitive incremental. Cumalitives give faster
backup
> performance than differentials, but cause longer restoration times.
This
> is assuming that there is > 1 incremental level 1+ between level 0.
>
> > The reason I stopped using it is that you HAVE to do a backup COPY.
I
> > didn't have the disk to hold an actual copy, and needed to have
> > compression.
> >
> >
>
> Somehow I have missed that part. I have backed up and restored
> databases from incremental 0 and 1, but have not had to do any
> backup COPY.
>
> Can you point to a relevant doc?
>
> --
>
> Jared Still
> Certifiable Oracle DBA and Part Time Perl Evangelist
>
>
-- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Tue Dec 05 2006 - 13:38:47 CST
 |
 |