Informix ist bekannt für Zuverlässigkeit, Performance und Sicherheit. Wenn jedoch das Geschäft brummt und die Datenbank „kränkelt“, ist das eine denkbar ungünstige Konstellation. Kunden erwarten schnellen, reibungslosen Service und freundliche Mitarbeiter. Wenn die Datenbank nicht mitspielt, ist das unmöglich zu leisten.
Schnelle Hilfe tut Not – wohl dem, der einen Spezialisten kennt. Lesen Sie hier als Tatsachenbericht, wie NSI-Experte Andreas Seifert mit beherztem Einsatz einem Informix-Anwender schnell und unbürokratisch aus der Klemme half und so einen begeisterten Neukunden gewann.
Mittwoch, 11.50 Uhr: Der Hilferuf
Das Telefon klingelt – ein Kollege bittet um Rückruf bei einem Informix-Anwender, der dringend Hilfe braucht. Eine unbekannte Nummer, ein bislang unbekanntes Unternehmen. Das Problem des Anwenders: die Datenbank wird seit rund 2 Monaten immer langsamer, die aktuelle Performance behindert das Tagesgeschäft sehr. Auch die nächtliche Datensicherung benötigt statt bisher zwei nun mehr als acht Stunden. Telefonisch ließ sich das Problem nicht lösen und wir entschieden, das Ganze vor Ort zu begutachten. Die Kosten waren schnell geklärt und ich machte mich auf den Weg zum Kunden.
Mittwoch 13.45 Uhr: Support vor Ort
Das System ist in Ordnung – angeblich. Vor Ort erfuhr ich bei der Einweisung, dass die Maschine vom Hardware-Lieferant vor einem Monat auf Herz und Nieren gecheckt und für OK befunden wurde. Datenbank-Konfiguration und Logfile hatte der ERP-Hersteller an einen Informix-Distributor weitergeleitet, dem aber keine Unstimmigkeiten aufgefallen waren. Trotzdem war hier der Wurm drin, es lief alles mehr als träge.
Mittwoch 14.30 Uhr: Die erste Spur
Als erstes fiel mir auf, das im online.log die Zeiten für die Checkpoints außergewöhnlich hoch waren. Sie fanden immer zum eingestellten Checkpoint-Intervall von 300 Sekunden statt und dauerten ca. 70-120 Sekunden. Im Klartext: alle 5 Minuten war eine bis zwei Minuten Pause.
Mittwoch 15.30 Uhr: Pause – aber wir bleiben dran!
Erstaunlich, dass in dieser Zeit im normalen Betrieb nur ca. 300 Dirty Pages aufliefen. Das entspricht einer Datenmenge von ca. 600 Kilobyte. Das Schreiben sollte hier deutlich unterhalb einer Sekunde liegen. Daher testeten wir die Schreib- und Lese-Performance der Maschine. Auf Linux gar nicht so einfach, da der Dateisystem-Cache groß und intelligent ist. Eine große Datei, die sicher in der letzten Zeit nicht gelesen wurde, fanden wir schnell in einigen alten dbexport-Verzeichnissen. Das Ergebnis war vernichtend. Das Lesen einer 2GB großen Datei wurde nach 35 Minuten Ergebnislos abgebrochen. Bei kleineren Dateien kamen wir auf Lese-Raten, die die langsamen Checkpoints erklären konnten.
Mittwoch 18.00 Uhr: Planung für den nächsten Tag
Das Problem war analysiert – die Hardware „lahmt“. Schnell wurde der Hardware-Service verständigt, der sein Kommen für den folgenden Tag zusicherte. In einer kurzen Krisensitzung beschlossen wir Maßnahmen, um bis dahin produktives Arbeiten zu ermöglichen. Das Checkpoint-Intervall verlängerten wir auf eine Stunde. Die LRU-Werte konnten nicht mehr verringert werden, sie waren schon auf Minimum. Die nächtliche Datensicherung wurde von der lokalen Platte auf ein Netzwerklaufwerk umgelegt – mit Erfolg: Sie war nach rund 3 Stunden fertig. Auch das veränderte Checkpoint-Intervall brachte Wirkung. Statt 1-2 Minuten Wartezeit alle 5 Minuten kamen wir auf 1-2 Minuten alle Stunde. Leseoperationen, die nicht aus dem Cache kamen, waren aber immer noch sehr träge.
Donnerstag, 18.00 Uhr: Tausch der defekten Hardware
Am Abend kam dann ein Hardware-Techniker und tauschte die Backplane, den SCSI-Kontroller und eine Platte aus. Mit Erfolg: alle Probleme waren nun verschwunden. Ein paar Verbesserungen der onconfig wurden noch auf die Produktionsversion übernommen, was die Performance weiter verbesserte.