Blog
Friday, 05. May 2023

SQL Server Upgrade auf 2022

Rainer
IT-Consultant

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.

In Place Upgrade - Der Trivialfall
In Place Upgrade - Der Trivialfall

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.
On-Prem Migration, Übertragung der Datenbanken in eine Instanz der neuen Version, ggf. auf einem anderen Server
On-Prem Migration, Übertragung der Datenbanken in eine Instanz der neuen Version, ggf. auf einem anderen Server 

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:

Produkttyp Quelle Ziel
Database Engine SQL Server Azure SQL Database
Database Engine SQL Server Azure SQL Managed Instance
Database Engine SQL Server SQL Server in einer Azure VM
Database Engine SQL Server SQL Server
Database Engine AWS RDS for SQL Server Azure SQL Database
Database Engine AWS RDS for SQL Server Azure SQL Managed Instance
Database Engine AWS RDS for SQL Server SQL Server in einer Azure VM
Database Engine AWS RDS for SQL Server SQL Server
Integration Services SQL Server Azure SQL Database
Integration Services SQL Server Azure SQL Managed Instance

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:

exec [sys].[sp_MS_replication_installed]

# Je nach Situation erhalten Sie eine der folgenden Ausgaben:

# Replikation installiert:
Commands completed successfully.


######################################################################


# Replikation nicht installiert:
RegOpenKeyEx() hat den Fehler "2", "Das System kann die angegebene Datei nicht finden." zurückgegeben.
Meldung 22001, Ebene 1, Status 1
Nachricht 21028, Stufe 16, Status 1, Prozedur sys.sp_MS_replication_installed, Zeile 35 [Batchstartzeile 0]
Replikationskomponenten sind auf diesem Server nicht installiert. Führen Sie das SQL Server-Setup erneut aus, und wählen Sie die Option zum Installieren der Replikation aus.

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

Could not find any resources appropriate for the specified
culture or the neutral culture.
Make sure "Microsoft.SqlServer.Management.UI.ArticlePropertiesForm.resources"
was correctly embedded or linked into assembly "CreatePubWizard" at
compile time, or that all the satellite assemblies required are
loadable and fully signed. (mscorlib)

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:

# Im Distribution-Job:
Unable to start execution of step 2 (reason: The Distribution subsystem failed to load
[see the SQLAGENT.OUT file for details];
The job has been suspended).  The step failed.

# Im LogReader-Job:
Unable to start execution of step 2 (reason: The LogReader subsystem failed to load
[see the SQLAGENT.OUT file for details];
The job has been suspended).  The step failed.

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:

Fehlermeldung bei der Verwendung des Replikations-Wizard
Fehlermeldung bei der Verwendung des Replikations-Wizard

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:

sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'Agent XPs', 1;
GO
RECONFIGURE
GO

Publisher-Wizard

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

Startseite des Publisher-Wizard
Startseite des Publisher-Wizard

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

Verwendung der lokalen Instanz
Verwendung der lokalen Instanz

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

“Um den SQL Server-Agent-Dienst für den Assistenten zu konfigurieren, muss das SQL Server-Dienstkonto über Administratorberechtigungen auf dem Servercomputer verfügen. Wenn der Dienst diese Berechtigungen nicht hat, müssen Sie die Konfiguration manuell ändern.“
Bestätigen des automatischen Agent-Starts
Bestätigen des automatischen Agent-Starts

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.

Pfadangabe der Snapshot-Dateien
Pfadangabe der Snapshot-Dateien

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

Auswahl des Replikationskandidaten
Auswahl des Replikationskandidaten

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

Auswahl der Transaktionsveröffentlichung
Auswahl der Transaktionsveröffentlichung

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.

Markierung aller Objekte für die Replikation mit Auswahl einer Tabelle
Markierung aller Objekte für die Replikation mit Auswahl einer Tabelle

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.

Beispiel für Replikationsparameter der Tabellen
Beispiel für Replikationsparameter der Tabellen

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

