JTL-Wawi langsam? SQL-Server-Wartung, Indizes und die Grenzen der Express-Edition

„Die Wawi war früher schneller“ – diesen Satz hören wir oft. Artikellisten bauen sich zäh auf, die Suche hängt, der Abgleich mit Shop und Marktplätzen dauert länger als gewohnt. Die Ursache liegt selten in der JTL-Wawi selbst, sondern fast immer eine Ebene darunter: im Microsoft SQL Server.

JTL stellt im JTL-Guide klar, dass der SQL Server ein eigenständiges Produkt ist und nicht Teil der JTL-Wawi – seine Wartung liegt also beim Betreiber. Wer sie nicht einplant, merkt das irgendwann an der Geschwindigkeit.

Typische Symptome

• Übersichten (Artikel, Aufträge, Kunden) laden spürbar langsamer als früher
• Suchen und Filter brauchen mehrere Sekunden
• Abgleich mit Onlineshop oder Marktplätzen dauert länger
• Mehrere Arbeitsplätze gleichzeitig bremsen sich gegenseitig aus
• Die Datenbank wächst kontinuierlich, bei Express nähert sie sich der Größengrenze

Die häufigsten Ursachen

Indizes und Statistiken

Indizes sind für den SQL Server, was das Register für ein Telefonbuch ist. Durch ständiges Einfügen, Ändern und Löschen werden sie fragmentiert: Die Daten verteilen sich auf viele halb gefüllte Seiten, der Server muss mehr lesen. Microsoft weist darauf hin, dass oft die Seitendichte (wie voll die Seiten sind) sogar mehr ausmacht als die Fragmentierung selbst.

Mindestens genauso wichtig sind Statistiken. Auf ihrer Grundlage entscheidet der SQL Server, wie er eine Abfrage ausführt. Laut JTL-Guide werden sie automatisch erst nach größeren Änderungen an einer Tabelle aktualisiert – bei großen Tabellen können sie dazwischen veralten. Microsoft beschreibt außerdem: Wer nach einem Index-Neuaufbau eine Verbesserung sieht, verdankt sie oft vor allem den dabei mitaktualisierten Statistiken – und die lassen sich deutlich günstiger auch einzeln aktualisieren.

Die Grenzen der Express-Edition

Viele kleinere Installationen laufen auf dem kostenlosen SQL Server Express. Das funktioniert – solange die Grenzen nicht erreicht sind. Laut Microsoft gilt für SQL Server 2022 Express:

• Datenbankgröße: maximal 10 GB je Datenbank
• Arbeitsspeicher (Buffer Pool): maximal 1.410 MB je Instanz
• CPU: das Kleinere von 1 Sockel oder 4 Kernen

Mit SQL Server 2025 hat Microsoft das Größenlimit für Express auf 50 GB angehoben; Arbeitsspeicher- und CPU-Grenzen sind gleich geblieben. Zudem fehlt in Express der SQL Server Agent – zeitgesteuerte Wartungsaufträge laufen also nicht von selbst.

JTL weist in der Checkliste zum Umstieg auf Wawi 1.6 darauf hin, dass die Datenbank nach dem Update um mehr als 30 % wachsen kann. Wer schon nahe an 10 GB liegt, sollte das vor einem Update einplanen.

Virenscanner auf Datenbankdateien

Microsoft empfiehlt, die Datendateien (.mdf, .ndf, .ldf), Backup-Dateien (.bak, .trn) und den Prozess sqlservr.exe vom Virenscan auszunehmen – das verbessert die Leistung und verhindert, dass Dateien gesperrt sind, wenn der SQL Server sie braucht. Microsoft weist aber auch darauf hin: Infizierte Dateien in ausgenommenen Pfaden werden dann nicht erkannt. Das ist eine Abwägung, die zu Ihrem Sicherheitskonzept passen muss.

Diagnose: Wo steht Ihre Datenbank?

Alle Abfragen in diesem Abschnitt lesen nur und ändern nichts. Sie laufen in SQL Server Management Studio. eazybusiness ist der Standardname der ersten Mandanten-Datenbank – passen Sie ihn bei Bedarf an.

Edition und Version des SQL Servers:

SELECT SERVERPROPERTY('Edition')        AS Edition,
       SERVERPROPERTY('ProductVersion') AS Version;

Größe und Belegung der Datenbankdateien:

USE eazybusiness;

SELECT name                                           AS Datei,
       type_desc                                      AS Typ,
       CAST(size / 128.0 AS DECIMAL(10,1))            AS Groesse_MB,
       CAST(FILEPROPERTY(name, 'SpaceUsed') / 128.0
            AS DECIMAL(10,1))                         AS Belegt_MB
FROM sys.database_files;

Die Größe wird in 8-KB-Seiten gespeichert; geteilt durch 128 ergibt das MB. Bei Express ist vor allem die Datendatei (Typ ROWS) im Vergleich zum Limit interessant.

