Freigeben über

Upgrade des Protokollversands auf den SQL Server 2014 (Transact-SQL)

Es ist möglich, Protokollversandkonfigurationen beim Upgrade von SQL Server 2005, SQL Server 2008, SQL Server 2008 R2 oder SQL Server 2012 auf SQL Server 2014 beizubehalten. In diesem Thema werden alternative Szenarien und bewährte Methoden zum Aktualisieren einer Protokollversandkonfiguration beschrieben.

Hinweis

Die Sicherungskomprimierung wurde in SQL Server 2008 Enterprise eingeführt. In einer aktualisierten Protokollversandkonfiguration wird durch die Serverkonfigurationsoption Komprimierungsstandard für Sicherung bestimmt, ob die Transaktionsprotokoll-Sicherungsdateien mithilfe der Sicherungskomprimierung komprimiert werden. Das Verhalten für die Sicherungskomprimierung der Protokollsicherung kann für jede Protokollversandkonfiguration festgelegt werden. Weitere Informationen finden Sie unter Konfigurieren des Protokollversands (SQL Server).

Datensicherung vor dem Upgrade

Als bewährte Methode wird empfohlen, dass Sie die Daten vor einem Protokollversandupgrade schützen.

So schützen Sie die Daten

  1. Führen Sie für jede primäre Datenbank eine vollständige Datenbanksicherung aus.

    Weitere Informationen finden Sie unter Erstellen einer vollständigen Datenbanksicherung (SQL Server).

  2. Führen Sie den DBCC CHECKDB -Befehl für jede primäre Datenbank aus.

Aktualisieren der MonitorServerinstanz

Die Überwachungsserverinstanz, sofern vorhanden, kann jederzeit aktualisiert werden.

Während der Aktualisierung des Überwachungsservers ist die Protokollversandkonfiguration weiterhin in Betrieb, ihr Status wird allerdings nicht in den Tabellen auf dem Überwachungsserver aufgezeichnet. Warnungen, die ggf. konfiguriert wurden, werden während der Aktualisierung des Überwachungsservers nicht ausgelöst. Nach der Aktualisierung können Sie die Überwachungstabellen aktualisieren, indem Sie die gespeicherte Systemprozedur sp_refresh_log_shipping_monitor ausführen.

Aktualisieren von Protokollversandkonfigurationen mit einem einzelnen sekundären Server

Bei dem in diesem Abschnitt beschriebenen Upgradeprozess wird davon ausgegangen, dass eine Konfiguration besteht, die aus dem primären Server und nur einem sekundären Server besteht. Diese Konfiguration wird in der folgenden Abbildung dargestellt, die eine primäre Serverinstanz, A und eine einzelne sekundäre Serverinstanz B zeigt.

Ein sekundärer Server und kein Monitorserver

Informationen zum Upgrade mehrerer sekundärer Server finden Sie weiter unten in diesem Thema unter Upgrade mehrerer sekundärer Serverinstanzen.

Aktualisieren der sekundären Serverinstanz

Der Upgradevorgang umfasst das Upgrade der sekundären Serverinstanzen einer SQL Server 2005- oder höher-Protokollversandkonfiguration auf SQL Server 2014, bevor die primäre Serverinstanz aktualisiert wird. Aktualisieren Sie immer zuerst die sekundäre Serverinstanz. Wenn der primäre Server vor einem sekundären Server aktualisiert wurde, schlägt der Protokollversand fehl, da eine auf einer neueren Version von SQL Server erstellte Sicherung nicht in einer älteren Version von SQL Server wiederhergestellt werden kann.

Der Protokollversand wird während des gesamten Upgrade-Prozesses fortgesetzt, da die aktualisierten sekundären Server weiterhin die Protokollsicherungen vom primären SQL Server 2005 oder höher wiederherstellen. Der Prozess für das Upgrade der sekundären Serverinstanzen hängt teilweise davon ab, ob die Protokollversandkonfiguration über mehrere sekundäre Server verfügt. Weitere Informationen finden Sie unter Upgrade mehrerer sekundärer Serverinstanzen weiter unten in diesem Thema.

