SQL Server Upgrade auf 2022

Einleitung

Software unterliegt ständigen Aktualisierungs-, Erweiterungs- und Erneuerungsprozessen. Hierbei gibt es zwei wesentliche Phasen, nämlich den Mainstream Support in dem die jeweilige Software uneingeschränkt unterstützt wird und in regelmäßigem Abstand Software- und Sicherheitspatches herausgegeben werden.

In der zweiten Phase, dem Extended Support, erhält man nach wie vor Unterstützung vom Hersteller, diese aber sehr eingeschränkt. Änderungen der Software werden lediglich im Fall von Sicherheitsupdates bereitgestellt.

Ist auch die Phase des Extended Support verstrichen, so werden im Rahmen des Extended Security Update Programms und dem Kauf einer Software Assurance mit jährlich steigenden Gebühren drei weitere Jahre Patches zur Verfügung gestellt, die sich allerdings nur auf grobe Sicherheitslücken beziehen.

Ausgangspunkt für dieses Dokument ist die Tatsache, dass SQL Server 2014 SP3 im kommenden Jahr, genauer am 09.07.2024, aus dem Extended Support läuft und damit ab diesem Zeitpunkt zusätzliche Gebühren für die erforderliche Software Assurance bei gleichzeitig reduzierter Sicherheit anfallen.

In diesem Artikel werden Migrationsszenarien zu der neuesten SQL Server Version (MSSQL 2022) für unterschiedliche Quell- und Zielumgebungen dargestellt, dies insbesondere im Hinblick auf On-Premises (“On-Prem”) und die Cloud, und hier speziell Azure.

Vorarbeiten

Im Vorfeld eines geplanten Upgrades müssen die folgenden Checks bzw. Aktionen durchgeführt werden:

• Vom Applikationshersteller muss das OK zu der Migration eingeholt werden, er muss also bestätigen, dass die Applikation die Zielversion der SQL Server Instanz und ggf. einer neuen Umgebung unterstützt
• Überprüfung der Hard- und Software der Zielumgebung bezüglich Kompatibilitäten
• Sicherstellen, dass in der Instanz Windows Authentication aktiviert ist und dass der SQL Server Agent Dienst-Account Mitglied der SQL Server Gruppe sysadmin ist
• Das Betriebssystem des Zielservers muss von der SQL Server Zielversion unterstützt sein
• Es muss sichergestellt sein, dass es keine ausstehenden Upgrades gibt. Diese würden ein Upgrade blockieren
• Aus Gründen des Recovery im Problemfall sicherstellen, dass alle DBs im Full Recovery Mode betrieben werden
• Erstellen von DB- und Transaktionslog Backups
• Ausschalten des automatischen Failover
• Sicherstellen, dass die Kompatibilitätsstufe der Datenbanken in der zu migrierenden Instanz mindestens den Wert 90 hat. Datenbanken mit Kompatibilitätsstufe 90 werden automatisch durch das Upgrade auf Stufe 100 gebracht, alle Datenbanken mit Stufe 100 oder höher behalten ihre Stufe bei.

Betriebssystem

Wie bereits in einem der Punkte des Abschnitts “Vorarbeiten” aufgeführt, muss das Betriebssystem die Zielversion des SQL Servers unterstützen. Im Rahmen der Erstellung dieses Dokumentes war die Ausgangssituation eine SQL Server 2014 Instanz auf Windows Server 2012 R2. Dieses Betriebssystem kann nicht direkt auf die aktuelle Windows Server Version 2022 aktualisiert werden. In diesem Fall muss ein mehrstufiges wechselseitiges Upgrade von SQL Server und Betriebssystem durchgeführt werden.

Durchführung von Tests

Alle hier vorgestellten Szenarien müssen unbedingt im Vorfeld der Migration ausgiebig in einer von der Produktion getrennten Testumgebung getestet werden. Hierbei muss nicht nur das eigentliche Upgrade, sondern auch das Zusammenspiel mit der Applikation berücksichtigt werden. Im Zusammenhang mit den Tests muss auch die Kompatibilitätsstufe der Datenbanken der Instanz angehoben werden, damit man von den vielen seit MSSQL 2014 eingeführten neuen Features, die insbesondere auch die Performance betreffen, profitieren kann

In Place Upgrade - Der Trivialfall

Der einfachste Fall, das Upgrade durchzuführen, ist das In Place Upgrade: Im Rahmen der Software-Installation wird die bestehende Instanz der alten Version in eine Instanz der neuen Version überführt. Dies bedeutet insbesondere auch, dass die IP-Adresse, der Instanzname und der Port unverändert bleiben. Hierbei werden durch den Installer folgende Aktionen durchgeführt:

