Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 







VMware: Create the RAC Database

Oracle Tips by Burleson Consulting

Unlike the prior chapter, for this pseudo-RAC setup you will need to run Oracles Database Configuration Assistant (DBCA) twice. The first time will create your single RAC instance on your single Linux node. Then the second time, you will ask DBCA to create a second instance on that same node. And voila! You now have more than one instance operating against a single database. The only real difference is that these two instances are not on separate Linux nodes, but rather the same node. This may be considered cheating a bit, but for non-production and non-testing use, this setup requires the minimum resources to deploy.

You should immediately notice a very distinct difference when you run DBCA in a cluster enabled environment. The very first screen should prompt for which type of database: Real Application Cluster (RAC) databases or single instance databases, as shown in Figure 17 on the next page. If it does not, then once again backtrack and re-verify the prior steps done properly. Of course, it is best to choose the first alternative RAC.

Figure 17:  Choosing RAC Database

In step 1 of the DBCA wizard, choose to create a database. You should now see a RAC node selection screen as shown in Figure 18 (next page). Very similar to what you did in the prior section for the clusterware installers hardware selection,  you are telling DBCA which nodes will participate in this RAC cluster database and, hence, which nodes DBCA will need to run scripts on to actually create that database and any node specific portions, i.e. redo logs, rollback segments and such. As before, since you have only the one node, you will see just that being offered. This will result in a single instance being created on a single node, which may not seem too useful. But do not worry you will be adding that second node shortly.

Figure 18:  Node Selection Screen

Next, DBCA will ask for the Global Database Name and SID Prefix. In my case, I said RAC for each. At this point, DBCA will realize that it needs to create virtual IP addresses to support creating the database with this name. Then you will see the dialog shown in Figure 19. It says that you need to run the Oracle Virtual IP Configuration Assistant (VIPCA). But note that while the dialog indicates it is located under the database or db Oracle Home, it is actually under the cluster ware or crs Oracle Home. So you will need to issue the following two commands instead as root:

  • export ORACLE_HOME=/home/oracle/product/10.2.0/crs

  • $ORACLE_HOME/bin/vipca

Figure 19:  Screen with Dialog About VIPCA 

VIPCA should then recognize your Oracle public network adapter, i.e. eth0, as the one to which to add the virtual IP address. Once again, the virtual IP address mechanism is required for both load balancing and fault tolerance reasons. In effect, Oracle will be creating some network loopback adapters and the necessary trickery or redirection to make your RAC database instances totally accessible via that new virtual IP address. That is why you needed the one IP address in your hosts file for linux_rac-vip. In step one of the VIPCA wizard, you will identify eth0 as the correct public network adapter. Then in step 2 you will provide the linux_rac-vip alias and IP address as shown in Figure 20.

Figure 20:  Providing Alias and IP Address in VIPCA

VIPCA will then go off and create everything necessary to support this network setup. Now it is time to return to some of the more typical database creation questions, such as how and where to store the database files.

Step 7 of the database creation wizard will offer a RAC database three choices (shown in Figure 21), all of which are shared disk resources, meaning more than one node can concurrently access those files as block I/O devices without locking or blocking issues. In this case, you will choose Cluster File System since you know you are using Oracles ocfs2.

Special Note:  The Raw Devices choice only applies when you are truly allocating raw devices directly to Oracle for data files. If  you are instead doing some of the other options, such as the earlier mentioned choice to use Linux loop back devices to create raw devices to then allocate to ASM to manage as if real disks, then you choose ASM. However, if you map a host raw device to a virtual machine disk, then the raw devices choice would apply.

Figure 21:  RAC Database Choices

Then, on step 8 of the database creation wizard (Figure 22), you simply choose Use Common Location for All Database files. That centralized location will be located on your ocfs2 mount point: /data. DBCA will thus create all the control files, redo log files, and data files under this location. In addition, note that your OCR and voting disk were here as well under /data since these files must be concurrently accessible also.

