Minimieren der Ausfallzeit von gespiegelten Datenbanken beim Aktualisieren von Serverinstanzen

Wenn Sie Serverinstanzen von SQL Server 2005 oder SQL Server 2008 auf SQL Server 2012 aktualisieren, können Sie die Ausfallzeiten der einzelnen gespiegelten Datenbanken auf nur einen einzelnen manuellen Failover begrenzen, indem Sie ein sequenzielles Upgrade ausführen, das auch 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 eines Hotfixes finden Sie unter Installieren eines Service Packs auf einem System mit minimaler Downtime der gespiegelten 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:

   • Manueller Failover für eine Datenbank-Spiegelungssitzung (SQL Server Management Studio)

   • Ausführen des manuellen Failovers einer Datenbank-Spiegelungssitzung (Transact-SQL).

   Hinweis
   Informationen zur Funktionsweise eines manuellen Failovers 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
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.

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

• Ä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.

  • In SQL Server Management Studio: Ändern Sie im Dialogfeld Datenbankeigenschaften auf der Seite Spiegelung die Option Betriebsmodus in Hohe Sicherheit ohne automatisches Failover (synchron). Informationen zum Zugriff auf diese Seite finden Sie unter Starten des Assistenten zum Konfigurieren der Sicherheit für die Datenbankspiegelung (SQL Server Management Studio).

  • In Transact-SQL: Legen Sie die Transaktionssicherheit auf FULL fest. Weitere Informationen finden Sie unter Ändern der Transaktionssicherheit in einer Datenbank-Spiegelungssitzung (Transact-SQL).

So entfernen Sie einen Zeugen aus einer Sitzung

• 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 von dem Zeugen ab, der weiterhin mit der Prinzipalserverinstanz verbunden bleibt, wenn die Spiegelserverinstanz aktualisiert wird. Wenn Sie einen Zeugen entfernt haben, ist eine Aktualisierung jederzeit während des parallelen Upgradeprozesses möglich, ohne Gefahr zu laufen, dass die Datenbank ausfällt.

  Hinweis
  Weitere Informationen finden Sie unter Quorum: Auswirkungen eines Zeugen auf die Datenbankverfügbarkeit (Datenbankspiegelung).

  • Entfernen des Zeugen aus einer Datenbank-Spiegelungssitzung (SQL Server)

So führen Sie das parallele Upgrade aus

1. Zur Minimierung der Ausfallzeit wird Folgendes empfohlen: Starten Sie das Rolling 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 Rolling 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 der Aktualisierung 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, in der sie als Partner beteiligt ist.

   Einschränkungen nach einem Failover zu einer aktualisierten Serverinstanz

   Nach dem Ausführen eines Failovers von einer SQL Server 2005- oder SQL Server 2008-Serverinstanz zu einer SQL Server 2012-Serverinstanz 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 Server ausgeführt werden.

3. Nach der Ausführung eines Failovers sollten Sie den DBCC CHECKDB-Befehl für die Prinzipaldatenbank ausfü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 sind.

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

• 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

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

  So fügen Sie einen Zeugen wieder hinzu

  • Hinzufügen oder Ersetzen eines Datenbank-Spiegelungszeugen (SQL Server Management Studio)

  • Hinzufügen eines Zeugen für die Datenbankspiegelung mithilfe der Windows-Authentifizierung (Transact-SQL)

Siehe auch

Aufgaben

Anzeigen des Status einer gespiegelten Datenbank (SQL Server Management Studio)

Installieren eines Service Packs auf einem System mit minimaler Downtime der gespiegelten Datenbanken

Erzwingen des Diensts in einer Datenbank-Spiegelungssitzung (Transact-SQL)

Starten des Datenbankspiegelungs-Monitors (SQL Server Management Studio)

Verweis

ALTER DATABASE-Datenbankspiegelung (Transact-SQL)

BACKUP (Transact-SQL)

Konzepte

Datenbankspiegelung (SQL Server)

Rollenwechsel während einer Datenbank-Spiegelungssitzung (SQL Server)

Betriebsmodi der Datenbankspiegelung