Teilen über

Wählen einer Upgrademethode für die Datenbank-Engine

  • Artikel

Gilt für: SQL Server - nur Windows

Es gibt verschiedene zu prüfende Ansätze beim Planen des Upgrades der Datenbank-Engine von einer früheren Version von SQL Server, um Ausfallzeiten und Risiken zu minimieren. Sie können ein direktes Upgrade ausführen, zu einer neuen Installation migrieren oder ein paralleles Upgrade vornehmen. Das folgende Diagramm hilft Ihnen, zwischen diesen Ansätzen auszuwählen. Jeder Ansatz im Diagramm wird zudem im Artikel erläutert. Informationen zu den Entscheidungskriterien im Diagramm finden Sie auch unter Planen und Testen des Upgradeplans für die Datenbank-Engine.

Diagramm der Entscheidungsstruktur der Upgrademethode für die Datenbank-Engine.

Herunterladen

  • Laden Sie SQL Server aus dem Evaluation Center herunter.

  • Sie haben ein Azure-Konto? Wechseln Sie anschließend zum Azure Marketplace, um eine VM zu starten, auf der SQL Server Developer Edition bereits installiert ist.

Azure SQL-Upgradeoptionen

Sie können auch ein Upgrade Ihrer Azure SQL-Datenbank oder Azure SQL Managed Instance erwägen oder Ihre SQL Server-Umgebung als Teil Ihres Upgradeplans virtualisieren. Weitere Informationen zu diesen Optionen finden Sie in den folgenden Themen:

Direktes Upgrade

Bei diesem Ansatz aktualisiert das SQL Server-Setup-Programm die vorhandene SQL Server-Installation durch Ersetzen der vorhandenen SQL Server-Bits durch die neuen SQL Server-Bits und aktualisiert anschließend alle System- und Benutzerdatenbanken.

Der Ansatz mit direktem Upgrade ist am einfachsten, bringt gewisse Ausfallzeiten mit sich, erfordert nötigenfalls ein längeres Fallback und wird nicht für alle Szenarien unterstützt. Weitere Informationen zu unterstützten und nicht unterstützten direkten Aktualisierungsszenarien finden Sie unter Unterstützte Versions- und Editionsupgrades.

Dieser Ansatz wird häufig in den folgenden Szenarien verwendet:

  • Eine Entwicklungsumgebung ohne Konfiguration mit hoher Verfügbarkeit.

  • Eine nicht unternehmenswichtige Produktionsumgebung mit Toleranz für Ausfallzeiten, die auf aktueller Hardware und Software ausgeführt wird. Die Länge der Ausfallzeit ist abhängig von der Größe Ihrer Datenbank und der Geschwindigkeit des E/A-Subsystems. Wenn während des Upgrades von SQL Server 2014 (12.x) speicheroptimierte Tabellen verwendet werden, erfordert das Upgrade zusätzliche Zeit. Weitere Informationen finden Sie unter Planen und Testen des Upgradeplans für die Datenbank-Engine.

Auf hoher Ebene sind die Schritte, die für ein direktes Upgrade der Datenbank-Engine erforderlich sind, wie folgt:

Diagramm eines nicht hoch verfügbaren direkten Upgrades der Datenbank-Engine.

Ausführliche Schritte finden Sie unter Upgrade von SQL Server mithilfe des Installations-Assistenten (Setup).

Überlegungen

Das SQL Server-Setupprogramm beendet und startet die SQL Server-Instanz im Rahmen der Überprüfungen vor dem Upgrade neu.

Wenn Sie auf SQL Serveraktualisieren, wird die frühere SQL Server -Instanz überschrieben und ist auf dem Computer folglich nicht mehr vorhanden. Sichern Sie vor dem Upgrade die SQL Server -Datenbanken und alle anderen der früheren SQL Server -Instanz zugeordneten Objekte.

Migrieren zu einer neuen Installation

