Der Monatsbericht läuft eine halbe Stunde und bremst alle anderen aus? Warum das passiert und was hilft

Der letzte Arbeitstag im Monat. Um acht Uhr morgens startet die Buchhaltung den monatlichen Umsatzbericht. Fünf Minuten später kann das Lager keine Lieferscheine drucken, und der Vertrieb ruft die IT an, weil das System ausgefallen sei. Niemand weiß, was los ist, also klickt jemand in der Buchhaltung noch einmal auf “Erstellen”. Jetzt laufen zwei Berichte.

Dieses Szenario ist erfunden, aber fast jedes Unternehmen mit einer eigenen Geschäftsanwendung wird es wiedererkennen. Und meistens liegt es nicht am Server. Es liegt daran, wie die Berichte gebaut sind.

1. 08:00Die Buchhaltung startet den Monatsbericht
2. 08:05Das Lager kann keine Lieferscheine drucken
3. 08:20Der Vertrieb meldet, das System sei ausgefallen
4. 08:25Jemand startet den Bericht noch einmal
5. 08:40Zeitüberschreitung, alles beginnt von vorn

Warum ein einziger Bericht alle aufhält

Stellen Sie sich ein Geschäft vor, das für die Inventur schließt, während die Kunden noch an der Kasse anstehen. Geschäftsanwendungen machen das ständig:

• Berichte und Tagesgeschäft nutzen dieselbe Datenbank. Der Bericht liest Millionen von Zeilen, und dieselbe Festplatte, derselbe Speicher und derselbe Prozessor müssen gleichzeitig Lager, Vertrieb und alle anderen bedienen.
• Lesen blockiert Schreiben. Auf SQL Server kann ein langer Lesevorgang in der Standardeinstellung jeden aufhalten, der dieselben Daten ändern will, und umgekehrt. Der Bericht wartet auf das Lager, das Lager wartet auf den Bericht.
• Alles wird jedes Mal neu berechnet. Um die Summe des letzten Monats zu bekommen, addiert der Bericht jedes Mal fünf Jahre Rechnungen. Solange es wenige Daten gab, hat es niemand bemerkt.
• Die Anwendung lädt alles in den Speicher. Statt die Datenbank summieren und hundert Zeilen zurückgeben zu lassen, lädt die Anwendung alle Daten und rechnet selbst.
• Der Nutzer wartet vor dem Bildschirm. Der Bericht läuft, während der Browser wartet. Gibt der Browser auf, klickt der Mensch noch einmal, und dieselbe Arbeit läuft doppelt.

Was es kostet

Ein einfaches Beispiel mit erfundenen, aber realistischen Zahlen:

Mitarbeitende, die in der Anwendung arbeiten	40
Verlorene Zeit, wenn ein Bericht alles ausbremst	30 Minuten
Wie oft das passiert (Monatsabschluss, Umsatzsteuer, Geschäftsleitung, ad hoc)	4-mal im Monat
Verlorene Stunden pro Monat	80
Bei 30 € pro Stunde	2.400 € im Monat, fast 29.000 € im Jahr

Das ist nur, was sich zählen lässt. Dazu kommen verspätete Lieferungen, eine Buchhaltung, die abends bleibt, um niemanden zu stören, und Entscheidungen auf Basis alter Zahlen, weil sich niemand traut, den Bericht während der Arbeitszeit zu starten.

Lösungen, die günstigste zuerst

Die gute Nachricht: Ein neues System brauchen Sie selten. Die Reihenfolge ist meistens dieselbe:

Lösung	Was sie bedeutet	Aufwand
1. Abfrage und Indizes	Der Bericht fragt die Datenbank richtig und bekommt nur, was er braucht	Tage
2. Lesen blockiert Schreiben nicht	Eine Datenbankeinstellung, damit Bericht und Lager nicht mehr aufeinander warten	Stunden bis Tage, mit Tests
3. Der Bericht läuft im Hintergrund	Der Nutzer klickt, arbeitet weiter und bekommt eine E-Mail mit Link, wenn der Bericht fertig ist	Tage
4. Vorberechnete Summen	Summen pro Tag, Kunde und Artikel werden einmal berechnet, nachts	Tage bis Wochen
5. Eine eigene Kopie für Berichte	Berichte lesen aus einer Kopie der Datenbank, das Tagesgeschäft nutzt das Original	Tage, je nach Plattform

