| Page 1 Page
2 Page 3
Build Your Own
Oracle RAC 10g Release 2 Cluster on Linux and
FireWire (Continued)
For development
and testing only; production deployments will not be supported!
11.
Configure the Linux Servers for Oracle
Perform the following configuration
procedures on all nodes in the cluster!
The kernel parameters discussed in this section will
need to be defined on every node within the cluster every time the
machine is booted. This section provides very detailed information
about setting those kernel parameters required for Oracle. Instructions
for placing them in a startup script (/etc/sysctl.conf)
are included in Section
14 ("All Startup Commands for Each RAC Node").
Overview
This section focuses on configuring both Linux servers
- getting each one prepared for the Oracle RAC 10g
installation. This includes verifying enough swap space, setting shared
memory and semaphores, setting the maximum amount of file handles,
setting the IP local port range, setting shell limits for the oracle
user, activating all kernel parameters for the system, and finally how
to verify the correct date and time for each node in the cluster.
Throughout this section you will notice that there are
several different ways to configure (set) these parameters. For the
purpose of this article, I will be making all changes permanent
(through reboots) by placing all commands in the /etc/sysctl.conf
file.
Swap Space Considerations
- Installing Oracle10g Release 2
requires a minimum of 512MB of memory. (Note: An inadequate amount of
swap during the installation will cause the Oracle Universal Installer
to either "hang" or "die")
- To check the amount of memory / swap you have
allocated, type either:
# cat /proc/meminfo | grep MemTotal MemTotal: 1034352 kB
- If you have less than 512MB of memory (between your
RAM
and SWAP), you can add temporary swap space by creating a temporary
swap file. This way you do not have to use a raw device or even more
drastic, rebuild your system.
As root, make a file that will act as additional
swap space, let's say about 300MB:
# dd if=/dev/zero of=tempswap bs=1k count=300000
Now we should change the file permissions:
# chmod 600 tempswap
Finally we format the "partition" as swap and add
it to the swap space:
# mke2fs tempswap
# mkswap tempswap
# swapon tempswap
Setting Shared Memory
Shared memory allows processes to access common
structures and data by placing them in a shared memory segment. This is
the fastest form of inter-process communications (IPC) available,
mainly due to the fact that no kernel involvement occurs when data is
being passed between the processes. Data does not need to be copied
between processes.
Oracle makes use of shared memory for its Shared Global
Area (SGA) which is an area of memory that is shared by all Oracle
backup and foreground processes. Adequate sizing of the SGA is critical
to Oracle performance because it is responsible for holding the
database buffer cache, shared SQL, access paths, and so much more.
To determine all shared memory limits, use the
following:
# ipcs -lm ------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 32768 max total shared memory (kbytes) = 8388608 min seg size (bytes) = 1
Setting SHMMAX
The SHMMAX parameters defines
the maximum size (in bytes) for a shared memory segment. The Oracle SGA
is comprised of shared memory and it is possible that incorrectly
setting SHMMAX could limit the size of the SGA.
When setting SHMMAX, keep in mind that the size
of the SGA should fit within one shared memory segment. An inadequate SHMMAX
setting could result in the following:
ORA-27123: unable to attach to shared memory segment
You can determine the value of SHMMAX by
performing the following:
# cat /proc/sys/kernel/shmmax 33554432
The default value for SHMMAX is 32MB. This size
is often too small to configure the Oracle SGA. I generally set the SHMMAX
parameter to 2GB using the following methods:
- You can alter the default setting for SHMMAX
without rebooting the machine by making the changes directly to the /proc
file system (/proc/sys/kernel/shmmax) by using the
following command:
# sysctl -w kernel.shmmax=2147483648
- You should then make this change permanent by
inserting the kernel parameter in the /etc/sysctl.conf
startup file:
# echo "kernel.shmmax=2147483648" >> /etc/sysctl.conf
Setting SHMMNI
We now look at the SHMMNI
parameters. This kernel parameter is used to set the maximum number of
shared memory segments system wide. The default value for this
parameter is 4096.
You can determine the value of SHMMNI
by performing the following:
# cat /proc/sys/kernel/shmmni 4096
The default setting for SHMMNI should be adequate
for your Oracle RAC 10g Release 2 installation.
Setting SHMALL
Finally, we look at the SHMALL
shared memory kernel parameter. This parameter controls the total
amount of shared memory (in pages) that can be used at one time on the
system. In short, the value of this parameter should always be at
least:
ceil(SHMMAX/PAGE_SIZE)
The default size of SHMALL is 2097152 and can be
queried using the following command:
# cat /proc/sys/kernel/shmall 2097152
The default setting for SHMALL should be adequate
for our Oracle RAC 10g Release 2 installation.
(Note: The page size in Red Hat Linux on the i386
platform is 4,096 bytes. You can, however, use bigpages
which supports the configuration of larger memory page sizes.)
Setting Semaphores
Now that you have configured our shared memory
settings, it
is time to configure your semaphores. The best way to describe a
"semaphore" is as a counter that is used to provide synchronization
between processes (or threads within a process) for shared resources
like shared memory. Semaphore sets are supported in UNIX System V where
each one is a counting semaphore. When an application requests
semaphores, it does so using "sets."
To determine all semaphore limits, use the following:
# ipcs -ls ------ Semaphore Limits -------- max number of arrays = 128 max semaphores per array = 250 max semaphores system wide = 32000 max ops per semop call = 32 semaphore max value = 32767
You can also use the following command:
# cat /proc/sys/kernel/sem 250 32000 32 128
Setting SEMMSL
The SEMMSL kernel parameter is
used to control the maximum number of semaphores per semaphore set.
Oracle recommends setting SEMMSL
to the largest PROCESS instance parameter setting in the init.ora
file for all databases on the Linux system plus 10. Also, Oracle
recommends setting the SEMMSL to a value of no
less than 100.
Setting SEMMNI
The SEMMNI kernel parameter is
used to control the maximum number of semaphore sets in the entire
Linux system. Oracle recommends setting the SEMMNI
to a value of no less than 100.
Setting SEMMNS
The SEMMNS kernel parameter is
used to control the maximum number of semaphores (not semaphore sets)
in the entire Linux system.
Oracle recommends setting the SEMMNS
to the sum of the PROCESSES instance parameter
setting for each database on the system, adding the largest PROCESSES
twice, and then finally adding 10 for each Oracle database on the
system.
Use the following calculation to determine the
maximum number of semaphores that can be allocated on a Linux system.
It will be the lesser of:
SEMMNS -or- (SEMMSL * SEMMNI)
Setting SEMOPM
The SEMOPM kernel parameter is
used to control the number of semaphore operations that can be
performed per semop system call.
The semop system call
(function) provides the ability to do operations for multiple
semaphores with one semop system call. A
semaphore set can have the maximum number of SEMMSL
semaphores per semaphore set and is therefore recommended to set SEMOPM
equal to SEMMSL.
Oracle recommends setting the SEMOPM
to a value of no less than 100.
Setting Semaphore Kernel Parameters
Finally, we see how to set all semaphore parameters
using several methods. In the following, the only parameter I care
about changing (raising) is SEMOPM. All other
default settings should be sufficient for our example installation.
- You can alter the default setting for all
semaphore settings without rebooting the machine by making the changes
directly to the /proc file system (/proc/sys/kernel/sem)
by using the following command:
# sysctl -w kernel.sem="250 32000 100 128"
- You should then make this change permanent by
inserting the kernel parameter in the /etc/sysctl.conf
startup file:
# echo "kernel.sem=250 32000 100 128" >> /etc/sysctl.conf
Setting File Handles
When configuring our Red Hat Linux server, it is
critical to ensure that the maximum number of file handles is
sufficiently large. The setting for file handles denotes the number of
open files that you can have on the Linux system.
Use the following command to determine the maximum
number of file handles for the entire system:
# cat /proc/sys/fs/file-max 102563
Oracle recommends that the file handles for the entire system be set to
at least 65536.
- You can alter the default setting for the maximum
number of file handles without rebooting the machine by making the
changes directly to the /proc file system (/proc/sys/fs/file-max)
using the following:
# sysctl -w fs.file-max=65536
- You should then make this change permanent by
inserting the kernel parameter in the /etc/sysctl.conf
startup file:
# echo "fs.file-max=65536" >> /etc/sysctl.conf
You can query the current usage of file handles by using the following:
# cat /proc/sys/fs/file-nr 825 0 65536
The file-nr file displays three parameters: total allocated file
handles, currently used file handles, and maximum file handles that can
be allocated.
(Note: If you need to increase the value in
/proc/sys/fs/file-max, then make sure that the ulimit is set properly.
Usually for 2.4.20 it is set to unlimited. Verify the ulimit
setting my issuing the ulimit command:
# ulimit unlimited
Setting IP Local Port Range
Configure the system to allow a local port range of
1024 through 65000.
Use the following command to determine the value of
ip_local_port_range:
# cat /proc/sys/net/ipv4/ip_local_port_range 32768 61000
The default value for ip_local_port_range is ports 32768 through 61000.
Oracle recommends a local port range of 1024 to 65000.
- You can alter the default setting for the local port
range without rebooting the machine by making the changes directly to
the /proc file system (/proc/sys/net/ipv4/ip_local_port_range)
by using the following command:
# sysctl -w net.ipv4.ip_local_port_range="1024 65000"
- You should then make this change permanent by
inserting the kernel parameter in the /etc/sysctl.conf
startup file:
# echo "net.ipv4.ip_local_port_range = 1024 65000" >> /etc/sysctl.conf
Setting Shell Limits for the oracle User
To improve the performance of the software on Linux systems, Oracle
recommends you increase the following shell limits for the oracle user:
|
Shell
Limit
|
Item
in limits.conf
|
Hard
Limit
|
|
Maximum number
of open file descriptors
|
nofile
|
65536
|
|
Maximum number
of processes available to a single user
|
nproc
|
16384
|
To make these changes, run the following as root:
cat >> /etc/security/limits.conf <<EOF oracle soft nproc 2047 oracle hard nproc 16384 oracle soft nofile 1024 oracle hard nofile 65536 EOF
cat >> /etc/pam.d/login <<EOF session required /lib/security/pam_limits.so EOF
Update the default shell startup file for the "oracle" UNIX account.
- For the Bourne, Bash, or Korn shell, add the
following lines to the /etc/profile file by
running the following command:
cat >> /etc/profile <<EOF if [ \$USER = "oracle" ]; then if [ \$SHELL = "/bin/ksh" ]; then ulimit -p 16384 ulimit -n 65536 else ulimit -u 16384 -n 65536 fi umask 022 fi EOF
- For the C shell (csh or tcsh), add the following
lines to the /etc/csh.login file by running the
following command:
cat >> /etc/csh.login <<EOF if ( \$USER == "oracle" ) then limit maxproc 16384 limit descriptors 65536 endif EOF
Activating All Kernel Parameters for the
System
At this point, we have covered all of the required Linux kernel
parameters needed for a successful Oracle installation and
configuration. Within each section above, we configured the Linux
system to persist each of the kernel parameters on system startup by
placing them all in the /etc/sysctl.conf file.
We could reboot at this point to ensure all of these parameters are set
in the kernel or we could simply "run" the /etc/sysctl.conf
file by running the following command as root. Perform this on each
node of the cluster!
# sysctl -p net.ipv4.ip_forward = 0 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.default.accept_source_route = 0 kernel.sysrq = 0 kernel.core_uses_pid = 1 net.core.rmem_default = 262144 net.core.wmem_default = 262144 net.core.rmem_max = 262144 net.core.wmem_max = 262144 kernel.shmmax = 2147483648 kernel.sem = 250 32000 100 128 fs.file-max = 65536 net.ipv4.ip_local_port_range = 1024 65000
Setting the Correct Date and Time on All
Cluster Nodes
During the installation of Oracle Clusterware, the Database, and the
Companion CD, the Oracle Universal Installer (OUI) first installs the
software to the local node running the installer (i.e. linux1). The
software is then copied remotely to all of the remaining nodes in the
cluster (i.e. linux2). During the remote copy process, the OUI will
execute the UNIX "tar" command on each of the
remote nodes to extract the files that were archived and copied over.
If the date and time on the node performing the install is greater than
that of the node it is copying to, the OUI will throw an error from the
"tar" command indicating it is attempting to
extract files stamped with a time in the future:
Error while copying directory /u01/app/oracle/product/crs with exclude file list 'null' to nodes 'linux2'. [PRKC-1002 : All the submitted commands did not execute successfully] --------------------------------------------- linux2: /bin/tar: ./bin/lsnodes: time stamp 2006-09-13 09:21:34 is 735 s in the future /bin/tar: ./bin/olsnodes: time stamp 2006-09-13 09:21:34 is 735 s in the future ...(more errors on this node)
Please note that although this would seem like a severe error from the
OUI, it can safely be disregarded as a warning. The "tar"
command DOES actually extract the files; however, when you perform a
listing of the files (using ls -l) on the remote
node, they will be missing the time field until the time on the server
is greater than the timestamp of the file.
Before starting any of the above noted installations, ensure that each
member node of the cluster is set as closely as possible to the same
date and time. Oracle strongly recommends using the Network
Time Protocol feature of most operating systems for this
purpose, with all nodes using the same reference Network Time Protocol
server.
Accessing a Network Time Protocol server, however, may not always be an
option. In this case, when manually setting the date and time for the
nodes in the cluster, ensure that the date and time of the node you are
performing the software installations from (linux1) is less than all
other nodes in the cluster (linux2). I generally use a 20 second
difference as shown in the following example:
Setting the date and time from linux1:
# date -s "9/13/2006 23:00:00"
Setting the date and time from linux2:
# date -s "9/13/2006 23:00:20"
The two-node RAC configuration described in this article does not make
use of a Network Time Protocol server.
12.
Configure the hangcheck-timer Kernel Module
Perform the following configuration
procedures on all nodes in the cluster!
Oracle9i Release 1 (9.0.1) and
Oracle9i Release 2 ( 9.2.0.1) used a userspace watchdog
daemon called watchdogd to monitor the
health of the cluster and to restart a RAC node in case of a failure.
Starting with Oracle9i Release 2 (9.2.0.2) (and
still available in Oracle 10g Release 2), the
watchdog daemon has been deprecated by a Linux kernel module named hangcheck-timer
which addresses availability and reliability problems much better. The hang-check
timer is loaded into the Linux kernel and checks if the system hangs.
It will set a timer and check the timer after a certain amount of time.
There is a configurable threshold to hang-check
that, if exceeded will reboot the machine. Although the hangcheck-timer
module is not required for Oracle Clusterware (Cluster Manager)
operation, it is highly recommended by Oracle.
The hangcheck-timer.ko Module
The hangcheck-timer module uses a kernel-based timer
that periodically checks the system task scheduler to catch delays in
order to determine the health of the system. If the system hangs or
pauses, the timer resets the node. The hangcheck-timer module uses the
Time Stamp Counter (TSC) CPU register, which is incremented at each
clock signal. The TCS offers much more accurate time measurements
because this register is updated by the hardware automatically.
Much more information about the hangcheck-timer project
can be found here.
Installing the hangcheck-timer.ko Module
The hangcheck-timer was normally shipped only by
Oracle, however, this module is now included with Red Hat Linux AS
starting with kernel versions 2.4.9-e.12 and higher. The
hangcheck-timer should already be included. Use the following to ensure
that you have the module included:
# find /lib/modules -name "hangcheck-timer.ko" /lib/modules/2.6.9-22.EL/kernel/drivers/char/hangcheck-timer.ko
In the above output, we care about the hangcheck timer object (hangcheck-timer.ko)
in the /lib/modules/2.6.9-22.EL/kernel/drivers/char
directory.
Configuring and Loading the hangcheck-timer
Module
There are two key parameters to the hangcheck-timer
module:
- hangcheck-tick:
This parameter defines the period of time between checks of system
health. The default value is 60 seconds; Oracle recommends setting it
to 30 seconds.
- hangcheck-margin:
This parameter defines the maximum hang delay that should be tolerated
before hangcheck-timer resets the RAC node. It defines the margin of
error in seconds. The default value is 180 seconds; Oracle recommends
setting it to 180 seconds.
Note: The two hangcheck-timer
module parameters indicate how long a RAC node must hang before it will
reset the system. A node reset will occur when the following is true:
system hang time > (hangcheck_tick + hangcheck_margin)
Configuring Hangcheck Kernel Module Parameters
Each time the hangcheck-timer kernel module is loaded
(manually or by Oracle), it needs to know what value to use for each of
the two parameters we just discussed: (hangcheck-tick
and hangcheck-margin). These values need to be
available after each reboot of the Linux server. To do that, make an
entry with the correct values to the /etc/modprobe.conf
file as follows:
# su - # echo "options hangcheck-timer hangcheck_tick=30 hangcheck_margin=180" >> /etc/modprobe.conf
Each time the hangcheck-timer kernel module gets loaded, it will use
the values defined by the entry I made in the /etc/modprobe.conf
file.
Manually Loading the Hangcheck Kernel
Module for Testing
Oracle is responsible for loading the hangcheck-timer
kernel module when required. For that reason, it is not required to
perform a modprobe or insmod
of the hangcheck-timer kernel module in any of the startup files (i.e. /etc/rc.local).
It is only out of pure habit that I continue to include
a modprobe of the hangcheck-timer kernel module
in the /etc/rc.local file. Someday I will get
over it, but realize that it does not hurt to include a modprobe
of the hangcheck-timer kernel module during startup.
So to keep myself sane and able to sleep at night, I
always configure the loading of the hangcheck-timer kernel module on
each startup as follows:
# echo "/sbin/modprobe hangcheck-timer" >> /etc/rc.local
(Note: You don't have to manually load the
hangcheck-timer kernel module using modprobe or insmod
after each reboot. The hangcheck-timer module
will be loaded by Oracle automatically when needed.)
Now, to test the hangcheck-timer kernel module to
verify it is picking up the correct parameters we defined in the /etc/modprobe.conf
file, use the modprobe command. Although you
could load the hangcheck-timer kernel module by
passing it the appropriate parameters (e.g. insmod
hangcheck-timer hangcheck_tick=30 hangcheck_margin=180), we
want to verify that it is picking up the options we set in the /etc/modprobe.conf
file.
To manually load the hangcheck-timer kernel module and
verify it is using the correct values defined in the /etc/modprobe.conf
file, run the following command:
# su - # modprobe hangcheck-timer # grep Hangcheck /var/log/messages | tail -2 Dec 19 21:04:40 linux2 kernel: Hangcheck: starting hangcheck timer 0.5.0 (tick is 30 seconds, margin is 180 seconds)
13. Configure RAC Nodes for Remote Access
Perform the following configuration
procedures on all nodes in the cluster!
Before you can install and use Oracle Real Application clusters, you
must configure either secure shell (SSH) or remote shell (RSH) for the
"oracle" UNIX user account on all cluster nodes. The goal here is to
setup user equivalence for the "oracle" UNIX user
account. User equivalence enables the "oracle" UNIX user account to
access all other nodes in the cluster (running commands and copying
files) without the need for a password. This can be configured using
either SSH or RSH where SSH is the preferred method. Oracle added
support in 10g Release 1 for using the SSH tool
suite for setting up user equivalence. Before Oracle10g,
user equivalence had to be configured using remote shell.
Note that if the Oracle Universal Installer in 10g
does not detect the presence of the secure shell tools (ssh
and scp), it will attempt to use the remote shell
tools instead (rsh and rcp).
So, why do we have to setup user equivalence? Installing Oracle
Clusterware and the Oracle Database software is only performed from one
node in a RAC cluster. When running the Oracle Universal Installer
(OUI) on that particular node, it will use the ssh
and scp commands (or rsh
and rcp commands if using remote shell) to run
remote commands on and copy files (the Oracle software) to all other
nodes within the RAC cluster. The "oracle" UNIX user account on the
node running the OUI (runInstaller) must be
trusted by all other nodes in your RAC cluster. This means that you
must be able to run the secure shell commands (ssh
or scp) or the remote shell commands (rsh
and rcp) on the Linux server you will be running
the OUI from against all other Linux servers in the cluster without
being prompted for a password.
Note that the use of secure shell or remote shell is not required for
normal RAC operation. This configuration, however, must to be enabled
for RAC and patchset installations as well as creating the clustered
database.
The first step is to decide which method of remote access to use -
secure shell or remote shell. Both of them have their pros and cons.
Remote shell, for example, is extremely easy to setup and configure. It
takes fewer steps to construct and is always available in the terminal
session when logging on to the trusted node (the node you will be
performing the install from). The connection to the remote nodes,
however, is not secure during the installation and any patching
process. Secure shell on the other hand does provide a secure
connection when installing and patching but does require a greater
number of steps. It also needs to be enabled in the terminal session
each time the oracle user logs in to the trusted node. The official
Oracle documentation only describes the steps for setting up secure
shell and is considered the preferred method.
Both methods for configuring user equivalence are described in the
following two sections:
Using
the Secure Shell Method
This
section describes how to configure OpenSSH version 3.
To
determine if SSH is installed and running, enter the following
command:
# pgrep sshd 2808 4440 4442 6067 6069
If SSH is
running, then the response to this command is a list of process ID
number(s). Please run this command on all nodes in the cluster to
verify the SSH daemons are installed and running!
To find
out more about SSH, refer to the man page:
# man ssh
Creating
RSA and DSA Keys on Each Node
The
first step in configuring SSH is to create RSA and DSA key pairs on
each node in the cluster. The command to do this will create a public
and private key for both RSA and DSA (for a total of four keys per
node). The content of the RSA and DSA public keys will then need to be
copied into an authorized key file which is then
distributed to all nodes in the cluster.
Use
the following steps to create the RSA and DSA key pairs. Please
note that these steps will need to be completed on all nodes
in the cluster:
- Logon
as the "oracle" UNIX user account.
# su - oracle
- If necessary, create the .ssh
directory in the "oracle" user's home directory and set the correct
permissions on it:
$ mkdir -p ~/.ssh $ chmod 700 ~/.ssh
- Enter the following command to generate an RSA
key pair (public and private key) for version 3 of the SSH protocol:
$ /usr/bin/ssh-keygen -t rsa
At the prompts:
- Accept the default location for the key
files.
- Enter and confirm a pass phrase.
This should be different from the "oracle" UNIX user account password
however it is not a requirement.
This command will write the public key to the ~/.ssh/id_rsa.pub
file and the private key to the ~/.ssh/id_rsa
file. Note that you should never distribute the
private key to anyone!
- Enter the following command to generate a DSA
key pair (public and private key) for version 3 of the SSH protocol:
$ /usr/bin/ssh-keygen -t dsa
At the prompts:
- Accept the default location for the key
files.
- Enter and confirm a pass phrase.
This should be different from the "oracle" UNIX user account password
however it is not a requirement.
This command will write the public key to the ~/.ssh/id_dsa.pub
file and the private key to the ~/.ssh/id_dsa
file. Note that you should never distribute the
private key to anyone!
- Repeat the above steps for each node in the
cluster.
Now
that each node contains a public and private key for both RSA and DSA,
you will need to create an authorized key file on
one of the nodes. An authorized key file is nothing more than a single
file that contains a copy of everyone's (every node's) RSA and DSA
public key. Once the authorized key file contains all of the public
keys, it is then distributed to all other nodes in the cluster.
Complete
the following steps on one of the nodes in the cluster to
create and then distribute the authorized key file. For the purpose of
this article, I am using linux1:
- First,
determine if an authorized key file already exists on the node (~/.ssh/authorized_keys).
In most cases this will not exist since this article assumes you are
working with a new install. If the file doesn't exist, create it now:
$ touch ~/.ssh/authorized_keys $ cd ~/.ssh $ ls -l *.pub -rw-r--r-- 1 oracle dba 603 Aug 31 23:40 id_dsa.pub -rw-r--r-- 1 oracle dba 223 Aug 31 23:36 id_rsa.pub
The listing above should show the id_rsa.pub and id_dsa.pub
public keys created in the previous section.
- In this step, use SSH to copy the content of the
~/.ssh/id_rsa.pub and ~/.ssh/id_dsa.pub
public key from each node in the cluster to the authorized key file
just created (~/.ssh/authorized_keys). Again, this
will be done from linux1. You will be prompted
for the "oracle" UNIX user account password for each node accessed.
Notice that when using SSH to access the node you are on (linux1),
the first time prompts for the "oracle" UNIX user account password. The
second attempt at accessing this node will prompt for the pass phrase
used to unlock the private key. For any of the remaining nodes, it will
always ask for the "oracle" UNIX user account password.
The following example is being run from linux1
and assumes a two-node cluster, with nodes linux1
and linux2:
$ ssh linux1 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys The authenticity of host 'linux1 (192.168.1.100)' can't be established. RSA key fingerprint is 61:8a:f9:9e:28:a2:b7:d3:70:8d:dc:76:ca:d9:23:43. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'linux1,192.168.1.100' (RSA) to the list of known hosts. oracle@linux1's password: xxxxx $ ssh linux1 cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys Enter passphrase for key '/u01/app/oracle/.ssh/id_rsa': xxxxx $ ssh linux2 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys The authenticity of host 'linux2 (192.168.1.101)' can't be established. RSA key fingerprint is 84:2b:bd:eb:31:2c:23:36:55:c2:ee:54:d2:23:6a:e4. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'linux2,192.168.1.101' (RSA) to the list of known hosts. oracle@linux2's password: xxxxx $ ssh linux2 cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys oracle@linux2's password: xxxxx
Note: The first time you use SSH to
connect to a node from a particular system, you may see a message
similar to the following:
The authenticity of host 'linux1 (192.168.1.100)' can't be established. RSA key fingerprint is 61:8a:f9:9e:28:a2:b7:d3:70:8d:dc:76:ca:d9:23:43. Are you sure you want to continue connecting (yes/no)? yes
Enter yes at the prompt to continue. You should
not see this message again when you connect from this system to the
same node.
- At this point, we have the content of the RSA
and DSA public keys from every node in the cluster in the authorized
key file (~/.ssh/authorized_keys) on linux1.
We now need to copy it to the remaining nodes in the cluster. In our
two-node cluster example, the only remaining node is linux2.
Use the scp command to copy the authorized key
file to all remaining nodes in the cluster:
$ scp ~/.ssh/authorized_keys linux2:.ssh/authorized_keys oracle@linux2's password: xxxxx authorized_keys 100% 1652 1.6KB/s 00:00
- Change the permission of the authorized key file
for each node in the cluster by logging into the node and running the
following:
$ chmod 600 ~/.ssh/authorized_keys
- At this point, if you use ssh
to log in to or run a command on another node, you are prompted for the
pass phrase that you specified when you created the DSA key. For
example, test the following from linux1:
$ ssh linux1 hostname Enter passphrase for key '/u01/app/oracle/.ssh/id_rsa': xxxxx linux1 $ ssh linux2 hostname Enter passphrase for key '/u01/app/oracle/.ssh/id_rsa': xxxxx linux2
Note: If you see any other messages or
text, apart from the host name, then the Oracle installation can fail.
Make any changes required to ensure that only the host name is
displayed when you enter these commands. You should ensure that any
part of a login script(s) that generate any output, or ask any
questions, are modified so that they act only when the shell is an
interactive shell.
Enabling
SSH User Equivalency for the Current Shell Session
When running the OUI, it will need to run the secure shell tool
commands (ssh and scp)
without being prompted for a pass phrase. Even though SSH is configured
on all nodes in the cluster, using the secure shell tool commands will
still prompt for a pass phrase. Before running the OUI, you need to
enable user equivalence for the terminal session you plan to run the
OUI from. For the purpose of this article, all Oracle installations
will be performed from linux1.
User
equivalence will need to be enabled on any new terminal shell session
before attempting to run the OUI. If you log out and log back in to the
node you will be performing the Oracle installation from, you must
enable user equivalence for the terminal shell session as this is not
done by default.
To
enable user equivalence for the current terminal shell session, perform
the following steps:
- Logon
to the node where you want to run the OUI from (linux1)
as the "oracle" UNIX user account.
# su - oracle
- Enter the following commands:
$ exec /usr/bin/ssh-agent $SHELL $ /usr/bin/ssh-add Enter passphrase for /u01/app/oracle/.ssh/id_rsa: xxxxx Identity added: /u01/app/oracle/.ssh/id_rsa (/u01/app/oracle/.ssh/id_rsa) Identity added: /u01/app/oracle/.ssh/id_dsa (/u01/app/oracle/.ssh/id_dsa)
At the prompts, enter the pass phrase for each key that you generated.
- If SSH is configured correctly, you will be able
to use the ssh and scp
commands without being prompted for a password or pass phrase from this
terminal session:
$ ssh linux1 "date;hostname" Wed Sep 13 17:35:30 EDT 2006 linux1 $ ssh linux2 "date;hostname" Wed Sep 13 17:36:14 EDT 2006 linux2
Note: The commands above should
display the date set on each node along with its hostname. If any of
the nodes prompt for a password or pass phrase then verify that the ~/.ssh/authorized_keys
file on that node contains the correct public keys. Also, if you see
any other messages or text, apart from the date and hostname, then the
Oracle installation can fail. Make any changes required to ensure that
only the date is displayed when you enter these commands. You should
ensure that any part of a login script(s) that generate any output, or
ask any questions, are modified so that they act only when the shell is
an interactive shell.
- The Oracle Universal Installer is a GUI
interface and requires the use of an X Server. From the terminal
session enabled for user equivalence (the node you will be performing
the Oracle installations from), set the environment variable DISPLAY
to a valid X Windows display:
Bourne, Korn, and Bash shells:
$ DISPLAY=<Any X-Windows Host>:0 $ export DISPLAY
C shell:
$ setenv DISPLAY <Any X-Windows Host>:0
After setting the DISPLAY variable to a valid X
Windows display, you should perform another test of the current
terminal session to ensure that X11 forwarding is
not enabled:
$ ssh linux1 hostname linux1 $ ssh linux2 hostname linux2
Note: If you are using a remote client
to connect to the node performing the installation, and you see a
message similar to: "Warning: No xauth data; using fake
authentication data for X11 forwarding." then this means
that your authorized keys file is configured correctly; however, your
SSH configuration has X11 forwarding enabled. For
example:
$ export DISPLAY=melody:0 $ ssh linux2 hostname Warning: No xauth data; using fake authentication data for X11 forwarding. linux2
Note that having X11 Forwarding enabled will cause the Oracle
installation to fail. To correct this problem, create a user-level SSH
client configuration file for the "oracle" UNIX user account that
disables X11 Forwarding:
- Using a text editor, edit or create the file
~/.ssh/config
- Make sure that the ForwardX11
attribute is set to no. For example, insert the
following into the ~/.ssh/config file:
Host * ForwardX11 no
- You must run the Oracle Universal Installer
from this terminal session or remember to repeat the steps to enable
user equivalence (steps 2, 3, and 4 from this section) before you start
the Oracle Universal Installer from a different terminal session.
Remove
any stty Commands
When
installing the Oracle software, any hidden files on the system
(i.e. .bashrc, .cshrc, .profile)
will cause the installation process to fail if they contain stty
commands.
To
avoid this problem, you must modify these files to suppress all
output on STDERR as in the following examples:
Note: If there are hidden files that
contain stty commands that are loaded by the
remote shell, then OUI indicates an error and stops the installation.
Using the
Remote Shell Method
The
services provided by remote shell are disabled
by default on most Linux systems. This section describes the tasks
required for enabling and configuring user equivalence for use by the
Oracle Universal Installer when commands should be run and files copied
to the remote nodes in the cluster using the remote shell tools. The
goal is to enable the Oracle Universal Installer to use rsh
and rcp to run commands and copy files to a
remote node without being prompted for a password. Please note that
using the remote shell method for configuring user equivalence is not
secure.
The
rsh daemon validates users using the /etc/hosts.equiv
file or the .rhosts file found in the user's
(oracle's) home directory.
First,
let's make sure that we have the rsh RPMs
installed on each node in the RAC cluster:
# rpm -q rsh rsh-server rsh-0.17-25.3 rsh-server-0.17-25.3
From the
above, we can see that we have the rsh and rsh-server
installed. Were rsh not installed, we would run
the following command from the CD where the RPM is located:
# su - # rpm -ivh rsh-0.17-25.3.i386.rpm rsh-server-0.17-25.3.i386.rpm
To
enable the "rsh" and "rlogin" services, the "disable" attribute in
the /etc/xinetd.d/rsh file must be set to "no"
and xinetd must be reloaded.
This can be done by running the following commands on all
nodes in the cluster:
# su - # chkconfig rsh on # chkconfig rlogin on # service xinetd reload Reloading configuration: [ OK ]
To allow
the "oracle" UNIX user account to be trusted among the RAC nodes,
create the /etc/hosts.equiv file on all
nodes in the cluster:
# su - # touch /etc/hosts.equiv # chmod 600 /etc/hosts.equiv # chown root.root /etc/hosts.equiv
Now add
all RAC nodes to the /etc/hosts.equiv file
similar to the following example for all nodes in the cluster:
# cat /etc/hosts.equiv +linux1 oracle +linux2 oracle +linux1-priv oracle +linux2-priv oracle
Note:
In the above example, the second field permits only the oracle
user account to run rsh commands on the specified
nodes. For security reasons, the /etc/hosts.equiv
file should be owned by root and the permissions
should be set to 600. In fact, some systems will
only honor the content of this file if the owner of this file is root
and the permissions are set to 600.
Before
attempting to test your rsh command, ensure that
you are using the correct version of rsh. By
default, Red Hat Linux puts /usr/kerberos/sbin at
the head of the $PATH variable. This will cause
the Kerberos version of rsh to be executed.
I will typically rename the Kerberos version of rsh
so that the normal rsh command will be used. Use
the following:
# su - # which rsh /usr/kerberos/bin/rsh # mv /usr/kerberos/bin/rsh /usr/kerberos/bin/rsh.original # mv /usr/kerberos/bin/rcp /usr/kerberos/bin/rcp.original # mv /usr/kerberos/bin/rlogin /usr/kerberos/bin/rlogin.original # which rsh /usr/bin/rsh
You
should now test your connections and run the rsh
command from the node that will be performing the Oracle Clusterware
and 10g RAC installation. I will be using the node linux1
to perform all installs so this is where I will run the following
commands from:
# su - oracle $ rsh linux1 ls -l /etc/hosts.equiv -rw------- 1 root root 68 Sep 27 23:37 /etc/hosts.equiv $ rsh linux1-priv ls -l /etc/hosts.equiv -rw------- 1 root root 68 Sep 27 23:37 /etc/hosts.equiv $ rsh linux2 ls -l /etc/hosts.equiv -rw------- 1 root root 68 Sep 27 23:45 /etc/hosts.equiv $ rsh linux2-priv ls -l /etc/hosts.equiv -rw------- 1 root root 68 Sep 27 23:45 /etc/hosts.equiv
Unlike
when using secure shell, no other actions or commands are needed to
enable user equivalence using the remote shell. User equivalence will
be enabled for the "oracle" UNIX user account after successfully
logging in to a terminal session.
14. All Startup Commands for Each RAC Node
Verify that the following startup commands
are included on all nodes in the cluster!
Up to this point, you have read in great detail about
the parameters and resources that need to be configured on all nodes
for the Oracle10g RAC configuration. This section
will let you " take a deep breath" and recap those parameters,
commands, and entries (in previous sections of this document) that need
to happen on each node when the machine is booted.
For each of the startup files below, entries in gray should be included in each
startup file.
/etc/modprobe.conf
(All parameters and values to be used by kernel
modules.)
alias eth0 b44 alias eth1 tulip alias snd-card-0 snd-intel8x0 options snd-card-0 index=0 alias usb-controller ehci-hcd alias usb-controller1 uhci-hcd options sbp2 exclusive_login=0 alias scsi_hostadapter sbp2 options hangcheck-timer hangcheck_tick=30 hangcheck_margin=180
/etc/sysctl.conf
(We wanted to adjust the default and maximum
send buffer size as well as the default and maximum receive buffer size
for the interconnect. This file also contains those parameters
responsible for configuring shared memory, semaphores, file handles,
and local IP range for use by the Oracle instance.)
# Kernel sysctl configuration file for Red Hat Linux # # For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and # sysctl.conf(5) for more details.
# Controls IP packet forwarding net.ipv4.ip_forward = 0
# Controls source route verification net.ipv4.conf.default.rp_filter = 1
# Controls the System Request debugging functionality of the kernel kernel.sysrq = 0
# Controls whether core dumps will append the PID to the core filename. # Useful for debugging multi-threaded applications. kernel.core_uses_pid = 1
# Default setting in bytes of the socket receive buffer net.core.rmem_default=262144
# Default setting in bytes of the socket send buffer net.core.wmem_default=262144
# Maximum socket receive buffer size which may be set by using # the SO_RCVBUF socket option net.core.rmem_max=262144
# Maximum socket send buffer size which may be set by using # the SO_SNDBUF socket option net.core.wmem_max=262144 # +---------------------------------------------------------+ # | SHARED MEMORY | # +---------------------------------------------------------+ kernel.shmmax=2147483648
# +---------------------------------------------------------+ # | SEMAPHORES | # | ---------- | # | | # | SEMMSL_value SEMMNS_value SEMOPM_value SEMMNI_value | # | | # +---------------------------------------------------------+ kernel.sem=250 32000 100 128
# +---------------------------------------------------------+ # | FILE HANDLES | # ----------------------------------------------------------+ fs.file-max=65536
# +---------------------------------------------------------+ # | LOCAL IP RANGE | # ----------------------------------------------------------+ net.ipv4.ip_local_port_range=1024 65000
/etc/hosts
(All machine/IP entries for nodes in our RAC
cluster.)
# Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost # Public Network - (eth0) 192.168.1.100 linux1 192.168.1.101 linux2 # Private Interconnect - (eth1) 192.168.2.100 linux1-priv 192.168.2.101 linux2-priv # Public Virtual IP (VIP) addresses for - (eth0) 192.168.1.200 linux1-vip 192.168.1.201 linux2-vip 192.168.1.106 melody 192.168.1.102 alex 192.168.1.105 bartman
/etc/hosts.equiv
(The /etc/hosts.equiv file is only required
when using the remote shell method to establish remote access and user
equivalency. Allow logins to each node as the oracle user account
without the need for a password when using the remote shell method for
enabling user equivalency.)
+linux1 oracle +linux2 oracle +linux1-priv oracle +linux2-priv oracle
/etc/rc.local
(Loading the hangcheck-timer kernel module.)
#!/bin/sh # # This script will be executed *after* all the other init scripts. # You can put your own initialization stuff in here if you don't # want to do the full Sys V style init stuff.
touch /var/lock/subsys/local
# +---------------------------------------------------------+ # | HANGCHECK TIMER | # | (I do not believe this is required, but doesn't hurt) | # ----------------------------------------------------------+
/sbin/modprobe hangcheck-timer
15.
Check RPM Packages for Oracle 10g Release 2
Perform the following checks on all
nodes in the cluster!
When installing the Linux O/S (CentOS Enterprise Linux
or RHEL4), you should verify that all required RPMs are installed. If
you followed the instructions I used for installing Linux, you would
have installed everything, in which case you will
have all the required RPM packages. However, if you performed another
installation type (i.e. Advanced Server), you may have some packages
missing and will need to install them. All of the required RPMs are on
the Linux CDs/ISOs.
Check Required RPMs
The following packages (or higher versions) must be
installed:
make-3.80-5 glibc-2.3.4-2.9 glibc-devel-2.3.4-2.9 glibc-headers-2.3.4-2.9 glibc-kernheaders-2.4-9.1.87 cpp-3.4.3-22.1 compat-db-4.1.25-9 compat-gcc-32-3.2.3-47.3 compat-gcc-32-c++-3.2.3-47.3 compat-libstdc++-33-3.2.3-47.3 compat-libstdc++-296-2.96-132.7.2 openmotif-2.2.3-9.RHEL4.1 setarch-1.6-1
To query package information (gcc and glibc-devel for
example), use the "rpm -q <PackageName> [,
<PackageName>]" command as follows:
# rpm -q gcc glibc-devel gcc-3.4.3-22.1 glibc-devel-2.3.4-2.9
If you need to install any of the above packages, use "rpm
-Uvh <PackageName.rpm>". For example, to
install the GCC 3.2.3-24 package, use:
# rpm -Uvh gcc-3.4.3-22.1.i386.rpm
Reboot the System
If you made any changes to the O/S, reboot all nodes in
the cluster before attempting to install any of the Oracle components!!!
# init 6
16.
Install & Configure OCFS2
Most of the configuration procedures in this
section should be performed on all nodes
in the cluster! Creating the OCFS2 filesystem, however, should be
executed on only one node in the cluster.
It is now time to install OCFS2. OCFS2 is a cluster
filesystem that allows all nodes in a cluster to concurrently access a
device via the standard filesystem interface. This allows for easy
management of applications that need to run across a cluster.
OCFS Release 1 was released in 2002 to enable Oracle
RAC users to run the clustered database without having to deal with RAW
devices. The filesystem was designed to store database related files,
such as data files, control files, redo logs, archive logs, etc. OCFS
Release 2 (OCFS2), in contrast, has been designed as a general-purpose
cluster filesystem. With it, one can store not only database related
files on a shared disk, but also store Oracle binaries and
configuration files (shared Oracle Home) making management of RAC even
easier.
In this guide, you will be using the latest release of
OCFS2 (OCFS2
Release 1.2.3-1 at the time of this writing) to
store the two files that are required to be shared by the Oracle
Clusterware software. Along with these two files, you will also be
using this space to store the shared SPFILE for all Oracle RAC
instances.
See this
page for more information on OCFS2 (including Installation
Notes) for Linux.
Download OCFS
First, download the latest OCFS2 distribution. The
OCFS2 distribution comprises of two sets of RPMs; namely, the kernel
module and the tools. The latest kernel module is available for
download from http://oss.oracle.com/projects/ocfs2/files/
and the tools from http://oss.oracle.com/projects/ocfs2-tools/files/.
Download the appropriate RPMs starting with the latest
OCFS2 kernel module (the driver). With CentOS 4.2 Enterprise Linux, I
am using kernel release 2.6.9-22.EL. The appropriate OCFS2 kernel
module was found in the latest release of OCFS2 at the time of this
writing (OCFS2
Release 1.2.3-1). The available OCFS2 kernel modules for
Linux kernel 2.6.9-22.EL are listed below. Always download the latest
OCFS2 kernel module that matches the distribution, platform, kernel
version and the kernel flavor (smp, hugemem, psmp, etc).
ocfs2-2.6.9-22.EL-1.2.3-1.i686.rpm
- (for single processor)
or
ocfs2-2.6.9-22.ELsmp-1.2.3-1.i686.rpm
- (for multiple processors)
or
ocfs2-2.6.9-22.ELhugemem-1.2.3-1.i686.rpm
- (for hugemem)
For the tools, simply match the platform and
distribution. You should download the OCFS2 tools as well as the OCFS2
console applications.
ocfs2-tools-1.2.1-1.i386.rpm
- (OCFS2 tools)
ocfs2console-1.2.1-1.i386.rpm
- (OCFS2 console)
The OCFS2 Console is optional but highly recommended.
The ocfs2console application requires e2fsprogs,
glib2 2.2.3 or later, vte 0.11.10 or later, pygtk2 (EL4) or python-gtk
(SLES9) 1.99.16 or later, python 2.3 or later and ocfs2-tools.
If you were curious as to which OCFS2 driver release
you need, use the OCFS2 release that matches your kernel version. To
determine your kernel release:
$ uname -a Linux linux1 2.6.9-22.EL #1 Sat Oct 8 17:48:27 CDT 2005 i686 i686 i386 GNU/Linux
In the absence of the string "smp" after the string "EL", we are
running a single processor (Uniprocessor) machine. If the string "smp"
were to appear, then you would be running on a multi-processor machine.
Install OCFS2
I will be installing the OCFS2 files onto two
single-processor machines. The installation process is simply a matter
of running the following command on all nodes in the
cluster as the root user account:
$ su - # rpm -Uvh ocfs2-2.6.9-22.EL-1.2.3-1.i686.rpm \ ocfs2console-1.2.1-1.i386.rpm \ ocfs2-tools-1.2.1-1.i386.rpm Preparing... ########################################### [100%] 1:ocfs2-tools ########################################### [ 33%] 2:ocfs2-2.6.9-22.EL ########################################### [ 67%] 3:ocfs2console ########################################### [100%]
Disable SELinux (RHEL4 U2 Only)
RHEL4 U2 users (CentOS 4.2 is based on RHEL4 U2) are
advised that OCFS2 currently does not work with SELinux enabled. If you
are using RHEL4 U2 (which includes you, since you are using CentOS 4.2
here) you will need to disable SELinux (using tool system-config-securitylevel)
to get the O2CB service to execute.
To disable SELinux, run the "Security Level
Configuration" GUI utility:
# /usr/bin/system-config-securitylevel &
This will bring up the following screen:

