Recovery Manager (RMAN)
updated for RAC and 10g

Topics


Recovery Manager Major Features
Recovery Manager contains a number features to aid in the backup, restore and recovery operations in large, complex Oracle environments. These include:


Backup file Compression
Recovery Manager only copies data blocks that contain data. A tablespace that is only half filled will be backed up into a file half the size of an OS image copy of the same tablespace.

Incremental Backups
This feature allows backups to be performed that contain only database blocks that have changed since the last full or incremental backup. This can greatly reduce the size of backups. It can also reduce the time required to do a restoration. A typical scenario would be to perform a weekly full backup and daily incrementals.

Corrupt Block Detection
When a backup is executed with Recovery Manager, the database blocks are read and corruption is automatically detected. By default, when a corrupt block error is detected by Recovery Manager, an error message will be displayed (or written to a log file if not running interactively), and the backup terminates. This error message will identify the file that the corrupt block is in. By setting the value of maxcorrupt to something greater than zero (the default) and re-executing the backup or copy, more information on the corrupt block will be put in the views V$BACKUP_CORRUPTION or V$COPY_CORRUPTION.

Fractured Block Detection
Another benefit of an Oracle server process being used when executing Recovery Manager is that an Oracle server process can detect when a data block is fractured. A data block is considered fractured when the control information in the header does not match the information stored in the footer. A fractured block can occur during an online backup because the Oracle data blocks are not always the same size as the operating system block size.
Oracle data blocks are referred to as logical blocks while operating system blocks are called physical blocks. In most environments, the logical block contains multiple physical blocks. Therefore, while the operating system is backing up a database, Oracle can be writing into multiple physical blocks at the same time the operating system is reading a subset of the physical blocks written to by Oracle. To resolve this problem, Oracle implemented the hot backup mode , which tells Oracle to copy the entire logical block to the redo log buffer when a data block is modified. When the database is not in hot backup mode, only the before and after image of the modified row is written to the redo buffer. Since the server process can detect fractured blocks and will reread the block if a fracture is detected, the hot backup mode is not necessary using Recovery Manager.

Automatic Parallelization
Backup and restore operations are automatically parallelized. This is supported with both disk and tape backup/restore operations. The parallelization can be implemented by using the allocate channel and filesperset Recovery Manager commands. Allocate channel is used to assign I/O devices, and the filesperset is used to define how many database files will be written to a single backup output file (called a backup set). The total backup time can be reduced by taking advantage of parallelism.

Backup Usability and Restore Validation Reporting
Recovery Manager has several features that allow a DBA to look at both a running database and backups that have been performed on that database. This information can answer such questions as:

The Recovery Manager report and recover commands can be used to answer these questions. These commands can be executed interactively, or as scripts.
To find out if a tablespace has a datafile that can't be recovered (this could be due to an unrecoverable operation, such as running SQL*Loader in UNRECOVERABLE mode), enter:
report unrecoverable tablespace "users";

To determine if a database has not been backed up within the last 7 days, enter:
report need backup days 7 database;

Backups can become obsolete for various reasons including: a backup of a database file that no longer exists, or there is a more recent backup of an existing file. A report of obsolete backups can be used to determine what could be deleted from backup media to free up space. To find backups that are obsolete because there are at least 2 more recent backups, enter:
report obsolete redundancy 2;

Recovery Manager has the capability of doing a "dry run" restoration of a database. This can be valuable in determining that all files needed for the restoration are available from backup media. The following is an example of validating restoration for an entire database:
restore database validate;

This command checks for the database files needed for restoration, but not the archive log files that may be needed to recover.

Recovery Catalog for Centralized Operations
The recovery catalog is used to store information regarding backup and restore operations. The catalog is a schema that should reside in a database other than those being backed up (target databases). The recovery catalog can contain information about multiple target databases. The reports described in the previous section were generated from information stored in the recovery catalog. The recovery catalog is also used to store scripts of Recovery Manager commands.

If you have just a few databases, then the recovery catalog is probably not worth the extra effort and hassle. If you have a database environment with many databases in it, you should consider using a recovery catalog. Generally, the added flexibility and centralized enterprise-wide reporting benefits of the recovery catalog outweigh the additional maintenance and administrative requirements that are added with the use of a recovery catalog. One downside to using a recovery catalog, though, is that if the catalog database is down, your backups will all fail unless you have coded your backup scripts to perform a backup without the recovery catalog in cases where the first backup with the recovery catalog fails.
Additionally, a recovery catalog is an essential part of a Data Guard backup environment and Split mirror backups. In these configurations, when you back up the database from the backup host, the recovery catalog is considered the most current information, so it is the brains behind the strategy and becomes a single point of failure if not maintained properly. The bottom line is that you need to decide for yourself whether your environment calls for a recovery catalog.
 
Change-Aware Incremental Backups
In previous releases of the Oracle database, RMAN had to examine every block in the data file to determine which blocks had been changed when performing an incremental backup.  The time to perform an incremental backup was proportional to the size of the data files.  Therefore,  performing an incremental backup on a very large database could take some time, even if only a few blocks were changed.
In Oracle 10g, you can create a block change tracking file that records the blocks modified since the last backup.  RMAN uses the tracking file to determine which blocks to include in the incremental backup.  RMAN no longer needs to examine the entire data file.  The time to perform an incremental backup is now proportional to the amount of content modified since the last backup. Here are the steps RMAN will perform to do an incremental backup:
1.    Read the Block Change Tracking File to determine which blocks in the data file need to be read.
2.    Scan only the changed blocks in the data file and then back them up.

The size of the block change tracking file is proportional to:
- The database size in bytes: the block change tracking file contains data representing every data file block in the database.  The data is approximately 1/250000 of the total size of the database.
- The number of enabled threads: In a Real Application Cluster (RAC) environment, the instances update different areas of the tracking file without any locking or inter-node block swapping.  You enable block change tracking for the entire database and not for individual instances.
- The number of old backups: The block change tracking file keeps a record of all changes between previous backups, in addition to the modification since the last backup.  It retains the change history for a maximum of eight backups.
The size of the file is calculated by the following formula:
Size of the Block Change Tracking File =    ( (Threads*2) + number of old backups ) * database size in bytes / 250,000

The initial size for the block change tracking file is 10 MB. Using this formula, a 2 TB database with only one thread and having five backups in the RMAN repository will require a block change tracking file of 59 MB.

Enabling, Disabling and Monitoring Block Change Tracking
By default, Oracle will not record block change information.  To enable this feature, you need to issue the following command:
SQL> alter database enable block change tracking USING FILE ‘/u01/oradata/ora1/change_tracking.f’;

To disable this feature, you issue this command:
SQL> alter database disable block change tracking;

To monitor the status of block change tracking, you type:
select file, status, bytes from   v$block_change_tracking;
STATUS    FILE                            BYTES
--------  ----------------------------    ---------------
ENABLED    /dba/backup/01_mf_yzmrr7.chg    10,000,000

If the location needs to be moved, change tracking can be disabled, and a new change tracking file can be created, but this causes the database to lose all change tracking information. Moreover, unfortunately the change tracking file cannot be moved without shutting down the database, moving it with the appropriate ALTER DATABASE RENAME FILE <filename> command, and then restarting the database.
Oracle does recommend that this feature be activated for any database whose disaster recovery plan utilizes incremental backups of differing levels. Oracle also notes that theirs is a small performance hit during normal operations, but that hit should be discounted against the need to avoid scans of datafiles during restoration and recovery operations.


Expanded Image Copying Features
A standard RMAN backup set contains one or more backup pieces, and each of these pieces consists of the data blocks for a particular datafile stored in a special compressed format. When a datafile needs to be restored, therefore, the entire datafile essentially needs to be recreated from the blocks present in the backup piece.
An image copy of a datafile, on the other hand, is much faster to restore because the physical structure of the datafile already exists. Oracle 10g now permits image copies to be created at the database, tablespace, or datafile level through the new RMAN directive BACKUP AS COPY. For example, here is a command script to create image copies for all datafiles in the entire database:
RUN {
# Set the default channel configuration. Note the use of the
# %U directive to insure unique file names for the image copies
ALLOCATE CHANNEL dbkp1 DEVICE TYPE DISK FORMAT 'c:\oracle\rmanbkup\U%';
# Create an image copy of all datafiles in the database
BACKUP AS COPY DATABASE;
}

