Examples: Oracle database and SAP R/3

Example 1: Oracle Database

The Oracle Database, like many databases, functions well under PowerHA SystemMirror. It is a robust application that handles failures well. It can roll back uncommitted transactions after a fallover and return to service in a timely manner. However, there are a few things to keep in mind when using Oracle Database under PowerHA SystemMirror.

Starting Oracle

Oracle must be started by the Oracle user ID. Thus, the start script should contain the following code su - oracleuser. The dash (-) is important since the su command needs to take on all characteristics of the Oracle user and reside in the Oracle users home directory. The command would look something like this:

su - oracleuser -c /apps/oracle/startup/dbstart

The dbstart command and the dbshut command read the /etc/oratabs file for instructions on which database instances are known and should be started. In certain cases it is inappropriate to start all of the instances, because they might be owned by another node. This would be the case in the mutual takeover of two Oracle instances. The oratabs file typically resides on the internal disk and thus cannot be shared. If appropriate, consider other ways of starting different Oracle instances.

Stopping Oracle

The stopping of Oracle is a process of special interest. There are several different ways to ensure Oracle has completely stopped. The suggested sequence is this: first, implement a graceful shutdown; second, call a shutdown immediate, which is a somewhat more forceful method; finally, create a loop to check the process table to ensure all Oracle processes have exited.

Oracle file storage

The Oracle product database contains several files as well as data. It is necessary that the data and redo logs be stored on shared disk so that both nodes might have access to the information. However, the Oracle binaries and configuration files could reside on either internal or shared disks. Consider what solution is best for your environment.

Example 2: SAP R/3, a multitiered application

SAP R/3 is an example of a three-tiered application. It has a database tier, an application tier, and a client tier. Most frequently, it is the database tier that is made highly available. In such a case, when a fallover occurs and the database is restarted, it is necessary to stop and restart the SAP application tier. You can do this in one of two ways:

• Using a remote execution command, such as rsh, rexec, or ssh
  Note: Certain methods, such as the use of ~/.rhosts files, pose a security risk.
• Making the application tier nodes cluster aware.

Using a remote execution command

The first way to stop and start the SAP application tier is to create a script that performs remote command execution on the application nodes. The application tier of SAP is stopped and then restarted. This is done for every node in the application tier. Using a remote execution command requires a method of allowing the database node access to the application node.

Making application tier nodes cluster aware

A second method for stopping and starting the application tier is to make the application tier nodes cluster aware. This means that the application tier nodes are aware of the clustered database and know when a fallover occurs. You can implement this by making the application tier nodes either PowerHA SystemMirror servers or clients. If the application node is a server, it runs the same cluster events as the database nodes to indicate a failure. Pre-event and post-event scripts could then be written to stop and restart the SAP application tier. If the application node is a PowerHA SystemMirror client, it is notified of the database fallover using SNMP through the cluster information daemon (Clinfo). A program could be written using the Clinfo API to stop and restart the SAP application tier.