Top 10 Backup and Recovery best practices. [ID 388422.

1]
Modified 26-AUG-2010 Type FAQ Status PUBLISHED

In this Document
Purpose
Top 10 Backup and Recovery best practices.
Questions and Answers

Applies to:
Oracle Server - Enterprise Edition - Version: 9.2.0.1 and later [Release: 9.2 and later ]
Information in this document applies to any platform.

Purpose
Top 10 Backup and Recovery best practices.

This document assumes that you are doing the Backup and Recovery basics
- Running in Archivelog mode
- multiplexing the controlfile
- Taking regular backups
- Periodically doing a complete restore to test your procedures.

Questions and Answers

1. Turn on block checking.
REASON: The aim is to detect, very early the presence of corrupt blocks in the database.
This has a slight performance overhead, but will allow Oracle to detect early
corruption caused by underlying disk, storage system, or I/O system problems.

SQL> alter system set db_block_checking = true scope=both;

2. Turn on block tracking when using RMAN backups (if running 10g)
REASON: The block tracking file contains a bitmap that is used during incremental backups
Each bit represents an extent, so only those extents that have been modified will be read and
backed up.
If this is not used, all blocks must be read to determine if they have been modified since the last
backup.

SQL> alter database enable block change tracking using file

'/u01/oradata/ora1/change_tracking.f';
3. Duplex log groups and members and have more than one archive log dest.
REASON: If an archivelog is corrupted or lost, by having multiple copies in multiple locations,
the other logs will still be available and could be used.

If an online log is deleted or becomes corrupt, you will have another member that can be
used to recover if required.

SQL> alter system set log_archive_dest_2='location=/new/location/archive2' scope=both;

SQL> alter database add logfile member '/new/location/redo21.log' to group 1;

4. When backing up the database use the 'check logical' parameter

REASON: This will cause RMAN to check for logical corruption within a block as well as the
normal
head/tail checksumming. This is the best way to ensure that you will get a good backup.

RMAN> backup check logical database plus archivelog delete input;

5. Test your backup.

REASON: This will do everything except actually restore the database. This is the best method
to
determine if your backup is good and usable before being in a situation where it is
critical and issues exist.

RMAN> restore validate database;

6. Have each datafile in a single backup piece

REASON: When doing a partial restore RMAN must read through the entire piece to get the
datafile/archivelog requested. The smaller the backup piece the quicker the restore can
complete. This is especially relevent with tape backups of large databases or where the
restore is only on individual / few files.

RMAN> backup database filesperset 1 plus archivelog delete input;

7. Maintain your RMAN catalog/controlfile

REASON: Choose your retention policy carefully. Make sure that it compliments your tape
subsystem
retention policy, requirements for backup recovery strategy. If not using a catalog,
ensure that your controlfile record keep time instance parameter matches your retention policy.

SQL> alter system set control_file_record_keep_time=21 scope=both;

This will keep 21 days of backup records.
Run regular catalog maintenance.
REASON: Delete obsolete will remove backups that are outside your retention policy.
If obsolete backups are not deleted, the catalog will continue to grow until performance
becomes an issue.

RMAN> delete obsolete;

REASON: crosschecking will check that the catalog/controlfile matches the physical backups.
If a backup is missing, it will set the piece to 'EXPIRED' so when a restore is started,
that it will not be eligible, and an earlier backup will be used. To remove the expired
backups from the catalog/controlfile use the delete expired command.

RMAN> crosscheck backup;

RMAN> delete expired backup;

8. Prepare for loss of controlfiles.

set autobackup on
REASON: This will ensure that you always have an up to date controlfile available that has been
taken at the end of the current backup not during.

RMAN> configure controlfile autobackup on;

keep your backup logs

REASON: The backup log contains parameters for your tape access, locations on controlfile
backups
that can be utilised if complete loss occurs.

9. Test your recovery

REASON: During a recovery situation this will let you know how the recovery will go without
actually doing it, and can avoid having to restore source datafiles again.

SQL> recover database test;

10. Do not specify 'delete all input' when backing up archivelogs

REASON: Delete all input' will backup from one destination then delete both copies of the
archivelog where as 'delete input' will backup from one location and then delete what has
been backed up. The next backup will back up those from location 2 as well as new logs
from location 1, then delete all that are backed up. This means that you will have the
archivelogs since the last backup available on disk in location 2 (as well as backed up
once) and two copies backup up prior to the previous backup.

