Specific Configuration Considerations for Oracle

*If you plan to use Oracle with Raw I/O, the Raw I/O devices must be properly set up prior to use. See the Appendix for instructions. (Raw I/O is not an option for LifeKeeper Single Server Protection.)

Before configuring the Oracle Recovery Kit, complete the following preparatory steps to ensure that file systems and disk partitions used by Oracle will be accessible from each server.

1. Remove personal initialization file prompts. For the Oracle Recovery Kit to work properly, you must remove (or comment out) all prompts in the personal initialization file (i.e., .profile, .bash_profile) for the Oracle user. This file is specific to the shell that is being used by the Oracle user. The file cannot be interactive.

*If “stty” statements are going to be in the personal initialization file, they must be in an “if” statement that verifies that an interactive terminal is being used.

2. Configure Kernel Parameters. Please refer to the Oracle documentation for information on how linux kernel parameters such as shared memory and other kernel resources should be configured. An example of how to set these parameters is below.

On each server in the cluster:

a. Set the following ipcs limits in /etc/sysctl.conf before configuring LifeKeeper.

# changes for Oracle
kernel.shmmax = <value>
kernel.shmmni = <value>
kernel.shmall = <value>
kernel.sem = <value>

b. Run sysctl -p to set the above changes in the kernel.

c. On certain distributions you may need to add sysctl -p to the system initialization file (i.e. boot.local or rc.local) so that these kernel changes are set after each reboot.

3. $ORACLE_HOME directory. When you configure the $ORACLE_HOME directory and associated files on local disks, be sure that the $ORACLE_HOME directory and files are identical on all servers. Use the standard Linux utilities to create and copy directories and files to the set of servers.

*In certain active/active configurations, the location of $ORACLE_HOME are different.

4. Location. The $ORACLE_HOME directory can be on shared or non-shared disks. The advantage to having the directory on shared media is that you only need to configure files such as the parameter file Oracle_HOME/dbs/<initSID.ora or spfileSID.ora> once, if the same shared disk is used for $ORACLE_HOME (e.g. in an active/standby configuration). The disadvantage to the shared directory is that direct access to the file system is available to only one server at a time. SCSI reservations permit only one server at a time access to a LifeKeeper protected shared drive. If creating an active-active cluster configuration where two or more Oracle instances (SID) will be protected independently in the cluster, $ORACLE_HOME must be installed on local, non-shared storage.

5. User and Group ID. An oracle user (oracle) and group (dba) should be created on all servers. The user ID and group ID numbers must be the same on all servers.

6. Databases, archive files, log files and control files. All databases, archive files, log files, and control files must be created on shared file systems or disk partitions. These locations are set in the Oracle parameter file init<SID>.ora or spfileSID.ora. Please refer to the Oracle documentation for information on editing database parameters. The pathnames must be the same for all servers. Oracle internally keeps this information in its control file; therefore, SYSTEMS database space and paths cannot be changed unless Oracle is running.

*Oracle log archiving is not enabled by default. If it is enabled prior to the creation of the LifeKeeper Oracle hierarchy, LifeKeeper will detect the location of the archive files and create a separate file system hierarchy if necessary. But if log archiving is enabled after the LifeKeeper Oracle hierarchy has been created, you must manually create and extend a file system hierarchy to protect the shared archive location, and create a dependency from the Oracle resource to this new file system hierarchy.

*When using storage applications with locking and following recommendations for the NFS mount options, SPS requires the additional nolock option be set, e.g. rw,nolock,bg,hard,nointr,tcp,nfsvers=3,timeo=600,rsize=32768,wsize=32768,actimeo=0.

7. On a new installation of Oracle, the final configuration of the database instance is easier if the database installation program is not allowed to create a database. When the installer asks if you want to create a database, select No. After the installation is complete, run the Oracle Database Creation Assistant (dbca). dbca provides much better control of where database components get created. When running dbca, specify that the Flash Recovery Area gets created on LifeKeeper protected storage.

!The Flash Recovery Destination must be located on a shared drive.

