Minimieren der Ausfallzeit von gespiegelten Datenbanken beim Aktualisieren von Serverinstanzen

Beim Upgrade von Serverinstanzen auf SQL Server 2014 können Sie die Ausfallzeit für jede gespiegelte Datenbank auf ein einzelnes manuelles Failover reduzieren, indem Sie ein sequenzielles Upgrade durchführen, das als paralleles Upgrade bezeichnet wird. Ein paralleles Upgrade bildet einen mehrstufigen Vorgang, bei dem im einfachsten Fall die gegenwärtig als Spiegelserver in einer Spiegelungssitzung verwendete Serverinstanz aktualisiert, dann ein manuelles Failover auf die gespiegelte Datenbank ausgeführt, der vorherige Prinzipalserver aktualisiert und die Spiegelung wiederaufgenommen wird. In der Praxis hängt der genaue Vorgang vom Beriebsmodus und der Anzahl und dem Layout der Spiegelungssitzung auf den zu aktualisierenden Serverinstanzen ab.

Hinweis

Informationen zum Ausführen eines parallelen Upgrades zum Installieren eines Service Packs oder Hotfixes finden Sie unter Installieren eines Service Packs auf einem System mit minimaler Ausfallzeit für gespiegelte Datenbanken.

Empfehlungen zur Vorbereitung (bewährte Methoden)

Vor dem Start eines parallelen Upgrades sollten Sie Folgendes ausführen:

  1. Führen Sie zu Übungszwecken ein manuelles Failover für mindestens eine der Spiegelungssitzungen aus:

    Hinweis

    Informationen zum Verwalten des potenziellen Datenverlusts finden Sie unter Rollenwechsel während einer Datenbank-Spiegelungssitzung (SQL Server).

  2. Schützen Sie Ihre Daten:

    1. Führen Sie für jede Prinzipaldatenbank eine vollständige Datenbanksicherung aus:

      Erstellen einer vollständigen Datenbanksicherung (SQL Server).

    2. Führen Sie den DBCC CHECKDB-Befehl für jede Prinzipaldatenbank aus.

Phasen eines parallelen Upgrades

Die einzelnen Schritte bei einem parallelen Upgrade hängen vom Betriebsmodus der Spiegelungskonfiguration ab. Die grundlegenden Phasen sind jedoch identisch.

Hinweis

Weitere Informationen zu den Betriebsmodi finden Sie unter Betriebsmodi der Datenbankspiegelung.

Die folgende Abbildung zeigt ein Flussdiagramm mit den Grundstufen eines parallelen Upgrades für jeden Betriebsmodus. Die entsprechenden Prozeduren finden Sie nach der Abbildung.

Flussdiagramm mit den Schritten eines parallelen Upgrades

Wichtig

Eine Serverinstanz kann bei gleichzeitigen Spiegelungssitzungen verschiedene Spiegelungsrollen (Prinzipalserver, Spiegelserver oder Zeuge) ausführen. In diesem Fall müssen Sie den grundlegenden Prozess für das parallele Upgrade entsprechend anpassen. Weitere Informationen finden Sie unter Rollenwechsel während einer Datenbank-Spiegelungssitzung (SQL Server).

So ändern Sie den Modus einer Sitzung vom Modus für hohe Leistung in den Modus für hohe Sicherheit

  1. Ändern Sie den Betriebsmodus in den Modus für hohe Sicherheit ohne automatisches Failover, wenn sich eine Spiegelungssitzung vor der Ausführung eines parallelen Upgrades im Modus für hohe Leistung befindet.

    Wichtig

    Wenn der Spiegelserver vom Prinzipalserver geografisch entfernt ist, ist ein paralleles Upgrade möglicherweise nicht geeignet.

So entfernen Sie einen Zeugen aus einer Sitzung

  1. Wenn ein Zeuge an einer Spiegelungssitzung beteiligt ist, sollte der Zeuge vor der Ausführung eines parallelen Upgrades entfernt werden. Andernfalls hängt die Datenbankverfügbarkeit beim Upgrade der Spiegelserverinstanz von dem Zeugen ab, der weiterhin mit der Prinzipalserverinstanz verbunden bleibt. Nachdem Sie den Zeugen entfernt haben, ist ein Upgrade jederzeit während des parallelen Upgrades ohne Gefahr eines Datenbankausfalls möglich.

