Using Serviceguard Extension for RAC, 10th Edition, April 2011

• The output of cmviewcl shows the current state of each dependency on each node where
the package is configured.
• A failover or multi-node package may define dependencies on multiple multi-node packages.
Multiple failover or multi-node packages may depend on a multi-node package. Multi-level
dependencies can exist; for example, A depends on B which in turn depends on C, etc.
• If A depends on B and B fails, A (the appropriate instance, if A is of type multi-node) is halted.
Why use multi-node packages/simple package dependencies for Oracle
RAC integration
As mentioned previously, we want to use packages to manage the storage for Oracle Clusterware
and RAC database instances. To make the case for the use of the SGeRAC package manager
enhancements, we need separate SGeRAC packages for Oracle Clusterware and the RAC database
instances.
If we have a package only for Oracle Clusterware, then the storage for each RAC database in
the cluster as well as for Oracle Clusterware must be managed out of the Oracle Clusterware
package. This approach could potentially create both a single point of failure as well as a
management bottleneck.
For example, if the storage for one database fails to start up on a given node (for example, because
an SLVM volume group containing part of the database fails to start up), the Oracle Clusterware
package will fail to start up Oracle Clusterware, and consequently none of the RAC database
instances will start up on that node. For some types of failure (for example, the SLVM volume group
is corrupt), the failure to start up the databases could be cluster-wide.
Another example: if we are in a CFS environment with a CFS for each RAC database, then we
need packages for each of the databases to properly model the dependency of a database instance
on its CFS. We cannot do this if there is only a package for Oracle Clusterware. Setting up the
dependency as between Oracle Clusterware and each CFS will result in inappropriate system
behavior (for example, after shutting down a RAC database instance on a node, we will not be
able to shut down its CFS on that node without shutting down Oracle Clusterware.)
If ASM over SLVM or ASM over raw disk is used as storage for oracle RAC database, he can
configure ASMDG MNP. This is a new enhancement to SGeRAC toolkit. This MNP decouples ASM
Disk Group management from OC MNP Package and creates an independent MNP package for
ASM DG management.
The VG for ASM Diskgroup will be specified in this new ASM DG Package configuration file
instead of OC Package configuration file. This package will be responsible for activating the VG
which contains the diskgroup for database and mounting and unmounting of the diskgroup. This
package will also monitor the state of diskgroup.
Configuring this package is mandatory only in metrocluster environment. However, it is only a
recommendation not mandatory in non metrocluster environment. You can configure CRS and RAC
MNP as suggested by the old toolkit.
An example of a bottleneck created if we only have a package for Oracle Clusterware is this: if
we concentrate all storage management in the Oracle Clusterware package, then any time there
is a change in the storage configuration for one database (for example, an SLVM volume group
is added), we would have to modify the Oracle Clusterware package.
These are the main arguments in favor of having separate packages for Oracle Clusterware and
each RAC database. But then the question arises: how do we ensure that these packages start and
halt in the proper order? Prior to version A.11.17, SG/SGeRAC did not provide a mechanism for
package ordering.
Two new features are introduced in SG/SGeRAC that help us solve this problem: MNPs and simple
package dependencies. The combination of MNPs and simple package dependencies is a very
good fit for our problem of coordinating Oracle RAC and SGeRAC. We configure Oracle
84 SGeRAC Toolkit for Oracle RAC 10g or later