QUESTIONS ON RMAN

How do we Set A Retention Policy For Tape Backups And

Disk Backups Differently?

Step 1: Set the retention policy.

RMAN currently only allows one retention policy. The retention policy
should be set to 14 days.
RMAN> configure retention policy to recovery window of 14 days;

Step 2: Move the backups from disk to tape to meet the specified disk
retention policy. This must be done manually.

The following command will move the backups from disk to tape and
delete the original backup copy from disk.

RMAN> backup device type sbt backupset completed before 'sysdate-

2' delete input;

The time specified may be changed depending which backupsets will

be moved to tape and deleted from disk. The retention policy
guarantees that the backups will not be marked as obsolete unless
they meet the specified retention policy.

How does the RMAN Retention Policy Obsolete

Incremental Backupsets ?

The report/delete obsolete commands works in two steps.

First, we identify the oldest full backup (i.e. full or level 0 backupset, or
image copy) of every file that is not obsolete, as defined by the
retention policy (either REDUNDANCY or RECOVERY WINDOW). Every
older full backup is obsolete.

Then, all archived logs and level > 0 incremental backups that are
older than the oldest non-obsolete full backup are also considered to
be obsolete, because there is no longer any full backup to which they
could possibly apply.

Note that a level > 0 backup performs much the same function as an
archived log - it causes a full backup to move forward in time, so those
backups are treated in the same manner as archived logs for the
purposes of retention. Incremental backups are not restored using the
restore command, they are restored using the recover command if it
will cause fewer archive logs to be needed during recovery. When you
restore it is always only from full or level 0 incremental backups of
the datafiles.

How can we have different retention policies for

different backups ?

We cannot have different retention policies for different backups . The

retention policy is always same for all backups .

But there could be situations where you would be looking for different
kind of retention policies.Such kind of a situation is explained below.

EXAMPLE
========

QUESTION
=========

There are 3 types of backup , daily , weekly and monthly, so we would

like to have 3 retention policies 1 for retention of 32 days, 2 for
retention of 365 days and other for 700 days for example

ANSWER
=========

For all your daily backups maintain a normal retention policy i.e

Rman > configure retention policy for recovery window of 32 days ;

This retention policy is always common for all backups . But since you
have to retain the weekly backups for 365 days and monthly backups
for 700 days .

Therefore for the weekly and monthly backups we will be going for "
KEEP " option .

You can exempt a backup from the retention policy by using the KEEP
option with the BACKUP command
when you create the backup, or the KEEP option of the CHANGE
command to exempt an existing backup.
Note that backups exempted from the retention policy are still fully
valid backups, which can be
used in restore and recovery operations like any other if RMAN judges
them to be the best choice
available.

You can change the exempt status of a backup using the CHANGE...
KEEP and CHANGE... NOKEEP
commands. The NOKEEP option (default) indicates that the backup is
not immune from the configured
retention policy.

You can specify the LOGS option to save archived logs for a possible
incomplete recovery of the
long-term backup. When LOGS is specified, all logs more recent than
the backup are kept as long as
the backup is kept. In other words, KEEP UNTIL TIME... LOGS means
that RMAN will keep all logs
required to recover the backup as long as the backup is kept. If you
specify NOLOGS, then RMAN
does not keep the logs required to recover the backup. Note that if you
use KEEP UNTIL TIME...
with an inconsistent backup, you must use the LOGS option, or that
backup will become unusable
when the logs required to recover it are deleted as obsolete.

You can specify an end date using the UNTIL clause, or either specify
that the backup should be
kept FOREVER. If you specify UNTIL, then RMAN will not mark the
backup as obsolete until after the
UNTIL date has passed. Note that it is an error to specify KEEP
FOREVER with the LOGS option, as
this would require keeping all redo logs forever.

EXAMPLE:
=========
+ For weekly and monthly backups you can take the backups in this
way :

Rman > BACKUP DATABASE KEEP UNTIL TIME "TO_DATE('31-DEC-2007'

'dd-mon-yyyy')" NOLOGS;

Specify the until time as needed depending upon whether the backup
is weekly or monthly .
For the rest of your daily backups you can have the normal retention
policy of 32 days .

Why do the backups do not become obsolete even if

they are out of retention policy ?

We can have different conditions due which the backups would not
become obsolete. They are :

1) There is an offline datafile in the database because of which the all

the archivelogs or the archivelog backups needed to recover the
datafile will not become obsolete.

2) The backups were done with KEEP option.

3) If the above conditions do not satisfy , then there could be a bug

due to which the backups are not becoming obsolete.

What is the recommended retention policy for

incremental merge backups ?

To implement the retention policy for the incremental merge backups,

please use the following guidelines.

+ Retain the default retention policy to redundancy 1. This enables all

the incremental backups to become obsolete as soon as they are
applied to the copy.

+ To implement the retention policy based on recovery window,do not

use the CONFIGURE command.Instead use the UNTIL CLAUSE in the
RECOVER COMMAND.

Example
---------
run {
allocate channel oem_disk_backup device type disk;
RECOVER COPY OF DATABASE with tag 'ORA$OEM_LEVEL_0 until time
'sysdate-8' ';
backup incremental level 1 cumulative copies=1 for recover of copy
with tag 'ORA$OEM_LEVEL_0' database;
}
NOTE
======

For incremental merge backups,please ensure that the retention policy

is retained to its default value of redundancy 1.However if you want to
configure retention policy based on recovery window of n days , then
ensure that you include the UNTIL TIME clause in the RECOVER
command to 'sysdate-(n+1)'.

Neither list backup or report/delete obsolete display the

obsolete backup pieces. But the backup pieces are
very much available on the disk.

It is possible that the information about these backups are

