Ioug tip book11_gunukula

Understand the Power of Oracle RMAN
By Satishbabu Gunukula

This article addressees anyone using RMAN with an Oracle database
version 10g+. Throughout my experience, I have seen many situations
where DBAs end up with a failed recovery of a database because they did
not know what was backed or what is needed for a backup. Many users
are posting the same RMAN-failure related questions in the My Oracle
Support and Oracle Technology forums.

Oracle RMAN Reporting
For any company, the most important asset is data, and the most challenging
job is to recover the database with less downtime while eliminating data
loss in the event of a database failure. You should ensure that your database
is backed up efficiently and able to be restored. RMAN reporting
provides the most effective and the easiest way to determine the best
database backup strategy for a successful recovery.

In general, when using an RMAN catalog, the catalog view contains the
metadata of all databases. This would require a complex query to extract
usable backup information, but with RMAN reporting you can obtain the
same information with LIST and REPORT commands. RMAN reporting
has been enhanced from version to version, and now you can determine
which database files have not been backed up and preview the backups
required for a successful restore.

As part of your backup and recovery strategy, you should periodically run
reports that indicate:
1) what you have backed up;
2) which datafiles need backups or which files have not been backed up to
satisfy retention and recovery policies;

IOUG TIPS & BeST PracTIceS BOOKLeT | 47
Reprinted with permission from Select Journal, the official publication of the Independent Oracle Users Group,
Chicago, Illinois. Visit www.ioug.org for more publication and membership information. All rights reserved.

3) which backups RMAN would need to restore if a problem occurs; and
4) historical information about RMAN jobs.

What Do You Have Backed Up?
To know what you have backed up, use the LIST command to get the lists
of backups, copies and other objects relating to backup and recovery (e.g.,
backups that are expired or restricted).

For example, you can list backups of all files in the database.

RMAN> LIST BACKUP OF DATABASE;

You can list a copy of specified datafile.

RMAN> LIST COPY OF DATAFILE ‘/oradata/users01.dbf';

Besides backups and copies, the RMAN can list other types of data using
the LIST command, and it supports a number of options that enable you
to control how output is displayed.

For example, you can list restore points known to the RMAN catalog for
this database.

RMAN> LIST RESTORE POINT;

You can list the names of recovery catalog scripts created with the
CREATE SCRIPT or REPLACE SCRIPT command.

RMAN> LIST SCRIPT NAMES;

You can list all of the expired backup sets.

48 | INdePeNdeNT OracLe USerS GrOUP www.IOUG.OrG

RMAN> LIST EXPIRED BACKUP SET;

Which Datafiles Need a Backup?
To know which files need to be backed up, the REPORT command
analyzes the available backups in the RMAN catalog repository and returns
results about which files need a backup, which files have had unrecoverable
operations on them and which files are obsolete.

Use the REPORT NEED BACKUP command to determine which database
files need backup under a specific retention policy. For example, display
objects requiring backup to satisfy a recovery window-based retention policy.

RMAN> REPORT NEED BACKUP RECOVERY WINDOW OF n DAYS;

Use the REPORT UNRECOVERABLE command to determine which
database files need a backup when a database file has been affected by
unrecoverable operation, such as insert with no logging or direct-path
insert. Normal media recovery cannot be used to recover the file because
an unrecoverable operation does not generate redo log entries resulting in
them not being captured in the archived redo. You must perform either
a full or incremental backup of the affected datafiles after no logging
operations to ensure that data blocks affected by the unrecoverable
operation can be recovered using RMAN.

For example, identify the datafiles affected by an unrecoverable operation.

RMAN > REPORT UNRECOVERABLE;

You should also know which backups are obsolete according to the retention
policy and can therefore be deleted. A database can be unresponsive as well
as exhibit performance issues when it runs out of room at the disk level.


The CROSSCHECK command is used to update the status of backups
in the RMAN repository compared to their backup status on disk or
tape. Running the REPORT OBSOLETE command identifies which
backups are obsolete and are no longer needed for recovery. When scripting
DELETE OBSOLETE commands, you will need to add the NOPROMPT
keyword so the script won’t stop and wait for your response.

For example, crosscheck all backups and copies on the disk.

RMAN>CROSSCHECK BACKUP DEVICE TYPE DISK;
RMAN> CROSSCHECK BACKUP;

Identify which backups are obsolete and no longer needed for recovery.

RMAN> REPORT OBSOLETE;

Delete obsolete backup information from RMAN repository.

