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 Applikationsserver? 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 den Appontes Performance Check für Sage 100 entwickelt. Das Programm durchleuchtet in wenigen Minuten die komplette Kette vom Arbeitsplatz über den Applikationsserver bis zum SQL Server: Netzwerk, Verbindungsaufbau, echte Sage-Abfragen, Server-Gesundheit, Konfiguration, Wartung und Sicherheit. Am Ende steht ein Bericht mit klaren Bewertungen, einer Diagnose, wo die Ursache liegt, und einem Maßnahmenplan. In diesem Beitrag zeigen wir Dir, wie der Check funktioniert und was die einzelnen Indikatoren bedeuten.

So funktioniert der Test

Den Performance Check kannst Du kostenlos herunterladen. Nach einem kurzen Setup ist er sofort einsatzfähig. Er läuft auf einem beliebigen Windows-Rechner mit Zugriff auf den SQL Server. Idealerweise startest Du ihn genau dort, wo die Anwender arbeiten, denn dann misst er exakt die Strecke, die auch die Sage 100 nimmt. Er braucht nur vier Angaben: Server, Datenbank, Anmeldung und die Sage-Mandantennummer.

Drei Dinge sind uns dabei wichtig:

• Er misst unter realen Bedingungen. Der Check 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.
• Er 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 fasst ein formatierter HTML-Bericht alle Messwerte, die Auffälligkeiten und ein Fazit zusammen.

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. Der Check 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: Der Check 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 der Check entweder einen Begriff, mit dem Deine Anwender tatsächlich suchen, oder er 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.

Lasttest und Storage-Test

Zwei optionale Tests gehen noch einen Schritt weiter. Der Mehrbenutzer-Lasttest führt die Artikelsuche mit mehreren parallelen Verbindungen aus und vergleicht das Ergebnis mit dem Einzelbenutzer. So siehst Du, ob der Server unter gleichzeitigen Zugriffen sauber skaliert oder ab einer bestimmten Zahl von Anwendern einbricht. Der Storage-Test misst den Datenträger direkt, ungepuffert mit großen sequenziellen und kleinen zufälligen Zugriffen. Auf dem SQL Server ausgeführt, prüft er das Datenlaufwerk. Damit lässt sich ein langsames Storage belegen, statt es nur zu vermuten.

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 der Check 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.

Der Check 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.

Neu ist der Reiter Größte Objekte. Er listet die größten Tabellen der Datenbank mit Zeilenzahl, Daten-, Index- und LOB-Anteil auf und gibt Empfehlungen zu Partitionierung und Komprimierung. So siehst Du auf einen Blick, wo der Platz steckt und ob eigene Tabellen oder Protokolle die Datenbank aufblähen.

Konfiguration, Wartung und Sicherheit

Zum Abschluss prüft der Check zahlreiche Einstellungen gegen bewährte Praxiswerte, ergänzt um die Best Practices aus der Microsoft Tiger Toolbox. 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.

Der Sage 100 Applikationsserver

Seit die Sage 100 viele Funktionen über den Applikationsserver abwickelt, gehört er fest in jede Performance-Analyse. Auch seine Konfiguration lässt sich auf die eigene Umgebung abstimmen. Der Check liest dafür rein lesend auf dem Rechner des Applikationsservers aus, was dort läuft und wie es eingestellt ist:

• Dienste: Laufen alle Kerndienste und die Dienste des Umfelds, und unter welchem Konto?
• Konfiguration: Begrenzung asynchroner Anfragen, Speichergrenzen der Isolationsräume, Autorisierungsrichtlinie, Rolle im Mehr-Server-Betrieb und der HealthCheck-Endpunkt.
• Speicher und Leistungsindikatoren: Reicht der Arbeitsspeicher für die erwartete Zahl gleichzeitiger Benutzer, und wie verhalten sich die Leistungsindikatoren, als Momentaufnahme oder über einen wählbaren Zeitraum gemittelt?
• Antwortzeiten: Mit einem Sage-Benutzer misst der Check zusätzlich die Antwortzeiten typischer Standardabrufe, etwa die Anmeldung mit dem Laden der Metadaten, die den Programmstart bestimmt. Auch hier werden nur lesende Abrufe ausgeführt.

Dazu kommt der Arbeitsplatz selbst: Windows-Version, Prozessor, Arbeitsspeicher, Energieplan, Netzwerkadapter und Virenscanner des Rechners, auf dem der Test läuft. Denn oft liegt die Bremse gar nicht am Server.

Die Diagnose: Wo liegt die Ursache?

Am Ende verdichtet der Check 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. Zeigt der Applikationsserver Auffälligkeiten, landet er im Fazit ganz oben. Sind alle Seiten unauffällig und die Sage 100 trotzdem langsam, suchen wir beim Client weiter, etwa beim Virenscanner oder bei AppDesigner-Anpassungen.

In der Vollversion bleibt es nicht bei der Diagnose. Der Maßnahmenplan ordnet die Befunde nach Dringlichkeit und liefert die passenden SQL-Befehle als Skript für das SQL Server Management Studio. Läuft der Check erneut, vergleicht er automatisch mit dem letzten Lauf. So siehst Du sofort, ob eine Maßnahme gewirkt hat.

Sicherung und Wartung gleich mit einrichten