Fragmentierung und Seitendichte der größten Indizes (angelehnt an das Beispiel aus der Microsoft-Dokumentation):

USE eazybusiness;

SELECT TOP (30)
       OBJECT_SCHEMA_NAME(ips.object_id)  AS Schema_,
       OBJECT_NAME(ips.object_id)         AS Tabelle,
       i.name                             AS Index_,
       ips.avg_fragmentation_in_percent   AS Fragmentierung_Prozent,
       ips.avg_page_space_used_in_percent AS Seitendichte_Prozent,
       ips.page_count                     AS Seiten
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') AS ips
JOIN sys.indexes AS i
  ON i.object_id = ips.object_id AND i.index_id = ips.index_id
WHERE ips.page_count > 1000
ORDER BY ips.page_count DESC;

Kleine Indizes (unter etwa 1.000 Seiten) sind hier bewusst ausgefiltert – bei ihnen bringt Wartung kaum etwas.

Wann wurden die Statistiken zuletzt aktualisiert?

USE eazybusiness;

SELECT TOP (30)
       OBJECT_NAME(s.object_id)  AS Tabelle,
       s.name                    AS Statistik,
       sp.last_updated           AS Zuletzt_aktualisiert,
       sp.rows                   AS Zeilen,
       sp.modification_counter   AS Aenderungen_seitdem
FROM sys.stats AS s
CROSS APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) AS sp
WHERE OBJECTPROPERTY(s.object_id, 'IsUserTable') = 1
ORDER BY sp.modification_counter DESC;

Viele Änderungen seit der letzten Aktualisierung bei gleichzeitig altem Datum sind ein deutliches Zeichen für fehlende Wartung.

Lösung: ein fester Wartungsplan

Variante 1: Bordmittel der JTL-Wawi

JTL bietet die Wartung direkt in der Datenbankverwaltung an. Laut JTL-Guide: Start > Datenbank, JTL-Datenbankverwaltung öffnen, Mandant wählen, Performanceoptimierung. Dort stehen die Optionen Indizes Neuorganisieren und Neuerstellen und Aktualisierung der Statistiken zur Verfügung.

Die Empfehlung von JTL: Indizes idealerweise täglich, Statistiken wöchentlich – abends, nachts oder am Wochenende. Beim Neuaufbau ist ein Index zeitweise nicht verfügbar, die Wawi kann in dieser Zeit stocken.

Variante 2: Wartungsskript (Ola Hallengren)

Für eine automatische Wartung verweist JTL selbst auf die Maintenance Solution von Ola Hallengren. Sie ist kostenlos und enthält gespeicherte Prozeduren für Backup (DatabaseBackup), Integritätsprüfung (DatabaseIntegrityCheck) sowie Index- und Statistikpflege (IndexOptimize). IndexOptimize wartet nur Indizes, die tatsächlich fragmentiert sind, und überspringt kleine Indizes.

Ein typischer Aufruf aus der offiziellen Dokumentation:

EXECUTE dbo.IndexOptimize
    @Databases              = 'USER_DATABASES',
    @FragmentationLow       = NULL,
    @FragmentationMedium    = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
    @FragmentationHigh      = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
    @FragmentationLevel1    = 5,
    @FragmentationLevel2    = 30,
    @UpdateStatistics       = 'ALL',
    @OnlyModifiedStatistics = 'Y';

Online-Neuaufbau ist laut Microsoft nur in der Enterprise-Edition möglich. In Standard und Express greift das Skript automatisch auf den Offline-Neuaufbau zurück – der sperrt die Tabelle während der Ausführung. Deshalb gehört der Lauf zwingend außerhalb der Geschäftszeiten.

Bei SQL Server Express gibt es keinen SQL Server Agent. Ola Hallengren beschreibt für diesen Fall den Weg über .cmd-Dateien, die die Prozeduren per sqlcmd aufrufen, und die Windows-Aufgabenplanung als Zeitgeber. Prüfen Sie nach der Einrichtung, ob die Aufgaben tatsächlich erfolgreich durchlaufen.

JTL rät im selben Guide zur Vorsicht bei Datenbank-Optimierungswerkzeugen von Drittanbietern und davon ab, eigenständig in tiefere Datenbankfunktionen einzugreifen. Bleiben Sie bei den Bordmitteln des SQL Servers und den von JTL genannten Werkzeugen.

Einzelne Befehle von Hand

Für gezielte Eingriffe – etwa nach großen Importen oder Bereinigungen – genügen oft einzelne Befehle:

USE eazybusiness;

-- Einen bestimmten Index reorganisieren (online, ressourcenschonend)
ALTER INDEX [Indexname] ON dbo.tArtikel REORGANIZE;

-- Alle Statistiken einer Tabelle aktualisieren
UPDATE STATISTICS dbo.tArtikel;

