Das Herzstück von Microsoft Dynamics 365 Business Central bildet der Datenbankserver auf Basis vom Microsoft SQL Server. Egal ob Ausfallsicherheit, Performance oder Wiederherstellungsszenarien, der Datenbankserverdienst benötigt Aufmerksamkeit und Überwachung, um stets sicher und performant zu laufen. Folgende Inhalte und Themen sind dabei zu berücksichtigen:
- Laufender Betrieb
- Administration
- Zyklische Wartung
- Kontinuierliche Optimierung
Sicherung und Wiederherstellung
Wir starten unsere Serie mit der Sicherung und Wiederherstellung der Datenbanken. Dieser Punkt ist von größter Bedeutung für den sicheren Betrieb Ihres ERP-Systems. Haben Sie sich schon einmal ernsthaft Gedanken darüber gemacht, ob Ihre Datensicherungen auch tatsächlich funktionieren? Oftmals werden die Wartungspläne einmalig eingerichtet, geraten dann jedoch genauso schnell wieder in Vergessenheit.
So können vermutlich die wenigsten IT-Verantwortlichen die Frage mit “ja” beantworten, ob sich die regelmäßigen Sicherungen auch sauber wiederherstellen lassen. Zu einer ordentlichen Sicherungs-Strategie gehört auch immer ein gelegentlicher Blick auf die Wiederherstellung.
"Kein Backup, kein Mitleid"
Mit diesem Zitat steigen wir in eine wichtige Säule des SQL-Server-Betriebs ein: Die Ausfallsicherheit. Datensicherungen (Backups) ermöglichen im Fall der Fälle, das System und Datenbanken wiederherzustellen.
Dabei sollte man bedenken, welche Auswirkungen ein Server- und/oder Datenausfall haben kann. Wie lange kann man auf ein System verzichten und welche Zeitspanne an Datenverlust ist noch akzeptabel und nicht kritisch für das Überleben des eigenen Unternehmens?
Nachfolgende Fragen helfen dabei, ein gutes und passendes Backup-Konzept festzulegen:
- Was wird gesichert?
- Wie oft wird gesichert?
- Welche Tools werden verwendet?
- Wo werden die Backups gespeichert?
Eine wichtige Entscheidung und Einstellung des SQL-Servers ist die Wiederherstellungsmethode:
- Einfach: damit kann eine Wiederherstellung nur auf Basis des letzten Backups gemacht werden. Ein Backup in der Nacht und ein Serverausfall am Ende des Arbeitstages hätte den Datenverlust der Änderungen des gesamten Arbeitstages zur Folge.
- Vollständig: alle Änderungen seit dem letzten Backup werden in einem Transaktionsprotokoll mitgeschrieben und eine Datenwiederherstellung ist zu beliebigen Zeitpunkten möglich.
- Bulk-Logged: Dieses Wiederherstellungsmodell ist für den zeitweiligen Einsatz konzipiert, um die Leistung von Massenimporten großer Datenmengen zu verbessern. Es ist praktisch dasselbe wie das vollständige Wiederherstellungsmodell, mit der einzigen Ausnahme, dass beim Bulk-Logged-Wiederherstellungsmodell einige Vorgänge nur minimal protokolliert werden.
Ein kurzer, vereinfachter Exkurs in die NAV-Datenbank
Eine Dynamics NAV / Business Central-Datenbank besteht aus (mindestens) zwei Datenbank-Dateien – der eigentlichen Daten-Datei (ndf) und dem Transaktions-Protokoll (ldf). In einer produktiven Datenbank müssen wir, aus Backup-Sicht, beide Typen getrennt betrachten. Während die “Daten-Datei” tatsächlich unsere Daten beherbergt, hat das Transaktions-Protokoll eine etwas andere Aufgabe.
Was verbirgt sich nun also hinter diesem “Transaction Log”? Reicht nicht nur eine Datei, in der alles gespeichert wird? Nein, denn der SQL macht sich eine relativ einfache Idee zu Nutze: Das “Write-Ahead” Prinzip. Jede Transaktion wird zunächst in das sequenzielle, und dadurch schnelle Transaction-Log geschrieben.
Erst wenn das letzte Bit und Byte fehlerfrei darin gelandet ist (Commit), wird der Inhalt auch in die eigentliche Daten-Datei übertragen. Sollte nun aber an einer beliebigen Stelle ein ebenso beliebiger Fehler auftreten – z.B. bei der Buchung eines Auftrages – wird die Transaktion erst gar nicht in der Daten-Datei persistiert, sondern sauber zurückgerollt. Dieses Prinzip sorgt also maßgeblich für die Konsistenz der gesamten ERP-Datenbank.
Was wird gesichert?
Die gesamte Datenbank sollte regelmäßig vollgesichert und/oder differentiell gesichert werden. (z.B. täglich) In Kombination mit den zusätzlichen Transaktionsprotokoll-Sicherungen (z.B. stündlich) können wir die Datenbank im Fehlerfall sehr engmaschig wiederherstellen.
Das Transaktionsprotokoll (Log) wird dabei erst nach einer Log-Sicherung geleert und die Abstände zwischen den Log-Sicherungen bestimmen letztlich die maximale Zeit eines möglichen Datenverlustes.
Ist kein Job zur Sicherung des Transaktionsprotokolls konfiguriert oder läuft dieser auf Fehler, kommt es zu einem stetigen und ungebremsten Wachstum des Transaktionsprotokolls. Dies kann sogar die Nutzbarkeit der Datenbank und der kompletten Applikation blockieren.
Der erfolgreiche Abschluss von Sicherungsaufträgen sollte immer überwacht und geprüft werden und Fehlerursachen unmittelbar beseitigt werden. Ergänzend sollte man sich nicht nur auf die ERP-Datenbank konzentrieren, sondern bestenfalls auch die sogenannten “Systemdatenbanken” berücksichtigen.
Wie oft wird gesichert?
Die Antwort ergibt sich damit aus dem Wunsch und der Vorgabe wieviel Datenverlust maximal akzeptabel ist. Zudem kommt es auf die Größe der Datenbank und auch das tägliche Datenvolumen an, welche Sicherungsstrategie die passende ist. Häufig bilden die Grundlage tägliche Voll-Backups und je nach Anforderung weitere Log-Backups in kürzeren Abständen.
Es gibt viele Hersteller von Backup-Software und meistens wird der SQL-Server ins globale Sicherungskonzept mit eingebunden. Aber auch mit MSSQL-Bordmitteln kann man sich ein robustes Backup-Konzept aufbauen.
Wo werden die Backups gespeichert?
Die Antwort darauf ergibt sich aus dem Ziel. Die primäre Sicherung auf ein Netzlaufwerk und anschließende Sicherung des Laufwerks auf externe Medien hilft, um im Notfall über schnelle Festplatten ein Restore durchzuführen. Externe Medien dienen der physikalischen und ggf. räumlichen Trennung in Bezug auf den Speicherort der gesicherten Datenbank(en).
Neben Netzwerkfreigaben gibt es auch externe Speichermedien wie Bandlaufwerke, Cloud-Storage, usw. und es empfiehlt sich eine Kombination / Staffelung von Technologien und Geräten.
Kann ich meine Daten auch in der Praxis wiederherstellen?
Hat man aber nun ein wunderbar ausgeklügeltes Backupkonzept stehen, so ist dies nichts wert, wenn man es nicht auch auf die Probe stellt. Turnusmäßige Wiederherstellungen sollten also fest eingeplant werden.
Zum Abschluss der Hinweis auf den nächsten Blog-Beitrag: “SQL: Der laufende Betrieb”. Da gehen wir auf wichtige Tipps und Hinweise ein, was man im laufenden Betrieb beim SQL-Server unbedingt überwachen sollte.
Durch ein Blog-Abo werden Sie automatisch per E-Mail mit den Beiträgen versorgt - einfach registrieren.
.png)