More examples:
RUN {
    # Set the default channel configuration
    ALLOCATE CHANNEL dbkp1 DEVICE TYPE DISK FORMAT 'c:\oracle\rmanbkup\ic_%d_%s_%t_%p';
    # Back up specific datafiles and retain them as an image copies
    BACKUP AS COPY (DATAFILE 2, 6, 9 MAXSETSIZE 25M);
    # Back up a specific tablespace and retain it as an image copy
    BACKUP AS COPY (TABLESPACE example MAXSETSIZE 15M);
    # Back up the whole database and retain it as an image copy
    BACKUP AS COPY DATABASE;
}

Incrementally Updated Backups
As we saw before, it is now much simpler to create image copy backups of the database. Another new Oracle 10g feature, incrementally updated backups, allows me to apply incremental database changes to the corresponding image copy backup - also known as rolling forward the datafile image copy -- of any datafile in the database. Since image copy backups are much faster to restore in a media recovery situation, this new feature gives me the option to have updated image copies ready for restoration without having to recreate the image copies on a regular basis.
To utilize this feature, you will use the new BACKUP ... FOR RECOVER OF COPY command to create the incremental level 1 backups to roll forward the changes to the image copy of the datafiles, and use the new RMAN RECOVER COPY OF DATABASE command to apply the incremental backup to the image copies of the datafiles. Note that the TAG directive becomes extremely important to this implementation, as it is used to identify to which image copies the changes are to be rolled forward. Here is a script that illustrates a daily cycle of creation and application of the incrementally updated backups. This would be appropriate for a database that has sufficient disk space for storage of image copies, and has a relatively high need for quick restoration of media:
RUN {
# Roll forward any available changes to image copy files
# from the previous set of incremental Level 1 backups
recover copy of database with tag 'img_cpy_upd';

# Create incremental level 1 backup of all datafiles in the database
# for roll-forward application against image copies
backup incremental level 1
for recover of copy with tag 'img_cpy_upd' database;
}

Though this appears a bit counter-intuitive at first, here is an explanation of what happens during the initial run of this script:
    * The RECOVER command actually has no effect, because it cannot find any incremental backups with a tag of img_cpy_upd.
    * However, the BACKUP command will create a new Incremental Level 0 backup that is labeled with a tag of img_cpy_upd because no backups have been created yet with this tag.

And during the second run of this script:
    * The RECOVER command still will have no effect, because it cannot find any Level 1 incremental backups with a tag of img_cpy_upd.
    * The BACKUP command will create its first Incremental Level 1 backup that is labeled with a tag of img_cpy_upd.

But during the third and subsequent runs of this script:
    * The RECOVER command finds the incremental level 1 image copy backups from the previous night's run tagged as img_cpy_upd, and applies them to the existing datafile image copies.
    * The BACKUP command will create the next Incremental Level 1 backup that is labeled with a tag of img_cpy_upd.

After the third run of this script, RMAN would then choose the following files during a media recovery scenario: the image copy of the database for tag img_cpy_upd from the previous night, the most recent incremental level 1 backup, and all archived redo logs since the image copy was taken. This strategy offers a potentially quick and flexible recovery, since the datafile image copies will be relatively quick to restore, and the incremental level 1 backup plus all archived redo logs can be used to perform either a point-in-time or a complete recovery.
Example: Incrementally-Updated Backups: A Weekly Implementation
RUN {
######
# This script will create image copy backups to which incremental
# changes can be applied on a weekly schedule
######
# Roll forward any available changes to image copy files
# from the previous set of incremental Level 1 backups. Note that
# the roll-forward will not occur until 7 days have elapsed!
recover copy of database with tag 'img_cpy_upd'
until time (sysdate-7);

## Create incremental level 1 backup of all datafiles in the database
# for roll-forward application against weekly image copies
backup incremental level 1
for recover of copy with tag 'img_cpy_upd' database;
}

Database Dropping and Deregistration
Oracle 10g allows a database to be dropped and its entry removed from the RMAN catalog. The following statement drops the entire database and removes the database files:
RMAN> drop database;

The statement below drops the entire database, removes the database files, and deletes all backup copies of the database and the archive log files:
RMAN> drop database including backups;

The two statements above drop the database and delete the database files.  However, they do not unregister the database from the RMAN catalog. The following statement will remove the database information from the RMAN catalog:
RMAN> unregister database grid;

RMAN Architecture
The production database that you are backing up is called the target. A separate database, called the recovery catalog, contains information about datafile and control-file copies, backup sets, archived redo logs, and other key elements needed for recovery.
RMAN performs two main functions:
 - It maintains the RMAN metadata in the control file or the recovery catalog.
 - It communicates with the Oracle database and the operating system in order to create, restore, and recover backup sets and image copies. (RMAN writes image copies to disk only, not to tape.)
RMAN creates several client connections, or channels, between the target database and the backup storage device. RMAN can create backup sets on disk or directly on tape. To use tape storage, RMAN requires a media manager.
If you have more than one database to back up, you can create more than one recovery catalog and have each database serve as the other's recovery catalog. For example, assume there are two production databases, one called "prd1," and a second called "prd2." You can install the recovery catalog for "prd1" in the "prd2" database, and the recovery catalog for the "prd2" database in "prd1." This enables you to avoid the extra space requirements and memory overhead of maintaining a separate recovery catalog database. However, this solution is not practical if the recovery catalog databases for both reside in tablespaces residing on the same physical disk.

To get the most out of RMAN, you should always use a recovery catalog, which contains details of all backup-and-recovery-related operations. RMAN uses the catalog to identify the relationship between backups and database files, automatically deciding which recovery events will minimize the mean time to recover (MTTR). If you run RMAN without using a recovery catalog, it will gather the necessary information from the database's control file but won't support point-in-time recovery. And if you lose all copies of your control file you'll be out of luck. That's why unless you have only one computer running the Oracle software, you should always use a recovery catalog and store it on totally separate hardware from any of your production or target instances - preferably in a separate location. The catalog itself rarely occupies more than 40MB.

IMPORTANT NOTE:
Save the database id displayed in the RMAN output if you are operating RMAN backups in nocatalog mode, since it is required during disaster recovery.
You will see the database id in output from RMAN on connecting to target database like:
connected to target database: INVENTORY (DBID=1670954628)

It's also recommended to save your init.ora file and your tnsnames.ora file in a "safe" place.

Terminology in RMAN
a) Backup Set - is one or more backup piece (physical files) written in format that only RMAN can access.

b) Image Copy - is bit-by-bit copy of database files created on Disk. This is equivalent to cp (on Linux) or copy (on windows).

* Backup Set is default method to backup, for image copy use BACKUP AS COPY while backup.

c) Hot backup - backup taken while Oracle Database is Up. (Database should be in “Archive Log” mode for hot backup)

d) Cold backup - backup taken while Oracle database is down or in mount state (NOT OPEN).

e) Full Backup - Backing up entire database is called as full backup

f) Incremental Backup - Backup of block level changes to database made after previous incremental/full backup.

g) “Level 0" Incremental backup - This backs up all blocks in database. This is equivalent to full backup.

h) “Level 1" Incremental backup - This backs up database block changes after previous incremental backup.
If there is no level 0 incremental backup and you run level 1 incremental backup, RMAN will automatically make level 0 incremental backup.

i) Cumulative incremental backup - level 1 incremental backup which includes all blocks changed since most recent level 0 incremental backup.

j) Differential incremental backup - level 1 incremental backup which includes only block changed since most recent incremental backup.

By default, incremental backups are differential

Flash Recovery Area (FRA)

Please READ HERE FIRST!!!!

