HP Serviceguard Enterprise Cluster Master Toolkit User Guide, December 2012 (5900-2145)

For more information, see 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
8. 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
9. Now, "modular1.ascii" 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. If required, these values can be edited 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).
Retain 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.
10. Apply the new modular package configuration using cmapplyconf.
11. 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
For more information on managing packages, see the latest Managing Serviceguard manual
available at http://www.hp.com/go/hpux-serviceguard-docs—>HP Serviceguard .
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.
According to Oracle, you 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 runs the Oracle commands, the Oracle shell script also checks 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.
NOTE: If you are using this configuration, you must see the 'PFILE' parameter in the haoracle.conf
configuration file to the specific pfile on a given host. For example, the PFILE in haoracle.conf on
node1 must be set to /ORACLE_TEST0/dbs/initORACLE_TEST0.ora.node1.
Adding the Package to the Cluster 53