Im vorherigen Blogbeitrag zu diesem Thema haben wir uns das Thema „Sicherung und Wiederherstellung“ angesehen, um zu zeigen, wie wichtig es ist, regelmäßig die Sicherungen und vor allem deren Wiederherstellung zu prüfen. Denn nach dem Motto „Aus dem Auge, aus dem Sinn“ beschäftigen sich die Wenigsten nach einmaliger Einrichtung mit diesem Thema.
In diesem Beitrag beleuchten wir nun einige Punkte, die gerne vernachlässigt werden, aber maßgeblichen Einfluss auf die Performance und Stabilität des Systems haben können.
Dieser Beitrag beschäftigt sich also mit regelmäßigen Prüfungen und Möglichkeiten, die jeder Administrator in seine Wartungs-Routinen einbauen kann.
„Reboot macht alles gut“ ist eine oft zitierte Weisheit, die allerdings nicht für die SQL-Welt gilt, denn im laufenden Betrieb sammelt ein SQL-Server Informationen und Statistiken zu sämtlichen Abfragen und nutzt diese, um beim nächsten Auftreten möglichst schnell und effizient an die Daten heranzukommen.
Diese Statistiken und Informationen werden mit jedem Neustart des SQL-Dienstes gelöscht und erst nach und nach wieder neu aufgebaut. Dies ist auch der Grund, warum sich Ihre Microsoft Dynamics 365 Business Central Installation nach einem Neustart zunächst einmal sehr zäh anfühlen kann. Der Server muss sich erst wieder „aufwärmen“.
Das soll allerdings nicht bedeuten, dass man diese Maschinen niemals neustarten darf. Die Devise sollte eher sein:
“So oft wie nötig, so selten wie möglich!”
Ein klassischer Fall sind Server-Updates. Leider sehen wir es sehr oft, dass der Dynamics 365 Business Central bzw. SQL-Server wie ein rohes Ei behandelt wird und die Betriebssysteme aus den Update-Routinen genommen werden – und das trotz, oder vielleicht gerade wegen seiner zentralen Bedeutung für das Unternehmen.
Jedoch ist es selbstverständlich auch auf diesen Systemen wichtig, regelmäßig Updates zu installieren – sei es aus Sicherheits- oder Performance-Gründen.
Beim Update der Server sollte zunächst der Business Central Server gepatcht und heruntergefahren werden. Nach dem erfolgreichen Update und Neustart des SQL-Server kann letzterer wieder hochgefahren werden. Durch diesen Ablauf kann sichergestellt werden, dass die Datenbank bereits wieder erreichbar ist, wenn Business Central wieder startet.
Auf Ihren regelmäßigen Kontrollgängen lohnt auch immer wieder mal ein Blick auf die letzten Rollups des Microsoft SQL-Server. Die wenigsten Administratoren haben auf dem Schirm, dass die SQL-Instanzen manuell und nicht automatisch aktualisiert werden müssen. Diese SQL Rollups kommen also nicht über die klassischen Windows-Updates, sondern müssen heruntergeladen und kontrolliert installiert werden.
Daher kommt es leider auch regelmäßig vor, dass wir bei unseren Kunden die Grundversion der jeweiligen SQL-Version vorfinden. Gerade für die Versionen 2017 und 2019 gilt jedoch, dass diese Grundversionen zum Teil haarsträubende Performance-Probleme mit sich bringen. Eine gute Anlaufstelle für die letzten Rollups bietet diese Seite.
Hier gibt es wieder eine Faustregel: Bitte nicht das letzte verfügbare Rollup installieren, sondern besser auf das Vorletzte setzen! So hat es Microsoft leider schon geschafft, mit ungenügend getesteten Rollups für Probleme bis hin zu Datenverlust zu sorgen!
Ihre aktuell installierte Version können Sie über die Server-Eigenschaften via SQL Management Studio ermitteln:
Vor der Aktualisierung einer SQL-Instanz empfehlen wir, die Datenbank zu sichern oder einen Snapshot zu erstellen. Wir hatten selbst zwar noch keine Probleme damit, jedoch sollte bei solch umfangreichen Updates die Sicherheit vor gehen.
Man kann mit ein paar wenigen, regelmäßigen Handgriffen für ein stabileres ERP-System sorgen. Zunächst lohnt sich meist ein Blick auf die eigentlichen Datenbank-Dateien. Wie wir auch schon im letzten Blogbeitrag erfahren haben, besteht eine Business Central SQL-Datenbank aus zwei getrennten Dateien. Der „Daten-Datei“ (ndf) und der „Log-Datei“ (ldf).
In ersterer liegen die eigentlichen Informationen Ihres ERP, in letzterer werden alle Änderungen mitgeschrieben, bis eine Transaktion abgeschlossen ist. Somit kann die Konsistenz der Daten stets gewährleistet werden. Denn sollte in einer Transaktion ein Fehler auftreten, kann die Änderung mittels der Log-Datei bis auf das letzte Bit und Byte zurückgerollt werden.
Bei beiden Typen sollte man stets den „Füllstand“ beachten. Als Faustregel gilt, dass die Daten-Datei mindestens 20% freien Speicher bereitstellen sollte. Hintergrund ist, dass der SQL-Server andernfalls auf die automatische Vergrößerung der Daten-Dateien zurückgreift.
Letzteres führt auf lange Sicht zu einer Fragmentierung der Daten-Datei und kann deutlich negativen Einfluss auf die Performance haben. Daher macht es Sinn manuell, dafür jedoch in größeren Blöcken zu vergrößern.
Über die „Datei verkleinern“ Funktion im SQL Management Studio können Sie die Füllstände einsehen:
In diesem Beispiel hat unsere Daten-Datei keinen freien Platz mehr, weshalb der SQL-Server demnächst automatisch um 500MB vergrößern wird. Besser wäre es, z.B. direkt
von 60Gb auf 75Gb zu vergrößern, um die Fragmentierung in Zaum zu halten:
PS: Es gibt jedoch auch TSQL basierte Methoden zur Ermittlung der Füllstände:
Nach unserer manuellen Erweiterung bekommen wir somit prompt das Ergebnis angezeigt:
Für die Log-Datei gibt es in dem Sinne keine Faustregel, jedoch lohnt auch hier ein regelmäßiger Blick. Da die Log-Datei bei korrekt eingerichteten Backups und Sicherungen stets nur maximal die Transaktionen seit der letzten Sicherung enthalten sollte, muss im Normalfall der größte Teil der Datei als „frei“ markiert sein. Ist dies nicht der Fall, findet entweder gerade eine umfangreiche Transaktion statt, oder es stimmt etwas nicht mit den Sicherungen.
Zum Abschluss möchten wir noch auf den nächsten Blog-Beitrag der Serie verweisen: “SQL: Replikation & Ausfallsicherheit ”. Darin beleuchten wir Möglichkeiten, wie der SQL-Server z.B. mittels Replikation ausfallsicherer aufgebaut werden kann.
Durch ein Blog-Abo werden Sie automatisch per E-Mail mit den Beiträgen versorgt - einfach registrieren.