Use of Serviceguard Extension for RAC Toolkit with Oracle RAC 10g Release 2 or later, March 2009

5
• cmrunpkg will fail if the user attempts to start a package that has a dependency on another
package that is not running. The package manager will not attempt to start a package if its
dependencies are not met. If multiple packages are specified to cmrunpkg, they will be started in
dependency order. If the AUTO_RUN attribute is set to YES, the package manager will start the
packages automatically in dependency order.
• cmhaltpkg will fail if the user attempts to halt a package that has another package depending on it
which is still running. If multiple packages are specified to cmhaltpkg, they will be halted in
dependency order. During cmhaltcl or cmhaltnode, the package manager will halt packages in
dependency order.
• 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 shutdown
its CFS on that node without shutting down Oracle Clusterware.)
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