Thursday, June 20, 2019

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

Problem:
While I was restoring a Non-Production DB using the duplicate method from RMAN backup, 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:
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')";
}

It supposes to work while the instance "to be restored" is in NOMOUNT mode, so why it's asking to mount it?!

I used to run the duplicate command first time with random UNTIL TIME date ahead of the backup date, then the RMAN will give me an error indicating the actual farthest recovery date the backup can go to, then I use this date from the error message and update the UNTIL TIME with it in the duplicate script, and run it one more time.

Solution:
This time I figure out that I used a date older than the backup date in the duplicate script, this is why I got 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 and used the exact "last NEXT TIME in archived logs" date mentioned in the last RMAN error message in the script, 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')";
}

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