Figure 6 Security Level Configuration Opening
Screen
Now, click the SELinux tab and check off the
"Enabled" checkbox. After clicking on [OK], you will be presented with
a warning dialog. Simply acknowledge this warning by clicking "Yes".
Your screen should now look like the following after disabling the
SELinux option:

Figure 7 SELinux Disabled
After making this change on both nodes in the cluster,
each node will need to be rebooted to implement the change:
# init 6
Configure OCFS2
The next step is to generate and configure the /etc/ocfs2/cluster.conf
file on each node in the cluster. The easiest way to accomplish this is
to run the GUI tool ocfs2console. In this
section, we will not only create and configure the /etc/ocfs2/cluster.conf
file using ocfs2console, but will also create and
start the cluster stack O2CB. When the /etc/ocfs2/cluster.conf
file is not present, (as will be the case in our example), the ocfs2console
tool will create this file along with a new cluster stack service
(O2CB) with a default cluster name of ocfs2. This
will need to be done on all nodes in the cluster as
the root user account:
$ su - # ocfs2console &
This will bring up the GUI as shown below:

Figure 8 ocfs2console GUI
Using the ocfs2console GUI tool,
perform the following steps:
- Select [Cluster] -> [Configure
Nodes...]. This will start the OCFS Cluster Stack (Figure 9)
and bring up the "Node Configuration" dialog.
- On the "Node Configuration" dialog, click the [Add]
button.
- This will bring up the "Add Node" dialog.
- In the "Add Node" dialog, enter the Host
name and IP address for the first node in
the cluster. Leave the IP Port set to its default
value of 7777. In my example, I added both nodes using linux1
/ 192.168.1.100 for the first node and linux2
/ 192.168.1.101 for the second node.
- Click [Apply] on the "Node Configuration" dialog
- All nodes should now be "Active" as shown in Figure 10.
- Click [Close] on the "Node Configuration"
dialog.
- After verifying all values are correct, exit the
application using [File] -> [Quit]. This
needs to be performed on all nodes in the cluster.

Figure 9. Starting the OCFS2 Cluster
Stack
The following dialog show the OCFS2 settings I used for
the node linux1 and linux2:

Figure 10 Configuring Nodes for
OCFS2
After exiting the ocfs2console,
you will have a /etc/ocfs2/cluster.conf similar
to the following. This process needs to be completed on all nodes in
the cluster and the OCFS2 configuration file should be exactly the same
for all of the nodes:
node: ip_port = 7777 ip_address = 192.168.1.100 number = 0 name = linux1 cluster = ocfs2
node: ip_port = 7777 ip_address = 192.168.1.101 number = 1 name = linux2 cluster = ocfs2
cluster: node_count = 2 name = ocfs2
O2CB Cluster Service
Before we can do anything with OCFS2 like formatting or
mounting the file system, we need to first have OCFS2's cluster stack,
O2CB, running (which it will be as a result of the
configuration process performed above). The stack includes
the following services:
- NM: Node Manager that keep track
of all the nodes in the cluster.conf
- HB: Heart beat service that
issues up/down notifications when nodes join or leave the cluster
- TCP: Handles communication
between the nodes
- DLM: Distributed lock manager
that keeps track of all locks, its owners and status
- CONFIGFS: User space driven
configuration file system mounted at /config
- DLMFS: User space interface to
the kernel space DLM
All of the above cluster services have been packaged in
the o2cb system service (/etc/init.d/o2cb).
Here is a short listing of some of the more useful commands and options
for the o2cb system service.
- /etc/init.d/o2cb status
Module "configfs": Not loaded Filesystem "configfs": Not mounted Module "ocfs2_nodemanager": Not loaded Module "ocfs2_dlm": Not loaded Module "ocfs2_dlmfs": Not loaded Filesystem "ocfs2_dlmfs": Not mounted
Note that with this example, all of the services are
not loaded. I did an "unload" right before executing the "status"
option. If you were to check the status of the o2cb service immediately
after configuring OCFS using ocfs2console utility, they would all be
loaded.
- /etc/init.d/o2cb load
Loading module "configfs": OK Mounting configfs filesystem at /config: OK Loading module "ocfs2_nodemanager": OK Loading module "ocfs2_dlm": OK Loading module "ocfs2_dlmfs": OK Mounting ocfs2_dlmfs filesystem at /dlm: OK
Loads all OCFS modules.
- /etc/init.d/o2cb online ocfs2
Starting cluster ocfs2: OK
The above command will online the cluster we
created, ocfs2.
- /etc/init.d/o2cb offline ocfs2
Unmounting ocfs2_dlmfs filesystem: OK Unloading module "ocfs2_dlmfs": OK Unmounting configfs filesystem: OK Unloading module "configfs": OK
The above command will offline the cluster we
created, ocfs2.
- /etc/init.d/o2cb unload
Cleaning heartbeat on ocfs2: OK Stopping cluster ocfs2: OK
The above command will unload all OCFS modules.
Configure O2CB to Start on Boot
You now need to configure the on-boot properties of the
OC2B driver so that the cluster stack services will start on each boot.
All the tasks within this section will need to be performed on
both nodes in the cluster.
Note: At the time of writing this
guide, OCFS2 contains a bug wherein the driver does not get loaded on
each boot even after configuring the on-boot properties to do so. After
attempting to configure the on-boot properties to start on each boot
according to the official OCFS2 documentation, you will still get the
following error on each boot:
... Mounting other filesystems: mount.ocfs2: Unable to access cluster service
Cannot initialize cluster mount.ocfs2: Unable to access cluster service Cannot initialize cluster [FAILED] ...
Red Hat changed the way the service is registered between
chkconfig-1.3.11.2-1 and chkconfig-1.3.13.2-1. The O2CB script used to
work with the former.
Before attempting to configure the on-boot properties:
- REMOVE the following lines in /etc/init.d/o2cb
### BEGIN INIT INFO # Provides: o2cb # Required-Start: # Should-Start: # Required-Stop: # Default-Start: 2 3 5 # Default-Stop: # Description: Load O2CB cluster services at system boot. ### END INIT INFO
- Re-register the o2cb service.
# chkconfig --del o2cb # chkconfig --add o2cb # chkconfig --list o2cb o2cb 0:off 1:off 2:on 3:on 4:on 5:on 6:off # ll /etc/rc3.d/*o2cb* lrwxrwxrwx 1 root root 14 Sep 29 11:56 /etc/rc3.d/S24o2cb -> ../init.d/o2cb
The service should be S24o2cb in the default
runlevel.
After resolving this bug, you can continue to set the
on-boot properties as follows:
# /etc/init.d/o2cb offline ocfs2 # /etc/init.d/o2cb unload # /etc/init.d/o2cb configure Configuring the O2CB driver. This will configure the on-boot properties of the O2CB driver. The following questions will determine whether the driver is loaded on boot. The current values will be shown in brackets ('[]'). Hitting <ENTER> without typing an answer will keep that current value. Ctrl-C will abort. Load O2CB driver on boot (y/n) [n]: y Cluster to start on boot (Enter "none" to clear) [ocfs2]: ocfs2 Writing O2CB configuration: OK Loading module "configfs": OK Mounting configfs filesystem at /config: OK Loading module "ocfs2_nodemanager": OK Loading module "ocfs2_dlm": OK Loading module "ocfs2_dlmfs": OK Mounting ocfs2_dlmfs filesystem at /dlm: OK Starting cluster ocfs2: OK
Format the OCFS2 Filesystem
You can now start to make use of the partitions created
in the section Create Partitions on the
Shared FireWire Storage Device. (Well, at least the first
partition!)
If the O2CB cluster is offline, start it. The format
operation needs the cluster to be online, as it needs to ensure that
the volume is not mounted on some node in the cluster.
Earlier in this document, we created the directory /u02/oradata/orcl
under the section Create
Mount Point for OCFS/Clusterware. This section contains the
commands to create and mount the file system to be used for the Cluster
Manager - /u02/oradata/orcl.
Unlike the other tasks in this section, creating the
OCFS2 filesystem should only be executed on one node in the
RAC cluster. You will be executing all commands in this
section from linux1 only.
Note that it is possible to create and mount the OCFS2
file system using either the GUI tool ocfs2console
or the command-line tool mkfs.ocfs2. From the ocfs2console
utility, use the menu [Tasks] - [Format].
See the instructions below on how to create the OCFS2
file system using the command-line tool mkfs.ocfs2.
To create the filesystem, use the Oracle executable mkfs.ocfs2.
For the purpose of this example, I run the following command only from linux1
as the root user account:
$ su - # mkfs.ocfs2 -b 4K -C 32K -N 4 -L oradatafiles /dev/sda1 mkfs.ocfs2 1.2.1 Filesystem label=oradatafiles Block size=4096 (bits=12) Cluster size=32768 (bits=15) Volume size=1011646464 (30873 clusters) (246984 blocks) 1 cluster groups (tail covers 30873 clusters, rest cover 30873 clusters) Journal size=16777216 Initial number of node slots: 4 Creating bitmaps: done Initializing superblock: done Writing system files: done Writing superblock: done Formatting Journals: done Writing lost+found: done mkfs.ocfs2 successful
Mount the OCFS2 Filesystem
Now that the file system is created, you can mount it.
Let's first do it using the command-line, then I'll show how to include
it in the /etc/fstab to have it mount on each
boot. Mounting the filesystem will need to be performed on
all nodes in the Oracle RAC cluster as the root
user account.
First, here is how to manually mount the OCFS2 file
system from the command line. Remember, this needs to be performed as
the root user account:
$ su - # mount -t ocfs2 -o datavolume,nointr /dev/sda1 /u02/oradata/orcl
If the mount was successful, you will simply got your
prompt back. You should, however, run the following checks to ensure
the fil system is mounted correctly.
Let's use the mount command to
ensure that the new filesystem is really mounted. This should be
performed on all nodes in the RAC cluster:
# mount /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) none on /proc type proc (rw) none on /sys type sysfs (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) usbfs on /proc/bus/usb type usbfs (rw) /dev/hda1 on /boot type ext3 (rw) none on /dev/shm type tmpfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) cartman:SHARE2 on /cartman type nfs (rw,addr=192.168.1.120) configfs on /config type configfs (rw) ocfs2_dlmfs on /dlm type ocfs2_dlmfs (rw) /dev/sda1 on /u02/oradata/orcl type ocfs2 (rw,_netdev,datavolume,nointr,heartbeat=local)
Note: You are using the datavolume
option to mount the new filesystem here. Oracle database users must
mount any volume that will contain the Voting Disk file, Cluster
Registry (OCR), Data files, Redo logs, Archive logs, and Control files
with the datavolume mount option so as to ensure
that the Oracle processes open the files with the o_direct
flag. The nointr option ensures that the I/O's
are not interrupted by signals.
Any other type of volume, including an Oracle home (not
used in this guide), should not be mounted with
this mount option.
The volume will mount after a short delay, usually around five seconds.
It does so to let the heartbeat thread stabilize. In a future release,
Oracle plans to add support for a global heartbeat, which will make
most mounts instantaneous.
Configure OCFS to Mount Automatically at Startup
Let's review what you've done so far. You downloaded
and installed OCFS2, which will be used to store the files needed by Cluster
Manager files. After going through the install, you loaded
the OCFS2 module into the kernel and then formatted the clustered
filesystem. Finally, you mounted the newly created filesystem. This
section walks through the steps responsible for mounting the new OCFS2
file system each time the machine(s) are booted.
Start by adding the following line to the /etc/fstab
file on all nodes in the RAC cluster:
/dev/sda1 /u02/oradata/orcl ocfs2 _netdev,datavolume,nointr 0 0
Notice the _netdev option for mounting this
filesystem. The _netdev mount option is a must
for OCFS2 volumes; it indicates that the volume is to be mounted after
the network is started and dismounted before the network is shutdown.
Now, let's make sure that the ocfs2.ko
kernel module is being loaded and that the file system will be mounted
during the boot process.
If you have been following along with the examples in
this article, the actions to load the kernel module and mount the OCFS2
file system should already be enabled. However, you should still check
those options by running the following on all nodes in the
RAC cluster as the root user account:
$ su - # chkconfig --list o2cb o2cb 0:off 1:off 2:on 3:on 4:on 5:on 6:off
The flags that I have marked in bold should be set
to "on".
Check Permissions on New OCFS2 Filesystem
Use the ls command to check
ownership. The permissions should be set to 0775 with owner "oracle"
and group "dba".
Let's first check the permissions:
# ls -ld /u02/oradata/orcl drwxr-xr-x 3 root root 4096 Sep 29 12:11 /u02/oradata/orcl
As you can see from the listing above, the oracle
user account (and the dba group) will not be able
to write to this directory. Let's fix that:
# chown oracle.dba /u02/oradata/orcl # chmod 775 /u02/oradata/orcl
Let's now go back and re-check that the permissions are correct for
each node in the cluster:
# ls -ld /u02/oradata/orcl drwxrwxr-x 3 oracle dba 4096 Sep 29 12:11 /u02/oradata/orcl
Adjust the O2CB Heartbeat Threshold
This is a very important section when configuring OCFS2
for use by Oracle Clusterware's two shared files on our FireWire drive.
During testing, I was able to install and configure OCFS2, format the
new volume, and finally install Oracle Clusterware (with its two
required shared files; the voting disk and OCR file), located on the
new OCFS2 volume. I was able to install Oracle Clusterware and see the
shared drive; however, during my evaluation I was receiving many
lock-ups and hanging after about 15 minutes when the Clusterware
software was running on both nodes. It always varied on which node
would hang (either linux1 or linux2
in my example). It also didn't matter whether there was a high I/O load
or none at all for it to crash (hang).
Keep in mind that the configuration you are creating is
a rather low-end setup being configured with slow disk access with
regards to the FireWire drive. This is by no means a high-end setup and
is susceptible to bogus timeouts.
After looking through the trace files for OCFS2, it was
apparent that access to the voting disk was too slow (exceeding the
O2CB heartbeat threshold) and causing the Oracle Clusterware software
(and the node) to crash.
The solution I used was to simply increase the O2CB
heartbeat threshold from its default setting of 7, to 601 (and in some
cases as high as 901). This is a configurable parameter that is used to
compute the time it takes for a node to "fence" itself.
First, let's see how to determine what the O2CB
heartbeat threshold is currently set to. This can be done by querying
the /proc file system as follows:
# cat /proc/fs/ocfs2_nodemanager/hb_dead_threshold 7
The value is 7, but what does this value represent? Well, it is used in
the formula below to determine the fence time (in seconds):
[fence time in seconds] = (O2CB_HEARTBEAT_THRESHOLD - 1) * 2
So, with a O2CB heartbeat threshold of 7, you would have a fence time
of:
(7 - 1) * 2 = 12 seconds
You need a much larger threshold (1200 seconds to be exact) given your
slower FireWire disks. For 1200 seconds, you will want a
O2CB_HEARTBEAT_THRESHOLD of 601 as shown below:
(601 - 1) * 2 = 1200 seconds
Let's see now how to increase the O2CB heartbeat
threshold from 7 to 601. This will need to be performed on both nodes
in the cluster. You first need to modify the file /etc/sysconfig/o2cb
and set O2CB_HEARTBEAT_THRESHOLD to 601:
# O2CB_ENABELED: 'true' means to load the driver on boot. O2CB_ENABLED=true
# O2CB_BOOTCLUSTER: If not empty, the name of a cluster to start. O2CB_BOOTCLUSTER=ocfs2
# O2CB_HEARTBEAT_THRESHOLD: Iterations before a node is considered dead. O2CB_HEARTBEAT_THRESHOLD=601
After modifying the file /etc/sysconfig/o2cb,
you need to alter the o2cb configuration. Again,
this should be performed on all nodes in the cluster.
# umount /u02/oradata/orcl/ # /etc/init.d/o2cb unload # /etc/init.d/o2cb configure Load O2CB driver on boot (y/n) [y]: y Cluster to start on boot (Enter "none" to clear) [ocfs2]: ocfs2 Writing O2CB configuration: OK Loading module "configfs": OK Mounting configfs filesystem at /config: OK Loading module "ocfs2_nodemanager": OK Loading module "ocfs2_dlm": OK Loading module "ocfs2_dlmfs": OK Mounting ocfs2_dlmfs filesystem at /dlm: OK Starting cluster ocfs2: OK
You can now check again to make sure the settings took place in for the
o2cb cluster stack:
# cat /proc/fs/ocfs2_nodemanager/hb_dead_threshold 601
It is important to note that the value of 601 I used for the O2CB
heartbeat threshold will not work for all of the FireWire drives I have
listed to work for this article. In some cases, the O2CB heartbeat
threshold value had to be increased to as high as 901 in order to
prevent OCFS2 from panicking the kernel.
Replace CFQ I/O Scheduler with the DEADLINE I/O
Scheduler - (RHEL4 U2 and U3 Users)
A bug has been encountered with the default CFQ I/O
scheduler which causes a process doing heavy I/O to temporarily starve
out other processes. While this is not fatal for most environments, it
is for OCFS2 as the heartbeat thread is expected to be r/w to the
heartbeat area at least once every 12 seconds (default). A bug along
with the fix has been filed with Red Hat. Red Hat is expected to have
this fixed in RHEL4 U4 release. SLES9 SP3 2.5.6-7.257 includes this
fix. Until this issue is resolved, one is advised to use the DEADLINE
I/O scheduler. To use it, add "elevator=deadline"
to the kernel command line found in the /boot/grub/grub.conf
file. This will need to be performed on both nodes in the
cluster:
# grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00 # initrd /initrd-version.img #boot=/dev/sda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS-4 i386 (2.6.9-22.EL) root (hd0,0) kernel /vmlinuz-2.6.9-22.EL ro root=/dev/VolGroup00/LogVol00 rhgb quiet elevator=deadline initrd /initrd-2.6.9-22.EL.img
After making this change, the system will need to be
rebooted for the change to take effect. (See the next task)
Reboot Both Nodes
Before starting the next section, this would be a good
place to reboot all of the nodes in the RAC cluster. When the machines
come up, ensure that the cluster stack services are being loaded and
the new OCFS2 file system is being mounted:
# mount /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) none on /proc type proc (rw) none on /sys type sysfs (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) usbfs on /proc/bus/usb type usbfs (rw) /dev/hda1 on /boot type ext3 (rw) none on /dev/shm type tmpfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) cartman:SHARE2 on /cartman type nfs (rw,addr=192.168.1.120) configfs on /config type configfs (rw) ocfs2_dlmfs on /dlm type ocfs2_dlmfs (rw) /dev/sda1 on /u02/oradata/orcl type ocfs2 (rw,_netdev,datavolume,nointr,heartbeat=local)
You should also verify that the O2CB heartbeat threshold is set
correctly (to our new value of 601):
# cat /proc/fs/ocfs2_nodemanager/hb_dead_threshold 601
Lastly, verify the new kernel command line enabled the DEADLINE I/O
scheduler:
# cat /proc/cmdline ro root=/dev/VolGroup00/LogVol00 rhgb quiet elevator=deadline
How to Determine OCFS2 Version
To determine which version of OCFS2 is running, use:
# cat /proc/fs/ocfs2/version OCFS2 1.2.3 Wed Jul 26 12:34:15 PDT 2006 (build 6b798aaadf626d3b137c3952809b2f38)
17.
Install & Configure Automatic Storage Management (ASMLib 2.0)
Most of the installation and configuration
procedures should be performed on all nodes.
Creating the ASM disks, however, will only need to be performed on a single
node within the cluster.
In this section, you will configure ASM to be used as
the filesystem / volume manager for all Oracle physical database files
(data, online redo logs, control files, archived redo logs) and a Flash
Recovery Area.
The ASM feature was introduced in Oracle Database 10g
Release 1 and is used to alleviate the DBA from having to manage
individual files and drives. ASM is built into the Oracle kernel and
provides the DBA with a way to manage thousands of disk drives 24x7 for
both single and clustered instances of Oracle. All the files and
directories to be used for Oracle will be contained in a disk
group. ASM automatically performs load balancing in parallel
across all available disk drives to prevent hot spots and maximize
performance, even with rapidly changing data usage patterns.
I start this section by first discussing the ASMLib 2.0
libraries and its associated driver for Linux plus other methods for
configuring ASM with Linux. Next, I will provide instructions for
downloading the ASM drivers (ASMLib Release 2.0) specific to your Linux
kernel. Last, you will install and configure the ASMLib 2.0 drivers
while finishing off the section with a demonstration of how to create
the ASM disks.
If you would like to learn more about the ASMLib, visit
www.oracle.com/technology/tech/linux/asmlib/install.html.
Methods for Configuring ASM with Linux (For
Reference Only)
When I first started this guide, I wanted to focus on
using ASM for all database files. I was curious to see how well ASM
works with this test RAC configuration with regard to load balancing
and fault tolerance.
There are two different methods to configure ASM on
Linux:
- ASM with ASMLib I/O: This
method creates all Oracle database files on raw block devices managed
by ASM using ASMLib calls. Raw devices are not required with this
method as ASMLib works with block devices.
- ASM with Standard Linux I/O:
This method creates all Oracle database files on raw character devices
managed by ASM using standard Linux I/O system calls. You will be
required to create raw devices for all disk partitions used by ASM.
We will examine the "ASM with ASMLib I/O" method here.
Before discussing the installation and configuration
details of ASMLib, however, I thought it would be interesting to talk
briefly about the second method, "ASM with Standard Linux I/O." If you
were to use this method (which is a perfectly valid solution, just not
the method we will be implementing here), you should be aware that
Linux does not use raw devices by default. Every Linux raw device you
want to use must be bound to the corresponding block device using the
raw driver. For example, if you wanted to use the partitions we've
created, (/dev/sda2, /dev/sda3, and /dev/sda4), you would need to
perform the following tasks:
- Edit the file /etc/sysconfig/rawdevices
as follows:
# raw device bindings # format: <rawdev> <major> <minor> # <rawdev> <blockdev> # example: /dev/raw/raw1 /dev/sda1 # /dev/raw/raw2 8 5 /dev/raw/raw2 /dev/sda2 /dev/raw/raw3 /dev/sda3 /dev/raw/raw4 /dev/sda4
The raw device bindings will be created on each reboot.
- You would then want to change ownership of all raw
devices to the "oracle" user account:
# chown oracle:dba /dev/raw/raw2; chmod 660 /dev/raw/raw2 # chown oracle:dba /dev/raw/raw3; chmod 660 /dev/raw/raw3 # chown oracle:dba /dev/raw/raw4; chmod 660 /dev/raw/raw4
- The last step is to reboot the server to bind the
devices or simply restart the rawdevices service:
# service rawdevices restart
As I mentioned earlier, the above example was just to
demonstrate that there is more than one method for using ASM with
Linux. Now let's move on to the method that will be used for this
article, "ASM with ASMLib I/O."
Download the ASMLib 2.0 Packages
First download the latest ASMLib 2.0 libraries and the
driver from OTN. At the time of this writing, the latest release of the
ASMLib driver was 2.0.3-1.
Like OCFS2, you need to download the version for the Linux kernel and
number of processors on the machine. You are using kernel 2.6.9-22.EL
#1 on single-processor machines:
# uname -a Linux linux1 2.6.9-22.EL #1 Sat Oct 8 17:48:27 CDT 2005 i686 i686 i386 GNU/Linux
Oracle ASMLib Downloads for Red Hat
Enterprise Linux 4 AS
You will also need to download the following ASMLib
tools:
Install ASMLib 2.0 Packages
This installation needs to be performed on all
nodes as the root user account:
$ su - # rpm -Uvh oracleasm-2.6.9-22.EL-2.0.3-1.i686.rpm \ oracleasmlib-2.0.2-1.i386.rpm \ oracleasm-support-2.0.3-1.i386.rpm Preparing... ########################################### [100%] 1:oracleasm-support ########################################### [ 33%] 2:oracleasm-2.6.9-22.EL ########################################### [ 67%] 3:oracleasmlib ########################################### [100%]
Configure and Loading the ASMLib 2.0 Packages
Now that you downloaded and installed the ASMLib
Packages for Linux, you need to configure and load the ASM kernel
module. This task needs to be run on all nodes
as root:
$ su - # /etc/init.d/oracleasm configure Configuring the Oracle ASM library driver. This will configure the on-boot properties of the Oracle ASM library driver. The following questions will determine whether the driver is loaded on boot and what permissions it will have. The current values will be shown in brackets ('[]'). Hitting <ENTER> without typing an answer will keep that current value. Ctrl-C will abort. Default user to own the driver interface []: oracle Default group to own the driver interface []: dba Start Oracle ASM library driver on boot (y/n) [n]: y Fix permissions of Oracle ASM disks on boot (y/n) [y]: y Writing Oracle ASM library driver configuration: [ OK ] Creating /dev/oracleasm mount point: [ OK ] Loading module "oracleasm": [ OK ] Mounting ASMlib driver filesystem: [ OK ] Scanning system for ASM disks: [ OK ]
Create ASM Disks for Oracle
In Section 10, you
created three Linux partitions to be used for storing Oracle database
files like online redo logs, database files, control files, archived
redo log files, and a flash recovery area.
Here is a list of those partitions we created for use
by ASM:
| Oracle
ASM Partitions Created |
| Filesystem Type |
Partition |
Size |
Mount Point |
File Types |
| ASM |
/dev/sda2 |
50GB |
ORCL:VOL1 |
Oracle Database Files |
| ASM |
/dev/sda3 |
50GB |
ORCL:VOL2 |
Oracle Database Files |
| ASM |
/dev/sda4 |
100GB |
ORCL:VOL3 |
Flash Recovery Area |
| Total |
|
200GB |
|
|
The last task in this section it to create the ASM
Disks. Creating the ASM disks only needs to be done on one
node as the root user account. I
will be running these commands on linux1. On the
other nodes, you will need to perform a scandisk to
recognize the new volumes. When that is complete, you should then run
the oracleasm listdisks command on all nodes to
verify that all ASM disks were created and available.
$ su - # /etc/init.d/oracleasm createdisk VOL1 /dev/sda2 Marking disk "/dev/sda2" as an ASM disk [ OK ]
# /etc/init.d/oracleasm createdisk VOL2 /dev/sda3 Marking disk "/dev/sda3" as an ASM disk [ OK ]
# /etc/init.d/oracleasm createdisk VOL3 /dev/sda4 Marking disk "/dev/sda4" as an ASM disk [ OK ]
Note: If you are repeating
this guide using the same hardware (actually, the same shared drive),
you may get a failure when attempting to create the ASM disks. If you
do receive a failure, try listing all ASM disks using:
# /etc/init.d/oracleasm listdisks VOL1 VOL2 VOL3
As you can see, the results show that I have three volumes already
defined. If you have the three volumes already defined from a previous
run, go ahead and remove them using the following commands and then
creating them again using the above (oracleasm createdisk)
commands:
# /etc/init.d/oracleasm deletedisk VOL1 Removing ASM disk "VOL1" [ OK ] # /etc/init.d/oracleasm deletedisk VOL2 Removing ASM disk "VOL2" [ OK ] # /etc/init.d/oracleasm deletedisk VOL3 Removing ASM disk "VOL3" [ OK ]
On all other nodes in the cluster, you
must perform a scandisk to recognize the new volumes:
# /etc/init.d/oracleasm scandisks Scanning system for ASM disks [ OK ]
You can now test that the ASM disks were successfully
created by using the following command on all nodes
as the root user account:
# /etc/init.d/oracleasm listdisks VOL1 VOL2 VOL3
18.
Download Oracle 10g RAC Software
The following download procedures only need
to be performed on one node in the
cluster!
The next logical step is to install Oracle Clusterware
Release 2 (10.2.0.1.0), Oracle Database 10g Release
2 (10.2.0.1.0), and finally the Oracle Database 10g
Companion CD Release 2 (10.2.0.1.0) for Linux x86 software. However,
you must first download and extract the required Oracle software
packages from OTN.
You will be downloading and extracting the required
software from Oracle to only one of the Linux nodes in the
cluster—namely, linux1. You will
perform all installs from this machine. The Oracle installer will copy
the required software packages to all other nodes in the RAC
configuration we set up in Section 13.
Login to one of the nodes in the Linux RAC cluster as
the oracle user account. In this example, you
will be downloading the required Oracle software to linux1
and saving them to /u01/app/oracle/orainstall.
Downloading and Extracting the Software
First, download
the Oracle Clusterware Release 2 (10.2.0.1.0), Oracle Database 10g
Release 2 (10.2.0.1.0), and Oracle Database 10g
Companion CD Release 2 (10.2.0.1.0) software for Linux x86. All
downloads are available from the same page.
As the oracle user account,
extract the three packages you downloaded to a temporary directory. In
this example, we will use /u01/app/oracle/orainstall.
Extract the Oracle Clusterware package as follows:
# su - oracle $ cd ~oracle/orainstall $ unzip 10201_clusterware_linux32.zip
Then extract the Oracle Database Software:
$ cd ~oracle/orainstall $ unzip 10201_database_linux32.zip
Finally, extract the Oracle Companion CD Software:
$ cd ~oracle/orainstall $ unzip 10201_companion_linux32.zip
Page 1 Page
2 Page 3 |