HP Serviceguard Extension for SAP (SGeSAP) manual Option 2 Non-MAXDB Environments

NOTE: The data and log disk spaces of MAXDB are called devspaces. For security and performance reasons SAP recommends to place the devspaces on raw devices.

Option 2: Non-MAXDB Environments

Cluster Layout Constraints:

•There is no MAXDB or additional liveCache running on cluster nodes. Especially the APO System RDBMS is either based on , ORACLE or DB2, but not on MAXDB.

•There is no hot standby liveCache system configured.

Often APO does not rely on MAXDB as underlying database technology. But independent from that, all Instances of the APO System still need access to the liveCache client libraries. The best way to deal with this is to make the client libraries available throughout the cluster via AUTOFS cross-mounts from a dedicated NFS package.

Table 4-3 File System Layout for liveCache in a non-MAXDB Environment (Option 2)

Storage Type	Package	Mount Point
shared	lc<LCSID>	/sapdb/data
shared	lc<LCSID>	/sapdb/<LCSID>
shared	lc<LCSID>	/sapdB/<LCSID>/datan
shared	lc<LCSID>	/sapdb/<LCSID>/logn
shared	lc<LCSID>	/var/spool/sql
autofs shared	sapnfs1	/sapdb/programs

1 This can be any standard, standalone NFS package. The SAP global transport directory should already be configured in a similar package. This explains why this package is often referred to as "the trans package" in related literature. A trans package can optionally be extended to also serve the global liveCache fileshares.

Option 3: Full Flexibility

If multiple MAXDB based components are either planned or already installed, the setup looks different. All directories that are shared between MAXDB instances must not be part of the liveCache package. Otherwise a halted liveCache package would prevent that other MAXDB instances can be started.

Cluster Layout Constraint:

▲There is no hot standby system configured. The following directories are affected:

/sapdb/programs: This can be seen as a central directory with liveCache/MAXDB binaries. The directory is shared between all liveCache/MAXDB Instances that reside on the same host. It is also possible to share the directory across hosts. But it is not possible to use different executable directories for two liveCache/MAXDB Instances on the same host. Furthermore, it is not unusual to install different MAXDB versions on the same host. This can be seen from the LC1/AP1 example of the SAP_DBTech.ini file printed below. It is a standard version combination for SCM3.1.

During normal operation, the liveCache most likely won't share the host with the APO database. But the failover might allow mutual backup between the liveCache host and the APO host. This implies that the files in /sapdb/programs have to be of the highest version that any MAXDB in the cluster has. Files in /sapdb/programs are downwards compatible. For the liveCache 7.4 and the APO 3.1 using MAXDB 7.3 this means that within /sapdb/programs there have to be the 7.4 version executables installed.

/sapdb/data/config: This directory is also shared between instances, though you can find lots of files that are Instance specific in here, e.g. /sapdb/data/config/<LCSID>.* According to SAP this path setting is static.

/sapdb/data/wrk: The working directory of the main liveCache/MAXDB processes is also a subdirectory of the IndepData path for non-HA setups. If a liveCache restarts after a crash, it copies important files from

96 SAP Supply Chain Management