Linux-UNIX: Configure delayed cluster disk mounting
Configure S-TAP® for delayed loading for Oracle, Informix® and DB2® database servers only.
When the S-TAP starts it must have access to the database home. If your environment uses a clustering scheme in which multiple nodes share a single disk that is mounted on the active node, but not on the passive node, the database home is not available on the passive node until failover occurs.
S-TAP can be
configured for delayed loading by setting a configuration file property,
WAIT_FOR_DB_EXEC. When S-TAP restarts,
either from a system reboot or user initiated S-TAP stop / start
commands, S-TAP polls all
databases that have been configured to be monitored and begins monitoring all valid configurations.
Any configuration anomalies (either on the database side or the S-TAP side) that
limits S-TAP
ability to monitor a database does not limit the S-TAP from monitoring
other databases with valid configurations. This parameter determines the S-TAP response, and
its status in the S-TAP Control page,
if a DB instance is not available (db_install_dir or
db_exec_file is not accessible) during IE validation, after an S-TAP or DB restart.
- 0 and less: S-TAP logs
an event message with the event type CONF_ERROR when a DB instance is detected as unavailable for
certain DB(PROTOCOL) during the S-TAP starting time.
S-TAP also
logs a CONF_ERROR if a DB changes its status from available to unavailable during the periodic check
(every 15 minutes). These event messages change the S-TAP status in the
GUI to yellow with the instruction to correct the parameter or set WAIT_FOR_DB_EXEC >
0. When a DB instance status changes from unavailable to available, a WARNING message
is sent to the sniffer, but the GUI status does not change automatically. You need to click
to open the S-TAP event log and
click Accept. - greater than 0: A WARNING is logged for any unavailable database during S-TAP startup time or during a periodic check. The time interval of the periodic check is the value of wait_for_db_exec, in minutes. A warning message is also sent when an unavailable DB instance becomes available. Since the periodic check needs to get status of the database file configured for each inspection engine, and it consumes the CPUs, the value should not be less than the number of inspection engines.