By configuring the RMAN RETENTION POLICY, the FRA will automatically delete obsolete backups and archive logs that are no longer required based on that configuration.  If you set the RETENTION POLICY to a recovery window of 7 days, then RMAN will retain all backups required to recover the database 7 days in the past. FRA will delete obsolete files once the disk is arriving to the quote defined.

All files that are needed to completely recover a database from a media failure are part of the Flash Recovery Area. Those recovery related files include:
•    Control file: A copy is created in the Flash Recovery Area location at database creation.
•    Archived log files: When the Flash Recovery Area is configured, the archiver background process then creates archived files in the Flash Recovery Area and in other configured LOG_ARCHIVE_DEST_n locations.
•    Flashback logs: the Flash Recovery Area automatically manages Flashback Database logs.
•    Control file autobackups: The default location for control file .
•    Data file copies:  The default location for data file copies created by RMAN is stored in the Flash Recovery Area.
•    RMAN backups: The default location for RMAN to create files during backup & copy operations.  It is also the default location to restore archive logs from tape if they are required during a recover task.

Per default a backuppiece is created in the Flash Recovery Area unless it is overruled by using the FORMAT-clause.  The FORMAT-clause can be specified in the BACKUP command or configured  in the persistent configuration, by using CONFIGURE command.

Like with normal backup, the Controlfile autobackup will be stored in the Flash Recovery Area unless the location is overruled by the FORMAT for the autobackup.
  RMAN> configure controlfile autobackup format for device type disk to <....>;

Per default RMAN restores the archived redologs in the LOG_ARCHIVE_DEST_n location.  If one of the LOG_ARCHIVE_DEST_n parameters is set to  "LOCATION=USE_DB_RECOVERY_FILE_DEST" then restored archived redo log files will be stored in the Flash Recovery Area. This can be overrulled by using the RMAN command :
  RMAN> SET ARCHIVELOG DESTINATION <....>;



RMAN Configuration

STEP 1 Modify your Net Connnections and Create the Recovery Catalog
Before invoking RMAN, set the NLS_DATE_FORMAT and NLS_LANG environment variables. Much of the RMAN LIST output is date/time related. It is often necessary to have this information displayed as accurately as possible when performing time-based recovery. Example NLS settings:
NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
NLS_DATE_FORMAT=DD-MON-YYYY HH24:MI:SS

Your TNSNAMES.ORA file should have an entry for both your catalog and target databases. For our paper, we will use two databases, the catalog database (RMAN) and the target database (PROD).
Connect to the Oracle RMAN instance by using your DBA account, create an account for RMAN, and grant it appropriate rights.
sqlplus "sys@RMAN as sysdba"
create tablespace RMAN datafile '.......' size 150M autoextend on next 10M maxzize 700M
      EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;
create user RMAN identified by rman temporary tablespace TEMP default tablespace RMAN quota unlimited on RMAN;
grant recovery_catalog_owner, connect, resource, dba to RMAN;
connect RMAN/RMAN@RMAN

Then, create the catalog.
rman catalog=rman/rman@RMAN
rman> create catalog;

To drop the catalog run (no backups performed yet):
rman> drop catalog;


STEP 2 Check Flash Recovery Area for your PROD (optional)
This is where the backups are going to be saved. You can check this parameter by quering query v$recovery_file_dest view. If the space is not big enough, then increase it. If this parameter is not defined yet do it by:
alter system db_recovery_file_dest = '/temp/...' scope=both;
alter system db_recovery_file_dest_size = 10G scope=both;
            (ALTER SYSTEM set db_recovery_file_dest_size=60G scope=both sid='*' ;  if using RAC)

STEP 3 Register Your Database
Now you need to register your target database (PROD) with the catalog you've created. This populates the catalog with initial information regarding the configuration of your target database and includes a full synchronization of the catalog with the target database's control file. Make the call to the rman file from your TARGET DB. Example from the PROD box:
rman target / catalog=rman/rman@RMAN
OR
rman target <qstring> [rcvcat <qstring> | cmdfile <qstring> |
msglog <qstring> | append | trace <qstring>]

Argument     Quoted String Description
TARGET= A connect string containing a userid and password for the database on which Recovery Manager is to operate.
RCVCAT= A connect string that contains a userid and password for the database that contains the recovery catalog (RMAN).
CMDFILE= The name of a file that contains the input commands for RMAN. If this argument is specified, RMAN operates in batch mode; otherwise, RMAN operates in interactive line mode.
MSGLOG= The name of a file where RMAN records commands and output Results. If not specified, RMAN outputs to the screen.
APPEND= This parameters causes the msglog file to be opened in append mode. If this parameter is not specified and a file with the same name as the msglog file already exists, it is overwritten.
TRACE=  A file name where RMAN will dump a trace information. (useful feature for RMAN jobs debugging)

Note: RMAN automatically requests a connection to the target database as SYSDBA. In order to connect to the target database as SYSDBA, you must either:

Be part of the operating system DBA group with respect to the target database. This means that you have the ability to CONNECT INTERNAL to the target database without a password.

-or -

Have a password file setup. This requires the use of the "orapwd" command and the initialization parameter "remote_login_passwordfile".

--As a comment, you can start RMAN from any PROD server using:
rman catalog=rman/rman@RMAN target=sys/passwd@PROD
or
rman
connect target sys/mh_flyers@PROD
connect rcvcat rman/rman@RMAN
# then enter your RMAN commands here


Then Register the Database:
rman> register database

Once complete, the DBID, DB_NAME and structure are captured in the recovery catalog. To verify the registration run:
rman> list incarnation;
List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            CUR Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
38      39      PROD     4283267716       YES 19688901   10-MAY-01


STEP 4 Back Up the Catalog and Synchronize All Databases
If you lose your catalog, you can partially regenerate it from the information in the control file, but you should avoid that predicament by backing it up. You can use RMAN to back up the catalog by creating a recovery-catalog schema in one of your other instances, using that as the catalog for your primary catalog instance. Providing that these two instances do not share any common resources, this role reversal is free from single points of failure.
It's important that your recovery catalog has an up-to-date view of your database. When you execute RMAN operations on the database, RMAN automatically synchronizes the catalog with the target. However, depending on the volatility of your database, you may need to resynchronize the catalog more frequently. Always include catalog resynchronization as part of any structural database change (the addition of files, tablespaces, and so on) and ensure that a resynchronization occurs at intervals less than the init.ora setting for the parameter CONTROL_FILE_RECORD_KEEP_TIME. To perform this action, issue the RESYNC CATALOG command from within RMAN.
 

STEP 5 Setup RMAN Settings
You can always setup the settings from the OEM Console: DB Home Page/Maint Property / Backup and Recovery. This settings are specified only one time.
Use the following command to check your settings once you connect:
rman target / catalog=rman/rman@RMAN
rman> show all;

RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/9.2.0/dbs/snapcf_ORA920.f'; # default
New RMAN Configuration Parameters 
configure retention policy to redundancy 2;
configure default device type to disk;
configure controlfile autobackup on;
configure controlfile autobackup format for device type disk to '/orabackup/rman/ORA920/%d_%F_ctl.bckp';
configure channel device type disk format '/orabackup/rman/ORA920/backup_db_%d_S_%s_P_%p_T_%t' maxpiecesize 5000M;

rman> show all;
 
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
#Keep at least two copies of each datafile and controlfile backup.
# Note that when configuring a retention policy, RMAN will not cause backups to be automatically deleted. 
#The retention policy will, however, mark backups as OBSOLETE that have fallen outside the retention period. 
#RMAN commands like "REPORT OBSOLETE" and "DELETE OBSOLETE" will work with these obsolete backups.
# If you have certain backups which must be retained longer than this retention policy, 
# you can use the KEEP option with the BACKUP command when creating those backups

CONFIGURE BACKUP OPTIMIZATION OFF; # default
#If we turn this command ON, then RMAN will not backup already backuped READ ONLY tablespaces

CONFIGURE DEFAULT DEVICE TYPE TO DISK;
#By Default save all the Backups to disk

