Managing Serviceguard Extension for SAP Version B.05.10, December 2012

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 this directory to a backup location. This information is then used to determine
the reason of the crash. In HA scenarios, for liveCache versions lower than 7.6, this directory
should move with the package. SAP allows you to redefine this path for each liveCache/MAXDB
individually. SGeSAP expects the work directory to be part of the lc package. The mount point
moves from /sapdb/data/wrk to/sapdb/data/<LCSID>/wrk. This directory should not be
mixed up with the directory /sapdb/data/<LCSID>/db/wrk that might also exist. Core files
of the kernel processes are written into the working directory. These core files have file sizes of
several Gigabytes. Sufficient free space needs to be configured for the shared logical volume to
allow core dumps.
NOTE: For liveCache starting with version 7.6 these limitations do not exist any more. The working
directory is utilized by all instances (IndepData/wrk) and can be globally shared.
/var/spool/sql: This directory hosts local runtime data of all locally running
liveCache/MAXDB Instances. Most of the data in this directory becomes meaningless in the
context of a different host after failover. The only critical portion that still has to be accessible after
failover is the initialization data in /var/spool/sql/ini. This directory is almost always very
small (< 1MB).
Table 27 General File System Layout for liveCache (Option 3)
Mount PointPackageStorage Type
/sapdb/<LCSID>lc<LCSID>shared
/sapdb/<LCSID>WRK*lc<LCSID>shared
/sapdB/<LCSID>/datanlc<LCSID>shared
/sapdb/<LCSID>/saplognlc<LCID>shared
122 SAP Supply Chain Management