Während die sekundäre Serverinstanz aktualisiert wird, werden die Kopier- und Wiederherstellungsaufträge für den Protokollversand nicht ausgeführt, sodass nicht wiederhergestellte Transaktionsprotokollsicherungen sich ansammeln. Die Menge der Akkumulation hängt von der Häufigkeit der geplanten Sicherung auf dem primären Server ab. Wenn ein getrennter Überwachungsserver konfiguriert wurde, werden möglicherweise Warnungen ausgegeben, die anzeigen, dass über einen längeren Zeitraum als das konfigurierte Intervall hinweg keine Wiederherstellungsvorgänge ausgeführt wurden.

Nachdem der sekundäre Server aktualisiert wurde, werden die Aufträge des Protokollversand-Agents fortgesetzt und weiterhin Protokollsicherungen aus der primären Serverinstanz, Server A, kopiert und wiederhergestellt. Die zeitaufwendige Zeit, die der sekundäre Server benötigt, um die sekundäre Datenbank auf dem neuesten Stand zu bringen, variiert je nach der Zeit, die zum Aktualisieren des sekundären Servers benötigt wird, und der Häufigkeit der Sicherungen auf dem primären Server.

Hinweis

Während des Serverupgrades wird die sekundäre Datenbank nicht auf eine SQL Server 2014-Datenbank aktualisiert. Es wird nur aktualisiert, wenn es online gebracht wird.

Von Bedeutung

Die RESTORE WITH STANDBY-Option wird für Datenbanken, die eine Aktualisierung erfordern, nicht unterstützt. Wenn eine aktualisierte sekundäre Datenbank mithilfe von RESTORE WITH STANDBY konfiguriert wurde, können Transaktionsprotokolle nach einer Aktualisierung nicht wiederhergestellt werden. Um den Protokollversand auf dieser sekundären Datenbank fortzusetzen, müssen Sie ihn auf diesem Standbyserver erneut einrichten. Weitere Informationen zur STANDBY-Option finden Sie unter RESTORE Arguments (Transact-SQL).

Aktualisieren der primären Serverinstanz

Bei der Planung eines Upgrades ist es wichtig zu berücksichtigen, wie lange Ihre Datenbank nicht verfügbar sein wird. Das einfachste Upgradeszenario umfasst, dass die Datenbank nicht verfügbar ist, während Sie den primären Server aktualisieren (Szenario 1, unten).

Zum Kosten eines komplizierteren Upgradeprozesses können Sie die Verfügbarkeit Ihrer Datenbank maximieren, indem Sie den primären SQL Server 2005- oder höher-Server auf einen sekundären SQL Server 2014 ausführen, bevor Sie den ursprünglichen primären Server aktualisieren (Szenario 2, unten). Es gibt zwei Varianten des Failoverszenarios. Sie können zurück zum ursprünglichen primären Server wechseln und die ursprüngliche Protokollversandkonfiguration beibehalten. Alternativ können Sie die ursprüngliche Protokollversandkonfiguration entfernen, bevor Sie den ursprünglichen primären Server aktualisieren und später eine neue Konfiguration mit dem neuen primären Server erstellen. In diesem Abschnitt werden beide Szenarien beschrieben.

Von Bedeutung

Achten Sie darauf, die sekundäre Serverinstanz vor dem Upgrade der primären Serverinstanz zu aktualisieren. Weitere Informationen finden Sie weiter oben in diesem Thema unter Upgrade der sekundären Serverinstanz.

Szenario 1: Upgrade der primären Serverinstanz ohne Failover

Dies ist das einfachere Szenario, verursacht aber mehr Ausfallzeiten als die Verwendung von Failover. Die primäre Serverinstanz wird einfach aktualisiert, und die Datenbank ist während dieses Upgrades nicht verfügbar.