CONFIGURE CONTROLFILE AUTOBACKUP ON;
#Performs backup of controlfile and spfile to the same backup piece each time a backup or copy is performed (default location is FRA).
NOTE= If you are not going to use a recovery catalog, and you wish to be able to recover your control file after an automated control file backup, 
you must know the DBID of the database. You should, as a part of your initial setup and configuration of RMAN, note the DBIDs of the databases that 
you will be backing up and save that list somewhere safe. 
The DBID of the database is available from the V$DATABASE view in the DBID column. 
The DBID of the database is also displayed when you start RMAN and connect to a target database.

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/some_location/%d_%F_ctl.bckp';
#Performs the Backup of the controlfile on that place instead of the Flash Recovery Area, 
# The "%F" in the file name translates into c-IIIIIIIIII-YYYYMMDD-QQ, where:
    * IIIIIIIIII - stands for the DBID. (The DBID is printed in decimal so that it can be easily associated with the target database.
    * YYYYMMDD - is a time stamp in the Gregorian calendar of the day the backup is generated.
    * QQ - is the sequence in hexadecimal number that starts with 00 and has a maximum of 'FF' (256). 

CONFIGURE DEVICE TYPE DISK PARALLELISM 2;
#By default put 2 channels per backup:
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/orabackup/rman/ORA920/backup_db_%d_S_%s_P_%p_T_%t' MAXPIECESIZE 5000 M;
#Specifies the location and name of the backup files. We need to specify the format for each channel. 
# The format specifier %t is replaced with a 4-byte timestamp, %s with the backup set number, and %p with the backup piece number.
The "%U" ensures that Oracle appends a unique identifier to the backup file name. 
The MAXPIECESIZE (optional) attribute sets a maximum file size for each file in the backup set. 
CONFIGURE MAXSETSIZE TO UNLIMITED; # default

CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/some_location/snapcf_ORA920.f'; 
# Where to create the snapshot file for resync

CONFIGURE EXCLUDE FOR TABLESPACE tbl_exclude;
# Excludes tbs_exclude from full database backups. 
# NOEXCLUDE can be specified with the BACKUP command to override this configuration.

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; (10g only)
Governs archived redo log deletion policy for the flash recovery area. Possible options :
APPLIED ON STANDBY - enables FRA to delete archivelogs that are applied on mandatory standby. 
NONE        - enables FRA to delete archivelogs that are backed up to tertiary device and that are obsolete based on the configured backup retention policy. 
              This is the default configuration.
CLEAR       - clears the deletion policy and returns the specified configuration to default value. The default value is NONE.
By default, archived redo log files in a FRA that were backed up to a tertiary device or made obsolete (as defined by the RMAN retention policy) are eligible for deletion. 
Examples of the CONFIGURE ARCHIVELOG DELETION POLICY Command:
When backups of archived redo log files are taken on the standby database:
1. Issue the following command on the primary database:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
2. Issue the following command on the standby database:
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;

When backups of archived redo log files are taken on the primary database:
1. Issue the following command on the standby database:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
2. Issue the following command on the primary database:
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;

Reconfiguring the Deletion Policy After a Role Transition :
After a switchover or failover, you may need to reissue the RMAN CONFIGURE ARCHIVELOG DELETION POLICY command on each database.
If the backup site for archived redo log files remains the same, then do nothing.
Otherwise, you must switch the archivelog deletion policy by issuing the
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY statement on the database where backups are not taken, and issuing the CONFIGURE ARCHIVELOG DELETION POLICY TO NONE statement on the database where backups are taken. 

Viewing the Current Deletion Policy
To view the current setting (APPLIED ON STANDBY, CLEAR, NONE) for a database,issue the following query:
SELECT NAME, VALUE 
FROM V$RMAN_CONFIGURATION 
WHERE NAME LIKE '%ARCHIVELOG DELETION POLICY%';
NAME                          VALUE
----------------------------- --------------
ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY

You can also find the existing configuration using the RMAN SHOW ARCHIVELOG DELETION POLICY command:
RMAN> SHOW ARCHIVELOG DELETION POLICY
RMAN configuration parameters are:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;

Using Substitution Variables
RMAN can make use of substitution variables in creating format strings to generate filenames. Without due care, non-unique filenames can be generated and, under certain circumstances, this can cause backup data to be overwritten and therefore lost. So be careful; this is not a bug with Oracle, but rather a usage error.

Format Description
%p specifies the backup piece number within the backup set. This value starts at 1 for each backup set and is incremented by 1 as each backup piece is created.
%s specifies the backup set number. This number is a counter in the control file that is incremented for each backup set. The counter value starts at 1 and is unique for the lifetime of the control file. If you restore a backup control file, then duplicate values can result. Also, CREATE CONTROLFILE initializes the counter back to 1.
%d specifies the database name.
%n specifies the database name, padded on the right with 'x' characters to a total length of 8 characters. For example, if PROD1 is the database name, then PROD1xxx is the padded database name.
%t specifies the backup set timestamp, which is a 4-byte value derived as the number of seconds elapsed since a fixed reference time. The combination of %s and %t can be used to form a unique name for the backup set.
%u specifies an 8-character name constituted by compressed representations of the backup set number and the time the backup set was created.
%c (Oracle8i or higher) - specifies the copy number of the backup piece within a set of duplexed backup pieces. If you did not issue the set duplex command, then this variable will be 1 for regular backup sets and 0 for proxy copies. If you issued set duplex, the variable identifies the copy number: 1, 2, 3, or 4.
%U (Oracle8i or higher) - specifies a convenient shorthand for %u_%p_%c that guarantees uniqueness in generated backup filenames. If you do not specify a format, RMAN uses %U by default. %U is the default in Oracle8i.



We can always clean these settings to its default values using:
configure ......   clear;

STEP 5.5 Validating Backups (optional)
Validation confirms that a backup could be run, by confirming that all database files exist, are in their correct location, and are free of physical and logical corruption:
RMAN> backup validate database archivelog all;

If you get:
RMAN-06059: expected archived log not found, lost of archived log compromises recoverability

It means that the Archive Log Files doesn't exist (maybe was removed on OS level but not by RMAN).  Your options are either to restore the missing file(s), or to perform a crosscheck. To perform a crosscheck, run the following command from within RMAN:
RMAN> crosscheck archivelog all;
This will give non-existing archivelogs status of 'EXPIRED', these are no longer used for backups.
When an archive log crosscheck is performed, RMAN checks each archive log in turn to make sure that it exists on disk (or tape). Those that are missing are marked as unavailable. If you have got missing logs, this won't bring them back. It will allow you to get past this error and back-up the database though.
It is advisable to perform a full backup of the database at this point. Schedule a crosscheck every once in a while (e.g. weekly) in order to prevent this.
And then run:
RMAN> list expired archivelog all;
to see if it lists any missing archive logs.
And then:
RMAN> delete expired;
to remove the expired ones.

STEP 6 Create Database Backups
Now you are ready to run a Full Backup.
rman> backup spfile;                                                                        #Just to test the backup of this file, it will save it to the default place (Flash Recovery Area or Disk)
rman> backup database plus archivelog tag="Full_Database";    # Will backup to the default place (Flash Recovery Area or Disk) with a tag
rman> backup database format '/tmp/%U';                                     #Backup to a Specific Place, the %U generates a unique name.
rman> backup archivelog all delete input;                                      #Backup All Archive log Files and delete the ones that were backuped from PROD
rman> backup archivelog all delete all input;                                 #Backup All Archive log Files and delete all of them from PROD

Next we perform a complete database backup using a single command, we will put a tag and delete obsolete files:
RMAN> run {
   backup database plus archivelog tag="Full_Database";
   delete noprompt obsolete;
}

When you run RMAN in command line mode, it sends the output to the terminal.
If you specify the msglog option, then RMAN writes the output to a specified log file instead. Example:

rman target=/ nocatalog msglog Full_RMAN_Backup.txt

In this example, a sample RMAN script is placed into a command file called commandfile.rcv. You can run this file from the operating system command line and write the output into the log file outfile.txt as follows:
rman TARGET / CATALOG rman/cat@catdb CMDFILE commandfile.rcv LOG outfile.txt

STEP 7 - Test your backup (optional)
This will do everything except actually restore the database. This is the best method to determine if your backup is good and usable before being in a situation where it is critical and issues exist.
The following commands can be run any time to check if RMAN is capable of restoring database/tablespace using existing backups.

# check if database can be restored
RMAN> restore validate database;

# check if tablespace is restorable
RMAN> restore validate tablespace read_only_tablespace_name ;

# check if controlfile can be restored
RMAN> restore controlfile validate ;

#check if archivelogs for the past two weeks can be restored
RMAN> restore archivelog from time 'sysdate-14' validatel;

Some Points to Remember:
-RMAN doesn't automatically delete obsolete files, you need to specify the DELETE OBSOLETE command, but if you are using FRA you don't need to specify the OBSOLETE command.
- The catalog is usefull ONLY to save some scripts, except for that, all the RMAN features work equally well with or without a catalog. The repository is ALWAYS on the controlfile of the TARGET DB.
- A whole backup is a backup of all database files and current control file, perform this one using the BACKUP DATABASE command.
- You can specify SQL commands on RMAN like:
          rman> sql 'alter system archive log current';   #switch log files


Other RMAN Commands
#Backup Some tablespaces only:
rman> backup tablespace users, tools;
rman> backup tablespace SYSTEM format '/u01/oracle/db/AKI1/bck/ora_df%t_s%s_s%p';

#Backup a datafile:
rman>backup datafile copy '/tmp/system01.dbf';

#Also backup the Archve log Files:
rman>backup .......  plus archivelog;

#Backup all the archive log Files:
rman> backup archivelog all;

#Backup all the archive log Files and delete them from their location:
rman> backup archivelog all delete all input;

#Backup current control file to specific place:
rman> backup current controlfile to '/.../....';


Scripting your Backups
To save a script into the catalog you can use:
create script prod_full_backup {
 # backup the complete database to disk, backup all Arch Logs and delete them
  backup database plus archivelog tag="Full_Database"
  format '/data/archdata/DBbackup/%d_t%t_s%s_p%p';
  sql "alter system archive log current";
  backup archivelog all delete all input;
}

To Drop it from RMAN just perform:
delete script  script_name;

To Execute it from RMAN just perform:
run {execute script prod_full_backup;}

To read the code from the Database you can run the following query:
select text from rc_stored_script_line where script_name='prod_full_backup';


Step 7 (optional) -  You can create a Unix Script
That will call the saved script in RMAN
We want to run it every Sunday night as a scheduled job. Let's run it as a cron job. Create a Korn shell script called "rman_backup.ksh". This shell script will run the RMAN script, prod_full_backup.rcv.

#!/bin/ksh
# Shell script to run RMAN script prod_full_backup.rcv
# Logging messages to prod_full_backup.log
# Set environment variables
export ORACLE_SID=PROD
export ORACLE_HOME=/usr/local/OraHome1
# Connect to RMAN and run the backup script (all in one line)
rman target / rcvcat rman/rman@rman cmdfile /home/oracle/script/rman_prod_full_backup.rcv msglog /home/oracle/script/rman_full_backup.log
exit

Change permissions on the shell script appropriately.
chmod 755 rman_backup.ksh

Now, create the RMAN script file, prod_full_backup.rcv. This just runs the previously stored catalog script, prod_full_backup. Here are the contents of prod_full_backup.rcv
run {execute script prod_full_backup;}

Finally, schedule the shell script using the crontab.
[prod-server:oracle] $ crontab -e
00 21 * * 0 /home/oracle/script/rman_backup.ksh

We have scheduled our script to run every Sunday night at 9:00 PM.

Query RMAN
LIST (no catalog needed) -> List Backups and DB Incarnations
REPORT(no catalog needed) -> Shows files that needs backups, backups that are obsolete
PRINT SCRIPT (use catalog) -> names of the scripts in the catalog


Understanding the Backup Process
Now that RMAN is configured, backing up the database (including backing up all archive redo logs), is as easy as:

RMAN Statements to Perform Full (online) Database Backup 
% rman target backup_admin/backup_admin nocatalog msglog rman_full_backup_db_online_ORA920.log

RMAN> backup database plus archivelog delete input;
RMAN> delete noprompt force obsolete;
RMAN> exit;


The following table includes all resulting backup sets contained in the control file after performing the above backup routine.

BS
Key		 Backup
Type		 Device
Type		 Controlfile
Included?		 SPFILE
Included?		 Piece
Number		 Handle (Piece) Name Start
Time		 End
Time		 Elapsed
Seconds		 Tag Block
Size
2 Datafile Full DISK     1 /orabackup/rman/ORA920/backup_db_ORA920_S_5_P_1_T_543443342 11/28/04 20:29:02 11/28/04 20:32:44 222 TAG20041128T202902 8,192
          2 /orabackup/rman/ORA920/backup_db_ORA920_S_5_P_2_T_543443342 11/28/04 20:32:47 11/28/04 20:34:45 118 TAG20041128T202902 8,192
3 Archived Logs DISK     1 /orabackup/rman/ORA920/backup_db_ORA920_S_6_P_1_T_543443693 11/28/04 20:34:53 11/28/04 20:34:53 0 TAG20041128T203452 512
4 Datafile Full DISK YES YES 1 /orabackup/rman/ORA920/c-2542143170-20041128-01 11/28/04 20:34:54 11/28/04 20:34:55 1   8,192


Now, let's talk about the actual steps that were performed by RMAN after running the full (online) database backup statements. I attempted to annotate the RMAN log file (below) with the following steps. Note that the first 6 steps were all part of the backup database plus archivelog delete input; statement. The 7th step includes the delete noprompt force obsolete; statement

  1. The first action performed by RMAN is a log switch (using the alter system srchivelog current command).

  2. Next, all existing archived redo logs (including the one just archived) are backed up to a Archive Log backup set. Note that at the end of the RMAN statements in our example, this archive log backup set (backup_db_ORA920_S_4_P_1_T_543443326) will be removed as it will no longer be needed once the database files are backed up.

  3. RMAN then starts the backup of the actual database files. For this backup set, (BS Key - 2), RMAN creates two backup pieces: backup_db_ORA920_S_5_P_1_T_543443342 and backup_db_ORA920_S_5_P_2_T_543443342.

  4. After the full database backup, RMAN performs another archive redo log switch (using the alter system archivelog current command).

  5. After the archive redo log switch completes, RMAN creates an Archived Log backup set (BS Key - 3) of the remaining archived redo logs (using the backup archivelog all command). This is backup piece backup_db_ORA920_S_6_P_1_T_543443693. Keep in mind that this archived redo log backup set includes the redo logs that occured during the full database backup.

  6. Finally, the autobackup of the control file and SPFILE occurs and creates another datafile backup set (BS Key - 4). This is contained in backup piece c-2542143170-20041128-01. Since a full database backup will always include datafile 1, which belongs to the SYSTEM tablespace, there will always be a backup of the control file and the SPFILE. At this point, all tasks for the backup database plus archivelog delete input; statement have been completed.

  7. The delete noprompt force obsolete; statement is then run to apply the retention policy we have configured. In our example, the first Archive Log backup set (that was performed at the begining on this example) will be removed. This was piece backup_db_ORA920_S_4_P_1_T_543443326.

RMAN Full (online) Database Backup Log File 
Recovery Manager: Release 9.2.0.5.0 - Production

Copyright (c) 1995, 2002, Oracle Corporation.  All rights reserved.

connected to target database: ORA920 (DBID=2542143170)
using target database controlfile instead of recovery catalog

RMAN> 

Starting backup at 28-NOV-04
current log archived  (Step 1)
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=16 devtype=DISK
channel ORA_DISK_1: starting archive log backupset  (Step 2)
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=89 recid=1 stamp=543441301
input archive log thread=1 sequence=90 recid=2 stamp=543443042
input archive log thread=1 sequence=91 recid=3 stamp=543443132
input archive log thread=1 sequence=92 recid=4 stamp=543443258
input archive log thread=1 sequence=93 recid=5 stamp=543443325
channel ORA_DISK_1: starting piece 1 at 28-NOV-04
channel ORA_DISK_1: finished piece 1 at 28-NOV-04
piece handle=/orabackup/rman/ORA920/backup_db_ORA920_S_4_P_1_T_543443326 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:15
channel ORA_DISK_1: deleting archive log(s)
archive log filename=/u06/app/oradata/ORA920/archive/arch_t1_s89.dbf recid=1 stamp=543441301
archive log filename=/u06/app/oradata/ORA920/archive/arch_t1_s90.dbf recid=2 stamp=543443042
archive log filename=/u06/app/oradata/ORA920/archive/arch_t1_s91.dbf recid=3 stamp=543443132
archive log filename=/u06/app/oradata/ORA920/archive/arch_t1_s92.dbf recid=4 stamp=543443258
archive log filename=/u06/app/oradata/ORA920/archive/arch_t1_s93.dbf recid=5 stamp=543443325
Finished backup at 28-NOV-04

Starting backup at 28-NOV-04
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset  (Step 3)
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/u06/app/oradata/ORA920/system01.dbf
input datafile fno=00010 name=/u06/app/oradata/ORA920/users01.dbf
input datafile fno=00002 name=/u06/app/oradata/ORA920/undotbs01.dbf
input datafile fno=00011 name=/u06/app/oradata/ORA920/perfstat01.dbf
input datafile fno=00007 name=/u06/app/oradata/ORA920/example01.dbf
input datafile fno=00003 name=/u06/app/oradata/ORA920/cwmlite01.dbf
input datafile fno=00004 name=/u06/app/oradata/ORA920/drsys01.dbf
input datafile fno=00005 name=/u06/app/oradata/ORA920/odm01.dbf
input datafile fno=00006 name=/u06/app/oradata/ORA920/xdb01.dbf
input datafile fno=00008 name=/u06/app/oradata/ORA920/indx01.dbf
input datafile fno=00009 name=/u06/app/oradata/ORA920/tools01.dbf
input datafile fno=00012 name=/u06/app/oradata/ORA920/users02.dbf
channel ORA_DISK_1: starting piece 1 at 28-NOV-04
channel ORA_DISK_1: finished piece 1 at 28-NOV-04
piece handle=/orabackup/rman/ORA920/backup_db_ORA920_S_5_P_1_T_543443342 comment=NONE
channel ORA_DISK_1: starting piece 2 at 28-NOV-04
channel ORA_DISK_1: finished piece 2 at 28-NOV-04
piece handle=/orabackup/rman/ORA920/backup_db_ORA920_S_5_P_2_T_543443342 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:05:50
Finished backup at 28-NOV-04

Starting backup at 28-NOV-04
current log archived  (Step 4)
using channel ORA_DISK_1
channel ORA_DISK_1: starting archive log backupset  (Step 5)
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=94 recid=6 stamp=543443692
channel ORA_DISK_1: starting piece 1 at 28-NOV-04
channel ORA_DISK_1: finished piece 1 at 28-NOV-04
piece handle=/orabackup/rman/ORA920/backup_db_ORA920_S_6_P_1_T_543443693 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
channel ORA_DISK_1: deleting archive log(s)
archive log filename=/u06/app/oradata/ORA920/archive/arch_t1_s94.dbf recid=6 stamp=543443692
Finished backup at 28-NOV-04

Starting Control File and SPFILE Autobackup at 28-NOV-04  (Step 6)
piece handle=/orabackup/rman/ORA920/c-2542143170-20041128-01 comment=NONE
Finished Control File and SPFILE Autobackup at 28-NOV-04

RMAN> 
RMAN retention policy will be applied to the command  (Step 7)
RMAN retention policy is set to redundancy 2
using channel ORA_DISK_1
Deleting the following obsolete backups and copies:
Type                 Key    Completion Time    Filename/Handle
-------------------- ------ ------------------ --------------------
Backup Set           1      28-NOV-04         
  Backup Piece       1      28-NOV-04          /orabackup/rman/ORA920/backup_db_ORA920_S_4_P_1_T_543443326
deleted backup piece
backup piece handle=/orabackup/rman/ORA920/backup_db_ORA920_S_4_P_1_T_543443326 recid=1 stamp=543443326
Deleted 1 objects


RMAN> 

Recovery Manager complete.


Special Considerations for RAC

- Check that your DB is in archive log mode
- Set up Flash Recovery to save the archive log files and backuped files to an NFS mounted drive or to the cluster file system (much better). The directory for Archive Log Files MUST exist in all the nodes.
- Setup the snapshot control file Location. The snapshot control file is a temporary snapshot control file that RMAN creates to re-synchronize from a read-consistent version of the control file. RMAN only needs a snapshot control file when re-synchronizing with the recovery catalog or when making a backup of the current control file.
In RAC, the snapshot control file is only needed on the nodes on which RMAN performs backups; the snapshot control file does not need to be globally available to all instances in a RAC environment.
You can specify a cluster file system file or a raw device destination for the location of your snapshot control file.
- Verify connectivity to all the boxes
- Connect to RMAN to verify and set the controlfile persistent configuration. The controlfiles are shared between the instances. Also note the target DBID at connection. Perform the following parameter modifications:
rman> show all;
 

RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/9.2.0/dbs/snapcf_ORA920.f'; # default
configure retention policy to redundancy 3;       #retain the 3 last backups performed
configure default device type to disk;
configure controlfile autobackup on;              #Performs backup of controlfile and spfile each time a backup is performed
configure snapshot controlfile name to '$ORACLE_HOME/dbs/snapcf_ORACLE_SID';  # Where to create the snapshot file for resync
configure controlfile autobackup format for device type disk to '/backup_oltp/%d_%F_ctl.bckp';
#Performs Backups on that place instead of the Flash Recovery Area, The "%F" in the file name instructs RMAN 
#to append the database identifier and backup timestamp to the backup filename. 
#The database identifier, or DBID, is a unique integer identifier for the database. Note that the control file is only specified for a single location, 
#which requires each node to have that directory in each node. 
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/backup_oltp/backup_db_%d_S_%s_P_%p_T_%t';
configure device type disk parallelism 2;          #Put 2 because 2 nodes
configure channel 1 device type disk connect 'SYS/password@node1';
configure channel 2 device type disk connect 'SYS/password@node2';


Managing Archived Redo Logs on RAC
When a node generates an archived redo log, Oracle always records the filename of the log in the control file of the target database. If you are using a recovery catalog, then RMAN also records the archived redo log filenames in the recovery catalog when a re-synchronization occurs. The archived redo log naming convention that you use is important because when a node writes to a log with a specific filename on its file system, the file must be readable by any node that needs to access this archived redo log. For example, if node 1 archives a log to /oracle/arc_dest/log_1_100_23452345.arc, then node 2 can only back up this archived redo log only if it can read /oracle/arc_dest/log_1_100_23452345.arc on its own file system.
The backup and recovery strategy that you choose depends on how you configure the archiving destinations for each node. Whether only one node or all nodes perform archived redo log backups, you need to ensure that all archived redo logs are backed up. If you use RMAN parallelism during recovery, then the node that performs recovery must have read access to all archived redo logs in your cluster.
As an example, if the instance associated with redo thread number 1 sets LOG_ARCHIVE_FORMAT to log_%t_%s_%r.arc, then its archived redo log files are named:
log_1_1000_23435343.arc
log_1_1001_23452345.arc
log_1_1002_23452345.arc
The primary consideration is to ensure that all archived redo logs can be read from every node during recovery, and if possible during backups.
I HIGHLY recommend to use a CFS to save the archived redo logs from all the nodes to a single location

- Perform a Backup with differential incremental 0 and then archived logs using delete input option.
rman> backup incremental level 0 format '/shared_directory/%d_LVL0_%T_%u_s%s_p%p'
database PLUS ARCHIVELOG format '/shared_directory/%d_ARCGLOG_%T_%u_s%s_p%p'
delete input;

 - Backupset Maintenance using the configured retention policy
rman>
list backup summary;
list backup of database;
list backup of archivelog all;
list backup of controlfile;
report obsolete;
delete obsolete or delete noprompt obsolete;
report schema;

- Deleting archived Redo Logs after a Successful Backup
Assuming that you have configured the automatic channels, you can use the following example to delete the archived logs that you backed up n times (in this case I'm using a '1' to specify RMAN not to delete the archive logs unless it has a record of them being backed up at least once). The device type can be DISK or SBT:
rman> DELETE ARCHIVELOG ALL BACKED UP 1 TIMES TO DEVICE TYPE disk;
During a delete operation, as long as at least one of the channels allocated has access to the archived log, RMAN will automatically schedule the deletion of the specific log on that channel. For a local archiving scheme, there must be at least one channel allocated that can delete an archived log. For a CFS archiving scheme, assuming that every node writes to the archived logs on the same CFS, the archived log can be deleted by any allocated channel.

If you have not configured automatic channels, then you can manually allocate the maintenance channels as follows and delete the archived logs.
rman> ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK CONNECT 'SYS/oracle@node1';
ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE DISK CONNECT 'SYS/oracle@node2';
DELETE ARCHIVELOG ALL BACKED UP 1 TIMES TO DEVICE TYPE disk;


Backing up Backups
There is a legitimate need to take a copy of a backup set: for example, you backup to disk, because restores and recoveries from disk will be quicker than ones to tape.  But you can’t just keep backing up to disk, because it will run out of room.  Instead, you treat the disk as a staging area… as a new backup to disk is taken, the previous one is moved off onto tape.
The default backup directory is:
         /path1/backup_dir
You need to move the backups to another disk or directory.
         /path2/backup_dir/
To move the backupsets directory structure to restore a backup use:
BACKUP DEVICE TYPE disk BACKUPSET ALL format '/path2/backup_dir/prod9/%d_%U' DELETE INPUT;

To move the backupsets directory to tape and leave them on disk use:
Backup device type sbt backupset all;

This command would typically be run in a scenario where the user wants more recent backups to exist on disk and older backups to exist on tape, but does not need backups to exist on both disk and tape at the same time. Using DELETE INPUT effectively makes this a move operation. If you don't use DELETE INPUT then rman can failover if a error occurs reading the backup backupset.
BACKUP DEVICE TYPE SBT BACKUPSET CREATED BEFORE 'sysdate-7' DELETE INPUT;

…but (assuming a nightly backup, and room on disk for just one night’s backup) you could do this:
backup device type sbt backupset created before ‘sysdate-1’ delete input;
…and the ‘delete input’ bit ensures that the source backup set is removed from the disk, after being archived onto tape.


Unregister a Database From RMAN
First we start up RMAN with a connection to the catalog and the target, making a note of the DBID in the banner
rman catalog=rman/rman@rman target=sys/password@PROD

Next we list and delete any backupsets recorded in the repository:
rman> list backup summary;
rman> delete backup device type sbt;
rman> delete backup device type disk;

Next we connect to the RMAN catalog owner using SQL*Plus and issue the following statement:
SQL> CONNECT rman/rman@dba1
SQL> SELECT db_key, db_id FROM db WHERE db_id = 1487421514;
DB_KEY      DB_ID
---------- ----------
1          1487421514

The resulting key and id can then be used to unregister the database:
SQL> EXECUTE dbms_rcvcat.unregisterdatabase(1, 1487421514);

Deleting data from Catalog
If the backuped files has been deleted from the host, you can perform a "CLEAN" process running the following:
************************************************************************
--Clean ALL INVALID on RMAN (specially if I delete files manually)
************************************************************************
rman> crosscheck backup;
rman> report obsolete;
rman> delete obsolete;
rman> report schema;
rman> report need backup;
rman> list backup;
rman> list expired backup;
rman> delete expired backup;
rman> list expired backupset;
rman> delete expired backupset;
rman> RESYNC CATALOG;


Backing up in no archivelog mode
Target database is MOUNTED (but not open). If the database is open and not in archivelog mode, RMAN will generate an error when you attempt to perform a datafile backup

1. Example of how to back up a complete database
This example assumes that the target database is already configured with automatic channels. The following will perform an offline backup. Notice that you you can use RMAN to shutdown and startup the database (which is required for performing an offline backup):

% rman target system/manager@PROD
RMAN> shutdown immediate
RMAN> startup mount
RMAN> backup database;
RMAN> alter database open;


Image Copies

The advantage of using Image Copies is that they can be used in manual recovery operations. The disadvantage of them is that they take more space than backup sets.

Incremental backups
If your database is particularly large, you may want to consider making incremental backups. Unlike incremental exports, which operate at a table level, RMAN incremental backups back up only changed blocks. This approach optimizes not only backup times but recovery operations as well, because RMAN intelligently decides what combination of full, incremental, and archive-log backups will produce the optimal recovery path.
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.
RMAN incremental backups back up only datafile blocks that have changed since a specified previous backup.

RMAN uses the concept of multilevel incremental backups, with levels 0, 1, or 2.
Level 0 is equivalent to a full backup.  Level 0 backup of database is taken by
RMAN>BACKUP INCREMENTAL LEVEL 0 DATABASE;


Level 1 incremental backup can be two types,
1) Differential Level 1 Backup: It backs up all blocks changed after the most recent incremental backup at level 1.
If no level 1 found then backs up all blocks after most recent incremental backup at level 0.
If no level 1 and level 0 is found then the behavior is based on COMPATIBILITY settings.
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.
If compatibility <10.0.0, RMAN generates a level 0 backup.
This is the default level 1 incremental backup.  Level 1 backup of database is taken by
RMAN>BACKUP INCREMENTAL LEVEL 1 DATABASE;

2) Cumulative Level 1 Backup: It backs up all blocks changed after the most recent incremental backup at level 0. Level 1 cumulative backup can be taken by,
RMAN>BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;