If runInstaller is allowed to create a database, the Flash Recovery Area will have to be relocated manually. (Note: Allowing runInstaller to create a database is not recommended.)

8. During the installation of Oracle using the “runInstaller” utility, there will be a point where the installer verifies the packages and configuration of Linux before proceeding with the Oracle database installation. If LifeKeeper 7.2 (or higher version) has already been installed, a message complaining about a missing ksh package will appear.

If this message is displayed, check the box in the upper righthand corner, Ignore All. The installation of LifeKeeper has removed the ksh package and replaced it with the Public Domain Korn Shell, pdksh. Oracle should install fine using pdksh.

*Beginning with Version 8.0, the Oracle ARK no longer requires pdksh; however, pdksh is still required by the LifeKeeper core and therefore still requires checking the Ignore All setting.

*Beginning with Version 8.1, LifeKeeper provides its own private pdksh package and therefore does not conflict with Oracle’s ksh requirements.

9. Tune the database engine. Refer to Oracle documentation for guidelines on tuning the database engine for data integrity and performance. In particular, the tuning for memory caching and checkpointing frequency is critical to optimizing the application for fault resilience. The checkpoint interval determines the number of uncommitted database transactions. As a result, it determines the number of database transactions that will be lost in the event of a system failure.

10. Database entry in oratab file. The /etc/oratab file must contain an entry for the database. The LifeKeeper configuration routines use the contents of this file to relate $ORACLE_HOME and $ORACLE_SID values. Usually, the Oracle installation program creates the required entry. In a configuration in which the Oracle software is installed to a shared file system, however, you must copy the oratab file from the server where the Oracle installation was performed to the /etc directory of the other servers so that it is available to all the servers.

*The configuration can have only one oratab per server. Refer to the Oracle Product Manual for information on the file format.

*The oratab file can be accommodated in other locations besides /etc. By default, the Oracle ARK looks for the oratab file in /etc followed by /var/opt/oracle. If the oratab file is not located in one of these default locations, then ORACLE_ORATABLOC must be set in /etc/default/LifeKeeper to the directory containing oratab.

11. Disable automatic start-ups. Since LifeKeeper is responsible for starting the databases it controls, be sure to disable any automatic start-up actions. LifeKeeper disables automatic start-up when a hierarchy is created. This is accomplished by modifying the oratab file.

12. The Listener configuration file, listener.ora. New lines should not be embedded in the entries (e.g., SID_NAME=xx should be on one line).

13. Oracle Database Username and Password. LifeKeeper will use local session and OS Authentication to control Oracle Database. If you would like to turn off local OS Authentication for security reasons, LifeKeeper can use the specified username and password. The Oracle Database user must be able to connect as sysdba authority to the database to be protected, and each server’s Oracle Database must have the same username and password. If this configuration is skipped during resource creation, then LifeKeeper will not use username and password to control the Oracle Database resource. This parameter can be added, changed or removed any time after creating the resource.

Once under LifeKeeper protection, the LifeKeeper and database user privileges can be lowered from sysdba to sysoper. See Changing Username / Password for the Oracle Database Account for more information.

Tips for Creating the Oracle Username and Password.

a. On the node where the Oracle database is running, log in to Linux with a user that is part of the dba group. (The “oracle” account is most common.) Using the sqlplus utility, connect to the database as the administrative user by issuing the following command:

$ sqlplus / as sysdba

b. Create a new user for this function:

SQL> CREATE USER lkdba IDENTIFIED BY “password”;

c. Then grant this user SYSDBA privileges:

SQL> GRANT SYSDBA to lkdba;

d. If Oracle has been configured so that each node in the LifeKeeper cluster has a local copy of $ORACLE_HOME, execute these commands on each node in the cluster. After creating the LifeKeeper Oracle hierarchy, bring the database in service on the node and then execute the CREATE and GRANT commands (above) to set up the user in Oracle.

!CAUTION: Avoid configuring two databases on the same file system. If you must configure two databases on the same file system, exercise great care. In this situation, both databases must be placed under LifeKeeper protection and both hierarchies must have the same primary and backup servers.