增量追加备份

Oracle-suggested backup strategy使用的就是这种方式

　　增量追加备份工作原理：首先创建一个文件镜像拷贝，然后定期把从上次镜像拷贝最大SCN以来变化的数据块追加到镜像拷贝文件中。增量追加备份可以达到快速恢复的目的，如果是每天进行增量追加的话，在进行恢复的时候，我们最多应用一天的REDO数据就可以完成恢复。

　　创建增量追加备份，格式如下：

BACKUP... FOR RECOVER OF COPY WITH TAG

　　一个基础的增量追加备份示例：简称basic脚本：

RUN ...{ RECOVER COPY OF DATABASE WITH TAG 'incr_update'; BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE; }

　　为了理解上述脚本，我们先看一下如果没有数据文件拷贝和增量备份运行这两个脚本的情况。

　　1、如果没有LEVEL0备份或者备份文件拷贝，执行BACKUP INCREMENTAL LEVEL 1…… FOR RECOVER OF COPY WITH TAG……不能产生LEVEL1增量备份文件，但是RMAN会按照指定的tag在DATAFILE对应的目录下创建一分镜像文件拷贝。

　　2、如果没有LEVEL0备份或者备份文件拷贝，执行RECOVER COPY OF DATABASE WITH TAG……则生成一些信息但是不产生错误。

　　我们看一下整个basic脚本的执行情况：

　　第一次运行该脚本没有数据文件拷贝和增量备份所以执行RECOVER COPY OF DATABASE WITH TAG 'incr_update'没有任何结果；执行BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE将产生数据文件的镜像文件拷贝。

　　第二次运行该脚本，由于第一次运行的时候BACKUP INCREMENTAL LEVEL 1…… FOR RECOVER OF COPY WITH TAG……命令产生一个镜像文件拷贝，但是没有LEVEL1的增量备份，所以执行RECOVER COPY OF DATABASE WITH TAG 'incr_update'还是没有任何结果；执行BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE将产生LEVEL1增量备份。

　　第三次运行该脚本，执行RECOVER COPY OF DATABASE WITH TAG 'incr_update'命令将把第二次执行该脚本产生的LEVEL1增量备份追加到镜像文件拷贝，同时又产生一个新的LEVEL1增量备份文件。

　　以后再执行该脚本都是把上次产生的LEVEL1的增量备份追加到镜像文件拷贝，然后再产生一个新的LEVEL1的增量备份文件。

　　如果需要恢复，我们首先恢复镜像文件拷贝和最后一次LEVEL1增量备份，最后应用REDO.

4.4.3 Incrementally Updated Backups: Rolling Forward Image Copy Backups

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.

4.4.3.1 Incrementally Updated Backups: A Basic Example

To create incremental backups for use in an incrementally updated backups strategy, you must use the BACKUP... FOR RECOVER OF COPY WITH TAG form. of the BACKUPcommand. How the command works is best understood in the context of an example script. that would implement the strategy.

This script, run on a regular basis, is all that is required to implement a strategy based on incrementally updated backups:

RUN {
   RECOVER COPY OF DATABASE WITH TAG 'incr_update';
   BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update'
       DATABASE;
   }

The syntax used in the script. does not, however, make it clear how the strategy works. To understand the script. and the strategy, it is necessary to understand the effects of these two commands when no datafile copies or incremental backups exist.

• The BACKUP INCREMENTAL LEVEL 1... FOR RECOVER OF COPY WITH TAG... command does not actually always create a level 1 incremental backup. If there is no level 0 image copy backup of an particular datafile, then executing this command creates an image copy backup of the datafile on disk with the specified tag instead of creating the level 1 backup.

  Note:

  Even when the BACKUP INCREMENTAL LEVEL 1 ... FOR RECOVER OF COPY command is used with DEVICE TYPE SBT to create a backup on tape, the first time it is used it creates the image copy on disk, and does not write any backup on tape. Subsequent incremental level 1 backups can be created on tape once the image copy is on disk.

  Thus, the first time the script. runs, it creates the image copy of the datafile needed to begin the cycle of incremental updates. In the second run and all subsequent runs, it produces level 1 incremental backups of the datafile.

