RMAN
Different errors and their Solution
Backup Fails
with Invalid RECID Error: RMAN-20035, RMAN-6038
RMAN-3014: Implicit resync of recovery catalog failed
RMAN-6038: Recovery catalog package detected an error
RMAN-20035: Invalid high RECID error
It indicates
the control file and the recovery catalog is not synchronized. RMAN detects
that the control file currently in use is older than the control file
previously used to resynchronize.
Cause:
This due to any of the scenario you
are restore a backup controlfile through a non-oracle mechanism and then open
the database through Resetlogs option or making a copy of control file through
operating system utility and trying the restore on new system through RNAN. You
do not use catalog so RMAN does not get any information regarding this
process. The recovery catalog indicates that the highest
RECID
is 100, but the control file indicates that
the highest RECID
is 90. The control
file RECID
should always be greater than or equal to the recovery catalog RECID, so RMAN issues RMAN-20035
Solution:
Login with sysdba:
sys/oracle@orcl3
Mount the database
SQL> shutdown immediate;
SQL> startup mount;
1.
Perform cancel based recovery to
open the database with Resetlogs option.
Alter Database Recover Database
until Cancel Using Backup Controlfile;
Alter Database Recover Cancel;
2.
Then connect to the rman and open
the database using Resetlogs option
CONNECT rsys/oracle@target catalog
catalog/catalog@rman
RMAN> Alter database open
resetlogs;
Backup Fails Because
of Control File Enqueue: ORA-00230
In
this scenario, a backup job fails because RMAN cannot make a snapshot control
file. The message stack is as follows:
RMAN-00571:
===========================================================
RMAN-00569: =============== ERROR
MESSAGE STACK FOLLOWS ===============
RMAN-00571:
===========================================================
RMAN-03002: failure of backup
command at 08/30/2001 22:48:44
ORA-00230: operation disallowed:
snapshot control file enqueue unavailable
Cause:
When RMAN needs to back up or
resynchronize from the control file, it first creates a snapshot or
consistent image of the control file. If one RMAN job is already backing up the
control file while another needs to create a new snapshot control file, then
you may see the following message:
Waiting for snapshot control file
enqueue
Under normal circumstances, a job
that must wait for the control file enqueue waits for a brief interval and then
successfully obtains the enqueue. RMAN makes up to five attempts to get the
enqueue and then fails the job. The conflict is usually caused when two jobs
are both backing up the control file, and the job that first starts backing up
the control file waits for service from the media manager.
Solution:
To determine which job is holding
the conflicting enqueue:
1. Start a new SQL*Plus session and login with the sysdba:
2. Execute the query to check the waiting cause:
SELECT s.SID, USERNAME AS
"User", PROGRAM, MODULE,
ACTION, LOGON_TIME "Logon",
l.*
FROM V$SESSION s, V$ENQUEUE_LOCK l
WHERE l.SID = s.SID
AND l.TYPE = 'CF'
AND l.ID1 = 0 AND l.ID2 = 2;
The output is look like as: (if
there is lock)
SID User Program Module Action Logon
--- ---- --------------------
------------------- ---------------- ---------
4 SYS rman@rman (TNS V1-V3) backup
full datafile: c10000210 STARTED 16-NOV-12
This situation generally came across
when a job is writing to a tape drive, but the tape drive is waiting for new tape
to be inserted. In the mean time if you start new job then you will probably
receive the enqueue message because the first job cannot complete until the new
tape is loaded.
After you have determined which job
is creating the enqueue, you can do one of the following:
§
Wait until the job holding the
enqueue completes
§
Cancel the current job and restart
it after the job holding the enqueue completes
§
Cancel the job creating the enqueue
RMAN Does Not Recognize
Character Set Name: PLS-00553
While working with Sadhan I
configure the rman backup server and start taking different production DB
backup. In one fine morning one of our database break down needs media
recovery. I connected the rman to target database and try to restore the
database but I receive the following error while using the “restore database”
command.
RMAN-03002: failure during
compilation of command
RMAN-03013: command type:
send
RMAN-06003: ORACLE error from
target database: ORA-06550: line 1, column 51:
PLS-00553: character set name
is not recognized
Cause:
After searching about this error I
found RMAN failed to compile the SEND statement because the NS_LANG of the
target database differed from the NS_LANG of the recovery catalog. In the
environment or shell script, set and export NS_LANG to the correct value for
the recovery catalog so that RMAN receives the correct value.
Solution:
1. Query the target database to
determine NLS_CHARACTERSET parameter.
SQL>
SELECT VALUE FROM
V$NLS_PARAMETERS WHERE PARAMETER='NLS_CHARACTERSET';
VALUE
-------------
AR8MSWIN1256
Try same Query with the rman catalog
database I found the database character set is same as the production database
here also.
2. Set the character environment
variable in the rman catalog system same as the server.
% setenv NLS_LANG
american_america.we8dec
% setenv NLS_DATE_FORMAT "MON
DD YYYY HH24:MI:SS"
In windows you can go through the
registry to setup environment variable:
HKEY_LOCAL_MACHINE
–> SOFTWARE –> ORACLE –> NLS_LANG
also check from the below path:
My Computer ->
Properties -> Advanced -> Environment Variables -> System Variables
-> New/Edit/Delete (to set the variables)
Note: If the connection is made
through a listener, then the listener must be started with the correct
Globalization Support settings. Otherwise, the spawned connections inherit the
incorrect Globalization Support settings from the listener.
Database Duplication
Fails with error: RMAN-06053, RMAN-06025
When I try to duplicate database
first time using RMAN the duplicate command is failed with following error:
RMAN-03002: failure of
Duplicate Db command at 07/28/2010 23:11:44
RMAN-03015: error
occurred in stored script Memory Script
RMAN-06053: unable to
perform media recovery because of missing log
RMAN-06025: no backup of log thread 1 seq 12 lowscn 487272 found to restore
Cause:
RMAN-06025: no backup of log thread 1 seq 12 lowscn 487272 found to restore
Cause:
RMAN unable to start archive log
restore to default destination. The problem is that rman is not able to apply
the entire archive log needed for complete recovery. For example, if you only
backed up logs through sequence 15, but the most recent archived log is
sequence 16, then DUPLICATE fails.
Solution:
When creating the duplication script
either, use the SET UNTIL command to specify a log sequence number for
incomplete recovery or include NOFILENAMECHECK with the duplicate command. For
example, to terminate recovery after applying log sequence 15, enter:
RUN
{
SET UNTIL
SEQUENCE 16 THREAD 1; #recovers up to but not including log 16
DUPLICATE
TARGET DATABASE TO 'dupdb';
}
-or- add NOFILENAMECHECK with
duplicate database command:
DUPLICATE TARGET
DATABASE TO "clone" NOFILENAMECHECK;
For Example:
RMAN> DUPLICATE
TARGET DATABASE TO "clone";
When NOFILENAMECHECK is used with
the DUPLICATE command, RMAN does not validate the filenames during restoration.
Note: If the primary database and the standby database are on
the same host, The DUPLICATE NOFILENAMECHECK option should not be used.
Write error on file:
ORA-19502:
While trying to take the backup
through the RMAN some times we are facing the below error.
RMAN> backup database plus
archivelog;
channel ORA_DISK_1: starting piece 1 at 03-OCT-12
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 10/03/2012 12:05:04
ORA-19502: write error on file "4crcv3st_1_1", blockno 5354 (blocksize=8192)Solution:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 10/03/2012 12:05:04
ORA-19502: write error on file "4crcv3st_1_1", blockno 5354 (blocksize=8192)Solution:
As the name it is clear. It is a
write error on output file. Check the file then try again.
Check the location parameter default
setting by issuing a command like:
Configure channel 1 device type disk format
'H:\oraback\backup_%U';
It is also possible the backup will
be attempting to write to a larger disk space than is available; there is not
enough disk space on the drive to complete the backup.
Failed to identify file
in RMAN: ORA-19505
After configuring the target
database with the RMAN first time. I try to take database backup through RMAN
and found the following error:
RMAN-00571:
===========================================================
RMAN-00569:
=============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571:
===========================================================
RMAN-03009: failure of
backup command on ch00 channel at 03/26/2012 13:01:03
ORA-19505: failed to
identify file “/oraback/arch/1_1100721_664058960.dbf”
ORA-27037: unable to
obtain file status
Linux-x86_64 Error: 2:
No such file or directory
In this case nothing happened with
your backup command. If you read the error, it is 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
RMAN>Delete expired
archivelog all;
This will prompt you YES or NO. If
you don’t want a prompt
RMAN>Delete
noprompt archivelog all;
3. Then take a fresh archivelog
backup
RMAN>Backup archivelog all;
RMAN-06172: no autobackup found tips
Recently I got the
issue from one of the user. He is getting the RMAN-06172 error with the restore
spfile command in case of disaster recovery. He is using oracle 10g on windows
2003. He states he has not tested his backup before
RMAN> restore
spfile from autobackup;
RMAN-03002: failure of
restore command at 04/01/2013 04:32:11
RMAN-06172: no
autobackup found or specified handle is not a valid copy or piece
Cause:
A restore could not
proceed because no autobackup was found or the specified handle is not a valid
copy or backup piece.
1. In case of restore from autobackup,
it may be the case that a backup exists, but it does not find the location of
backup due to not specify the real backup location.
2. In case of restore from backup, it
may be the backup is not a backup piece or controlfile copy. It may be that it
does not exist.
Solution:
The above error occurs
because RMAN does not find the controlfile or spfile location. Normally Oracle
looks the backup by default in the ORACLE_HOME/dbs directory if you are not
proving the destination with the spfile restore command. You need to change
your RMAN command to point to the real spfile location with the restore
command.
RMAN> Restore
spfile from autobackup db_recovery_file_dest='D:\oracle\flash_recovery_area'
db_name=’ORCL3’;
In the case when FRA
is not configured and autobackup control file location is not set
RMAN> CONFIGURE
CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR;
RMAN> Configure
controlfile autobackup on;
The backupset and
autobackup controlfile is created in default windows location:
"C:\windows\system32\", with DBID. For Example:
C:\WINDOWS\SYSTEM32\C-1681257132-20130102-02
comment=NONE
RMAN-06207, RMAN-06208, RMAN-06210 errors
Sometimes we are facing errors from RMAN for Oracle backup as following.
RMAN-06207: WARNING: 2 objects could not be deleted for DISK channel(s) due to mismatched status.
RMAN-06208: Use CROSSCHECK command to fix status
Solution:
To solve RMAN-06207, RMAN-06208, RMAN-06210 errors perform crosscheck command execution from rman prompt. This command will update RMAN’s metadata and catalog.
RMAN>crosscheck archivelog all;
If this command error doesn’t resolved then delete command can be helpful in this situation.
RMAN>DELETE FORCE OBSOLETE;
If above all commands do not working then kindly check from where are you executing above commands.
Because standby archives doesn’t register in primary database. For this situation execute above commands in standby and primary both with “crosscheck archivelog all” command also.
RMAN-05542: Only UNTIL TIME can be used with DUPLICATE without TARGET and CATALOG connections
RMAN-06207, RMAN-06208, RMAN-06210 errors
Sometimes we are facing errors from RMAN for Oracle backup as following.
RMAN-06207: WARNING: 2 objects could not be deleted for DISK channel(s) due to mismatched status.
RMAN-06208: Use CROSSCHECK command to fix status
Solution:
To solve RMAN-06207, RMAN-06208, RMAN-06210 errors perform crosscheck command execution from rman prompt. This command will update RMAN’s metadata and catalog.
RMAN>crosscheck archivelog all;
If this command error doesn’t resolved then delete command can be helpful in this situation.
RMAN>DELETE FORCE OBSOLETE;
If above all commands do not working then kindly check from where are you executing above commands.
Because standby archives doesn’t register in primary database. For this situation execute above commands in standby and primary both with “crosscheck archivelog all” command also.
RMAN-05542: Only UNTIL TIME can be used with DUPLICATE without TARGET and CATALOG connections
While trying to use
RMAN DUPLICATE DATABASE command without connecting to target or catalog
database, we are getting the following error:
DUPLICATE DATABASE to
TEST1
until SCN 3587956
SPFILE
SET CONTROL_FILES='D:\ORACLE\oradata\SADHAN\control01.ctl'
set db_file_name_convert='D:\ORACLE\ORADATA\SADHAN','D:\ORACLE\ORADATA\TEST'
set log_file_name_convert='D:\ORACLE\ORADATA\SADHAN ','D:\ORACLE\ORADATA\TEST'
backup location 'H:\ORABACK\SADHAN';
until SCN 3587956
SPFILE
SET CONTROL_FILES='D:\ORACLE\oradata\SADHAN\control01.ctl'
set db_file_name_convert='D:\ORACLE\ORADATA\SADHAN','D:\ORACLE\ORADATA\TEST'
set log_file_name_convert='D:\ORACLE\ORADATA\SADHAN ','D:\ORACLE\ORADATA\TEST'
backup location 'H:\ORABACK\SADHAN';
Cause: Only UNTIL TIME can be used with
DUPLICATE without TARGET and CATALOG connections or the situation if you
specify UNTIL clause but not putting the time based.
Action: Retry the command with an UNTIL
TIME clause or without an UNTIL clause.
Solution: When we change UNTIL SCN to UNTIL
TIME with specified parameter details, duplication process was successful.
DUPLICATE DATABASE to
TEST1
UNTIL TIME "To_Date('12-FEB-2013 07:45:28','DD-MON-YYYY HH24:MI:SS')"
SPFILE
SET CONTROL_FILES='D:\ORACLE\oradata\SADHAN\control01.ctl'
set db_file_name_convert='D:\ORACLE\ORADATA\SADHAN','D:\ORACLE\ORADATA\TEST'
set log_file_name_convert='D:\ORACLE\ORADATA\SADHAN ','D:\ORACLE\ORADATA\TEST'
backup location 'H:\ORABACK\SADHAN';
UNTIL TIME "To_Date('12-FEB-2013 07:45:28','DD-MON-YYYY HH24:MI:SS')"
SPFILE
SET CONTROL_FILES='D:\ORACLE\oradata\SADHAN\control01.ctl'
set db_file_name_convert='D:\ORACLE\ORADATA\SADHAN','D:\ORACLE\ORADATA\TEST'
set log_file_name_convert='D:\ORACLE\ORADATA\SADHAN ','D:\ORACLE\ORADATA\TEST'
backup location 'H:\ORABACK\SADHAN';
Reference:
For More RMAN related errors and their
solution, please search on this blog with the error code or follow the below
link.
Comments
Post a Comment