-- Statistiken der gesamten Datenbank aktualisieren
EXEC sp_updatestats;

Microsoft empfiehlt, Wartung nicht pauschal, sondern gezielt einzusetzen: Erst messen, dann handeln. Häufig bringt schon das Aktualisieren der Statistiken den gewünschten Effekt – bei deutlich geringerer Last als ein vollständiger Index-Neuaufbau.

Vor jeder Wartungsmaßnahme gilt: aktuelles Backup erstellen und prüfen. Testen Sie neue Wartungsskripte zuerst auf einer Kopie der Datenbank oder einem Testmandanten, bevor sie auf dem Produktivsystem laufen.

Backup-Kette nicht vergessen

Wartung und Datensicherung gehören zusammen. JTL empfiehlt mindestens ein Backup pro Tag, gelagert an einem anderen Ort als der Server. Beachten Sie dabei:

• Wartung nach dem Backup einplanen, nicht gleichzeitig – beide erzeugen hohe Last auf den Datenträgern.
• Ein Index-Neuaufbau schreibt viel ins Transaktionsprotokoll. Läuft die Datenbank im Wiederherstellungsmodell „Vollständig“, werden die folgenden Protokollsicherungen entsprechend größer.
• Wiederherstellungsmodell nicht „mal eben“ umstellen. Microsoft beschreibt: Nach einem Wechsel von „Einfach“ zurück auf „Vollständig“ beginnt die Protokollkette erst mit einer neuen vollständigen oder differenziellen Sicherung neu.
• Backups stichprobenartig wiederherstellen – erst dann wissen Sie, dass sie funktionieren.

Wann lohnt sich das Upgrade auf SQL Server Standard?

Wartung behebt Fragmentierung und veraltete Statistiken, aber keine festen Editionsgrenzen. Ein Wechsel auf die Standard-Edition ist sinnvoll, wenn:

• die Datenbank sich dem 10-GB-Limit von Express nähert (bei SQL Server 2022 und älter),
• mehrere Arbeitsplätze, Worker und Abgleiche gleichzeitig arbeiten und der Server trotz freiem RAM ausgebremst wird – Express nutzt höchstens 1.410 MB Buffer Pool und 4 Kerne,
• Sie Wartung und Backups zuverlässig über den SQL Server Agent automatisieren möchten.

Zum Vergleich nennt Microsoft für die Standard-Edition von SQL Server 2022 bis zu 128 GB Buffer Pool und das Kleinere von 4 Sockeln oder 24 Kernen. JTL empfiehlt in der Umstiegs-Checkliste für größere Datenbanken ausdrücklich eine höhere SQL-Server-Lizenz. Für Express-Installationen nennt JTL außerdem, den Arbeitsspeicher des SQL Servers auf 1 GB zu begrenzen.

SQL Server 2025 Express hebt das Größenlimit auf 50 GB an, ändert aber nichts an den Grenzen für Arbeitsspeicher und CPU. Prüfen Sie vor einem Versionswechsel in den Systemvoraussetzungen von JTL, welche SQL-Server-Versionen für Ihre Wawi-Version freigegeben sind.

Fazit

Eine langsame JTL-Wawi ist in den meisten Fällen kein Rätsel, sondern eine Wartungsfrage: Indizes pflegen, Statistiken aktuell halten, Backups sauber einplanen – und die Grenzen der Express-Edition im Blick behalten. Mit den Abfragen oben sehen Sie in wenigen Minuten, wo Ihre Datenbank steht.

Sie möchten Ihre Datenbank prüfen lassen oder einen Wartungsplan einrichten, der zu Ihren Geschäftszeiten passt? Als JTL-Servicepartner unterstützen wir Sie gern dabei – von der Diagnose bis zur Entscheidung für oder gegen ein Upgrade.

Häufige Fragen

Quellen

• JTL-Guide: Tipps zur SQL-Server-Wartung
• JTL-Guide: SQL-Server für JTL-Wawi optimal einrichten
• JTL-Guide: Checkliste für den Umstieg auf JTL-Wawi 1.6 und höher
• JTL-Guide: Systemvoraussetzungen aller JTL-Produkte
• Microsoft Learn: Editionen und unterstützte Features von SQL Server 2022
• Microsoft Learn: Editionen und unterstützte Features von SQL Server 2025
• Microsoft Learn: Indizes optimal warten (Reorganisieren und Neuerstellen)
• Microsoft Learn: Statistiken
• Microsoft Learn: Statistiken aktualisieren
• Microsoft Learn: Wiederherstellungsmodell einer Datenbank ändern
• Microsoft Learn: Antivirensoftware für SQL Server konfigurieren
• Ola Hallengren: SQL Server Maintenance Solution
• Ola Hallengren: Index- und Statistikwartung (IndexOptimize)
• Ola Hallengren: Häufige Fragen (u. a. SQL Server Express)