Search this Blog

Wednesday, June 9, 2010

Create RAC database results in PRKP-1001 and CRS-0215

During the installation of a two Node RAC cluster we decided to install CRS and ASM on the latest stable Oracle level ( and for reasons of application compatibility installed the database with release

All installation actions went fine. CRS, ASM and the database installation had their own owners and installation directories. All environments were physically seperated.
CRS, ASM and the listener were running OK.
However during the creation of the database we ran into troubles.

Using 'dbca' for the database creation the final steps of starting the just created instance, dbca failed with the
PRKP-1001 and CRS-0215 errors, giving no real clue of what was going on.

Thinking it must be a kind of compatibility problem, we tried all kinds of combinations.
Creating the database with the software, but administrating it with the release. Nothing really worked.
We even tried to install the database software with one of the other owners, just to rule out any possibility of conflicts, but that also didn't work.

After a couple of hours digging through the logfiles and banging our heads against the wall, we solved the problem !!

It turned out the the use of a central TNS_ADMIN location, i.e. the location where the listener.ora and tnsnames.ora resides, wasn't correctly passed through to the running resources. Although 'dbca' was aware of this central location, it failed to update the Cluster resources responsible for the database with this information.

It resulted in the resources looking for listener.ora and tnsnames.ora in $OH/network/admin.
Errors ORA-01078 and ORA-00119 appeared in the logs of the database.
The starting of the cluster resources then was solved by copying the listener.ora and tnsnames.ora to the $OH/network/admin directory.

But that was not the initial goal.
We especially created a central location for these files.

Then finally with help of Oracle support we also solved that challenge:
It is possible to tell the resources afterwards what the TNS_ADMIN location is.
This can be done by setting the environment variable TNS_ADMIN to the correct value for every resource involved, as shown below:

$> export TNS_ADMIN=/opt/oracle/network/admin
$> srvctl setenv db -d -t TNS_ADMIN=/opt/oracle/network/admin
$> srvctl setenv inst -d -i -t TNS_ADMIN=/opt/oracle/network/admin
$> srvctl setenv inst -d -i -t TNS_ADMIN=/opt/oracle/network/admin

Executing these statements from one node only is sufficient, as this information is saved into the Oracle Cluster Registry

1 comment:

  1. This is an excellent article.
    Still, if you want something more hands-on, try these:

    You can find more demos (including dataguard, goldengate, streams) there at

    Vladimir Grigorian