Backup Fails with Invalid RECID Error: RMAN-20035, RMAN-6038
When you attempt a backup and receive the following error messages:
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 RMAN. 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;
3. Do not forget to take the fresh backup after resetlogs option;
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/20/2018 06: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 19-AUG-18
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 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 20-AUG-18
RMAN-00571: ========================================
RMAN-00569: ========= ERROR MESSAGE STACK FOLLOWS =========
RMAN-00571: =========================================
RMAN-03002: failure of backup command at 20/08/2012 07: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 20/08/2018 07: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 20/08/2018 07: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 control file 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
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\RAM\control01.ctl'
set db_file_name_convert='D:\ORACLE\ORADATA\RAM','D:\ORACLE\ORADATA\TEST'
set log_file_name_convert='D:\ORACLE\ORADATA\RAM ','D:\ORACLE\ORADATA\TEST'
backup location 'H:\ORABACK\RAM';
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('20-AUG-2018 07:45:28','DD-MON-YYYY HH24:MI:SS')"
SPFILE
SET CONTROL_FILES='D:\ORACLE\oradata\RAM\control01.ctl'
set db_file_name_convert='D:\ORACLE\ORADATA\RAM','D:\ORACLE\ORADATA\TEST'
set log_file_name_convert='D:\ORACLE\ORADATA\RAM ','D:\ORACLE\ORADATA\TEST'
backup location 'H:\ORABACK\RAM';
When you attempt a backup and receive the following error messages:
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 RMAN. 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;
3. Do not forget to take the fresh backup after resetlogs option;
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/20/2018 06: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 19-AUG-18
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 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 20-AUG-18
RMAN-00571: ========================================
RMAN-00569: ========= ERROR MESSAGE STACK FOLLOWS =========
RMAN-00571: =========================================
RMAN-03002: failure of backup command at 20/08/2012 07: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 20/08/2018 07: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 20/08/2018 07: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 control file 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
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\RAM\control01.ctl'
set db_file_name_convert='D:\ORACLE\ORADATA\RAM','D:\ORACLE\ORADATA\TEST'
set log_file_name_convert='D:\ORACLE\ORADATA\RAM ','D:\ORACLE\ORADATA\TEST'
backup location 'H:\ORABACK\RAM';
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('20-AUG-2018 07:45:28','DD-MON-YYYY HH24:MI:SS')"
SPFILE
SET CONTROL_FILES='D:\ORACLE\oradata\RAM\control01.ctl'
set db_file_name_convert='D:\ORACLE\ORADATA\RAM','D:\ORACLE\ORADATA\TEST'
set log_file_name_convert='D:\ORACLE\ORADATA\RAM ','D:\ORACLE\ORADATA\TEST'
backup location 'H:\ORABACK\RAM';