Serviceguard ECMT Oracle mount helper

About

The 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.

Code

Download the script from following GitHub repository: https://github.com/patvdv/hpux_scripts

Features

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.:

PKG dbacme : UP
DG dbacmedbf01dg : IMPORTED
FS /oradbs/acme/dbf01 : MOUNTED [-o rw,largefiles,nodatainlog,mincache=direct,convosync=direct]
DG dbacmefradg : IMPORTED
FS /oradbs/acme/fra : MOUNTED [-o rw,largefiles,nodatainlog,mincache=direct,convosync=direct]
DG dbacmeredoadg : IMPORTED

• --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:

dbacme:dbacmedbf01dg:/dev/vx/dsk/dbacmedbf01dg/oradbs_acme_dbf01_vol: \
    /oradbs/acme/dbf01:-o rw,largefiles,nodatainlog,mincache=direct,convosync=direct
dbacme:dbacmefradg:/dev/vx/dsk/dbacmefradg/oradbs_acme_fra_vol: \
    /oradbs/acme/fra:-o rw,largefiles,nodatainlog,mincache=direct,convosync=direct

lines are split by backslash to improve legibility.

Dependencies/Requirements

• HP-UX 11 (tested on v3)
• HP-UX Serviceguard v16+
• VxVM as volume manager (tested on VxVM 5.1)
• Korn shell

Usage

# control_pkg_db.sh --help

**** control_pkg_db.sh ****
**** (c) KUDOS BVBA - UNIX (Patrick Van der Veken) ****

(De-)activate database diskgroup(s) (DG) & their filesystem(s) (FS) -- Only works with VXVM!

Syntax: control_pkg_db.sh [--help] | [--version] | [--verbose] [--no-log] [--log-dir=<log_directory>]
    (--status | --get | --mount | --umount) --pkg=<db_package> | --use-file=<config_file>


Parameters:

--get           : display the configuration info from the running cluster for the
       	          database DGs & FSs in order to create a custom configuration file
--help          : show this help text
--log-dir       : specify a log directory location.
--mount         : activate the database DGs & FSs
--no-log        : do not log any messages to the script log file.
--pkg|--package : name of the serviguard database package
--status        : show the current status of the database DGs & FSs
--umount        : de-activate the database DGs & FSs
--use-file      : use the supplied configuration file with list of DGs & FSs
                  (instead of querying the cluster configuration)
--verbose       : execute actions with full feedback/output
--version       : show the script version/release/fix

Note 1: this script should never be run on a RAC cluster or single node instance

Note 2: never forget to un-mount your database DG/FS before starting the cluster
   		package! To be sure run the script with '--status' on BOTH cluster nodes.

<i class="far fa-hand-point-right"></i> Examples (using package 'dbacme', database 'acme'):

1) Import DG and mount FS of the dbacme database (using the cluster configuration)
    control_pkg_db.sh --mount --pkg=dbacme

2) Get current status of DG & FS (using the cluster configuration)
    control_pkg_db.sh --status --pkg=dbacme

3) Unmount FS & deport DG of the dbacme database (using a custom config)
    control_pkg_db.sh --umount --use-file=dbacme.conf

4) Get the configuration data from the cluster to create a custom config file:
    control_pkg_db.sh --get --pkg=dbacme >dbacme.conf

Command-line parameters/options

• Both the double-dash (GNU long options) and single-dash notation are supported, e.g.:

# control_pkg_db.sh --status --pkg=dbacme
# control_pkg_db.sh -status -pkg=dbacme

• Options carrying no arguments may also be abbreviated to the short-hand single character notation:

# control_pkg_db.sh --status --pkg=dbacme
# control_pkg_db.sh -s --pkg=dbacme

Logging

• By default the script operates in non-verbose modus. This can be changed by specifying --verbose as additional parameter on the command-line.
• All script actions are logged to a log file defined in $LOG_DIR (/var/log) or the setting overridden by the --log-dir command-line parameter. Specifying the --no-log switch totally disables logging (not recommended)

Privileges

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.:

# visudo
oracle ALL=(root) NOPASSWD: /etc/cmcluster/scripts/control_pkg_db.sh

And execute the script as:

# su - oracle
$ sudo /etc/cmcluster/scripts/control_pkg_db.sh --status --pkg=dbacme

Run-time checks

The script has a fair amount of safeties built in:

• The script will only run as root.
• 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.