Replikationsparameter für Prozeduren (hier “DropIndexes”)
Replikationsparameter für Prozeduren (hier “DropIndexes”)

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

Ohne zu Filtern zur nächsten Seite schalten
Ohne zu Filtern zur nächsten Seite schalten

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

Starten des initialen Snapshots
Starten des initialen Snapshots

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!

Festlegung der Konten für Snapshot und Verleger
Festlegung der Konten für Snapshot und Verleger
Zielseite des Button “Sicherheitseinstellungen”
Zielseite des Button “Sicherheitseinstellungen”

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

Veröffentlichung erstellen und optionales Erstellen des Skripts
Veröffentlichung erstellen und optionales Erstellen des Skripts

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

Pfad und gewünschtes Format der Skriptdatei
Pfad und gewünschtes Format der Skriptdatei

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.

Übersicht der verwendeten Einstellungen
Übersicht der verwendeten Einstellungen

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.

Verlauf der Veröffentlichungskonfiguration
Verlauf der Veröffentlichungskonfiguration

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.

Initiales Fenster des Subscriber-Wizard
Initiales Fenster des Subscriber-Wizard

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

Datenquelle der Replikation
Datenquelle der Replikation

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

Auswahl Push-Abonnement
Auswahl 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

Neues Ziel über den “Abonnent”-Button einrichten
Neues Ziel über den “Abonnent”-Button einrichten

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

Anmeldedaten für die Zielinstanz
Anmeldedaten für die Zielinstanz

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

Zeile mit neuem Abonnement
Zeile mit neuem Abonnement

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.

Navigation zur Seite für die Anmeldeinformationen über “…”
Navigation zur Seite für die Anmeldeinformationen über “…”

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.

Anmeldedaten für das Push-Abonnement
Anmeldedaten für das Push-Abonnement

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.

Synchronisationszeitplan: Fortlaufend ausführen
Synchronisationszeitplan: Fortlaufend ausführen

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

Initialisierung des Abonnements
Initialisierung des Abonnements

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

Abonnement erstellen und bei Bedarf T-SQL Skripte erstellen
Abonnement erstellen und bei Bedarf T-SQL Skripte erstellen
Pfad und gewünschtes Format der Skriptdatei
Pfad und gewünschtes Format der Skriptdatei

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.

Übersicht der verwendeten Einstellungen
Übersicht der verwendeten Einstellungen

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.

/****** Scripting replication configuration. Script Date: 18.04.2023 10:31:55 ******/
/****** Please Note: For security reasons, all password parameters were scripted with either NULL or an empty string. ******/

/****** Installing the server as a Distributor. Script Date: 18.04.2023 10:31:55 ******/
use master
exec sp_adddistributor @distributor = N'<Server>\<Quellinstanz>', @password = N''
GO
exec sp_adddistributiondb @database = N'distribution', @data_folder = N'C:\MSSQL_Files\Data\Microsoft SQL Server\MSSQL12.<Quellinstanz>\MSSQL\Data', @log_folder = N'C:\MSSQL_Files\Tlogs\Microsoft SQL Server\MSSQL12.<Quellinstanz>\MSSQL\Data', @log_file_size = 2, @min_distretention = 0, @max_distretention = 72, @history_retention = 48, @deletebatchsize_xact = 5000, @deletebatchsize_cmd = 2000, @security_mode = 1
GO

use [distribution] 
if (not exists (select * from sysobjects where name = 'UIProperties' and type = 'U ')) 
	create table UIProperties(id int) 
if (exists (select * from ::fn_listextendedproperty('SnapshotFolder', 'user', 'dbo', 'table', 'UIProperties', null, null))) 
	EXEC sp_updateextendedproperty N'SnapshotFolder', N'C:\MSSQL_Files\Data\Microsoft SQL Server\MSSQL12.<Quellinstanz>\MSSQL\ReplData', 'user', dbo, 'table', 'UIProperties' 
