SQL Server-Sicherung/Wiederherstellung vs. detach/attach

Question

Ich habe eine Datenbank, die die neuesten Daten enthält, und ich möchte den Datenbankinhalt in einigen anderen Servern replizieren. Aus nicht technischen Gründen kann ich die Replikatfunktion oder die Synchronisierungsfunktion nicht direkt für die Synchronisierung mit anderen SQL Server-Instanzen verwenden.

Jetzt habe ich zwei Lösungen, und ich möchte für jede Lösung die Vor- und Nachteile lernen. Vielen Dank!

Lösung 1: Trennen Sie die Quellendatenbank, die die neuesten Daten enthält, kopieren Sie dann auf die Zielserver, die die neuesten Daten benötigen, und hängen Sie die Datenbank auf den Zielservern an.

Lösung 2: Erstellen Sie eine vollständige Sicherung des Quellservers für die gesamte Datenbank, kopieren Sie dann die Daten auf die Zielserver und nehmen Sie eine vollständige Wiederherstellung auf der Seite des Zielservers vor.

Vielen Dank im Voraus, George

Answer 1

Die Detach/Attach Option ist oft schneller als ein Backup durchführen, da es nicht um eine neue Datei erstellen hat. Daher ist die Zeit von Server A zu Server B fast ausschließlich die Zeit für das Kopieren von Dateien.

Mit der Option Backup/Restore können Sie eine vollständige Sicherung durchführen, diese wiederherstellen und anschließend eine differenzielle Sicherung durchführen, wodurch die Ausfallzeit zwischen beiden reduziert werden kann.

Wenn es um die Datenreplikation geht, bedeutet das, dass Sie die Datenbank an beiden Standorten funktionsfähig haben wollen? In diesem Fall möchten Sie wahrscheinlich die Backup/Restore-Option, da die aktuelle Datenbank damit voll funktionsfähig bleibt.

EDIT: Nur um ein paar Punkte zu klären. Unter Ausfallzeiten verstehe ich, dass Sie bei der Migration einer Datenbank von einem Server auf einen anderen im Allgemeinen verhindern, dass Benutzer sie während der Übertragung verwenden. Daher kann dies vom "Stopp" -Punkt auf Server A bis zum "Start" -Punkt auf Server B als Ausfallzeit betrachtet werden. Andernfalls werden alle Aktionen, die während des Transports für die Datenbank auf Server A ausgeführt werden, nicht auf Server B repliziert.

In Bezug auf die "eine neue Datei erstellen". Wenn Sie eine Datenbank trennen, können Sie die MDF-Datei sofort kopieren. Es ist bereits bereit, kopiert zu werden. Wenn Sie jedoch eine Sicherung durchführen, müssen Sie auf die Erstellung der .BAK-Datei warten und sie dann für eine Wiederherstellung an den neuen Speicherort verschieben. Auch hier handelt es sich um eine Snapshot-Kopie oder eine Migration.

Answer 2

Lösung 2 wäre meine Wahl ... Hauptsächlich, weil es keine Ausfallzeit in der Quelldatenbank verursacht. Der einzige Nachteil, den ich feststellen kann, ist, dass das Transaktionsprotokoll je nach Wiederherstellungsmodell der Datenbank abgeschnitten wird. Wenn Sie also Daten aus dem Transaktionslog wiederherstellen möchten, müssen Sie Ihre Sicherungsdatei verwenden.

EDIT: Gefunden eine nette Verbindung; http://sql-server-performance.com/Community/forums/p/5838/35573.aspx

Answer 3

Das Sichern und Wiederherstellen ist viel sinnvoller, selbst wenn Sie stattdessen ein paar zusätzliche Minuten von einer Detach-Attach-Option entfernen. Sie müssen die ursprüngliche Datenbank vor einem Trennen offline schalten (alle trennen), und dann ist die Datenbank nicht verfügbar, bis Sie sie wieder anfügen. Sie müssen auch alle Dateien verfolgen, während bei einer Sicherung alle Dateien gruppiert sind. Und mit den neuesten Versionen von SQL Server sind die Sicherungen komprimiert.

Und nur etwas zu korrigieren: DB-Sicherungen und differenzielle Sicherungen nicht das Protokoll abschneiden, und nicht die Protokollkette zu brechen.

Zusätzlich ist die COPY_ONLY-Funktionalität nur für die differentielle Basis relevant, nicht für das LOG. Alle Protokollsicherungen können nacheinander von jeder Sicherung aus angewendet werden, vorausgesetzt, die Protokollkette wurde nicht unterbrochen. Es gibt einen kleinen Unterschied zum Archivpunkt, aber ich kann nicht sehen, wo das zählt.