1. Abfrage und Indizes. Das ist fast immer der erste Schritt und oft auch der letzte. Ein Bericht, der die ganze Tabelle liest, weil ein Index fehlt, oder ein Bericht, der für eine Seite Tausende Abfragen schickt, kann von einer halben Stunde auf unter eine Minute fallen. Die häufigsten Ursachen haben wir in den Artikeln über langsame Anwendungen und EF Core Performance beschrieben.

2. Lesen blockiert Schreiben nicht. SQL Server hat eine Option (Read Committed Snapshot Isolation), mit der ein Bericht ein konsistentes Bild der Daten liest, ohne jemanden aufzuhalten, der schreibt. In Azure SQL Database ist sie standardmäßig eingeschaltet, auf Ihrem eigenen SQL Server ausgeschaltet. Es ist eine einzige Einstellung, aber sie ändert das Verhalten der Datenbank, deshalb wird sie getestet, bevor sie live geht.

3. Der Bericht läuft im Hintergrund. Statt dass jemand vor dem Bildschirm wartet, kommt der Bericht in eine Warteschlange und wird erstellt, wenn Kapazität frei ist, einer nach dem anderen. Wer ihn angefordert hat, bekommt eine E-Mail, wenn er fertig ist. Keine Doppelklicks und Zeitüberschreitungen mehr, und die schwersten Berichte können bis zum Abend warten.

4. Vorberechnete Summen. Die meisten Berichte fragen dasselbe: wie viel, pro Tag, Kunde, Artikel oder Region. Diese Summen lassen sich einmal berechnen, nachts oder nach jeder Änderung, und der Bericht liest dann einige Tausend Zeilen statt einiger Millionen.

5. Eine eigene Kopie für Berichte. Wenn Sie Azure SQL Database in der Stufe Premium oder Business Critical nutzen, bezahlen Sie bereits eine schreibgeschützte Kopie der Datenbank, die die Anwendung nicht verwendet. Berichte werden mit einer Einstellung im Connection String dorthin geleitet:

"ConnectionStrings": {
  "App":     "Server=tcp:company.database.windows.net;Database=Erp;...",
  "Reports": "Server=tcp:company.database.windows.net;Database=Erp;ApplicationIntent=ReadOnly;..."
}

Das Tagesgeschäft nutzt App, die Berichte nutzen Reports, und sie konkurrieren nicht mehr um dieselben Ressourcen. Daten können auf der Kopie einen Moment später ankommen als im Original, was für einen Monatsbericht keine Rolle spielt. Auf Ihrem eigenen SQL Server ist Ähnliches möglich, hängt aber von Edition und Lizenzierung ab, deshalb wird das zuerst geprüft.

In welcher Reihenfolge

1. MessenWelche Berichte schmerzen und warum
2. AbfragenIndizes und weniger Aufrufe
3. HintergrundNiemand wartet vor dem Bildschirm
4. Summen und KopieNur wenn noch nötig

Zuerst wird gemessen, wie immer. Die Messung zeigt, welche drei oder vier Berichte den größten Teil der Probleme verursachen, und oft ist es weniger Arbeit, als es schien. Erst wenn die Abfragen in Ordnung sind, lohnt es sich, über Hintergrundverarbeitung, vorberechnete Summen und eine eigene Datenbank zu sprechen. Ein neues Reporting-Tool oder ein stärkerer Server kommen zuletzt, wenn überhaupt.

Wie wir arbeiten

ProCoding ist ein .NET-Studio aus Split, Kroatien. Langsame Berichte und eine Datenbank, die alle anderen aufhält, sind genau das, was wir beheben: in .NET-Anwendungen, SQL Server und Azure SQL, von Abfragen und Indizes bis zur Hintergrundverarbeitung und schreibgeschützten Kopien der Datenbank. Mehr darüber, was wir auf Azure machen, finden Sie auf der Seite Azure für .NET-Anwendungen.

Wir beginnen mit einer Messung Ihrer Berichte, und Sie erhalten eine Liste der Ursachen und Lösungen, sortiert nach dem, was sich am meisten lohnt. Danach beheben wir sie, oder Ihr Team tut es, wie es Ihnen besser passt. Der erste Schritt ist ein kostenloses 30-minütiges Gespräch.

Quellen

• Read queries on replicas (read scale-out), Microsoft Learn
• SET TRANSACTION ISOLATION LEVEL, Microsoft Learn
• Background tasks with hosted services in ASP.NET Core, Microsoft Learn