Sobald der Server aktualisiert wurde, wird die Datenbank automatisch online geschaltet. Daraufhin wird sie automatisch aktualisiert. Nachdem die Datenbank aktualisiert wurde, werden die Protokollversandaufträge fortgesetzt.

Szenario 2: Upgrade der primären Serverinstanz mit Failover

Dieses Szenario maximiert die Verfügbarkeit und minimiert Ausfallzeiten. Es verwendet ein kontrolliertes Failover auf die sekundäre Serverinstanz, wodurch die Datenbank verfügbar bleibt, während die ursprüngliche primäre Serverinstanz aktualisiert wird. Ausfallzeiten sind auf die relativ kurze Zeit beschränkt, die zum Übergang zu einem Backup-System erforderlich ist, statt der Zeit, die für das Upgrade der primären Serverinstanz benötigt wird.

Das Upgrade der primären Serverinstanz mit Failover umfasst drei allgemeine Verfahren: Ausführen eines kontrollierten Failovers auf den sekundären Server, Upgrade der ursprünglichen primären Serverinstanz auf SQL Server 2014 und Einrichten des Protokollversands auf einer primären SERVERinstanz von SQL Server 2014. Diese Verfahren werden in diesem Abschnitt beschrieben.

Von Bedeutung

Wenn Sie beabsichtigen, die sekundäre Serverinstanz als neue primäre Serverinstanz zu verwenden, müssen Sie die Protokollversandkonfiguration entfernen. Der Protokollversand muss vom neuen primären Server auf den neuen sekundären Server neu konfiguriert werden, nachdem die ursprüngliche primäre Serverinstanz aktualisiert wurde. Weitere Informationen finden Sie unter Remove Log Shipping (SQL Server).For more information, see Remove Log Shipping (SQL Server).

Prozedur 1: Ausführen eines kontrollierten Failovers auf den sekundären Server

Kontrolliertes Failover auf den sekundären Server:

  1. Führen Sie manuell eine Tailprotokollsicherung des Transaktionsprotokolls in der primären Datenbank aus, die WITH NORECOVERY angibt. Diese Protokollsicherung erfasst alle Protokolldatensätze, die noch nicht gesichert wurden. Dann wird die Datenbank offline versetzt. Beachten Sie, dass während der Offlinemodus der Datenbank der Sicherungsauftrag für den Protokollversand fehlschlägt.

    Im folgenden Beispiel wird eine Tailprotokollsicherung der AdventureWorks Datenbank auf dem primären Server erstellt. Die Sicherungsdatei heißt:Failover_AW_20080315.trn

    BACKUP LOG AdventureWorks 
  TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Failover_AW_20080315.trn' 
   WITH NORECOVERY;
GO

    Es wird empfohlen, eine unterschiedliche Benennungskonvention für Dateien zu verwenden, um die manuell erstellte Sicherungsdatei von den Sicherungsdateien zu unterscheiden, die vom Sicherungsauftrag für den Protokollversand erstellt wurden.

  2. Auf dem sekundären Server:

    1. Stellen Sie sicher, dass alle Sicherungen, die automatisch von den Sicherungsaufträgen für den Protokollversand übernommen wurden, angewendet wurden. Um zu überprüfen, welche Sicherungsaufträge angewendet wurden, verwenden Sie die sp_help_log_shipping_monitor gespeicherte Systemprozedur auf dem Monitorserver oder auf den primären und sekundären Servern. Die gleiche Datei sollte in den Spalten last_backup_file, last_copied_file und last_restored_file aufgeführt werden. Wenn eine der Sicherungsdateien nicht kopiert und wiederhergestellt wurde, rufen Sie die Agentkopie- und Wiederherstellungsaufträge für die Protokollversandkonfiguration manuell auf.

      Informationen zum Starten eines Auftrags finden Sie unter "Auftrag starten".

    2. Kopieren Sie die endgültige Protokolldatei, die Sie in Schritt 1 erstellt haben, von der Dateifreigabe an den lokalen Speicherort, der vom Protokollversand auf dem sekundären Server verwendet wird.

    3. Stellen Sie die endgültige Protokollsicherung wieder her, indem Sie WITH RECOVERY angeben, um die Datenbank online zu bringen. Im Rahmen der Onlineerstellung wird die Datenbank auf SQL Server 2014 aktualisiert.

      Im folgenden Beispiel wird die Sicherung des Tail-Logs der AdventureWorks-Datenbank auf der sekundären Datenbank wiederhergestellt. Im Beispiel wird die WITH RECOVERY-Option verwendet, die die Datenbank online bringt:

      RESTORE LOG AdventureWorks 
  FROM DISK = N'c:\logshipping\Failover_AW_20080315.trn' 
   WITH RECOVERY;
