Aktualisieren des SQL Server 2005-Protokollversands auf SQL Server 2008

Beim Aktualisieren von SQL Server 2005 auf SQL Server 2008 kann die Protokollversandkonfigurationen beibehalten werden. 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 backup compression default bestimmt, ob die Transaktionsprotokollsicherungsdateien 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 Vorgehensweise: Aktivieren des Protokollversands (SQL Server Management Studio).

Datensicherung vor der Aktualisierung

Als bewährte Methode wird empfohlen, dass Sie die Daten vor einer Protokollversandaktualisierung 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 in den folgenden Themen:

   • Vorgehensweise: Sichern einer Datenbank (SQL Server Management Studio).

   • Vorgehensweise: Erstellen einer vollständigen Datenbanksicherung (Transact-SQL)

   • BACKUP (Transact-SQL)

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

Aktualisieren der Überwachungsserverinstanz

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 (Transact-SQL) ausführen.

Der Aktualisierungsvorgang für Konfigurationen mit einem einzelnen sekundären Server

Für den in diesem Abschnitt beschriebenen Aktualisierungsvorgang wird eine Konfiguration vorausgesetzt, die einen primären Server und nur einen sekundären Server umfasst. Diese Konfiguration wird in der folgenden Abbildung dargestellt, die eine primäre Serverinstanz A und eine einzelne sekundäre Serverinstanz B zeigt.

Informationen zur Aktualisierung mehrerer sekundärer Server finden Sie unter "Überlegungen zur Aktualisierung mehrerer sekundärer Server" weiter hinten in diesem Thema.

Aktualisieren der sekundären Serverinstanz

Der Aktualisierungsvorgang erfordert die Aktualisierung der sekundären Serverinstanzen einer SQL Server 2005-Protokollversandkonfiguration auf SQL Server 2008, 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 wird, schlägt der Protokollversand fehl, weil eine mit einer neueren Version von SQL Server erstellte Sicherung nicht mit einer älteren Version von SQL Server wiederhergestellt werden kann.

Der Protokollversand wird während des Aktualisierungsvorgangs weiter ausgeführt, weil die aktualisierten sekundären Server die Protokollsicherungen vom primären SQL Server 2005-Server weiterhin wiederherstellen. Der Aktualisierungsvorgang für die sekundären Serverinstanzen hängt teilweise davon ab, ob die Protokollversandkonfiguration mehrere sekundäre Server umfasst Weitere Informationen hierzu finden Sie unter "Überlegungen zur Aktualisierung mehrerer sekundärer Server" weiter hinten in diesem Thema.

Während der Aktualisierung der sekundären Serverinstanz werden die Aufträge zum Kopieren und Wiederherstellen des Protokollversands nicht ausgeführt, daher sammeln sich nicht wiederhergestellte Sicherungen von Transaktionsprotokollen an. Die Menge dieser Ansammlung hängt von der Frequenz 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.

Sobald der sekundäre Server aktualisiert wurde, werden die Protokollversandaufträge der Agents zum Kopieren und Wiederherstellen von Protokollsicherungen von der primären Serverinstanz, Server A, wieder aufgenommen und fortgesetzt. Wie lange der sekundäre Server für die Aktualisierung der sekundären Datenbank benötigt, hängt davon ab, wie lange die Aktualisierung des sekundären Servers dauert und wie häufig die Sicherungen auf dem primären Server ausgeführt werden.

Hinweis
Während der Serveraktualisierung wird die sekundäre Datenbank nicht auf eine SQL Server 2008-Datenbank aktualisiert. Sie wird nur aktualisiert, wenn sie online geschaltet wird.

Wichtig

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 zu der Option STANDBY finden Sie unter RESTORE-Argumente (Transact-SQL).

Aktualisieren der primären Serverinstanz

Bei der Planung einer Aktualisierung ist die Dauer, für die die Datenbank nicht verfügbar sein ist, ein maßgeblicher Aspekt. Im einfachsten Aktualisierungsszenario ist die Datenbank nicht verfügbar, während der primäre Server aktualisiert wird (Szenario 1, unten).