• Herunterfahren des SQL Server Agents
• Installation der neuen Software
• Herunterfahren der zu aktualisierenden SQL Server Instanz
• Umkonfigurieren der Dienste und Starten der SQL Server Instanz mit der neuen Software
• Starten des SQL Server Agents
• Das In Place Upgrade wird mit der von Microsoft gelieferten Software durchgeführt. In der folgenden schematischen Abbildung wird “SQL Server Installer for Developer Edition” verwendet.

Das In Place Upgrade erfordert damit nur eine kurze Offline-Zeit die weitestgehend unabhängig von der Größe und Anzahl der in der Instanz betriebenen Datenbanken und Datensätze ist.

On-Prem Migration

Die On-Prem Migration betrifft, im Gegensatz zur Cloud, eine Migration innerhalb der eigenen Umgebung / des eigenen Rechenzentrums.

In der Regel gehen Software Aktualisierungen mit der Einführung neuer und besserer Hardware einher: Gerade bei dem hier vorgestellten Fall der Aktualisierung von MSSQL 2014 nach MSSQL 2022 ist davon auszugehen, dass seit dem initialen Setup bereits ca. acht Jahre vergangen sind, die Hardware längst abgeschrieben ist und aktuelle Systeme weitaus leistungsfähiger sind. In größeren Umgebungen ist auch davon auszugehen, dass viele Systeme bereits auf neuerer Hardware oder virtualisiert betrieben werden und im Rahmen des Upgrades eine Konsolidierung der IT Landschaft erreicht werden soll.

In dem hier betrachteten Szenario wird die alte MSSQL also als neue Version in eine neue Umgebung innerhalb der IT-Landschaft des Nutzers gebracht. Hierbei sind folgende Fragen zu klären bzw. Punkte zu berücksichtigen:

• Verwendet die Instanz eine oder mehrere der folgenden Komponenten? Gibt es Einschränkungen beim Upgrade? Welche und sind diese relevant?
• Reporting Services
• Integration Services
• Master Data Services
• Data Quality Services
• Replikationsmechanismen
• Spiegelung
• Transaktionslog-Shipping
• Failover-Cluster
• AlwaysOn Verfügbarkeitsgruppen
• Eine weitere zu klärende Frage ist, ob die o.a. Komponenten weiterhin benötigt werden.

Verwendung des Data Migration Assistant

Zur Unterstützung der Migration in eine neue Umgebung (und eine neue Version) bietet Microsoft ein Tool an, den Data Migration Assistant (DMA), mit dem die Migration erheblich erleichtert wird. Mit dem DMA können wahlweise die Database Engine oder die Integration Services aktualisiert werden.

Eine Gegenüberstellung der möglichen Quellen und Ziele zeigt die folgende Tabelle:

QuelleSQL ServerSQL ServerSQL ServerSQL ServerAWS RDS for SQL ServerAWS RDS for SQL ServerAWS RDS for SQL ServerAWS RDS for SQL ServerSQL ServerSQL Server

Im Vorfeld der Migration kann mit dem DMA ein Assessment durchgeführt werden, aus dem eventuelle Probleme bei der Migration hervorgehen. Werden hierbei keine Probleme festgestellt, kann mit der Migration begonnen werden. Bei einem konkreten Test mit diesem Tool erhielten wir eine leere Problemliste aus dem Assessment, bei der Durchführung der Migration erfolgte jedoch ein Abbruch mit einer Fehlermeldung bezüglich eines nicht existierenden Logfiles. Dieser bekannte Bug konnte durch Neustart der SQL Server Instanz umgangen werden. Obwohl der DMA die Migration inkl. der Übernahme der Logins der Quell- in die Ziel-Instanz automatisiert, ist dieser Weg für eine Migration, in der höchstmögliche Verfügbarkeit benötigt wird, ungeeignet, weil der DMA i.W. die Datenbanken aus der Quellinstanz exportiert und in die Zielinstanz importiert. Insbesondere bei sehr großen Datenbanken ist hierdurch eine entsprechende Nichtverfügbarkeit einzuplanen.

Upgrade von Instanzen mit Always On Verfügbarkeitsgruppen

Die durch die Verwendung von Always On Verfügbarkeitsgruppen erreichte Verfügbarkeit von SQL Server Datenbanken ist auch im Fall eines Upgrades von 2014 nach 2022 gegeben. Zu beachten ist jedoch, dass ohne temporäres Hinzufügen eines weiteren Replikats während des Upgrade-Verlaufs die zuvor konfigurierte Hochverfügbarkeit reduziert ist. Das Upgrade sollte also zügig und für alle verwendeten Instanzen durchgeführt werden um die gewünschte Hochverfügbarkeit wiederzuerlangen. Beispiel: Instanz A wird als primäre und Instanz B als sekundäre Instanz betrieben. Nachdem Instanz B aktualisiert wurde, ist die Replikation von Instanz B nach Instanz A nicht mehr möglich. Bevor nicht auch Instanz A aktualisiert wurde, ist ein Ausfall von Instanz B nicht durch eine Umschaltmöglichkeit nach A abgesichert.

