When the installation is almost done, you will be prompted to run orainstRoot.sh
and root.sh scripts. You will have to open a new console (do not do it
in the same console as your installer!) beginning from the primary node where
you are carrying the installation and logged in as "root" run the script.
Now go the the /u01/app/oracle/oraInventory directory and run
orainstRoot.sh. You have to do this on ALL NODES!
As you can see, it changes the permissions of the oraInventory and assigns
DBA the group name of the same directory.
There are many discussions about miscounts, specifically to the VMware
environment (like VMware Server OR Workstation), where the overhead might just
not be supportive enough to allow for a full and robust functioning of our RAC.
This is also necessary when running DBCA in order to install our database. Not
doing so might result in an ora-03113
error.
What actually is the problem then? In VMware you might encounter slower disk
responsiveness (depending on how fast and what configuration you have for your
disks, I had success on an old server with RAID0 and problems with a RAID 5/SAN
disk) . However, this does not have to be the case for VMware RAC testbed, it
can also occur in a poorly selected hardware configuration. The CSS miscount
has a default value of 60 and happens to be a bit too small for the CSS to miss
the heartbeat and eventually ending up evicting the node and thus throwing the
ora-03113 error. Beginning with the Oracle 10gR1 series, the algorithm has
changed to allow a lengthier timeout. I have had success with 300, but you can
go as high as 600. So now, the question arises of how to do it. If you haven’t
done it, do it now by doing:
Query your nodes:
$ORA_CRS_HOME/bin/crsctl get css misscount
60
Query again:
$ORA_CRS_HOME/bin/crsctl get css misscount
360
Now we go about installing the root.sh script:
You do see that the clscfg complains that the miscount must be below 360 and
that is when I went looking for the trade off, trying to set it just below 300.
Moreover, after doing so you will need to run this root.sh on ALL NODES!
Despite the error of that ONS (Notification Services daemon), I was able to
successfully conclude the installation. The last node runs the VIPCA (VIP
Configuration Agent).
As you can see, the configuration starts:
And completes successfully.
Doing a quick check on the cluster nodes:
And also checking if all the daemons will start automatically:
Conclusion:
In this
article, we took our first steps towards installing the Oracle Clusterware and
as you saw yourself, the installation went fine. That was due to the
painstaking and yet rewarding preparatory efforts that we put in the beginning
of our series. In our next article, we will go ahead and install Oracle
software and the Companion CD. Then we will take on our DBCA (Database Creation
Assistant). In our Oracle RAC administration series, we will go ahead and
administer the clusterware components. Although I had started this series to do
a Windows and Linux RAC installation, I am tempted to look at HP-UX, AIX and
Solaris too, hopefully my VMware server will get out of beta and I can get on
with these configurations as well.
»
See All Articles by Columnist Tarry Singh
» 
