Incremental backup strategies are appropriate for large databases in which only a small portion of the database blocks change from one backup to the next.
If you are in a data warehouse environment, you may want to consider an incremental backup strategy, because it can greatly reduce the size of your backups.
For example, you may want to run a weekly level 0 backup and then run a daily level 1 incremental backup.
The term RMAN level 0 incremental backup doesn’t exactly describe itself very well either.
A level 0 incremental backup is backing up the same blocks as a full backup. In other words, the following two commands back up the same blocks in a database:
RMAN> backup as backupset full database;
RMAN> backup as backupset incremental level=0 database;
The only difference between the prior two commands is that an incremental level 0 backup can be used in conjunction with other incremental backups, whereas a full backup cannot participate in an incremental backup strategy.
Therefore, I almost always prefer to use the INCREMENTAL LEVEL=0 syntax (as opposed to a full backup); it gives me the flexibility to use the level 0 incremental backup along with subsequent incremental level 1 backups.
Use Block Change Tracking
This feature keeps track of when a database block changes. The idea is that if you are using an incremental backup strategy, you can enhance performance, because by implementing this feature, RMAN does not have to scan each block (under the high-water mark) in the data files to determine whether it needs to be backed up.
Rather, RMAN only has to access the block change tracking file to find which blocks have changed since the last backup and directly access those blocks. If you work in a large, data warehouse environment and are using an incremental backup strategy, consider enabling block change tracking to enhance performance.
SQL> alter database enable block change tracking;
Configure Informational Output
A good practice is to always set the NLS_DATE_FORMAT variable at the OS level (before running RMAN) so that both the date and time information are displayed in the RMAN log instead of just the date, which is the default:
$ export NLS_DATE_FORMAT=’dd-mon-yyyy hh24:mi:ss’
This is useful during troubleshooting, especially when RMAN fails, because we can use the exact date/time information for when RMAN error occurred and compare it with the alert.log and OS/XML logs to verify what other events occurred in the database/server.
Also, consider executing SET ECHO ON to ensure that RMAN commands are displayed within the log before the command is executed.
Execute SHOW ALL as well to display the current settings of RMAN variables. These settings are useful when troubleshooting and tuning.
