Sichern und Wiederherstellen einer Datenbank

Wie jede andere Produktionsdatenbank sollte eine Datenbank, die an Synchronisierungen beteiligt ist, regelmäßig gesichert werden. Beim Wiederherstellen einer Datenbank aus einer Sicherung sind im Wesentlichen zwei Punkte zu berücksichtigen:

• Nach der Wiederherstellung in der Datenbank vorgenommene Änderungen wurden u. U. nicht an die Clients oder andere Peers weitergegeben. Die Ursache hierfür sind die timestamp-Werte, die beim Auswählen der Änderungen aus einer Datenbank verwendet werden.

  Beispielsweise ruft Sync Framework bei der Client- und Serversynchronisierung einen neuen Ankerwert aus der Serverdatenbank ab und speichert diesen in der Clientdatenbank. Dieser Wert wird als obere Grenze für die aktuellen Änderungen verwendet, die synchronisiert werden sollen. Weitere Informationen finden Sie unter Änderungsnachverfolgung in der Serverdatenbank. Nach der Wiederherstellung der Serverdatenbank liegt der in der Clientdatenbank gespeicherte Wert möglicherweise logisch vor dem Wert, der von der Serverdatenbank zurückgegeben wird.

• Bei Upload- und bidirektionalen Szenarien können für Clients oder andere Peers Änderungen vorliegen, die in der neu wiederhergestellten Datenbank nicht enthalten sind.

Die Beispiele in diesem Thema verwenden die Client- und Serversynchronisierung als Beispiel. Ähnliche Prinzipien gelten für die Peer-zu-Peer-Serversynchronisierung. Außerdem werden Peer-zu-Peer-Überlegungen beschrieben. Die Serverdatenbank ist der Remotepeer. Die Clientdatenbank ist der lokale Peer. Weitere Informationen zum Sichern und Wiederherstellen von SQL Server-Datenbanken, die mithilfe von SqlSyncProvider synchronisiert werden, finden Sie unter Vorgehensweise: Sichern und Wiederherstellen einer Datenbank (SQL Server).

Serverdatenbank

Um zu verstehen, wie die Clientdatenbank logisch vor der Serverdatenbank liegen kann, beachten Sie, wie Aktualisierungen in der Tabelle Sales.Customer der Sync Framework-Beispieldatenbank nachverfolgt werden. In der UpdateTimestamp-Spalte wird ein timestamp-Wert gespeichert, und der neue Ankerbefehl gibt aus der Funktion MIN_ACTIVE_ROWVERSION von SQL Server einen Wert zurück. Aus Gründen der Übersichtlichkeit werden in diesem Beispiel anstelle von Hexadezimalwerten ganze Zahlen verwendet:

1. Bevor die Datenbank wiederhergestellt wird, gibt MIN_ACTIVE_ROWVERSION den Wert 31 zurück. Dieser Wert wurde in der Clientdatenbank als zuletzt empfangener Anker gespeichert.

2. Nach der Wiederherstellung der Datenbank gibt MIN_ACTIVE_ROWVERSION den Wert 19 zurück.

3. Die Aktualisierungen werden so vorgenommen, dass der timestamp-Wert in der UpdateTimestamp-Spalte den Wert 32 erreicht.

4. Die Synchronisierung erfolgt, und MIN_ACTIVE_ROWVERSION gibt den Wert 32 zurück. Da 32 größer als der letzte empfangene Ankerwert 31 ist, wird die letzte Aktualisierung für Sales.Customer heruntergeladen. Die Aktualisierungen zwischen 19 und 31 werden nicht als Änderungen erkannt.

Jedes Nachverfolgungsschema, das eine logische Uhr wie beispielsweise einen Timestamp verwendet, ist für dieses Problem nicht erkannter Änderungen anfällig. Bei Nachverfolgungsschemas, die einen Datentyp auf der Grundlage von Datum und Uhrzeit verwenden, tritt dieses Problem nicht auf, da die Wanduhr unabhängig vom Status der Datenbank läuft. Bei der Peer-to-Peer-Synchronisierung ist ein Timestamp für die Änderungsnachverfolgung erforderlich.

Verwenden Sie zur Beseitigung des Problems mit dem Timestamp eine der folgenden Methoden:

• Ändern Sie den Timestamp für den Server auf den Wert vor dem Wiederherstellungsvorgang. Im obigen Beispiel können so lange Dummyaktualisierungen für eine separate Tabelle ausgeführt werden, bis MIN_ACTIVE_ROWVERSION den Wert 31 zurückgibt.

  Dies ist die empfohlene Vorgehensweise für die Peer-to-Peer-Synchronisierung.

