Admin-Scout 2.3 - New Scheduler Module
We asked the question, which areas of an Informix database system have to be administered manually and where is it possible to set up an automated administration? The goal is to achieve increasing automation and independent optimization of the system through an interaction of sensors and tasks.
An important aspect here is the administration of the internal database processes. Senior administrators still know how to set up recurring tasks via a cronjob. Today's Informix editions offer independent job management, including the creation of custom tasks and sensors with dedicated result tables and reports.
Informix provides an SQL API and corresponding commands as a basis for setting up tasks. If you are an Informix administrator and are rarely concerned with setting up and managing tasks and sensors, you will find that this can quickly become a complex challenge. Therefore, in the new version of our Admin-Scout, we have intensively addressed the topic of a task scheduler and developed a new Admin-Scout module for the administration of tasks and sensors.
The new Admin-Scout 2.3 Scheduler module offers a centralized administration of all tasks and sensors
Entry Page and tab Overview
The entry page shows in the left column a very good overview of the current states of sensors and tasks. To the right of it, in the tab Overview, you can see when and how often the individual configured elements are triggered. You can sort by each column to see which tasks or sensors will start next. By default, the cursor is on "All" and all content is displayed.
In the case that an unwanted sequence occurs during execution, the button "Stop Scheduler" offers the possibility to stop and restart the Scheduler.
Tab Threshold
In the tab "Threshold" the corresponding parameters of each task or sensor can be managed. By double-clicking on the values, the desired settings can be implemented. In our example, the task "Auto Update Statistics Evaluation" updates the statistics for tables that have undergone more than 10% changes.
The number of parameters varies from task to task or from sensor to sensor.
Tab Runtimes
In the tab Runtimes the execution times can be viewed. In our example, the analysis of the message log file (including possible secondaries) takes about 0.3 seconds. If the values become larger, for example if the message logfile becomes too large, you should consider a logfile switch. It is particularly helpful that changes that may be related to higher workloads or other external influences become visible very quickly.
Tab Alerts
Let's stick to the example of the analysis of a message log file. You can determine at any time which events can be searched for in the log file. In addition to the entries of the alarm program for any threshold value excesses of other sensors, a log file parsing with individual terms can be used here. The settings can be found in the menu item "Administration -> Scout-Admin -> Onlinelog words".
Here we see the alarms issued by the selected sensor and their weighting according to a traffic light control. The column "Object Name" shows why the alarm was generated.
Of course, all generated alarms also converge in the dashboard. However, they can only be viewed there and marked as completed if necessary. The configuration is mostly done here in the Scheduler Module in the tab "Threshold".
Single view of a task or sensor in tab Overview
Back to the "Overview" of a task or sensor.
In the example shown here, the admin scout collects information from tables. If the limit for the maximum number of pages of a table/fragment is reached, an alarm is sent.
This alarm can become very important for large or rapidly growing tables to avoid application failure. We defined this evaluation as a sensor and created a result table for the history. The results can be viewed in the tab "Monitoring Table".
Tab Monitoring Table
In our example, the Monitoring Table tab shows that we are still well below the defined thresholds.
How to create a new task
So much for the monitoring and administration of existing tasks and sensors.
The question now is what to do, for example, to create a new task?
Creating a new task is easy. As an example, we have created a task here that regularly tries to release SHM segments. It is possible to include any known SQL API syntax at this point. To create a new sensor or task you have to select any task on the left side. In "Overview" the button "New" appears.
Conclusion:
Our new scheduler module is an extremely powerful tool for managing and administering tasks and sensors in an Informix instance. It is also possible to define one's own jobs and combine them with a results table in the form of a sensor, if necessary, for comparison with historical data. We have set a storage period of 93 days for the new creation, which can be individually adapted at any time to control data expansion.
