Some notes about the RMAN architecture, and creating the catalog

RMAN creates backups of your database. But you can use rman with multiple databases, possibly Any way, whether you use rman to backup a single database, or many databases, rman needs

a "repository" to store some vital data like which backupsets are associated to which database, the pieces that belong to the sets, and all kinds of other usefull information.

1. The target's database controlfile (belonging to the database which rman will backup)

Actually, only a separate rman tablespace and a user rman is required. So you could use an existing database for holding the rman repository. But if that database is an important Although you might not be happy to create a separate database, just for holding rman's metadata, only a very small database is required with an rman tablespace (which does not need to be

larger than 100M). Ofcourse, if a database is used as the rman catalog, much more historical Now above we said that either the target's controlfile can be used, or a separate database can be used as the rman catalog. Well, even if a catalog database is present, the controlfiles

of the targetdatabase(s) will always contain the latest rman backup information, so its actually impossible

Even stronger, the controlfile remains Authorative in the sense that this "latest info", and periodically that data But the rman catalog database can hold much more data, and more types of data, then the target's database

metadata:

what kind of backup, status, date/time etc..

The "real" data rman catalog

which is a small periodic synchronization

Oracle database

Remark: should one backup that

database as well?

Yes, an export or cold or hot

backup with sufficient frequency should be fine.

If you want you can also store scripts, which are named user-created sequences of RMAN commands

If we want a RMAN recovery catalog in a database, we follow the following steps:

2. Create a suitable tablespace, e.g. with the name "rman" and, let's say, with a initial size of 100MB.

3. Create the user "rman" which has as its default tablespace tablespace "rman"

4. Create the catalog on tablespace rman as user rman (use the "CREATE CATALOG" command).

datafile '/dbms/oradata/prodrman/rman01.dbf' size 100M reuse autoextend on next 10M maxsize 500M

The above command was step 2. Now we create the catalog owner, that is, the user rman:

On unix, make sure your environment variable ORACLE_SID points to the right Database:

(it does not always has to be in capital, maybe your database id uses small capital).

Now, to connect, or logon, to the catalog database, you use the "connect catalog" command, and pass along

A number of tables and views are installed in the database PRODRMAN, and those objects live

Those tables (and the views) have all specialized purposes to store the metadata.

You may ofcourse query the tables and the views, but you can also retrieve all kinds of reports from the RMAN> prompt (which itself does query the tables and views).

You absolutely do not have to interface to those tables and views. Just use the

As the last step we need to register the target database. In the following example

And after a little while, rman is ready storing some parameters (like the name and dbid) in the catalog.

In principle, we are ready to backup the target database. But its much better to set, or store, some default values in the catalog that has to do on how exactly we want to backup.

Note: You can also connect to the target database and the catalog database in one command, with passing to the rman executable the right credentials, as in the following example:

You are certainly not required to set defaults in rman, but some options in your scripts that you normally always would set, can just as well be put as a configurable setting.

With this series of command, you have told rman to keep all backups that are not older than 5 days, and that per default the backups will be stored to disk, and that at every backupjob, the controlfile

You could go now to the second sheet "Some_RMAN_Notes" and see if you inderstand

The above list of rman commands, are very important. The first command tells rman

Ensure that RMAN retains all backups needed to recover the database to any point in time in the last 7 days:

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default

CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'C:\ORA10G\PRODUCT\10.2.0\DB_1\DATABASE\SNCFTEST10G.ORA'; # default

Lets start with a basic backup script that really will make a complete (open) backup

From the prompt, type in those commands, and after the last "}", the script will execute.

So, from the RMAN> prompt, you can give singular commands, that is, one statement, like for example:

And you can let rman run a script by starting with "run {" followed by as series of statements.

If you take a look again at the above backupscript, you may wonder why there is no specification to where you want to backup, because you might want to choose between tape or disk.

Secondly, we do not see a "channel" alocation in the script. A "channel" is a Server session which will access the database, selects the data, and writes the data to the backuplocation.

RMAN comes preconfigured with one DISK channel that you can use for backups to disk.

Now let us take a look at a second backup script, which backups the database to tape(s).

2> allocate channel t1 type 'sbt_tape' parms 'ENV=(tdpo_optfile=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt)';

3> allocate channel t2 type 'sbt_tape' parms 'ENV=(tdpo_optfile=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt)';

In this example, you see that two channels are created before the actual backupcommands

are called. These channels will write to tape, because in the statement you might see the "sbt_tape"

Writing to disk, is easy for the Server session, because the Hosts Operating System

"knows" how to write to disks. So there will never be "difficult" parameters in the

The tapedrive or taperobot can probably only be accessed by specific third-party software.

That‟s why in the channel allocation command, you will see parameters that referr to

a certain configuration file, which will contain pointers on how to access the specilized libraries.

That‟s why you find in the allocate channel command parameters similar to this example:

