Thursday, June 20, 2019

RMAN-05502: the target database must be mounted when issuing a DUPLICATE command

Problem:

While restoring a Non-Production DB from RMAN backup using Duplicate method , I received this error:
RMAN-05502: the target database must be mounted when issuing a DUPLICATE command

Here is the RMAN script I was using:
# export ORACLE_SID=pssp
# rman AUXILIARY /
RMAN> 
run {
ALLOCATE AUXILIARY CHANNEL ch1  DEVICE TYPE DISK;
ALLOCATE AUXILIARY CHANNEL ch2  DEVICE TYPE DISK;
duplicate database to "pssp"  backup location '/db02/bkp/2019-06-02' nofilenamecheck
UNTIL TIME "TO_DATE('01/06/2019 13:05:17', 'DD/MM/YYYY HH24:MI:SS')";
}

This duplicate method is supposed to work while the instance "to be restored" is in NOMOUNT mode, so why the error message is asking to mount it?!

I used to execute the duplicate command one time with a random "UNTIL TIME" date ahead of the backup date, then the RMAN will give me an error message referring to the actual farthest recovery date the backup can restore to, then I feed that date into the "UNTIL TIME" clause when I run the same script second time.

Solution:

If you are performing the Duplicate from a backup:

First: 90% of the cases, your rman command is being aliased in the shell environment to connect to "target /", so it will not connect as "auxiliary /" as you want:

# which rman


 
 
 
 
 If this is the case, then remove that alias and run the rman script again and most probably it will succeed this time:

# unalias rman 
 
Second: You are trying to connect target and auxiliary, while it is not necessary for cloning from backup to connect as target:
i.e.
Command returning RMAN-05502:
# rman target / auxiliary /@TARGETDB

Try using:
# export ORACLE_SID=TARGETDB
# rman auxiliary /

Third: You are trying unnecessarily to provide username and password to the auxiliary clause, while you can simply "connect auxiliary /"
i.e.

Command returning RMAN-05502:
# rman auxiliary sys/passw@TARGETDB

Try using:
# export ORACLE_SID=TARGETDB
# rman auxiliary /

Forth: Simply try to remove the UNTIL TIME clause  from the script if you want to recover the database to the latest archivelog available in the backup.
 
Or: If you insist on restoring the DB to a specific point in time inside that backup, then you have to know that the date specified in the UNTIL TIME clause is trying to restore the backup to a date older than the backup creation date, this is why I received that vague error message. Once I used a date ahead of the backup time (randomly) I got the right farthest recovery date the backup can go to:

run {
ALLOCATE AUXILIARY CHANNEL ch1  DEVICE TYPE DISK;
ALLOCATE AUXILIARY CHANNEL ch2  DEVICE TYPE DISK;
duplicate database to "pssp"  backup location '/db02/bkp/2019-06-02' nofilenamecheck
UNTIL TIME "TO_DATE('20/06/2019 13:05:17', 'DD/MM/YYYY HH24:MI:SS')";
}

RMAN-06617: UNTIL TIME (20-Jun-2019 13:05:17) is ahead of last NEXT TIME in archived logs (02-Jun-2019 17:30:19)

Then I restarted the instance in NOMOUNT mode one more time and used the exact "last NEXT TIME in archived logs" received from the above error message and the duplicate succeeded.

 run {
ALLOCATE AUXILIARY CHANNEL ch1  DEVICE TYPE DISK;
ALLOCATE AUXILIARY CHANNEL ch2  DEVICE TYPE DISK;
duplicate database to "pssp"  backup location '/db02/bkp/2019-06-02' nofilenamecheck
UNTIL TIME "TO_DATE('02/06/2019 17:30:19', 'DD/MM/YYYY HH24:MI:SS')";
}


If you are performing the Duplicate from a source LIVE database:
Most probably you are swapping between source and target DBs in the Connect part in your script, when duplicating from an ACTIVE DB, the TARGET should be connecting to the source LIVE DB which you will restore from e.g. Production DB, and the AUXILIARY should be the TARGET DB which you will restore to e.g. Test DB which should be in NOMOUNT mode, like this:
connect target sys/xxx@SOURCEDB 
connect auxiliary sys/xxx@TARGETDB
...
DUPLICATE TARGET DATABASE TO ... FROM ACTIVE DATABASE
... 
 
Tip: When duplicating from an active database, It's NOT recommended to use "NOFILENAMECHECK" with the duplicate command to avoid overwriting the source DB files.

 
Conclusion:

- When doing a duplicate from an RMAN backup, RMAN-05502 error can happen because rman command is being aliased to connect to target as a default, remove this alias using "unalias rman" command and run the duplicate command again.

- If your rman command is not aliased, you may be using a wrong date in the UNTIL TIME clause, once you use the right date and time of the backupset, the Duplicate command will go through.

- If you are duplicating from an active database, RMAN-05502 error can indicate that you are wrongly swapping between source and target DBs in the RMAN connect command.

Sunday, June 16, 2019

Grid Infrastructure root.sh Fail With Error "Failed to create keys in the OLR"


During the installation of Grid Infrastructure Clusterware 12.1.0.2 on OEL 6.6 root.sh failed with the following error:

[root]# /u01/12.1.0/grid/root.sh 
Performing root user operation. 

The following environment variables are set as: 
ORACLE_OWNER= grid 
ORACLE_HOME= /u01/12.1.0/grid 

Enter the full pathname of the local bin directory: [/usr/local/bin]: 
Copying dbhome to /usr/local/bin ... 
Copying oraenv to /usr/local/bin ... 
Copying coraenv to /usr/local/bin ... 


Creating /etc/oratab file... 
Entries will be added to the /etc/oratab file as needed by 
Database Configuration Assistant when a database is created 
Finished running generic part of root script. 
Now product-specific root actions will be performed. 
Using configuration parameter file: /u01/12.1.0/grid/crs/install/crsconfig_params 
/u01/12.1.0/grid/bin/crsctl query crs releaseversion ... failed rc=1 with message: 
/u01/12.1.0/grid/bin/crsctl: line 307: /u01/12.1.0/grid/bin/crsctl.bin: Success 

Failed to create keys in the OLR, rc = 1, Message: 
/u01/12.1.0/grid/bin/clscfg: line 307: /u01/12.1.0/grid/bin/clscfg.bin: Success 

Died at /u01/12.1.0/grid/crs/install/crsutils.pm line 7705. 
The command '/u01/12.1.0/grid/perl/bin/perl -I/u01/12.1.0/grid/perl/lib -I/u01/12.1.0/grid/crs/install /u01/12.1.0/grid/crs/install/rootcrs.pl ' execution failed 

Analysis:
At the first glance, I thought there is a problem with writing to the ASM disk group where the OCR will be created, after a long analysis and research, I finally figured out that the Grid binary source files where I'm installing the Clusterware from are missing some files!

Fix:
I re-downloaded the Grid Infrastructure source binaries and managed to install the Grid Infrastructure successfully.

Reference: Doc ID 1909073.1