control_pkg_db.sh script provides a quick way to manually (de)-activate the disk resources (VxVM) of a cluster package created with the Serviceguard ECMT Oracle Toolkit. This can come in handy when the Serviceguard cluster (package) has become inconsistent/unstartable. In those cases it presents itself as aid for sysadmins & DBAs in their troubleshooting process.
Download the script from following GitHub repository: https://github.com/patvdv/hpux_scripts
The script can be used to:
- Import/deport diskgroup(s)
- Mount/un-mount filesystem(s) of a single database.
By default the script will operate on the cluster package configuration (
cmgetconf) to determine which disk components need to be made available/unavailable.
Alternatively, the user can specify the path to a custom prepared configuration detailing which disk components should be acted upon (
--use-file option). This configuration file can be used to operate in full off-line mode.
There are 4 main modes of operation:
--status: view the status of package, diskgroup(s) and filesystem(s), e.g.:
--mount: make the diskgroup(s) and filesystems(s) configured in the database package (or specified configuration file) available.
--umount: de-activate the diskgroup(s) and filesystems(s) configured in the database package (or specified configuration file)
--get: query the cluster package configuration for its disk-based resources and provide input to create a custom configuration file, e.g:
lines are split by backslash to improve legibility.
- HP-UX 11 (tested on v3)
- HP-UX Serviceguard v16+
- VxVM as volume manager (tested on VxVM 5.1)
- Korn shell
- Both the double-dash (GNU long options) and single-dash notation are supported, e.g.:
- Options carrying no arguments may also be abbreviated to the short-hand single character notation:
- By default the script operates in non-verbose modus. This can be changed by specifying
--verboseas additional parameter on the command-line.
- All script actions are logged to a log file defined in
/var/log) or the setting overridden by the
--log-dircommand-line parameter. Specifying the
--no-logswitch totally disables logging (not recommended)
The script may and should only be executed by the
root super-user. If the typical DBA only has access to the
oracle super-user, a sudo rule should be provided, e.g.:
And execute the script as:
The script has a fair amount of safeties built in:
- The script will only run as
- The script will not run in a RAC environment
- The script will not run on a host without Serviceguard installed
- The script will only operate on fail-over packages (not on multi-node, system packages).
- When specifying a custom configuration file, the script will perform a number of basic syntax checks on the configuration file.
- Mount/umount actions will not be performed if the corresponding cluster package is still UP and RUNNING.
- When un-mounting filesystems, the umount will be retried 3 times. After that the script discards the entire diskgroup and will not try to deport it. You will be required to intervene manually to fix the umount problem and then try again.