GO

      Hinweis

      Für eine Konfiguration, die mehr als einen sekundären Server enthält, gibt es zusätzliche Überlegungen. Weitere Informationen finden Sie unter Upgrade mehrerer sekundärer Serverinstanzen weiter unten in diesem Thema.

    4. Führen Sie einen Failover der Datenbank durch, indem Sie Clients vom ursprünglichen primären Server (Server A) an den sekundären Online-Server (Server B) umleiten.

    5. Achten Sie darauf, dass das Transaktionsprotokoll der sekundären Datenbank nicht ausgefüllt wird, während die Datenbank online ist. Um zu verhindern, dass das Transaktionsprotokoll ausgefüllt wird, müssen Sie es möglicherweise sichern. Wenn dies der Fall ist, empfiehlt es sich, sie an einem freigegebenen Speicherort, einer Sicherungsfreigabe, zu sichern, um die Sicherungen für die Wiederherstellung auf der anderen Serverinstanz verfügbar zu machen.

Prozedur 2: Upgrade der ursprünglichen primären Serverinstanz auf SQL Server 2014

Nachdem Sie die ursprüngliche primäre Serverinstanz auf SQL Server 2014 aktualisiert haben, bleibt die Datenbank weiterhin offline und in ihrem Format.

Verfahren 3: Einrichten des Protokollversands auf SQL Server 2014

Der rest des Upgradeprozesses hängt davon ab, ob der Protokollversand wie folgt konfiguriert ist:

  • Wenn Sie die SQL Server 2005or-Konfiguration für den höheren Protokollversand beibehalten haben, wechseln Sie zurück zur ursprünglichen primären Serverinstanz. Weitere Informationen finden Sie unter "Zurück zur ursprünglichen primären Serverinstanz" weiter unten in diesem Abschnitt.

  • Wenn Sie die Protokollversandkonfiguration vor einem Failover entfernt haben, erstellen Sie eine neue Protokollversandkonfiguration, in der die ursprüngliche sekundäre Serverinstanz die neue primäre Serverinstanz ist. Weitere Informationen finden Sie unter "Beibehalten der alten sekundären Serverinstanz als neue primäre Serverinstanz" weiter unten in diesem Abschnitt.

So wechseln Sie zurück zur ursprünglichen primären Serverinstanz

  1. Sichern Sie auf dem Zwischen-Primärserver (Server B) den Tail des Protokolls mithilfe von WITH NORECOVERY, um eine Tailprotokollsicherung zu erstellen und die Datenbank offline zu schalten. Die Protokollsicherung wird als Switchback_AW_20080315.trn benannt. Zum Beispiel:

    BACKUP LOG AdventureWorks 
  TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Switchback_AW_20080315.trn' 
   WITH NORECOVERY;
