The sensor cas_mon_dbspace_full checks the level of all instances of the instance. It generates an alarm if the percendays value of the free memory of a dbspace exceeds the thresholds red or yellow.

Parallel to this sensor there is also a task cas_check_dbspace_full. While the sensor writes the values to the monitoring table once a day, the task checks the thresholds in the 5-minute cycle and generates an alarm when the thresholds are exceeded. This ensures that an overshoot is reported promptly. To ensure that you do not receive emails in the 5-minute rhythm when the thresholds are exceeded, you can use the setting 'alarm repeat time' to determine when the alarm should be repeated on the day. An alarm is repeated if the previous message is more than 24 hours past the set time.

The cas_mon_vp_color sensor collects information about the distribution of CPU resources to the running virtual processors. In contrast to the standard sensors, the difference time to the last run is also noted here. An alarm is not generated when a CPU VP is high in time, but if more than the set number of threads are in the ready queue of the VP. This is an indication that the CPU load of the instance is higher than the resources allocated to it. If you get these alarms, we recommend assigning additional CPU VPs to the instance.

The cas_mon_log_backup sensor counts the log which are not backed-up. Log files and generates an alarm if the number exceeds the red or yellow limit.

The sensor cas_mon_log_count counts the filled log. Log files in a specified time interval and generates an alarm if the number exceeds the red or yellow limit.

The sensor cas_mon_log_trans counts the filled log. logfiles that are within a transaction and generate an alarm when the number exceeds the red or yellow limit.

This alarm is an indication of transactions that are too long in the instance. If this alarm occurs, check how long transactions are made and whether the number and size of the log files is sufficient to obtain the necessary data. If this is not the case, a long transaction abort threatens.

The cas_mon_tabextents sensor checks the number of extents of all tables and generates an alarm if the percentage of available extents for this table falls below a threshold.

This alarm is an indication that in the near future the maximum number of extents for the table will be reached. The table should be reorganized in the near future. In the 12.10 version, this is done simply via the built-in defragmenter (SQL-Admin-API task ('defragment', '<database>: <table>'). There should be enough space in the dbspace where the table is located. Ideal is at least once again the place the table occupies.

The cas_mon_performance sensor collects various performance parameters. It reads from the sysshmvals all parameters starting with pf_. Therefore, the number of parameters within the Informix versions may also vary.

Since not all of these parameters need to be monitored, there are no threshold values for all parameters. Parameters without threshold values do not generate an alarm and can be ignored.

Since the thresholds for these parameters are very much dependent on the size and the workload of the instance, we can not set any really good default values for these parameters. After this sensor has been activated it is necessary to set the thresholds for the alarms according to the values measured in this time after a running time of 1 to 2 weeks.

The sensor cas_mon_wait checks the number of waits for a reason in the system table systwaits. The cumulated waiting time against the yellow or red threshold value is checked for each reason. If the waiting time is above one of the threshold values, an alarm is generated.

In normal cases, there are no values in this table. Only if there are longer waiting times due to high system load are values displayed here.

The sensor cas_mon_table_growth collects information about the growth of tables. For each table, a set with the number rows and the difference to the previous run is created. This allows you to quickly find fast growing tables.

This sensor does not generate any alarms and has no thresholds.

The sensor cas_mon_tabinfo checks the number of pages occupied by a table. The number of pages of a fragment is limited to 16.7 millons. If a table reaches this value, an insert is no longer possible. This is the only way to create a new fragment (only allowed in the Enterprise / Advanced Enterprise Edition) or to convert such a table into a dbspace with larger pagesize.

There are 3 limit values for this sensor. The 1st limit is the number of extents of a table that it must have reached at least to be tested. If you have large tables created with large first and next extent sizes, leave this value set to 0 (all tables). If they are sure that the tables are not affected with a few extents, they can make this value larger.

The other two thresholds are the thresholds for the red or yellow alarm. The upper limit pages per fragment are 16.7 million. The default values leave them enough time to find a solution for normal table growth.

This sensor, cas_mon_locks, checks the sample-by-probe whether there are sessions at the time the sensor is running, whose number of block locks is above the threshold value. If such sessions are found, they are entered into the monitoring table. An alarm is not generated.

This sensor, cas_mon_slow_stmt, checks the sample-by-case if there are SQL statements at the time of the run whose runtime is above the threshold value. If such statements are found, they are entered into the monitoring table. An alarm is not generated.