Sie können die Datenbankverfügbarkeit maximieren, indem Sie für den primären SQL Server 2005-Server einen Failover auf einen sekundären SQL Server 2008-Server durchführen, bevor Sie den ursprünglichen primären Server aktualisieren (Szenario 2, unten). Der Aktualisierungsvorgang wird dadurch allerdings komplizierter. Es sind zwei Varianten des Failoverszenarios denkbar. 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 unter Verwendung des neuen primären Servers eine neue Konfiguration erstellen. In diesem Thema werden beide Szenarien beschrieben.

Wichtig
Aktualisieren Sie unbedingt die sekundäre Serverinstanz vor der primären Serverinstanz. Weitere Informationen finden Sie im Abschnitt "Aktualisieren der sekundären Serverinstanz" weiter oben in diesem Thema.

Szenario 1: Aktualisieren der primären Serverinstanz ohne Failover

Dies ist das einfachere Szenario, aber es verursacht eine längere Ausfallzeit als die Aktualisierung mit Failover. Die primäre Serverinstanz wird einfach aktualisiert, und die Datenbank ist während dieses Aktualisierungsvorgangs 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: Aktualisieren der primären Serverinstanz mit Failover

In diesem Szenario wird die Verfügbarkeit maximiert und die Ausfallzeit minimiert. Es wird ein kontrolliertes Failover auf die sekundäre Serverinstanz durchgeführt, wodurch die Datenbank verfügbar bleibt, während die ursprüngliche primäre Serverinstanz aktualisiert wird. Die Ausfallzeit wird auf den relativen kurzen Zeitraum beschränkt, der zur Durchführung des Failovers erforderlich ist, statt auf den Zeitraum, der zur Aktualisierung der primären Serverinstanz benötigt wird.

Das Aktualisieren der primären Serverinstanz mit Failover umfasst drei allgemeine Schritte: Ausführen eines kontrollierten Failovers auf den sekundären Server, Aktualisieren der ursprünglichen primären Serverinstanz auf SQL Server 2008 und Einrichten des Protokollversands auf einer primären Serverinstanz von SQL Server 2008. In diesem Abschnitt werden diese Schritte beschrieben.

Wichtig
Wenn Sie die sekundäre Serverinstanz als neue primäre Serverinstanz nutzen möchten, müssen Sie die Protokollversandkonfiguration entfernen. Der Protokollversand muss vom neuen primären auf den neuen sekundären Server konfiguriert werden, nachdem die ursprüngliche primäre Serverinstanz aktualisiert wurde. Weitere Informationen finden Sie unter Entfernen des Protokollversands.

Schritt 1. Ausführen eines kontrollierten Failovers auf den sekundären Server

Kontrollierter Failover auf den sekundären Server:

1. Führen Sie manuell eine Sicherung des Endes des Transaktionsprotokolls für die primäre Datenbank unter Angabe von WITH NORECOVERY durch. Mit dieser Protokollsicherung werden alle bislang noch nicht gesicherten Protokolldatensätze erfasst und die Datenbank offline geschaltet. Beachten Sie Folgendes: Während die Datenbank offline ist, kann der Protokollversandsicherungsauftrag nicht ausgeführt werden.

   Im folgenden Beispiel wird das Ende des Protokolls für die AdventureWorks-Datenbank auf dem primären Server gesichert. Die Sicherungsdatei erhält den Namen Failover_AW_20080315.trn:

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

   Es wird empfohlen, dass Sie eine eigene Dateibenennungskonvention verwenden, um manuell erstellte Sicherungsdateien von den Sicherungsdateien, die vom Protokollversandsicherungsauftrag erstellt werden, unterscheiden zu können.

