Archive for the ‘RMAN’ Category
Speaking of RMAN, the DELETE command obviously deletes what you tell it to, but what is the difference between DELETE OBSOLETE and DELETE EXPIRED? If a backup item (piece or set) is expired, isn’t it also obsolete? Or, if obsolete, is it also expired? One way to look at the difference is this: not needed versus not found. Something obsolete may or may not be found. Something expired may or may not be needed.
What does DELETE do?
DELETE removes the physical files from the backup media, deletes the record of the backup from the recovery catalog (if RMAN is connected to a recovery catalog), and updates the records of these backups in the control file to status DELETED.
In the obsolete case, what helps to clarify the difference between OBSOLETE and EXPIRED is the retention policy. If a backup item is no longer needed for recovery – because it is older than the retention policy – then it is obsolete. What does DELETE OBSOLETE do?
What does DELETE do?
DELETE removes the physical files from the backup media, deletes the record of the backup from the recovery catalog (if RMAN is connected to a recovery catalog), and updates the records of these backups in the control file to status DELETED.
In the obsolete case, what helps to clarify the difference between OBSOLETE and EXPIRED is the retention policy. If a backup item is no longer needed for recovery – because it is older than the retention policy – then it is obsolete. What does DELETE OBSOLETE do?
The RMAN DELETE command supports an OBSOLETE option, which deletes backups that are obsolete, that is, no longer needed to satisfy specified recoverability requirements. You can delete files obsolete according to the configured default retention policy, or another retention policy that you specify as an option to the DELETE OBSOLETE command. As with other forms of the DELETE command, the files deleted are removed from backup media, deleted from the recovery catalog, and marked as DELETED in the control file.
The next clarification concerns the EXPIRED status. How does an object become expired?
When the CROSSCHECK command is used to determine whether backups recorded in the repository still exist on disk or tape, if RMAN cannot locate the backups, then it updates their records in the RMAN repository to EXPIRED status. You can then use the DELETE EXPIRED command to remove records of expired backups from the RMAN repository. If the expired files still exist, then the DELETE EXPIRED command terminates with an error.
When the CROSSCHECK command is used to determine whether backups recorded in the repository still exist on disk or tape, if RMAN cannot locate the backups, then it updates their records in the RMAN repository to EXPIRED status. You can then use the DELETE EXPIRED command to remove records of expired backups from the RMAN repository. If the expired files still exist, then the DELETE EXPIRED command terminates with an error.
As you can, something will be deleted when using the DELETE command. It is either a physical item, or metadata. Same thing, but different.
With the introduction of CTWR (change track writer) background process, 10g RMAN made the incremental backups faster than before.
CTWR background process will be started when we enable change tracking feature in database using following command
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;
An OMF file will be created in DB_CREATE_FILE_DEST location with the initial size of 10M and will grow in 10M of size. This file will record the information of the blocks which are getting changed including their block SCN. We can use already existing file also as change tracker file as follows:
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE ‘/u01/oradata/MYSID/rman_change_track.f’ REUSE;
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE ‘/u01/oradata/MYSID/rman_change_track.f’ REUSE;
Note: Enabling change tracking may cause overhead in performance of database
The following command can be used to disable change tracking:
ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
To know the status of change tracking feature, use:
SELECT status FROM v$block_change_tracking;
SELECT status FROM v$block_change_tracking;
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 CONTROLFILE_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 CONTROLFILE_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 CONTROLFILE_RECORD_KEEP_TIME always a higher value than what we set for retention policy. As per the formula, it should be
CONTROLFILE_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 CONTROLFILE_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 ……………….
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
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
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)
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
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. Always make sure you have only one RMAN backup in process
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;
}
{
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)
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)
Cause:
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.
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.
Solution:
Use the below way to use rman commands 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)
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)
Today, When I am accessing RMAN for a database in one of my prod server, i got below error
Copyright (c) 1982, 2007, Oracle. All rights reserved.
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00554: initialization of internal recovery manager package failed
RMAN-03000: recovery manager compiler component initialization failed
RMAN-06035: wrong version of recover.bsq, expecting 10.2.0.4, found 10.2.0.3
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00554: initialization of internal recovery manager package failed
RMAN-03000: recovery manager compiler component initialization failed
RMAN-06035: wrong version of recover.bsq, expecting 10.2.0.4, found 10.2.0.3
By this its clear that there could be some version mismatch. Then i checked how many oracle homes are existing on the server. I found there are 3 different 10g oracle homes (each of different version).
In this kind of situation, you can invoke rman by going to HOME path/bin directory
[oracle@pc14 ~]$ cd $ORACLE_HOME/bin
[oracle@pc14 ~]$ ./rman
RMAN> connect target /
So folks, if you face same error…don’t be panic its all simple that we can solve this issue.
Tip: To avoid these complications, Oracle always recommend to maintain same version of database under a release in the server
No comments:
Post a Comment