Freigeben über


Migrieren einer Protokollversandkonfiguration für SQL Server 2000 nach SQL Server 2005

Es ist nicht möglich, eine Protokollversandkonfiguration direkt von SQL Server 2000 auf SQL Server 2005 zu aktualisieren. Der Datenbank-Wartungsplanungs-Assistent, der bei SQL Server 2000 ein wichtiger Bestandteil des Protokollversands war, wird bei der Protokollversandkonfiguration von SQL Server 2005 nicht verwendet. Daher funktioniert der Protokollversand nicht mehr, wenn Sie einen Server auf SQL Server 2005 aktualisieren.

Sie können eine Protokollversandkonfiguration von SQL Server 2000 migrieren und dabei die Synchronisierung zwischen der primären und der sekundären Datenbank aufrechterhalten. In diesem Thema werden zwei mögliche Methoden beschrieben:

  • Über die Migration mit Failover können Sie die Verfügbarkeit der Datenbank aufrechterhalten, während Sie die einzelnen Server in der Protokollversandkonfiguration aktualisieren. Für diesen Vorgang muss die SQL Server 2000-Protokollversandkonfiguration so konfiguriert sein, dass Failover zugelassen sind.
  • Die Migration ohne Failover ist ein einfacherer Vorgang, bei dem kein Failover auf den sekundären Server erforderlich ist. Bei diesem Vorgang steht Ihre Protokollversanddatenbank nicht zur Verfügung, während Sie den primären Server auf SQL Server 2005 aktualisieren.

Wenn die Migration der Protokollversandkonfiguration auf SQL Server 2005 abgeschlossen ist, können Sie die Tabellen und die Aufträge des SQL Server-Agents, die über den Protokollversand von SQL Server 2000 erstellt wurden, löschen.

Einschränkungen

Nachdem eine SQL Server 2000-Protokollversandkonfiguration zu SQL Server 2005 migriert wurde, können sekundäre Datenbanken nicht in den Standbymodus versetzt werden.

Migration mit Failover

Um eine hohe Verfügbarkeit der Protokollversandkonfiguration von SQL Server 2000 sicherzustellen, können Sie die Datenbank mithilfe der Failoverfunktionen des Protokollversands online halten.

Bei einer Migration mit Failover wird die primäre Serverinstanz temporär in der ursprünglichen SQL Server-Version erhalten, während die sekundäre Serverinstanz aktualisiert wird. Beim Aktualisieren einer Serverinstanz werden nur Online-Datenbanken aktualisiert. Offlinedatenbanken, wie eine sekundäre Protokollversanddatenbank, bleiben in der ursprünglichen Version von SQL Server erhalten. Solange eine Datenbank offline ist, können Protokollsicherungen der ursprünglichen Version von SQL Server wiederhergestellt werden. Aus diesem Grund kann der Protokollversand so lange Protokollsicherungen der primären Datenbank in der sekundären Datenbank wiederherstellten, bis diese durch ein Failover als neue primäre Datenbank online gebracht wird.

Um den Vorgang erfolgreich abzuschließen, muss der Protokollversand bei SQL Server 2000 so konfiguriert sein, dass ein Failover zwischen der primären und der sekundären Datenbank zulässig ist. Der Übersichtlichkeit halber wird die Instanz des primären Servers für den SQL Server 2000-Protokollversand als Server A und die Instanz des sekundären Servers für den SQL Server 2000-Protokollversand als Server B bezeichnet.

  1. Aktualisieren von Server B auf SQL Server 2005. Bei der Aktualisierung von Server B bleibt die Protokollversanddatenbank als SQL Server 2000-Datenbank bestehen, da sie offline ist. Diese Datenbank wird im nächsten Schritt aktualisiert.
    ms188297.note(de-de,SQL.90).gifHinweis:
    An diesem Punkt können Benutzer weiterhin auf die primäre Datenbank auf Server A zugreifen.
  2. Failover von Server A auf Server B, indem alle erforderlichen Transaktionsprotokolle von der primären Datenbank auf Server A angewendet werden und die primäre Datenbank über NORECOVERY gesichert wird. Wenn Sie die sekundäre Datenbank auf Server B online schalten, wird sie automatisch auf eine SQL Server 2005-Datenbank aktualisiert. Die Datenbankaktualisierung wird vollständig protokolliert.
    ms188297.note(de-de,SQL.90).gifHinweis:
    Nach der Aktualisierung ist die Protokollversanddatenbank auf Server B für Benutzer verfügbar. Bevor der SQL Server 2005-Protokollversand auf Server B konfiguriert ist, können keine Protokollsicherungen von Server B auf die Datenbank auf Server A angewendet werden.
  3. Aktualisieren von Server A auf SQL Server 2005. Die Protokollversanddatenbank bleibt als SQL Server 2000-Datenbank erhalten, weil sie offline ist.
  4. Konfigurieren Sie auf Server B den Protokollversand für SQL Server 2005, sodass Server B der primäre Server und Server A der sekundäre Server ist. Wenn Sie mit dem Versenden von Transaktionsprotokollen an Server A beginnen, wird die Protokollversanddatenbank auf Server A beim Anwenden der ersten Protokollsicherung auf eine SQL Server 2005-Datenbank aktualisiert.
    Beim Konfigurieren des Protokollversands auf Server B müssen Sie im Dialogfeld Einstellungen für die sekundäre Datenbank auf der Registerkarte Sekundäre Datenbank initialisieren die Option Nein, die sekundäre Datenbank ist initialisiert festlegen. Weitere Informationen finden Sie unter Vorgehensweise: Aktivieren des Protokollversands (SQL Server Management Studio).
  5. Wenn Sie Server A optional wieder als primären Server festlegen möchten, müssen Sie ein Failover auf Server A ausführen. Weitere Informationen finden Sie unter Ändern der Rollen zwischen primärem und sekundärem Server.