To improve the performance of incrementally updated backups another feature called Change Tracking has also been introduced in Oracle 10g. This lets you record the changes in the blocks of datafiles in a separate datafile in the database called Change Tracking File. Then when the time for backup comes, RMAN reads the Change Tracking File to find out the changes which happened to the database instead of scanning whole datafile. This makes the backup faster. This feature is available on Enterprise EDITION Only. You can enable Change Tracking with:
SQL> alter database enable block change tracking using file '/usr/local/oracle/testdw0/rman_change_track.dbf';


The Script I used to take an Incrementally Updated Backup is rman_incr_backup.sh below. This is a script which uses non-default RMAN location as I explicitly indication where the backups should be stored on disk. This version doesn't use FRA (Flash Recovery Area) either.

# ########################################
# !/bin/bash
# Unix controls
trap cleanup 1 2 3 15
cleanup()
{
echo "Caught CTRL-C Signal ... exiting script."
exit 1
}
# Oracle Variables
export ORACLE_SID=testdw0
export ORACLE_BASE=/usr/local/oracle
export ORACLE_HOME=/usr/local/oracle/product/10.2.0.1
export PATH=$PATH:${ORACLE_HOME}/bin

# RMAN INCREMENTALLY UPDATED BACKUPS (Window of 24 hours)
rman target=/ << EOF
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/usr/local/oracle/backups/rman_bkps/dwbacks/atbckp_cntrlfile_testdw0%F';
run {
ALLOCATE CHANNEL RMAN_BACK_CH01 TYPE DISK FORMAT '/usr/local/oracle/backups/rman_bkps/dwbacks/databasefiles_%d_%u_%s_%T';
CROSSCHECK BACKUP;
RECOVER COPY OF DATABASE with TAG 'testdw0_incr_update';
BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY with TAG 'testdw0_incr_update' DATABASE;
sql 'ALTER SYSTEM ARCHIVE LOG CURRENT';
BACKUP as compressed backupset ARCHIVELOG ALL format '/usr/local/oracle/backups/rman_bkps/dwbacks/archivelogs_%d_%u_%s_%T' DELETE INPUT;
CROSSCHECK BACKUP;
DELETE NOPROMPT OBSOLETE;
DELETE NOPROMPT EXPIRED BACKUP;
RELEASE CHANNEL RMAN_BACK_CH01;
}
EXIT;
EOF
#########################################