Unabhängig vom Betrieb der Instanzen On-Prem oder in der Cloud ist die Vorgehensweise beim Upgrade die folgende, wobei initiale Backups und Überprüfung der Synchronisierung während der folgenden Schritte vorausgesetzt werden:

1. Zu Beginn muss verhindert werden, dass während des Upgrades ein unerwünschter Failover zu einer anderen synchronen Replika auftritt.
2. Anschließend werden, sofern vorhanden, asynchrone sekundäre Replikas aktualisiert.
3. Im nächsten Schritt erfolgt die Aktualisierung für synchrone Replikas die remote betrieben werden.
4. Danach werden synchrone lokale Replikas aktualisiert.
5. Bevor nun die primäre(n) Verfügbarkeitsgruppen(n) aktualisiert werden, muss/müssen diese per manuellem Failover auf eine lokale synchrone Replika umgeschaltet werden. Diese liegt nun, entsprechend der hier dargestellten Vorgehensweise, in der aktualisierten Version vor.
6. Im letzten Schritt wird dann die ursprünglich primäre Replika aktualisiert. Bei Bedarf bzw. entsprechender Anforderung und wenn alle Instanzen wieder sauber laufen, kann ein erneuter Failover auf die ursprünglich primäre Replika erfolgen.

Werden auf einem Server Verfügbarkeitsgruppen unterschiedlicher Versionen verwendet, kann es im Zusammenhang mit der Installation einer neueren SQL Server Version zu einem kurzzeitigen Ausfall der Verfügbarkeitsgruppen der älteren Versionen kommen. Dies wird durch die damit einhergehende Aktualisierung des SQL Server High Availability Moduls verursacht. In einem solchen Fall muss die neue Version also in einem Wartungsfenster installiert werden, um unerwünschte Ausfälle zu vermeiden.

Always on Betrieb mit Replikation in die Cloud

Die im Kapitel “Upgrade von Instanzen mit Always On Verfügbarkeitsgruppen“ dargestellte Vorgehensweise lässt sich auch zur Online-Migration in die Cloud verwenden, dies setzt im Fall von SQL Server 2014 allerdings zwingend eine Enterprise Edition voraus, weil die Standard Edition die Always On Eigenschaft nicht unterstützt. Hier wird für die On-Prem Instanz zunächst eine Instanz in der Cloud mit gleicher Version angelegt. Anschließend wird die Always On Verfügbarkeitsgruppe mit Ziel in der neu angelegten Instanz eingerichtet. Im nächsten Schritt erfolgt das Upgrade in der Cloud wie in dem oben erwähnten Kapitel beschrieben. Anschließend wird/werden in der Cloud je nach Verfügbarkeitsanforderung eine oder mehrere weitere Replica eingerichtet, um nach dem Umschalten weiterhin Hochverfügbarkeit zu haben. Sobald die Zielumgebung in Azure vollständig eingerichtet ist und die Synchronisation den Stand der primären On-Prem Instanz erreicht hat, erfolgt der Failover in die Cloud und die Umschaltung der Applikation auf die primäre Azure Instanz. Die ursprüngliche primäre On-Prem Instanz kann wegen der niedrigeren Version nicht mehr synchronisiert werden und kann damit aus der Verfügbarkeitsgruppe entfernt werden.

Migration in eine Azure SQL Instanz

Azure SQL Datenbank ist wie Azure Managed Instance ein Platform-as-a-Service (PaaS) Dienst von Microsoft Azure zum Betrieb einer SQL Server Datenbank in der Cloud. Die detaillierten Unterschiede zwischen Azure SQL und Azure Managed Instance sind unter Unterschiede Managed Instance - Azure SQL (englisch) bzw. Unterschiede Managed Instance - Azure SQL (deutsch) beschrieben.

Im Internet existieren einige Seiten, auf denen zunächst der Begriff “Online Migration” verwendet wird, auf denen aber letztendlich nur eine Offline-Migration beschrieben wird. Auch auf der folgenden Seite Migrate databases by using the Azure SQL Migration extension for Azure Date Studio , auf der es um tool-gestützte Migrationen nach Azure geht, existiert in der Tabelle, in der die verschiedenen Szenarien dargestellt sind, für die Zeile “SQL Server to Azure SQL Database“ nur ein Link für eine Offline Migration. Um sicherzugehen, ob eine entsprechende Unterstützung durch Microsoft-Tools existiert, wurde eine Anfrage bei Microsoft erstellt, aus der als einzige Lösung eine Transaktionsreplikation hervorging. Dem entsprechend beschreiben wir hier diese Methode:

Transaktionsreplikation

Die Verwendung von Replikation ist ein gängiges und altbewährtes Mittel, um Daten zwischen Datenbanken zu übertragen. Damit kann dieses Verfahren auch für ältere MSSQL Versionen ab Version 2008 eingesetzt werden. Zur Erstellung dieses Dokumentes wurde SQL Server 2014 als Quelle verwendet. Zur Durchführung der hier betrachteten Migration von SQL Server nach Azure SQL kann nur eine Push-Replikation verwendet werden, da die Replikation auf der Azure SQL Ebene nicht verfügbar ist. Bei der Einrichtung der Replikation gibt es einige Vorbereitungen und Fallstricke die berücksichtigt werden müssen, diese werden in den folgenden Unterkapiteln behandelt.

Installation der Replikationskomponente

Sofern Sie zuvor in Ihrer Umgebung keine Replikation verwendet haben, ist diese vermutlich noch nicht in Ihrer SQL Server Installation vorhanden und muss nachinstalliert werden. Dieser Vorgang ist online möglich, erfordert also keinen Neustart der SQL Server Instanz.

Eine einfache Überprüfung der Verfügbarkeit dieser Komponente kann durch den folgenden Befehl in der master-Datenbank der Instanz erfolgen:

Mit SQL Server Management Studio 19.01 funktioniert’s nicht

Sofern Sie SQL Server Management Studio V. 19.01 verwenden, ist ein Update auf V. 19.02 erforderlich, denn V. 19.01 führt bereits in einer sehr frühen Phase zu einem Absturz beim Einrichten der Replikation. Die entsprechende Fehlermeldung ist

SQL User

Als Benutzer für den Replikationsprozess muss auf Quell- und Zielseite ein Benutzer mit SQL Server Authentifikation und Administrationsrechten eingerichtet sein / werden. Hierzu muss die Quellinstanz ggf. in den Mixed Mode gebracht werden, damit sie neben Windows Authentication auch SQL Server Authentication akzeptiert. Sofern Ihre Instanz noch nicht im Mixed Mode betrieben wird, erfordert die Umstellung einen Neustart der SQL Server Instanz. Die erforderliche Zeit ist zwar relativ kurz, muss aber bei der Anforderung von Hochverfügbarkeit berücksichtigt werden.

Einschränkungen bezüglich der Verwendung von Replikation

Die Replikation kann über den Wizard und alternativ auch über T-SQL eingerichtet werden. Hierbei gibt es aber einige Einschränkungen die berücksichtigt werden müssen. Auf einige dieser Einschränkungen wurde bereits weiter oben hingewiesen.

• Wie bereits erwähnt, können nur Push-Subscriptions nach Azure SQL verwendet werden
• Auf Azure SQL Seite existiert keinerlei Möglichkeit, replikationsspezifische Objekte (Provider, Subscriber) anzulegen, weder über das SQL Server Management Studio, noch im Azure Portal order über T-SQL in einer Azure-Session
• Für die Replikation muss zwingend SQL Server Authentication verwendet werden, hier ist evtl. ein Neustart der SQL Server Instanz erforderlich
• Tabellen, die repliziert werden sollen, müssen einen Primärschlüssel besitzen
• Da Azure SQL keinerlei Möglichkeit der Replikations-Administration bietet, müssen alle administrativen Tätigkeiten bzw. das Monitoring auf SQL Server Seite durchgeführt werden
• Sofern Sie statt des Wizards T-SQL und damit die Stored Procedure sp_addsubscription verwenden, darf hier als Parameter subscriber_type nur 0 (= SQL Server Subscriber) verwendet werden
• Azure SQL unterstützt keine bidirektionalen, sofortigen, aktualisierbaren oder Peer-zu-Peer-Replikationen

Einschränkungen bezüglich replizierbarer Objekte und Features

Die Benutzung der Replikation erfordert die Berücksichtigung einer größeren Anzahl von Einschränkungen die diese nicht unterstützt. Diese sind:

• Kopieren einer Dateigruppenzuordnung
• Kopieren von Tabellenpartitionierungsschemas
• Kopieren von Indexpartitionierungsschemas
• Kopieren von benutzerdefinierten Statistiken
• Kopieren von Standardbindungen
• Kopieren von Regelbindungen
• Kopieren von Volltextindizes
• Kopieren einer XML-XSD
• Kopieren von XML-Indizes
• Kopieren von Berechtigungen
• Kopieren von räumlichen Indizes
• Kopieren von gefilterten Indizes
• Kopieren von Datenkomprimierungsattributen
• Kopieren von Sparsespaltenattributen
• Konvertieren von filestream in MAX-Datentypen
• Konvertieren von hierarchyid in MAX-Datentypen
• Konvertieren von spatial in MAX-Datentypen
• Kopieren von erweiterten Eigenschafte