RMAN> DELETE OBSOLETE;
RMAN> DELETE NOPROMPT OBSOLETE;

This way you can effectively manage the backups and space.

Which Backups RMAN Would Need to Be Restored if Problems Occur?
Use RESTORE... PREVIEW to know which backups would need to be
restored if a problem occurs. The RESTORE…PREVIEW command does
not actually restore; rather, it identifies the backups required to complete
a given restore operation based on the information in the repository. This
command ensures that all required backups are available or identifies the
backups required for successful recovery. In case a backup is unavailable,
use the CHANGE…UNAVAILABLE command to mark the backup status
to UNAVAILABLE and re-run the RESTORE…PREVIEW to see


the backups required to perform a restore operation without using the
unavailable backup.

You can use RESTORE…VALIDATE HEADER as an alternative to
RESTORE…PREVIEW. In addition to listing of the files needed for
restore and recovery, this command validates the backup file headers to
determine whether the files on disk or in the media management catalog
correspond to the metadata in the RMAN repository.

For example, identify the backups required to complete a database restore.

RMAN> RESTORE DATABASE PREVIEW;

Use the REVIEW...SUMMARY command to summarize the lengthy output.

RMAN> RESTORE DATABASE PREVIEW SUMMARY;

The RESTORE... PREVIEW RECALL can be used in case a restore fails
due to a needed backup not available on a local drive. Using this RECALL
mode with a media manager that supports vaulted (secure offsite storage)
backups simplifies the RECALL operation by recalling the backups that are
needed for restore from remote storage.

For example, to recall backups stored offsite, use:

RMAN>RESTORE DATABASE PREVIEW RECALL;

You can also use RMAN validation to be sure they can be used for a
restore. (For example, check for block corruption and missing backup sets.)
The RESTORE…VALIDATE command tests whether you can restore
from a particular backup and validates the restore of the backup control
file, SYSTEM tablespace and all archived logs related to that backup set.


For example, to validate RMAN backups, use:

RMAN> RESTORE DATABASE VALIDATE;

By default, VALIDATE does not check for logical corruption.
To identify logical corruption, use the CHECK LOGICAL clause
with RESTORE…VALIDATE command, which populates the
V$DATABASE_BLOCK_CORRUPTION view.

Historical Information About RMAN Jobs
In some cases, the V$ views supply information that is not available
through use of the LIST and REPORT commands. You should
periodically run the reports to obtain historical information about RMAN
jobs. For example, you may want to know how many backup jobs have
been issued, the status of each backup job (i.e., whether it failed or
completed), when a job started and finished and what type of backup
was performed.

The following query shows the failed backup jobs for a particular time period.
Use the query in a script to generate a weekly or monthly report. These types
of queries are run against the RMAN catalog repository database.

SQL>select DB_NAME, START_TIME, END_TIME, OBJECT_TYPE, STAMP, STATUS
from RC_RMAN_STATUS
WHERE OBJECT_TYPE IN ('DB FULL','ARCHIVELOG','DATAFILE FULL')
and START_TIME > to_date('08-01-2011','MM-DD-YYYY')
and START_TIME < to_date('08-07-2011','MM-DD-YYYY')
and STATUS='FAILED'
order by START_TIME;

You can also use the example code that follows in your backup script to
report the backup job failure errors immediately instead of after the backup
job is finished.


V_LOGFILE=/backup/RMAN/pindbts_hotbackup.log
ERRORS=`cat $V_LOGFILE | grep "RMAN-"| wc -l`
if [ $ERRORS -gt 0 ]; then
echo `cat $V_LOGFILE | grep "RMAN-"` | mailx -s "Database Backup Failed" dba@company.com
fi
Where V_LOGFILE is the backup log generated by your backup script.

The views V$RMAN_BACKUP_JOB_DETAILS and V$RMAN_
BACKUP_SUBJOB_DETAILS provide details about RMAN backup jobs.

RMAN reporting has been enhanced through the V$VIEWS from version
to version. Backup operations are more transparent. DBAs can now easily
embed queries to these views in SQL scripts to generate historical reports.
These reports help to analyze the issues and provide information to come
up with the correct action plan to prevent further failures.

All the recovery catalog views have corresponding underlying V$ views:

