SAP Basis Tech Supports

Symptom

You want to run a MaxDB/SAP DB/liveCache instance in a UNIX cluster for failover.
The database software can be configured differently for your directories depending on your requirements. This note describes tips for installing the software directories.
This note should not be considered for HotStandby implementations. During a HotStandby solution, there is no transfer of the database instance itself, rather the system transfers to a standby instance.
Other terms

Cluster, MSCS, UNIX, Linux
Reason and Prerequisites

You can apply this note with all of the supported MaxDB, SAP DB and liveCache versions.
Solution

The installation distinguishes between different software directories. These are described in

Note the followingdirectories:

Registration: dbmcli [-s] dbm_setpath indepprogpath
SAP Standard:/sapdb/programs
This directory contains downward-compatible instance- or version-independent software. As of Version 7.5, call dbmcli with option -s as user root.
Registration: dbmcli [-s] dbm_setpath indepdatapath
SAP Standard:/sapdb/data
As of Version 7.5, call dbmcli with option -s as user root.
/config
Registration using
SAP Standard:/sapdb/data/config
Registration: dbmcli -d -u , inst_reg
or
dbmcli -R db_create , SAP standard: /sapdb/SID/db
Registration: dbmcli -d -u , param_startsession
param_put
param_checkall
param_commitsession
SAP standard: /sapdb/data/wrk/SID

Up to Version 7.4.3, the /usr/spool/sql directory is used. SAP instances that run with a newer database version may also need the clients of the older versions, so that /usr/spool/sql is used here also.
As of Version 7.5, the file /etc/opt/sdb is created.

Host or node

Below we have designated node A for a host that is active for an instance. The host to which a transfer can occur is designated with node B.

Access modes for the directories

You can structure accesses to the directories in various ways.
local
The directory is only accessible for a certain host.shared
Several hosts can access the directory simultaneously (for example, using NFS). When you use shared directories, the NFS host for the directories should be neither node A nor node B, otherwise a transfer is not possible if you lose the NFS host. A “Single Point of Failure” occurs if the NFS host itself is not secured with clusters.Resource
The directory is only accessible for node A. During the transfer, node B receives the access.
Links

All directories can be referenced using links. You can also define the work directory (run directory) by setting the RUNDIRECTORY database parameter.
Special scenario:
The /config directory contains files for all database instances that are registered on the host.

Case analyses

The system distinguishes between the following cluster use cases:
No database software is running on node B (neither client nor server).A database client (for example, application server) is active on node B. During the transfer, the application and the database share the host.A database instance is running on node B that is deactivated during a transfer.A database instance is running on node B that remains active during a transfer.

No database software is running on node B (neither client nor server).

Define the directory /sapdb and /usr/spool/sql with the subdirectories as the resource. If you are using version 7.5 or higher, copy the file /etc/opt/sdb before the first transfer of node A to node B.

A database client (for example, application server) is active on node B.
Using NFS

Set up the directories and as share directories. Then you do not have to perform any actions during the transfer.

Without using NFS

Set up the directories and as a resource.
The names of the directories
differ, depending on the host (for example, /sapdb/programs_nodeA,
/sapdb/programs_nodeB, /sapdb/data_nodeA, /sapdb/data_nodeB).
During the transfer, change the registration for the two directories. Sample calls for the transfer of node A to B:
dbmcli dbm_setpath indepprogpath /sapdb/programs_nodeA
dbmcli dbm_setpath indepdatapath /sapdb/data_nodeA
You can also implement the procedure using links.
For example:
before the transfer to node B:
/sapdb/programs -> /sapdb/programs_nodeB
/sapdb/data -> /sapdb/data_nodeB
after the transfer to node B:
/sapdb/programs -> /sapdb/programs_nodeA
/sapdb/data -> /sapdb/data_nodeA

General information

The directory /usr/spool/sql is set up locally.
Define the directory as a resource. Register the transfer instance at the latest during the transfer to node B.
For example:
dbmcli -R /sapdb/SID/db db_create , You do not have to handle the directories and /config separately.

A database instance is running on node B that is deactivated during a transfer.

Proceed as in the case “A database client is active on node B (for example, application server)”.
If no NFS is used, you must stop the previously active database instance on node B before reregistering the directories and .

A database instance is running on node B that remains active during a transfer.
Using NFS

When you use NFS, proceed as in the case “A database client is active on node B (for example, the application server)”.

Without using NFS

The directory is set up locally.
It contains the newer software package of the versions from nodes A and B, because the software is upward-compatible. If a new software version is imported on node A, you must also install the Basis tools on node B to ensure downward-compatibility. Execute the following calls using the installation package:
./SDBINST -package “Base”
./SDBINST -package “Server Utilities”
The directory is set up as a resource.
It has a separate name for each host (for example: /sapdb/data_nodeA, /sapdb/data_nodeB).
There are files for different database instances in the directory /config. Before you start the transfer instance, copy the /sapdb/data_nodeA/config/SID* files to /sapdb/data_nodeB/config during the transfer.
The directory /usr/spool/sql is set up locally.
Define the directory as a resource. Register the transfer instance no later than during the transfer to node B.
For example:
dbmcli -R /sapdb/SID/db db_create , Define the directory as a resource. During the transfer, create a link
/sapdb/data_nodeB/wrk/SID -> /sapdb/data_nodeA/wrk/SID
or set the RUNDIRECTORY database parameter to a directory that is not in the subtree of .

Additional tips
If there is a transfer to a host that has other active components (for example, the application server, database), the components must split the available resources. It may therefore be useful, for example, to reduce the data cache during the transfer.
The reduction of the data cache may cause performance to deteriorate considerably with liveCache instances in particular.In the XUSER file, the virtual name should be entered for the database host for the connection information.Operating system user
Ensure that the operating system users on nodes A and B are known with the same ID. In version 7.5, this also applies to owners of the database software (standard system: User sdb, group sdba).