Agent

Der Replikations-Wizard richtet Datenbankjobs ein, die die Replikation der Daten vornehmen. In einigen Umgebungen kann es zu folgenden Fehlermeldungen kommen, die eine Datenübertragung verhindern. In diesem Fall erhalten Sie die folgenden Fehlermeldungen:

Dieses Fehlverhalten konnte auch durch Änderung einiger Job-Parameter nicht unterbunden werden. Ein Neustart des Agent-Dienstes führte hier schließlich zum Erfolg. Der Neustart des Agent-Dienstes beeinflusst nicht die Verfügbarkeit der Datenbank.

Replikations-Wizards

Die Einrichtung der Replikation kann entweder über T-SQL Skripte oder über zwei Wizards im SQL Server Management Studio durchgeführt werden. In den folgenden beiden Unterkapitel stellen wir die Einrichtung der Replikation über diese Wizards vor. Als Beispiel wurde die StackOverflow2013 Beispieldatenbank in der mittelgroßen Version (= 50 GB) verwendet. Im hier behandelten Fall (Push-Replikation) benötigen wir einen neuen Publisher (=”Veröffentlichung”) und einen Subscriber auf der On-Prem Instanz der die Quelldatenbank in die Zielumgebung repliziert. Für beide Komponenten existiert ein Konfigurations-Wizard.

Vor der Verwendung der Wizards sollte überprüft werden, ob die erweiterten Stored Procedures des SQL Server Agenten verfügbar sind. Ist dies nicht der Fall, so erhält man die folgende Fehlermeldung:

Eine Überprüfung bezüglich der Verfügbarkeit der Stored Procedures kann sehr einfach über das Management Studio erfolgen. Ist hier der SQL Server Agent mit einem roten Kreuz markiert und enthält der Knotenname die Erweiterung “('Agent XPs' deaktiviert)”, so erfolgt eine Aktivierung mit dem folgenden Skript:

Publisher-Wizard

Die Konfiguration des Publishers erfolgt mit dem Kontext-Menü über “Replikation” => “Lokale Veröffentlichungen” => “Neue Veröffentlichung …”

Auf der folgenden Seite wird die lokale Instanz (= Default-Wert) als Provider verwendet.

Auf der nächsten Seite kann ausgewählt werden, ob der SQL Server Agent, durch den die für die Replikation benötigten Datenbank-Jobs ausgeführt werden, automatisch starten soll. Auch hier wird der Default-Wert beibehalten. In der Meldungszeile der Seite erhält man den Hinweis

Die Replikation beginnt mit der Erstellung lokaler Snapshot-Dateien die auf der Festplatte abgelegt werden. Auf der folgenden Seite wird der gewünschte Pfad abgefragt, wobei ein Default-Pfad vorgegeben ist. Hier muss sichergestellt werden, dass unter diesem Pfad ausreichend Platz für die Snapshot-Dateien der zu replizierenden Datenbank existiert. Da wir ein Push-Abonnement verwenden, kann die Meldung
“Pullabonnements, die auf dem Abonnenten erstellt wurden, werden von diesem Standardordner für Momentaufnahmeordner nicht unterstützt. Er ist kein Netzwerkpfad, oder er ist ein einem Netzwerkpfad zugeordneter Laufwerkbuchstabe. Verweisen Sie mit einem Netzwerkpfad auf diesen Ordner, um sowohl Push- als auch Pullabonnements zu unterstützen.“ unberücksichtigt bleiben.

Auf der nächsten Seite muss die zu replizierende Datenbank aus der Liste der in der Instanz betriebenen Datenbanken ausgewählt werden.

Auf der folgenden Seite ist wichtig, dass die Transaktionsveröffentlichung ausgewählt wird.

Es geht weiter mit der Liste der Objekte die repliziert werden sollen und der Spezifikation der zugehörigen Replikationsparameter. Im Beispiel wurden alle Objekte als Kandidaten markiert und beispielhaft die Tabelle “LinkTypes” selektiert. Der Typ des selektierten Objektes (Tabellen-Knoten oder individuelle Tabelle, Prozeduren-Knoten oder individuelle Prozedur) bewirkt eine Änderung des Untermenüs das sich hinter dem Button “Artikeleigenschaften” verbirgt: Hier besteht die Möglichkeit, Replikationsparameter für ein einzelnes Objekt oder eine Objektgruppe zu spezifizieren.

