Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: rman incremental merge

RE: rman incremental merge

From: Mercadante, Thomas F \(LABOR\) <>
Date: Tue, 5 Dec 2006 14:38:47 -0500
Message-ID: <ABB9D76E187C5146AB5683F5A07336FFE0891A@EXCNYSM0A1AJ.nysemail.nyenet>

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.

This transmission may contain confidential, proprietary, or privileged information which is intended solely for use by the individual or entity to whom it is addressed. If you are not the intended recipient, you are hereby notified that any disclosure, dissemination, copying or distribution of this transmission or its attachments is strictly prohibited. In addition, unauthorized access to this transmission may violate federal or State law, including the Electronic Communications Privacy Act of 1985. If you have received this transmission in error, please notify the sender immediately by return e-mail and delete the transmission and its attachments.

-----Original Message-----

[] On Behalf Of Don Seiler Sent: Tuesday, December 05, 2006 2:23 PM To: Jared Still
Cc:; Subject: Re: rman incremental merge 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 <> wrote:
> On 12/4/06, Don Seiler <> wrote:
> > The usage that I've seen and used is to start with a level 0, and
> > 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
> > image to start with for recovery.
> The recovery of course depends on whether the incremental was a
> differential or cumalitive incremental. Cumalitives give faster
> performance than differentials, but cause longer restoration times.
> 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.
> > 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

Received on Tue Dec 05 2006 - 13:38:47 CST

Original text of this message