Migration ohne Failover

Sie können die Protokollversandkonfiguration von SQL Server 2000 auch ohne Failover auf SQL Server 2005 migrieren. Mit diesem Verfahren können Sie beide Serverinstanzen auf einfache Weise in der Protokollversandkonfiguration aktualisieren. Die primäre Datenbank ist jedoch nicht verfügbar, während Sie die primäre Serverinstanz auf SQL Server 2005 aktualisieren.

  1. Aktualisieren Sie die sekundäre Serverinstanz auf SQL Server 2005. Bei der Aktualisierung der sekundären Serverinstanz bleibt die Protokollversanddatenbank als SQL Server 2000-Datenbank bestehen, da sie offline ist.
  2. Aktualisieren Sie die primäre Serverinstanz auf SQL Server 2005. Die primäre Datenbank ist nicht verfügbar, während die Aktualisierung ausgeführt wird.
  3. Konfigurieren Sie den Protokollversand von der primären Serverinstanz auf die sekundäre Serverinstanz. Sie müssen die Option Nein, die sekundäre Datenbank ist initialisiert auf der Registerkarte Sekundäre Datenbank initialisieren im Dialogfeld Einstellungen für die sekundäre Datenbank festlegen. Weitere Informationen finden Sie unter Vorgehensweise: Aktivieren des Protokollversands (SQL Server Management Studio).
    ms188297.note(de-de,SQL.90).gifWichtig:
    Geben Sie dieselbe Sicherungsfreigabe an, die Sie bei der Protokollversandkonfiguration für SQL Server 2000 verwendet haben. Dadurch wird sichergestellt, dass alle Protokollsicherungen auf die sekundäre Datenbank angewendet werden, wenn Sie den Protokollversand für SQL Server 2005 aktivieren.
    Da es sich bei der Datenbankaktualisierung um einen vollständig protokollierten Vorgang handelt, wird die sekundäre Datenbank auf eine SQL Server 2005-Datenbank aktualisiert, wenn Sie mit dem Versenden von Protokollen an die sekundäre Serverinstanz beginnen.

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).

Entfernen von Tabellen und Aufträgen beim Protokollversand für SQL Server 2000

Nach dem Bereitstellen einer neuen Protokollversandkonfiguration können Sie ggf. noch auf dem Computer vorhandene Protokollversandtabellen und -aufträge für SQL Server 2000 entfernen.

SQL Server 2005 verwendet keine der Protokollversandtabellen, die von SQL Server 2000 benötigt wurden. Daher können Sie diese Tabellen löschen, nachdem Sie den Server auf SQL Server 2005 aktualisiert haben:

  • log_shipping_databases
  • log_shipping_monitor
  • log_shipping_plan_databases
  • log_shipping_plan_history
  • log_shipping_plans
  • log_shipping_primaries
  • log_shipping_secondaries

Sie können sämtliche Protokollversandaufträge des SQL Server-Agents löschen, die von SQL Server 2000 erstellt wurden.

Siehe auch

Konzepte

Protokollversandtabellen und gespeicherte Prozeduren

Andere Ressourcen

Protokollversand

Hilfe und Informationen

Informationsquellen für SQL Server 2005