Produktion Auswerten & Messen Läuft im Alltag
Datenbank-Leerlauf von 74,4 % auf 8,3 % gesenkt
Der Datenbankserver verbrauchte seine Zeit vor allem für Suchen ohne Ergebnis. 22 gezielte Indizes haben das fast vollständig beseitigt — ein größerer Speicher allein hatte nichts geändert.
Der Fall auf einen Blick
Das Problem
Die Datenbank einer gewachsenen Webplattform war dauerhaft ausgelastet, und niemand wusste, welcher der 6.137 Datenbankaufrufe im Code dafür verantwortlich war.
Was der Fall macht
Misst, wofür ein Datenbankserver seine Zeit verbraucht, und baut gezielte Suchhilfen für die teuersten Abfragen.
Was er bewirkt
Der Anteil der Datenbankzeit für Suchen ohne Ergebnis fiel von 74,4 % auf 8,3 % — gemessen über 20 Minuten.
So funktioniert es
1 von 4 Arbeitsschritten erledigt ein Sprachmodell. Den Rest machen ein normales Programm und ein Mensch.
- 1 Daten Datenbank und Quelltext Die laufende Datenbank einer Webplattform und 6.137 Datenbankaufrufe in 422 Dateien.
- 2 Programm Mitschneiden und einlesen Programme zeichnen die laufenden Abfragen auf, anonymisieren sie sofort und ziehen alle Aufrufe aus dem Code.
- 3 Sprachmodell Gegeneinanderlegen Die KI ordnet Messung und Code einander zu und schreibt die Indizes samt Rückbau-Skript.
- 4 Programm Prüfen Ein Programm hält jede Anweisung vor dem Einspielen gegen die tatsächliche Tabellenstruktur.
- 5 Mensch Freigeben Ein Mensch gibt das Einspielen frei; danach dient dieselbe Messung als Abnahme.
- Datenquelle
- normales Programm
- Sprachmodell (KI)
- Mensch
Die Zahlen dahinter
Was das für Ihren Betrieb heißt
Bevor Sie für einen langsamen Server mehr Hardware kaufen, lassen Sie messen, wofür er seine Zeit tatsächlich verbraucht — die Antwort ist oft eine Handvoll Abfragen.
Das Muster passt auf jede gewachsene Eigenentwicklung mit Datenbank — Warenwirtschaft, Buchungssystem, Kundenportal. Voraussetzung: lesender Zugang zur Datenbank und zum Quelltext. Mehr braucht die Messung nicht.
Erster Schritt: einige Stunden die laufenden Abfragen mitschneiden und nach Zeitanteil sortieren. Meist tragen wenige Abfragen den Großteil. Fallstrick: Ein Mitschnitt einer Produktivdatenbank enthält Kundendaten. Anonymisieren Sie vor dem Ablegen, nicht danach.
Die Ausgangslage
Eine über Jahre gewachsene Webplattform mit vielen Hintergrundjobs: 6.137 Datenbankaufrufe in 422 Dateien. Der Server war dauerhaft beschäftigt, einzelne Vorgänge dauerten Minuten.
Eine Messung über vier Stunden am 23.08.2026 zeigte die Ursache: 70,3 % der Datenbankzeit gingen für Suchläufe drauf, die null Treffer lieferten. Minütliche Jobs suchten ihren Arbeitsvorrat und lasen dafür jedes Mal ganze Tabellen. Eine einzige Abfrage verbrauchte 32,4 % der Serverzeit und lief bis zu 144 Sekunden.
Die Lösung im Einzelnen
Zuerst der Speicher. Der Puffer wurde vergrößert, die Trefferquote stieg von 72,1 % auf 91,3 %. Der Leerlauf-Anteil blieb aber bei 74,4 %. Mehr Speicher hilft nicht, wenn die Suche selbst falsch gebaut ist.
Dann die Indizes — Suchhilfen für die Datenbank. 22 Indizes gezielt für die leeren Suchläufe, jede Anweisung vorher gegen die tatsächliche Tabellenstruktur geprüft, in 75 Sekunden angelegt. Die teuerste Abfrage liest laut Ausführungsplan statt 417.136 Zeilen noch eine.
Dazu eine Adminseite: 4.511 Abfragen je Aufruf auf 4, gemessen rund 260 Sekunden auf 1,17 Sekunden. Diese Änderung ist bisher nur in einer Codekopie umgesetzt und gemessen, noch nicht eingespielt. Die 8,3 % stammen aus einer Messung über 20 Minuten. Der automatische Nachtest eine Woche später brach ab, bevor er messen konnte — der Langzeitbeleg steht noch aus.
| Abfrage | Anteil Serverzeit | Treffer | gelesene Zeilen |
|---|---|---|---|
| Aufgaben-Warteschlange: offene Einträge suchen | 41,7 % | 0 | 382.500 |
| Newsletter: noch nicht versendete Empfänger | 12,3 % | 0 | 96.140 |
| Bestellungen des Tages anzeigen | 3,1 % | 58 | 1.420 |
| Protokoll: alte Einträge löschen | 2,8 % | 0 | 210.900 |
Werte erfunden. Die Spalte „Treffer“ ist die entscheidende: Eine Abfrage, die Hunderttausende Zeilen liest, um null zurückzugeben, braucht keinen stärkeren Server, sondern einen Index.
Was wir dabei gelernt haben
- Ein Zähler mit plausiblem Ergebnis ist kein Beleg. Der erste Zähllauf fand 2.372 Aufrufe und kein einziges Lesen — aufgefallen nur, weil die Verteilung nicht stimmen konnte. Richtig waren 6.137.
- Die eigene Empfehlung hätte den Server am Hochfahren gehindert. Sie enthielt einen Konfigurationsparameter, den die eingesetzte Datenbankversion nicht mehr kennt. Konfiguration gegen die konkrete Version prüfen, nicht aus dem Gedächtnis schreiben.
- Ein Engpass verschwindet nicht, er wandert. Nach dem größeren Speicher stieg die Laufzeit einer Abfrage von 32 auf 289 Sekunden, weil die Parameter für das Schreiben auf die Platte nicht mitgezogen wurden.
- Wer eine Produktivdatenbank mitschneidet, schneidet Kundendaten mit. Der Mitschnitt wird deshalb sofort beim Schreiben anonymisiert — nicht erst vor der Auswertung, und nie in einer Ablage, die nicht dafür gedacht ist.
- Eine Konfigurationsänderung ohne Neustart wirkt nicht. Die geänderte Datei lag bereit, der Server lief mit den alten Werten weiter.
- Ein Nachtest, der nicht meldet, ist kein Nachtest. Die automatische Wirkungsmessung nach einer Woche brach ab, weil eine Datei fehlte — ohne dass jemand eine Nachricht bekam.
Ein Engpass verschwindet nicht, er wandert.
Aus dem Projektjournal, nach der Messung mit größerem Speicher
Drei Messungen, zwei Maßnahmen Tabelle
| Kennzahl | 23.08. Ausgang | 28.08. mehr Speicher | 29.08. + 22 Indizes |
|---|---|---|---|
| Puffer-Trefferquote | 72,1 % | 91,3 % | 91,2 % |
| Leerlauf-Anteil | 70,3 % | 74,4 % | 8,3 % |
| Gleichzeitige Abfragen | 4,59 | 12,46 | 1,22 |
Quelle: Mitschnitt der Prozessliste; Messdauer 4 h, 51 min und 20 min
Der Ablauf als Diagramm Schaubild
Haben Sie so einen Fall im Betrieb?
Schreiben Sie mir in zwei Sätzen, welche Aufgabe bei Ihnen am meisten Zeit frisst. Sie bekommen eine ehrliche Einschätzung — samt Aufwand und samt der Antwort „lohnt sich nicht“, wenn es so ist.