Oracle RMAN 11g Backup and Recovery (91 page)

increments. A minimum of 320KB of space is allocated to each datafile in the BCTF regardless of the size of the datafile.

The Oracle Database defaults to not using block change tracking, and you can determine if block change tracking is enabled by checking the V$BLOCK_CHANGE_TRACKING view. The STATUS column indicates if block change tracking is enabled, and the FILENAME column contains the filename of the block change tracking file. You can move the block change tracking file by using the
alter database rename file
command just as you would any other database file.

SQL> select status from v$block change tracking;

STATUS

----------

DISABLED

The Base Backup

When doing an incremental backup, the first thing you need is an
incremental base backup.
This backup is the backup that all future incremental backups will be based on. Each time you perform a backup of the database, you assign that backup an incremental level identifier through the use of the
incremental
parameter of the
backup
command. Incremental backups have levels assigned to them. A
base
backup will always have a level value of 0, and you must have a base backup to be able to perform any type of incremental backup. An incremental backup will always have a level value of 1 (more on level 1 incrementals in a moment). If you do not have a base backup and you try to perform an incremental backup (using a backup level 1), then RMAN will perform a base backup for you automatically. Here is an example of performing a base incremental backup:

Chapter 11: RMAN Backups
257

backup incremental level 0 database;

NOTE

Earlier versions of RMAN used to support more than level 0 and

level 1 backups. Starting in Oracle Database 10
g
Release 1, any
incremental level backup other than 0 or 1 was deprecated by Oracle.

Differential vs. Cumulative Incremental Backups

Now, we need to decide how we want to perform our incremental backups. We can use one of two methods:

■ Differential

■ Cumulative

Each is a different method of performing an incremental backup. Let’s look at these two different types of incremental backup in a bit more detail.

Differential Backups

This is the default type of incremental backup that RMAN generates. With a differential backup, RMAN backs up all blocks that have changed since the last level 1 backup or since the last level 0 backup if the differential backup is the first incremental backup after a level 0 backup.

Understanding how this all works can get a bit confusing. Figure 11-1 should help you better understand the impacts of using different levels.

In this example, we have a level 0 differential backup being taken on Sunday. This backup will back up the entire database. Following the level 0 backup, we perform a level 1 differential backup on Monday. This backup will back up all changed blocks since the level 0 backup on Sunday. On Tuesday, the level 1 incremental backup will back up all blocks changed since the level 1 backup on Monday. On Wednesday, another level 0 backup is performed, which backs up all database blocks. On Thursday and Friday, we have level 1 backups again, which back up only the changed blocks, just as the Monday and Tuesday backups did. Finally, on Sunday, we start all over again with a level 0 backup.

FIGURE 11-1
Differential backups

258
Part II: Setup Principles and Practices

Here is an example of a level 1 differential backup being executed. Remember, if a level 0

has not already occurred, this will result in a level 0 backup instead of a level 1 backup.

backup incremental level 1 database;

Cumulative Backups

RMAN provides another incremental backup option, the cumulative backup. Using this option causes backup sets to back up changed blocks since the last level 0 backup, ignoring any previous level 1 backups. This is an optional backup method and requires the use of the
cumulative
keyword in the
backup
command. Again, this can all be somewhat confusing, so let’s look at an example.

Figure 11-2 is an example of the impacts of cumulative backups using different levels.

In Figure 11-2, just as in Figure 11-1, we start with a level 0 differential backup being taken on Sunday. This backup backs up the entire database. Following that, on Monday, we perform a level 1 backup. This backup is not unlike the differential backup. Now things change a little bit. On Tuesday, we perform another level 1 differential backup. This time, the backup will contain not only changed blocks since Monday’s backup, but also the blocks that were contained in Monday’s backup. Thus, a cumulative backup accumulates all changed blocks for any backup level equal to or less than the level of the backup. As a result, for recovery purposes, we need only Tuesday’s backup along with Sunday’s base backup. We continue to take level 0 and level 1 backups over the remainder of the week to complete our backup strategy.

Here is an example of the creation of a level 1 cumulative backup:

backup incremental level 1 cumulative database;

Incremental Backup Options

Oracle allows you to perform incremental backups of not only the database, but also tablespaces, datafiles, and datafile copies. Control files, archived redo logs, and backup sets cannot be made
FIGURE 11-2
Incremental backups

Chapter 11: RMAN Backups
259

as incremental backups. Additionally, you can choose to back up the archived redo logs at the same time. Here are some examples:

backup incremental level 0 tablespace users;

backup incremental level 1 tablespace users;

backup incremental level 0 datafile 4;

backup incremental level 1 datafile 4;

backup incremental level 1 database plus archivelog;

Incrementally Updated Backups

RMAN offers incrementally updated backups (also called merged incremental backups), which let you avoid the overhead of taking full image copy backups of datafiles, yet provide the same recovery advantages as image copy backups.

Merged incremental backups are cumulative incremental backups by default. Older versions of Oracle will generate an error if you try to do them as differential incremental backups. With a merged incremental backup, you create a level 0 (full) backup. Subsequent backups will be level 1 incremental backups. As these incremental backups are made, they are merged into the previous level 0 backup. Thus, there is no need to re-create the level 0 backup, which can save time. Use a block change tracking file in combination with a merged incremental backup to further reduce the time it takes to back up a database.

Let’s look at an example of a merged incremental backup:

RUN {

RECOVER COPY OF DATABASE WITH TAG 'incr update';

BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr update'

DATABASE;

}

The
recover copy of database
command does not actually recover your database, but it causes RMAN to apply any incremental backups to the datafile copies associated with the tag listed (incr_update). The previous commands will create the backup in three stages:
1.
The first backup using these commands will result in the creation of a level 0 backup (assuming a level 0 incremental backup does not already exist). Note that some errors will appear during this backup, starting with “no copy of datafile 1 found to recover.” This is expected, since there is no level 1 incremental backup.

2.
The second time you run this set of commands, a level 1 incremental backup will occur.

Nothing else will occur during this run. Again, you will see the same error as seen on execution number 1.

3.
On the third and subsequent iterations of this backup, the previous level 1 incremental backup will be applied to the level 0 backup. As a result, the level 0 backup will be up to date as of the applied level 1 incremental backup. A new level 1 incremental backup will then occur. This means that any recovery/restore effort only requires the recovery of the level 0 backup, followed by only one level 1 incremental backup (and any required archived redo logs). This can significantly reduce the time required to restore your database.