GO

  2. Wenn auf der vorläufigen primären Datenbank Transaktionsprotokollsicherungen erstellt wurden, abgesehen von der in Schritt 1 erstellten Tail-Sicherung, stellen Sie diese Protokollsicherungen unter Verwendung von WITH NORECOVERY auf dem ursprünglichen primären Server (Server A) in der Offlinedatenbank wieder her. Die Datenbank wird auf das SQL Server 2014-Format aktualisiert, wenn die erste Protokollsicherung wiederhergestellt wird.

  3. Stellen Sie die Sicherung des Tailprotokolls in der ursprünglichen primären Datenbank (auf Server A) mithilfe von WITH RECOVERY wieder her, Switchback_AW_20080315.trnum die Datenbank online zu schalten.

  4. Übernehmen Sie zurück zur ursprünglichen Primärdatenbank (auf Server A), indem Sie die Clients vom ursprünglichen Primärserver zum online verfügbaren Sekundärserver umleiten.

Nachdem die Datenbank online ist, wird die ursprüngliche Protokollversandkonfiguration fortgesetzt.

So behalten Sie die alte sekundäre Serverinstanz als neue primäre Serverinstanz bei

Richten Sie eine neue Protokollversandkonfiguration mithilfe der alten sekundären Serverinstanz B als Primärserver und der alten primären Serverinstanz A als neuen sekundären Server wie folgt ein:

Von Bedeutung

Die alte Konfiguration für den Protokollversand sollte zu Beginn des Prozesses vom ursprünglichen primären Server entfernt worden sein, bevor die manuelle Transaktionsprotokollsicherung, die die Datenbank offline genommen hat, übernommen wurde.

  1. Um eine vollständige Sicherung und Wiederherstellung der Datenbank auf dem neuen sekundären Server (Server A) zu vermeiden, wenden Sie die Protokollsicherungen aus der neuen primären Datenbank auf die neue sekundäre Datenbank an. In der Beispielkonfiguration umfasst dies das Wiederherstellen der Protokollsicherungen auf Server B in der Datenbank auf Server A.

  2. Sichern Sie das Protokoll aus der neuen primären Datenbank (auf Server B).

  3. Stellen Sie die Protokollsicherungen mithilfe von WITH NORECOVERY auf der neuen sekundären Serverinstanz (Server A) wieder her. Der erste Wiederherstellungsvorgang aktualisiert die Datenbank auf SQL Server 2014.

  4. Konfigurieren Sie den Protokollversand mit dem ehemaligen sekundären Server (Server B) als primäre Serverinstanz.

    Von Bedeutung

    Wenn Sie SQL Server Management Studio verwenden, geben Sie an, dass die sekundäre Datenbank bereits initialisiert ist.

    Weitere Informationen finden Sie unter Konfigurieren des Protokollversands (SQL Server).

  5. Schalten Sie die Datenbank um, indem Sie Clients vom ursprünglichen Server A zum sekundären Server B umleiten.

    Von Bedeutung

    Wenn Sie ein Failover zu einer neuen primären Datenbank durchführen, sollten Sie sicherstellen, dass die Metadaten mit den Metadaten der ursprünglichen primären Datenbank konsistent sind. Weitere Informationen finden Sie unter Verwalten von Metadaten beim Bereitstellen einer Datenbank auf einer anderen Serverinstanz (SQL Server).

Aktualisieren mehrerer sekundärer Serverinstanzen

Diese Konfiguration wird in der folgenden Abbildung dargestellt, die eine primäre Serverinstanz, A und zwei sekundäre Serverinstanzen, B und C, zeigt.

Zwei sekundäre Server und kein Monitorserver

In diesem Abschnitt wird erläutert, wie Sie ein Upgrade mithilfe eines Failovers durchführen und dann zurück zum ursprünglichen primären Server wechseln. Beim Upgrade der primären Instanz mit Failover ist der Prozess komplexer, wenn mehrere sekundäre Serverinstanzen vorhanden sind. Im folgenden Verfahren wird der primäre Server auf eine der aktualisierten sekundären Datenbanken umgeschaltet, nachdem alle sekundären Server aktualisiert wurden. Der ursprüngliche primäre Server wird aktualisiert, und der Protokollversand wird zurückgeschaltet.