removed/overwritten in the controlfile.
To prevent this ensure the control_file_record_keep_time initialization
parameter value is set to a value higher than the retention policy of
recovery window OR consider using a recovery catalog.

How to check/validate backup of datafile and archivelogs are good to

restore and recover ?

To check the backups are good or not there are two options :

Option 1: Restore the database on a server and recover it using the

backups. This you accomplish using RMAN duplicate command.

View the below note for more information on RMAN duplicate :

Note.228257.1 RMAN 'Duplicate Database' Feature in Oracle9i / Oracle
10G

Option 2 : Run RMAN validate command. The validate command will

not restore any file it just reads and gives confirmation that the
backups are good.

Example:

Want to restore and recover the database till time '10:23, 05-
November-2007 then you have to use the below command to
accomplish this :
Step 1: The below command just gives the report of backups that are
used to do the restore and recover :

run
{
set until time "to_date('2007-05-10:23:00:00','yyyy-dd-
mm:hh24:mi:ss')";
restore database preview;
}

The Restore ... Preview identifies the backups (backup sets or image
copies, on disk or sequential media like tapes) required to carry out a
given restore operation, based on the information in the RMAN
repository. Use RESTORE... PREVIEW when planning your restore and
recovery operation, to ensure that all required backups are available or
to identify situations.

The restore database preview gives a report of all the backup pieces
and archivelogs that are required to restore/recover the database.
Make a note of the start sequence and end sequence of archivelogs
and the same will be used in the next step

Step 2: Then run the below command to check the backup pieces are
good :

run
{
allocate channel c1 type disk;
set until time "to_date('2007-05-10:23:00:00','yyyy-dd-
mm:hh24:mi:ss')";
restore database validate;
}

The above command will read the backup pieces/Copies which has
datafiles and if finds any error it will report at the RMAN prompt.

RMAN> run
{
allocate channel c1 type disk;
restore archivelog from sequence xxx until sequence yyy validate;
}

Replace the xxx, yyy with the start and end archivelog sequence
reported by restore database preview command ran in the step 1.

The RESTORE ... VALIDATE command test whether you can restore from
your backups. You can test the availability of usable backups for any
desired RESTORE operation, or test the contents of a specific backup
for use in RESTORE operations. The contents of the backups are
actually read and validated for corruption to ensure that the objects to
be restored can be restored from them.

How to change Flash Recovery Area to a new location ?
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­
 
If you need to move the Flash Recovery Area of your database
to a new location, 
invoke SQL*Plus to change the DB_RECOVERY_FILE_DEST 
initialization parameter. 
For example:

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='+disk1' SCOPE=BOTH 
SID='*';

After you change this parameter, all new Flash Recovery Area
files will be 
created in the new location.

The permanent files (control files and online redolog 
files), flashback logs 
and transient files can be left in the old Flash Recovery 
Area location. The 
database will delete the transient files from the old Flash 
Recovery Area 
location as they become eligible for deletion.

For the FLASHBACK logfiles to be able to to pick up the new 
'db_recovery_file_dest' location, 
the flashback option needs to be toggled off and on.

This can be done like this:
­ Shutdown the Database
­ Startup mount the Database:
  SQL> startup mount;
­ Toggle the Flashback off:
  SQL> alter database flashback off;
­ Toggle the Flashback on:
  SQL> alter database flashback on;
­ Open the Database:
  SQL> alter database open;
If you need to actually move your current permanent files, 
transient files, to the new Flash Recovery Area, then follow
the following steps:

1) To move the existing backupsets and archived redo log 
files,use the following 
   command:

   RMAN> BACKUP AS COPY ARCHIVELOG ALL DELETE INPUT;
   RMAN> BACKUP DEVICE TYPE DISK BACKUPSET ALL DELETE INPUT;

2) To move the datafile copies. Run the below command for 
each datafile copy:

   RMAN> BACKUP AS COPY DATAFILECOPY <name> DELETE INPUT;
   
   where the <name> is the datafilecopy name in the old 
recovery area.

3) To move the controlfile from the old Flash Recovery Area 
to new one. 
   Change the location in the parameter CONTROL_FILES to the
new location
   and restart the instance in NOMOUNT.

   RMAN> RESTORE CONTROLFILE FROM 
'filename_of_old_control_file';

4) To move the online redo logs. Use the commands to add a a
log file stored in 
   the new Flash Recovery Area and drop the logfile in the 
old Flash Recovery Area 
   for each redo log group.

   SQL> alter database add logfile size 100M;
   SQL> alter database drop logfile 'name of the old redo 
log';

Oracle will clean up transient files remaining in the old 
Flash Recovery Area 
location as they become eligible for deletion.
Relation between RMAN retention period
and control_file_record_keep_time

RMAN backup keeps the backup metadata information in the reusable

section of the controlfile. Its depends on the parameter
CONTROL_FILE_RECORD_KEEP_TIME.
CONTROL_FILE_RECORD_KEEP_TIME specifies the minimum number of
days before a reusable record in the control file can be reused. In the
event a new record needs to be added to a reusable section and there
is not enough space then it will delete the oldest record, which are
aged enough.

Backup retention policy is the rule to set regarding which backups must
be retained (whether on disk or other backup media) to meet the
recovery and other requirements.

If the CONTROL_FILE_RECORD_KEEP_TIME is less than the retention

policy then it may overwrite reusable records prior to obsoleting them
in the RMAN metadata. Therfor it is recommended that the
CONTROL_FILE_RECORD_KEEP_TIME should set to a higher value than
the retention policy.

Formula

CONTROL_FILE_RECORD_KEEP_TIME = retention period + level 0

backup interval + 1

For e.g.

e.q. level 0 backup once a week with retention policy of a recovery

windows of 14 days then in this case the
CONTROL_FILE_RECORD_KEEP_TIME should be 14+7+1=22