Configuring HP Serviceguard Toolkit for Oracle Data Guard

Note: The example assumes that the package name is dgpkg, package directory is

/etc/cmcluster/pkg/dgpkg, and the ORACLE_HOME is configured as /orahome.

1. Disable the failover of the package through cmmodpkg command.

$ cmmodpkg -d dgpkg

2. Pause the monitor script.

Create an empty file /etc/cmcluster/pkg/dgpkg/dataguard.debug as shown below:

$ touch /etc/cmcluster/pkg/dgpkg/dataguard.debug

Toolkit monitor scripts (both database instance and listener monitoring scripts), which continuously

monitor ODG process daemons’ processes, would now stop monitoring these daemon processes. The

messages, “Serviceguard Toolkit for ODG pausing Data Guard monitoring and entering maintenance

mode” appears in the Serviceguard Package log file.

3. If required, stop the database instance(s) as shown below:

$ cd /etc/cmcluster/pkg/dgpkg/

$ $PWD/hadg.sh stop

4. Perform maintenance actions (Example: Database maintenance).

5. Restart the Oracle database instance again if you manually stopped it prior to maintenance.

$ cd /etc/cmcluster/pkg/dgpkg/

$ $PWD/hadg.sh start

6. Allow monitoring scripts to continue normally as shown below:

$ rm -f /etc/cmcluster/pkg/dgpkg/dataguard.debug

The message “Starting Oracle Data Guard monitoring again after maintenance” appears in the

Serviceguard Package Control script log.

7. Enable the package failover.

$ cmmodpkg -e dgpkg

Note: If a package failure occurs during maintenance operations, the package does not

automatically failover to an adoptive node. You must manually start the package on the adoptive

node. For more information on manually starting the package on an adoptive node, see the

“Managing HP Serviceguard” guide available at

http://www.hp.com/go/hpux-serviceguard-docs

Troubleshooting

This section provides the guidelines to verify if the ODG package has been configured properly

or not.

The following steps help the user to troubleshoot the possible causes for the package failure:

1. Verify ODG setup:

To verify a Data Guard configuration, check if the standby database is able to receive the redo logs.

Also check if the RFS process is running on the standby database by querying the table

“V$MANAGED_STANDBY.” If the standby site is not receiving the logs, obtain information about the

archiving status of the primary database by querying the V$ARCHIVE_DEST view. Check especially

for error messages.