So führen Sie das parallele Upgrade aus

  1. Zur Minimierung der Ausfallzeit wird Folgendes empfohlen: Starten Sie das parallele Upgrade mit dem Aktualisieren aller Spiegelungspartner, die aktuell als Spiegelserver in allen Spiegelungssitzungen fungieren. Möglicherweise müssen an dieser Stelle mehrere Serverinstanzen aktualisiert werden.

    Hinweis

    Ein Zeuge kann jederzeit während der Ausführung des parallelen Upgrades aktualisiert werden. Wenn beispielsweise eine Serverinstanz in Sitzung 1 als Spiegelserver und in Sitzung 2 als Zeuge fungiert, können Sie die Serverinstanz nun aktualisieren.

    Welche Serverinstanz zuerst aktualisiert wird, hängt von der aktuellen Konfiguration der Spiegelungssitzungen ab, und zwar wie folgt:

    • Wenn eine Serverinstanz bereits als Spiegelserver in allen Spiegelungssitzungen fungiert, aktualisieren Sie die Serverinstanz auf die neue Version.

    • Wenn alle Serverinstanzen aktuell als Prinzipalserver in allen Spiegelungssitzungen fungieren, wählen Sie eine Serverinstanz aus, die zuerst aktualisiert werden soll. Führen Sie dann ein manuelles Failover für alle Prinzipaldatenbanken aus, und aktualisieren Sie die Serverinstanz.

    Nach dem Upgrade schließt sich eine Serverinstanz automatisch wieder den zugehörigen Spiegelungssitzungen an.

  2. Warten Sie bei jeder Spiegelungssitzung, deren Serverinstanz gerade aktualisiert wurde, ab, bis die Sitzung synchronisiert ist. Stellen Sie dann eine Verbindung mit der Prinzipalserverinstanz her, und führen Sie manuell ein Failover zur Sitzung aus. Beim Failover wird die aktualisierte Serverinstanz zum Prinzipalserver dieser Sitzung, und der frühere Prinzipalserver wird zum Spiegelserver.

    Ziel dieses Schritts ist es, dass eine andere Serverinstanz zum Spiegelserver in jeder Spiegelungssitzung wird, an der sie als Partner beteiligt ist.

    Einschränkungen nach einem Failover zu einer aktualisierten Serverinstanz

    Nach dem Failover von einem früheren Server instance auf einen SQL Server 2014-Server instance wird die Datenbanksitzung angehalten. Sie kann erst dann fortgesetzt werden, wenn der andere Partner aktualisiert wurde. Der Prinzipalserver nimmt jedoch nach wie vor Verbindungen an und lässt den Datenzugriff auf die und Änderungen an der Prinzipaldatenbank zu.

    Hinweis

    Damit eine neue Spiegelungssitzung eingerichtet werden kann, muss auf allen Serverinstanzen dieselbe Version von SQL Serverausgeführt werden.

  3. Nach dem Failover empfiehlt es sich, den BEFEHL DBCC CHECKDB für die datenbankprincipal auszuführen.

  4. Aktualisieren Sie alle Serverinstanzen, die nun als Spiegelserver in allen Spiegelungssitzungen fungieren, in denen sie als Partner beteiligt sind. Möglicherweise müssen an dieser Stelle mehrere Server aktualisiert werden.

    Wichtig

    Es ist möglich, dass in einer komplexen Spiegelungskonfiguration manche Serverinstanz nach wie vor der ursprüngliche Prinzipalserver in mindestens einer Spiegelungssitzung ist. Wiederholen Sie die Schritte 2 bis 4 für diese Serverinstanzen, bis alle beteiligten Instanzen aktualisiert wurden.

  5. Setzen Sie die Spiegelungssitzung fort.

    Hinweis

    Ein automatisches Failover ist erst möglich, wenn der Zeuge aktualisiert und der Spiegelungssitzung erneut hinzugefügt wurde.

  6. Aktualisieren Sie die verbleibenden Serverinstanzen, die als Zeuge in allen zugehörigen Spiegelungssitzungen fungieren. Nachdem sich ein aktualisierter Zeuge wieder einer Spiegelungssitzung angeschlossen hat, ist das Ausführen eines automatischen Failovers wieder möglich. Möglicherweise müssen an dieser Stelle mehrere Server aktualisiert werden.

So ändern Sie den Modus einer Sitzung wieder in den Modus für hohe Leistung

  1. Sie haben die folgenden Möglichkeiten, um den Modus einer Sitzung wieder in den Modus für hohe Leistung zu ändern:

    • In SQL Server Management Studio: Ändern Sie im Dialogfeld Datenbankeigenschaften auf der Seite Spiegelung die Option Betriebsmodus in Hohe Leistung (asynchron) .

    • In Transact-SQL: Verwenden Sie ALTER DATABASE, um die Transaktionssicherheit auf OFF festzulegen.

So fügen Sie einen Zeugen einer Spiegelungssitzung erneut hinzu

  1. Im Modus für hohe Sicherheit können Sie den Zeugen in jeder Spiegelungssitzung wiederherstellen.

    So fügen Sie einen Zeugen wieder hinzu

Weitere Informationen

ALTER DATABASE-Datenbankspiegelung (Transact-SQL)
BACKUP (Transact-SQL)
Anzeigen des Status einer gespiegelten Datenbank (SQL Server Management Studio)
Datenbankspiegelung (SQL Server)
Installieren eines Service Packs auf einem System mit minimaler Downtime der gespiegelten Datenbanken
Rollenwechsel während einer Datenbank-Spiegelungssitzung (SQL Server)
Erzwingen des Diensts in einer Datenbank-Spiegelungssitzung (Transact-SQL)
Starten des Datenbankspiegelungs-Monitors (SQL Server Management Studio)
Database Mirroring Operating Modes