Recovery Catalog View Corresponding V$ View
--------------------- ------------------------------------
RC_RMAN_BACKUP_JOB_DETAILs V$RMAN_BACKUP_JOB_DETAILS
RC_RMAN_OUTPUT V$RMAN_OUPUT
RC_RMAN_STATUS V$RMAN_STATUS
RC_BACKUP_DATAFILE V$BACKUP_DATAFILE
RC_BACKUP_FILES V$BACKUP_FILES
RC_BACKUP_CORRUPTION V$BACKUP_CORRUPTION
RC_RMAN_STATUS V$RMAN_STATUS
RC_RMAN_CONFIGURATION V$RMAN_CONFIGURATION

Enhanced V$ Views from Oracle 10g+
The V$RMAN_STATUS view shows the status of completed and
running RMAN jobs. The running RMAN job information is stored
in memory. Once the job is completed, the information is stored in the
control file. That information is kept in the control file for the length
of time specified in the initialization parameter CONTROL_FILE_
RECORD_KEEP_TIME. My Oracle Support document 397269.1,


CONTROL_FILE_RECORD_KEEP_TIME should be higher than the
RMAN retention policy with a suggested formula:

CONTROL_FILE_RECORD_KEEP_TIME = retention period + level 0 backup interval + 1

The following query shows the status of completed, completed with errors,
failed and running RMAN jobs.

SQL> select OPERATION, START_TIME, END_TIME, OBJECT_TYPE, STATUS
from v$RMAN_STATUS order by START_TIME;

OPERATION START_TIME END_TIME OBJECT_TYPE SESSION_
STAMP STATUS
---------------- ----------------------------- ----------------------------- ----------------
--- ------------------------ ---------------------------
RMAN 09/20/2009 20:00:06 09/20/2009 20:01:21
698172917 COMPLETED
BACKUP 09/20/2009 20:00:09 09/20/2009 20:01:06 DB FULL 698172913
COMPLETED
BACKUP 09/20/2009 20:01:11 09/20/2009 20:01:21 ARCHIVELOG 698172917
COMPLETED
RMAN 09/20/2009 20:05:03 09/20/2009 20:05:28
698172924 COMPLETED WITH ERRORS
FAILED
RMAN 09/20/2009 20:10:15 09/20/2009 20:10:47 698172938
RUNNING
RUNNING

You can find out the errors using the V$RMAN_OUTPUT view. The
V$RMAN_OUTPUT view is an in-memory view that shows the output
of all currently running, recently completed and any failed RMAN jobs.
The following query shows the output of a RMAN job. Notice that the
SESSION_STAMP comes from the V$RMAN_STATUS output in the
previous command above.


SQL> Select OUTPUT from V$RMAN_OUTPUT where SESSION_STAMP='698172913';

OUTPUT
-----------------------------------------------------------------
connected to target database: PINDBTS (DBID=3952868985)

executing command: SET SNAPSHOT
using target database control file instead of recovery catalog
snapshot control file name set to: /backup/dvtestrac01/RMAN/pindbts1/snapcf.f
new RMAN configuration parameters are successfully stored

allocated channel: d1
channel d1: sid=311 instance=pindbts1 devtype=DISK

sql statement: alter system archive log current

Starting backup at 21-SEP-09
channel d1: starting full datafile backupset
channel d1: specifying datafile(s) in backupset
including current control file in backupset
channel d1: starting piece 1 at 21-SEP-09

---- (Some detail removed for brevity) ----

Finished backup at 21-SEP-09
released channel: d1

95 rows selected.

The V$BACKUP_FILES view simulates the LIST BACKUP and LIST
COPY RMAN commands. This view also provides the information used
as the basis of the REPORT OBSOLETE command. Now you can get
the exact physical size of the backup set from BS_BYTES column, as the
BYTES column shows the size of the physical file.

Other Tips and Tricks Using RMAN
Restoring a Never-Backed-up Datafile
Recovery in this situation can come from the combination of online redo
and available archived logs.


Note: Try this in a test environment, as it may leave your database in an
unusable state.

Remove any online backups. You can temporarily move the backup
directories to a location unknown to RMAN. You already have an existing
database account with logon; create table privileges to do the test with.
This database is in archivelog mode:

SYS@ORCL>show parameter create_file
SYS@ORCL>db_create_file_dest string /u01/oradata
SYS@ORCL> create tablespace tbs_from_online;
SYS@ORCL> alter user testcaseuser quota unlimited on tbs_from_online;
SYS@ORCL> alter user testcaseuser default tablespace tbs_from_online;
TESTCASEUSER@ORCL> create table table_from_online as select * from user_tables;
SYS@ORCL> alter system switch logfile;

