collaborate 2012 - rman eliminate the mystery

High Availability Boot Camp: RMAN - Eliminate the Mystery

RMANRMAN -- ELIMINATEELIMINATE THETHE MYSTERYMYSTERY

Nelson Calero, UYOUG

RMAN is a must-have tool familiar to most Oracle DBAs. There are many capabilities hidden in RMAN and going beyond the basics is important.

After a quick review of the core functionality, we will discuss both old and new features and provide tips and tricks along with sample code using the Command Line Interface (CLI).

INTRODUCTION One of the most important tasks of the DBA is to ensure that production data are safe, although incidents can occur and compromise hardware, software or physical facilities. Within our Disaster Recovery and High Availability plans, one of the most important components are the backups.

RMAN functionality is implemented in the Oracle kernel, with many features to use in backup and recovery tasks, available through a PL/SQL API. The RMAN client is a command line utility included in the installation of the Oracle database, in the $ORACLE_HOME/bin directory, written in Pro*C that executes the PL/SQL API. Also there are some functionalities accessible through Enterprise Manager, and the possibility to create your own scripts calling the PL/SQL API.

The most important tasks we can perform with RMAN are:

• backup

• recovery

• failure diagnostic (from 11.1, Data Recovery Advisor functionality)

• instance duplication

• backups history

RMAN provides several additional features in addition to the obvious tasks expected of backups and recovery. From validating the logical and physical integrity of the backups to sophisticated tasks in a single command as the duplication of an instance. It also presents a lot of maturity, where there have been resolved many errors (bugs): over 170 in all versions (ref: support.oracle.com), and with few known issues remaining in the current version (MOS Note 247611.1).Additionally, each new version of the database incorporate new functionaliies or improves existing ones. For example, 11 improvements are included in version 11.2 and 21 in version 11.1 (documented in the "new features" section of each manual).

Although RMAN has been available since version 8 of the database (CLI mode), its adoption by users has been low compared to the alternative of developing scripts that perform backups manually.This article will show the advantages of using RMAN, with examples to motivate those who do not use it yet, and help leverage their capabilities to those who already use it.

1 Session #492


BACKUP POLICIES?RMAN is a tool that can be used for specific actions or to implement tasks from a backup policy. These policies are the ones who ensure that sensitive information of our organization is safe, and therefore include processes and procedures that exceed the use of a particular tool.

As an example, these include the transfer of backups to external sites, the rotation frequency of the media used to store the backups, use of encryption techniques to ensure that data is not readable by third parties in case of media devices get lost, use of additional features of the database to have redundant data to be used in case of failure, etc..

The DataPump utility, functionality such as Flashback and Secure Backup of the Oracle Database are other ingredients to include in a backup policy, that we will not see here.

ORACLE BACKUPS

