Backup With the Recovery Manager (RMAN for Beginners Part 1)

ORACLE.COM TECHNOLOGY NETWORK PARTNERS BUY ONLINE SUPPORT Welcome (Jordi unsubscribe | account )

Worldwide

Backup with the Recovery Manager (RMAN for Beginners Part 1)Sebastian Solberg, ORACLE Germany GmbH

Since the Oracle Recovery Manager (RMAN) ships with the database, the Online Backup and Recovery of an Oracle database is not rocket science anymore. It's actually so simple that one might askwhy more and more databases will be secured only "offline" or even completely operated without a backup.

One of the reasons may be, perhaps, that RMAN has a different interface and a different syntax than one that is used by SQL * Plus her. One finds here and there is still some resistance against theRMAN.

But especially with 10g many little things have improved in the operation of the RMAN, allowing a backup to accomplish in a short time. But not only that, but housekeeping operations of backups andarchived redo logs are set associated with the RMAN and facilitate the tasks of a DBA.

In the next tip I would like to briefly show the basis of a plate-based backup:

How easy to use RMAN

The significance of the Flash Recovery Area (FRA) for the backup

What are the general parameters you should still consider

Note: Images are visible to the tip by the mouse moves over the icon with glasses.

In order to reduce the image again, click on the image.

Minimum configuration

As can be secured with a RMAN backup only the database and all related files, but not the software, it makes sense to outsource the software on another drive RAID system, respectively.but the backup to the FRA and lie on a physically different, independent drive, LUN, or RAID array. A backup is supposed to offer protection against disk corruption, and this makes little sense if thebackup is on the same physical drive as the database to back. In small systems, while it would also extend two plates, in this case would, however, either the database or the FRA on the software / system disks.

That's why I'm in my scenario of at least 3 plates and 3 independent RAID systems.Here, the database is distributed as follows on the locations to ensure maximum safety (red marked files are not backed up by RMAN):

Location 1 (first drive as sda1) Location 2 (second disk as sda2)Location 3 (third panel sda3 for example)

Flash Recovery Area includes:

SoftwarePassword fileLogfiles / Diag directorySPFile1. Control File

2. Control FileData files (system, undo, user tablespaces)Redo Member 1

3. Control FileRedo Member 2Archived redo logsBackup

This "simple" distribution is also used if ASM is used, is recognized as "Best Practice":

Software is on the local disks

An ASM disk group contains all the information

A second group contains the ASM Disk FRA

Preparations

1. Archivelog mode

2. Enterprise Edition: Flashback mode

3. Flash Recovery Area

4. Auto Backup Control File / SPFile

For an online backup can be performed, the database is in archivelog mode.If you use the Enterprise Edition it is also recommended the Flashback mode of the database to switch, because Flashback provides some recovery operations immense time savings.configure the same course the parameters of the Flash Recovery Area.

In Enterprise Manager, these settings happen at all: "Availability" => "Recovery Settings"

