Der Sensor cas_mon_dbspace_full prüft dem Füllstand aller DBSpaces der Instanz. Er generiert einen Alarm, wenn der prozentuale Wert des freien Speichers eines DBSpace die Schwellwerte Rot oder Gelb überschreitet.

Parallel zu diesem Sensor existiert auch ein Task cas_check_dbspace_full. Während der Sensor einmal t&aauml;glich die Werte in die Monitoring-Tabelle schreibt, prüft der Task die Schwellwerte im 5-Minuten-Takt und generiert einen Alarm, wenn die Schwellwerte überschritten werden. Damit ist gewährleistet, das eine Überschreitung zeitnah gemeldet wird. Damit man bei einer Überschreitung der Schwellwerte nicht im 5-Minuten Rythmus Mails bekommt, kann man mit der Einstellung: 'alarm repeat time' bestimmen, wann am Tag ein solcher Alarm wiederholt werden soll. Dabei wird ein Alarm wiederholt, wenn zum eingestelleten Zeitpunkt die vorherige Meldung mehr als 24 Stunden zurück liegt.

Der Sensor cas_mon_vp_color sammelt Informationen über die Verteilung von CPU-Resourcen auf die laufenden Virtuellen Prozessoren. Im Gegensatz zu den Standard-Sensoren wird hier auch die Differenzzeit zum letzen Lauf vermerkt. Ein Alarm wird nicht bei hoher Zeitaufnahme eines CPU-VP generiert, sondern wenn mehr als die eingestellte Anzahl Threads in der Ready-Queue des VP stehen. Dies ist ein Indiz dafür, das die CPU-Last der Instanz höher ist als die ihr zugeteilten Resourcen. Bekommt man diese Alarme, so empfehlen wir, der Instanz weitere CPU-VP's zuzuweisen.

Der Sensor cas_mon_log_backup zählt die nicht gesicherten log. Logfiles und generiert einen Alarm, wenn die Anzahl den roten oder gelben Grenzwert überschreitet.

Der Sensor cas_mon_log_count zählt die gefüllten log. Logfiles in einem festgelegten Zeitinterval und generiert einen Alarm, wenn die Anzahl den roten oder gelben Grenzwert überschreitet.

Der Sensor cas_mon_log_trans zählt die gefüllten log. Logfiles die innerhalb einer Transaktion sind und generiert einen Alarm, wenn die Anzahl den roten oder gelben Grenzwert überschreitet.

Dieser Alarm ist ein Indiz für zu lange Transaktionen in der Instanz. Tritt dieser Alarm auf, so prüfen sie, woher so lange Transaktionen kommen und ob die Anzahl und Größe der Logfiles ausreicht die notwendigen Daten zu fassen. Ist das nicht der Fall, so droht ein Long Transaction Abort.

Der Sensor cas_mon_tabextents prüft die Anzahl der Extents aller Tabellen und generiert einen Alarm, wenn der Prozentsatz der verfügbaren Extents für diese Tabelle einen Schwellwert unterschreitet.

Dieser Alarm ist ein Indiz dafür das in nächster Zukunft die maximale Zahl der Extents für die Tabelle erreicht wird. Die Tabelle sollte in nächster Zeit reorganisiert werden. In der 12.10'er Version geht das einfach über den eingebauten Defragmentierer (SQL-Admin-API task ('defragment', '<database>:<table>'); ). Im DBSpace in dem die Tabelle liegt sollte genügend Platz sein. Ideal ist mindestens noch einmal der Platz den die Tabelle einnimmt.

Der Sensor cas_mon_performance sammelt verschiedene Performance Parameter. Er liest aus der sysshmvals alle Parameter die mit pf_ beginnen. Deshalb kann auch die Anzahl Parameter innerhalb der Informix-Versionen variieren.

Da nicht alle diese Parameter überwacht werden müssen, gibt es auch nicht für alle Parameter Schwellwerte. Parameter ohne Schwellwerte erzeugen keinen Alarm und können ignoriert werden.

Da die Schwellwerte für diese Parameter sehr stark von der Größe und dem Workload der Instanz abhängen, könne wir für diese Parameter auch keine wirklich guten Default-Werte vorgeben. Nachdem dieser Sensor aktiviert wurde ist es notwendig, nach einer Laufzeit von 1 bis 2 Wochen anhand der in dieser Zeit gemessenen Werte die Schwellwerte für die Alarme entsprechend zu setzen.

Der Sensor cas_mon_wait prüft die Anzahl der Waits für eine Grund in der System-Tabelle systwaits. Pro Grund wird die kumulierte Wartezeit gegen den gelben bzw. roten Schwellwert geprüft. Liegt die Wartezeit über einem der Schwellwerte, so wird ein Alarm generiert.

Im Normalfall, stehen in dieser Tabelle keine Werte. Nur wenn es zu längeren Wartezeiten aufgrund hoher Systemlast kommt werden hier Werte angezeigt.

Der Sensor cas_mon_table_growth sammelt Informationen über das Wachstum von Tabellen. Für jede Tabelle wird ein Satz mit der Anzahl rows und der Differenz zum vorherigen Lauf erstellt. Dadurch kann man leicht schnell wachsende Tabellen ermitteln.

Dieser Sensor generiert keine Alarme und hat dem zufolge auch keine Schwellwerte.

Der Sensor cas_mon_tabinfo prüft die Anzahl der durch eine Tabelle belegten pages. Die Anzahl pages eines Fragmentes ist auf 16,7 Millonen limitiert. Erreicht eine Tabelle diesen Wert, ist ein insert nicht mehr möglich. Hier hilft nur das Anlegen eines neuen Fragments (nur in der Enterprise/Advanced Enterprise-Edition erlaubt) oder das Umlegen einer solchen Tabelle in einen DBSpace mit größerer Pagesize.

Für diesen Sensor gibt es 3 Grenzwerte. Der 1. Grenzwert ist die Anzahl extents einer Tabelle, die sie mindestens erreicht haben muss, um geprüft zu werden. Haben sie große Tabellen, die mit großen First- und Next-Extent-Sizes angelegt wurden, so lassen sie diesen Wert auf 0 (alle Tabellen). Sind sie sicher, das Tabellen mit wenigen Extents nicht betroffen sind, so können sie diesen Wert größer setzen.

Die anderen beiden Schwellwerte sind die Schwellwerte für den Alarm Rot oder Gelb. Die Obergrenze Pages pro Fragment sind 16,7 Millionen. Die Default-Werte lassen ihnen also bei normalen Tabellen-Wachstum genügend Zeit eine Lösung zu finden.

Dieser Sensor cas_mon_locks prüft stichprobenartig, ob es zum Zeitpunkt des Laufs des Sensors Sessions gibt, deren Anzahl Satzsperren oberhalb des Schwellwertes liegt. Werden solche Sessions gefunden, werden sie in die Monitoring-Tabelle eingetragen. Ein Alarm wird nicht generiert.

Dieser Sensor cas_mon_slow_stmt prüft stichprobenartig, ob es zum Zeitpunkt des Laufs SQL-Statements gibt, deren Laufzeit oberhalb des Schwellwertes liegt. Werden solche Statements gefunden, werden sie in die Monitoring-Tabelle eingetragen. Ein Alarm wird nicht generiert.