• Speichern Sie den Anker für jeden Client auf dem Server. Im obigen Beispiel hat der aus der Sicherung zuletzt empfangene Anker den Wert 19. Damit würden alle nachfolgenden Aktualisierungen erkannt und alle Änderungen zwischen 19 und 32 heruntergeladen werden. Sync Framework bietet zwar keine integrierte Unterstützung dafür, Sie können aber wie folgt auf dem Server ein System erstellen:

  1. Erstellen Sie in der Serverdatenbank eine Tabelle, die für jeden Client eine eigene Zeile enthält. Die Tabelle sollte dann eine Spalte mit der ID, die Sync Framework für jeden Client generiert, sowie eine Spalte mit dem Anker für den betreffenden Client enthalten. Während der Synchronisierung aktualisiert die Anwendung diese Spalte mit einem neuen Ankerwert.

  2. Ändern Sie die Synchronisierungsbefehle so, dass der niedrigste Ankerwert für den Client ausgewählt wird, der die Synchronisierung durchführt. Dieser Wert kann der in der Clientdatenbank oder der in der Serverdatenbank gespeicherte Wert sein. Nach einer Datenbankwiederherstellung müsste der Wert in der Serverdatenbank niedriger sein. Wenn es nach dem Schreiben eines Werts in die Servertabelle und vor dem Übernehmen von Änderungen für den Client zu einem Fehler kommt, müsste der Wert in der Clientdatenbank niedriger sein. Wenn die Synchronisierung wie erwartet abläuft, müssten die Werte gleich sein. Ein Einfügebefehl könnte wie folgt geschrieben werden:

     SELECT CustomerId, CustomerName, SalesPerson, CustomerType
     FROM Sales.Customer
     WHERE (InsertTimestamp > (SELECT AnchorValue from ServerAnchorTable WHERE ClientId = @sync_client_id)
     OR InsertTimestamp > @sync_last_received_anchor) AND InsertTimestamp <= @sync_new_received_anchor
     AND InsertId <> @sync_client_id
     

Clientdatenbanken

Nachdem die Serverdatenbank hinsichtlich der Synchronisierungsmetadaten auf den aktuellen Zeitpunkt wiederhergestellt worden ist, können in der Datenbank immer noch die Änderungen fehlen, die auf Clients seit der Zeit vorgenommen wurden, zu der die Serversicherung erfolgt ist. Ein Client kann nur entsprechend reagieren, wenn er weiß, dass die Serverdatenbank wiederhergestellt wurde. Sie könnten eine serverseitige Nachverfolgungstabelle verwenden, die angibt, ob seit der letzten Synchronisierung, die ein konkreter Client vorgenommen hat, eine Wiederherstellung erfolgt ist. Bei jeder Synchronisierungssitzung würde die Clientanwendung dann zunächst in dieser Tabelle nachsehen, um zu bestimmen, ob sie eine normale Synchronisierung vornehmen kann oder ob sie speziellen Code ausführen muss, um mit der wiederhergestellten Datenbank zusammenzuarbeiten.

Wenn eine Clientanwendung erkennt, dass die Serverdatenbank wiederhergestellt wurde, kann die Anwendung die Client- und die Serverdatenbank in Übereinstimmung bringen. Dafür stehen u. a. die folgenden Möglichkeiten zur Verfügung:

• Initialisieren Sie die Clientdatenbank neu, indem Sie alle Tabellen verwerfen und dann eine Synchronisierung mit dem Server vornehmen. Dies ist die einfachste Methode. Allerdings gehen dabei alle am Client vorgenommenen Änderungen verloren.

  Die erneute Initialisierung ist die empfohlene Vorgehensweise für die Peer-to-Peer-Synchronisierung. Informationen zum Initialisieren von Peerdatenbanken finden Sie unter „Initialisieren einer Serverdatenbank“ in Vorgehensweise: Konfigurieren und Ausführen der Synchronisierung für die Zusammenarbeit (Nicht-SQL Server).

• Initialisieren Sie die Clientdatenbank erneut, nachdem Sie eine Kopie der Clienttabellen erstellt haben. Eine Anwendung könnte die folgenden Schritte ausführen:

  1. Feststellen, dass die Serverdatenbank wiederhergestellt wurde

  2. Kopie aller Tabellen in der Clientdatenbank anlegen und anschließend die Originaltabellen verwerfen

  3. Synchronisierung mit dem Server vornehmen, um das neue Schema und neue Daten herunterzuladen

  4. Die Zeilen in den neuen Tabellen mit den Zeilen in den Kopien vergleichen

  5. Alle Unterschiede zwischen den beiden Tabellensätzen ermitteln und alle erforderlichen Änderungen in die neuen Tabellen übernehmen

  6. Erneute Synchronisierung vornehmen, um die an den neuen Tabellen vorgenommenen Änderungen hochzuladen

Siehe auch

Konzepte

Überlegungen zum Entwurf und zur Bereitstellung von Anwendungen