else 
	EXEC sp_addextendedproperty N'SnapshotFolder', N'C:\MSSQL_Files\Data\Microsoft SQL Server\MSSQL12.<Quellinstanz>\MSSQL\ReplData', 'user', dbo, 'table', 'UIProperties'
GO

exec sp_adddistpublisher @publisher = N'<Server>\<Quellinstanz>', @distribution_db = N'distribution', @security_mode = 0, @login = N'srvadmin', @password = N'', @working_directory = N'C:\MSSQL_Files\Data\Microsoft SQL Server\MSSQL12.<Quellinstanz>\MSSQL\ReplData', @trusted = N'false', @thirdparty_flag = 0, @publisher_type = N'MSSQLSERVER'
GO

use [<QuellDB>]
exec sp_replicationdboption @dbname = N'<QuellDB>', @optname = N'publish', @value = N'true'
GO
-- Adding the transactional publication
use [<QuellDB>]
exec sp_addpublication @publication = N'sql2azure', @description = N'Transactional publication of database ''<QuellDB>'' from Publisher ''<Server>\<Quellinstanz>''.', @sync_method = N'native', @retention = 0, @allow_push = N'true', @allow_pull = N'true', @allow_anonymous = N'true', @enabled_for_internet = N'false', @snapshot_in_defaultfolder = N'true', @compress_snapshot = N'false', @ftp_port = 21, @ftp_login = N'anonymous', @allow_subscription_copy = N'false', @add_to_active_directory = N'false', @repl_freq = N'continuous', @status = N'active', @independent_agent = N'true', @immediate_sync = N'true', @allow_sync_tran = N'false', @autogen_sync_procs = N'false', @allow_queued_tran = N'false', @allow_dts = N'false', @replicate_ddl = 1, @allow_initialize_from_backup = N'false', @enabled_for_p2p = N'false', @enabled_for_het_sub = N'false'
GO


exec sp_addpublication_snapshot @publication = N'sql2azure', @frequency_type = 4, @frequency_interval = 1, @frequency_relative_interval = 1, @frequency_recurrence_factor = 0, @frequency_subday = 4, @frequency_subday_interval = 5, @active_start_time_of_day = 0, @active_end_time_of_day = 235959, @active_start_date = 0, @active_end_date = 0, @job_login = null, @job_password = null, @publisher_security_mode = 1


use [<QuellDB>]
exec sp_addarticle @publication = N'sql2azure', @article = N'<Zielobjekt_1>', @source_owner = N'dbo', @source_object = N'<Zielobjekt_1>', @type = N'logbased', @description = null, @creation_script = null, @pre_creation_cmd = N'drop', @schema_option = 0x000003F67DFF7FF7, @identityrangemanagementoption = N'manual', @destination_table = N'<Zielobjekt_1>', @destination_owner = N'<ZielDB-User>', @status = 8, @vertical_partition = N'false', @ins_cmd = N'SQL', @del_cmd = N'SQL', @upd_cmd = N'SQL'
GO




use [<QuellDB>]
exec sp_addarticle @publication = N'sql2azure', @article = N'<Zielobjekt_2>', @source_owner = N'dbo', @source_object = N'<Zielobjekt_2>', @type = N'logbased', @description = null, @creation_script = null, @pre_creation_cmd = N'drop', @schema_option = 0x000003F67DFF7FF7, @identityrangemanagementoption = N'manual', @destination_table = N'<Zielobjekt_2>', @destination_owner = N'<ZielDB-User>', @status = 8, @vertical_partition = N'false', @ins_cmd = N'SQL', @del_cmd = N'SQL', @upd_cmd = N'SQL'
GO

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.

