Sysadmin-Scheduler: cas_mon_ddl und PANIC

Notiz zur Datenbank sysadmin. Der Scheduler führt Tasks und Sensoren aus der Tabelle ph_task innerhalb von oninit aus, als Benutzer informix. Ein normaler SQL-Fehler beendet nur diesen Task-Lauf. Ein NULL-Zeiger im aufgerufenen Servercode nicht: der Thread stirbt, im Online-Log steht PANIC: Attempting to bring system down, die Instanz geht herunter.

Konkreter Fall hier: der Sensor cas_mon_ddl. Er wertet den SQL-Trace aus. NULL im Trace (Anweisungstext oder Host-Variable) läuft in diesen Zeiger und damit in den PANIC. Abhilfe ist, den Sensor abzuschalten, nicht sysadmin zu löschen.

Als informix, gegen die Datenbank sysadmin:

echo "SELECT tk_name, tk_enable FROM ph_task WHERE tk_name = 'cas_mon_ddl';" | dbaccess sysadmin

tk_enable ist t, solange der Sensor läuft, und f, wenn er aus ist. Fehlt die Zeile, ist der Sensor nicht installiert.

echo "UPDATE ph_task SET tk_enable = 'f' WHERE tk_name = 'cas_mon_ddl';" | dbaccess sysadmin

Das ist der von IBM dokumentierte Schalter. Dieselbe Spalte setzt IBM in der Gegenrichtung auf t, zum Beispiel für idle_user_timeout. Die Zeile in ph_task bleibt stehen. Nur der nächste geplante Lauf entfällt. Ein Lauf, der schon im Server steckt, wird von diesem UPDATE nicht abgebrochen.

Nach einem PANIC zuerst starten, dann diese Abschaltung, bevor der Sensor wieder an der Reihe ist. Danach die SELECT-Abfrage erneut ausführen. tk_enable muss f sein.

Tasks und Sensoren sind SPL oder SQL in sysadmin, oft mit admin() oder task() und mit Abfragen auf sysmaster. Das läuft im Adressraum von oninit.

• Ein SQL-Fehler (fehlende Tabelle, Rechte, Datenkonflikt) wird protokolliert. Die Instanz bleibt oben.
• Ein Assert oder ein NULL-Zeiger im Servercode, den der Task dabei betritt, ist kein SQL-Fehler. IBM fährt die Instanz dann mit PANIC herunter. Eine Assertion-Datei muss dabei nicht entstehen.

cas_mon_ddl gehört in die zweite Klasse, weil er den SQL-Trace liest. IBM hat genau diesen Pfad als Absturz dokumentiert, ohne den Sensornamen zu nennen:

• SQL-Trace eingeschaltet und Host-Variablen mit NULL: Absturz der Instanz (IC60371).
• SELECT aus syssqltrace kann die Engine zum Absturz bringen (IC63448).
• NULL-Zeichen über eine Host-Variable bei SQLTRACE HIGH: Absturz (IC67763).
• SELECT auf syssqltrace oder der dbCron-Task sql_showsnap: Speicherfehler (IC70193).

Der Sensor schaltet den Trace und liest syssqltrace. Trifft er dabei auf NULL, ist das derselbe Codepfad. Weil der Aufruf aus dem Scheduler kommt, ist das Ergebnis ein PANIC der Instanz.

• IBM: Built-in tasks and sensors — Task über tk_enable = f in ph_task abschalten.
• IBM Informix 12.10: idle_user_timeout — offizielles UPDATE ph_task SET tk_enable gegen sysadmin als informix.
• IBM Informix 12.10: Creating a task — Tasks liegen in ph_task, Verbindung nur als informix oder ein berechtigter Benutzer.
• IBM: Master Daemon Died — Online-Log PANIC: Attempting to bring system down. Eine Assertion-Datei muss nicht da sein.
• IBM Fix List 11.50.xC4 — IC60371, SQL-Trace und NULL in Host-Variablen.
• IBM Fix List 11.50.xC5W4 — IC63448, Lesen von syssqltrace.
• IBM Fix List 11.50.xC7 — IC67763 und IC70193.

Informix, sysadmin, ph_task, Scheduler, cas_mon_ddl, tk_enable, SQLTRACE, syssqltrace, NULL, PANIC