Kurz gesagt: Wenn Ihre Logo-Datenbank langsam ist, klären Sie zuerst, ob nur eine Maske oder alle Benutzer betroffen sind. Prüfen Sie danach auf der SQL-Server-Seite der Reihe nach Editionsgrenzen, Speichereinstellung, Datenträger-Wartezeiten, Sperren, Statistiken und Indizes. Messen Sie vor und nach jeder einzelnen Änderung.
In Installationen von Logo Edge T-Series (früher Logo Tiger 3) und Logo Edge N-Series (früher Logo Netsis 3) liegen die Unternehmensdaten in einer Microsoft-SQL-Server-Datenbank. Dauert das Speichern einer Rechnung länger oder frieren Masken am Monatsende ein, heißt es schnell: „Der Server reicht nicht.“ Als Logo-Partner finden wir in unseren Projekten meist zuerst Konfigurations-, Wartungs- und Sperrprobleme. Dieser Beitrag gibt Ihnen eine Checkliste, die Sie oder Ihr IT-Team Schritt für Schritt abarbeiten können.
Inhalt
- Liegt die Langsamkeit wirklich an der Datenbank?
- Erst messen, dann ändern
- Logo-Datenbank langsam: die SQL-Server-Checkliste
- Vom Symptom zur Ursache: Diagnosetabelle
- 5 gut gemeinte Eingriffe, die es schlimmer machen
- Wann sollten Sie Hilfe holen?
- Fazit
Liegt die Langsamkeit wirklich an der Datenbank?
SQL Server ist das relationale Datenbankmanagementsystem von Microsoft. Logo-Produkte schreiben Datensätze in dessen Tabellen und lesen Berichte daraus.
Nicht immer ist die Datenbank die Ursache. Netzwerk, Terminalserver, Client-PC oder ein einzelnes Berichtsdesign zeigen dasselbe Symptom. Beantworten Sie vor der Checkliste drei Fragen:
- Wo? Ist eine Maske oder ein Bericht langsam, oder jedes Modul?
- Wer? Ist ein Benutzer betroffen, oder alle? Klagen Benutzer in einer entfernten Filiale mehr?
- Wann? Zu bestimmten Zeiten (Sicherung, Massenimport, Monatsende) oder den ganzen Tag?
Ist nur ein Benutzer an einem PC betroffen, prüfen Sie zuerst Client und Netzwerk. Sind alle in jedem Modul zur selben Zeit langsam, liegt das Problem sehr wahrscheinlich beim SQL Server. Ist nur ein Bericht langsam, sind seine Filter und sein Datumsbereich die ersten Verdächtigen.
Erst messen, dann ändern
Der häufigste Fehler, den wir sehen: Einstellungen ändern, ohne zu messen. Nach drei Änderungen auf einmal weiß niemand, welche geholfen hat. Gehen Sie in dieser Reihenfolge vor:
- Notieren Sie den langsamen Vorgang: welche Maske, welcher Bericht, welche Uhrzeit, wie lange.
- Halten Sie die Wartestatistiken (wait statistics) des SQL Servers und die ressourcenintensivsten Abfragen fest.
- Nehmen Sie eine einzige Änderung vor.
- Messen Sie denselben Vorgang unter denselben Bedingungen erneut und vergleichen Sie.
Dabei hilft der Abfragespeicher (Query Store). Er speichert Laufzeiten und Pläne der Abfragen in der Datenbank, sodass Sie vorher und nachher direkt vergleichen können. Laut der Microsoft-Dokumentation zum Abfragespeicher ist er für neue Datenbanken ab SQL Server 2022 standardmäßig aktiv. In älteren Versionen schalten Sie ihn selbst ein.
Logo-Datenbank langsam: die SQL-Server-Checkliste
Arbeiten Sie die acht Schritte der Reihe nach ab. Die ersten gehen schnell und erklären das Problem oft schon allein.
1. SQL-Server-Edition und ihre Grenzen
Prüfen Sie, auf welcher SQL-Server-Edition die Installation läuft. Die kostenlose Express-Edition hat klare Grenzen. Laut Microsofts Editionsvergleich für SQL Server 2022 darf eine Express-Datenbank höchstens 10 GB groß sein, der Pufferpool nutzt höchstens 1.410 MB Arbeitsspeicher, und die Rechenleistung ist auf das Kleinere von 1 Sockel oder 4 Kernen begrenzt. Mit wachsendem Datenbestand können diese Grenzen direkt zu Langsamkeit führen. Ein Editionswechsel will geplant sein.
2. Speichereinstellung (max server memory)
Mit Standardeinstellungen kann SQL Server fast den gesamten Arbeitsspeicher des Servers belegen. Der Standardwert von „max server memory“ beträgt 2.147.483.647 MB. Laufen Logo-Anwendungsdienste, Terminalsitzungen oder andere Software auf demselben Server, konkurrieren sie um Speicher. Microsofts Leitfaden zur Serverspeicherkonfiguration empfiehlt, SQL Server etwa 75 % des Speichers zuzuweisen, den andere Prozesse nicht nutzen. Listen Sie vor der Änderung auf, was sonst auf dem Server läuft.
3. Datenträger und Wartetypen
Wenn SQL Server einen Task warten lässt, hält er den Grund fest. Die häufigsten Wartetypen in sys.dm_os_wait_stats zeigen Ihnen die Richtung:
- PAGEIOLATCH_SH und PAGEIOLATCH_EX: Warten auf das Lesen von Datenseiten vom Datenträger. Lange Wartezeiten deuten auf das Datenträgersubsystem. Bei zu wenig Arbeitsspeicher werden Seiten öfter vom Datenträger gelesen, auch das erhöht diese Wartezeit.
- WRITELOG: Warten auf das Schreiben des Transaktionsprotokolls. Prüfen Sie die Latenz des Datenträgers mit der Protokolldatei.
- Wartetypen mit LCK_M_: Warten auf eine Sperre. Das Problem ist nicht der Datenträger, sondern gleichzeitige Arbeit.
Dass Datendateien, Protokolldatei und tempdb auf demselben langsamen Datenträger liegen, erleben wir in unseren Projekten häufig.
4. Sperren (Blocking)
Startet ein Benutzer eine lange Transaktion, müssen andere Benutzer warten, die dieselben Datensätze brauchen. Benutzer beschreiben das als „Logo ist eingefroren“. Sehen Sie sich im Aktivitätsmonitor von SQL Server Management Studio die Spalte „Blocked By“ an oder das Feld blocking_session_id in sys.dm_exec_requests. Ein Wert ungleich null bedeutet, dass die Sitzung auf eine andere Sitzung wartet. Suchen Sie die Sitzung am Anfang der Kette. Meist ist es ein langer Bericht, ein Massenimport oder eine offen gelassene Transaktion. Mehr dazu im Beitrag SQL-Sperrprobleme verhindern.
5. Statistiken
SQL Server wählt den Abfrageplan anhand von Statistiken, die die Datenverteilung einer Tabelle zusammenfassen. Nach einem Massenimport oder einem arbeitsreichen Monatsende veralten Statistiken, und eine Abfrage wählt einen schlechten Plan. Laut Microsofts Dokumentation zur Indexwartung kommt die Verbesserung durch einen Indexneuaufbau oft von der dabei mitlaufenden Statistikaktualisierung. Statistiken zu aktualisieren kostet deutlich weniger Ressourcen. Planen Sie deshalb zuerst die Statistikwartung.
6. Indizes
Messen Sie die Indexfragmentierung mit sys.dm_db_index_physical_stats. Microsoft rät davon ab, Wartung allein nach einem festen Fragmentierungsschwellenwert zu entscheiden, und empfiehlt, die Wirkung zu messen. Statt jede Nacht alle Indizes neu aufzubauen, konzentrieren Sie sich auf die gemessenen Indizes mit sichtbarer Wirkung. Legen Sie in Logo-Tabellen nicht eigenmächtig neue Indizes an; entscheiden Sie das mit Ihrem Partner und testen Sie zuerst. Die Wartungsmethoden vergleichen wir im Beitrag SQL Server Indexwartung.
7. tempdb
tempdb ist der temporäre Arbeitsbereich des SQL Servers. Sortieren, Gruppieren und große Berichte nutzen ihn stark. Laut Microsofts tempdb-Dokumentation beginnen Sie bei acht oder weniger logischen Prozessoren mit ebenso vielen Datendateien, bei mehr Prozessoren mit acht Dateien. Hält der Konflikt an, erhöhen Sie die Zahl in Vielfachen von vier. Alle Dateien sollten dieselbe Anfangsgröße und dieselben Wachstumseinstellungen haben.
8. Daten- und Protokolldateien
Prüfen Sie die Einstellungen für automatisches Wachstum (Autogrowth). Eine Protokolldatei, die in sehr kleinen Schritten wächst, verursacht zu Spitzenzeiten häufige Wachstumswartezeiten. Stellen Sie sicher, dass AUTO_SHRINK ausgeschaltet ist; laut Microsoft führt häufiges Verkleinern und Vergrößern zu physischer Fragmentierung. Ist das Wiederherstellungsmodell FULL, prüfen Sie, ob regelmäßige Protokollsicherungen laufen. Sonst wächst die Protokolldatei weiter.
Kurze Checkliste:
- Sind langsamer Vorgang, Uhrzeit und Dauer notiert?
- Sind SQL-Server-Edition und ihre Grenzen bekannt?
- Ist max server memory unter Berücksichtigung der anderen Dienste gesetzt?
- Sind die häufigsten Wartetypen festgehalten?
- Ist die Sitzung am Anfang der Sperrkette gefunden?
- Ist die Statistikwartung eingeplant?
- Richtet sich die Indexwartung nach Messungen?
- Sind die tempdb-Dateien gleich groß und auf einem schnellen Datenträger?
- Ist AUTO_SHRINK aus und laufen Protokollsicherungen regelmäßig?
Vom Symptom zur Ursache: Diagnosetabelle
| Symptom | Wahrscheinliche Ursache | Erste Prüfung |
|---|---|---|
| Alle Masken den ganzen Tag langsam | Speicher, Datenträger oder Editionsgrenzen | max server memory, Wartetypen, SQL-Server-Edition |
| Zu bestimmten Zeiten frieren alle ein | Sperren, Sicherung oder Wartungsauftrag | blocking_session_id, Zeitpläne geplanter Aufträge |
| Ein Bericht ist sehr langsam | Veraltete Statistiken, großer Datumsbereich | Berichtsfilter, Aktualität der Statistiken |
| Langsam nach einem Massenimport | Statistiken veraltet | Statistikaktualisierung, Messung vorher und nachher |
| Nur die Filiale ist langsam | Netzwerk oder Terminalserver | Netzwerklatenz, Sitzungsressourcen |
| Der Protokolldatenträger läuft voll | Keine Protokollsicherung, kleine Wachstumsschritte | Wiederherstellungsmodell, Sicherungsplan |
5 gut gemeinte Eingriffe, die es schlimmer machen
- Die Datenbank regelmäßig verkleinern (Shrink): Die Datei wächst wieder und die Fragmentierung steigt.
- Jede Nacht alle Indizes neu aufbauen: Das dauert lange, vergrößert das Protokoll und die Wirkung wird nie gemessen.
- Ungetestet Indizes in Logo-Tabellen anlegen oder Daten direkt per SQL ändern: Das kann Probleme bei Produktupdates und Geschäftsregeln verursachen.
- Nur Hardware nachrüsten: Sind Sperren oder veraltete Statistiken die Ursache, bleibt auch ein neuer Server langsam.
- Mehrere Einstellungen gleichzeitig ändern: Sie wissen danach nicht, was gewirkt hat.
Wann sollten Sie Hilfe holen?
Fachliche Unterstützung spart Zeit, wenn sich die Sperrkette täglich wiederholt, wenn die Wartetypen Datenträger und Speicher nicht klar trennen oder wenn ein Editionswechsel oder Serverumzug ansteht. Für Logo-Parameter, Benutzer und Modulstruktur arbeiten Sie mit unserem Team der ERP-Beratung. Für SQL-Server-Einstellungen, Wartungspläne und Überwachung ist unsere SQL-Beratung da. Wenn Sie noch ein Produkt auswählen, hilft Ihnen unser Vergleich Logo Edge T-Series oder N-Series.
Fazit
Wird Logo langsam, trennen Sie zuerst: wo, wer und wann. Liegt die Ursache in der Datenbank, beginnen Sie mit den Editionsgrenzen und machen mit Speicher, Datenträger-Wartezeiten, Sperren, Statistiken, Indizes, tempdb und Dateieinstellungen weiter. Messen Sie bei jedem Schritt zuerst, ändern Sie eine Sache und messen Sie erneut. ÇAP Teknoloji prüft die SQL-Server-Seite Ihrer Logo-Installation gern gemeinsam mit Ihnen; schreiben Sie uns über die Kontaktseite.
Häufig gestellte Fragen
Was prüfe ich zuerst, wenn Logo langsam ist?
Klären Sie zuerst, ob eine Maske, alle Benutzer oder bestimmte Tageszeiten betroffen sind. Sind alle gleichzeitig betroffen, prüfen Sie Sperren und Wartetypen im SQL Server. Ist nur ein PC betroffen, sind Client und Netzwerk die ersten Verdächtigen.
Kann SQL Server Express Logo langsam machen?
Ja, das ist möglich. Laut Microsoft darf eine Datenbank in SQL Server 2022 Express höchstens 10 GB groß sein, und der Pufferpool nutzt höchstens 1.410 MB Arbeitsspeicher. Mit wachsenden Daten und Benutzerzahlen können diese Grenzen bremsen. Prüfen Sie Ihre Edition.
Sollte ich jede Nacht alle Indizes neu aufbauen?
Meist nicht. Microsoft empfiehlt, Wartung nach gemessener Wirkung und nicht nach einem festen Fragmentierungsschwellenwert zu entscheiden. Die Verbesserung kommt oft von der Statistikaktualisierung, und die kostet deutlich weniger Ressourcen.
Löst ein stärkerer Server das Problem?
Er hilft, wenn Speicher oder Datenträger wirklich der Engpass sind. Sind Sperren, veraltete Statistiken oder eine falsche Speichereinstellung die Ursache, hat auch der neue Server dasselbe Problem. Messen Sie die Wartetypen, bevor Sie entscheiden.
Darf ich selbst Indizes in Logo-Tabellen anlegen?
Wir raten davon ab. Änderungen an Logo-Tabellen können Produktupdates und Geschäftsregeln beeinflussen. Scheint ein Index nötig, entscheiden Sie das gemeinsam mit Ihrem Partner und testen Sie ihn zuerst in einer Testumgebung.
