Menu Content/Inhalt
Home arrow Oracle arrow Administration arrow CRS 10.2.0.2 error on Windows 2003
CRS 10.2.0.2 error on Windows 2003 PDF Print E-mail
Written by Martin   
Tuesday, 06 February 2007

If you don't know what CRS is then you are probably just browsing this web page :)

CRS is short for Cluster Ready Services, Oracle's cluster layer for Real Application Clusters 10g. It makes third party clusterware such as Veritas Cluster and Sun Cluster redundant altough I think most of them still work with 10g RAC as long as they don't do anything Oracle Clusterware is supposed to do. You might want to check the compatibility matrix for your 3rd party clusterware in case you intend to continue using them.


Having done a few RAC installations on Linux I am tasked with repairing a two node RAC Standard Edition production system. Downtime is absolutely a "no way" so I thought I might better try this at home first. I found a wonderful article about how to create a 2 node RAC cluster with Windows 2003 and VMWare server on http://www.oracle-base.com. However, there were a few problems I encountered that are not mentioned in that article. Update: this seems to happen with early, localised releases of Windows 2003 only! More recently I did an installation using Windows 2003 R2 and that worked a lot better - I have added an asterisk to the bullet point list below if the list item is not applicable to 2003 R2 and later.

During the CRS installation these are the ones I dealt with - please read  the section before starting:

  • I had to manually copy files from the primary to secondary nodes (ocfs.sys for example)
    After copying the file, make sure to click on "retry" to convince Oracle Universal Installer that it actually copied the file. If I remember correctly you need to copy 3 files via the network yourself. If you fail to do so you're screwed and need to begin from scratch because dependent services on the 2nd node won't start (*)
  • vipca will fail (but it also fails on real operating systems) and needs to be run manually if you're using a public IP address in the 192.168.0.0/24 netowork. Important! Close the OUI window before starting vipca or it will be unbearably slow. 
  • ocrconfig will fail when using shared raw devices for voting disk and cluster registry
    On each node, open a cmd.exe and enter diskpart followed by return. In diskpart, enter automount enable. Exit the program by typing exit. Reboot the node.
  • All failed commands are found in %CRS_HOME%\cfgtoollogs\configToolFailedCommands. Open a cmd box and copy paste one after another, fixing problems on the way before advancing.
  • Make sure to have the public interface first in your bind order before running OUI
  • If you still have problems, refer to Metalink note 310791.1 "Real Application Clusters 10g CRS Install on Windows Is Successful But Configuration Assistants Fail"

Once you are done, run cluvfy to check if everything is all right:

cd %CRS_HOME%\bin
cluvfy stage -post crsinst -n <your node list>

You should now backup both of your VMs and the shared disks. 

I detected some strange behaviour of cluvfy after rebooting my cluster. First of all, give the cluster software some time to configure itself after the reboot. Only when %CRS_HOME%\bin\crs_stat -t shows ons,evm,vip applications online for all cluster nodes can you continue.

cluvfy complains about finding no suitable VIP interface! This is an Oracle bug: if you are using any of the private IP address ranges ("private" as per RFC 1918, ie. 192.168.0.0/24) then these will not be considered suitable for a public interface.

Last Updated ( Monday, 28 May 2007 )
 
< Prev   Next >