The newly created tablespace was taken offline and its status was verified.
The database has to be in archivelog mode to be able to accomplish the
following task without shutting down the database.

SYS@ORCL> alter tablespace tbs_from_online offline immediate;
SYS@ORCL> select tablespace_name,status from dba_tablespaces;
SYS@ORCL> select name, status from v$data_file;
/u01/oradata/ORCL/data_file/01_tbs_1_5nz5261s_.dbf RECOVER

Remove the datafile from the operating system location. Remember, there
is no backup of this new tablespace at this point in time. Start an RMAN
restore session.

RMAN> restore tablespace tbs_from_online;

At this point at the OS level, the datafile still doesn’t exist. It is during the
recover command where Oracle searches for redo and/or archive logs. During
this particular restore session, no archive logs were applied (by viewing


the output from the RMAN session and alert_$ORACLE_SID.log), so it
restored the missing data file from online redo.

RMAN> recover tablespace tbs_from_online;
SYS@ORCL> alter tablespace tbs_from_online online;
SYS@ORCL>select tablespace_name, status from dba_tablespaces;

Upgrading/Downgrading a Database During an RMAN Restore/
Recovery Session
RMAN can directly downgrade or upgrade a database. This is particularly
useful during migration projects when you need to create a clone/copy of a
database that is a different Oracle version.

Use this method for the following reasons:
• You can migrate between one-off operating system levels.
• You can change database word sizes (32-vit to 64-bit and vice versa).
• There is no need to install multiple ORACLE_HOMES of the
different versions, just the one you are migrating to. This is assumed
you are working with a different server than the original.
• It can be used for one-off patches, patchsets or single version differences.

For example: 10.2.x to 11.2.x, 10.2.0.1 to 10.2.0.4, 11.2.0.1.0 to
11.2.0.4.4. Just be aware of any post-patch steps that might have to be
executed against a database. You will find these as part of the readmes for
each version involved. These post upgrade tasks typically include catalog.
sql, catproc.sql, catpatch.sql and utlrp.sql. Follow the steps used for a
manual upgrade/downgrade — search in MOS for the documents that
start with the keywords Complete Checklist for Manual Upgrades.

This method is:
• Great for a trial restore of a critical database — so you can test your
RMAN restores and recoverability.


• Useful for a situation where you need to downgrade to a version
different than the original.
• Useful for cloning a database using a user-managed backup (commonly
called cold or hot backups) — in this case, you would need to use the
RMAN catalog command to let the repository catalog know where to
find the datafile copies.

This allows you to skip the step where you would first need to clone (like the
RMAN duplicate command) to the same binary version as the original and
then finish the database upgrade/downgrade. See Oracle Database Backup
and Recovery User's Guide 11g (Chapter 19, Performing RMAN Recovery:
Advanced Scenarios) Look for the section labeled “Restoring a Database on a
New Host” for more details that aren’t included in the following steps.

This type of restore/recovery in order to upgrade/downgrade scenario
cannot be used in conjunction with the RMAN duplicate database
command. Also, be careful to use the NOCATALOG mode of RMAN
recovery when you are attempting this on the same host as the original
database. See MOS Note: 245262.1 for more information.

Steps for RMAN upgrade:
1. Install higher-versioned Oracle software. Create oratab entry —
ORACLE_SID same as original. Use NID to change later if desired.
Create necessary datafile directories; you can change the datafile
locations using SET NEWNAME as part of the RMAN command.
2. Run Pre-Upgrade Tool.
3. Make backups available on the server to which you are restoring.
4. Set environmental variables, run oraenv and start RMAN.

RMAN> CONNECT TARGET /
RMAN>SET DBID XXXXXXXXXX;
RMAN>STARTUP NOMOUNT


5. Recover spfile or create a new pfile. If upgrading from 10.x, the spfile
won’t be included if the controlfile is configured for autobackup.
6. Restore the controlfile, then mount the database.

run {
SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/backuplocation/%F';
restore controlfile from autobackup;
alter database mount;
}

7. Restore datafiles and recover the database. The following example
restores to a certain point in time:

RUN
{
set until time = "to_date('02/05/11:16:00:00','MM/DD/YY:HH24:MI:SS')";
# restore the database and switch the datafile names, this example will restore the #
datafiles to their original location.
RESTORE DATABASE;
SWITCH DATAFILE ALL;
RECOVER DATABASE;
}