-----------------BEGIN: Script to be run at Publisher '<Server>\<Quellinstanz>'-----------------
use [<QuellDB>]
exec sp_addsubscription @publication = N'sql2azure', @subscriber = N'<Zielserver>.database.windows.net,<Port>', @destination_db = N'<ZielDB>', @subscription_type = N'Push', @sync_type = N'automatic', @article = N'all', @update_mode = N'read only', @subscriber_type = 0
exec sp_addpushsubscription_agent @publication = N'sql2azure', @subscriber = N'<Zielserver>.database.windows.net,<Port>', @subscriber_db = N'<ZielDB>', @job_login = null, @job_password = null, @subscriber_security_mode = 0, @subscriber_login = N'<Ziel-Login>', @subscriber_password = null, @frequency_type = 64, @frequency_interval = 0, @frequency_relative_interval = 0, @frequency_recurrence_factor = 0, @frequency_subday = 0, @frequency_subday_interval = 0, @active_start_time_of_day = 0, @active_end_time_of_day = 235959, @active_start_date = 20230418, @active_end_date = 99991231, @enabled_for_syncmgr = N'False', @dts_package_location = N'Distributor'
GO
-----------------END: Script to be run at Publisher '<Server>\<Quellinstanz>'-----------------

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

Starten des Wizard zur Replikation nach Azure
Starten des Wizard zur Replikation nach Azure

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.
Upgrade und Migration in eine Managed Instance (Azure)
Upgrade und Migration in eine Managed Instance (Azure)
  1. Das Azure Connect Pack muss installiert werden.
  2. Es wird empfohlen die Trace Flags 1800 und 9567 einzuschalten
Fehlermeldungen und Warnungen beim Anlegen eines Managed Instance Links
Fehlermeldungen und Warnungen beim Anlegen eines Managed Instance Links
  1. Für die Einrichtung des Managed Instance Links muss zur Unterstützung der Verschlüsselung der Datenübertragung der DB Masterkey installiert werden.
Weitere Anforderung: Installation des DB Masterkeys
Weitere Anforderung: Installation des DB Masterkeys

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.

Installation des Azure Connect Pack
Installation des Azure Connect Pack

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.

Menüfolge zum Starten des Replikations-Wizard
Menüfolge zum Starten des Replikations-Wizard

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.

 Auswahl der DBs die nach Azure repliziert werden sollen
Auswahl der DBs die nach Azure repliziert werden sollen

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.

Azure Login und Zielparameter
Azure Login und Zielparameter

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.

Vorkonfigurierte Optionen für die Distributed Availability Group
Vorkonfigurierte Optionen für die Distributed Availability Group

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.

Zusammenfassung der Aktionen
Zusammenfassung der Aktionen

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

Ausführung und Ergebnis der Aktionen
Ausführung und Ergebnis der Aktionen

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.

Failover einleiten
Failover einleiten
Startseite des Failover-Wizard
Startseite des Failover-Wizard
 Auswahl der Managed Instance und der Quelldatenbank
Auswahl der Managed Instance und der Quelldatenbank
Zugangsdaten zu Azure
Zugangsdaten zu Azure
Auswahl des Failover-Typs
Auswahl des Failover-Typs
Zum Abschluss des Failover kann die Availability Gruppe aufgelöst werden
Zum Abschluss des Failover kann die Availability Gruppe aufgelöst werden
Übersicht und Zusammenfassung der Aktionen
Übersicht und Zusammenfassung der Aktionen

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

Ergebnisse der Failover-Schritte
Ergebnisse der Failover-Schritte

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.

Interesse geweckt?

Unsere Expert:innen stehen Ihnen bei allen Fragen rund um Ihre IT Infrastruktur zur Seite.

Kontaktieren Sie uns gerne über das Kontaktformular und vereinbaren ein unverbindliches Beratungsgespräch mit unseren Berater:innen zur Bedarfsevaluierung. Gemeinsam optimieren wir Ihre Umgebung und steigern Ihre Performance!
Wir freuen uns auf Ihre Kontaktaufnahme!

Taunusstraße 72
55118 Mainz
info@madafa.de
+49 6131 3331612
Bürozeiten
Montag bis Donnerstag:
9:00 - 17:00 Uhr MEZ

Freitags:
9:30 - 14:00 Uhr MEZ