Bei diesem Ansatz behalten Sie die aktuelle Umgebung bei, während Sie eine neue SQL Server -Umgebung einrichten. Dies erfolgt häufig auf neuer Hardware und mit einer neuen Version des Betriebssystems. Nach Installation von SQL Server in der neuen Umgebung führen Sie mehrere Schritte aus, um die neue Umgebung so vorzubereiten, dass eine Migration der vorhandenen Benutzerdatenbanken aus der vorhandenen in die neue Umgebung bei minimierter Ausfallzeit erfolgen kann. Bei diesen Schritten wird Folgendes migriert:

  • Systemobjekte: Einige Anwendungen sind von Informationen, Entitäten und/oder Objekten abhängig, die sich außerhalb des Bereichs einer einzelnen Benutzerdatenbank befinden. Normalerweise weist eine Anwendung Abhängigkeiten von den Datenbanken master und msdb sowie von der Benutzerdatenbank auf. Alle Daten, die außerhalb einer Benutzerdatenbank gespeichert werden und für die richtige Funktionsweise dieser Datenbank erforderlich sind, müssen auf der Zielserverinstanz bereitgestellt werden. Beispielsweise werden die Anmeldungen für eine Anwendung als Metadaten in der master-Datenbank gespeichert und müssen auf dem Zielserver neu erstellt werden. Wenn ein Anwendungs- oder Datenbankwartungsplan von Aufträgen des SQL Server-Agents abhängig ist, deren Metadaten in der msdb-Datenbank gespeichert sind, müssen Sie diese Aufträge auf der Zielserverinstanz neu erstellen. Analog dazu werden die Metadaten für einen Trigger auf Serverebene in der master-Datenbank gespeichert.

    Wenn Sie die Datenbank für eine Anwendung in eine andere Serverinstanz verschieben, müssen Sie alle Metadaten der abhängigen Entitäten und Objekte in den Datenbanken master und msdb der Zielserverinstanz neu erstellen. Wenn für eine Datenbankanwendung beispielsweise Trigger auf Serverebene verwendet werden, genügt es nicht, die Datenbank im neuen System lediglich anzufügen oder wiederherzustellen. Die Datenbank funktioniert nur dann wie erwartet, wenn Sie die Metadaten für diese Trigger in der master-Datenbank manuell neu erstellen. Ausführliche Informationen finden Sie unter Verwalten von Metadaten beim Bereitstellen einer Datenbank auf einer anderen Serverinstanz (SQL Server).

  • In der msdb-Datenbank gespeicherte Integration Services-Pakete: Wenn Sie Pakete in der msdb-Datenbank speichern, müssen Sie diese Pakete entweder mithilfe des Hilfsprogramms dtutil als Skripts extrahieren oder sie auf dem neuen Server erneut bereitstellen. Vor der Verwendung der Pakete auf dem neuen Server müssen Sie die Pakete auf SQL Serveraktualisieren. Weitere Informationen finden Sie unter Upgrade Integration Services Packages.

  • Verschlüsselungsschlüssel für Reporting Services: Das Erstellen einer Sicherungskopie des symmetrischen Schlüssels, der zum Verschlüsseln sensibler Informationen verwendet wird, ist ein wichtiger Bestandteil der Berichtsserverkonfiguration. Eine Sicherungskopie des Schlüssels ist für viele Routinevorgänge erforderlich und ermöglicht Ihnen das Wiederverwenden einer vorhandenen Berichtsserver-Datenbank in einer neuen Installation. Weitere Informationen finden Sie unter Sichern und Wiederherstellen von Reporting Services-Verschlüsselungsschlüsseln und Upgrade und Migrate Reporting Services

Sobald die neue SQL Server-Umgebung über die gleichen Systemobjekte wie die vorhandene Umgebung verfügt, können Sie die Benutzerdatenbanken aus dem vorhandenen System in die SQL Server-Instanz auf eine Weise migrieren, die Ausfallzeiten für das vorhandene System minimiert. Sie erreichen die Datenbankmigration entweder mittels Sicherung und Wiederherstellung oder indem Sie bei einer SAN-Umgebung die LUNs auf neue Ziele verweisen. Die Schritte für beide Methoden sind in den folgenden Diagrammen angegeben.

Achtung