To execute an incremental backup, include the incremental keyword and a level number in the backup statement:
# Resync the catalogue
resync catalog;
# Backup the database Level 0
backup incremental level 0 tag = "Weekly_Full_Database"  format '/data/oracle8/BACKUP/rman_LVL0_%d.%t.%p.%c' database;


# Resync the catalogue
resync catalog;
# Backup the database level 1
backup incremental level 1 tag="Oracle_Backup_Level_1" format '/data/oracle8/BACKUP/rman_LVL1_%d.%t.%p.%c' database;
or
backup incremental level 1 cumulative tag="Oracle_Backup_Level_1" filesperset 5 format '%d_%t_%s_%p.dbf' database  ;

Example backup strategy using incremental backups

A typical incremental backup cycle would be as follows:
        o. Sun night - level 0 backup performed
        o. Mon night - level 2 backup performed
        o. Tue night - level 2 backup performed
        o. Wed night - level 2 backup performed
        o. Thu night - level 1 backup performed  --> Contains all changes since Sunday
        o. Fri night - level 2 backup performed
        o. Sat night - level 2 backup performed

If the database suffered a failure on Sat morning and this resulted in a restore operation, RMAN could recover to the point of failure by restoring the backups from Sunday, Thursday, and Friday. This is because Thursdays level 1 backup contains all changes since Sunday, and Friday's level 2 backup contains all changes since Thursday. Whether the database could be completely recovered would depend on whether archive logging is enabled.
 
Example:
Following scenario assumes that you want to take one full database once a week, doing every day incrementals.
Backup cycle starts on friday, i.e., every friday full backup, and on other days incrementals.

# Section 1 - Start script for backup cycle
# -------------------------------------------
# The following commands are run each Friday to start the backup cycle.
# The steps are:
# - Take an incremental level 0 backup of the database. A level 0 backup is a complete backup of the entire file which can be used as the basis for a subsequent incremental backup.
# - Backup all archivelogs that have not already been backed up.
# - Delete on-disk archivelogs older than seven days.
run{
backup incremental level 0 tag = "Weekly_Full_Database" format 'full_inc1_%u' fileperset 4 database plus archivelog;
--backup archivelog all;
delete archivelog until time 'sysdate-4';
delete nopromp obsolete;
}

If the above backup fails for any reaon, you can use the NOT BACKED UP SINCE option on the BACKUP command (9i restartable backup feature) to continue from the point of failure. The small value of FILESPERSET is good for restartable backups. However you should note that smaller FILESPERSET produces more backup sets.

Use the following commands to re-start backups after a failure:
BACKUP INCREMENTAL LEVEL 0 DATABASE FILESPERSET 4
NOT BACKED UP SINCE TIME 'SYSDATE-1';
BACKUP ARCHIVELOG ALL;
DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7';



