PL/SQL package CATDBA.DBMS_RCVCAT version 11.02.00.02 in RCVCAT database is not current
Problem Description
While starting Oracle RMAN backup whenever we use catalog database as repository it fails with following errors:
Depending on the version of the RMAN-catalog schema version there might notice following errors.
Whenever it is issued "register database" it fails with following error:
Resync catalog also fails with following error:
Recent Changes
The target database has been recently upgrades and so RMAN executable is upgraded but catalog database is not aware of this upgrade.
Cause of the Problem
The problem happened due to version mismatch between the RMAN-executable and the RMAN-catalog SCHEMA.
Solution of the Problem
Solution 01:
Upgrade the RMAN catalog SCHEMA. Start the RMAN-executable from the ORACLE_HOME which has been upgraded. There is only a connection to the CATALOG required.
A connection to the TARGET is optional.
For example issue,
Don't use catalog for backup information. So run backup without connecting catalog database.
While starting Oracle RMAN backup whenever we use catalog database as repository it fails with following errors:
$rman target / catalog catdba@RMAN Recovery Manager: Release 11.2.0.3.0 - Production on Tue Nov 22 22:30:47 2011 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. connected to target database: SPMDP (DBID=2694055214) recovery catalog database Password: connected to recovery catalog database PL/SQL package CATDBA.DBMS_RCVCAT version 11.02.00.02 in RCVCAT database is not current PL/SQL package CATDBA.DBMS_RCVMAN version 11.02.00.02 in RCVCAT database is not current
Depending on the version of the RMAN-catalog schema version there might notice following errors.
PL/SQL package RMAN.DBMS_RCVCAT version 11.01.00.07 in RCVCAT database is not current PL/SQL package RMAN.DBMS_RCVMAN version 11.01.00.07 in RCVCAT database is not currentor,
PL/SQL package RMAN.DBMS_RCVCAT version 11.02.00.01 in RCVCAT database is not current PL/SQL package RMAN.DBMS_RCVMAN version 11.02.00.01 in RCVCAT database is not current
Whenever it is issued "register database" it fails with following error:
RMAN> register database;
DBGSQL: RCVCAT> begin dbms_rcvman.dumpPkgState('RCVMAN after sqlerror'); end;
DBGSQL: sqlcode = 6550
DBGSQL: RCVCAT> begin dbms_rcvcat.dumpPkgState('RCVCAT after sqlerror');end;
DBGSQL: sqlcode = 6550
database registered in recovery catalog
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03008: error while performing automatic resync of recovery catalog
RMAN-10015: error compiling PL/SQL program
RMAN-10014: PL/SQL error 0 on line 1655 column 12: Statement ignored
RMAN-10014: PL/SQL error 306 on line 1655 column 12: wrong number or types of arguments in call to 'CHECKTABLESPACE'
Resync catalog also fails with following error:
RMAN> resync catalog; RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03009: failure of resync command on default channel at 11/22/2011 23:09:07 RMAN-10015: error compiling PL/SQL program RMAN-10014: PL/SQL error 0 on line 1655 column 12: Statement ignored RMAN-10014: PL/SQL error 306 on line 1655 column 12: wrong number or types of arguments in call to 'CHECKTABLESPACE'
Recent Changes
The target database has been recently upgrades and so RMAN executable is upgraded but catalog database is not aware of this upgrade.
Cause of the Problem
The problem happened due to version mismatch between the RMAN-executable and the RMAN-catalog SCHEMA.
Solution of the Problem
Solution 01:
Upgrade the RMAN catalog SCHEMA. Start the RMAN-executable from the ORACLE_HOME which has been upgraded. There is only a connection to the CATALOG required.
A connection to the TARGET is optional.
For example issue,
$ rman catalog $RMAN_USERID/$RMAN_PASSWD@$RMAN_CONN_STR RMAN> upgrade catalog;Solution 02:
Don't use catalog for backup information. So run backup without connecting catalog database.
$ rman target / $ backup database;
RMAN Backup on RAC fails with ORA-00245: control file backup operation failed
Problem Description
In Oracle database version 11.2g RMAN Backup on RAC database fails with following errors while doing controlfile autobackup.
From Oracle documentation we get following information about the error ORA-00245.
ORA-00245 "control file backup failed; target is likely on a local file system"
// *Cause: Failed to create a control file backup because some process
// signaled an error during backup creation. This is likely caused
// by the backup target being on a local file system so it could not
// be accessed by other instances. It can also be caused by other
// I/O errors to the backup target. Any process of any instance that
// starts a read/write control file transaction must have access
// to the backup control file during backup creation.
// *Action: Check alert files of all instances for further information.
RMAN creates a copy of the control file for read consistency, this is the snapshot controlfile. Due to the changes made to the controlfile backup mechanism in 11gR2 any instances in the cluster may write to the snapshot controlfile. Therefore, the snapshot controlfile file needs to be visible to all instances.
The same happens when a backup of the controlfile is created directly from sqlplus any instance in the cluster may write to the backup controfile file.
In 11gR2 onwards, the controlfile backup happens without holding the control file enqueue. For non-RAC database, this doesn't change anything.
But, for RAC database, the snapshot controlfile location must be in a shared file system that will be accessible from all the nodes. So if you put your snapshot controlfile in local file system and if that file are not accessible to other nodes of the RAC database you will likely face Oracle error ORA-00245.
Solution of the Problem
The snapshot controlfile must be accessible by all nodes of a RAC database. If the snapshot controlfile does not reside in on a shared device this error will raise.
1. Check the existing snapshot controlfile location:
rman> show all;
2. Configure the snapshot controlfile to a shared disk:
rman> CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'shared_disk/snapcf.f'; # default
In Oracle database version 11.2g RMAN Backup on RAC database fails with following errors while doing controlfile autobackup.
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03009: failure of Control File and SPFILE Autobackup command on ORA_DISK_1 channel at 301/10/2011 12:10:12 ORA-00245: control file backup operation failedWhile backing up through Sql*plus ORA-00245 error also returned.
alter database backup controlfile to '/oracle/cntl_file' ERROR at line 1: ORA-00245: control file backup operation failedCause of the Problem
From Oracle documentation we get following information about the error ORA-00245.
ORA-00245 "control file backup failed; target is likely on a local file system"
// *Cause: Failed to create a control file backup because some process
// signaled an error during backup creation. This is likely caused
// by the backup target being on a local file system so it could not
// be accessed by other instances. It can also be caused by other
// I/O errors to the backup target. Any process of any instance that
// starts a read/write control file transaction must have access
// to the backup control file during backup creation.
// *Action: Check alert files of all instances for further information.
RMAN creates a copy of the control file for read consistency, this is the snapshot controlfile. Due to the changes made to the controlfile backup mechanism in 11gR2 any instances in the cluster may write to the snapshot controlfile. Therefore, the snapshot controlfile file needs to be visible to all instances.
The same happens when a backup of the controlfile is created directly from sqlplus any instance in the cluster may write to the backup controfile file.
In 11gR2 onwards, the controlfile backup happens without holding the control file enqueue. For non-RAC database, this doesn't change anything.
But, for RAC database, the snapshot controlfile location must be in a shared file system that will be accessible from all the nodes. So if you put your snapshot controlfile in local file system and if that file are not accessible to other nodes of the RAC database you will likely face Oracle error ORA-00245.
Solution of the Problem
The snapshot controlfile must be accessible by all nodes of a RAC database. If the snapshot controlfile does not reside in on a shared device this error will raise.
1. Check the existing snapshot controlfile location:
rman> show all;
2. Configure the snapshot controlfile to a shared disk:
rman> CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'shared_disk/snapcf.f'; # default
RMAN-20070 on RESYNC or CROSSCHECK archivelog
Problem Description
After switchover operation standby database now becomes primary database and now database backups, crosscheck archivelog all on new primary database fails with error RMAN-20070.
This issue is due to Oracle Bug:4755799 RMAN-20070 ERROR ON PRIMARY AFTER DATAGUARD SWITCHOVER
RMAN-20070 can occur during RMAN resync after a dataguard switchover. Also this bug can appear on using CROSSCHECK as it also implies a resync.
This bug remains in,
9.2.0.4 to 9.2.0.8
10.1 to 10.1.0.4
10.2.0.1 to 10.2.0.2
However, this issue does not affect 10.1.0.5, 10.2.0.3 or higher, and 11g.
Solution of the Problem
Workaround:
Disable the rlh_u2 constraint after connecting to the recovery catalog schema.
$ sqlplus rman/rman@catalog_db
SQL> alter table rlh modify constraint rlh_u2 disable ;
Fix:
- Upgrade to 11g, 10.2.0.3 or 10.1.0.5 (fixed versions)
- Apply patch 4755799 if it is available for your platform and release.
After switchover operation standby database now becomes primary database and now database backups, crosscheck archivelog all on new primary database fails with error RMAN-20070.
RMAN> CROSSCHECK archivelog all; starting full resync of recovery catalog RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of crosscheck command at 30/10/2011 12:13:00 RMAN-03014: implicit resync of recovery catalog failed RMAN-03009: failure of full resync command on default channel at 30/10/2011 12:13:00 RMAN-20070: invalid log history sequence#Cause of the Problem
This issue is due to Oracle Bug:4755799 RMAN-20070 ERROR ON PRIMARY AFTER DATAGUARD SWITCHOVER
RMAN-20070 can occur during RMAN resync after a dataguard switchover. Also this bug can appear on using CROSSCHECK as it also implies a resync.
This bug remains in,
9.2.0.4 to 9.2.0.8
10.1 to 10.1.0.4
10.2.0.1 to 10.2.0.2
However, this issue does not affect 10.1.0.5, 10.2.0.3 or higher, and 11g.
Solution of the Problem
Workaround:
Disable the rlh_u2 constraint after connecting to the recovery catalog schema.
$ sqlplus rman/rman@catalog_db
SQL> alter table rlh modify constraint rlh_u2 disable ;
Fix:
- Upgrade to 11g, 10.2.0.3 or 10.1.0.5 (fixed versions)
- Apply patch 4755799 if it is available for your platform and release.
RMAN-20032 while taking backup using RMAN with catalog
Problem Description
Backup of Oracle database using RMAN with catalog fails with RMAN-20032:
Cause of the Problem
Database was resorted from the cold backup. Catalog can not be reseted for this change.
Reset database will not work as open resertlogs is a prerequisite for reset.
Solution of the Problem
$ rman TARGET / CATALOG rman/password@catalog
RMAN> UNREGISTER DATABASE NOPROMPT;
RMAN> REGISTER DATABASE;
Backup of Oracle database using RMAN with catalog fails with RMAN-20032:
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of show command at 30/10/2011 10:21:12 RMAN-03014: implicit resync of recovery catalog failed RMAN-03009: failure of full resync command on default channel at 30/10/2011 10:21:12 RMAN-20032: checkpoint change# too low
Cause of the Problem
Database was resorted from the cold backup. Catalog can not be reseted for this change.
Reset database will not work as open resertlogs is a prerequisite for reset.
Solution of the Problem
$ rman TARGET / CATALOG rman/password@catalog
RMAN> UNREGISTER DATABASE NOPROMPT;
RMAN> REGISTER DATABASE;
ORA-30036 error in undo tablespace during RMAN backup
Problem Description
During Oracle RMAN database backup ORA-30036 error is raised.
Cause of the Problem
The problem happened due to oracle bug 8416270 - ORA-30036 DURING RMAN RESYNC.
Solution of the Problem
Workaround of this bug is to turn off undo autotune hidden parameter in init.ora:
_undo_autotune = false
If you are using spfile, then you have to issue,
alter system set "_undo_autotune" = false scope=spfile;
shutdown immediate
startup
Note that, with _undo_autotune=false, statistics tracking on UNDO is no longer available (for example, in V$UNDOSTAT).
During Oracle RMAN database backup ORA-30036 error is raised.
starting full resync of recovery catalog RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of show command at 30/10/2011 10:32:12 RMAN-03014: implicit resync of recovery catalog failed RMAN-03009: failure of full resync command on default channel at 30/10/2011 10:32:12 ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS1'The funny thing is error is not reported in alert log and does not generate trace files.
Cause of the Problem
The problem happened due to oracle bug 8416270 - ORA-30036 DURING RMAN RESYNC.
Solution of the Problem
Workaround of this bug is to turn off undo autotune hidden parameter in init.ora:
_undo_autotune = false
If you are using spfile, then you have to issue,
alter system set "_undo_autotune" = false scope=spfile;
shutdown immediate
startup
Note that, with _undo_autotune=false, statistics tracking on UNDO is no longer available (for example, in V$UNDOSTAT).
RMAN backup using catalog database terminates with deadlock Error ORA-00060
Problem Description
RMAN backups that use catalog database fails with following deadlock errors.
DELETE FROM CKP WHERE DBINC_KEY = :B1 AND CKP_KEY IN (SELECT CKP_KEY1 FROM
(SELECT CKP_KEY CKP_KEY1 FROM CKP WHERE DBINC_KEY = :B1 ) CKP1, (SELECT :B2
CKP_KEY2 FROM DUAL UNION SELECT :B3 FROM DUAL UNION SELECT NVL(MAX(CKP_KEY),0) F
ROM CKP WHERE DBINC_KEY=:B1 UNION SELECT START_CKP_KEY FROM TSATT WHERE DBINC_KE
Y = :B1 UNION SELECT NVL(END_CKP_KEY,0) FROM TSATT WHERE DBINC_KEY = :B1 UNION S
ELECT START_CKP_KEY FROM DFATT WHERE DBINC_KEY = :B1 UNION SELECT NVL(END_CKP_KE
Y,0) FROM DFATT WHERE DBINC_KEY = :B1 UNION SELECT START_CKP_KEY FROM TFATT WHER
E DBINC_KEY = :B1 UNION SELECT NVL(END_CKP_KEY,0) FROM TFATT WHERE DBINC_KEY = :
B1 ) CKP2 WHERE CKP_KEY1 = CKP_KEY2(+) AND CKP_KEY2 IS NULL)
Cause of the Problem
Oracle is buggy product. And this issue is due to Bug 6830296.
Solution of Problem
Workaround
In RMAN catalog database create the following indexes :
CREATE INDEX tfatt_i_sck on tfatt(start_ckp_key) ;
CREATE INDEX tfatt_i_eck on tfatt(end_ckp_key) ;
You can also check for availability of one off patch 6830296.
RMAN backups that use catalog database fails with following deadlock errors.
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of backup plus archivelog command at 30/10/2011 12:00:40 RMAN-03014: implicit resync of recovery catalog failed RMAN-03009: failure of partial resync command on default channel at 30/10/2011 12:00:40 ORA-00060: deadlock detected while waiting for resourceDead lock trace file contains the following statement
DELETE FROM CKP WHERE DBINC_KEY = :B1 AND CKP_KEY IN (SELECT CKP_KEY1 FROM
(SELECT CKP_KEY CKP_KEY1 FROM CKP WHERE DBINC_KEY = :B1 ) CKP1, (SELECT :B2
CKP_KEY2 FROM DUAL UNION SELECT :B3 FROM DUAL UNION SELECT NVL(MAX(CKP_KEY),0) F
ROM CKP WHERE DBINC_KEY=:B1 UNION SELECT START_CKP_KEY FROM TSATT WHERE DBINC_KE
Y = :B1 UNION SELECT NVL(END_CKP_KEY,0) FROM TSATT WHERE DBINC_KEY = :B1 UNION S
ELECT START_CKP_KEY FROM DFATT WHERE DBINC_KEY = :B1 UNION SELECT NVL(END_CKP_KE
Y,0) FROM DFATT WHERE DBINC_KEY = :B1 UNION SELECT START_CKP_KEY FROM TFATT WHER
E DBINC_KEY = :B1 UNION SELECT NVL(END_CKP_KEY,0) FROM TFATT WHERE DBINC_KEY = :
B1 ) CKP2 WHERE CKP_KEY1 = CKP_KEY2(+) AND CKP_KEY2 IS NULL)
Cause of the Problem
Oracle is buggy product. And this issue is due to Bug 6830296.
Solution of Problem
Workaround
In RMAN catalog database create the following indexes :
CREATE INDEX tfatt_i_sck on tfatt(start_ckp_key) ;
CREATE INDEX tfatt_i_eck on tfatt(end_ckp_key) ;
You can also check for availability of one off patch 6830296.
RMAN backup fails with errors RMAN-03014 RMAN-03009 ORA-01580 ORA-27037
Problem Description
Oracle database backup and maintenance commands fail with following errors:
The error occurred due to wrong name in snapshot control file. You have to specify full name of snapshot control file including file name. By default snapshot controlfile name is '$ORACLE/HOME/dbs/snapcf_$ORACLE_SID.f'. Instead of snapshot controlfile name if only the directory is given, you will see above errors.
For example if you specify following command in RMAN you will face this error.
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u011/app/oracle/admin/BDDBA/snapctl';
Because here file name is not given, only the location is specified in the configure snapshot controlfile name.
Solution of the Problem
Connect to RMAN with nocatalog option and then set the snapshot controlfile to the proper location and specify name.
$ rman target / nocatalog
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u011/app/oracle/admin/BDDBA/snapctl/snapcf_ora10g.f';
Once the snapshot controlfile name is set properly; the backups or maintenance operation can be performed successfully without any error.
Oracle database backup and maintenance commands fail with following errors:
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of show command at 30/10/2011 19:26:33 RMAN-03014: implicit resync of recovery catalog failed RMAN-03009: failure of full resync command on default channel at 30/10/2011 19:26:33 ORA-01580: error creating control backup file /u011/app/oracle/admin/BDDBA/snapctl/ ORA-27037: unable to obtain file status SVR4 Error: 20: Not a directory Additional information: 6Cause of the Problem
The error occurred due to wrong name in snapshot control file. You have to specify full name of snapshot control file including file name. By default snapshot controlfile name is '$ORACLE/HOME/dbs/snapcf_$ORACLE_SID.f'. Instead of snapshot controlfile name if only the directory is given, you will see above errors.
For example if you specify following command in RMAN you will face this error.
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u011/app/oracle/admin/BDDBA/snapctl';
Because here file name is not given, only the location is specified in the configure snapshot controlfile name.
Solution of the Problem
Connect to RMAN with nocatalog option and then set the snapshot controlfile to the proper location and specify name.
$ rman target / nocatalog
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u011/app/oracle/admin/BDDBA/snapctl/snapcf_ora10g.f';
Once the snapshot controlfile name is set properly; the backups or maintenance operation can be performed successfully without any error.
ORA-3135: connection lost contact during RMAN backup
Problem Description
Database version is 10.2.0.3 and it is 5 nodes RAC on Red Hat Enterprise Linux. RMAN backup is integrated with Veritas Netbackup 5.1 (MP6). Whenever run backup operation is going to be hanged for long periods of time and then generates error:
ORA-3135: connection lost contact
once if we kill the backup job everything goes back to normal.
Investigation
From the OEM ADDM it is found followings:
FINDING 1: 100% impact (98213 seconds)
---------------------------------------------
Wait class "Scheduler" was consuming significant database time.
Cause of the Problem
This is Oracle bug specifically Bug 6874858 Poor performance with Resource Manager when RMAN is running. When RMAN is running with Resource Manager enabled, the performance of the system may degrade. Users may have problems logging in. When this occurs large waits will be seen with the wait event "resmgr:cpu quantum" with low CPU utilization.
Solution of the Problem
Workaround you can disable Oracle Resource Manager.
However this bug is fixed in following versions:
- 11.2.0.1 (Base Release)
- 11.1.0.7 (Server Patch Set)
- 10.2.0.5 (Server Patch Set)
- 11.1.0.6 Patch 11 on Windows Platforms
- 10.2.0.4 Patch 41 on Windows Platforms
So upgrade to your Oracle database is another solution.
Database version is 10.2.0.3 and it is 5 nodes RAC on Red Hat Enterprise Linux. RMAN backup is integrated with Veritas Netbackup 5.1 (MP6). Whenever run backup operation is going to be hanged for long periods of time and then generates error:
ORA-3135: connection lost contact
once if we kill the backup job everything goes back to normal.
Investigation
From the OEM ADDM it is found followings:
FINDING 1: 100% impact (98213 seconds)
---------------------------------------------
Wait class "Scheduler" was consuming significant database time.
Cause of the Problem
This is Oracle bug specifically Bug 6874858 Poor performance with Resource Manager when RMAN is running. When RMAN is running with Resource Manager enabled, the performance of the system may degrade. Users may have problems logging in. When this occurs large waits will be seen with the wait event "resmgr:cpu quantum" with low CPU utilization.
Solution of the Problem
Workaround you can disable Oracle Resource Manager.
However this bug is fixed in following versions:
- 11.2.0.1 (Base Release)
- 11.1.0.7 (Server Patch Set)
- 10.2.0.5 (Server Patch Set)
- 11.1.0.6 Patch 11 on Windows Platforms
- 10.2.0.4 Patch 41 on Windows Platforms
So upgrade to your Oracle database is another solution.
RMAN backup Fails with ORA-19510 and ORA-27046
Problem Description
RMAN backup failed with error message RMAN-03009, ORA-19510 and ORA-27046.
Cause of the Problem
Note that, there are several variants of this ORA-19510 error. You can search for ORA-19510 within my blog. In this case problem started due to the operating system size limit. RMAN backup piece size exceed the max file size limit of the O/S.
Solution of the Problem
Make sure that rman backup piece won't exceed the O/S permitted filesize limit. You can restrict the rman backup piece using the MAXPIECESIZE option.
For example in RMAN prompt issue,
RMAN> Configure channel device type disk MAXPIECESIZE = 2G;
And then run your backup command again.
RMAN> backup database ;
RMAN backup failed with error message RMAN-03009, ORA-19510 and ORA-27046.
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03009: failure of backup command on channel1 channel at 20/12/2010 01:22:21 ORA-19510: failed to set size of 262143 blocks for file "/backup/database/prod/hot_backup.rman" (blocksize=) ORA-27046: file size is not a multiple of logical block size Additional information: 2
Cause of the Problem
Note that, there are several variants of this ORA-19510 error. You can search for ORA-19510 within my blog. In this case problem started due to the operating system size limit. RMAN backup piece size exceed the max file size limit of the O/S.
Solution of the Problem
Make sure that rman backup piece won't exceed the O/S permitted filesize limit. You can restrict the rman backup piece using the MAXPIECESIZE option.
For example in RMAN prompt issue,
RMAN> Configure channel device type disk MAXPIECESIZE = 2G;
And then run your backup command again.
RMAN> backup database ;
ORA-19510, ORA-27044 HP-UX Error: 2: No such file or directory
Problem Description
While taking RMAN backup it fails with following message.
Cause of the Problem
The backup fails as there is no space available on the disk.
Solution of the Problem
Check the space where you are taking RMAN backup. For example, in this case we see backup is generated in the location /backup/PROD_DATABASE/rman/ so check disk space usage or free disk space remained into /backup partition. You can check space usage on unix file system by using du -sh * comamnd. You can also issue,
$df -h
to see free space available.
In order to take backup you need to delete unnecessary files from the partition.
While taking RMAN backup it fails with following message.
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03009: failure of backup command on channel1 channel at 12/20/2010 01:30:21 ORA-19510: failed to set size of 6410 blocks for file "/backup/PROD_DATABASE/rman/PROD_tdatabase_s2398_LVL_1" (blocksize=8192) ORA-27044: unable to write the header block of file HP-UX Error: 2: No such file or directory Additional information: 7 ORA-19510: failed to set size of 4294967295 blocks for file "/backup/PROD_DATABASE/rman/PROD_tdatabase_s2398_LVL_1" (blocksize=8192) ORA-27044: unable to write the header block of file
Cause of the Problem
The backup fails as there is no space available on the disk.
Solution of the Problem
Check the space where you are taking RMAN backup. For example, in this case we see backup is generated in the location /backup/PROD_DATABASE/rman/ so check disk space usage or free disk space remained into /backup partition. You can check space usage on unix file system by using du -sh * comamnd. You can also issue,
$df -h
to see free space available.
In order to take backup you need to delete unnecessary files from the partition.
RMAN-03009, ORA-19510, ORA-27037, IBM AIX RISC System/6000 Error
Problem Description
While taking RMAN backup it fails with following errors:
The problem occurred because backup piece is being removed from disk before the backup finished. That means backup piece is deleted before RMAN completely finishes creating it. In fact there was a scheduled cron purge job that conflicted with the RMAN backup and was removing the piece before RMAN finished creating it.
Solution of the Problem
The solution is schedule the cron purge job to run at a different time to allow the RMAN backup job to complete or remove the cron purge job entirely.
While taking RMAN backup it fails with following errors:
RMAN-03009: failure of backup command on DISK1 channel at 09/19/2005 19:51:02 ORA-19510: failed to set size of 268930 blocks for file "/backup/rman/backup/full/rman_complete_backup" (blocksize=8192) ORA-27037: unable to obtain file status IBM AIX RISC System/6000 Error: 2: No such file or directory Additional information: 5Cause of the Problem
The problem occurred because backup piece is being removed from disk before the backup finished. That means backup piece is deleted before RMAN completely finishes creating it. In fact there was a scheduled cron purge job that conflicted with the RMAN backup and was removing the piece before RMAN finished creating it.
Solution of the Problem
The solution is schedule the cron purge job to run at a different time to allow the RMAN backup job to complete or remove the cron purge job entirely.
RMAN-03002, RMAN-06059, ORA-19625 and ORA-27037 during RMAN archivelog backup
Problem Description
The problem happened because Oracle archivelog files were deleted at OS level.
Solution of the Problem
Run following commands in your RMAN prompt to resolve the issue,
After you run the above commands in your RMAN prompt RMAN will unlink all archived log entry from its repository. But due to oracle bug
- if still it can't delete or,
- delete force obsolete and delete expired archivelog all fails with segmentation errors or,
- delete is succeed but still you face RMAN-03002, RMAN-06059, ORA-19625 and ORA-27037 error then do the following:
Rman> Change archivelog '{location of archivelog which is deleted}' UNCATALOG ;
Please note the first archive log name would be present in the error message ORA-19625:
For example in our case our error output was:
Rman> Change archivelog '/u01/app/oracle/admin/ORACLE/arch/arch_94049.log' uncatalog;
Run the archive log backup command check if you still get the error
Keeping specify the archive log file name reported in ORA-19625 till backup of archive log goes fine.
If there is so many archivelog you deleted from specify then alternatively you can do the following as each time specifying the name will take much time.
Rman> Change archivelog all uncatalog ;
Please note the above command will uncatalog the information about the Archive log from catalog database.
Starting backup at 19-OCT-2010 00:31:37 current log archived released channel: channel1 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of backup command at 10/19/2010 00:32:03 RMAN-06059: expected archived log not found, lost of archived log compromises recoverability ORA-19625: error identifying file /u01/app/oracle/admin/ORACLE/arch/arch_94049.log ORA-27037: unable to obtain file status HP-UX Error: 2: No such file or directory Additional information: 3Cause of the Problem
The problem happened because Oracle archivelog files were deleted at OS level.
Solution of the Problem
Run following commands in your RMAN prompt to resolve the issue,
Rman> Crosscheck copy of archivelog all; Rman> Crosscheck archivelog all; Rman> Resync catalog; Rman> delete force obsolete; Rman> delete expired archivelog all ;
After you run the above commands in your RMAN prompt RMAN will unlink all archived log entry from its repository. But due to oracle bug
- if still it can't delete or,
- delete force obsolete and delete expired archivelog all fails with segmentation errors or,
- delete is succeed but still you face RMAN-03002, RMAN-06059, ORA-19625 and ORA-27037 error then do the following:
Rman> Change archivelog '{location of archivelog which is deleted}' UNCATALOG ;
Please note the first archive log name would be present in the error message ORA-19625:
For example in our case our error output was:
RMAN-06059: expected archived log not found, lost of archived log compromises recoverability ORA-19625: error identifying file /u01/app/oracle/admin/ORACLE/arch/arch_94049.log ORA-27037: unable to obtain file status HP-UX Error: 2: No such file or directorySo run the following command,
Rman> Change archivelog '/u01/app/oracle/admin/ORACLE/arch/arch_94049.log' uncatalog;
Run the archive log backup command check if you still get the error
Keeping specify the archive log file name reported in ORA-19625 till backup of archive log goes fine.
If there is so many archivelog you deleted from specify then alternatively you can do the following as each time specifying the name will take much time.
Rman> Change archivelog all uncatalog ;
Please note the above command will uncatalog the information about the Archive log from catalog database.
Creation of second standby database using RMAN DUPLICATE fails with RMAN-20242
Problem Description
You can run the following command to create a physical standby database from the primary database.
RMAN-20242
The problem happened due to oracle bug. If the source database has standby destination, then while copying archived logs from the source database the bug will fire. Oracle named this bug as Bug 6603587.
Solution of the Problem
Solution 01: This bug is fixed in Oracle 11.2 and in patchset 11.1.0.7. So upgrade your current oracle software is a solution.
Solution 02: For DUPLICATE DATABASE FOR STANDBY FROM ACTIVE, simply avoid using the DORECOVER clause. Logs will ship naturally as part of the standby log shipping.
Solution 03: For DUPLICATE TARGET DATABASE ... FROM ACTIVE, defer all standby destinations prior to executing the command. For example, issue
alter system set LOG_ARCHIVE_DEST_STATE_2=DEFER scope=both sid='*';
where LOG_ARCHIVE_DEST_STATE_2 is standby destination.
You can run the following command to create a physical standby database from the primary database.
run{
allocate channel prmy1 type disk;
allocate channel prmy2 type disk;
allocate auxiliary channel stby1 type disk;
duplicate target database for standby from active database
spfile
parameter_value_convert 'BDDIPDC','BDDIPDRS'
set db_file_name_convert='/BDDIPDC/','/BDDIPDRS/'
set log_file_name_convert='/BDDIPDC/','/BDDIPDRS/'
set 'db_unique_name'='BDDIPDRS'
set control_files='+DATA/BDDIPDRS/control01.ctl','+DATA/BDDIPDRS/control02.ctl'
set db_recovery_file_dest='+RECOVERY/BDDIPDRS'
set DB_RECOVERY_FILE_DEST_SIZE='500G'
nofilenamecheck;
}
So you have one primary and one physical standby database. Now you
want to add another standby database in your Data Guard environment.
And you issued following command but it failed with RMAN-20242
rman target sys/sys@bddipdc auxiliary sys/sys@bddipdrs DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE DORECOVER SPFILE SET db_unique_name = 'BDDIPDRS' SET FAL_CLIENT = 'BDDIPDRS' SET FAL_SERVER = 'BDDIPDC' set log_archive_dest_1 = 'LOCATION=USE_DB_RECOVERY_FILE_DEST valid_for=(all_logfiles,all_roles) db_unique_name=x11106_stby2' set log_archive_dest_2 = 'db_unique_name=BDDIPDC SERVICE=BDDIPDC valid_for=(online_logfile, primary_role) REOPEN=60 OPTIONAL LGWR SYNC AFFIRM' CONTROL_FILES='+DATA/BDDIPDRS/control01.dbf' set DB_FILE_NAME_CONVERT='/BDDIPDC/','/BDDIPDRS/' set LOG_FILE_NAME_CONVERT='/BDDIPDC/','/BDDIPDRS/' NOFILENAMECHECK;Following is the error output,
RMAN-8162: executing Memory Script RMAN-3090: Starting backup at 01-NOV-10 RMAN-12016: using channel ORA_DISK_1 RMAN-571: =========================================================== RMAN-569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-571: =========================================================== RMAN-3002: failure of Duplicate Db command at 11/01/2010 04:26:39 RMAN-3015: error occurred in stored script Memory Script RMAN-20242: specification does not match any archived log in the recovery catalogCause of the Problem
The problem happened due to oracle bug. If the source database has standby destination, then while copying archived logs from the source database the bug will fire. Oracle named this bug as Bug 6603587.
Solution of the Problem
Solution 01: This bug is fixed in Oracle 11.2 and in patchset 11.1.0.7. So upgrade your current oracle software is a solution.
Solution 02: For DUPLICATE DATABASE FOR STANDBY FROM ACTIVE, simply avoid using the DORECOVER clause. Logs will ship naturally as part of the standby log shipping.
Solution 03: For DUPLICATE TARGET DATABASE ... FROM ACTIVE, defer all standby destinations prior to executing the command. For example, issue
alter system set LOG_ARCHIVE_DEST_STATE_2=DEFER scope=both sid='*';
where LOG_ARCHIVE_DEST_STATE_2 is standby destination.
RMAN duplicate fails with RMAN-10006, ORA-03113, ORA-01092
Problem Description
While duplicating database using RMAN it fails with ORA-01092: "ORACLE instance terminated. Disconnection forced" and ora-03113 error reported.
Cause of the Problem
The UNDO_TABLESPACE parameter of auxiliary database is not same as target database. In the source database undo tablespace is set to UNDOTBS2 while in target database undo tablespace is set to UNDOTBS1. The undo tablespace specified in the auxiliary database parameter file does not exist.
Solution of the Problem
Make sure that the undo tablespace for auxiliary database is same as of target database.
Edit the init.ora or alter the UNDO_TABLESPACE parameter of the auxiliary instance and set
undo_tablespace = UNDOTBS2
- restart the auxiliary instance in nomount mode and repeat the duplicate database command.
While duplicating database using RMAN it fails with ORA-01092: "ORACLE instance terminated. Disconnection forced" and ora-03113 error reported.
RMAN-00601: fatal error in recovery manager RMAN-03004: fatal error during execution of command RMAN-10039: error encountered while polling for RPC completion on channel clone_default RMAN-10006: error running SQL statement: select act from x$ksusex where sid=:1 and serial=:2 RMAN-10002: ORACLE error: ORA-03113: end-of-file on communication channel RMAN-03002: failure of Duplicate Db command at 02/30/2010 01:21:18 RMAN-03015: error occurred in stored script Memory Script RMAN-06136: ORACLE error from auxiliary database: ORA-01092: ORACLE instance terminated. Disconnection forcedIf we look for the auxiliary database alert.log file then it shows that Undo Tablespace 'UNDOTBS1' does not exist or of wrong type.
Cause of the Problem
The UNDO_TABLESPACE parameter of auxiliary database is not same as target database. In the source database undo tablespace is set to UNDOTBS2 while in target database undo tablespace is set to UNDOTBS1. The undo tablespace specified in the auxiliary database parameter file does not exist.
Solution of the Problem
Make sure that the undo tablespace for auxiliary database is same as of target database.
Edit the init.ora or alter the UNDO_TABLESPACE parameter of the auxiliary instance and set
undo_tablespace = UNDOTBS2
- restart the auxiliary instance in nomount mode and repeat the duplicate database command.
RMAN duplicate database fails with RMAN-00601, RMAN-10006, ORA-00704, ORA-39700
Problem Description
Duplicating database using RMAN fails with following errors.
Cause of the Problem
The errors occurred because the Oracle versions for both the target database home and the auxiliary database home are not same.
Solution of the Problem
The solution is to upgrade the auxiliary database server binaries to match the target database server. Also if there is one off patches that exist on the target database, you also need to apply on the auxiliary database in order to make the duplication work.
Duplicating database using RMAN fails with following errors.
channel channel1: starting piece 1 at 29-JUL-2010 03:49:19 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-00601: fatal error in recovery manager RMAN-03004: fatal error during execution of command RMAN-10039: error encountered while polling for RPC completion on channel channel1 RMAN-10006: error running SQL statement: select action from gv$session where sid=:1 and serial#=:2 and inst_id=:3 RMAN-10002: ORACLE error: ORA-3114: not connected to ORACLE RMAN-10041: Could not re-create polling channel context following failure. RMAN-10024: error setting up for rpc polling RMAN-10005: error opening cursor RMAN-10002: ORACLE error: ORA-3114: not connected to ORACLE RMAN-03002: failure of Duplicate Db command at 02/23/2007 11:11:50 RMAN-03015: error occurred in stored script Memory Script RMAN-06136: ORACLE error from auxiliary database: ORA-1092: ORACLE instance terminated. Disconnection forced ORA-00704: bootstrap process failure ORA-39700: database must be opened with UPGRADE option
Cause of the Problem
The errors occurred because the Oracle versions for both the target database home and the auxiliary database home are not same.
Solution of the Problem
The solution is to upgrade the auxiliary database server binaries to match the target database server. Also if there is one off patches that exist on the target database, you also need to apply on the auxiliary database in order to make the duplication work.
Thursday, June 10, 2010
crosscheck archivelog fails with validation failed for archived log
Problem Description
Whenever I run "crosscheck archivelog all" it failed with message "validation failed for archived log" like below.
The problem happened because archive log file destination was changed or someone deleted the archive log files manually using OS commands.
Solution of the Problem
The solution is to delete the expired archive log files. So do following,
$ rman
RMAN> connect target /
RMAN> crosscheck archivelog all;
RMAN> delete expired archivelog all;
Whenever I run "crosscheck archivelog all" it failed with message "validation failed for archived log" like below.
RMAN> crosscheck archivelog all; released channel: ORA_DISK_1 allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=323 devtype=DISK validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_10/o1_mf_1_3_5bkc1o5q_.arc recid=6 stamp=697208725 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_10/o1_mf_1_4_5bkd60x4_.arc recid=7 stamp=697209883 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_10/o1_mf_1_5_5bkd78q9_.arc recid=8 stamp=697209922 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_10/o1_mf_1_6_5bkf2rwx_.arc recid=9 stamp=697210802 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_10/o1_mf_1_7_5blbdsqs_.arc recid=10 stamp=697240820 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_10/o1_mf_1_8_5blc2tvx_.arc recid=11 stamp=697241524 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_11/o1_mf_1_9_5bm1t7hk_.arc recid=12 stamp=697264802 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_11/o1_mf_1_10_5bmqwzr6_.arc recid=13 stamp=697287417 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_11/o1_mf_1_11_5bnjqg4n_.arc recid=14 stamp=697312840 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_11/o1_mf_1_12_5bnytoy5_.arc recid=15 stamp=697327280 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_12/o1_mf_1_13_5boplo7l_.arc recid=16 stamp=697351600 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_12/o1_mf_1_14_5bp6vv6w_.arc recid=17 stamp=697368277 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_12/o1_mf_1_15_5bpdtlfn_.arc recid=18 stamp=697374380 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_13/o1_mf_1_16_5br3nh19_.arc recid=19 stamp=697430505 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_13/o1_mf_1_17_5brvlghg_.arc recid=20 stamp=697455015 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_14/o1_mf_1_18_5btzdcv5_.arc recid=21 stamp=697524454 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_14/o1_mf_1_19_5bw0drf0_.arc recid=22 stamp=697558259 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_14/o1_mf_1_20_5bwvyksr_.arc recid=23 stamp=697586476 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_15/o1_mf_1_21_5bxmsqql_.arc recid=24 stamp=697610898 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_15/o1_mf_1_22_5bz0h5on_.arc recid=25 stamp=697656639 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_15/o1_mf_1_23_5bzjbvg2_.arc recid=26 stamp=697672884 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_16/o1_mf_1_24_5c0lgk9r_.arc recid=27 stamp=697707819 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_16/o1_mf_1_25_5c24o21l_.arc recid=28 stamp=697759227 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_17/o1_mf_1_26_5c30s9py_.arc recid=29 stamp=697788035 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_17/o1_mf_1_27_5c4s0wyy_.arc recid=30 stamp=697845623 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_18/o1_mf_1_28_5c5k0jrj_.arc recid=31 stamp=697870186 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_18/o1_mf_1_29_5c6z1g0p_.arc recid=32 stamp=697917319 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_18/o1_mf_1_30_5c7mqfl8_.arc recid=33 stamp=697938502 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_19/o1_mf_1_31_5c89jkhw_.arc recid=34 stamp=697960811 validation failed for archived log archive log filename=/u01/app/oracle/archivelog/2009_09_19/o1_mf_1_32_5c9ggk5p_.arc recid=35 stamp=697998634 validation succeeded for archived log archive log filename=/u01/app/oracle/archivelog/2009_12_02/o1_mf_1_343_5kdfc1sv_.arc recid=36 stamp=704560058 validation succeeded for archived log archive log filename=/u01/app/oracle/archivelog/2009_12_02/o1_mf_1_344_5kdfy3pd_.arc recid=37 stamp=704560667 validation succeeded for archived log archive log filename=/u05/archive/%t_%s_%r.arc1_345_697204983.dbf recid=38 stamp=704560901 validation succeeded for archived log archive log filename=/u05/archive/1_346_697204983.dbf recid=39 stamp=704561258 validation succeeded for archived log archive log filename=/u05/archive/1_347_697204983.dbf recid=40 stamp=704561835 validation succeeded for archived log archive log filename=/u05/archive/1_348_697204983.dbf recid=41 stamp=704561992 validation succeeded for archived log archive log filename=/u05/archive/1_349_697204983.dbf recid=42 stamp=704562987 validation succeeded for archived log archive log filename=/u05/archive/1_350_697204983.dbf recid=43 stamp=704562987 validation succeeded for archived log archive log filename=/u05/archive/1_351_697204983.dbf recid=44 stamp=704562992 validation succeeded for archived log archive log filename=/u05/archive/1_352_697204983.dbf recid=45 stamp=704563257 validation succeeded for archived log archive log filename=/u05/archive/1_353_697204983.dbf recid=46 stamp=704563321 validation succeeded for archived log archive log filename=/u05/archive/1_354_697204983.dbf recid=47 stamp=704563408 validation succeeded for archived log archive log filename=/u05/archive/1_355_697204983.dbf recid=48 stamp=704563434 validation succeeded for archived log archive log filename=/u05/archive/1_356_697204983.dbf recid=49 stamp=704584836 validation succeeded for archived log archive log filename=/u05/archive/1_357_697204983.dbf recid=50 stamp=704586204 validation succeeded for archived log archive log filename=/u05/archive/1_358_697204983.dbf recid=51 stamp=704611511 validation succeeded for archived log archive log filename=/u05/archive/1_359_697204983.dbf recid=52 stamp=704648675 validation succeeded for archived log archive log filename=/u05/archive/1_360_697204983.dbf recid=53 stamp=704650176 validation succeeded for archived log archive log filename=/u05/archive/1_361_697204983.dbf recid=54 stamp=704650675 validation succeeded for archived log archive log filename=/u05/archive/1_362_697204983.dbf recid=55 stamp=704671244 validation succeeded for archived log archive log filename=/u05/archive/1_363_697204983.dbf recid=56 stamp=704692487 validation succeeded for archived log archive log filename=/u05/archive/1_364_697204983.dbf recid=57 stamp=704708839 validation succeeded for archived log archive log filename=/u05/archive/1_365_697204983.dbf recid=59 stamp=704736263 validation succeeded for archived log archive log filename=/u05/archive/1_366_697204983.dbf recid=58 stamp=704736262 validation succeeded for archived log archive log filename=/u05/archive/1_367_697204983.dbf recid=60 stamp=704736266 validation succeeded for archived log archive log filename=/u05/archive/1_368_697204983.dbf recid=61 stamp=704737398 Crosschecked 56 objectsCause of the Problem
The problem happened because archive log file destination was changed or someone deleted the archive log files manually using OS commands.
Solution of the Problem
The solution is to delete the expired archive log files. So do following,
$ rman
RMAN> connect target /
RMAN> crosscheck archivelog all;
RMAN> delete expired archivelog all;
About RMAN Compatibility Matrix
About RMAN Environment
If you say about RMAN Environment, then there comes the following components.
1) RMAN executable
2) Recovery catalog database
3) Recovery catalog schema in the recovery catalog database
4) Target database
5) Auxiliary database (used for duplicate, duplicate for standby or tablespace point-in-time recovery)
Each component has a release number. Oracle uses up to 5 digits to indicate a version of the release, but only up to 4 are significant for RMAN compatibility purposes. For example, to check the release number of RMAN executable just issue, rman on command prompt like below.
E:\Documents and Settings\Arju>rman
Recovery Manager: Release 10.2.0.1.0 - Production on Tue Mar 2 16:16:59 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Here we see the version is 10.2.0.1.0
Determine the Recovery Catalog Schema Version
Use SQL*Plus to connect to the recovery catalog database as the catalog owner. For example, enter:
$ sqlplus rman@catdb
Query the rcver catalog table. For example, run this query:
SQL> SELECT * FROM rcver;
VERSION
------------
09.00.01.00
10.02.01.00
11.01.00.03
Note that, if multiple versions are listed, then the last row is the current version, and the rows before it are prior versions. In the preceding example, the current recovery catalog schema version is 11.1 and the previous version was 10.2.
Note that for releases 10.2 and later, the last two digits in the rcver output indicate patch level. For earlier releases, they are always zeros.
RMAN Compatibility Matrix
In general, the rules of RMAN compatibility are as follows:
1) You can create an 8.x or 9.x recovery catalog schema in any Oracle database release 8.1.x (or higher), and a 10.0.1 (or higher) recovery catalog schema in any Oracle database release 9.0.1 (or higher).
2) The version of an auxiliary database instance must be equal to the version of the RMAN client.
3) Any release of Oracle database can restore backup sets and copies created by any prior release back to Oracle8i.
4) The RMAN executable version should be the same as the target database. There are some exceptions regarding this rule.
5) The RMAN catalog schema version must be greater than or equal to the RMAN executable.
6) The RMAN catalog is backwards compatible with target databases from earlier releases.
7) While backing up an Oracle Database 10g or later database with the Oracle9i RMAN client, you cannot include a control file that was created using COMPATIBLE=10.0.0 in a datafile backup set. The workaround is to turn control file autobackup ON.
RMAN Compatibility table is shown below.
From above table you can easily conclude about the compatibility about different components of RMAN.
Note that when compatibility matrix is broken the following error message may be generated.
- RMAN-06186: PL/SQL package string.string version string in string database is too old
- RMAN-06429: string database is not compatible with this version of RMAN
If you say about RMAN Environment, then there comes the following components.
1) RMAN executable
2) Recovery catalog database
3) Recovery catalog schema in the recovery catalog database
4) Target database
5) Auxiliary database (used for duplicate, duplicate for standby or tablespace point-in-time recovery)
Each component has a release number. Oracle uses up to 5 digits to indicate a version of the release, but only up to 4 are significant for RMAN compatibility purposes. For example, to check the release number of RMAN executable just issue, rman on command prompt like below.
E:\Documents and Settings\Arju>rman
Recovery Manager: Release 10.2.0.1.0 - Production on Tue Mar 2 16:16:59 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Here we see the version is 10.2.0.1.0
Determine the Recovery Catalog Schema Version
Use SQL*Plus to connect to the recovery catalog database as the catalog owner. For example, enter:
$ sqlplus rman@catdb
Query the rcver catalog table. For example, run this query:
SQL> SELECT * FROM rcver;
VERSION
------------
09.00.01.00
10.02.01.00
11.01.00.03
Note that, if multiple versions are listed, then the last row is the current version, and the rows before it are prior versions. In the preceding example, the current recovery catalog schema version is 11.1 and the previous version was 10.2.
Note that for releases 10.2 and later, the last two digits in the rcver output indicate patch level. For earlier releases, they are always zeros.
RMAN Compatibility Matrix
In general, the rules of RMAN compatibility are as follows:
1) You can create an 8.x or 9.x recovery catalog schema in any Oracle database release 8.1.x (or higher), and a 10.0.1 (or higher) recovery catalog schema in any Oracle database release 9.0.1 (or higher).
2) The version of an auxiliary database instance must be equal to the version of the RMAN client.
3) Any release of Oracle database can restore backup sets and copies created by any prior release back to Oracle8i.
4) The RMAN executable version should be the same as the target database. There are some exceptions regarding this rule.
5) The RMAN catalog schema version must be greater than or equal to the RMAN executable.
6) The RMAN catalog is backwards compatible with target databases from earlier releases.
7) While backing up an Oracle Database 10g or later database with the Oracle9i RMAN client, you cannot include a control file that was created using COMPATIBLE=10.0.0 in a datafile backup set. The workaround is to turn control file autobackup ON.
RMAN Compatibility table is shown below.
| Target/Auxiliary Database | RMAN Executable | Catalog Database | Catalog Schema |
|---|---|---|---|
| 8.0.6 | 8.0.6 | >=8.1.7 | >=8.0.6 |
| 8.1.7 | 8.0.6.1 | >=8.1.7 | >=8.1.7 |
| 8.1.7 | 8.1.7 | >=8.1.7 | >=RMAN executable |
| 8.1.7.4 | 8.1.7.4 | >=8.1.7 | 8.1.7.4 |
| 8.1.7.4 | 8.1.7.4 | >=8.1.7 | >=9.0.1.4 |
| 9.0.1 | 9.0.1 | >=8.1.7 | >= RMAN executable |
| 9.2.0 | >=9.0.1.3 and <= Target database | >=8.1.7 | >= RMAN executable |
| 10.1.0 | >=9.0.1.3 and <= Target database | >=9.0.1 | >= RMAN executable |
| 10.2.0 | >=9.0.1.3 and <= target database executable | >=9.0.1 | >= RMAN executable |
| 11.1.0 | >=9.0.1.3 and <= target database executable | >=9.0.1 | >= RMAN executable |
| 11.2.0 | >=9.0.1.3 and <= target database executable | >=9.0.1 | >= RMAN executable |
From above table you can easily conclude about the compatibility about different components of RMAN.
Note that when compatibility matrix is broken the following error message may be generated.
- RMAN-06186: PL/SQL package string.string version string in string database is too old
- RMAN-06429: string database is not compatible with this version of RMAN
RMAN-06900 RMAN-06901 ORA-19921: maximum number of 64 rows exceeded
RMAN backup completed successfully but backup logs shows warning message as,
RMAN-06900: WARNING: unable to generate V$RMAN_STATUS or V$RMAN_OUTPUT row
RMAN-06901: WARNING: disabling update of the V$RMAN_STATUS and V$RMAN_OUTPUT rows ORACLE error from target database:
ORA-19921: maximum number of 64 rows exceeded
A variant version of warning message is like below,
connected to target database: PROD1 (DBID=3378321056)
RMAN-06900: WARNING: unable to generate V$RMAN_STATUS or V$RMAN_OUTPUT row
RMAN-06901: WARNING: disabling update of the V$RMAN_STATUS and V$RMAN_OUTPUT rows
ORACLE error from target database:
ORA-19921: maximum number of 128 rows exceeded
Cause of the Problem
The RMAN-06900 RMAN-06901 ORA-19921 error stack indicates oracle RMAN bug. ORA-19921: maximum number of 64 rows exceeded is oracle bug 4659734 and ORA-19921: MAXIMUM NUMBER OF 128 ROWS EXCEEDED is oracle Bug 8264365. This bug fires when the RMAN output is too huge because it couldn't log the output in v$rman_output.
Solution of the Problem
If your RMAN goes well and you only see warning message in your RMAN log then simply you can ignore these warnings. The bug "ORA-19921: maximum number of 64 rows exceeded" is fixed in Oracle 10.2.0.4 version and in 11g. So to solve it upgrade your oracle version or apply oracle patch. If you already have oracle version 10.2.0.4 + and hit this bug then in fact you should do nothing and just to wait for oracle to resolve the issue.
No comments:
Post a Comment
Thank for showing interest in giving comments/feedback/suggestions
Note: Only a member of this blog may post a comment.