Die Länge der Ausfallzeit ist abhängig von der Größe Ihrer Datenbank und der Geschwindigkeit des E/A-Subsystems. Wenn während des Upgrades von SQL Server 2014 (12.x) speicheroptimierte Tabellen verwendet werden, erfordert das Upgrade zusätzliche Zeit. Weitere Informationen finden Sie unter Planen und Testen des Upgradeplans für die Datenbank-Engine.

Nach Migration der Benutzerdatenbanken verweisen Sie neue Benutzer mithilfe einer mehrerer Methoden (z. B. Umbenennen des Servers, Verwenden eines DNS-Eintrags, Ändern von Verbindungszeichenfolgen) auf die neue SQL Server-Instanz. Durch diesen neuen Installationsansatz werden Risiken und Ausfallzeiten im Vergleich mit einem direkten Upgrade reduziert und Upgrades von Hardware und Betriebssystem mit dem Upgrade auf SQL Server erleichtert.

Hinweis

Falls Sie eine Lösung für Hochverfügbarkeit oder eine andere Umgebung mit mehreren SQL Server-Instanzen haben, fahren Sie mit dem parallelen Upgradefort. Wenn keine Lösung für Hochverfügbarkeit vorhanden ist, können Sie entweder vorübergehend die Datenbankspiegelung konfigurieren, um Ausfallzeiten zu minimieren und dieses Upgrade zu vereinfachen, oder die Chance wahrnehmen, eine Always On-Verfügbarkeitsgruppe als dauerhafte Lösung für Hochverfügbarkeit zu konfigurieren.

Beispielsweise können Sie diesen Ansatz befolgen, um Folgendes zu aktualisieren:

  • Eine Installation von SQL Server unter einem nicht unterstützten Betriebssystem.
  • Eine x86-Installation (32-Bit) von SQL Server, da SQL Server 2016 (13.x) und höher keine x86-Installationen unterstützen.
  • SQL Server auf neue Hardware und/oder eine neue Version des Betriebssystems.
  • SQL Server in Verbindung mit einer Serverkonsolidierung.
  • SQL Server 2005 (9.x), da SQL Server 2016 (13.x) und höher kein direktes Upgrade von SQL Server 2005 (9.x) unterstützt. Weitere Informationen finden Sie unter Aktualisieren von einer älteren Version von SQL Server.

Die erforderlichen Schritte für ein Upgrade auf eine neue Installation hängen zum Teil davon ab, ob Sie zugeordneten oder SAN-Speicher verwenden.

  • Umgebung mit zugeordnetem Speicher: Wenn Sie eine SQL Server-Umgebung mit zugeordnetem Speicher haben, finden Sie im folgenden Diagramm und unter den darin enthaltenen Links die Schritte, die für ein Upgrade auf eine neue Installation der Datenbank-Engine erforderlich sind.

    Diagramm einer neuen Installationsupgrademethode mithilfe einer Sicherung und der Wiederherstellung für einen angeschlossenen Speicher.

  • SAN-Speicherumgebung: Wenn Sie eine SQL Server-Umgebung mit SAN-Speicher haben, finden Sie im folgenden Diagramm und unter den darin enthaltenen Links die Schritte, die für ein Upgrade auf eine neue Installation der Datenbank-Engine erforderlich sind.

    Diagramm einer neuen Installationsupgrademethode mithilfe von Trennen und Anfügen für den SAN-Speicher.

parallelen Upgrade

Ein paralleles Update ist in Umgebungen mit SQL Server-Lösungen mit mehreren SQL Server -Instanzen erforderlich, die in einer bestimmten Reihenfolge aktualisiert werden müssen, um die Betriebszeit zu maximieren, Risiken zu minimieren und Funktionalität beizubehalten. Ein paralleles Upgrade ist im Wesentlichen das Upgrade mehrerer SQL Server-Instanzen in einer bestimmten Reihenfolge. Dabei erfolgt entweder ein direktes Upgrade jeder vorhandenen SQL Server-Instanz oder ein Upgrade auf eine Neuinstallation, um die Aktualisierung von Hardware und/oder des Betriebssystems im Rahmen des Upgradeprojekts zu erleichtern. Es gibt mehrere Szenarien, in denen der parallele Upgradeansatz befolgt werden muss. Diese Szenarien sind in den folgenden Artikeln dokumentiert: