Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

6.3. RGManager Configuration

Note

At this point in the process, we have installed Oracle on a shared volume disk (i.e. SAN).
The Resource manager is required only in the HA configuration and is responsible for ensuring that the selected node is capable of supporting an Oracle instance. The manager must ensure that network connectivity (provided by a Virtual IP address) is available, and mount the appropriate shared file systems that contain the Oracle database and the Oracle product installation and finally start the Oracle instance.
RGManager is capable of terminating Oracle services, dismantling the file systems and network so that the other node may safely start the Oracle services. There is a sample script, oracledb.sh, found in /usr/share/cluster. The customer must always modify this script so that RGManager can identify the Oracle services that require cluster management. Oracle environment variables, such as ORACLE_HOME and ORACLE_SID are critical to this identification. Oracle will likely use several file system mount points, and all mounts that are required to successfully run the database must be made known to RGManager.
RGManager is not enabled to start upon RHEL boot, so it must be enabled for the appropriate run level (typically 3): 
$ sudo chkconfig –level 3 rgmanager on

6.3.1. Customizing oracledb.sh Environment Variables

Here are some notes from the script’s preamble: 
# (1) You can comment out the LOCKFILE declaration below.  This will prevent
# the need for this script to access anything outside of the ORACLE_HOME
# path.
#
# (2) You MUST customize ORACLE_USER, ORACLE_HOME, ORACLE_SID, and
# ORACLE_HOSTNAME to match your installation if not running from within
# rgmanager.
#
# (3) Do NOT place this script in shared storage; place it in ORACLE_USER's
# home directory in non-clustered environments and /usr/share/cluster
# in rgmanager/Red Hat cluster environments.
The original script supported Oracle’s attempt at an application server (iAS), which has been replaced by a real product, Weblogix. It is also not common to co-locate the connection pool on the database server.
The script also attempts to start up the OEM (Oracle Enterprise Manger) console. The console is also not generally run on server, but runs on some random Windows box, and the OEM agents are configured on the server. If you happen to be using an older version of RHEL, the oracledb.sh script might need to have all of this disabled, including references to these obsolete services in the start_db, stop_db and get_db_status functions in the script.

6.3.1.1. DB_PROCNAMES

There has been some debate over what constitutes a running instance and RGManager uses a list of Oracle background processes (daemons in unix) to test for their existence. Historically, PMON and SMON are the most frequently selected and they are a good set. PMON is the Process Monitor part of the instance, and mostly cleans out latches and locks left by dead processes. It does dead process detection, including the death of critical background process like LGWR (redo log writer), DBWR (database writer), including SMON (system monitor). It is SMON’s job to make sure the instance is in a healthy state. If SMON crashes for some reason, then PMON will kill the instance. The presence of both of these is a reasonable test.

6.3.1.2. LSNR_PROCNAME

The SQL*Net Network Listener must be running for clients running on other machines to connect to the instance. The database can be accessed on the server node with the use of a Listener. Some instances that don’t need client access (like batch ETL, or extremely security sensitive instances), do not have to run a Listener. Most conventional databases with a mid-tier connection pool need a listener, so RGManager ensures that the Listener is up and running. The lack of a Listener will look like a dead database to the mid-tier.

6.3.2. Network VIP for Oracle Listeners

The Oracle SQL*Net Listener service must listen on a common IP address that must be accessible from either host, and this is accomplished using a Virtual IP, or VIP. 
# ip addr add 192.168.1.20/24 dev eth0
The VIP is managed and relocated by rgmanager, and must be in the same submit as the public, or front-side physical network interfaces. The front-side network is the network the Listener uses, and clients will also have access. 

<rm log_level="7">
<service domain="OracleHA" autostart=”1” exclusive=”1” name=”oracle11g” recovery=”relocate”>
<oracledb home="/ff/11g/db" name="ed" type="11g" user="jneedham" vhost="192.168.1.60"/>
<ip address="192.168.1.60" />
<fs device...
<rm/>
Alternatively, you can use a hostname for the virtual IP: 

edb home="/ff/11g/db" name="ed" type="11g" user="jneedham" vhost="hacf-vip"/>
<ip address="hacf-vip" />
The vhost argument must match the IP address clause in the service domain definition, and the /etc/hosts file must contain all the required addresses: 
# Cold Failover VIP
192.168.1.60    hacf-vip

192.168.1.160   rac5
192.168.2.160   rac5-priv
192.168.2.5     rac5-jlo

192.168.1.161   rac6
192.168.2.161   rac6-priv
192.168.2.6     rac6-jlo

6.3.2.1. listener.ora Configuration

The listener is managed by the rgmanager package, but the functionality is determined by the Oracle configuration file, listener.ora. The bolded LISTENER tag in the file is the specific name of this listener instance. This is the default, but this can be changed, and often is, when there is more than 1 SQL*Net Listener service for this database. 
LISTENER =
  (ADDRESS_LIST=
       (ADDRESS=(PROTOCOL=tcp)(HOST=hacf-vip)(PORT=1521)) #1521 is too common
       (ADDRESS=(PROTOCOL=ipc)(KEY=PNPKEY)))
SID_LIST_LISTENER =
  (SID_LIST =
   (SID_DESC =
    (GLOBAL_DBNAME = ed)      # Needs to match DBNAME in inited.ora
    (ORACLE_HOME = /ff/11g/db)
    (SID_NAME = ed)           # Needs to match the instance’s ORACLE_SID
   )
   (SID_DESC =
    (SID_NAME = PLSExtProc)
    (ORACLE_HOME = /ff/11g/db)
    (PROGRAM = extproc)
   )
  )
The Listener must listen on the VIP, not on the host-specific public interfaces. The connecting clients use an SQL*Net tnsnames.ora configuration file that contains an alias that directs them to the virtual IP. The location of the database instance is now transparent to clients. 
rhcs11g=
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = hacf-vip)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME =ed)   # This is the ORACLE_SID
    )
  )
Most JDBC clients do not install Oracle client libraries, so must use the Thin client driver. (More advanced JDBC connectivity does require an Oracle client install). For JDBC thin, the connection string cannot use the SQL*Net alias, but must encode the same information: 
… getConnection (“jdbc:oracle:thin:@hacf-vip:1521:ed”, “scott”, “tiger”)

6.3.3. Files System Entries

Oracle single-instance can run on any RHEL-supported filesystem type. Ths is unlike RAC, where only GFS is specifically certified for use. Most customers use EXT3, but EXT4, GFS and NFS are supported as well. 

<fs device="/dev/mapper/dbp5" force_unmount="1" fstype="ext3" mountpoint="/ff" name="ora_ff"/>
<fs device="/dev/mapper/dbp6" force_unmount="1" fstype="ext3" mountpoint="/gg" name="ora_gg"/>
And for NFS mounts: 

<netfs host="F3040" export="/vol/ed" force_unmount="1" mountpoint="/mnt/ed" options="rw,hard,nointr,vers=3,rsize=32768,wsize=32768,actimeo=0,proto=tcp" name="ora_nfs_ed"/>

Note

NFS must be mounted using only the mount options that are required by Oracle. The most important of these is actimeo and it should be set to zero to ensure the access times stay current.