Die Feuerlöscher

Unser Kunde bei diesem Notfalleinsatz war ein Anbieter für Medizintechnik, der Produkte für die stationäre und ambulante Behandlung vertreibt, wie zum Beispiel Beatmungsgeräte, Atemmasken oder Ventilatoren. Vertrieb, Einkauf und Lager verwalten die Angestellten mithilfe eines Warenwirtschaftssystems. Über eine zentrale App erstellen und bearbeiten sie Vorgänge, speichern Artikel oder werten Umsatzzahlen aus.

Das System ist für einen reibungslosen Informationsfluss im Unternehmen unverzichtbar. Doch eines Morgens reagierte die App auf Eingaben der Mitarbeiter nur noch sehr langsam oder gar nicht. Der hauseigene Datenbank-Administrator vermutete ein Problem mit der Datenbank, das er selbst nicht lösen konnte – also rief er uns an. Wir übernehmen für das Büro seit drei Jahren den Notfall-Support und helfen bei größeren IT-Problemen. Als „Feuerlöscher“ sollten wir die Störung möglichst rasch beheben und die App wieder einwandfrei zum Laufen bringen.

Das System „hängt“ – Was tun?

Zunächst machten unsere IT-Experten den Fehler ausfindig. Es kann viele Gründe haben, warum ein System „hängt“. In diesem Fall zeigte sich: Der Prozessor (CPU) war voll ausgelastet. Die Db2 Datenbank kam nicht mehr nach mit dem Verarbeiten der hereinkommenden Mitarbeiteranfragen. Wir stellten uns die Frage: Warum sind nur so wenig Ressourcen vorhanden? Schließlich stellte sich heraus: Das System wurde am Vorabend neu gestartet. Ein Server-Administrator hatte ihm dabei statt drei nur eine CPU zugeordnet. Der Prozessor war dadurch schnell ausgelastet, was letztendlich zum Stillstand der App führte.

Dazu muss man wissen: Die Datenbank schreibt alle durchgeführten Änderungen in ein Logband. Dessen Speicherplatz ist beschränkt: Ist es voll, führt das System keine Änderung mehr durch. Im Tagesbetrieb kommt man in der Regel nicht über eine Auslastung von zehn Prozent. Durch die langsame Verarbeitung und die wenigen CPU-Ressourcen liefen aber viel mehr Transaktionen parallel auf und belegten das Logband vollständig.

Ursache und Wirkung unterscheiden

Fehlkonfigurationen wie die beschriebenen sind selten, Notfalleinsätze kommen dagegen regelmäßig vor: Durch ein unbekanntes Problem lässt sich eine Anwendung kaum noch bedienen. Das Schwierige bei der Fehlersuche ist oft, Ursache und Wirkung zu unterscheiden.

Auch hier war das der Knackpunkt: Liegt die Ursache in der erhöhten Auslastung des Systems, sodass das Logband vollläuft? Oder führt das volle Logband dazu, dass mehr Last auf dem System ist? Sind also die knappen Ressourcen das Problem? Letzteres war richtig. Um die Ressourcen zu erhöhen, ordneten wir dem System drei CPUs zu und vergrößerten zusätzlich das Logband. Anschließend lief alles wieder reibungslos. Hätten wir nur das Logband vergrößert, wäre die Störung spätestens mittags wieder aufgetaucht.

Bei der Fehlersuche half uns „Speedgain“, ein Monitoring-Tool unter anderem für Db2 Datenbanken. Es zeichnet Kennzahlen und Messwerte auf, speichert, historisiert und wartet die Daten, erstellt Trendcharts, generiert Reports oder führt Detailanalysen durch.

Vor allem aber profitierten wir von unserem umfangreichen Know-how im Umgang mit Db2 Datenbanken. Je mehr Erfahrung man hat, desto schneller erkennt man Zusammenhänge. Mit der Zeit wird man gelassener, lässt sich nicht ablenken und sagt sich: „Okay, ich habe eine Vermutung, aber will es genau wissen, bevor ich vorschnell handle und womöglich andere Probleme bekomme. Denn das hilft am Ende niemandem.“

Kundenvorteile Speedgain für Db2 Datenbanken:

• Transparenz der Datenbank-Performance: Das Monitoring-Tool macht die Leistung des Datenbank-Services für das Gesamtsystem transparent und bewertbar. Grafische Oberflächen mit Charts erleichtern dem Administrator zu sehen, wie gut es dem System gerade geht und machen ihn auf Probleme aufmerksam.
• Alarmierung im Notfall: Werden wichtige Kennzahlen überschritten – liegt zum Beispiel die letzte Sicherung zu lange zurück, ist die SQL-Laufzeit überschritten oder das Transaktionslog voll –, sendet das Tool einen Alarm und generiert nach einer Minute automatisch einen Anruf bei unserer Notfallrufnummer.
• Performance-Tuning: Vermeintlich harmlose SQLs können bei häufiger Ausführung die Performance einer Datenbank stark schwächen – vergleichbar mit tausenden Nadelstichen oder einem Heuschreckenschwarm. SQLs werden bei Analysen und in Reports jedoch oft übersehen. Durch die Analyse des gesamten SQL-Workloads wird der Heuschreckenschwarm mit Speedgain sichtbar.