Von Bedeutung

Aktualisieren Sie immer alle sekundären Serverinstanzen, bevor Sie den primären Server aktualisieren.

So führen Sie ein Upgrade mit einem Failover durch und wechseln dann zurück zum ursprünglichen primären Server

  1. Aktualisieren Sie alle sekundären Serverinstanzen (Server B und Server C).

  2. Rufen Sie den Tail des Transaktionsprotokolls der primären Datenbank (auf Server A) ab, und nehmen Sie die Datenbank offline, indem Sie das Transaktionsprotokoll mit WITH NORECOVERY sichern.

  3. Stellen Sie auf dem sekundären Server, auf dem Sie einen Failover (Server B) planen, die sekundäre Datenbank online, indem Sie die Protokollsicherung mithilfe von WITH RECOVERY wiederherstellen.

  4. Lassen Sie auf jedem anderen sekundären Server (Server C) die sekundäre Datenbank offline, indem Sie die Protokollsicherung mit WITH NORECOVERY wiederherstellen.

    Hinweis

    Die Kopier- und Wiederherstellungsaufträge für den Protokollversand werden auf den sekundären Servern ausgeführt, haben jedoch keine Wirkung, da neue Log-Backup-Dateien nicht auf der Sicherungsfreigabe abgelegt werden.

  5. Schalten Sie die Datenbank um, indem Sie Clients vom ursprünglichen primären Server (Server A) zum Online-Sekundärserver (Server B) umleiten. Die Onlinedatenbank wird zu einem vorläufigen primären Server, wobei die Datenbank verfügbar bleibt, während der ursprüngliche primäre Server offline ist (Server A).

  6. Upgrade des ursprünglichen primären Servers (Server A).

  7. Führen Sie auf der Datenbank, zu der Sie das Failover durchgeführt haben - der aktuellen Primärdatenbank (auf Server B), eine manuelle Sicherung des Transaktionsprotokolls mit WITH NORECOVERY durch. Dadurch wird die Datenbank offline.

  8. Stellen Sie alle Transaktionsprotokollsicherungen wieder her, die Sie in der Zwischen-Primärdatenbank (auf Server B) erstellt haben, in jeder anderen sekundären Datenbank (auf Server C) mit WITH NORECOVERY. Dadurch kann der Protokollversand nach dem Upgrade von der ursprünglichen primären Datenbank fortgesetzt werden, ohne dass für jede sekundäre Datenbank eine vollständige Datenbankwiederherstellung erforderlich ist.

  9. Stellen Sie das Transaktionsprotokoll vom Zwischen-Primärserver (Server B) mithilfe von WITH RECOVERY in der ursprünglichen primären Datenbank auf Server A wieder her.

Erneute Bereitstellung von Log Shipping

Wenn Sie Ihre Protokollversandkonfiguration nicht mithilfe eines der oben gezeigten Verfahren migrieren möchten, können Sie den Protokollversand von Grund auf neu bereitstellen, indem Sie die sekundäre Datenbank mit einer vollständigen Sicherung und Wiederherstellung der primären Datenbank erneut initialisieren. Dies kann eine wünschenswerte Option sein, wenn Sie über eine kleine Datenbank verfügen oder eine hohe Verfügbarkeit während des Upgradevorgangs nicht von entscheidender Bedeutung ist.

Informationen zum Aktivieren des Protokollversands finden Sie unter Konfigurieren des Protokollversands (SQL Server).

Siehe auch

Transaktionsprotokollsicherungen (SQL Server)Anwenden von Transaktionsprotokollsicherungen (SQL Server)Protokollversandtabellen und gespeicherten Prozeduren

  • Last updated on