6
SQL Logdatei verkleinern
ich beschäftige mich schon eine Zeit lang mit SQL, allerdings muss ich hier auf ein Live-System zugreifen und konnte die Shrink Funktion vorher nicht ausfürhlich testen.
Hallo liebe SQL-Admins,
Es gibt in einer SQL 2008 R2 Umgebung zwei Datenbanken dessen LDF Logdateien unaufhörlich weiterwachsen (aktuell 50 - 65GB).
Ich hab mich soweit über die Logfiles informiert, allerdings habe ich noch ein paar Fragen die mir hoffentlich jemand beantworten kann:
Die Datenbanken werden von einem externen Programm gesichert (nicht die Logfiles). Kann ich nun ohne Bedenken die Verkleinern-Funktion des SQL Management Studios verwenden um die LDF Dateien auf beispielsweise 2GB zu verkleinern?
Mit welchen Komplikationen muss ich rechnen bzw was kann dabei schief gehen?
Die zweite Frage wäre, ob es Sinn macht die Größe der Logdateien allgemein zu beschränken (Beispielsweise auf 10GB)?
Wenn ich es richtig verstanden habe, benötigt man diese Files für Datenbank-Sicherungen. Die Sicherung übernimmt allerdings Symantecs Backup Exec? Sind diese Logdateien für mich in dieser Umgebung überhaupt relevant?
Schon mal jetzt vielen Dank für die Hilfe
Es gibt in einer SQL 2008 R2 Umgebung zwei Datenbanken dessen LDF Logdateien unaufhörlich weiterwachsen (aktuell 50 - 65GB).
Ich hab mich soweit über die Logfiles informiert, allerdings habe ich noch ein paar Fragen die mir hoffentlich jemand beantworten kann:
Die Datenbanken werden von einem externen Programm gesichert (nicht die Logfiles). Kann ich nun ohne Bedenken die Verkleinern-Funktion des SQL Management Studios verwenden um die LDF Dateien auf beispielsweise 2GB zu verkleinern?
Mit welchen Komplikationen muss ich rechnen bzw was kann dabei schief gehen?
Die zweite Frage wäre, ob es Sinn macht die Größe der Logdateien allgemein zu beschränken (Beispielsweise auf 10GB)?
Wenn ich es richtig verstanden habe, benötigt man diese Files für Datenbank-Sicherungen. Die Sicherung übernimmt allerdings Symantecs Backup Exec? Sind diese Logdateien für mich in dieser Umgebung überhaupt relevant?
Schon mal jetzt vielen Dank für die Hilfe
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 203333
Url: https://administrator.de/contentid/203333
Printed on: April 24, 2024 at 20:04 o'clock
6 Comments
Latest comment
Moin,
lass doch Backup Exec nach erfolgreicher Sicherung die Logs einfach abschneiden. Ggfs. kannst du auch das Logging auf "simple" stellen, da sollte man dann aber schon wissen was das für Auswirkungen hat.
Guckst du hier
lg,
Slainte
lass doch Backup Exec nach erfolgreicher Sicherung die Logs einfach abschneiden. Ggfs. kannst du auch das Logging auf "simple" stellen, da sollte man dann aber schon wissen was das für Auswirkungen hat.
Guckst du hier
lg,
Slainte
Hallo,
ähnliches hatten wir auch vor nicht allzu langer Zeit. Dieser Link hat uns sehr geholfen http://blogs.technet.com/b/austria/archive/2011/03/08/sql-server-the-tr ... .
Wichtig ist, das durch die Sicherung nur die alten abgearbeiteten Einträge entfernt werden, dadurch ist der Anteil % in Gebrauch des Files niedriger. Der File selbst behält aber seine Größe.
Dann natürlich die Angabe ändern, bis wieviel die Datei maximal wachsen darf.
Den File selbst bekommst du nur duch das shrinken kleiner.
Viel Erfolg
Andreas
Vielleicht noch als Tip bzw. Workaround: Wir haben nun einen Task laufen, der lokal die Datei sichert. Dadurch ist die Benutzung in % immer klein und der File wächst so nicht weiter. Dies lassen wir 1x pro Woche laufen, das Backup wird einfach überschrieben.
Wir machen das Ganze - auch nach Rücksprache - mit einer NAV DB...
ähnliches hatten wir auch vor nicht allzu langer Zeit. Dieser Link hat uns sehr geholfen http://blogs.technet.com/b/austria/archive/2011/03/08/sql-server-the-tr ... .
Wichtig ist, das durch die Sicherung nur die alten abgearbeiteten Einträge entfernt werden, dadurch ist der Anteil % in Gebrauch des Files niedriger. Der File selbst behält aber seine Größe.
Dann natürlich die Angabe ändern, bis wieviel die Datei maximal wachsen darf.
Den File selbst bekommst du nur duch das shrinken kleiner.
Viel Erfolg
Andreas
Vielleicht noch als Tip bzw. Workaround: Wir haben nun einen Task laufen, der lokal die Datei sichert. Dadurch ist die Benutzung in % immer klein und der File wächst so nicht weiter. Dies lassen wir 1x pro Woche laufen, das Backup wird einfach überschrieben.
Wir machen das Ganze - auch nach Rücksprache - mit einer NAV DB...
Hallo wer imme Du bist !
Du solltest Dich ausführlichst mit dem Thema Backup und Recovery Deiner DB befassen.
Wenn der der die Datensicherung eingerichtet hat, was von der Sache verstehen würde, hätte er die Sicherung wie folgt eingerichtet.
Einmal Täglich komplettsicherung der Datenbank.
Danach alles 1 bis 2 Stunden (länger oder kürzer, je nachdem was in der DB los ist) Sicherung der Transaktionslog.
Hinterfrund:
Mit der Sicherung der Datenbank kannst Du nur den Sicherungsstand wiederherstellen.
Wenn wir davon ausgehen, dass die Sicherung um 22.00 Uhr erfolgt und Du durch ein wie auch immer geartets Problem die DB und die Tansaktionlogs am nächsten Tag um 18.00 Uhr Abends verlierst, kannst Du nur den Stand vom Tag zuvor 22.00 Uhr wieder herstellen und der Rest der Arbeit ist verloren.
Wenn Du nun aber nach der komplettsicheurng regelmäßig je nach Auslastung der DB das Logfile sagen wir alle 20 Minuten wegsicherst hast Du einen maximalen Datenverlust von 20 Minuten und verhinderst gleichzeitig das wachsen der LDB-Dateien.
Natürlich ist es nicht nur mit dem Backup getan, auch ein regelmäßiges Testen der Wiederherstéllbarkeit des Backups ist nicht zu vernachlässigen.
Gruß
Anton
Du solltest Dich ausführlichst mit dem Thema Backup und Recovery Deiner DB befassen.
Wenn der der die Datensicherung eingerichtet hat, was von der Sache verstehen würde, hätte er die Sicherung wie folgt eingerichtet.
Einmal Täglich komplettsicherung der Datenbank.
Danach alles 1 bis 2 Stunden (länger oder kürzer, je nachdem was in der DB los ist) Sicherung der Transaktionslog.
Hinterfrund:
Mit der Sicherung der Datenbank kannst Du nur den Sicherungsstand wiederherstellen.
Wenn wir davon ausgehen, dass die Sicherung um 22.00 Uhr erfolgt und Du durch ein wie auch immer geartets Problem die DB und die Tansaktionlogs am nächsten Tag um 18.00 Uhr Abends verlierst, kannst Du nur den Stand vom Tag zuvor 22.00 Uhr wieder herstellen und der Rest der Arbeit ist verloren.
Wenn Du nun aber nach der komplettsicheurng regelmäßig je nach Auslastung der DB das Logfile sagen wir alle 20 Minuten wegsicherst hast Du einen maximalen Datenverlust von 20 Minuten und verhinderst gleichzeitig das wachsen der LDB-Dateien.
Natürlich ist es nicht nur mit dem Backup getan, auch ein regelmäßiges Testen der Wiederherstéllbarkeit des Backups ist nicht zu vernachlässigen.
Gruß
Anton
Falls...
Hi,
es versteht sich ja wohl von selbst, das die DB(s) mit Boardmitteln oder wie auch immer entsprechend - und häufig - gesichert wird.
Vielleicht noch kreuzweise durch verschiedene Brandabschnitte, an unterschiedlichen Tagen usw. usf.
Hier ging es doch wohl "nur" um die Transaktionlogs und darum, das diese Dateien dazu neigen, recht groß zu werden . Eben weil diese nicht korrekt angefasst oder gesichert werden.
Ich denke den Rest muss natürlich jeder für sich verantworten bzw. am besten an einem Testsystem vorab austesten.
Schönes WE
Hi,
es versteht sich ja wohl von selbst, das die DB(s) mit Boardmitteln oder wie auch immer entsprechend - und häufig - gesichert wird.
Vielleicht noch kreuzweise durch verschiedene Brandabschnitte, an unterschiedlichen Tagen usw. usf.
Hier ging es doch wohl "nur" um die Transaktionlogs und darum, das diese Dateien dazu neigen, recht groß zu werden . Eben weil diese nicht korrekt angefasst oder gesichert werden.
Ich denke den Rest muss natürlich jeder für sich verantworten bzw. am besten an einem Testsystem vorab austesten.
Schönes WE
Hallo zusammen,
danke für eure Unterstützung. Wie Ihr euch denken könnt war ich nicht der installateur der Datenbank und des Backup Schemas. Allerdings muss ich dieses jetzt verstehen.
Ich habe nun etwas weiter geforscht und in den Backup Exec Logs folgendes gefunden:
Datenbank XXYY ist zur Verwaltung von Transaktionsprotokollen konfiguriert. Transaktionsprotokoll-Backups werden nicht durchgeführt. Das Protokoll wird immer umfangreicher, bis es den gesamten Speicherplatz beansprucht. Regelmäßige Protokoll-Backups sollten geplant oder der einfache Wiederherstellungsmodus sollte für die Datenbank festgelegt werden.
Genau das ja hier der Fall. Es wird jede Nacht ein Vollbackup durch Backup Exec gemacht was auch ausreicht. Im Falle des Falles müssen die kompletten Datenbanken wieder hergestellt werden und nicht nur einzelne Datensätze.
So wie ich das verstanden habe, kann in diesem Fall auf den einfachen Wiederherstellungsmodell gewechselt werden?
danke für eure Unterstützung. Wie Ihr euch denken könnt war ich nicht der installateur der Datenbank und des Backup Schemas. Allerdings muss ich dieses jetzt verstehen.
Ich habe nun etwas weiter geforscht und in den Backup Exec Logs folgendes gefunden:
Datenbank XXYY ist zur Verwaltung von Transaktionsprotokollen konfiguriert. Transaktionsprotokoll-Backups werden nicht durchgeführt. Das Protokoll wird immer umfangreicher, bis es den gesamten Speicherplatz beansprucht. Regelmäßige Protokoll-Backups sollten geplant oder der einfache Wiederherstellungsmodus sollte für die Datenbank festgelegt werden.
Genau das ja hier der Fall. Es wird jede Nacht ein Vollbackup durch Backup Exec gemacht was auch ausreicht. Im Falle des Falles müssen die kompletten Datenbanken wieder hergestellt werden und nicht nur einzelne Datensätze.
So wie ich das verstanden habe, kann in diesem Fall auf den einfachen Wiederherstellungsmodell gewechselt werden?
So wie ich das verstanden habe, kann in diesem Fall auf den einfachen Wiederherstellungsmodell
gewechselt werden?
gewechselt werden?
Wenn Du eh nur einmal die Nacht sicherst, ja. Oder du sagst Backup Exec, das es nach erfolgter Sicherung die Logs abschneiden (truncaten) soll. Das geht mit den SQL-Optionen.