8. Open the database using the following command. This step can also be
accomplished at the RMAN command line or using SQL*PLUS.
SYS@ORCL> or RMAN> alter database open resetlogs upgrade;

9. Finish the upgrade by following the standard manual upgrade method.
There may be more post steps than what is listed. The shortened
example outlined just highlights the differences between using RMAN
and a traditional manual upgrade.

SYS@ORCL> @$ORACLE_HOME/rdbms/admin/catupgrd.sql


Backup Strategies and Recommendations
What is the best number of days to set for a recovery window? It depends
on how much backup space is available and the type of backups — full
or incremental. For an incremental backup policy, the most efficient use
of backup space would be a window that is one less than the default of
seven days: six days. That makes an older Level 0 obsolete prior to the next
Level 0. This is assumed that you will take a Level 0 incremental backup
(basically a full backup) once a week with all other backups as incremental
and/or differential. Of course, you can extend this window strategy to 13
or 20 days and so on.

While using a recovery window is one of the most common backup and
recovery strategies used, you should also familiarize yourself with Oracle’s
recommendation: Incrementally Updated Backup. To take full advantage of
this type of strategy (fastest restores/recovery), store the backups in the Flash
Recovery Area (FRA). This allows you to switch the database to the actual
copy stored in the FRA. This also removes the need (hint: save time) to restore
or recover any datafiles, as you are actually switching to the backup set plus
the step of media recovery — applying archivelogs. Note this type of backup
strategy limits the time period to restore from as it is a daily updated backup.

The difference between a normal incremental and the merge method is
the RECOVER command that comes before the backup and the FOR
RECOVER OF COPY keywords in the backup command. The following
example also checks for logical corruption while compressing:

RMAN> run{
backup as compressed backupset
check logical incremental level 1
for recover of copy with
tag MY_DAILY_COPY database
filesperset 1;

recover copy of database with
tag MY_DAILY_COPY;
}


Fastest Way to Restore Entire Database using Incremental Merge
Backup Strategy
1. Create a pfile with control_file =’/FRA_location_copy of controlfile.’
2. Mount DB.
3. Switch Database to Copy .
4. Recover.
5. Open.

Recommendations Utilizing RMAN, FRA & DATA GUARD with 11g
Here are some generalized tips combining Incremental Merged Backups,
FRA and DataGuard for a fully redundant backup solution:
• One-time image copy backup to Fast Recovery Area (FRA)
• Daily differential incremental backup to FRA
• Image copy rolled forward daily until “sysdate – 4,” extends recovery
time period
• FRA sized for one image copy backup + 4 incrementals + 4 days of
archived logs
• Daily backup of FRA to tape and/or Cloud (retained for one month)
• Daily vaulting of tape backups to offsite location (retained for one year)
• Real time, synchronized physical standby database in Maximum
Performance mode for disaster recovery and other point in time
recoveries
• Utilize RMAN Recovery Advisor + DATA GUARD for real-time
detection, analysis and recovery of failures

• ASM — excellent FRA destination due to raw device-like performance,
management capabilities, working with large pools and/or multiple FRA


Datawarehouse RMAN Backup over Several Days Method
The following example runs the backup command for the next eight
hours, running the same command again at the next interval takes up
where it left off.

RMAN> BACKUP DATABASE NOT BACKED UP SINCE
‘SYSDATE-3’ DURATION 08:00 PARTIAL MINIMIZE TIME;

If you haven’t started using RMAN yet, now is the time to start. It is
becoming the standard for Oracle database.

■ ■ ■ About the Author
Satishbabu Gunukula has more than 12 years of experience in Oracle database
technologies and has specialized in Oracle rac administration on a wide variety of UNIX
platforms. He has implemented many business critical rac and Maa systems for Fortune
500 and Fortune 1000 companies. He also has experience in Oracle applications and Oracle
Hyperion. He received his master’s and is an Oracle certified dBa in OcP 8i/9i/10g and
Oracle certified expert in Oracle 10g rac. He is currently working for Intuitive Surgical, a
medical device company, as senior database administrator.

.?.
Did You
KNOW…
The highest rated member benefit is the IOUG SELECT Journal,
IOUG’s quarterly technical journal that provides in-depth technical
articles from recognized authorities in Oracle technology.


Ioug tip book11_gunukula

More Related Content

What's hot

Similar to Ioug tip book11_gunukula

More from Satishbabu Gunukula

Recently uploaded

Ioug tip book11_gunukula