Pavan DBA's Blog

The DBA Knowledge Store

Archive for the ‘RMAN’ Category

How RMAN take backup?

Posted by Pavan DBA on March 28, 2013

Today I want to share what I know about RMAN backup behaviour in different versions.

Behaviour in 9i or below versions (which uses dictionary managed tablespace):

Normally there is a misconception that RMAN will take backup of only USED blocks.

But, during database backup, RMAN will take backup of both USED and FREE blocks also. Why and How this happens?


When we initiate RMAN to take backup of dictionary managed tablespace, it will read all the blocks from datafile into memory (which we usually call as input buffers). While doing this, RMAN will read all the blocks which are written by Oracle processes at some point of time i.e if a block is filled with data one month back and may be due to some delete/drop/truncate operation now the block is empty, still RMAN will count that block for backup.

By this we can understand that RMAN will read blocks with data and blocks without data also into memory.

Then which blocks RMAN will skip? BLOCKS WHICH ARE NEVER WRITTEN i.e if a block is UNUSED and no oracle process has written anything to it, then RMAN will skip those kind of blocks.


An immediate question that raises after above statement is why RMAN is doing this?

Because RMAN is designed in such a way that it can take backup even if database is in closed state (we know this already). Now, if the database is closed, RMAN cannot read data dictionary to get information like if the block is on freelist or not. So, RMAN will skip only UNUSED (never written) blocks.
This behaviour is completely changed in 10gR2 with the usage of locally managed tablespaces (from 10g by default a tablespace will be locally managed) which can maintain the block information in bitmap headers itself. So, in 10g, RMAN will take backup of only USED blocks leaving FREE and UNUSED blocks.

Note: The above behaviour is applicable also in 9i/8i if you use LMT.


Posted in RMAN | Tagged: , | 6 Comments »

how to define RMAN retention policy time?

Posted by Pavan DBA on July 11, 2011

Many a times, I heard DBA’s complaining about RMAN retention policy through which they face some problems during restore or  recovery.

For example a friend posted that his retention policy is set to recovery window of 90 days, but when tried to restore the database to 30 days back date, RMAN saying recovery till that time is not possible. he wondered why this cannot be done if he has retention of 90 days.

Here is the answer for the same….

we all know that RMAN will store backup metadata in control file’s reusable location if recovery catalog is not configured. Generally this information will be stored for 7 days and can be changed by modifying CONTROL_FILE_RECORD_KEEP_TIME parameter.

whenever we define retention policy of RMAN either to recovery window or redundancy to some X value, we need to remember that  RMAN still follow the value defined for CONTROL_FILE_RECOD_KEEP_TIME. That means, if recovery window is set to 30 days, but the above parameter is set to 7 days (default), you cannot recover beyond 7 days… which is very unfortunate…

Right ! so lets see what can be done for this?

we need to define CONTROL_FILE_RECORD_KEEP_TIME always a higher value than what we set for retention policy. As per the formula, it should be

CONTROL_FILE_RECORD_KEEP_TIME=retention policy value+ level 0 backup interval+ 1

let me throw some example for easy understanding…

If suppose your retention time is set to recovery window of 90 days and a weekly full level 0 backup is scheduled, then CONTROL_FILE_RECORD_KEEP_TIME = 90 (retention policy) + 7 (level 0 backup interval) + 1 = 98

Note: In worst case, atleast you should set that same (equal to) as retention policy value

What happens if I don’t set to higher value?

In such case, RMAN will overwrite the content of backup metadata prior to obsolete them by RMAN and even though physically backup pieces are existing, you cannot use them

Hope this will help you ……………….

Posted in RMAN | 15 Comments »

How to solve ORA-19505: failed to identify file in RMAN?

Posted by Pavan DBA on January 18, 2011

DBA’s will feel bad when they got any error. It’s common for any 🙂

Lets say you got below error

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on ch00 channel at 01/17/2011 13:01:03
ORA-19505: failed to identify file “/dwh1/oraarch/arch/1_1100721_664058960.dbf”
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

Don’t be panic, nothing happened to your backup or database. If you read the error, its saying particular archive logfile is not available. This may be due to file deleted at OS level due to some reason.

In this situation, do the following

1. Run crosscheck command against archivelogs

RMAN> crosscheck archivelog all;

2. If you find any archives marked as EXPIRED, then delete those expired archives using below command

RMAN> delete expired archivelog all;
This will prompt you YES or NO. If you don’t want a prompt, use below command

RMAN> delete noprompt archivelog all;

3. Take a fresh archivelog backup

RMAN> backup archivelog all; (you  can use delete input clause also)

Posted in RMAN | Tagged: , , | 4 Comments »

Resolving ORA-19588: archived log recid stamp is no longer valid

