Empfehlungen zum Datensicherungsverfahren
Kunden, die das eTASK.FM-Portal auf einem eigenen Server installiert haben, haben bei der Protokollierung der Datenbank zwei Möglichkeiten:
Eine einfache Protokollierung
Eine vollständige Protokollierung
Informiere dich über die zwei möglichen Varianten und nutze die, die am besten zu deinem Unternehmen passt. Achte nur darauf, dass du bei einer vollständigen Protokollierung ein entsprechendes Datensicherungsverfahren konfigurierst, das es dir ermöglicht, das Protokoll regelmäßig abzuschneiden. Wenn du dies nicht tust, wird das Protokoll immer größer und kann so zu Performance-Problemen oder sogar dem Stillstand der Datenbank führen.
Bei vollständiger Protokollierung wirklich wichtig, Zitat von Microsoft (https://learn.microsoft.com/de-de/sql/relational-databases/backup-restore/back-up-a-transaction-log-sql-server ):
”Wenn eine Datenbank entweder das vollständige oder das Massenwiederherstellungsmodell verwendet, müssen Sie das Transaktionsprotokoll regelmäßig genug sichern, um Ihre Daten zu schützen und das Transaktionsprotokoll am Ausfüllen zu hindern. Dadurch wird das Protokoll gekürzt, und die Wiederherstellung der Datenbank zu einem bestimmten Zeitpunkt wird unterstützt.”
Tipp: Es kann (manchmal) nötig sein, mehrere Transaktionsprotokollsicherungen unmittelbar hintereinander (ggfs. in einer Schleife mit n, z.B. 10 Durchläufen) zu machen, um Speicherplatz in der Datei des Transaktionsprotokolls wieder freizugeben. Möchte man es sogar so durchführen, das immer sofort der Speicher wieder freigegeben wird, es das möglich mit diesem Befehl (ggfs. mit der “Backup-log-Schleife): https://learn.microsoft.com/de-de/sql/t-sql/database-console-commands/dbcc-shrinkfile-transact-sql
”Reduziert die Größe der angegebenen Daten oder Protokolldateien der aktuellen Datenbank.”
Dort steht auch “Verwenden Sie DBCC SHRINKFILE nur bei Bedarf.” - für den Betrieb unserer eigenen SQL Server haben wir diesen Bedarf doch ab und zu, so dass wir es mit in unsere interne Automatisierung eingebaut haben. Hintergrund ist, dass man mit “DBCC loginfo”, bzw. moderner heute mit https://learn.microsoft.com/de-de/sql/relational-databases/system-dynamic-management-views/sys-dm-db-log-info-transact-sql prüfen kann, wie der Status der VLFs ist (Virtual Log Files) sys.dm_db_log_info: Ermitteln der Position des letzten VLF im Transaktionsprotokoll vor dem Verkleinern der Protokolldatei . Wenn “DBCC loginfo” z.B. viele Zeilen mit Status 0 hat, und dazwischen welche mit Status 2, dann hilft die hier beschriebene Vorgehensweise, um die Größe der Logdatei sicher zu reduzieren und dauerhaft normal “niedrig zu halten”.
IC2254