Die folgenden beiden Abbildungen geben die möglichen Parameter für Tabellen bzw. Prozeduren wieder. Bei der Parametrisierung der Replikationsobjekte (“Artikel”) werden im Abschnitt “Anweisungsübermittlung” keine benutzerspezifischen Stored Procedures benötigt, sondern hier können die generischen Einträge geändert werden:

1. “CALL ” in “INSERT-Anweisung”
2. “SCALL “ in “Update Anweisung”
3. “CALL ” in “DELETE-Anweisung”

Eine Besonderheit tritt bei dem Zielobjektbesitzer im Zielobjekt auf: Hier existiert ein Bruch der Bezeichnungen sowohl in der englischen als auch in der deutschen Version des SQL Server Management Studios: Das Eingabefeld erfordert nicht den Benutzer, sondern das Zielschema. Dieses wird per Default von dem Quellobjekt übernommen, kann aber bei Bedarf für die Zielumgebung geändert werden. Wird ein nicht in Azure SQL vorhandenes Zielschema angegeben, so wird dieses in Azure SQL angelegt und für das betreffende Objekt verwendet.

Bei der Prozedur DropIndexes wurden in diesem Beispiel die Default-Parameter nicht geändert

Von der Möglichkeit, bestimmte Tabellenzeilen von der Replikation über Filter auszuschließen wird hier kein Gebrauch gemacht:

Auf der nächsten Seite wird der initiale Snapshot gestartet. Ein Scheduling weiterer Snapshots ist hier nicht erforderlich.

Auf der nächsten Seite werden über den Button “Sicherheitseinstellungen” die Logins für die Snapshot-Erstellung und den Verleger eingegeben. Für dieses Beispiel wurde zur Vereinfachung jeweils das Konto des SQL Server Agenten verwendet. Dies ist jedoch aus Sicherheitsgründen nicht die empfohlene Vorgehensweise!

Auf der nächsten Seite kann die Veröffentlichung erstellt und optional auch ein entsprechendes Skript generiert werden

Falls die Skript-Option verwendet wurde, müssen im nächsten Schritt Pfad und Format der Skriptdatei angegeben werden.

Abschließend muss die Veröffentlichung benannt werden und man erhält eine Zusammenfassung der zuvor vorgenommenen Einstellungen. Als Name wurde hier “sql2azure” verwendet.

Eine Besonderheit auf dieser Seite ist ein “Weiter”-Button der nicht aktiviert und nicht aktivierbar ist. Der Wizard wird hier nach Eingabe des Veröffentlichungsnamens durch Verwendung der -Taste gestartet.

Der Verlauf der Veröffentlichungskonfiguration zeigt Ihnen evtl. die unten angegebene Warnung. Bei Selektion der Meldung erhalten Sie Details zu dem aufgetretenen Problem. Hier handelt es sich lediglich um eine Warnung, dass der Versuch, die Agent-Einstellung in der Windows-Registry auf automatischen Neustart zu setzen, wegen fehlender Berechtigung abgelehnt wurde. Dieser Schreibversuch erfolgt aber unabhängig von der aktuellen Agent-Einstellung und wenn dieser schon automatisch neu gestartet wird ist diese Registry-Änderung und die Fehlermeldung irrelevant.

Subscriber-Wizard

Der Subscriber-Wizard legt das Ziel der Replikation, in diesem Fall die Azure SQL Instanz, fest. Er wird gestartet indem man das Kontextmenü auf dem Knoten “Replikation” => “Lokale Veröffentlichungen” ==> “:<Publisher Name”, in unserem Beispiel “StackOverflow2013: sql2azure” verwendet. Dieser Knoten ist durch die im vorhergehenden Kapitel beschriebene Konfiguration mit dem Publisher-Wizard neu angelegt worden. In dem Kontextmenü wird der erste Eintrag “Neue Abonnements“ zum Start verwendet.

Im ersten Schritt wird die Quelle der Daten festgelegt. In diesem Fall handelt es sich um die StackOverflow2013 Datenbank mit dem zugehörigen, zuvor konfigurierten Publisher “sql2azure”.

Wie bereits erwähnt, benötigen wir für die Replikation nach Azure SQL das Push-Abonnement

Auf der nächsten Seite muss der “Abonnent”-Button rechts unten verwendet werden, um das neue Replikationsziel einzurichten. Hinter diesem Button befinden sich zwei Optionen:

1. SQL Server-Abonnenten hinzufügen …
2. Nicht-SQL Server-Abonnenten hinzufügen …

Entsprechend dem Ziel wählen wir die erste Möglichkeit

