Im Laufe der Zeit migrieren immer mehr Unternehmen zu Azure SQL-Datenbank oder evaluieren sie zumindest als Alternative zu den hohen Kosten für den Betrieb von SQL Server vor Ort.
Kompatibilität prüfen
Einer der ersten Aspekte beim Verschieben Ihrer Datenbank zu Azure SQL-Datenbank ist die Überprüfung der Kompatibilität, und Microsoft bietet Ihnen zahlreiche Möglichkeiten, dies für Azure SQL-Datenbank V12 (im Folgenden nur als „V12“ bezeichnet) zu tun. Eine dieser Methoden ist die Verwendung von SQL Server Data Tools for Visual Studio (SSDT), die die neuesten Kompatibilitätsregeln verwendet, um V12-Inkompatibilitäten zu erkennen. In SSDT können Sie Ihr Datenbankschema importieren und ein Projekt für eine V12-Bereitstellung erstellen, und wenn Inkompatibilitäten gefunden werden, können diese in SSDT korrigiert und dann wieder mit der Quelldatenbank synchronisiert werden.
Sie können auch ein Befehlszeilentool namens SqlPackage verwenden, das einen Bericht über Kompatibilitätsprobleme erstellen kann (und immer sicherstellen, dass Sie über die neueste Version verfügen). SQL Server Management Studio ist eine andere Möglichkeit, dies zu tun, indem die Funktion „Anwendung auf Datenebene exportieren“ verwendet wird, die Fehler erkennen und auf dem Bildschirm melden kann. Wenn keine Fehler erkannt werden, können Sie Ihre Datenbank anschließend auf V12 migrieren. Wenn Inkompatibilitäten festgestellt werden, können diese vor der Migration mithilfe von SSMS korrigiert werden.
Der Datenmigrations-Assistent ist ein eigenständiges Tool (das leicht mit dem SQL Server-Migrations-Assistenten verwechselt werden kann), das verwendet werden kann, um den Upgrade-Aufwand zu reduzieren, und das die Vorschau des SQL Server 2016-Upgraderatgebers ersetzt. DMA kann auch Leistungs- und Zuverlässigkeitsverbesserungen empfehlen. Ein weiteres Tool, SQL Azure Migration Wizard (SAMW), ist ein Codeplex-Tool, das Azure SQL Database V11-Kompatibilitätsregeln verwendet, um V12-Inkompatibilitäten zu erkennen. SAMW kann auch die Migration auf V12 abschließen und einige Kompatibilitätsprobleme beheben. Beachten Sie bei der Verwendung von SAMW, dass es Inkompatibilitäten erkennen kann, die nicht behoben werden müssen.
Migration von Daten
Nachdem Ihre Datenbank die Kompatibilitätsprüfung bestanden hat, müssen Sie die beste Migrationsmethode bestimmen. Zu den gebräuchlicheren Methoden gehören die Verwendung des SSMS-Migrationsassistenten, der Export in ein BACPAC, die Verwendung der Transaktionsreplikation oder die manuelle Erstellung von Skripts für die Datenbanken und das Einfügen Ihrer Daten.
Die Verwendung des SSMS-Migrationsassistenten eignet sich hervorragend für SQL Server 2005 und höhere Datenbanken mit kleiner bis mittlerer Größe. Sie können diesen Assistenten in SSMS 2016 aktivieren, indem Sie mit der rechten Maustaste auf eine Datenbank klicken, Aufgaben auswählen und dann Datenbank in Microsoft Azure SQL-Datenbank bereitstellen. In SSMS 2014 heißt es Datenbank in Windows Azure SQL-Datenbank bereitstellen. Mithilfe dieses Assistenten können Sie die zu migrierende Datenbank angeben, eine Verbindung mit Ihrem Azure-Abonnement herstellen, den Speicherort für die BACPAC-Datei, den neuen Datenbanknamen und die zu migrierende Ebene auswählen. Wenn Sie auf Fertig stellen klicken, extrahiert und validiert der Assistent das Schema und exportiert dann die Daten. Sobald die Daten exportiert sind, wird ein Bereitstellungsplan erstellt und mit dem Import der Daten in die neue V12-Datenbank begonnen.
Sehr ähnlich dem SSMS-Migrationsassistenten ist die Anwendung zum Exportieren der Datenebene. Um diese Option auszuwählen, klicken Sie mit der rechten Maustaste auf die Datenbank, wählen Sie Aufgaben und dann Datenebenenanwendung exportieren. In den Exporteinstellungen legen Sie fest, wo Sie die .bacpac-Datei erstellen möchten. Sie können dies lokal oder direkt in Ihrem Azure-Speicherkonto speichern. Es gibt auch eine erweiterte Registerkarte, auf der Sie auswählen können, welche Tabellen eingeschlossen werden sollen. Dies ist hilfreich, wenn Ihre lokale Datenbank Kopien von Tabellen enthält, die Sie nicht auf V12 migrieren möchten. Wenn Sie Finish wählen, werden Ihre Daten exportiert. Anschließend können Sie über SSMS eine Verbindung zu Ihrem Azure-Server herstellen und die Datenebenenanwendung importieren auswählen. Sie geben den Speicherort der Datei, den Datenbanknamen und die Ebene der Azure SQL-Datenbank an. Wenn Sie Finish wählen, beginnt die Datenbank mit dem Importieren. Diese Methode gibt Ihnen etwas mehr Kontrolle über den Prozess, da sie den Export vom Import trennt. Außerdem haben Sie die Möglichkeit, die .bacpac-Datei in Ihrem Azure-Speicherkonto zu speichern, sodass der anfälligere Importvorgang nicht von Ihrer Internetverbindung abhängig ist.
Eine Option bei Verwendung des SSMS-Migrations-Assistenten oder der Anwendung zum Exportieren der Datenebene besteht darin, eine Azure-VM mit SQL Server zu erstellen und den Protokollversand einzurichten. Dadurch wird Ihre Datenbank in der Azure-Cloud vorab bereitgestellt, um die Importzeit der Datenbank zu minimieren. Wenn es an der Zeit ist, die Migration durchzuführen, stellen Sie einfach die letzten Protokollsicherungen auf dem sekundären Server wieder her und entfernen dann den Protokollversand. Um die Datenbank online zu bringen, führen Sie eine Wiederherstellung mit Wiederherstellung durch. Dadurch entfällt im Wesentlichen die Zeit, die zum Kopieren Ihrer Datenbank von Ihrem Rechenzentrum in das Azure-Rechenzentrum benötigt wird.
Die Transaktionsreplikation ist eine weitere Methode, um die Ausfallzeit der Migration auf V12 zu reduzieren. Es ist die beste Option, wenn Sie ein extrem kleines Wartungsfenster haben, um auf V12 umzustellen, wenn die Datenbank die Transaktionsreplikation unterstützen kann. Die Einrichtung der Transaktionsreplikation erfordert Primärschlüssel für jede veröffentlichte Tabelle, was für viele Datenbanken problematisch sein kann. Das Konfigurieren der Transaktionsreplikation kann ebenfalls kompliziert sein, da Sie die Verteilungsdatenbank einrichten, den Herausgeber und Abonnenten einrichten und Jobs überwachen müssen.
Sie können auch manuell migrieren, indem Sie den Assistenten zum Generieren von Skripts verwenden und das Datenbankschema und/oder die Daten per Skript erstellen. Anschließend können Sie eine leere Datenbank in Azure erstellen und Ihr Schema und/oder Ihre Daten importieren, indem Sie das Skript ausführen. Ich habe von einigen Leuten gehört, die diese Methode verwenden, um die leere Datenbank zu erstellen und dann ihre Daten manuell einzeln mit SSMS und einem Verbindungsserver einzufügen. Diese Methode funktioniert möglicherweise für Sie, kann aber auch sehr kompliziert sein, wenn Sie viele Schemakonstrukte wie Fremdschlüsselbeziehungen und Identitätsspalten haben. In diesem Fall wären die anderen oben genannten Methoden zuverlässiger und effizienter.
Weitere Überlegungen zur Migration
Bei der Planung, lokale Datenbanken auf V12 zu migrieren, ist die Größe der Datenbank ein wichtiger Faktor dafür, wie lange die Migration dauern wird. Der Export der Datenbank, die Übertragung der Daten und der Import werden alle proportional zur Größe der Datenbank zunehmen.
Ein weiterer wichtiger Faktor für die Wiederherstellungs-/Importzeit beim Verschieben Ihrer Datenbanken auf V12 ist die Leistungsebene, die Sie ebenfalls wiederherstellen. Der Wiederherstellungs-/Importprozess erfordert viel Leistung. Um Ihre Migration zu beschleunigen, sollten Sie daher die Wiederherstellung auf eine höhere Leistungsstufe in Betracht ziehen. Wenn die Datenbank online ist, können Sie einfach und schnell auf eine niedrigere Ebene heruntersteigen, die Ihren täglichen Leistungsanforderungen entspricht. Die Leistungsstufen mit wenigen Mausklicks ändern zu können, ist einer der großen Vorteile von Azure SQL-Datenbank.
Überwachung
Ein wichtiger Teil der Verwaltung einer Datenbank ist die Überwachung. Wenn Sie etwas nicht überwachen, können Sie es nicht messen. Wenn Sie nicht wissen, was Ihre Metriken sind, wenn die Dinge normal funktionieren, wie werden Sie dann wissen, welche Dinge schlechter sind, wenn die Leistung beeinträchtigt wird? Bei lokalen Datenbanken verfügen wir über Tools, mit denen wir vertraut sind:SQL Server Management Studio, Performance Monitor, Task Manager, DMVs und so weiter. Wenn wir unsere Datenbanken auf V12 verschieben, verlieren wir die Möglichkeit, sie aus der Perspektive des Betriebssystems zu überwachen, und auch andere Konzepte ändern sich ein wenig. Wir haben jetzt diese Metrik namens DTU, mit der wir arbeiten können, was für Database Transaction Units steht. Stellen Sie es sich als eine Kombination aus CPU, Daten- und Transaktionsprotokoll-E/A und Arbeitsspeicher vor. Das Azure-Portal enthält ein Überwachungsdiagramm, das standardmäßig den DTU-Prozentsatz überprüft, und Sie können dieses Diagramm bearbeiten, um zusätzliche Metriken einzuschließen, wie z. B.:
- Von der Firewall blockiert
- CPU %
- DTU-Limit
- DTU verwendet
- Daten-E/A %
- Datenbankgröße %
- Deadlocks
- Fehlgeschlagene Verbindungen
- In-Memory-OLTP-Speicher %
(Vorschau)
- E/A % protokollieren
- Sitzungen %
- Erfolgreiche Verbindungen
- Gesamtgröße der Datenbank
- Arbeiter %
Als Minimum würde ich CPU-Prozentsatz, Daten-E/A-Prozentsatz, Deadlocks und Prozentsatz der Datenbankgröße hinzufügen. Derzeit zeigt dieses Diagramm die vorherige Stunde der Ressourcennutzung an.
Die Überwachung durch DMVs hat sich nicht wesentlich geändert, abgesehen davon, dass es einige neue DMVs gibt, die sich auf einzelne Datenbankmetriken beziehen und wie die Datenbankgröße berechnet wird. Einer meiner vorherigen Artikel hier, Erste Schritte zur Optimierung der Leistung in Azure SQL-Datenbank, behandelt einige der Unterschiede in den gängigen Skripts, die zum Erfassen von Datenträgerlatenzen und Wartestatistiken in Bezug auf Azure SQL-Datenbank verwendet werden.
Auch Tools von Drittanbietern haben damit begonnen, Hooks in die Azure SQL-Datenbank aufzunehmen, wie z. B. SentryOne mit DB Sentry. DB Sentry gibt Ihnen die Möglichkeit, die Leistung zu überwachen und Ereignisse zu verwalten, die in Ihrem System auftreten. Eine coole Funktion ist die Top-SQL-Funktion, mit der Sie die Abfragen anzeigen können, die sich am stärksten auf Ihre Gesamtleistung auswirken, sodass Sie Probleme mit dieser Abfrage optimieren/beheben können. Eine andere Möglichkeit besteht darin, die DTU im Laufe der Zeit aufzuzeichnen und dies zusammen mit anderen wichtigen Metriken auf einem Dashboard zu visualisieren.
 Top-SQL im SentryOne-Client |  DTU-Verwendung im DB Sentry-Dashboard |
Diese Metriken werden in einer dedizierten Datenbank gespeichert und bieten Ihnen die Möglichkeit, Basiswerte und Trends über die Leistung im Laufe der Zeit zu erstellen, was viel besser ist als die begrenzten Diagramme, die Sie derzeit im Azure-Portal erhalten.
Zusammenfassung
Die Migration zu Azure SQL-Datenbank V12 bietet viele Vorteile, wenn Ihre Datenbank kompatibel ist. Nutzen Sie also eines der verfügbaren Tools, um Ihre Kompatibilität mit V12 zu überprüfen. Wenn Ihre Datenbank kompatibel ist oder einfach geändert werden kann, um kompatibel zu werden, können Sie problemlos zu Azure SQL Database V12 migrieren und mit dem Testen und Benchmarking Ihrer Anwendungen und Workloads beginnen.
