HP Enterprise Cluster Master Toolkit User Guide (5900-2131, December 2011)

Refer to the Whitepaper Migrating Packages from Legacy to Modular Style,October 2007
and also the Whitepaper on modular package support in Serviceguard at http://
www.hp.com/go/hpux-serviceguard-docs -> HP Enterprise Cluster Master Toolkit
• To add the values to this modular package configuration file, from the older toolkit
configuration file, issue the following command:
# cmmakepkg -i modular.ascii -m ecmt/Oracle/Oracle -t <older toolkit configuration file>
modular1.ascii
• "modular1.ascii" now has values for certain attributes which were present in the older
toolkit configuration file. Parameters like ORACLE_HOME, ORACLE_ADMIN, SID_NAME,
PFILE, LISTENER, LISTENER_NAME, LISTENER_PASS, MONITOR_PROCESSES,
MAINTENANCE_FLAG, MONITOR_INTERVAL , and TIME_OUT will have values from
the old toolkit configuration file. They can be edited if needed for the new environment.
Edit the value for TKIT_DIR (where the new toolkit configuration file should be generated
or where the toolkit scripts are copied to in case of a configuration directory mode of
operation). Leave the INSTANCE_TYPE to the default value "database". Edit the parameters
ASM, ASM_DISKGROUP, ASM_VOLUME_GROUP, ASM_HOME, ASM_USER, ASM_SID,
KILL_ASM_FOREGROUNDS, CLEANUP_BEFORE_STARTUP, and
USER_SHUTDOWN_MODE as mentioned for the database package.
• Apply the new modular package configuration using cmapplyconf.
• Start the database package.
Adding the Package to the Cluster
After the setup is complete, add the package to the Serviceguard cluster and start it.
$ cmapplyconf -P ORACLE_TEST0
$ cmmodpkg -e -n <node1> -n <node2> ORACLE_TEST0
$ cmmodpkg -e ORACLE_TEST0
If necessary, consult the manual Managing ServiceGuard manual available at http://www.hp.com/
go/hpux-serviceguard-docs —>HP Serviceguard for information on managing packages.
Node-specific Configuration
On many clusters, the standby nodes might be lower end systems than the primary node. An SMP
machine might be backed up by a uniprocessor, or a machine with a large main memory may be
backed up by a node with less memory.
From Oracle's point of view, we must make sure that any packaged instance can run on any
specified node in the corresponding package configuration. The Oracle shell script handles this
situation in the following way:
If node-specific tuning is required, set up a node-specific 'init.ora' file for each node in
${ORACLE_HOME}/dbs. This file should be named 'init${SID_NAME}.ora', and there should be
one such file for each host.
For Example:
/ORACLE_TEST0/dbs/initORACLE_TEST0.ora.host1
/ORACLE_TEST0/dbs/initORACLE_TEST0.ora.host2
When the Oracle shell script executes the Oracle commands, they will check for the existence of
such a file before starting the Oracle database. If no host specific init file exists, a 'global'
init${SID_NAME}.ora file is assumed.
50 Using the Oracle Toolkit in an HP Serviceguard Cluster