Nach Wahl der ersten Option werden die Anmeldedaten für die Zielinstanz erfragt und ggf. unter “Optionen” weitere Verbindungsparameter.

Anschließend gelangt man zurück zu der Abonnentenseite auf der jetzt das neue Abonnement aufgeführt ist. Dieses wird über die Check-Box auf der linken Seite selektiert und mit dem “Weiter”-Button zur nächsten Seite gesprungen

Die nächste Seite ist etwas unübersichtlich gestaltet. Hier muss man über die durch das rote Rechteck markierte Schaltfläche auf einer weiteren Seite Anmeldeinformationen eingeben.

Zur Vereinfachung wurde hier, wie auch bei dem Publisher-Wizard, das SQL Server Dienstkonto verwendet. Auch hier die Information, dass das aus Sicherheitsgründen nicht empfohlen wird.

Nachdem man die Anmeldedaten eingegeben hat, wieder auf die übergeordnete Seite zurückgekehrt ist und dort den “Weiter”-Button verwendet hat, gelangt man auf die folgende Seite, auf der die Default-Einstellung mit dem “Weiter”-Button bestätigt wird.

Auch die Seite zur Initialisierung des Abonnements wird mit den Default-Werten übernommen.

Anschließend wird das Abonnement erstellt und bei Bedarf die zugehörigen T-SQL Skripte generiert.

Wie beim Publisher-Wizard existiert auch auf der folgenden Überblickseite das Problem, dass der “Weiter”-Button deaktiviert ist und ein “Fertig stellen” Objekt nicht verfügbar ist. Auch hier wird mit der Zeilenwechsel-Taste zur nächsten Seite navigiert.

Zum Abschluss gelangt man auf die Übersichtsseite zu dem eingerichteten Abonnement

Replikationsmonitor

Im SQL Server Managementstudio existiert ein Replikationsmonitor über den der Status der Replikation verfolgt werden kann. Diesen erreicht man über das Kontextmenü über dem Knoten “Replikation”. Auf diesen Monitor wird hier nicht weiter eingegangen.

Replikations-Skripte

Der Replikations-Wizard zur Einrichtung der Publikation und der Subscription bietet jeweils die Möglichkeit, ein Skript für die vorgenommenen Einstellungen zu generieren. Diese beiden Skripte sind in den folgenden beiden Unterkapiteln auszugsweise wiedergegeben:

Publikations-Skript

Der folgende Textblock enthält ein generiertes Publikations-Skript. Es dient hier lediglich dazu, die erforderlichen Prozeduraufrufe zu dokumentieren, die Parametrisierung weicht eventuell von den Parametern in den o.a. Wizard-Fenstern ab und ggf. erforderliche Ersetzungen sind in Spitzen Klammern “<…>” angegeben.

Subscription-Skript

Der folgende Textblock enthält ein generiertes Subscription-Skript. Es dient hier lediglich dazu, die erforderlichen Prozeduraufrufe zu dokumentieren, die Parametrisierung weicht eventuell von den Parametern in den o.a. Wizard-Fenstern ab und ggf. erforderliche Ersetzungen sind in Spitzen Klammern “<…>” angegeben.

Migration in eine Azure Managed Instance

Azure Managed Instance ist wie Azure SQL Datenbank ein Platform-as-a-Service (PaaS) Dienst von Microsoft Azure zum Betrieb einer SQL Server Datenbank in der Cloud. Auf die Unterschiede zwischen diesen beiden Diensten wurde bereits in dem Kapitel Migration in eine Azure SQL Instanz hingewiesen. Die Migration erfolgt hier über die Replikation der On-Prem Instanz nach Azure über das Kontext-Menü <“Datenbank”> => “Azure SQL Managed Instance Link” ==> “Replicate database”.

Beim Einrichten der Replikation erhält man jedoch mehrere Fehlermeldungen und Warnungen die zunächst bearbeitet werden müssen:

1. Die direkte Replikation von SQL Server 2014 in eine Managed Instance wird nicht unterstützt, da das Verbindungsfeature die Technologie mit verteilten Verfügbarkeitsgruppen nutzt, die erst in SQL Server 2016 eingeführt wurde. Hier muss im Vorfeld auf SQL Server 2016 SP3 aktualisiert werden.

2. Das Azure Connect Pack muss installiert werden.
3. Es wird empfohlen die Trace Flags 1800 und 9567 einzuschalten

4. Für die Einrichtung des Managed Instance Links muss zur Unterstützung der Verschlüsselung der Datenübertragung der DB Masterkey installiert werden.