2/23/2011 Backup with the Recovery Manager (RM…

oracle.com/global/de/…/index.html 1/11

The size of the FRA is placed on about 90% of the available disk capacity fixed.If multiple databases are running on the computer, it is recommended to use the same FRA. Within the FRA should only files of the Oracle database (s) are stored: In my case, a control file copy, onemember of the redo logs. The FRA will then automatically for the archived redo logs, and backups Flashbacklogs used.



RMAN stores all relevant information about the backups (the so-called recovery catalog) in the control file of the database. Since Oracle 10g, this is sufficient for nearly all backup / recoverymeasures.But if one has multiple databases or Data Guard in action, it is recommended that you use the recovery catalog its own database. This will then backup / recovery saves information about alldatabases on this and over a much longer period than is possible with the control file would be. Also because the restore of the control files and SPFile much easier.If, no separate database for the RMAN catalog, but is content, as in the example, the information in the control file, you need to activate the Auto Backup Control File and SPFile mandatory, as for mycurrent recovery should always present the final control file with all information.This is done under the Enterprise Manager: "Availability" => "Backup Settings" => "Policy"



Setting up the settings in SQL * Plus and RMAN:

$ Sqlplus / as sysdba SQL> shutdown immediate SQL> startup mount; SQL> alter database archivelog; SQL> alter database flashback on; SQL> alter database open; SQL> alter system set db_recovery_file_dest = '<path to FRA>'; SQL> alter system set db_recovery_f

Two selected backup methods

A backup is quickly set up via Database Control. There are 2 simple ways:

The Oracle Suggested Backup

A custom full backup

When custom backup just the complete database including archived redo logs will be saved in a backup set. Since the backup is to disk, it is not recommended a "compressed" to create Backup, asthis would only go to the expense of backup time. Compressed backup sets only bring a performance advantage to tape or if you want to save loads of time backup disk space.

Here, the RMAN script, which could be used with the operating system scheduler:

$ Cat backup.sc run {backup incremental level 0 database plus archivelog not backed up;}

RMAN Call:

RMAN TARGET / @ backup.sc

Important: The file of the RMAN script must have a file name extension (*. something), otherwise there RMAN issues an error message.

Of course, the whole can be easier in the Database Control: "Availability" => "Schedule Backup". The scheduling of the job takes the corresponding agent.DB Control awards while the backup or an extra TAG. Since it is the backup to provide a basis for an incremental backup, subsequent backups may take this as a basis. For this purpose, the TAGserves as a kind of reference, ie, which serves as the basis for the subsequent backup incremental level 1 backup.



However, the times of recovery are longer, if need be tightened with a restore all changes to ARCHIVELOG. For this reason, the Oracle Suggested Backup works on the basis of image copies of datafiles. These copies are the respective new backup (eg daily) recovered to date, so have that in the event of a recovery, only the archivelog in the last day for a full recovery are tightened.recovery is significantly reduced.



The backup here consists of two parts: the recovery of the image copies with the present archivelog and the incremental level 1 backup of the new changes. It is indeed at the first call in a warning(the recovery), there can be no recovery, but this is negligible. The following table illustrates the procedure when the backup runs every day:

Running Recover command Backup command

1 Nothing happens, there's no backup is availableSince no backup is available, a level 0 backup (the basis for an incremental backup) isperformed.

2Nothing happens because there is no incremental backup is available, which could beapplied

An incremental backup level 1 with the block changes from the previous day

≥ 3 Recovery of image copies, with the incremental level 1 backup from the previous day An incremental backup level 1 with the block changes from the previous day

Here, the RMAN script to do this:

run {recover copy of database with tag 'daily image'; backup incremental level 1 cumulative for recover of copy with tag 'daily image' database;}

Whether now be used one or both options for the backup - at least we have with these few steps already created a good basis for data security.

Flashback Recovery Area (FRA)

Basically you have to backup and furnished with enough space for the FRA to worry about a Housekeeping. What does it now enough space?

Based on the considerations for backup from the previous one part lies with the following value on the "safe" side:Database 2x + (2x archived redo logs per day) * Flashback Retention Time (days) + online redo logs + Control File

The default settings for RMAN ensure that no more necessary files are automatically deleted from the FRA. These are the settings of the "RETENTION POLICY" and "ARCHIVELOG DELETIONPOLICY. The standard requires that (ie to perform a complete recovery), all necessary files for a backup present. Older backups are set to obsolete and automatically deleted if space is needed.the same in the archivelog deletion policy, if it is on the default "None". Archivelog all that

been secured are at least 1x

No longer are needed for a recovery of the last backup

are not required to guarantee the flashback time or a guaranteed restore point

are set to obsolete and can be deleted automatically. If you want to still run itself the housekeeping, so you can get information about the Database Control page "Availability" => "Manage CurrentBackups" an overview and perform the deletion (Delete Obsolete).



It works naturally in RMAN:

RMAN> list backup summary; ... RMAN> delete obsolete;

Some important parameters for the backup

The main backup parameters can be in the Database Control on "Availability" => "Setup" ("Backup Settings", "Recovery Settings" and "Recovery Catalog Settings") set or configure the RMAN:

RMAN> show all; CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTO BACKUP ON; CONFIGURE CONTROLFILE AUTO BACKUP FORMAT FOR DEVICE TY

In general, the standards are quite good. Following two parameters but you should always devote some attention:

RETENTION POLICY: The retention policy, the number of full backups should be stored in the FRA or a so-called Recovery Window mentioned. Configure a recovery window, then, this"window" that any backup must be within this time frame. At the same time, this "window" so well, it is possible that this period is a Point in Time Recovery.

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

The command indicates, therefore, that all information is held to go with a Point in Time Recovery at any time, in those days. However, it should also control_file_record_keep_time theparameters of the database are taken into account. This indicates how old may be the information in the control file of the database before they are overwritten. The parameter should beadjusted to the Recovery Window. Because the control file, but only limited space for the backup is available, is recommended for larger Windows Recovery, a database for the recoverycatalog to use.

CONTROLFILE AUTO BACKUP: How are the above-mentioned set this parameter to ON, if no database for the recovery catalog is used.

A successful backup is now no more obstacles. In one of the following tips are some typical recovery scenarios are covered in this setup.

Useful links and references

Oracle documentation: Backup and Recovery User's Guide

Back to Community Page



Backup With the Recovery Manager (RMAN for Beginners Part 1)

Documents

Transcript of Backup With the Recovery Manager (RMAN for Beginners Part 1)