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:
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/dbstart_auto.sh
and include the URL for the page.