The database has several files: data (datafiles), control (controlfiles), temporal (TempFiles), undo and redologs. To maintain consistency, it uses internally a number which identify transactions, called System Change Number (SCN).(http://docs.oracle.com/cd/E11882_01/server.112/e25789/transact.htm#CHDIAFFH)This number is stored in several of these files. During the opening of the database is analyzed and action is taken to ensure consistent data exist only with the last commited transaction, which corresponds to an SCN. (For more details on this operation, see note 1376995.1 Information on the System Change Number (SCN) and how it is Used in the Oracle Database).

To take a backup while the database is down, the procedure is simple: just copy all the files that composes the database to the new destination. This backup can be used later with the same result we have on the original installation when opening the database after the backup, If it is consistent, it will be consistent. If it needs to be recovered, we need to make sure we have all the necesary logs included on this copy at the destination site.This procedure is known as cold backup. It is difficult to have the option of using it in production because it implies lack of service (down time) while it runs and that may be diffcult to arrange.

When the database is running, any activity of internal processes (background) and user (server processes) can change data files. Then, copying those files from the operating system (using cp / copy) can generate copies that are not identical to the originals one, since the database blocks can be written (by the DBWR process) when trying to be read by the cp command, generating the problem known as Fractured Block (http://docs.oracle.com/cd/E11882_01/backup.112/e10642/glossary.htm#CHDBFCBF). This occurs because the OS write operations are not necessarily of the same size that the blocks used by the database (typical disk blocks are 512 bytes vs database blocks of 8 Kbytes), therefore there may be several non-atomic input/output operations for each Oracle data blocks.

Even if using ASM this copy is possible, and can run into the same problem, though with different methods depending on the version, because from 11.1 the command cp exists within the ASMCMD utility.

To avoid this problem while copying, we must tell the database that we are doing this operation through the command ALTER TABLESPACE BEGIN BACKUP <name>, and it will take precautions: to freezes the modification of the SCN in datafiles header, and to write full data block the first

2 Session #492


time a record is modified. Archivelog should be enabled on the database to use this functionality.It is necessary (and very important) to run another command to indicate the end of the copy (ALTER TABLESPACE <name> END BACKUP), and thus the database starts to operate normally.

With these actions, when using the restored backup files and open the database, the recovery process identifies that the datafiles need recovery from the moment the backup started (as the SCN in the headers is less than the last known to the controlfile), so the recovery applies the redo generated that include the complete blocks, correcting any possible inconsistencies in existing data files. For more details, see note 1050932.6 'Why Are Datafiles Being Written To DURING Hot Backup?'

This form of backup is known as hot backup, or inconsistent. This requires an additional task of recovery when used, therefore archived redologs generated until the end of the backup is needed in addition.

The following is a summary of the commands used in the two manual backup strategies (also known as user managed):

consistent (cold) inconsistent (hot) cp /u02/oradata/* dest-bkp alter tablespace nnn begin backup;

cp /u02/oradata/datafile-nnn.dbf destbkp alter tablespace nnn end backup; cp /archivelogs-path/* dest-bkp

RMAN BACKUPS

RMAN is invoked by the command line and it runs as a console waiting to execute commands.The database used to perform backup and recovery is called "target". It is necessary to connect before to start executing commands, indicating the command line parameter "target", or using the "connect" command. It can be used a database name configured using SQL*NET, or using "/" to connect to the local database. The user must have sysdba privilege, so SYS is usually used.

RMAN stores metadata about the operations performed in a repository itself, along with configuration variables in the controlfile of the target database or in a proprietary database called the catalog.

To take a backup we use the BACKUP command. It can make identical physical copies (image copies) or BACKUP SETS, a proprietary format, somewhat like TAR that can span multiple files, that stores all data backed up in one or more files, called BACKUP PIECES. The latter is preferred because it creates smaller files, as explained later.

There are several files in the database that are not required for recovery and which can be recreated without loss of information, therefore they are not copied. Also, other files that are not part of the data stored in the database are not copied either.In short, these are not copied:

• temporary files (tempfiles) and online redo logs

• files from external tabes or bfiles

• database binary files

• database network configuration files

3 Session #492


The copied files are:

• datafiles

• controlfiles

• archived logs

• spfile

Using the prior examples for manual backups, with RMAN they are as follows:

consistent (cold) inconsistent (hot):rman target / rman target / startup mount; backup database plus archivelog;backup database plus archivelog;

The difference between the scripts used for cold / hot cases is that in the first one the database must be open in at least mount mode to run the backup command. And in the second it should be in archivelog mode.

Archivelog needs to be included in a cold backup?. It depends. If the database was down normally (immediate), then it is not necessary to do recovery, and archivelogs are not necessary. If the database was closed with a "shutdown abort" command or the server was turned off, then they are required to do recovery when we attempt to open it. This is only possible if the database is in archivelog mode, because RMAN does not allow to take a backup of a closed database in an inconsistent state if it is in NOARCHIVELOG mode (http://docs.oracle.com/cd/E11882_01/backup.112/e10643/rcmsynta007.htm#CHDBIAHI).

RMAN do not have the problem of fractured blocks while copying, because it knows the format of the blocks and its contents is validated when copying, retrying the reading of those detected inconsistent. Then, the database does not need to store additional redo while taking the backup.

CONCEPTS

Now that we know how to make a backup, we must know the concepts used by RMAN:

• device: destination of the backups. It can be disk or tape (SBT).

• channels: is a connection to the database used to read data and write it to the destination device. The default value is one. Several can be used to achieve parallelism.

• Image copy: and identical copy of a single data file, archived redo log file, or control file.

• backup sets: an Oracle proprietary way of making backups, which includes all the backed up data in a TAR like format, having an internal table of contents, can span several files and loads multiple external files into one archive. It is identified by a unique number, a date and a label (TAG). It is the only format allowed to tape (SBT).

• backup pieces: are the files that make up a backupset.

4 Session #492


• backup status: Indicates whether the backup is available for use (Available) or if the file no longer exists in the destination (Expired). The latter is detected by manually running the command Crosscheck, which is not doing automatically.

• obsolete backups: those not needed to meet our retention policy. They are not deleted automatically. The commands REPORT OBSOLETE is used to see which are the files, and DELETE OBSOLETE to delete them from destination.

• incarnation: is a number associated with the instance, which changes every time it is open with resetlogs. It is important for the restore procedures, because the backups are useful only in the same line of incarnations that have the current database.

CONFIGURATION

The BACKUP command can change its behavior with configuration variables or parameters that implement extra functionality. These variables define the behavior of some commands, or defaults values when not explicitly stated.

To view these settings, there is the command "show all". These belong to the destination database to which we are connected, and they are stored in the RMAN metadata.

oracle@oraculo:~> rman target / Recovery Manager: Release 11.2.0.2.0 - Production on Thu Feb 9 16:16:00 2012 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. connected to target database: XE (DBID=2642191927)

RMAN> show all; using target database control file instead of recovery catalog RMAN configuration parameters for database with db_unique_name XE are: CONFIGURE RETENTION POLICY TO REDUNDANCY 2; CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP OFF; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # 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 ENCRYPTION FOR DATABASE OFF; # default CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/11.2.0/xe/dbs/snapcf_XE.f'; # default

The variables that we must set in order to get our backup policy are:

• Device: we will use disk or tape (SBT)? The default installation uses disk. To use tape you need to install and configure the use of a library provided by tape vendor, called media library (MML).

5 Session #492


• Parallelism: using multiple channels simultaneously for backup or restore of the base. Is defined at the DEVICE. Available in Enterprise.

• Retention Policy: For how long we want our backs available on disk?. This is controlled by setting the RETENTION POLICY, which can be defined by RECOVERY WINDOW or REDUNDANCY. The first is days during which backups must be kept, regardless of amount. The second quantity is only backrests.

• Backup optimization: Do not copy existing files identical on destination. It is useful to shorten time in operations that failed due to lack of space and can reuse the good copies when retried (eg duplication)

• Encryption: to seamlessly protect generated backups against third parties. Requires Advanced Security option for disk devices, or Oracle Secure Backup for tape devices.

Another important configuration setting is outside RMAN.

One is related to the use of the Fast Recovery Area (FRA). It is controlled by parameters in the target database: DB_RECOVERY_FILE_DEST_SIZE and DB_RECOVERY_FILE_DEST.

With the first one we can put a logical maximum to the disk space used by files inside the FRA.

This is important because archivelogs are automatically deleted when obsoleted by RMAN, so we only need to take care on proper setting its initial value, which must be big enough to allow all the files needed by our retention policy.

The other important parameter to consider when not using a recovery catalog is CONTROL_FILE_RECORD_KEEP_TIME. It defines the amount of days control file records are reused. Its default value is 7. This must be set consistent to our backup policy, to avoid lose backup records.

SEEING ITS CONTENTS

To see the generated files and their contents, use the "List backup" command. In this example, as we are not using a recovery Catalog, this information is stored in the controlfile.Adding the clause "summary" you can see a summary rather than detail.

oracle@oraculo:~> rman Recovery Manager: Release 11.2.0.2.0 - Production on Fri Feb 17 11:00:13 2012 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

RMAN> connect target connected to target database: ENT11G (DBID=410442782)

RMAN> list backup summary; List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag ------- -- -- - ----------- --------------- ------- ------- ---------- --- 1 B F A DISK 13-FEB-12 1 1 NO TAG20120213T122058 2 B F A DISK 13-FEB-12 1 1 NO TAG20120213T122238 3 B F A DISK 13-FEB-12 1 1 NO TAG20120213T122421 4 B F A DISK 13-FEB-12 1 1 NO TAG20120213T122440

To view the full content of a specific backup (to avoid seeing all cataloged backups), we can filter by backup attributes, like its label (TAG):

6 Session #492


RMAN> list backup tag TAG20120213T122058; using target database control file instead of recovery catalog

List of Backup Sets =================== BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 1 Full 1.03M DISK 00:00:01 13-FEB-12

BP Key: 1 Status: AVAILABLE Compressed: NO Tag: TAG20120213T122058 Piece Name:

/u01/app/oracle/fast_recovery_area/ENT11G/backupset/2012_02_13/o1_mf_nnndf_TAG20120213T122058_7ml72cnz_.bkp

List of Datafiles in backup set 1 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 5 Full 1044143 13-FEB-12 /u02/oradata/ent11g/prueba.dbf

In this example you can see that it is a backup of a single datafile (prueba.dbf) and was stored in the default destination (the Fast Recovery Area). This can be changed by adding the clause 'format /path-to-bkp' to the backup command.

NOTE: Dates displayed by these commands, as well as used as parameters to some commands in RMAN can be changed with the NLS_DATE_FORMAT environment variable at the operating system. For example to include the time:

[oracle@oraculo ~]$ export NLS_DATE_FORMAT='DD/MON/YYYY HH24:MI:SS' [oracle@oraculo ~]$ rman target / Recovery Manager: Release 10.2.0.3.0 - Production on Wed Dec 21 20:31:46 2011 Copyright (c) 1982, 2005, Oracle. All rights reserved. connected to target database: Ent11g (DBID=943234298)

RMAN> list backup summary tag bkp_prod_121511060003; using target database control file instead of recovery catalog

List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag ------- -- -- - ----------- -------------------- ------- ------- ---------- --- 1 B F A DISK 13/FEB/2012 03:21:03 1 1 NO TAG20120213T122058 2 B F A DISK 13/FEB/2012 03:25:42 1 1 NO TAG20120213T122238 3 B F A DISK 13/FEB/2012 03:29:28 1 1 NO TAG20120213T122421 4 B F A DISK 13/FEB/2012 03:35:17 1 1 NO TAG20120213T122440

BACKUPS WITH ORACLE XEIf you use Oracle XE, the installation includes scripts to backup and restore the database using RMAN: backup.sh and restore.sh. They are in the $ORACLE_HOME/config /scripts/ directory. They are a good starting point to take as an example and customize as you wish.

INCREMENTAL BACKUPS

In a database with several terabytes of data, a full backup can take longer that the time available for maintenance tasks. With incremental backups this time can be reduced by copying only the changed blocks since the last incremental backup.

There are two types of incremental backup: differential and cumulative.

7 Session #492


• Differential: copy only the changes since the last incremental backup

• Cumulative: copy all changes from the last full backup (level 0).

The level concept is similar to UNIX OS backup levels, but limited in the practice to 0 and 1, instead of the 0-5 for OS. This simply provides a marker for which to reach back for the increment or difference.

Therefore, to restore a database all differential backups are needed since the last full backup, or the last cumulative backup following the last full backup. Incremental backups are differential by default.

Example: the first incremental backup must be complete, and is identified with the level 0.

backup incremental level 0 tablespace users;

The next is level 1. If no level 0 backup exists when running a level 1, it creates a level 0 backup:

backup incremental level 1 tablespace users;

To take a cumulative backup:

backup incremental level 1 cumulative tablespace users;

If you have Enterprise version, you can enable the feature "Change Block Tracking" for this type of backup. It keeps a bitmap of changed blocks of the database since it was enabled, avoiding to analyze all the data blocks of the database each time the incremental backup is taken. This is more efficient in scenarios where the total amount of changes are small compared to the size of the database, so it needs to be evaluated to your specific environment. And is the way to handle bigfile tablespaces.

As an example, using Oracle Managed Files (DB_CREATE_FILE_DEST parameter), it can be enabled with this command, and then we can take the level 0 backup:

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;

Additionally, there are Incremental updated Backups, or merged incremental backups. This allows you to take an incremental backup and apply it to the last full backup for a new full backup, without reading all the destination database to create the full backup. The command to take it is:

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

This type of backup requires more disk space, because it creates a new backup file in the default destination. In the above example, only one copy is kept current at level 0, so a policy with redundancy 1 is used. If we want to use a recovery window with more available copies, it is

8 Session #492


needed to add the clause 'UNTIL TIME ..' to the recover command. For more details on this type of backup, see the Note "745798.1 Merged Incremental Backup Strategies".

COMPRESSION

There are several features in RMAN which helps in having more compact files.

The following prevents copying unnecessary blocks. They are built in and no configuration is required to activate them:

• BLOCK COMPRESSION NULL (8i) - does not backup empty blocks never used (ie: unformatted above High Water Mark (HWM))

• UNUSED BLOCK COMPRESSION (10.2) - does not backup unused blocks (ie: empty under HWM)

• UNDO OPTIMIZATION (11.1) - does not backup undo segments from commited transactions (considering UNDO_RETENTION).

A simple example to see the first optimization in action (NULL COMPRESSION) is to create a tablespace and then make a backup:

oracle@oraculo:~> du -hs oradata/XE 1.5G .oradata/XE

oracle@oraculo:~> ls -lrt /usr/lib/oracle/xe/app/oracle/flash_recovery_area/XE/backupset/2010_06_03/ total 1176688 -rw-r----- 1 oracle dba 1203748864 2010-06-03 00:57 o1_mf_nnndf_TAG20100603T005534_60g9xpkz_.bkp

The free space on the database is:

01:41:16 XE>select sum(bytes)/1024/1024 mb from dba_free_space;

MB ---------- 135.8125

Considering that RMAN does not include tempfiles nor redologs, 1.1Gb data were copied with RMAN against 1.5Gb which they had copied manually.

The last feature, binary compression, must be explicitly enabled:

• Binary COMPRESSION (10g) - Compress data before sending it to the destination. It supports incremental backups. Algorithm can be changed using the Advanced compression option (11.2)

9 Session #492


There are two ways to take compressed backups: set it as the default method, or explicitly stated in the BACKUP command.

a) Backup as compressed backupset …

b) CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;

The generated files are much smaller (from 1.1G to 200M), at the expense of using more CPU:

-rw-r----- 1 oracle dba 1203986432 2010-06-03 01:31 o1_mf_nnndf_TAG20100603T013020_60gcywnl_.bkp -rw-r----- 1 oracle dba 235642880 2010-06-03 01:38 o1_mf_nnndf_TAG20100603T013720_60gdd066_.bkp

COMPRESSION WITH ORACLEXE

The script backup.sh does not have a parameter to create compressed backups. Also, if we configured compression as our database default method (configure device...) It won't be used because the script includes clauses which take precedence.

This choice can be justified because the maximum amount of data handled by XE is 11GB, and with actual disk this size is not a problem, nor time required to manipulate this volume.

Furthermore, the same script backup.sh sets redundancy to 2. This ensures that we always have a valid backup available, but not more than two. Then compression is even less necessary.

Both can be adjusted according to our policy, simply by modifying this script.

As an example, we take a backup without compression and with the compression setting:

a) rman target / CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET; exit; ./backup.sh

b) rman target / CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET; exit ./backup.sh

Once they finish, both generated files are identical:

ls -lrt /usr/lib/oracle/xe/app/oracle/flash_recovery_area/XE/backupset/2010_06_03/

10 Session #492


-rw-r----- 1 oracle dba 1203748864 2010-06-03 00:57 o1_mf_nnndf_TAG20100603T005534_60g9xpkz_.bkp-rw-r----- 1 oracle dba 1203986432 2010-06-03 01:31 o1_mf_nnndf_TAG20100603T013020_60gcywnl_.bkp

Reviewing the content of the backup.sh script, we found:

echo "Backup in progress..."

rman target / >> $rman_backup << EOF set echo on; shutdown immediate; startup mount; configure retention policy to redundancy 2; configure controlfile autobackup format for device type disk clear; configure controlfile autobackup on; sql "create pfile=''$rman_spfile2init'' from spfile"; backup as backupset device type disk database; configure controlfile autobackup off; alter database open; delete noprompt obsolete;

EOF

The backup command explicitly includes parameters that indicate how to take backup, so it does not consider the default values. If we are interested on taking compressed backups, we must modify the code of the backup.sh script and include this explicitly:

... backup as compressed backupset device type disk database;

...

INTEGRITY VALIDATION

By default, the BACKUP command validates block checksum when writing to destination (physical integrity). Additionally, there are commands to validate logical integrity when taking the backup, or directly on the data without the need for a backup, or over already taken backup files.

To detect logical corruption in data blocks while taking the backup, the "check logical" clause must be included :

backup blocks all check logical database;

To validate already taken backups, and their availability for the restore operation, the “validate” clause must be included:

11 Session #492


restore validate database;restore validate controlfile to 'c:\temp\control01.ctl';restore validate archivelog from sequence N1 until sequence N2;

Since version 11.1 we have the command VALIDATE,so this can be done independently of the tasks of backup / recovery, with a variety of options that allows for example: validaing the entire database, a specific backup, a datafile, and only a few blocks from a datafile:

validate database;VALIDATE BACKUPSET 5;validate datafile 3;validate datafile 3 BLOCK 5 TO 20;

Also we can optimize validations executing it on parallel, distributing reading task over several channels, taking advantage of the new parameter in 11.1 SECTION SIZE, which enables to split the reading of a single datafile in smalls chunks:

RUN{ ALLOCATE CHANNEL n1 DEVICE TYPE DISK; ALLOCATE CHANNEL n2 DEVICE TYPE DISK; VALIDATE DATAFILE 3 SECTION SIZE 1024M;}

RECOVERY

There are several critical components in the database, and in case of isolated or combined failures, there are many different scenarios and steps needed to recover the database to a consistent state. In the official documentation there are 2 basic and 12 advanced cases.

To get just an overview on the subject, included here are only basic cases:

• recover the last full backup, using the existing controlfile:

RMAN> STARTUP MOUNT; RMAN> RESTORE DATABASE; RMAN> RECOVER DATABASE; RMAN> ALTER DATABASE OPEN;

• recover only one tablespace in an open instance:

RMAN> SQL 'ALTER TABLESPACE mytbs OFFLINE IMMEDIATE'; RMAN> RESTORE TABLESPACE mytbs; RMAN> RECOVER TABLESPACE mytbs; RMAN> SQL 'ALTER TABLESPACE mytbs ONLINE';

It is important to note that:

• recovery uses backups known by the instance (cataloged), leaving in our hands ensuring consistency with what we have available. This involves the tasks of obtaining appropriate

12 Session #492


backups from our archived media (tapes, DVD, etc), use the right controlfile for the set of backups to be used, and catalog them in the destination database (either controlfile or catalog).

• backups are useful only in the same line of incarnations known by the current database, so the controlfile to use is critical.

• recovery is to a point in time, so we must have the appropriate sequence of full backups and archivelogs (or incremental backups) to reach to the required point. In high-volume databases, to detect that this is not working may take several hours, so it is imperative to have a periodic test of these procedures, to anticipate any failures at a time where we have time to analyze and correct them without pressure.

¿WHAT TO DO IF I STILL DO NOT USE RMAN?After seeing the advantages of RMAN and the time we can save by adding it to our backup policy, we have to plan the steps to get started.

The first is to define the policy, including the following:

• acceptable level of service:

• time frame for implementation and execution

• disk consumption and CPU usage expected to define the use of compression

• retention

• destination

• generated file names

• use of parallelism

• maximum sizes of files generated

• use of encryption

With these definitions, the RMAN environment must be configured at each database. A script can be created to perform this configuration, and although it will be used only the first time RMAN be used by our database, it will serve as a backup of the configuration and will be part of the process of recreating the database on a new server .

Then it should implement the scripts that run the backup. They should incorporate controls to be complete, and in addition to the statements that actually take the backup, should include:

• Delete obsolete backups

• List catalog (documentation)

• Validate logical integrity

• Detect errors in the execution of the script and notify operators

Once the backups are working, we must remember that you must practice the various recovery scenarios, and run backups regularly taken to validate that there are no errors in the process, or on the destinations where they reside (tapes, CD, external drives, etc..).

13 Session #492


NOTE: remember that the RMAN-generated files are not portable between platforms, so a backup taken on Intel 32-bit (x86) can not be restored on Intel 64-bit (x86_64). There is an RMAN command , CONVERT DATABASE, which works only over platforms which share the endian format. Details of this on “Transporting Data Across Platfroms”, http://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmxplat.htm#CHDFHBFI

ADITIONAL TASKS

MONITORING

To validate the progress of a backup operation, the view V$SESSION_LONGOPS may be used while the operation is running, with a query like this:

SELECT SID, SERIAL#, CONTEXT, SOFAR, TOTALWORK, ROUND(SOFAR/TOTALWORK*100,2) "%_COMPLETE"FROM V$SESSION_LONGOPSWHERE OPNAME LIKE 'RMAN%'AND OPNAME NOT LIKE '%aggregate%'AND TOTALWORK != 0AND SOFAR <> TOTALWORK;

To see the result of executed commands in RMAN since the last start of the base, the view V$RMAN_OUTPUT may be used, which exists only in memory.To view the status of the tasks performed or in progress, there is the view V$RMAN_STATUS.

To view the backups that have been taken on the current database, we may use the views:

• V$BACKUP_SET

• V$BACKUP_SET_DETAILS

• v$BACKUP_DATAFILE

• V$RMAN_BACKUP_JOB_DETAILS

If using a catalog, then there is more metadata available in RC_* views.

Finally, after running the command VALIDATE, if bad blocks are detected they appear in the system view V$DATABASE_BLOCK_CORRUPTION.

MANTEINANCE

Our backup scripts should include crosscheck statements to detect backup files deleted outside RMAN, and statements to periodically delete obsolete backups.Both statements may be included in our backup script daily or weekly, or run separately.

In the case of having a standby database, from version 11.1 the deletion of obsolete can be done

14 Session #492


immediately to the back, having set the ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY. In previous versions, the deletion of archivelogs must be separated from the backup to ensure that archivelogs can be sent to the standby before being deleted.

if using the Fast Recovery Area, archivelogs are automatically deleted when obsoleted by the retention policy. Also there are disk quota rules for deletion when free space is needed, who can decide to delete files which are not obsoleted but has been backed up. For more details about this, http://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmcncpt.htm

WHEN ERRORS

The most common errors with RMAN are caused by recovery procedures using incorrect backup files or controlfiles, such as:

RMAN-03002: failure of restore command at 12/20/2011 08:08:22RMAN-06026: some targets not found - aborting restoreRMAN-06023: no backup or copy of datafile 17 found to restore

In case of errors that put health of our procedures in doubt, the first thing to do is to validate that we are doing the right thing by checking the official documentation (http://otn.oracle.com) and My Oracle Support (http://support.oracle. com).

If you already did that and want to analyze the steps RMAN took to get the error, then you can enable DEBUG in backup / restore commands, and use TRACE to see the channel's activity:

rman target / log rman.log trace rman.trc run{ allocate channel t1 type sbt………trace=2; allocate channel t2 type sbt………trace=2; allocate channel t3 type sbt………trace=2; debug on; restore database; debug off; }

Thus we see all the internal operations performed by RMAN that can serve as a guide to track the problem.

To address problems with the use of tape devices, it must be remembered that Media manager libraries (MML) are from third parties, and therefore can not be controlled with RMAN commands, We must review the documentation provided by the manufacturer.Enabling trace on the channel generates a file called sbtio.log, with information generated by the MML. This must be validated with the manufacturer.Another alternative is to use the simulation driver provided by Oracle, DISKSBT:

run {

15 Session #492


allocate channel t1 type sbt parms 'SBT_LIBRARY=oracle.disksbt,ENV=(BACKUP_DIR=d:\temp)' trace=2; backup database; }

This way it will rule out that the problem is in the read operation or at our instalation, thus we can advance in the diagnosis and if necessary pass the problem to the manufacturer of the tape drive.

OPTIMIZATION

Server running RMAN tasks increases mainly its I/O activity, so we should look to optimize the access time to devices.

The points to check are:

• using async I/O (O.S. configuration)

• adequate parallelism (channels) to amount of tapes slots of the hardware

• performance of the MML

• identify whether the problem is in reading or writing.

• for example, comparing the time of "backup validate" (read-only operation) with the time of backup.

• if using incremental backups and Enterprise Edition, enable block change tracking.

• to know the RMAN process architecture in detail helps in the optimization process. The MOS note 360443.1 "RMAN Backup Performance" goes deeper on it.

• to use the standby database if Active DataGuard is available.

Since version 11.1 SECTION SIZE parameter exists, which allows to generate a backup piece of a single datafile using smaller chunks (sections) in parallel, thus produce it in less time.For example, to back up a tablespace with a datafile of 900Mb using three parallel channels:

CONFIGURE DEVICE TYPE sbt PARALLELISM 3;CONFIGURE DEFAULT DEVICE TYPE TO sbt;RUN { BACKUP SECTION SIZE 300M TABLESPACE prueba;}

For recovery operations, we must remember that the content of the scripts are executed serially. For example, if we want to leverage that we have three tape drives and want to access them in parallel, this sequence does not succeed:

run { allocate channel t1 type sbt....; allocate channel t2 type sbt....; allocate channel t3 type sbt....; restore datafile 2; restore datafile 3;

16 Session #492


restore datafile 5; restore datafile 7; restore datafile 11; }

Since the smallest unit of reading up to 11.1 was the datafile, the way of using channels in parallel is:

run { allocate channel t1 type sbt....; allocate channel t2 type sbt....; allocate channel t3 type sbt....; restore datafile 2,3,5,7,11; }

BACKUP REPOSITORY (CATALOG) EXTERNAL

We can configure a database which is used exclusively as a repository of all information maintained by RMAN. If you manage a single database, this can add a task management too. But if you work with many, it gives us the possibility to have this information centrally.

FEATURES AVAILABLE ON ENTERPRISE EDITION ONLY

Remember that the following features are not available in Standard Edition:

• allocate disk parallel channels

• block change tracking

• encryption -- Advanced Security option or Oracle Secure Backup license

EXAMPLES

Here are some examples of using RMAN for specific tasks:

CLONING

Rman has the DUPLICATE command wich automates the process of creating a clone of a database. Since version 11.2 there are many ways to clone a database: from active database, and from pre-existing backups. This last one also could be connected or not to a target database, and to a catalog. All the details about this can be found in the manual: http://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmdupdb.htm

As an example, we will see how to duplicate a database to a remote host with the same directory structure, in 10g and in 11.2, assuming Oracle Net Connectivity has been already configured on the new server to the source database.

17 Session #492


10G CLONING

These steps must be performed to implement a clone that can be automated without manual intervention. Remember that the database created by cloning is done over the AUXILIAR connection, and the source database is the RMAN TARGET connection.

1. set destination database environment: parameter file, password file and directories

2. reboot the destination database in nomount mode

3. get the SCN to which you want to restore from the source database. There are several ways to do it. One possible is to look past SCN backed archivelogs with the following query:

select next_change#from v$archived_logwhere recid = (select max(recid) from v$archived_log

where backup_count>0);

4. execute the duplication on destination server:

rman catalog rman/clave@rman target sys/clave@origenconnect auxiliary /run { allocate auxiliary channel dupdb1 type disk; set until scn $MAX_SCN; duplicate target database to COPIA NOFILENAMECHECK;}

5. disable archivelog on the cloned database

ONLINE CLONING (> 11.1)

Same 1 and 2 steps, and the 4th is:

rman nocatalog target sys/clave@origenconnect AUXILIARY sys/clave@copiarun { DUPLICATE TARGET DATABASE TO 'COPIA' FROM ACTIVE DATABASE PASSWORD FILE SPFILE NOFILENAMECHECK SET SGA_TARGET=1000M;}exit;

18 Session #492


CLONING A RAC DATABASE

Cloning a database in a RAC environment is similar to the single instance procedure, with the following changes:

• pfile on destination database is configured as single instance (removing RAC configuration)

• clone the same way as single instance

• pfile parameters are adjusted, adding RAC settings removed before, and putting the correct names for the control_files and the new database.

• restart the database to use the new parameters

• configure the new database in all the remaining RAC nodes: pfile, pwfile, tnsnames.ora

• once cloned, you must register the new database in CRS

Details of this procedure can be found in My Oracle Support notes 461479.1 and 452868.1

DATA RECOVERY ADVISOR

This functionality, available since version 11.1, analyze failures on the database and recommends actions to correct them, having the possibility to execute the recommended scripts.

In this example we simulate the loss of a datafile:

oracle@test:> rm /u01/app/oracle/oradata/test11/users01.dbf

oracle@test:> rman target /Recovery Manager: Release 11.2.0.1.0 - Production on Thu Jun 3 14:07:35 2010Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.connected to target database: TEST11 (DBID=3428713062)

RMAN> validate database;

Starting validate at 03-JUN-10using target database control file instead of recovery catalogallocated channel: ORA_DISK_1channel ORA_DISK_1: SID=68 device type=DISKRMAN-06169: could not read file header for datafile 4 error reason 5RMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571: ===========================================================RMAN-03002: failure of validate command at 06/03/2010 14:07:50RMAN-06056: could not access datafile 4

RMAN> list failure;

List of Database Failures=========================Failure ID Priority Status Time Detected Summary---------- -------- --------- ------------- -------

19 Session #492

mailto:oracle@test


122 HIGH OPEN 03-JUN-10 One or more non-system datafiles are missing

RMAN> advise failure all;

List of Database Failures=========================Failure ID Priority Status Time Detected Summary---------- -------- --------- ------------- -------122 HIGH OPEN 03-JUN-10 One or more non-system datafiles are missing

analyzing automatic repair options; this may take some timeusing channel ORA_DISK_1analyzing automatic repair options complete

Mandatory Manual Actions========================no manual actions available

Optional Manual Actions=======================1. If file /u01/app/oracle/oradata/test11/users01.dbf was unintentionally renamed or moved, restore it

Automated Repair Options========================Option Repair Description------ ------------------1 Restore and recover datafile 4

Strategy: The repair includes complete media recovery with no data loss Repair script: /u01/app/oracle/diag/rdbms/test11/test11/hm/reco_2784754173.hm

The repair script has the following code:

# restore and recover datafilesql 'alter database datafile 4 offline';restore datafile 4;recover datafile 4;sql 'alter database datafile 4 online';

These steps are correct because we have a cataloged backup on our database, and available.

If this were not the case, the recommendation would be different:

analyzing automatic repair options; this may take some timeusing channel ORA_DISK_1analyzing automatic repair options complete

Mandatory Manual Actions========================

20 Session #492


1. If file /u01/app/oracle/oradata/test11/users01.dbf was unintentionally renamed or moved, restore it2. If you have an export of tablespace USERS, then drop and re-create the tablespace and import the data.3. Contact Oracle Support Services if the preceding recommendations cannot be used, or if they do not fix the failures selected for repair

Optional Manual Actions=======================no manual actions available

Automated Repair Options========================no automatic repair options available

Back to the first case, having the backup known to the catalog, we accept to execute the recommendation:

RMAN> repair failure;

Strategy: The repair includes complete media recovery with no data lossRepair script: /u01/app/oracle/diag/rdbms/test11/test11/hm/reco_3604648805.hm

contents of repair script: # restore and recover datafile sql 'alter database datafile 4 offline'; restore datafile 4; recover datafile 4; sql 'alter database datafile 4 online';

Do you really want to execute the above repair (enter YES or NO)? Yes

executing repair script

sql statement: alter database datafile 4 offline

Starting restore at 03-JUN-10using channel ORA_DISK_1channel ORA_DISK_1: starting datafile backup set restorechannel ORA_DISK_1: specifying datafile(s) to restore from backup setchannel ORA_DISK_1: restoring datafile 00004 to /u01/app/oracle/oradata/test11/users01.dbfchannel ORA_DISK_1: reading from backup piece /u01/app/oracle/flash_recovery_area/TEST11/backupset/2010_06_03/o1_mf_nnndf_TAG20100603T140513_60hr69ob_.bkpchannel ORA_DISK_1: piecehandle=/u01/app/oracle/flash_recovery_area/TEST11/backupset/2010_06_03/o1_mf_nnndf_TAG20100603T140513_60hr69ob_.bkp tag=TAG20100603T140513channel ORA_DISK_1: restored backup piece 1channel ORA_DISK_1: restore complete, elapsed time: 00:00:01Finished restore at 03-JUN-10

Starting recover at 03-JUN-10using channel ORA_DISK_1

21 Session #492


starting media recoverymedia recovery complete, elapsed time: 00:00:00

Finished recover at 03-JUN-10sql statement: alter database datafile 4 onlinerepair failure complete

NEXT STEPS?This paper provides a guide to start using RMAN. There are many areas to expand. The following are some suggestions to continue:

• Exercise recovery scenarios separating roles of DBA's with one group generating failures and the other trying to fix them.

• Using Enterprise Manager (EM). Many common operations with RMAN have their own screens inside EM (ie: cloning, backup), so it is recommended to move as much as possible of our backup policy to EM to take advantage of its reporting mechanisms, alerting and centralized management.

• Learn and incorporate additional high availability functionalities included on Oracle databases, such as Dataguard and Flashback.

REFERENCES Oracle® Database Backup and Recovery Basics - 10.2

http://download.oracle.com/docs/cd/B19306_01/backup.102/b14192/toc.htm

Oracle® Database Backup and Recovery Advanced User's Guide - 10.2

http://download.oracle.com/docs/cd/B19306_01/backup.102/b14191/toc.htm

Oracle® Database Backup and Recovery User's Guide – 11.2

http://download.oracle.com/docs/cd/E11882_01/backup.112/e10642/toc.htm

What's New in Backup and Recovery?

11.1 - http://docs.oracle.com/cd/B28359_01/backup.111/b28270/wnbradv.htm

11.2 - http://docs.oracle.com/cd/E24693_01/backup.11203/e10642/wnbradv.htm

MOS note 360443.1 - RMAN Backup Performance

MOS note 740911.1 - RMAN Restore Performance

MOS note 1116484.1 - Oracle Support Master Note For Oracle Recovery Manager (RMAN)

22 Session #492

collaborate 2012 - rman eliminate the mystery

Technology

oracle backupsthe database

rman functionality

data files

database blockscan

backup policy

new version

backup andrecovery tasks

secure backup