See Note 443814.1 Managing multiple archive log destinations with RMAN
for details.
Applies to:
Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 10.2.0.1 - Release: 10.1 to
10.2
Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 10.2.0.5.0 [Release: 10.1
to 10.2]
Information in this document applies to any platform.

Goal
Explain how multiple archive destinations are handled during an RMAN backup and restore
process

Solution
DELETE INPUT

DELETE INPUT will remove archivelogs from the first destination. It will also remove
archivelogs from the second destination that was PREVIOUSLY backed up.

For example:

Backup #1

• Backup archivelogs older than seven days from destination #1, and remove
these files
• Do not backup or remove any archivelogs in destination #2 has all files

Backup #2

• For destination #1, backup archivelogs older than seven days and remove
these files
• For destination #2, backup archivelogs that satisfied backup criteria #1
(more than 14 days old) and remove them

Whereas a DELETE ALL INPUT will backup from one destination and delete both copies of the
archivelog.

Backup and Delete from a Specified Archive Destination

If you'd like to only backup and remove from a single archive destination, use the LIKE clause:

eg:
RMAN> backup archivelog until time 'sysdate -7' like
'/u04/oracle/admin/TEST/arch/%' delete
input;

The above will only backup and delete from the LIKE destination

If archive logs are backed up to multiple destinations, and if the required retention policy is
required to be different for different destinations, then the following can be done:

RMAN> run {
backup archivelog all;
delete archivelog until time 'sysdate -1' like '/am3/oradata/arch/%';
delete archivelog until time 'sysdate -5' like '/am3/oradata/arch1/AM3P2/%';
}

The FRA and DELETE INPUT

RMAN will backup and remove the archivelogs in numerical order from _dest_1 to dest_10.
However,
if one of the archive destinations is an FRA, RMAN will always backup and remove from the
FRA
first, and then work on the numerical order of the log_archive_dest_x

eg.
If the following parameters were set:

• log_archive_dest_1='location=/u002/oraarch/ORA1020
• log_archive_dest_2='LOCATION=USE_DB_RECOVERY_FILE_DEST
• log_archive_dest_3='location=/u002/oraarch3/ORA1020'

Oracle will backup and remove from the FRA, folllowed by archivelogs in log_archive_dest_1.
Finally, logs in log_archive_dest_3 will be removed.

Where do the restored archivelogs go?

During the restore process RMAN will check all archive destinations to make sure that the
archivelog requested does not already exist. If the archivelog already exist in one of the
destinations RMAN will not restore the file. If the archivelog does not exist in any of the
destinations RMAN will restore it to the FRA if it exists. Otherwise it will restore it to the
highest archive destination defined.
Restoring archivelog to FRA in ASM

When using the FRA and ASM, the archivelog will be restored to the current directory, rather
than the time at which it was generated. Even if using the SET ARCHIVELOG DESTINATION,
an alias will be created to the current directory.

For example, on the 16 Aug 2010, when restoring the 13 Aug archivelogs:

RMAN> run {
allocate channel c1 type 'sbt_tape';
set archivelog destination to '+SHARED_FRA_DG01/P132/ARCHIVELOG/2010_08_13';
restore archivelog from time "to_date('13/08/2010:00:00:00','dd/mm/yyyy:hh24:mi:ss')"
until time "to_date('14/08/2010:00:00:00','dd/mm/yyyy:hh24:mi:ss')";
}

+SHARED_FRA_DG01/P132/ARCHIVELOG/2010_08_13
ASMCMD> ls -ltr
Type Redund Striped Time Sys Name
N 1_94528_708660567.dbf =>
+SHARED_FRA_DG01/P132/ARCHIVELOG/2010_08_16/thread_1_seq_94528.5341.7272245
33
N 1_94529_708660567.dbf =>
+SHARED_FRA_DG01/P132/ARCHIVELOG/2010_08_16/thread_1_seq_94529.3425.7272246
61
N 1_94530_708660567.dbf =>
+SHARED_FRA_DG01/P132/ARCHIVELOG/2010_08_16/thread_1_seq_94530.5644.7272247
79