Fehlende oder falsch eingerichtete Sicherungen und Indexwartung gehören zu den häufigsten Ursachen für Leistungsprobleme, und sie sind ein echtes Risiko. Deshalb richtet die Vollversion auf Wunsch Sicherungs- und Wartungsjobs nach bewährten Standards ein: Vollsicherung, Differenz- und Protokollsicherung, Indexwartung, Statistiken und Integritätsprüfung. Basis ist die bewährte MaintenanceSolution von Ola Hallengren. Vor dem Einrichten siehst Du das vollständige Skript, angelegt wird erst nach Deiner Bestätigung. Auch SQL Server Express wird unterstützt, dort laufen die Jobs über die Windows-Aufgabenplanung.

Start per Oberfläche, Kommandozeile oder Aufgabenplanung

Die grafische Oberfläche

Im Normalfall startest Du einfach SagePerformance.exe. Verbindungsdaten eintragen, Mandant angeben, auf „Test starten" klicken, fertig. Die Ausgabe läuft live und farbig mit: OK in Grün, WARNUNG in Gelb, KRITISCH in Rot. Die Oberfläche bleibt dabei jederzeit bedienbar und der Lauf lässt sich abbrechen. Optionen wie der Stabilitätstest, der Lasttest oder der Storage-Test lassen sich per Häkchen zuschalten. Am Ende speicherst Du den HTML-Bericht mit einem Klick oder öffnest ihn direkt im Browser.

Start über die Kommandozeile

Wer es direkt mag, startet den Check im Konsolenmodus. Ein typischer Aufruf mit SQL-Anmeldung sieht so aus:

SagePerformance.exe -NoGui -Uebermittlung -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. Der Schalter -Uebermittlung bestätigt die Nutzungsvereinbarung, ohne ihn startet der Test nicht. Den Text zeigt -Datenschutz an. 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, -LoadUsers 10 den Mehrbenutzer-Lasttest und -StorageTest die direkte Messung des Datenträgers.
• -SqlPlan speichert den Maßnahmenplan als T-SQL-Skript (Vollversion).
• -NoAudit lässt die Prüfungen zu Konfiguration, Wartung und Sicherheit weg, wenn es nur um die reine Performance geht.
• -Handbuch öffnet die ausführliche Hilfe mit allen Parametern und Prüfungen im Browser.

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 den Check zum Beispiel jeden Werktag startet. Weil der Test zusätzliche Last erzeugt, wählst Du dafür am besten eine Zeit, in der wenig los ist.

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

-NoProfile -Command "& 'C:\Tools\SagePerformance\SagePerformance.exe' -NoGui -Uebermittlung -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. Drei Hinweise dazu: Lass die Aufgabe unter einem Dienstkonto mit Windows-Anmeldung laufen, dann steht nirgendwo ein Passwort im Klartext. Aktiviere in der Aufgabe „Unabhängig von der Benutzeranmeldung ausführen", damit die Messung auch ohne angemeldeten Benutzer läuft. Und weil die Lizenz pro Rechner für den angemeldeten Benutzer aktiviert wird, aktivierst Du sie auch für das Dienstkonto, zum Beispiel mit SagePerformance.exe -Lizenz <Schlüssel>.

Datenschutz und Bericht teilen

Die Auswertung läuft komplett auf Deinem Rechner. Der Check übermittelt von sich aus keine Auswertung an uns. Möchtest Du Unterstützung, schickst Du uns den Bericht mit „Bericht mit Appontes teilen“ direkt aus dem Programm, zusammen mit Deinen Kontaktdaten und einer kurzen Beschreibung. Übermittelt wird nur nach Deiner ausdrücklichen Bestätigung und nur dieser eine Bericht, verschlüsselt und gespeichert ausschließlich in Deutschland. Wir sehen uns die Ergebnisse an und melden uns bei Dir.

Kostenlos starten: Basis und Vollversion

Mit der kostenlosen Basis-Lizenz führt der Performance Check alle Prüfungen aus, auch die des Applikationsservers, und zeigt Dir, wie viele Punkte in Ordnung, auffällig oder kritisch sind, samt Fazit. Den vollständigen Bericht teilst Du mit einem Klick mit uns, wir werten ihn aus und besprechen die Ergebnisse mit Dir. Die Lizenz forderst Du direkt im Programm an, Firma und E-Mail-Adresse genügen. Eine Newsletter-Anmeldung ist dafür nicht nötig.

Die Vollversion zeigt Dir den kompletten Bericht und das Detailprotokoll im Programm, liefert den Maßnahmenplan als fertiges SQL-Skript, vergleicht mit dem letzten Lauf und richtet Sicherung und Wartung ein. Alle Details findest Du auf der Produktseite und auf der eigenen Projektseite erp-performance.de.

Wofür wir den Check 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. Führe den Check selbst aus und teile den Bericht mit uns, oder wir messen gemeinsam mit Dir. Wir besprechen die Ergebnisse 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.

Sage und Sage 100 sind Marken der Sage GmbH bzw. der The Sage Group plc. Der Appontes Performance Check für Sage 100 ist ein Programm der Appontes GmbH und kein Produkt der Sage GmbH. Microsoft, Windows und SQL Server sind Marken der Microsoft Corporation.