• The RECOVER COPY OF DATABASE WITH TAG... command causes RMAN to apply any available incremental level 1 backups to a set of datafile copies with the specified tag.

  If there is no incremental backup or no datafile copy, the command generates a message but does not generate an error.

  The first time the script. runs, this command has no effect, because there is neither a datafile copy nor a level 1 incremental backup.

  The second time the script. runs, there is a datafile copy (created by the first BACKUP command), but no incremental level 1 backup, so again, the command has no effect.

  On the third run and all subsequent runs, there is a datafile copy and a level 1 incremental from the previous run, so the level 1 incremental is applied to the datafile copy, bringing the datafile copy up to the checkpoint SCN of the level 1 incremental.

Note also the following details about how this example works:

• Each time a datafile is added to the database, an image copy of the new datafile is created the next time the script. runs. The time after that, the first level 1 incremental for that datafile is created, and on all subsequent runs the new datafile is processed like any other datafile.

• Tags must be used to identify the incremental level 0 datafile copies created for use in this strategy, so that they do not interfere with other backup strategies you implement. If you have multiple incremental backup strategies in effect, RMAN cannot unambiguously create incremental level 1 backups unless you tag level 0 backups.

  The incremental level 1 backups to apply to those image copies are selected based upon the checkpoint SCNs of the image copy datafiles and the available incremental level 1 backups. (The tag used on the image copy being recovered is not a factor in the selection of the incremental level backups.)

In practice, you would schedule the example script. to run once each day, possibly at midnight. On a typical night (that is, after the first two nights), when the script. completed the following files would be available for a point-in-time recovery:

• An image copy of the database, as of the checkpoint SCN of the preceding run of the script, 24 hours earlier

• An incremental backup for the changes since the checkpoint SCN of preceding run

• Archived redo logs including all changes between the checkpoint SCN of the image copy and the current time

If, at some point during the following 24 hours, you need to restore and recover your database from this backup, for either complete or point-in-time recovery, you can restore the datafiles from the incrementally updated datafile copies, and apply changes from the most recent incremental level 1 and the redo logs to reach the desired SCN. At most, you will have 24 hours of redo to apply, which limits how long point-in-time recovery will take.

See Also:

Oracle Database 2 Day DBA to see how this technique is used in the Oracle-suggested backup strategy in Enterprise Manager.

4.4.3.2 Incrementally Updated Backups: A One Week Example

The basic example can be extended to provide fast recoverability to a window greater than 24 hours. Alter the RECOVER COPY... WITH TAG to perform. incomplete recovery of the datafile copies to the point in time in the past where you want your window of recoverability to begin. This example shows how to maintain a seven day window:

RUN {
   RECOVER COPY OF DATABASE WITH TAG 'incr_update' 
       UNTIL TIME 'SYSDATE - 7';
   BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update'
       DATABASE;
   }

The effect of the script. is as follows:

• On the first night the RECOVER COPY... UNTIL TIME statement has no effect, and the BACKUP INCREMENTAL... FOR RECOVER OF COPY statement creates the incremental level 0 copy.

• On the second through seventh nights, the RECOVER COPY... UNTIL TIME statement has no effect because TIME 'SYSDATE - 7' is still a time in the future. The BACKUP INCREMENTAL... FOR RECOVER OF COPY statement creates differetial incremental level 1 backups containing the block changes for the previous day.

• On the eighth and all subsequent nights night, the RECOVER COPY... UNTIL TIME statement applies the level 1 incremental from seven days ago to the copy of the database. The BACKUP INCREMENTAL... FOR RECOVER OF COPY statement creates an incremental backup containing the changes for the previous day.

As with the basic example, you have fast recoverability to any point in time between the SCN of the datafile copies and the present, using block changes from the incremental backups and individual changes from the redo logs. Because you have the daily level 1 incrementals, you still never need to apply more than one day of redo.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15747463/viewspace-763770/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/15747463/viewspace-763770/