2. Auf dem sekundären Server:

   1. Stellen Sie sicher, dass alle von Protokollversandsicherungsaufträgen durchgeführten Sicherungen automatisch übernommen wurden. Welche Sicherungsaufträge übernommen wurden, können Sie mithilfe der gespeicherten Systemprozedur sp_help_log_shipping_monitor (Transact-SQL) auf dem Überwachungsserver oder auf dem primären und dem sekundären Servern überprüfen. Dieselbe 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, starten Sie die Aufträge der Agents zum Kopieren und Wiederherstellen für die Protokollversandkonfiguration manuell. Weitere Informationen finden Sie unter Vorgehensweise: Starten eines Auftrags (SQL Server Management Studio) oder sp_start_job (Transact-SQL).

   2. Kopieren Sie die letzte Protokollsicherungsdatei, die Sie in Schritt 1 erstellt haben, von der Dateifreigabe an den Speicherort, der vom Protokollversand auf dem sekundären Server verwendet wird.

   3. Stellen Sie die letzte Protokollsicherung wieder her, und geben Sie hierbei WITH RECOVERY an, um die Datenbank online zu schalten. Die Datenbank wird im Rahmen des Onlineschaltens auf SQL Server 2008 aktualisiert.

      Im folgenden Beispiel wird das Ende der Protokollsicherung für die AdventureWorks-Datenbank in der sekundären Datenbank wiederhergestellt. Im Beispiel wird die WITH RECOVERY-Option verwendet, mit der die Datenbank online geschaltet wird:

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

      Hinweis
      Bei einer Konfiguration, die mehr als einen sekundären Server enthält, sind weitere Aspekte zu berücksichtigen. Weitere Informationen hierzu finden Sie unter "Überlegungen zur Aktualisierung mehrerer sekundärer Server" weiter hinten in diesem Thema.

   4. Führen Sie einen Failover für die Datenbank aus, indem Sie Clients vom ursprünglichen primären Server (Server A) auf den online geschalteten sekundären Server (Server B) durchführen.

   5. Sorgen Sie dafür, dass das Transaktionsprotokoll der zweiten Datenbank nicht gefüllt wird, während die Datenbank online ist. Um das Füllen des Transaktionsprotokolls zu verhindern, müssen Sie es sichern. Wenn Sie es sichern, wird die Verwendung eines gemeinsam genutzten Speicherorts, einer Sicherungsfreigabe, empfohlen, damit die Sicherungen zum Wiederherstellen auf der anderen Serverinstanz verfügbar sind.

Schritt 2. Aktualisieren der ursprünglichen primären Serverinstanz auf SQL Server 2008

Auch nachdem Sie die ursprüngliche primäre Serverinstanz auf SQL Server 2008 aktualisiert haben, ist die Datenbank noch offline und hat noch das SQL Server 2005-Format.

Schritt 3. Einrichten des Protokollversands auf SQL Server 2008

Der restliche Aktualisierungsvorgang hängt davon ab, ob der Protokollversand immer noch konfiguriert ist. Hier gilt:

• Wenn Sie die SQL Server 2005-Protokollversandkonfiguration beibehalten haben, wechseln Sie zurück zur ursprünglichen primären Serverinstanz. Weitere Informationen hierzu finden Sie unter "So wechseln Sie zurück zur ursprünglichen primären Serverinstanz" weiter hinten in diesem Thema.

• Wenn Sie die Protokollversandkonfiguration vor dem Failover entfernt haben, erstellen Sie eine neue Protokollversandkonfiguration, in der die ursprüngliche sekundäre Serverinstanz die neue primäre Serverinstanz bildet. Weitere Informationen hierzu finden Sie unter "So behalten Sie die ursprüngliche sekundäre Serverinstanz als neue primäre Serverinstanz bei" weiter hinten in diesem Thema.

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

1. Erstellen Sie auf dem zwischenzeitlichen primären Server (Server B) eine Sicherung des Endes der Protokolldatei unter Angabe von WITH NORECOVERY, um eine Sicherung des Protokollfragments zu erstellen und die Datenbank offline zu schalten. Die Sicherung des Protokollfragments hat den Namen Switchback_AW_20080315.trn. Beispiel:

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

