Informix 271 could not insert new row -
Downtime verhindert

Wir überwachen für unsere Kunden existenziell wichtige und zeitkritische Datenbanksysteme.
Für das umfassende Monitoring und die Alarmierung setzen wir natürlich den Admin-Scout für Informix ein.

In diesem Beispiel aus der Praxis hat ein Parameter die definierte Alarmschwelle erreicht.
Der Admin-Scout versendet eine E-Mail an den CURSOR Informix Support:

**************************************************

Notification Type: PROBLEM
Service: informix-checkalert
Alert color: RED

Message:
database: tablename has 16777215 pages, free are 1248744 pages
pagesisze is 2k maximum is 16.7 Mio pages

**************************************************

Bedeutung des Alarms

Eine Tabelle hat die maximale Anzahl von Pages allokiert und die freien Pages liegen unter 10%.
Sobald die freien Pages belegt sind, werden alle Versuche in diese Tabelle zu schreiben abgebrochen.

Prüfung

Der CURSOR Informix Support überprüft den Sachverhalt direkt auf der Maschine. Die Tabelle ist nach Buchungen einzelner Jahre fragmentiert. Erkennbar ist ein anhaltendes überproportional starkes Wachstum im aktuellen Jahr - dies ist die Ursache für den hohen Verbrauch an Pages.

Bewertung

Es besteht ein dringender Handlungsbedarf. Sobald die die verbliebenen freien Pages belegt sind, werden alle Versuche in diese Tabelle zu schreiben mit zwei Fehlermeldungen abgebrochen:

- 271 Could not insert new row into the table.
- 136 ISAM error: no more extents. (*)

Über die vom Admin-Scout gesammelten Wachstumsdaten wird leicht ersichtlich, dass die im aktuellen Jahr übliche Wachstumsrate von ca. 200.000 Sätze pro Tag auf über 500.000 angestiegen ist. Mit den historischen Daten des Admin-Scout und einer vorausschauenden Kalkulation, ermittelt der Informix Support einen Zeitraum von maximal 10 – 14 Tagen bis zum drohenden Stillstand der Datenbank.

Koordination

Der Informix Support setzt sich unmittelbar mit dem Kunden in Verbindung und bereits am nächsten Tag findet ein Planungsmeeting mit den fachlichen Ansprechpartnern statt.

Herausforderung

Die betroffene Tabelle ist für den permanenten 24 Stunden Betrieb notwendig und entsprechend zeitkritisch. Eine mögliche Anpassung der Fragmentierungsstrategie, um das Pagelimit pro Partition zu umgehen, kann nur während eines geplanten Wartungsfensters durchgeführt werden. Da innerhalb der nächsten Wochen keine Downtime möglich ist, muss eine andere Lösung gefunden werden.

In Zusammenarbeit mit dem Kunden wird entschieden, ältere Daten in eine zweite Tabelle mit identischer Struktur auszulagern und die kopierten Sätze in der aktuellen Tabelle zu löschen.

Die Herausforderung ist nun 75 Millionen Sätze zu kopieren und zu löschen, transaktionssicher und ohne Beeinflussung der Performance im laufenden Betrieb. Dies ist nur in kleinen abgeschlossenen Transaktionen möglich. Zur Umsetzung entwickelt und testet der Informix Support eine eigene copy-delete Stored-Procedure. Über Zeitstempel werden die Sätze in Gruppen eingeteilt. Eine Gruppe umfasst die zusammenhängenden Datensätze einer halben Stunde. Diese werden nun gruppenweise kopiert und gelöscht, jede Gruppe in einer abgeschlossenen Transaktion. Dadurch wird sichergestellt, dass es zu keinem Datenverlust kommt und die logische Protokollierung in kleinen Chargen erfolgt.

Durchführung

Die Verarbeitung startet im laufenden Betrieb. Die Verarbeitung über die Stored-Procedure benötigt insgesamt etwa zweieinhalb Stunden. Während dieser Zeit werden die Instanz und die Applikation genauestens überwacht. Sollte es Auswirkungen auf die Performance der Applikation geben, ist durch die Aufteilung in kleine Transaktionen jederzeit ein Abbruch möglich.

Wie zu erwarten, kommt es zu einem starken Anwachsen des I/O, es sind aber keine Behinderungen der Applikation feststellbar. Im normalen Betrieb schreibt das System alle 3 Minuten einen Checkpoint mit 2 - 4 Tausend Dirty Pages. Während der Verarbeitung erhöht sich die Anzahl auf 2 - 3 Checkpoints pro Minute mit 70 - 90 Tausend Dirty Pages je Checkpoint. Die Dauer der Checkpoints steigt auf 0,5 bis 0,8 Sekunden. Ein blockieren von Sessions ist während der gesamten Zeit kaum zu beobachten (weniger als 10 Sessions für höchstens 0,7 Sekunden).

Ohne Impact für den laufenden Betrieb wird so die Gefahr eines Datenbankstillstandes behoben.

Feedback

Im abschließenden Gespräch mit technischen Team des Kunden fällt folgender Satz:
„Ich bin glücklich, dass wir den CURSOR Informix Support haben, sonst hätten wir in zwei Wochen eine stehende Datenbank gehabt, mit Stunden Downtime, um das Problem erst zu finden und dann auch noch zu lösen.“.

Selbstredend, dass es sich hierbei um ein Zero Downtime System handelt, das nur Minuten im Jahr stillstehen darf.