In den meisten KMU macht derselbe SQL-Server zwei Dinge gleichzeitig: er trägt die laufende ERP-Arbeit und soll nebenbei einen 15-seitigen Vertriebsbericht mit Marge für das letzte Quartal ausspucken. Kein Wunder, dass am letzten Freitag des Monats um 10:30 Uhr die ganze Firma stillsteht.
Das Szenario, das wir im letzten Jahr ein Dutzend Mal gesehen haben, sieht immer gleich aus. Der Geschäftsführer oder der kaufmännische Leiter startet seinen Lieblingsbericht in Comarch Optima oder enova365. Währenddessen kann die Lagermitarbeiterin keinen Wareneingang scannen, dem Verkäufer öffnet sich die Kundenkarte nicht, der Buchhalterin friert das Rechnungsfenster ein. Dreißig Minuten später ist der Bericht da, alle machen weiter — bis zum nächsten Bericht. Das ist kein Problem eines „langsamen ERP". Das ist ein Problem einer einzigen Platte, einer einzigen SQL-Instanz und zweier sehr unterschiedlicher Lasten, die sich gegenseitig auffressen.
Die Lösung, die für Firmen zwischen 15 und 60 Mitarbeitern funktioniert, ist langweilig, in der Branche seit 20 Jahren bekannt und in polnischen KMU immer noch selten umgesetzt: eine separate Reporting-Datenbank, die jede Nacht (oder stündlich) die Daten aus der produktiven Datenbank kopiert. Diese Instanz macht nichts anderes. Dort werden keine Rechnungen geschrieben, keine Aufträge erfasst. Zugriff bekommt nur, wer fragt „wie viel haben wir letztes Quartal wirklich verdient".
Warum sich Berichte und Transaktionen in die Quere kommen
Die Datenbank des produktiven ERP ist auf kurze, berechenbare Abfragen optimiert. Ein Verkäufer schreibt eine Rechnung. Ein Lagerist bucht ein Stück aus. SQL Server hält Indizes, Zeilen-Sperren und Cache passend für diesen Verkehr vor.
Ein Managementbericht macht das Gegenteil. Er liest hunderttausende Zeilen aus mehreren Tabellen und aggregiert sie nach Kunden, Produktgruppen, Regionen. Er setzt Sperren, die transaktionale Arbeit normalerweise nicht braucht. Eine größere Abfrage kann die Tabellen, auf die das Vertriebsmodul alle fünf Sekunden zugreift, für zig Sekunden blockieren.
Man kann sich nicht ewig daraus optimieren. Irgendwann ist die einzig sinnvolle Antwort die physische Trennung: Berichte sollen auf einer anderen Instanz leben als Transaktionen.
Bei einem unserer Kunden — einem 22-Personen-Elektrogroßhandel mit Comarch Optima — lief der monatliche Bericht „Umsatz mit Marge nach Produktgruppen" 27 Minuten lang. In dieser Zeit bekamen vier Verkäufer und zwei Lageristen regelmäßig Timeout-Meldungen. Nach dem Aufsetzen der Replika läuft derselbe Bericht auf der Kopie in 11 Sekunden (weil dort eigene, auf Reporting zugeschnittene Indizes stehen), und der produktive ERP merkt gar nicht mehr, dass ihn jemand gestartet hat.
Drei Wege, eine Replika aufzusetzen
In einem polnischen KMU reicht in der Regel eine dieser drei Varianten. Ein Data Warehouse muss nicht sein.
Transactional Replication im SQL Server. Wenn dein ERP auf Microsoft SQL Server läuft (Optima, enova365, Subiekt GT Pro, die meisten Dynamics-AX-Installationen), ist das eingebaut. Die produktive Datenbank schiebt Änderungen laufend an die Replika — die Verzögerung liegt im Sekundenbereich. Nachteil: braucht Standard Edition oder höher und etwas Vorsicht bei ERP-Updates (die Replikation streitet gelegentlich mit Schemaänderungen).
Mirroring / Always On / Log Shipping. Wenn du ohnehin einen zweiten Server für Disaster Recovery hast, kannst du ihn „nebenbei" fürs Reporting nutzen. Ein Readable Secondary in Always On ist die sauberste Variante — eine Standby-Kopie der Datenbank, auf die live gelesen werden darf. Die DR-Datenbank und die Reporting-Datenbank sind dieselbe Maschine mit zwei Rollen.
Eine einfache nächtliche Kopie (ETL). Die simpelste Variante, zu der wir die meisten 10- bis 30-Personen-Firmen überreden. Jede Nacht holt ein Skript (SSIS, PowerShell, Python, manchmal nur bcp) die geänderten Datensätze aus der Produktion und schreibt sie in eine separate Datenbank. Die Daten sind 24 Stunden alt — und für 90% der Managementberichte reicht das völlig. Vorteil: kein Eingriff in den produktiven ERP, der ERP-Lieferant hat nichts mitzureden, ein Fehlschlag des Jobs legt den Betrieb nicht lahm.
Beim gleichen Elektrogroßhandel haben wir Variante drei gewählt. Ein PowerShell-Skript läuft jede Nacht um 02:00 Uhr und kopiert geänderte Rechnungen, Wareneingänge und Kundenstamm in eine separate Datenbank OptimaReport. Der ganze Lauf dauert 6 Minuten. Die Excel- und Power-BI-Berichte zeigen auf diese Datenbank, nicht auf die Produktion. Umsetzung: zwei unserer Arbeitstage plus 1200 PLN pro Jahr für eine zweite SQL-Server-Web-Lizenz. Ergebnis: keine Timeout-Meldungen mehr, keine Diskussionen „wer darf wann den großen Bericht starten".
Was du vorher entscheiden musst
Egal welche Variante, ein paar Entscheidungen gehören an den Anfang. Wenn man sie überspringt, finden wir später regelmäßig „eine Replika, die seit einem halben Jahr still steht, und keiner hat es gemerkt".
- Akzeptable Verzögerung. 1 Sekunde (Replication), 15 Minuten (Log Shipping), 24 Stunden (nächtliches ETL). Die meisten Managementberichte arbeiten mit Daten, die älter als ein Tag sind — zahle nicht für Echtzeit, die du nicht brauchst.
- Was wird repliziert, was nicht. Die Preishistorie aus 2008 muss nicht jede Nacht kopiert werden. Die vollständige Verkaufsrechnungstabelle, die Rechnungspositionen, Lagerbestände und der Kundenstamm — ja.
- Wer bekommt Zugriff auf die Replika. Eigene schreibgeschützte SQL-Logins für den kaufmännischen Leiter, die Reporting-Leute, Power BI. Keiner setzt sich mit einem transaktionalen Werkzeug auf die Replika — das ist der erste Schritt zu seltsamen Bugs.
- Monitoring, dass die Replika lebt. Ein einfacher Mail-Alarm: „wenn der letzte Zeitstempel in der Tabelle
Rechnungenauf der Replika älter als 36 Stunden ist, schrei". Ohne das erfährst du von dem Ausfall vom kaufmännischen Leiter, der eine Woche alte Zahlen bekommt und ihnen glaubt.
Was man nicht tun sollte
Zwei Fehler, die wir regelmäßig sehen, kosten am Ende mehr als die eigentliche Umsetzung.
Der erste ist „bauen wir gleich ein Data Warehouse". Für eine 20-Personen-Firma ist das überdimensioniert. Eine separate SQL-Datenbank, die die Produktion spiegelt, plus ein paar Reporting-Views — damit sind 95% der Bedarfe erledigt. Ein Warehouse fängt an Sinn zu ergeben bei zehntausenden Transaktionen pro Tag aus vielen Quellen — nicht bei einer einzigen Optima-Instanz.
Der zweite ist „machen wir die Berichte direkt auf dem Backup". Ein Backup ist ein Backup — eine Kopie, die einmal in ein paar Jahren laufen soll, wenn alles brennt. Berichte auf einem Backup abzufragen ist die sicherste Methode, am Tag des Ausfalls festzustellen, dass jemand eine Struktur geändert hat und der Restore nicht funktioniert. Replika und Backup sind zwei verschiedene Funktionen — eine fürs Reporting, eine für die Wiederherstellung. Nicht vermischen.
Wie geht es weiter
Wenn der Lieblingsbericht des Chefs bei euch länger als 2 Minuten läuft und in dieser Zeit irgendjemand im Betrieb die Meldung „Zeitüberschreitung bei der Abfrage" bekommt — habt ihr genau das Problem, um das es in diesem Text geht. Der ERP muss nicht gewechselt werden. Zwei Lasten müssen auf zwei Datenbanken aufgeteilt werden, selbst wenn beide auf derselben Maschine stehen.
Die erste halbe Stunde verbringen wir damit, zu kartieren, welche Berichte am meisten weh tun und welche der drei Varianten bei euch Sinn ergibt. Dabei entsteht in der Regel eine konkrete Liste, die in zwei bis drei Arbeitstagen umsetzbar ist.
Der produktive ERP soll die Arbeit von heute tragen. Die Berichte sollen nebenan leben — auf einer Kopie, zu der nur die greifen, die nach Zahlen fragen.