Sage 100 langsam? Erst messen, dann gezielt optimieren.
Wir analysieren die komplette Strecke vom Arbeitsplatz bis zur Datenbank – und finden den tatsächlichen Engpass.
Ein schnellerer Server ist nur dann die richtige Antwort, wenn die Messwerte genau dorthin zeigen. Appontes verbindet Sage-Prozesswissen mit SQL-Server-, Entwicklungs- und Infrastrukturkompetenz.
„Die Sage ist langsam“ ist noch keine Diagnose
Dasselbe Gefühl kann aus vollkommen unterschiedlichen Engpässen entstehen. Entscheidend sind Funktion, Zeitpunkt, betroffene Benutzer und die Änderung, seit der das Problem auftritt.
ServiceDomains, gleichzeitige Starts, Terminalserver oder Hintergrundjobs können Lastspitzen erzeugen.
Netzwerklatenz, Blocking, Log-I/O oder eine individuelle Erweiterung kommen infrage.
Ein neuer Ausführungsplan, wachsende Datenmengen oder veränderte Statistiken können die Laufzeit verschieben.
Client, Benutzerprofil, Drucker, Terminalserver oder die konkrete Netzwerkstrecke werden relevant.
Parallelität, Pools, Sperren und Ressourcengrenzen zeigen sich oft erst unter realer Last.
Das beseitigt ein Symptom, erklärt aber weder Speicher-, Plan- noch Prozessursache.
Sage-100-Performance ist eine Kette
Ein Klick durchläuft mehrere Komponenten. Ein einzelner Engpass reicht, damit sich das gesamte ERP langsam anfühlt.
Zusätzlich wirken Virtualisierung, Virenscanner, Backups, Reporting, Schnittstellen und Zusatzlösungen auf dieselbe Umgebung ein.
Erst messen. Dann verstehen. Dann optimieren.
Unser Sage-100-Performance-Test prüft nicht nur synthetische Serverwerte. Er misst die tatsächliche Strecke und Sage-typische Datenzugriffe.
Ist die Abfrage lokal schnell und am Client langsam, liegt der primäre Engpass sehr wahrscheinlich außerhalb der Datenbank.
Für ERP zählt Latenz – nicht nur Bandbreite
Viele Sage-Funktionen bestehen aus zahlreichen aufeinanderfolgenden Datenbank- und Serviceaufrufen. Wenige zusätzliche Millisekunden können sich dabei zu spürbarer Wartezeit addieren.
SQL-Kommunikation ist aussagekräftiger als ein reiner Dateikopiertest.
Server, Terminalserver und Arbeitsplatz mit identischer Messung gegenüberstellen.
Jitter, WLAN, Routing und Paketverlust können wichtiger sein als die nominelle Leitung.
Nicht raten, worauf der SQL Server wartet
Wait Statistics zeigen, wo SQL-Prozesse Zeit verlieren. Ein Wait Type ist noch keine Diagnose – erst Kontext, Verhältnis und tatsächliche Sage-Arbeitslast machen ihn aussagekräftig.
PAGEIOLATCHDatenseiten ladenStorage, physische Reads, Speicher oder ineffiziente Abfragen prüfen.
WRITELOGTransaktionslogRelevant bei Buchungen, Belegen und vielen Schreiboperationen.
LCK_*SperrenProzesse warten auf Transaktionen anderer Sessions.
ASYNC_NETWORK_IODatenabnahmeClient, Anwendung oder Netzwerk können die Gegenseite bremsen.
Hohe Auslastung sagt noch nicht, welche Maßnahme hilft
CPU, RAM und Storage sind wichtig. Aber erst ihre Ursache entscheidet, ob Hardware, Konfiguration oder Abfrageoptimierung der richtige Hebel ist.
Eine ungeeignete Abfrage kann unnötig viele Reads, Joins oder Sortierungen erzeugen.
- teure Abfragen identifizieren
- Ausführungspläne prüfen
- Datenmengen und Parallelität bewerten
SQL Server nutzt RAM als Cache. Relevant sind echter Speicherdruck und die Reserve für andere Dienste.
max server memory- Buffer Pool & Memory Grants
- Betriebssystem und Applikationsserver
Wir messen die vom SQL Server beobachtete Lese- und Schreiblatenz.
- Datendateien
- Transaktionslog
- TempDB und Backups
Langsame Abfrage oder langsamer Server?
Eine einzelne Abfrage kann 30 Sekunden brauchen, obwohl CPU, RAM, Netzwerk und Storage gesund sind. Dann analysieren wir, wie der SQL Server tatsächlich zum Ergebnis gelangt.
Index Seek oder Scan, Join-Strategie, Sortierungen und Abweichungen der Zeilenschätzung.
Historische Laufzeiten und Planwechsel machen sporadische Verschlechterungen sichtbar.
Ein Plan kann für einen Parameter gut und für eine andere Datenverteilung ungeeignet sein.
Bei Standardsoftware optimieren wir kontrolliert: über passende Indizes, Statistiken oder – abhängig von Version und Situation – Query Store, Plan Forcing, Hints und Plan Guides.
Blocking und Deadlock sind nicht dasselbe
Eine technisch schnelle Abfrage kann lange benötigen, wenn sie auf eine andere Transaktion wartet. Entscheidend ist, wer wen blockiert und in welcher Reihenfolge Sperren entstehen.
Blocking
Benutzer B wartet, bis Benutzer A seine Sperre freigibt.
Deadlock
Zwei Vorgänge warten zyklisch aufeinander. SQL Server beendet eine Transaktion.
Applikationsserver, Terminalserver und Erweiterungen gehören dazu
Eine über Jahre erweiterte Sage-Installation ist ein Gesamtsystem. Deshalb betrachten wir Standard, Infrastruktur und Individualentwicklung gemeinsam.
Benutzerzahl, ServiceDomains, Poolgrößen, Lebensdauer, parallele Requests und Lastverteilung.
- Anmeldephasen
- BlobStorage
- Druck- und Berichtsprozesse
CPU, RAM, Profile, Drucker, Office, Virenscanner und die Strecke zum Sage-Server.
Host-Auslastung, CPU-Overcommitment, SAN/iSCSI, Snapshots und konkurrierende VMs.
AppDesigner, eigene Masken, Abfragen, Trigger, Tabellen und Zusatzlösungen getrennt vom Standard analysieren.
Schnittstellen, Importe, SQL-Agent-Jobs, Backups, Wartung und BI-Refresh zeitlich korrelieren.
Echtzeitscans und Ausnahmen für Datenbank-, Log-, TempDB-, Blob- und Backupbereiche im Sicherheitskonzept prüfen.
So wird sichtbar, warum dasselbe System um 10 Uhr langsam und um 11 Uhr schnell sein kann. Auch Power BI, andere Schnittstellen und die Konfiguration des Sage-100-Applikationsservers werden passend zur produktiven Last geplant.
Baseline und Monitoring ersetzen Erinnerungen
Wenn das Problem nur montags, beim Monatsabschluss oder nach einigen Betriebstagen auftritt, reicht eine Momentaufnahme nicht. Historische Daten verbinden Laufzeit, I/O, Blocking, Jobs und Planwechsel.
Vorher und nachher mit demselben Maßstab
Beispielwerte zur Darstellung der Methodik – keine Ergebnisgarantie.
Eine Baseline ist besonders wertvoll vor und nach Sage-Update, Servermigration, SQL-Upgrade oder Einführung einer Zusatzlösung.
Vier Dinge, die wir nicht als ersten Schritt tun
Kann Symptome beseitigen, liefert aber keine belastbare Ursache.
Pauschales Löschen ist keine nachhaltige Strategie für einen einzelnen schlechten Plan.
Missing-Index-Hinweise berücksichtigen weder gesamte Schreiblast noch alle vorhandenen Indizes.
Millionen unnötige Reads bleiben auch auf einer schnelleren CPU unnötig.
Von der Problembeschreibung zur nachgewiesenen Verbesserung
Funktion, Benutzer, Zeitpunkt, Häufigkeit und letzte Änderungen konkretisieren.
Client, Netzwerk, Sage-Dienste und SQL Server unter realistischen Bedingungen erfassen.
Waits, CPU, RAM, I/O, Blocking, Query Store, Pläne, Indizes und Statistiken prüfen.
Server, Virtualisierung, Storage, Netzwerk, Terminalserver und Betriebssystem bewerten.
Applikationsserver, ServiceDomains, BlobStorage, Druck und Zusatzlösungen einbeziehen.
Eigene Abfragen, Schnittstellen, Trigger, Jobs und Masken vom Standard trennen.
Kritische Ursache, relevante Verbesserung und kosmetische Auffälligkeit unterscheiden.
Mit dem größten erwarteten Effekt bei kontrollierbarem Risiko beginnen.
Nur der identische Vorher-Nachher-Vergleich belegt den Erfolg.
Keine 40 Seiten Fachbegriffe ohne Prioritäten
Sie erhalten Ursachen, Auswirkungen und konkrete Empfehlungen – so aufbereitet, dass IT, Sage-Partner und Geschäftsleitung damit weiterarbeiten können.
Vom Gesundheitscheck bis zum SQL Deep Dive
Strukturierte Erstaufnahme von Netzwerk, SQL Server und Sage-typischen Zugriffen.
- generell langsame Sage
- Beschwerden mehrerer Benutzer
- Check vor Infrastrukturänderung
Wenn Messwerte auf den SQL Server oder einzelne Abfragen zeigen.
- Execution Plans & Query Store
- Blocking & Deadlocks
- I/O, CPU, Speicher und Wartung
Alte und neue Umgebung mit identischer Methodik objektiv gegenüberstellen.
- Serverumzug
- SQL-Upgrade
- Sage-Update oder neue Zusatzlösung
Sage-Prozess und technische Plattform zusammen denken
Wir kennen die Anwendung hinter den Abfragen und können Standard und individuelle Funktion einordnen.
Waits, Pläne, Query Store, Sperren, Speicher und I/O werden im Zusammenhang bewertet.
Eigene Abfragen, Schnittstellen, Dienste und Erweiterungen enden für uns nicht an einer Systemgrenze.
Unser Test nutzt typische Zugriffe auf Sage-Strukturen statt nur allgemeiner Serverbenchmarks.
Maßnahmen an Standardsoftware müssen dokumentiert, testbar und auch nach Updates nachvollziehbar sein.
Auch bei bestehendem Sage-Partner oder externer Infrastruktur-IT schaffen Messwerte eine gemeinsame Grundlage.
Wir finden heraus, wo die Zeit tatsächlich verloren geht.
Keine Vermutung und kein Hardwarekauf auf Verdacht: Wir messen die reale Umgebung, priorisieren die Ursachen und belegen die Wirkung jeder Optimierung.