RMAN incremental backups back up
only datafile blocks that have changed since a specified previous backup. You
can make incremental backups of databases, individual tablespaces or datafiles.
The goal of an incremental backup is
to back up only those data blocks that have changed since a previous backup.
The primary reasons for making
incremental backups parts of your strategy are:
- For use in a strategy based on incrementally updated
backups, where these incremental backups are used to periodically roll
forward an image copy of the database
- To reduce the amount of time needed for daily backups
- To save network bandwidth when backing up over a
network
- To get adequate backup performance when the aggregate
tape bandwidth available for tape write I/Os is much less than the
aggregate disk bandwidth for disk read I/Os
- To be able to recover changes to objects created with
the NOLOGGING option. For example, direct load inserts do not create
redo log entries and their changes cannot be reproduced with media
recovery. They do, however, change data blocks and so are captured by
incremental backups.
- To reduce backup sizes for NOARCHIVELOG databases. Instead of making a whole database backup
every time, you can make incremental backups.
As with
full backups, if you are in ARCHIVELOG mode, you can make incremental backups if the database is
open; if the database is in NOARCHIVELOG mode, then you can only make incremental backups after a
consistent shutdown.
See Also:
One effective strategy is to make
incremental backups to disk, and then back up the resulting backup sets to a
media manager with BACKUP AS BACKUPSET. The incremental backups are generally smaller than full
backups, which limits the space required to store them until they are moved to
tape. Then, when the incremental backups on disk are backed up to tape, it is
more likely that tape streaming can be sustained because all blocks of the
incremental backup are copied to tape. There is no possibility of delay due to
time required for RMAN to locate changed blocks in the datafiles.
Incremental Backup Algorithm
Each data block in a datafile
contains a system change number (SCN), which is the SCN at which the most
recent change was made to the block. During an incremental backup, RMAN reads
the SCN of each data block in the input file and compares it to the checkpoint
SCN of the parent incremental backup. If the SCN in the input data block is
greater than or equal to the checkpoint SCN of the parent, then RMAN copies the
block.
Note that if you enable the block
change tracking feature, RMAN can refer to the change tracking file to identify
changed blocks in datafiles without scanning the full contents of the datafile.
Once enabled, block change tracking does not alter how you take or use
incremental backups, other than offering increased performance. See "Improving Incremental Backup Performance: Change
Tracking" for more details about enabling block change tracking.
Level 0 and Level 1 Incremental Backups
Incremental backups can be either
level 0 or level 1. A level 0
incremental backup, which is the base for subsequent incremental backups,
copies all blocks containing data, backing the datafile up into a backup set
just as a full backup would. The only difference between a level 0 incremental
backup and a full backup is that a full backup is never included in an
incremental strategy.
A level 1 incremental backup can be
either of the following types:
- A differential backup, which backs up all blocks
changed after the most recent incremental backup at level 1 or 0
- A cumulative backup, which backs up all blocks changed
after the most recent incremental backup at level 0
Incremental backups are differential
by default.
Note:
Cumulative backups are preferable to
differential backups when recovery time is more important than disk space,
because during recovery each differential backup must be applied in succession.
Use cumulative incremental backups instead of differential, if enough disk
space is available to store cumulative incremental backups.
The size of the backup file depends
solely upon the number of blocks modified and the incremental backup level.
Differential Incremental Backups
In
a differential level 1 backup, RMAN backs up all blocks that have changed since
the most recent cumulative or differental incremental backup, whether at level
1 or level 0. RMAN determines which level 1 backup occurred most recently and
backs up all blocks modified after that backup. If no level 1 is available,
RMAN copies all blocks changed since the level 0 backup.
The following command performs a
level 1 differential incremental backup of the database:
RMAN>
BACKUP INCREMENTAL LEVEL 1 DATABASE;
If no level 0 backup is available, then the behavior depends
upon the compatibility mode setting. If compatibility is >=10.0.0, RMAN
copies all blocks changed since the file was created, and stores the results as
a level 1 backup. In other words, the SCN at the time the incremental backup is
taken is the file creation SCN. If compatibility <10.0.0, RMAN generates a
level 0 backup of the file contents at the time of the backup, to be consistent
with the behavior in previous releases.
Figure 4-1 Differential Incremental Backups (Default)
In the example shown in Figure 4-1, the following occurs:
An
incremental level 0 backup backs up all blocks that have ever been in use in
this database.
On each
day from Monday through Saturday, a differential incremental level 1 backup
backs up all blocks that have changed since the most recent incremental backup
at level 1 or 0. So, the Monday backup copies blocks changed since Sunday level
0 backup, the Tuesday backup copies blocks changed since the Monday level 1
backup, and so forth.
- The cycle is repeated for the next week.
Cumulative Incremental Backups
In a cumulative level 1 backup, RMAN
backs up all the blocks used since the most recent level 0 incremental backup.
Cumulative incremental backups reduce the work needed for a restore by ensuring
that you only need one incremental backup from any particular level. Cumulative
backups require more space and time than differential backups, however, because
they duplicate the work done by previous backups at the same level.
The following command performs a
cumulative level 1 incremental backup of the database:
BACKUP
INCREMENTAL LEVEL 1 CUMULATIVE DATABASE; # blocks changed since level 0
Figure 4-2 Cumulative Incremental Backups
In the example shown in Figure 4-2, the following occurs:
An
incremental level 0 backup backs up all blocks that have ever been in use in
this database.
A
cumulative incremental level 1 backup copy all blocks changed since the most
recent level 0 backup. Because the most recent level 0 backup was created on
Sunday, the level 1 backup on each day Monday through Saturday backs up all
blocks changed since the Sunday backup.
- The cycle is repeated for the next week.
Basic Incremental Backup Strategy
Choose a backup scheme according to
an acceptable MTTR (mean time to recover). For example, you can implement a
three-level backup scheme so that a full or level 0 backup is taken monthly, a
cumulative level 1 is taken weekly, and a differential level 1 is taken daily.
In this scheme, you never have to apply more than a day's worth of redo for
complete recovery.
When deciding how often to take full
or level 0 backups, a good rule of thumb is to take a new level 0 whenever 50%
or more of the data has changed. If the rate of change to your database is
predictable, then you can observe the size of your incremental backups to
determine when a new level 0 is appropriate. The following query displays the
number of blocks written to a backup set for each datafile with at least 50% of
its blocks backed up:
SELECT
FILE#, INCREMENTAL_LEVEL, COMPLETION_TIME, BLOCKS, DATAFILE_BLOCKS
FROM V$BACKUP_DATAFILE
WHERE INCREMENTAL_LEVEL > 0
AND BLOCKS / DATAFILE_BLOCKS > .5
ORDER BY COMPLETION_TIME;
Compare the number of blocks in
differential or cumulative backups to a base level 0 backup. For example, if
you only create level 1 cumulative backups, then when the most recent level 1
backup is about half of the size of the base level 0 backup, take a new level
0.
Making Incremental Backups: BACKUP INCREMENTAL
After starting RMAN, run the BACKUP
INCREMENTAL command at the RMAN prompt. This example makes a level 0
incremental backup of the database:
BACKUP
INCREMENTAL LEVEL 0 DATABASE;
This example makes a differential
level 1 backup of the SYSTEM tablespace and datafile tools01.dbf. It will
only back up those data blocks changed since the most recent level 1 or level 0
backup:
BACKUP
INCREMENTAL LEVEL 1
TABLESPACE SYSTEM
DATAFILE 'ora_home/oradata/trgt/tools01.dbf';
This example makes a cumulative
level 1 backup of the tablespace users, backing up all blocks changed
since the most recent level 0 backup.
BACKUP
INCREMENTAL LEVEL = 1 CUMULATIVE
TABLESPACE users;
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.
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 BACKUP command. 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:
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.
Improving Incremental Backup
Performance: Change Tracking
RMAN's change tracking feature for
incremental backups improves incremental backup performance by recording
changed blocks in each datafile in a change tracking file. If change tracking
is enabled, RMAN uses the change tracking file to identify changed blocks for
incremental backup, thus avoiding the need to scan every block in the datafile.
After enabling change tracking, the
first level 0 incremental backup still has to scan the entire datafile, as the
change tracking file does not yet reflect the status of the blocks. Subsequent
incremental backup that use this level 0 as parent will take advantage of the
change tracking file.
Using change tracking in no way
changes the commands used to perform incremental backups, and the change
tracking files themselves generally require little maintenance after initial
configuration.
Change tracking is disabled by
default, because it does introduce some minimal performance overhead on your
database during normal operations. However, the benefits of avoiding full
datafile scans during backup are considerable, especially if only a small
percentage of data blocks are changed between backups. If your backup strategy
involves incremental backups, then you should enable change tracking.
One change tracking file is created
for the whole database. By default, the change tracking file is created as an
Oracle managed file in DB_CREATE_FILE_DEST. You can also specify the name of the block change tracking
file, placing it in any location you choose.
Note:
In a Real Applications Clusters
(RAC) environment, the change tracking file must be located on shared storage
accessible from all nodes in the cluster.
Oracle saves enough change-tracking
information to enable incremental backups to be taken using any of the 8 most
recent incremental backups as its parent.
Although RMAN does not support
backup and recovery of the change-tracking file itself, if the whole database
or a subset needs to be restored and recovered, then recovery has no
user-visible effect on change tracking. After the restore and recovery, the
change tracking file is cleared, and starts recording block changes again. The
next incremental backup after any recovery is able to use change-tracking data.
Enabling and Disabling Change Tracking
You can enable or disable change tracking when the database
is either open or mounted. To alter the change tracking setting, you must use
SQL*Plus to connect to the target database with administrator privileges.
To store the change tracking file in
the database area, set DB_CREATE_FILE_DEST in the target database. Then issue the following SQL
statement to enable change tracking:
SQL>
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;
You can also create the change
tracking file in a location you choose yourself, using the following SQL
statement:
SQL>
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
USING FILE '/mydir/rman_change_track.f'
REUSE;
The REUSE option tells Oracle to overwrite
any existing file with the specified name.
To disable change tracking, use this
SQL statement:
SQL>
ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
If the change tracking file was
stored in the database area, then it is deleted when you disable change
tracking.
Checking Whether Change Tracking is Enabled
From SQL*Plus, you can query V$BLOCK_CHANGE_TRACKING.STATUS to determine whether change tracking is enabled, and if it
is, query V$BLOCK_CHANGE_TRACKING.FILENAME to display the filename.
Moving the Change Tracking File
If
you need to move the change tracking file, the ALTER DATABASE RENAME
FILE command updates the control file to refer to the new
location. The process outlined in this section describes how to change the
location of the change tracking file while preserving its contents.
To relocate the change tracking
file:
- If necessary, determine the current name of the change
tracking file:
2. SELECT
filename
3. FROM
V$BLOCK_CHANGE_TRACKING;
4.
- Shut down the database. For example:
6. SHUTDOWN
IMMEDIATE
7.
- Using host operating system commands, move the change
tracking file to its new location.
- Mount the database and move the change tracking file to
a location that has more space. For example:
10.ALTER DATABASE
RENAME FILE
'ora_home/dbs/change_trk.f' TO '/new_disk/change_trk.f';
11.
- Open the database:
13.ALTER
DATABASE OPEN;
14.
If you cannot shut down the
database, then you must disable change tracking and re-enable it at the new
location, as in the following example:
ALTER
DATABASE DISABLE BLOCK CHANGE TRACKING;
ALTER
DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE 'new_location';
If you choose this method, you will
lose the contents of the change tracking file. Until the next time you complete
a level 0 incremental backup, RMAN will have to scan the entire file.
Estimating Size of the Change Tracking File on Disk
The
size of the change tracking file is proportional to the size of the database
and the number of enabled threads of redo. The size is not related to the
frequency of updates to the database. Typically, the space required for block
change tracking is approximately 1/30,000 the size of the data blocks to be
tracked. Note, however, the following two factors that may cause the file to be
larger than this estimate suggests:
- To avoid overhead of allocating space as your database
grows, the change tracking file size starts at 10MB, and new space is
allocated in 10MB incremenents. Thus, for any database up to approximately
300GB the file size is no smaller than 10MB, for up to approximately 600GB
the file size is no smaller than 20MB, and so on.
- For each datafile, a minimum of 320K of space is
allocated in the change tracking file, regardless of the size of the file.
Thus, if you have a large number of relatively small datafiles, the change
tracking file is larger than for databases with a smaller number of larger
datafiles containing the same data.