# Section 2 - script for other days of backup cycle
# -----------------------------------------------------
# The following commands can be run from Saturday through Thursday to take cumulative incremental backups.
# The steps are:
# - delete incrementals on disk that were taken before 7 days.
# - take differential incremental backup of complete database.
# - copy incrementals to tape.
# - backup all archiveogs that are not backed up.
# - deletes any copies of archivelog on disk older than 7 days.

run{
delete backup completed before 'sysdate-7' ;
backup incremental level 1 cumulative tag="Incremental_Oracle_Backup" filesperset 4 database plus archivelog;
--backup archivelog all;
delete archivelog until time 'sysdate-7';
}


CONCEPT NOTE ON CUMULATIVE INCREMENTAL BACKUPS: Cumulative incremental level 1 backups will backup the blocks that changed since the last level 0 backup.  Incremental backups are similar in function to archived logs and RMAN uses them in favor of archived logs during recovery. If the CUMULATIVE option was not specified, then only the blocks that have changed since the last level 1 backup will be backed up. The advantage of a cumulative backup is that only one incremental backup ever needs to be applied during recovery.

As in section 1, you can use the NOT BACKED UP SINCE option with the BACKUP command (9i re-startable backup feature) to continue from the point of failure.
Use the following commands to re-start backups after a failure:
DELETE BACKUP COMPLETED BEFORE 'SYSDATE-7' DEVICE TYPE DISK;
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DEVICE TYPE DISK DATABASE FILESPERSET 4
NOT BACKED UP SINCE TIME 'SYSDATE -1 ';
BACKUP BACKUPSET ALL; # copies backups from disk to tape
BACKUP ARCHIVELOG ALL;
DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-7';
 

Scripting in RMAN
You can integrate RMAN into operating-system command scripts, either as a call to RMAN with a command file or with in-line RMAN scripts.
It is very easy to create and replace stored scripts with RMAN. E.g.

create script alloc_disk {
# Allocates one disk
allocate channel dev1 type disk;
setlimit channel dev1 kbytes 2097150 maxopenfiles 32 readrate 200;
}

replace script rel_disk {
# releases disk
release channel dev1;
}

replace script backup_db_full {
# Performs a complete backup
execute script alloc_disk;
 backup
 .....<backup commands here>
execute script rel_disk;
}

The first 2 scripts allocate and deallocate channels respectively. The alloc_disk script additionally specifies the maximum size of backup pieces created on this channel (kbytes), the maximum number of input files that a backup will have open (maxopenfiles), and the maximum number of buffers per second which will be read from each of the input datafiles. The 3rd script calls the previously stored scripts either side of performing a backup.
Example of executing a stored script:

run { execute script backup_db_full; }

It is possible to create a job command list in a flat file and call that script from the O/S command line as an RMAN option. E.g. to call scripts stored in a file called 'weekly_cold_backup':
    % rman <other RMAN options> cmdfile weekly_cold_backup

This UNIX script, for example, shows how to work around one of RMAN's current shortcomings - its inability to receive variables.
This script shows you how to pass variables from a UNIX Korn-shell script to RMAN.

#!/bin/ksh
# Back up single tablespace to disk or tape
# Process command-line args
TargetConnStr=$1
RcvcatConnStr=$2
TapeOrDisk=$3
tablespace=$4
# need to do some parameter validation here!
${ORACLE_HOME}/bin/rman << EOF
connect target ${TargetConnStr}
connect rcvcat ${RcvcatConnstr}
run {
execute script alloc_${TapeOrDisk}_channel;
backup tablespace ${tablespace}
format '${tablespace}_%u';
execute script rel_${TapeOrDisk}_channel;
}
exit
EOF
if [ $? -ne 0 ]
then
 echo "RMAN failed to backup ${tablespace}"
else
 echo "${tablespace} backed up OK"
fi
 

Report & Listing commands

RMAN has a few maintenance commands, shown next.

RMAN> report need backup;

Display a list of files that need to be backed up based on the retention policy

RMAN> crosscheck backup;

Determines whether a backup set and its related pieces still exist on media. If a backup piece exists in the location recorded in the control file of the target database or in the optional recovery catalog, its status is marked as AVAILABLE. If it is not at the specified location, it is marked as EXPIRED.

RMAN> delete expired backup of database;
RMAN> delete backup of database;

 For Oracle9i, this command deletes the physical files associated with backup sets and datafile copies, updates their status in the control file, and removes their information from the optional recovery catalog (if one is used).
In Oracle8i and Oracle9i, backups are flagged as EXPIRED if they cannot be found at their recorded location. Deletion of EXPIRED backups removes their information from the control file and from the optional recovery catalog (if one is used). 

RMAN> create catalog;
RMAN> drop catalog;

Create Recovery Catalog.
Drops all objects associated with the recovery catalog schema.

RMAN> report need backup days 2 database;


RMAN> report need backup days 2 tablespace system;

RMAN> report obsolete;
RMAN> report unrecoverable;

To report on those datafiles that, if restored, would require application of two days (or more) worth of archived redo log files:

To generate the same report but only for SYSTEM tablespace datafiles:

To list backups considered obsolete
Reports on all unrecoverable datafiles


Could I restore, if I needed to?
restore database validate;

report schema;

Report of database schema

List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    540      SYSTEM