Test alert db
Job details
| Name: |
Test alert db |
| Platform: |
Oracle |
| Category: |
Availability |
| Description: |
Test alert that alerts every ‘X’ minutes. |
| Long description: |
Test alert that alerts every ‘X’ minutes. Useful for testing extensions and not intended for use in production environments. Database centric, so runs on a single database or on one of the nodes in a RAC cluster. |
| Version: |
2.9 |
| Default schedule: |
5,15,25,35,45,55 * * * |
| Requires engine install: |
Yes |
| Compatibility tag: |
.[type=‘instance’ & databasetype=‘oracle’]/.[hasengine=‘YES’] |
Parameters
| Name |
Default value |
Description |
| Time between warnings |
180 |
The time in minutes between each alarm message. |
| Time between alarms |
360 |
The time in minutes between each alarm message. |
| Warning message |
Test WARNING |
The message to send if we send a warning message |
| Alarm message |
Test ALARM |
The message to send if we send an alarm message |
| Ok message |
Test OK |
The message to send if we send an OK message |
| Disable warnings |
NO |
Enables/disables warnings. YES or NO values |
| Disable alarms |
NO |
Enables/disables alarms. YES or NO values |
Job Summary
- Purpose: The purpose of this job is to periodically generate test alerts including warnings, alarms, and OK messages for the Oracle database environment, specifically to test monitoring extensions.
- Why: This job is crucial because it helps in verifying the responsiveness and accuracy of alert systems within database management, ensuring that all monitoring tools are functional even when there are no actual critical events. It’s especially useful in non-production environments or during the testing phase of system setup.
- Manual checking: Although detailed SQL for manual checks isn’t fully disclosed, you can fetch the history of alerts directly from the database by using the following SQL command:
select histr_date, type_message from dbw_test_alert_history order by histr_date desc
System & Job Details
- “Database Type”: Restricted to Oracle database instances with active engines.
- “Execution Schedule”: Alerts generate at the 5th, 15th, 25th, 35th, 45th, and 55th minute of every hour.
- “Company”: This job is constructed and maintained by dbwatch.com.
Core Functionality & Logic
- “Data Observations”: Monitors the time elapsed since the last alert (warning or alarm) and issues new alerts based on specified intervals.
- “Dependencies”: Includes self-referential requirements and historical data storage, ensuring previous alert data is available for reference and determining subsequent actions.
- “Response Triggers”: Based on the timing thresholds, appropriate alert messages are sent out as warnings, alarms, or OK statuses, depending on how much time has passed since the last corresponding alert.
Alert Parameters
Parameter Details:
| Name |
Default Value |
Description |
| Time between warnings |
180 minutes |
Minimum duration between consecutive warning alerts |
| Time between alarms |
360 minutes |
Minimum duration between consecutive alarm alerts |
| Warning message |
Test WARNING |
Specific message dispatched for a warning alert |
| Alarm message |
Test ALARM |
Specific message dispatched for an alarm alert |
| Ok message |
Test OK |
Message sent to indicate no issues |
| Disable warnings |
NO |
Enables or disables the sending of warning messages |
| Disable alarms |
NO |
Enables or disables the sending of alarm messages |
Implementation Details
- “Procedural Actions”: Incorporates creating a database table for storing alert history and a PL/SQL procedure to handle the logic of when to send alerts based on the last event and the specified time intervals.
- “Error Handling”: Includes exception management that logs and alerts in case of procedure failures or unexpected errors.
- “Housekeeping”: Old entries in the alert history table are purged after 30 days to maintain the efficiency and relevancy of the data.
Reports and History
- “Report Structure”: The job provides a structured report on the alert history displaying both the date of the alert and the type of message sent.
- “Report Accessibility”: Available periodically or upon request, tailored to highlight the operational status of the test alerts over time.
Deployment Cautions
- “Environment Suitability”: Explicitly stated as not intended for use in production environments but rather for testing and verification purposes.
- “Installation Preferences”: Designed for forceful installation with an option not to express install, indicating a need for deliberate deployment and setup.
Through the dbWatch Control Center, this job allows thorough testing of alert mechanisms, ensuring monitoring systems are always optimized for timely and precise alerting in real production scenarios.