SQL-Sicherungssoftware (VDP) und Protokollversand

312
Derrick Moeller

Ich verstehe eine SQL-Wiederherstellungsoperation so, dass eine vollständige Sicherung sowie alle seither durchgeführten inkrementellen Sicherungen erforderlich sind.

Ebenso verstehe ich, Log Shippingdass es einen SQL-Job verwendet, um eine Transaktionsprotokollsicherung durchzuführen, die dann in einer anderen SQL-Instanz wiederhergestellt wird.

Vermutlich sind Sicherungen, die von einer integrierten Lösung (VDP, Networker usw.) ausgeführt werden, nicht mit den Sicherungen von vertraut Log Shipping. Dies führt vermutlich zu einer kaputten unruhigen Kette. Ist es üblich, bei der Verwendung auf Backups auf Dateiebene zurückzugreifen Log Shipping, oder habe ich auf dem Weg etwas missverstanden?

0
Der Protokollversand verwendet die Transaktionsprotokollierung und versendet die Transaktionen an den anderen Server, auf dem sich eine Datenbank im Standby-Modus befindet, mit einem geplanten Job, der die Transaktionen ausführt und die Transaktionen überprüft, die an diesem Punkt nicht angewendet werden und die von der primären DB-Serverinstanz übernommen wurden . Solange Sie nichts unternehmen, um die Protokollkette zu unterbrechen, sollte alles gut sein, wenn Sie die andere Sicherungsmethode auf dem Primärserver in Verbindung mit dem Protokollversand verwenden. Normalerweise müssen Sie eine einmalige vollständige Wiederherstellung auf dem sekundären LS-Server durchführen und dann die Protokolle von LS anwenden. Pimp Juice IT vor 6 Jahren 0
@PimpJuiceIT Wir verwenden SQL 2012, unsere inkrementellen Sicherungen kürzen das Datenbankprotokoll. Vermutlich ist das erwünscht? Würde unser Protokoll nicht auf unbestimmte Zeit wachsen? Derrick Moeller vor 6 Jahren 0
Lesen Sie meine Antwort hier: https://dba.stackexchange.com/questions/127297/how-does-a-transaction-log-backup-deal-with-active-log/127302#127302 und prüfen Sie, ob sich das für Sie klarstellt . Wenn Sie über große Transaktionen verfügen, die dazu führen, dass die Protokolldatei wächst und wächst, erhält diese LDF-DB-Transaktionsdatei den Speicherplatz nur dann zurück, wenn Sie sie verkleinern. Sobald die Transaktionen abgeschlossen sind, kann der Speicherplatz in der LDF-Datei von anderen Transaktionen wiederverwendet werden. Wenn Sie das Datenbankprotokoll immer weiter abschneiden, können Protokollversandsicherungen ein Alptraum sein. Andernfalls müssen Sie eine Wiederherstellung im Standby-Modus der sekundären Datenbank durchführen. Pimp Juice IT vor 6 Jahren 0
@PimpJuiceIT Wir verkleinern das Transaktionsprotokoll nicht aktiv, es hat eine relativ feste Größe. Es wird gelegentlich nach Wartungsarbeiten geschrumpft, aber nicht während des "normalen Laufs". Angenommen, das Protokoll wächst um 1 GB / Stunde und wird alle zwei Stunden gesichert. Ich glaube, dass das Protokoll die gleichen 2 GB Speicherplatz auf unbestimmte Zeit verwenden wird, ohne dass das Protokoll abgeschnitten wird. Ich gehe davon aus, dass das Protokoll jede Stunde wächst. Im Moment haben wir kein sekundäres LS, wir bewerten es als Lösung gegen eine AlwaysOn Availability Group als Berichtsdatenbank, und ich versuche, die Einschränkungen von LS zu verstehen. Derrick Moeller vor 6 Jahren 0
Ich verstehe ... es gibt nichts Vergleichbares als einen Mann. Wenn Sie also die Möglichkeit haben, das System einzurichten und zu testen, welche Lösung am besten funktioniert, schlage ich vor, einfach herauszufinden, wie oder was für Ihre spezifischen Anforderungen und Ihre Umgebung funktioniert. Wenn Sie Transaktionsprotokolle mit einem LS-Setup abschließen, steht der inaktive Transaktionsteil der Protokolldatei an dieser Stelle zur Wiederverwendung zur Verfügung. Wenn Sie für jeden 15-Minuten-Transaktionsdump einrichten, werden alle 15 Minuten, die beispielsweise auftreten, festgelegt. Ich habe AlwaysOn nie persönlich verwendet, aber LS eignet sich hervorragend für Berichte und DR in meiner Erfahrung. Pimp Juice IT vor 6 Jahren 0
In einer Umgebung .... Ich hatte die LS-Sicherungs- und Kopieraufträge einmal alle 15 Minuten ausgeführt, glaube ich. Auf Sekundärseite für DR haben wir dann eine nächtliche LS-Wiederherstellung durchgeführt, um die TRN-Dateien auf die DB anzuwenden. Für die Berichterstellung haben wir einmal pro Nacht um 20:00 Uhr gearbeitet. Jeder wusste, dass die Berichterstattungsdaten um 24 Stunden hinter denen lagen, die in diesem Geschäftsumfeld gefunden wurden. Bis 20:00 Uhr waren dann alle Daten der Produktionsdatenbank eingegeben und das Geschäft geschlossen. Darüber hinaus habe ich auch den vollständigen Sicherungsjob (von prod) eingerichtet, um die komprimierte BAK-Datei auf eine sekundäre Freigabe zu kopieren, für den Fall, dass sie auf sekundär wiederhergestellt werden muss. Pimp Juice IT vor 6 Jahren 0

0 Antworten auf die Frage

Verwandte Probleme