Special Note: If you try to cheat and use one of the standard Linux file systems such as ext2 or ext3, the DBCA may appear to successfully create your database or not. But even if it does so, you will encounter problems later on while Oracle has multiple instances trying to access the same files at the same times. In that case, your RAC cluster may hang or corrupt its files. So please make 100% sure to be using a clustered file system or Oracles ASM.

Figure 22:  Database File Location Screen

Finally on step 9 of the database creation wizard, you will be prompted for the service name for your database. Do not attempt to name it the same as your global database name or SID prefix. So in my example as seen in Figure 23 (next page), I simply called my service RACDB for my RAC global database name. Just remember what name you choose since this will be the one name for which your listener process will be listening for and the service name you will reference in other SQL Net configuration files, such as both the host and external client tnsnames files. Note that the TAF Policy options refers to this RAC databases Transparent Application Failover setting. It defaults to none, but it is probably more realistic to set it to basic. However, remember that you are on just a single operating system node. So in reality, you are not going to gain anything with this setting other than appearing closer to a real world scenario.

Figure 23: Creating Database Service Name

DBCA will then go off and create a single RAC database instance on your one Linux operating system node. Now it is time to add that second instance.

First, run DBCA a second time and again choose to work with Real Application Clusters databases, choose Instance Management as shown in Figure 24 (next page), and then choose Add an Instance.  DBCA will display a cluster selection screen once again, just like the two times mentioned before and also shown in Figure 25, and then you will choose the one and only RAC database available ( in my case, RAC). DBCA will offer you the default SID name for that new instance, which you can override, and it will go off and create that second database instance on your one and only node. You will now have a two instance RAC cluster running on a single Linux node. If everything is properly configured, then DBCA will not take long to perform this operation. Remember, to add an instance just means to create the node specific items not to run the entire database creation process. So do not be too surprised if this process takes just a few seconds to run.

Figure 24:  Instant Management Screen

Figure 25:  Creating an Instance

RAC Auto-Start

All that is left to do is to configure your Linux node to autostart your Oracle RAC cluster. That requires just three easy steps shown below.

1.      Create auto start script /etc/init.d directory/

su - oracle -c "$ORACLE_HOME/bin/srvctl start nodeapps n linux_rac" >
su - oracle -c "$ORACLE_HOME/bin/srvctl start database d RAC" > /dev/null

2.      Create auto stop script /etc/init.d directory/ 

su - oracle -c "$ORACLE_HOME/bin/srvctl stop database d RAC" > /dev/null
su - oracle -c "$ORACLE_HOME/bin/srvctl stop nodeapps n linux_rac" >

1.      Then execute the following commands to set it all up 

ln -sf  /etc/init.d/   /etc/rc0.d/K10dbshut
ln -sf  /etc/init.d/   /etc/rc6.d/K10dbshut
ln -sf  /etc/init.d/  /etc/rc2.d/S99dbstart
ln -sf  /etc/init.d/  /etc/rc5.d/S99dbstart


In this chapter, we expanded on last chapters example and built more than a simple single instance database we built a pseudo-RAC cluster. The idea was again to provide a simple yet effective demo and/or experimentation playground for working with RAC on a machine with limited capacity while requiring the least amount of physical resources. And though this is not truly a RAC cluster and, therefore, not really supported by Oracle, it nonetheless looks and acts real enough for our intended limited purposes. In fact, this setup will run quite well on a reasonable laptop/notebook by todays standard like one with a dual core processor, 2 GB of memory and at least a 60GB disk drive. I have even been able to go to four RAC instances under such a setup on a notebook with 4GB of memory with no real loss of performance.

In the next chapter, we will examine creating true RAC in the virtualization world and how our abilities are expanding in this realm.

This is an excerpt from
Oracle on VMWare: Expert tips for database virtualization by Rampant TechPress.


Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2020

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.