2. Wenn für die zwischenzeitliche primäre Datenbank Transaktionsprotokollsicherungen durchgeführt wurden, die sich von der in Schritt 1 erstellten Sicherung des Protokollfragments unterscheiden, stellen Sie diese Sicherungen unter Angabe von WITH NORECOVERY in der offline geschalteten Datenbank auf dem ursprünglichen primären Server (Server A) wieder her. Die Datenbank wird auf das SQL Server 2008-Format aktualisiert, wenn die erste Protokollsicherung wiederhergestellt wird.

3. Stellen Sie die Sicherung des Protokollfragments Switchback_AW_20080315.trn für die ursprüngliche primäre Datenbank (auf Server A) unter Angabe von WITH RECOVERY wieder her, um die Datenbank online zu schalten.

4. Führen Sie einen Failover zur ursprünglichen primären Datenbank (auf Server A) aus, indem Sie Clients vom ursprünglichen primären Server zum online geschalteten sekundären Server umleiten.

Nachdem die Datenbank online geschaltet wurde, wird die ursprüngliche Protokollversandkonfiguration wieder aufgenommen.

So behalten Sie die ursprüngliche sekundäre Serverinstanz als neue primäre Serverinstanz bei

Richten Sie eine neue Protokollversandkonfiguration ein, in der die alte sekundäre Serverinstanz B als primärer Server und die alte primäre Serverinstanz A als neuer sekundärer Server fungiert. Beispiel:

Wichtig
Die alte Protokollversandkonfiguration sollte zu Beginn dieses Schritts vom ursprünglichen primären Server entfernt worden sein, bevor die manuelle Transaktionsprotokollsicherung durchgeführt wurde, mit der die Datenbank offline geschaltet wurde.

1. Um die Ausführung einer vollständigen Sicherung und Wiederherstellung der Datenbank auf dem neuen sekundären Server (Server A) zu vermeiden, wenden Sie die Protokollsicherungen der neuen primären Datenbank auf die neue sekundäre Datenbank an. In der Beispielkonfiguration werden hierzu die auf Server B erstellten Protokollsicherungen in der Datenbank auf Server A wiederhergestellt.

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

3. Stellen Sie die Protokollsicherungen auf der neuen sekundären Serverinstanz (Server A) unter Angabe von WITH NORECOVERY wieder her. Mit dem ersten Wiederherstellungsvorgang wird die Datenbank auf SQL Server 2008 aktualisiert.

4. Konfigurieren Sie den Protokollversand so, dass der frühere sekundäre Server (Server B) die primäre Serverinstanz bildet.

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

   So konfigurieren Sie den Protokollversand

   • Vorgehensweise: Aktivieren des Protokollversands (SQL Server Management Studio)

   • Vorgehensweise: Aktivieren des Protokollversands (Transact-SQL)

5. Führen Sie einen Failover für die Datenbank aus, indem Sie Clients vom ursprünglichen primären Server (Server A) auf den online geschalteten sekundären Server (Server B) durchführen.

   Wichtig
   Wenn Sie einen Failover auf eine neue primäre Datenbank durchführen, sollten Sie sicherstellen, dass die Metadaten mit den Metadaten der ursprünglichen primären Datenbank übereinstimmen. Weitere Informationen finden Sie unter Verwalten von Metadaten beim Bereitstellen einer Datenbank auf einer anderen Serverinstanz.

Überlegungen zur Aktualisierung mehrerer sekundärer Serverinstanzen

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

Aktualisieren Sie stets sämtliche sekundäre Serverinstanzen vor der primären Serverinstanz.

Aktualisieren mit Failover und Zurückwechseln zum ursprünglichen primären Server

Wenn die primäre Serverinstanz mit Failover aktualisiert wird, ist der Aktualisierungsvorgang komplizierter, wenn mehrere sekundäre Serverinstanzen vorhanden sind. Im folgenden Verfahren wird nach der Aktualisierung aller sekundären Server ein Failover für den primären Server auf eine der aktualisierten sekundären Datenbanken durchgeführt. Der ursprüngliche primäre Server wird aktualisiert, und für den Protokollversand wird ein Failover zurück zu diesem Server ausgeführt.

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