Posted by Pavan DBA on January 18, 2011

Sometimes you may find the following error in RMAN archive backup or online backup logfile

ORA-19588: archived log recid 24909 stamp 740658206 is no longer valid

This is not an error but a warning. The reason for this is archive logfile which this process is trying to take backup, is already been backed up by another process and file is deleted

This situation will occur if both archive backup job and full database backup (including archives) are executing at same time or two archive backup jobs executing at same time.

So to avoid this we have two ways

1. If you want to run a manual backup, just check whether any other RMAN backups are in execution phase. you can do this by

[oracle@viadbscph014 logs]$ ps -ef | grep rman

If any backup process is running, you will see a similar output as below

[oracle@viadbscph014 logs]$ ps -ef | grep rman
root      3022  3015  0 00:15 ?        00:00:00 su – oracle -c ?ORACLE_HOME=/opt/oracle/oracle/product/10.2.0?export ORACLE_HOME?ORACLE_SID=dwh2?export ORACLE_SID?/opt/oracle/oracle/product/10.2.0/bin/rman target / nocatalog msglog /opt/oracle/admin/DWH2/backup/logs/online_backup_20110118.out append << EOF?RUN {?ALLOCATE CHANNEL ch00 TYPE sbt PARMS=’ENV=(NB_ORA_SCHED=Default-Application-Backup,NB_ORA_CLIENT=viadbscph014)’;?ALLOCATE CHANNEL ch01 TYPE sbt PARMS=’ENV=(NB_ORA_SCHED=Default-Application-Backup,NB_ORA_CLIENT=viadbscph014)’;?BACKUP?    INCREMENTAL LEVEL=0?    SKIP INACCESSIBLE?    FILESPERSET 5?    # recommended format?    FORMAT ‘bk_%s_%p_%t_%U’?    DATABASE;?    sql ‘alter system archive log current’;?RELEASE CHANNEL ch00;?RELEASE CHANNEL ch01;?# backup all archive logs?ALLOCATE CHANNEL ch00 TYPE sbt PARMS=’ENV=(NB_ORA_SCHED=Default-Application-Backup,NB_ORA_CLIENT=viadbscph014)’;?ALLOCATE CHANNEL ch01 TYPE sbt PARMS=’ENV=(NB_ORA_SCHED=Default-Application-Backup,NB_ORA_CLIENT=viadbscph014)’;?BACKUP?   filesperset 20?   FORMAT ‘al_%s_%p_%t_%U’?   ARCHIVELOG ALL DELETE INPUT;?  # ARCHIVELOG ALL;?RELEASE CHANNEL ch00;?RELEASE CHANNEL ch01;?#?# Note: During the process of backing up the database, RMAN also backs up the?# control file.  This version of the control file does not contain the?# information about the current backup because nocatalog has been specified.?# To include the information about the current backup, the control file should?# be backed up as the last step of the RMAN section.  This step would not be?# necessary if we were using a recovery catalog.?#?ALLOCATE CHANNEL ch00 TYPE sbt PARMS=’ENV=(NB_ORA_SCHED=Default-Application-Backup,NB_ORA_CLIENT=viadbscph014)’;?BACKUP?    # recommended format?    FORMAT ‘cntrl_%s_%p_%t_%U’?    CURRENT CONTROLFILE;?    sql ‘alter database backup controlfile to trace’;?    sql “alter database backup controlfile to ”/opt/oracle/oracle/product/10.2.0/dbs/dwh2_backup_controlfile.ctl” reuse”;??RELEASE CHANNEL ch00;?}?EOF?
Note: Output may differ. In my case RMAN backup is initiated through Netbackup tool

2. Don’t schedule archive backup job during full database backup (including archivelog). Always make sure you have only one RMAN backup in process

Posted in RMAN | Tagged: , , | 8 Comments »

RMAN no channel allocated for maintenance

Posted by Pavan DBA on December 23, 2010

Many a times, when you issue some commands in RMAN you may receive following error

RMAN> run
allocate channel c1 device type sbt_tape;
delete noprompt obsolete;

released channel: c1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of crosscheck command at 12/23/2010 10:57:21
RMAN-06091: no channel allocated for maintenance (of an appropriate type)

This is because of command change across versions especially between 9i and 10g. The command which we used above is for 10g and will not work in 9i.

Use the below way to use rman commands in 9i

RMAN> allocate channel for maintenance type sbt_tape;

allocated channel: ORA_MAINT_SBT_TAPE_1
channel ORA_MAINT_SBT_TAPE_1: sid=1059 devtype=SBT_TAPE
channel ORA_MAINT_SBT_TAPE_1: VERITAS NetBackup for Oracle – Release 6.0 (2008012304)

Posted in RMAN | Tagged: , , , | 3 Comments »

%d bloggers like this: