Sage 100 langsam? So messen wir, woran es wirklich liegt

„Die Sage 100 ist langsam." Diesen Satz hören wir oft. Und er ist völlig berechtigt, nur leider auch völlig unpräzise. Liegt es am Netzwerk? Am SQL Server? Am Client? An fehlender Wartung? Jeder im Unternehmen hat eine Vermutung, und meistens wird dann erstmal neue Hardware gekauft. Manchmal hilft das sogar. Oft aber nicht, weil das eigentliche Problem woanders lag.

Deshalb raten wir nicht, sondern messen. Dafür haben wir ein PowerShell-Script entwickelt, das in wenigen Minuten die komplette Kette vom Client bis zum SQL Server durchleuchtet: Netzwerk, Verbindungsaufbau, echte Sage-Abfragen, Server-Gesundheit, Konfiguration, Wartung und Sicherheit. Am Ende steht ein Bericht mit klaren Bewertungen und einer Diagnose, wo die Ursache liegt. In diesem Beitrag zeigen wir Dir, wie das Script funktioniert und was die einzelnen Indikatoren bedeuten.

So funktioniert der Test

Das Script Test-SagePerformance.ps1 läuft auf einem beliebigen Windows-Rechner mit Zugriff auf den SQL Server. Idealerweise startest Du es genau dort, wo die Anwender arbeiten, denn dann misst es exakt die Strecke, die auch die Sage 100 nimmt. Es braucht nur vier Angaben: Server, Datenbank, Anmeldung und die Sage-Mandantennummer.

Drei Dinge sind uns dabei wichtig:

• Es misst unter realen Bedingungen. Das Script simuliert die Artikelsuche, das Öffnen eines Artikels und den Listenaufbau direkt auf den echten Sage-Tabellen wie KHKArtikel, KHKAdressen und KHKVKBelege. Kundenindividuelle USER_-Felder werden dabei ignoriert, damit die Messung vergleichbar bleibt.
• Es verändert nichts an Deinen Daten. Alle Abfragen sind lesend. Nur der Schreib-Benchmark nutzt eine temporäre Tabelle in der TempDB, die danach wieder verschwindet.
• Jeder Messwert wird bewertet. Für jeden Indikator gibt es einen Referenzwert aus gesunden Systemen. Das Ergebnis ist immer OK, WARNUNG oder KRITISCH. So muss niemand interpretieren, ob 12 Millisekunden nun gut oder schlecht sind.

Jeder Abfrage-Test läuft in mehreren Runden, damit einzelne Ausreißer das Ergebnis nicht verfälschen. Am Ende schreibt das Script auf Wunsch einen formatierten HTML-Bericht mit allen Messwerten, den Auffälligkeiten und einem Fazit. Den bekommst Du von uns nach jeder Messung, verständlich aufbereitet und ohne Fachchinesisch.

Warum Latenz bei der Sage 100 alles ist

Bevor wir in die Indikatoren einsteigen, ein wichtiger Hintergrund: Die Sage 100 stellt pro Maske nicht eine große Abfrage an den SQL Server, sondern viele kleine, je nach Maske etwa 20 bis 70. Deshalb multipliziert sich jede Verzögerung im Netzwerk.

Genau deshalb ist die Roundtrip-Latenz für uns der wichtigste Einzelwert des ganzen Tests. Und genau deshalb bringt ein schnellerer Server nichts, wenn das Problem zwischen Client und Server liegt.

Die Netzwerk-Indikatoren

Dazu kommen einige Prüfungen, die klassische Stolperfallen aufdecken. Der MTU-Test erkennt, ob große Pakete fragmentiert werden. Das ist ein typisches VPN-Problem: Der Ping sieht gut aus, aber der Durchsatz ist miserabel. Das Script prüft außerdem, ob die Verbindung über TCP oder über die deutlich langsameren Named Pipes läuft, und ob die Windows-Anmeldung Kerberos nutzt oder in den NTLM-Fallback rutscht. Letzteres ist ein Hinweis auf einen fehlenden SPN und eine häufige Ursache für zähe Logins.

Optional gibt es noch einen Langzeit-Stabilitätstest. Der feuert über einen wählbaren Zeitraum durchgehend Abfragen ab und zählt Ausreißer über 50 Millisekunden. Damit fangen wir die Fälle, in denen der Durchschnitt gut aussieht, aber alle paar Sekunden ein Hänger auftritt. Dahinter stecken oft Virenscanner, Backups oder WLAN-Roaming.

Die Sage-Praxistests

Der spannendste Teil: Das Script macht genau das, was Deine Anwender den ganzen Tag tun, und stoppt die Zeit dabei.

Der Unterschied zwischen den beiden Suchvarianten ist diagnostisches Gold. Ist „beginnt mit" schnell und „enthält" langsam, arbeitet der Server grundsätzlich sauber und die Tabelle passt nur nicht komplett in den RAM oder das Storage bremst beim Lesen. Sind beide langsam, obwohl das Netzwerk gut aussieht, liegt ein grundsätzliches Serverproblem vor.

Dieselben Tests laufen anschließend auf den Adressen, den Verkaufs- und Einkaufsbelegen und der Buchungserfassung. Als Suchbegriff nimmt das Script entweder einen Begriff, mit dem der Kunde tatsächlich sucht, oder es ermittelt automatisch einen aus den echten Daten. Ein Schreib-Benchmark mit 1000 Einfüge-, Änderungs- und Löschvorgängen misst zusätzlich den Schreibpfad des Servers, wie er auch beim Buchen und Speichern gefordert ist.

Der Blick in den SQL Server

Bis hierhin haben wir gemessen, was der Anwender erlebt. Jetzt schauen wir hinein, warum. Der SQL Server protokolliert intern sehr genau, worauf er wartet, und genau diese Werte liest das Script aus.

Besonders aufschlussreich sind zwei weitere Auswertungen. Die Lock-Hotspots zeigen, an welchen Sage-Tabellen sich die Anwender gegenseitig blockieren, umgerechnet in Wartesekunden pro Tag. Und der Anteil von ASYNC_NETWORK_IO verrät, wie viel Zeit der Server damit verbringt, auf die Clients zu warten. Ein hoher Wert dreht die Verdachtsrichtung komplett um: Nicht der Server ist langsam, sondern die Gegenseite nimmt die Daten nicht schnell genug ab, etwa ein überlasteter Terminalserver.

Das Script schaut außerdem ins Errorlog des SQL Servers. Meldungen wie „I/O requests taking longer than 15 seconds" sind Selbstanzeigen des Servers, dass das Storage massive Aussetzer hatte. Solche Einträge nehmen wir sehr ernst.

Konfiguration, Wartung und Sicherheit

Zum Abschluss prüft das Script gut 30 Einstellungen gegen bewährte Praxiswerte. Ein paar Klassiker, die wir auf vielen Kundensystemen finden:

• AUTO_CLOSE aktiviert: Die Datenbank wird nach jeder Verbindung geschlossen und muss neu geöffnet werden. Der Klassiker hinter „die erste Abfrage morgens dauert ewig".
• max server memory unbegrenzt: Der SQL Server nimmt dem Betriebssystem und dem Applikationsserver den RAM weg, wenn beide auf derselben Maschine laufen.
• RAM kleiner als die Datenbank: Passt die Datenbank nicht in den Speicher, wird ständig von der Platte gelesen. Mehr RAM ist hier fast immer die wirksamste Einzelmaßnahme.
• Keine Wartung: Fragmentierte Indizes, uralte Statistiken, nie ein DBCC CHECKDB. Das System wird schleichend langsamer, und Korruption würde erst beim Restore auffallen.
• Backup-Lücken: Recovery Model FULL ohne Log-Sicherungen lässt das Transaktionslog wachsen, bis die Platte voll ist. Das ist dann kein Performance-Problem mehr, sondern ein Stillstand mit Ansage.

Der Sicherheits-Teil prüft unter anderem den Support-Status der SQL-Server-Version, aktive sa-Konten, triviale Passwörter und riskante Serveroptionen. Das hat mit Performance nichts zu tun, aber wenn wir schon einmal messen, sagen wir Dir auch, wenn dort etwas im Argen liegt.

Die Diagnose: Netzwerk oder Server?

Am Ende verdichtet das Script alle Messwerte zu einer klaren Aussage. Sind die Netzwerkwerte auffällig und die Serverwerte gut, liegt die Ursache auf der Strecke. Ist es umgekehrt, gehört die Aufmerksamkeit dem Server, also RAM, Storage und Wartung. Sind beide Seiten unauffällig und die Sage trotzdem langsam, suchen wir beim Client weiter, etwa beim Virenscanner oder bei AppDesigner-Anpassungen.

Start per GUI, Kommandozeile oder Aufgabenplanung

Die grafische Oberfläche

Für alle, die nicht auf der Konsole arbeiten wollen, gibt es eine kleine grafische Oberfläche. Verbindungsdaten eintragen, Mandant wählen, auf „Test starten" klicken, fertig. Die Ausgabe läuft live und farbig mit: OK in Grün, WARNUNG in Gelb, KRITISCH in Rot. Der eigentliche Test läuft dabei in einem eigenen Prozess, die Oberfläche bleibt also jederzeit bedienbar und der Lauf lässt sich abbrechen. Deine Eingaben (außer dem Passwort) merkt sich die GUI für den nächsten Start, und am Ende speicherst Du den fertigen HTML-Bericht mit einem Klick oder öffnest ihn direkt im Browser.

Start über die Kommandozeile

Wer es direkt mag, startet das Script in einer PowerShell. Ein typischer Aufruf mit SQL-Anmeldung sieht so aus:

.\Test-SagePerformance.ps1 -Server "SQLSRV01\SAGE" -Database OLReweAbfDE `
    -User sa -Password "geheim" -Mandant 123 `
    -HtmlReport C:\Temp\SagePerf.html

Mit Windows-Anmeldung entfallen Benutzer und Passwort, stattdessen kommt der Schalter -WindowsAuth dazu. Nützliche optionale Parameter: -SearchTerm übergibt einen Suchbegriff, mit dem Deine Anwender wirklich suchen, -Rounds erhöht die Zahl der Messrunden für glattere Werte, -StabilitySeconds 60 aktiviert den Langzeit-Stabilitätstest und -NoAudit lässt die Audit-Sektionen weg, wenn es nur um die reine Performance geht. Blockiert die Ausführungsrichtlinie den Start, hilft der Aufruf über powershell -ExecutionPolicy Bypass -File .\Test-SagePerformance.ps1 ...

Automatisch messen mit der Windows-Aufgabenplanung

Richtig wertvoll wird der Test, wenn er regelmäßig läuft. Eine einzelne Messung ist eine Momentaufnahme, eine Messreihe zeigt Trends: Wird die Artikelsuche seit Wochen schleichend langsamer? Bricht die Latenz immer dienstags ein, wenn das Backup läuft? Dafür richtest Du in der Windows-Aufgabenplanung eine Aufgabe ein, die das Script zum Beispiel jeden Werktag um 10 Uhr startet, also mitten in der echten Last.

Als Programm trägst Du powershell.exe ein, als Argumente:

-NoProfile -ExecutionPolicy Bypass -Command "& 'C:\Tools\SQLPerformance\Test-SagePerformance.ps1' -Server 'SQLSRV01\SAGE' -Database OLReweAbfDE -WindowsAuth -Mandant 123 -HtmlReport ('C:\SagePerf\Bericht_{0:yyyy-MM-dd_HHmm}.html' -f (Get-Date))"

Der Kniff steckt am Ende: Der Zeitstempel wird beim Start in den Dateinamen eingesetzt, jeder Lauf speichert seinen Bericht also automatisch unter einem eigenen Namen. So sammelt sich in C:\SagePerf eine lückenlose Historie, die Du jederzeit vergleichen kannst. Zwei Hinweise dazu: Lass die Aufgabe unter einem Dienstkonto mit Windows-Anmeldung laufen, dann steht nirgendwo ein Passwort im Klartext. Und aktiviere in der Aufgabe „Unabhängig von der Benutzeranmeldung ausführen", damit die Messung auch ohne angemeldeten Benutzer läuft.

Das Tool kostenlos herunterladen

Du willst selbst messen? Gern. Wir stellen den kompletten Performance-Test kostenlos zur Verfügung, also das PowerShell-Script, die grafische Oberfläche und einen Beispiel-Bericht. Im Gegenzug freuen wir uns über Deine Newsletter-Anmeldung: Dort teilen wir Praxiswissen rund um Sage 100, SQL Server und unsere Tools, und Du erfährst als Erstes, wenn es eine neue Version des Performance-Tests gibt. Dein Download-Link ist persönlich und bleibt gültig, bei Updates lädst Du einfach über denselben Link die aktuelle Version.

Wofür wir das Script einsetzen

• Erstdiagnose: Wenn ein Kunde über eine langsame Sage 100 klagt, ist der Test unser erster Schritt. Nach wenigen Minuten wissen wir, in welcher Ecke wir suchen müssen.
• Vorher-Nachher-Vergleich: Nach einer Optimierung messen wir erneut. So sieht jeder schwarz auf weiß, was die Maßnahme gebracht hat.
• Gesundheitscheck: Bei Neuinstallationen und Serverumzügen prüfen wir, ob die Umgebung sauber konfiguriert ist, bevor die Anwender darauf arbeiten.
• Objektive Grundlage: Wenn mehrere Dienstleister beteiligt sind, ersetzt der Bericht das gegenseitige Fingerzeigen durch Messwerte.

Deine Sage 100 ist langsam? Lass uns messen.

Wenn sich Deine Sage 100 zäh anfühlt, musst Du das nicht hinnehmen. Und Du musst auch nicht auf Verdacht in neue Hardware investieren. Wir führen den Performance-Test bei Dir aus, besprechen den Bericht gemeinsam und sagen Dir konkret, welche Maßnahmen sich lohnen und welche Du Dir sparen kannst. Oft stecken hinter einem quälend langsamen System nur zwei oder drei Einstellungen.

Auch bei allen anderen Datenbankthemen rund um die Sage 100 helfen wir Dir gern: Langsame Auswertungen, wachsende Transaktionslogs, Blockierungen, Wartungspläne oder ein Backupkonzept, das den Namen verdient. Melde Dich einfach, die Erstanalyse ist unkompliziert und schnell terminiert.