2. Erstellen Sie eine Sicherung des Endes der Protokolldatei (auf Server A) unter Angabe von WITH NORECOVERY, um eine Sicherung des Protokollfragments der primären Datenbank zu erhalten und die Datenbank offline zu schalten.

3. Schalten Sie auf dem sekundären Server, auf den das Failover durchgeführt werden soll (Server B), die sekundäre Datenbank online, indem Sie die Protokollsicherung unter Angabe von WITH RECOVERY wiederherstellen.

4. Lassen Sie auf dem anderen sekundären Server (Server C) die sekundäre Datenbank offline, indem Sie die Protokollsicherung unter Angabe von WITH NORECOVERY wiederherstellen.

   Hinweis
   Die Aufträge zum Kopieren und Wiederherstellen des Protokollversands werden auf den sekundären Servern ausgeführt, aber die Aufträge bewirken nichts, weil die neuen Protokollsicherungsdateien nicht in der Sicherungsfreigabe abgelegt werden.

5. Führen Sie einen Failover für die Datenbank aus, indem Sie Clients vom ursprünglichen primären Server (Server A) auf den online geschalteten sekundären Server (Server B) durchführen. Die online geschaltete Datenbank fungiert zwischenzeitlich als primärer Server, wodurch die Datenbank verfügbar bleibt, während die ursprüngliche primäre Serverinstanz aktualisiert wird.

6. Aktualisieren Sie den ursprünglichen primären Server (Server A).

7. Führen Sie für die Datenbank, auf die das Failover durchgeführt wurde – die zwischenzeitliche primäre Datenbank (auf Server B) – eine manuelle Sicherung des Transaktionsprotokolls unter Angabe von WITH NORECOVERY durch. Dadurch wird die Datenbank offline geschaltet.

8. Stellen Sie alle Transaktionsprotokollsicherungen, die Sie in der zwischenzeitlichen Datenbank (auf Server B) erstellt haben, in jeder anderen sekundären Datenbank (auf Server C) unter Angabe von WITH NORECOVERY wieder her. Dadurch kann der Protokollversand von der ursprünglichen primären Datenbank nach deren Aktualisierung fortgesetzt werden, ohne dass in jeder sekundären Datenbank eine komplette Datenbankwiederherstellung durchgeführt werden muss.

9. Stellen Sie das Transaktionsprotokoll vom zwischenzeitlichen primären Server (Server B) unter Angabe von WITH RECOVERY in der ursprünglichen primären Datenbank (auf Server A) wieder her.

Erneutes Bereitstellen des Protokollversands

Wenn Sie die Protokollversandkonfiguration nicht mit einem der oben beschriebenen Verfahren migrieren möchten, können Sie den Protokollversand neu bereitstellen, indem Sie die sekundäre Datenbank mit einer vollständigen Sicherung und Wiederherstellung der primären Datenbank neu initialisieren. Diese Option bietet sich u. U. an, wenn es um eine kleine Datenbank geht oder wenn eine hohe Verfügbarkeit während des Aktualisierungsvorgangs nicht wichtig ist.

Weitere Informationen zum Aktivieren des Protokollversands mithilfe von SQL Server Management Studio finden Sie unter Vorgehensweise: Aktivieren des Protokollversands (SQL Server Management Studio).

Weitere Informationen zum Aktivieren des Protokollversands mithilfe von Transact-SQL finden Sie unter Vorgehensweise: Aktivieren des Protokollversands (Transact-SQL).

Siehe auch

Konzepte

Verwenden von Transaktionsprotokollsicherungen

Protokollversandtabellen und gespeicherte Prozeduren

Migrieren einer Protokollversandkonfiguration aus SQL Server 2000 nach SQL Server 2008

Andere Ressourcen

Protokollversandverwaltung

Änderungsverlauf

Aktualisierter Inhalt
Der Abschnitt "Aktualisieren der sekundären Serverinstanz" wurde aktualisiert, um darauf hinzuweisen, dass die RESTORE WITH STANDBY-Option für Datenbanken, die eine Aktualisierung erfordern, nicht unterstützt wird.