Im Fall der SQL Server Version 2016 und der oben dargestellten Inkompatibilität ist es nicht ausreichend, das Service Pack 3 zu installieren, sondern man muss zusätzlich das optionale Azure Connect Pack installieren. Im Rahmen der Suche nach Upgrades wurden auch zwei wichtige Sicherheitsupdates angezeigt die mit installiert wurden. Diese Installation erforderte einen Neustart des Servers. Damit war dann die erste Fehlermeldung bezüglich des SQL Server Versionschecks behoben.

Details zur Einrichtung des Managed Instance Links über ein Powershell-Script und die Behandlung der o.a. Fehler- und Warnmeldungen werden in dem Artikel “Managed Instance Links - On-Prem Managed Instance” meines Kollegen Attila detailliert beschrieben. An dieser Stelle wird die Einrichtung über die graphische Oberfläche des SSMS dargestellt. Hierzu wird im SSMS ein Wizard gestartet der über das Kontextmenü des Migrationskandidaten mit “Azure SQL Managed Instance Link” ==> “Replicate database” erreichbar ist.

Nachdem die Fehler und Warnungen wie oben dargestellt behoben wurden, konnte zum nächsten Schritt im Wizard über den Next-Button navigiert werden. Hier werden die verfügbaren, in der Instanz betriebenen Datenbanken aufgelistet und man kann die zu replizierenden DBs über die entsprechenden Check-Boxen auswählen. Zu Beginn konnte die StackOverflow2013 wegen ihrer Größe nicht repliziert werden und man erhielt eine Fehlermeldung, weil der Zielinstanz beim Setup nur 32 GB Storage zugeordnet waren. Nach Erweiterung des Storage auf 96 GB, was ca. eine Minute benötigte, konnte dann mit der Replikation fortgefahren werden.

Auf der nächsten Seite erfolgen der Login bei Azure und die Auswahl von Resource Gruppe und Managed Instance die als Ziel der Replikation verwendet werden sollen.

Die nächste Seite wurde mit bereits vorkonfigurierten Werten geöffnet, die allerdings einem Überprüfungsmechanismus durch den Wizard nicht standhielten, so dass der “Next”-Button “disabled” war: Hier mussten die Namen leicht modifiziert werden (hier nicht graphisch dargestellt). Weil bei einem vorherigen Test diese Korrekturen bereits durchgeführt wurden ist das vom Wizard generierte Zertifikat bereits vorhanden und wird verwendet.

Auf der folgenden Seite erfolgt eine Zusammenfassung der durchzuführenden Aktionen und man erhält die Möglichkeit, sich diese als Script generieren zu lassen.

Durch den Finish-Button werden diese Aktionen dann ausgeführt.

Die beiden Links zum Thema Log-Backup und Troubleshooting verwiesen auf folgende Seiten:
Bewährte Methoden für das Linkfeature - Azure SQL Managed Instance

Vorbereiten der Umgebung für einen Azure SQL Managed Instance-Link - Azure SQL Managed Instance

Jetzt ist das Replikat in Azure als Read-Only Version verfügbar und kann über ein Failover aktiviert werden. Hierzu wird jetzt der Menüpunkt “Failover database” verwendet.

Nach ca. 30 Sekunden sind der Umschaltvorgang und die Bereinigung erfolgreich verlaufen.

Aktualisierung des Kompatibilitätsgrades

In den hier dargestellten Upgrade-Szenarien, außer PaaS-Zielen, sollte nach dem Upgrade bzw. der Migration nicht vergessen werden, den Kompatibilitätsgrad der Datenbanken zu aktualisieren, damit man die Features der neueren Version im vollen Umfang nutzen kann oder, wie es ein Kollege formulierte, “damit man nicht mit angezogener Handbremse fährt”. Seit Version 2014 hat sich sehr viel geändert, insbesondere auch im Hinblick auf Performance.

Die Aktualisierung von MSSQL Instanzen wird oft sehr stiefmütterlich behandelt oder sogar bewusst vermieden. Hier führt die vielzitierte Philosophie “Never touch a running System” zum Verzicht auf die Nutzung neuer Features und Performance-Verbesserungen und erhöhte Support-Kosten bei gleichzeitigem Verlust der Support-Qualität (Patches nur noch bei groben Sicherheitslücken). Letztendlich kann sich der Aufwand zur Durchführung von sehr alten auf aktuelle Versionen erhöhen, da direkte Upgrades evtl. nicht mehr unterstützt werden und mehrstufig aktualisiert werden muss. In diesem Dokument wurden mehrere Upgrade- und Migrationsmethoden von MSSQL 2014 nach MSSQL 2022 bzw. Azure dargestellt, die größtenteils ohne oder ohne nennenswerte Nichtverfügbarkeit der Instanzen durchgeführt werden können.

Bei weitergehenden Fragen können Sie sich auch unverbindlich über unser Kontaktformular an uns wenden.