8
DPM SQL-Sicherung kürzt die Transaktionslogs nicht mehr
Hallo Leute,
ich musste meinen DPM (Data Protection Manager) - Server neu aufsetzen, weil er in die Brüche gegangen ist.
Habe alle Schutzgruppen etc. wieder eingerichtet und auch die Backups laufen astrein.
Das Problem was ich derzeit habe und nciht weiß wieso das so ist, ist dass unsere SQL-Datenbank (Widerherstellungsmodus: Vollständig) zwar komplett gesichert wird, jedoch die Transaktionslogs nicht.
Heißt der Container wird nciht geleert.
Ich sehe auch in den Eigenschaften der Datenbank den Eintrag:
Letzte Transaktionslogsicherung: 16.11.2021
Da wir eine recht große DB mit Zugriffen von etwas mehr als 350 Usern haben, wächst das Log sehr schnell.
Im Moment helfe ich mir mit einer vom SQL-Managementstudio iniziierten LOG-Datei-Sicherung.
Unsere DB ist 21TB groß.
Hat jemand eine Idee woran das liegen könnte?
Am DPM gibt es nichts einzustellen sondern bis zum 16.11. hat das alles wunderbar funktioniert.
Das einzige was sich geändert hat ist der DPM-Server, der ist ein anderer.
Aber gleiche Konfig und Versionen vom OS als auch DPM.
LG
Enrico
ich musste meinen DPM (Data Protection Manager) - Server neu aufsetzen, weil er in die Brüche gegangen ist.
Habe alle Schutzgruppen etc. wieder eingerichtet und auch die Backups laufen astrein.
Das Problem was ich derzeit habe und nciht weiß wieso das so ist, ist dass unsere SQL-Datenbank (Widerherstellungsmodus: Vollständig) zwar komplett gesichert wird, jedoch die Transaktionslogs nicht.
Heißt der Container wird nciht geleert.
Ich sehe auch in den Eigenschaften der Datenbank den Eintrag:
Letzte Transaktionslogsicherung: 16.11.2021
Da wir eine recht große DB mit Zugriffen von etwas mehr als 350 Usern haben, wächst das Log sehr schnell.
Im Moment helfe ich mir mit einer vom SQL-Managementstudio iniziierten LOG-Datei-Sicherung.
Unsere DB ist 21TB groß.
Hat jemand eine Idee woran das liegen könnte?
Am DPM gibt es nichts einzustellen sondern bis zum 16.11. hat das alles wunderbar funktioniert.
Das einzige was sich geändert hat ist der DPM-Server, der ist ein anderer.
Aber gleiche Konfig und Versionen vom OS als auch DPM.
LG
Enrico
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1566483837
Url: https://administrator.de/contentid/1566483837
Ausgedruckt am: 22.11.2024 um 14:11 Uhr
8 Kommentare
Neuester Kommentar
Moin,
prüf' mal die Prüfpunkteinstellungen:
https://docs.microsoft.com/de-de/sql/relational-databases/logs/database- ...
und allgemein das hier:
https://docs.microsoft.com/de-de/sql/relational-databases/logs/the-trans ...
Grüße
prüf' mal die Prüfpunkteinstellungen:
https://docs.microsoft.com/de-de/sql/relational-databases/logs/database- ...
und allgemein das hier:
https://docs.microsoft.com/de-de/sql/relational-databases/logs/the-trans ...
Grüße
MS SQL Sicherung sollte nicht nur die Datenbank aber auch die Transaktionslogs haben, MS empfiehlt abwechselndes sichern.
Denn:
Wenn ein Transaktionsprotokoll beschädigt wird, gehen die Änderungen seit der letzten gültigen Sicherung verloren. Daher empfehlen wir dringend, Protokolldateien auf einem fehlertoleranten Datenträger zu speichern.
quelle: https://docs.microsoft.com/de-de/sql/relational-databases/backup-restore ...
Denn:
Wenn ein Transaktionsprotokoll beschädigt wird, gehen die Änderungen seit der letzten gültigen Sicherung verloren. Daher empfehlen wir dringend, Protokolldateien auf einem fehlertoleranten Datenträger zu speichern.
quelle: https://docs.microsoft.com/de-de/sql/relational-databases/backup-restore ...
N'Abend.
DPM ist ne Weile her - aus dem Gedächtnis:
Entferne die DBs aus der Protection Group, ändere das Wiederherstellungsmodell auf Einfach und starte die Instanz neu, dann änderst du das Wiederherstellungsmodell wieder auf Vollständig und fügst die DBs wieder zur Protection Group hinzu. Dann direkt und sofort ein Backup starten.
DPM ist (oder war?) eigentlich ein sehr robustes Stück Software, aber bei SQL-Backups schon immer ein Sensibelchen gewesen.
Cheers,
jsysde
DPM ist ne Weile her - aus dem Gedächtnis:
Entferne die DBs aus der Protection Group, ändere das Wiederherstellungsmodell auf Einfach und starte die Instanz neu, dann änderst du das Wiederherstellungsmodell wieder auf Vollständig und fügst die DBs wieder zur Protection Group hinzu. Dann direkt und sofort ein Backup starten.
DPM ist (oder war?) eigentlich ein sehr robustes Stück Software, aber bei SQL-Backups schon immer ein Sensibelchen gewesen.
Cheers,
jsysde
Hi jsysde,
leider ist es unmöglich die Instanzen abzuhängen. Leider 24/7 Betrieb.
Aber es ist doch richtig, dass dann die Eigenschaten der DB mitschrieben, dass die Transaktionslogs gesicherten wurden.
Mein letzter Stand ist halt der 16.11.2021 und ab da an war Essig mit dem kürzen und leeren der Logs.
leider ist es unmöglich die Instanzen abzuhängen. Leider 24/7 Betrieb.
Aber es ist doch richtig, dass dann die Eigenschaten der DB mitschrieben, dass die Transaktionslogs gesicherten wurden.
Mein letzter Stand ist halt der 16.11.2021 und ab da an war Essig mit dem kürzen und leeren der Logs.
Moin.
Naja, dann wirst du ein Maintenance Window aufmachen müssen - der Neustart einer Instanz dauert genau wie lange? Ist das schon ne Minute oder doch nur Sekunden?
Es gibt halt (beim DPM) keinen anderen Weg, dieses leidige Problem (schleppen die seit DPM2010 (!!) mit sich rum) zu lösen. Siehe z.B. hier: https://geeql.com/2016/06/21/dpm-and-why-are-my-transaction-logs-filling ...
Google liefert dir auch reichlich Futter dazu: https://www.google.com/search?q=dpm+not+backing+up+transaction+logs
Die Quintessenz ist bei allen Beiträgen dazu die gleiche - ohne "raus aus der PG, Wiederherstellungsmodell ändern, wieder rein in die PG" kommst du aus der Nummer nicht raus.
Cheers,
jsysde
Naja, dann wirst du ein Maintenance Window aufmachen müssen - der Neustart einer Instanz dauert genau wie lange? Ist das schon ne Minute oder doch nur Sekunden?
Es gibt halt (beim DPM) keinen anderen Weg, dieses leidige Problem (schleppen die seit DPM2010 (!!) mit sich rum) zu lösen. Siehe z.B. hier: https://geeql.com/2016/06/21/dpm-and-why-are-my-transaction-logs-filling ...
Google liefert dir auch reichlich Futter dazu: https://www.google.com/search?q=dpm+not+backing+up+transaction+logs
Die Quintessenz ist bei allen Beiträgen dazu die gleiche - ohne "raus aus der PG, Wiederherstellungsmodell ändern, wieder rein in die PG" kommst du aus der Nummer nicht raus.
Cheers,
jsysde
Ok. Dann werd ich das mal als Wartung ankündigen und hoffen.
Ich danke dir und werde berichten
Ich danke dir und werde berichten
Mahlzeit.
Ich halte die Daumen.
Cheers,
jsysde
Ich halte die Daumen.
Cheers,
jsysde
Es ist manchmal einfach zu einfach. Das Problem war doch tatsächlich, das die Wiederherstellungspunkterstellung und die synchronisation tatsächlich auf die gleiche Uhrzeit verwiesen und demnach sich gegenseitig behinderten.
