Peterzz 11 Geschrieben 1. Dezember 2021 Melden Teilen Geschrieben 1. Dezember 2021 Hallo, da ich nicht so firm im SQL-Server 2017 bin habe ich mal die Frage, ob man die Transaktions-DB (*.Log ) regelmäßig, natürlich nach eine Backup, über das Management Studio verkleinern sollte oder ohne Probleme verkleinern kann? Danke Zitieren Link zu diesem Kommentar
Beste Lösung NilsK 2.940 Geschrieben 1. Dezember 2021 Beste Lösung Melden Teilen Geschrieben 1. Dezember 2021 (bearbeitet) Moin, Wenn man regelmäßig richtige Backups macht, wächst das Log normalerweise gar nicht so groß an. Aber im Wesentlichen ist die Antwort Ja. https://www.faq-o-matic.net/2014/08/27/sql-server-transaktionsprotokoll-verkleinern/ Gruß, Nils bearbeitet 1. Dezember 2021 von NilsK Zitieren Link zu diesem Kommentar
cj_berlin 1.323 Geschrieben 1. Dezember 2021 Melden Teilen Geschrieben 1. Dezember 2021 ...aber wenn Deine Logs unkontrolliert anwachsen, kannst Du ja auch kritisch hinterfragen, ob jede Anwendung ihre Datenbank tatsächlich im Wiederherstellungsmodell "FULL" benötigt. Zitieren Link zu diesem Kommentar
Peterzz 11 Geschrieben 1. Dezember 2021 Autor Melden Teilen Geschrieben 1. Dezember 2021 Danke für die Antwort und dem Link. vor 48 Minuten schrieb cj_berlin: aber wenn Deine Logs unkontrolliert anwachsen, kannst Du ja auch kritisch hinterfragen, ob jede Anwendung ihre Datenbank tatsächlich im Wiederherstellungsmodell "FULL" benötigt. Ist es nicht eigentlich besser, das Backup "Vollständig" als "Einfach" zu machen, damit man die Option hat Transaktionsloggenau wiederherzustellen? Zitieren Link zu diesem Kommentar
cj_berlin 1.323 Geschrieben 1. Dezember 2021 Melden Teilen Geschrieben 1. Dezember 2021 vor 23 Minuten schrieb Peterzz: Ist es nicht eigentlich besser, das Backup "Vollständig" als "Einfach" zu machen, damit man die Option hat Transaktionsloggenau wiederherzustellen? Wenn Du eine Anwendung hast, die einfach nur Logs und Konfigurationsänderungen in die DB schreibt, was willst Du da mit einem Point-in-Time-Restore anfangen? Klar, bei Finanztransaktionen oder so ist es notwendig, aber viele Anwendungshersteller machen sich da keinen Kopf. Manche schreiben sogar in ihrem Install Guide "recovery model=simple", erzeugen die Datenbank aber mit Standardeinstellungen von SQL (recovery model=full). Zitieren Link zu diesem Kommentar
Peterzz 11 Geschrieben 1. Dezember 2021 Autor Melden Teilen Geschrieben 1. Dezember 2021 vor 3 Minuten schrieb cj_berlin: nur Logs und Konfigurationsänderungen in die DB schreibt Ja, das sehe ich ein. Da macht das bestimmt keinen Sinn. Danke für die Zusatzinfos. Zitieren Link zu diesem Kommentar
NilsK 2.940 Geschrieben 1. Dezember 2021 Melden Teilen Geschrieben 1. Dezember 2021 Moin, die Hintergrundfragen habe ich hier mal ausführlicher beleuchtet: [SQL Server: Wie Datenablage, Backup und Recovery funktionieren | faq-o-matic.net]https://www.faq-o-matic.net/2011/01/03/sql-server-wie-datenablage-backup-und-recovery-funktionieren/ Gruß, Nils 1 Zitieren Link zu diesem Kommentar
Peterzz 11 Geschrieben 1. Dezember 2021 Autor Melden Teilen Geschrieben 1. Dezember 2021 vor 1 Stunde schrieb NilsK: die Hintergrundfragen habe ich hier mal ausführlicher beleuchtet: Zitieren Link zu diesem Kommentar
MDD 12 Geschrieben 2. Dezember 2021 Melden Teilen Geschrieben 2. Dezember 2021 (bearbeitet) Korrigiert mich wenn ich falsch dran bin. Wenn man das Full-Model fährt und recht große Log-Dateien hat kann ein Verkleinern der Dateien schon Effekt haben. Ist das automatische Vergrößern der Datei auf einen sehr kleinen Fixwert eingestellt, z.B. 1 MB, führt das unter Umständen dazu das man eine fragmentierte Datei hat. Ist ein Prozentwert eingestellt und das File ist groß kann das Anfordern von Platz Zeit kosten, was sich auf die Verarbeitungszeit auswirken kann. Und ja - das ganze hängt mit dem darunter liegenden HD-System zusammen. Regelmäßiges Abschneiden mag diese Effekte haben. Daher sollte die File-Einstellung mit ins Kalkül gezogen werden. Gruß MDD bearbeitet 2. Dezember 2021 von MDD fragmentiert statt defragmentiert. Danke Nils Zitieren Link zu diesem Kommentar
NilsK 2.940 Geschrieben 2. Dezember 2021 Melden Teilen Geschrieben 2. Dezember 2021 Moin, ja, das entspricht ja dem, was wir gesagt haben und auch dem, was in dem verlinkten Artikel steht. Wo siehst du jetzt einen Widerspruch? Gruß, Nils PS. du meinst "fragmentiert". ;) Zitieren Link zu diesem Kommentar
MDD 12 Geschrieben 9. Dezember 2021 Melden Teilen Geschrieben 9. Dezember 2021 Mir ist nicht aufgefallen in den angeführten Artikeln irgendwas über meine erwähnten Effekte stand, was das Allokieren von Speicherplatz anlagt. Zitieren Link zu diesem Kommentar
NilsK 2.940 Geschrieben 10. Dezember 2021 Melden Teilen Geschrieben 10. Dezember 2021 Moin, oh, ich wollte dir nicht zu nahe treten, sorry, falls der Eindruck entstanden ist. Dann hatte ich den Schwerpunkt deines Postings missverstanden. Der Aspekt mit der Fragmentierung war in der Tat noch nicht genannt worden. Gruß, Nils Zitieren Link zu diesem Kommentar
Squire 262 Geschrieben 7. Januar 2022 Melden Teilen Geschrieben 7. Januar 2022 Normalerweise schneidet jede halbwegs vernünftige und für SQL Server geeignete Sicherungssoftware die Transaction Logs nach dem Backup ab, sodass ein manuelles Verkleinern nicht nötig ist. Welche Backup Software ist denn im Einsatz? Zitieren Link zu diesem Kommentar
NilsK 2.940 Geschrieben 7. Januar 2022 Melden Teilen Geschrieben 7. Januar 2022 Moin, vor 3 Minuten schrieb Squire: Normalerweise schneidet jede halbwegs vernünftige und für SQL Server geeignete Sicherungssoftware die Transaction Logs nach dem Backup ab, sodass ein manuelles Verkleinern nicht nötig ist. das habe ich auch jahrelang gedacht und behauptet. Das ist aber nicht so. Mindestens das eingebaute Backupsystem lässt bei einem Full Backup die Logs in Ruhe. Man muss sich separat drum kümmern. https://www.sqlservercentral.com/forums/topic/does-a-full-backup-truncate-the-log Gruß, Nils Zitieren Link zu diesem Kommentar
Squire 262 Geschrieben 7. Januar 2022 Melden Teilen Geschrieben 7. Januar 2022 (bearbeitet) Aus eigener Erfahrung ... zumindest IBM Spectrum Protect, Nakivo und Veeam kürzen die Logs. Wobei ich wirklich nur bei kritischen DBs auf RecoveryMode Full gehe ... bei den meisten DBs braucht es kein PointInTime Restore. Bei den meisten DBs reicht Simple als Recovery Modell bearbeitet 7. Januar 2022 von Squire Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.