allocate channel t1 type 'sbt_tape' parms 'ENV=(tdpo_optfile=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt)';

Maybe sometimes you want to change the status of a certain backup, so that it no longer Use CHANGE... KEEP or CHANGE... NOKEEP to specify whether a backup should be subject to the configured retention policy or kept until a different date or even indefinitely.

The KEEP option exempts a backup from the current retention policy either indefinitely or until the specified UNTIL time. RMAN does not mark the files as obsolete even if they would be considered obsolete under the retention policy. Such backups are called long-term backups.

CHANGE ... NOKEEP is used to undo the effects of CHANGE ... KEEP, so that the configured For example, the following command prevents RMAN from considering backupsets with the tag

To allow backupsets with the tag year_end_2002 to be marked as obsolete based

If you want to prevent the use of a backup marked with KEEP in restore and recovery operations, then mark these backups as UNAVAILABLE. RMAN will not delete the records for these backups

from the RMAN repository, but will not try to use them in restore and recovery until they are marked

With the REPORT OBSOLETE command, you can find the backupsets which are "after" the In that case, all backups that are older than 7 days are reported as obsolete.

Backup Piece 26 28-JUN-08 C:\ORACLE\FLASH_RECOVERY_AREA\TEST10G\BACKUPSET\2008_06_28\O1_MF_NNNDF_TAG2008

Backup Piece 27 28-JUN-08 C:\ORACLE\FLASH_RECOVERY_AREA\TEST10G\BACKUPSET\2008_06_28\O1_MF_NCSNF_TAG2008

Backup Piece 43 28-JUN-08 C:\ORACLE\FLASH_RECOVERY_AREA\TEST10G\BACKUPSET\2008_06_28\O1_MF_NCNNF_TAG2008

Backup Piece 44 28-JUN-08 C:\ORACLE\FLASH_RECOVERY_AREA\TEST10G\BACKUPSET\2008_06_28\O1_MF_NNSNF_TAG2008

Backup Piece 67 28-JUN-08 C:\ORACLE\FLASH_RECOVERY_AREA\TEST10G\BACKUPSET\2008_06_28\O1_MF_ANNNN_TAG2008

Backup Piece 94 28-JUN-08 C:\ORACLE\FLASH_RECOVERY_AREA\TEST10G\BACKUPSET\2008_06_28\O1_MF_NCSNF_TAG2008

An obsolete backup differs from an expired backup. An obsolete backup is no longer needed according to the user's retention policy. An expired backup is a backup that the CROSSCHECK command fails to find

Its important to realize that you can still use obsolete backups. They only fall outside your

It's necessary to maintain the catalog and delete the obsolete backups. Make sure you really want this,

List commands query the catalog or control file, to determine which backups or copies are available.

You can control how the output is displayed by using the BY BACKUP and BY FILE options of the LIST command

The primary purpose of the LIST command is to determine which backups are available. For example, you can list:

. Backups and proxy copies of a database, tablespace, datafile, archived redo log, or control file

By default, RMAN lists backups by backup, which means that it serially lists each backup or proxy copy and then identifies the files included in the backup. You can also list backups by file.

By default, RMAN lists in verbose mode. You can also list backups in a summary mode if the verbose mode

To list backups by backup, connect to the target database and recovery catalog (if you use one), and then execute the LIST BACKUP command. Specify the desired objects with the listObjList clause. For example,

By default the LIST output is detailed, but you can also specify that RMAN display the output in summarized form.

Specify the desired objects with the listObjectList or recordSpec clause. If you do not specify an object,

After connecting to the target database and recovery catalog (if you use one), execute LIST BACKUP,

You can also specify the EXPIRED keyword to identify those backups that were not found during a crosscheck:

Reports enable you to confirm that your backup and recovery strategy is in fact meeting your requirements for database recoverability. The two major forms of REPORT used to determine whether your database

Reports which database files need to be backed up to meet a configured or specified retention policy

Use the REPORT NEED BACKUP command to determine which database files need backup under a specific retention policy.

With no arguments, REPORT NEED BACKUP reports which objects need backup under the currently configured retention policy.

The output for a configured retention policy of REDUNDANCY 1 is similar to this example:

Reports which database files require backup because they have been affected by some NOLOGGING operation

You can report backup sets, backup pieces and datafile copies that are obsolete, that is, not needed to meet a specified retention policy, by specifying the OBSOLETE keyword. If you do not specify any other options, then REPORT OBSOLETE displays the backups that are obsolete according to the current

In the simplest case, you could crosscheck all backups on disk, tape or both, using any one

The REPORT SCHEMA command lists and displays information about the database files.

After connecting RMAN to the target database and recovery catalog (if you use one), issue REPORT SCHEMA

RMAN displays backups that are obsolete according to those retention policies,

"standard file", contains stuff we do not consider in this note. Contains no data of the application, but its more tool oriented.