Bereits im August 2015 habe ich einen Artikel geschrieben, in dem das neue Stretch Database-Feature in SQL Server 2016 vorgestellt wurde. In diesem Artikel habe ich erläutert, wie man mit Stretch Database in SQL Server 2016 Community Technology Preview 2 (CTP2) loslegt. SQL Server 2016 wurde am 1. Juni 2016 veröffentlicht und es gab zahlreiche Updates für das Produkt. Die Methode zum Einrichten von Stretch Database hat sich leicht geändert, ebenso wie einige der Funktionen.
Beginnend mit SQL Server 2016 haben wir die Möglichkeit erhalten, Teile einer Datenbank in einer Azure SQL-Datenbank zu speichern. In früheren Vorschauversionen mussten Sie beim Aktivieren von Stretch für eine Datenbank die gesamte Tabelle migrieren, mit der RTM-Version von SQL Server 2016 können Sie jetzt einen Teil einer Tabelle auswählen. Sobald Sie Stretch für eine Tabelle aktivieren, werden Ihre Daten im Hintergrund migriert. Wenn Sie mit Stretch Database nicht vertraut sind, nutzt es die Verarbeitungsleistung in Azure, um Abfragen für die Remotedaten auszuführen, indem die Abfrage umgeschrieben wird. Sie müssen auf Ihrer Seite keine Abfragen neu schreiben. Sie sehen dies als „Remote-Abfrage“-Operator im Abfrageplan.
Eine einfache Möglichkeit, Datenbanken und Tabellen zu identifizieren, die für Stretch-fähig sind, besteht darin, den SQL Server 2016 Upgrade Advisor herunterzuladen und auszuführen und den Stretch Database Advisor auszuführen. Aaron Bertrand (@AaronBertrand) hat vor einiger Zeit darüber geschrieben. Der Upgrade Advisor hat sich seit Aarons Beitrag leicht verändert, der Prozess ist jedoch größtenteils derselbe:
- Kandidatentabellen für SQL Server 2016-Stretch-Datenbanken identifizieren
Einschränkungen für die Stretch-Datenbank
Nicht alle Tische können Stretch-fähig gemacht werden. Bestimmte Tabelleneigenschaften, Daten- und Spaltentypen, Einschränkungen und Indizes werden nicht unterstützt, wie zum Beispiel:
- Speicheroptimierte und replizierte Tabellen
- Tabellen, die FILESTREAM-Daten enthalten, verwenden Change Tracking oder Change Data Capture
- Datentypen wie timestamp, sql_variant, XML oder geography
- Überprüfen oder Standardbeschränkungen
- Fremdschlüsseleinschränkungen, die auf die Tabelle verweisen
- XML-, Volltext-, räumliche oder gruppierte Columnstore-Indizes
- Indizierte Ansichten, die auf die Tabelle verweisen
- Sie können keine UPDATE- oder DELETE-Anweisungen oder CREATE INDEX- oder ALTER INDEX-Operationen für eine Stretch-aktivierte Tabelle ausführen
Eine vollständige Liste der Einschränkungen finden Sie unter:Anforderungen und Einschränkungen für die Stretch-Datenbank.
Stretch-Datenbank einrichten
Der Einstieg in die RTM-Version unterscheidet sich ein wenig von den früheren Vorschauen. Sie benötigen ein Azure-Konto, und dann müssen Sie Stretch Database auf der lokalen Instanz aktivieren.
Um Stretch Database auf einer Instanz zu aktivieren, führen Sie Folgendes aus:
EXEC sys.sp_configure N'remote data archive', '1'; RECONFIGURE; GO
Für diese Demo werde ich eine von mir erstellte Beispieldatenbank namens STRETCH verwenden. Ich begann mit einem Rechtsklick auf die Datenbank, wählte Tasks, Stretch und dann Enable. Dabei wurde SQL Server 2016 Management Studio verwendet.
Der nächste Bildschirm zeigt Ihnen, welche Tische Sie für Stretch aktivieren möchten:
Ich habe mich für die Tabelle SALES2 entschieden. Der Assistent ist standardmäßig auf „Gesamte Tabelle“ eingestellt, aber Sie können diese Option auch ändern, um eine Teilmenge von Zeilen zu migrieren.
Wenn Sie nach Zeilen auswählen, müssen Sie einen Namen für Ihre Kriterien auswählen und dann können Sie auswählen, welche Spalte in Ihrer Where-Anweisung verwendet werden soll, sowie die Bedingung und den Wert. In diesem Screenshot habe ich Zeilen vor 2016 ausgewählt. Die Möglichkeit, einen Teil einer Tabelle auszuwählen, ist eine enorme Verbesserung gegenüber den früheren Vorschauen, bei denen Sie nur die gesamte Tabelle strecken konnten. Der Einfachheit halber werde ich in dieser Demo die gesamte Tabelle migrieren, also habe ich auf Abbrechen und dann auf Weiter geklickt.
Nachdem Sie Ihre Tabellen und Bedingungen ausgewählt haben, müssen Sie auswählen, welches Azure-Abonnement Sie verwenden möchten, Ihre Azure-Region und Ihre Serverinformationen.
Nachdem Sie die erforderlichen Informationen eingegeben haben, klicken Sie auf Weiter.
Eine neue Verbesserung verwendet den Datenbank-Hauptschlüssel, um die Azure-Anmeldeinformationen für die Verbindung mit Azure zu schützen. Wenn Sie noch keinen Hauptschlüssel haben, werden Sie aufgefordert, einen zu erstellen. Wenn Sie bereits einen haben, müssen Sie das Passwort eingeben. Klicken Sie auf Weiter.
Sie müssen eine Firewall-Regel für Ihren Server erstellen oder Sie können einen Subnetz-IP-Bereich eingeben. Treffen Sie Ihre Auswahl und klicken Sie auf Weiter.
Hier haben sich die Dinge wirklich geändert, und ich werde die Verwendung dieser Funktion überdenken. Microsoft hat eine Database Stretch Unit (DSU) erstellt, damit Sie die Leistung, die Sie für Stretch-Daten benötigen, hoch- oder herunterskalieren können. Ab Juni 2016 werden die aktuellen Preise sowohl für Rechenleistung als auch für Speicher in Rechnung gestellt, die Sie in der Abbildung oben sehen. Für meine migrierte 15-MB-Tabelle wurden mir 61 USD pro Monat für die Speicherung sowie das Mindest-DSU-Level (100) von 912,50 USD pro Monat berechnet. DSU-Stufen reichen von:
| DSU-Level | Stundenpreis | Maximale monatliche Kosten (Monate mit 31 Tagen) |
|---|---|---|
| 100 | 1,25 $ | $930 |
| 200 | 2,50 $ | 1.860 $ |
| 300 | 3,75 $ | 2.790 $ |
| 400 | 5,00 $ | 3.720 $ |
| 500 | 6,25 $ | 4.650 $ |
| 600 | $7,50 | 5.580 $ |
| 1000 | 12,50 $ | 9.300 $ |
| 1200 | 15,00 $ | 11.160 $ |
| 1500 | 18,75 $ | 13.950 $ |
| 2000 | $25,00 | 18.600 $ |
Warum hat mir der Assistent nur 912,50 $ gesagt, wenn das Preisblatt anzeigt, dass es 900 $ für Juni sein sollte (oder anteilig basierend auf der Anzahl der verbleibenden Tage im Juni)? Deine Vermutung ist genauso gut wie meine; Ich habe verschiedene mathematische Sachen ausprobiert und bin leer ausgegangen. Hier erfahren Sie mehr über die Preismodelle:
- Preise für die SQL Server-Stretch-Datenbank
Bevor ich etwas über diese neue Abrechnungsmethode für DSU erfuhr, könnte ich argumentieren, dass die Verwendung von Stretch Database eine sehr kostengünstige Methode zum Speichern kalter Daten (nicht verwendeter Daten) in der Cloud wäre. Indem Sie diese Daten in Azure ausdehnen, könnten Sie einen großen Teil älterer Daten migrieren, was die Größe (und damit die Kosten) Ihrer lokalen Sicherungen verringern würde. Für den Fall, dass Sie eine Datenbank wiederherstellen müssten, müssten Sie einfach die Verbindung zu Azure für die ausgeweiteten Daten herstellen, wodurch die Notwendigkeit einer Wiederherstellung entfällt. Da die minimalen Kosten jedoch fast 1.000 $ pro Monat für die Low-End-DSU-Skala betragen, werden viele Unternehmen feststellen, dass es viel billiger ist, die Daten auf einer weniger teuren Speicherebene in ihrem Rechenzentrum aufzubewahren und andere Methoden für HA zu finden, wie z Spiegelung, Protokollversand oder Verfügbarkeitsgruppen.
Klicken Sie auf Fertig stellen, um mit der Migration zu beginnen.
Herzlichen Glückwunsch, ich habe jetzt die SALES2-Tabelle in eine Azure SQL-Datenbank migriert
Deaktivieren Sie eine Stretch-Tabelle
Wenn Sie in den frühen Vorschauversionen von Stretch Database eine Stretch-Tabelle deaktivieren wollten, mussten Sie eine neue Tabelle erstellen und die Stretch-Daten darin einfügen. Sobald alle Daten kopiert wurden, müssten Sie entweder die Tabellen manuell austauschen, indem Sie sie umbenennen, oder die gestreckten Daten manuell wieder in die Produktionstabelle zusammenführen. Mit der RTM-Version können Sie die Migration weiterhin manuell durchführen, die Daten in Azure belassen oder eine Option zum Zurückholen von Daten aus Azure auswählen.
Unabhängig davon, welche Methode Sie verwenden, um die Daten zurückzubringen, fallen Datenübertragungsgebühren an.
Sicherung und Wiederherstellung einer Stretch-Datenbank
Nachdem Sie Daten in eine Stretch-Datenbank migriert haben, übernimmt Azure die Sicherung der Stretch-Daten. Sicherungen erfolgen mit einem Snapshot, der alle 8 Stunden erstellt wird, und die Snapshots werden 7 Tage lang aufbewahrt. Dadurch können Sie bis zu 21 Zeitpunkte der letzten 7 Tage wiederherstellen.
Sie müssen keine Änderungen an Ihren aktuellen lokalen Backup-Routinen vornehmen. Alle erstellten lokalen Sicherungen enthalten alle lokalen Daten und geeigneten Daten, die noch nicht migriert wurden. Dies wird als flache Sicherung bezeichnet und enthält keine Daten, die bereits zu Azure migriert wurden.
DBCC-CHECKDB
Sie können CHECKDB auch nicht für Daten ausführen, die zu Azure migriert wurden.
Als ich vor der Migration DBCC CHECKDB auf meiner STRETCH-Datenbank ausführte, erhielt ich die folgenden Ergebnisse für die SALES2-Tabelle:
DBCC-Ergebnisse für „SALES2“.Es gibt 45860 Zeilen auf 1901 Seiten für das Objekt „SALES2“.
Nach der Migration erhielt ich die folgende Ausgabe für die SALES2-Tabelle (Hervorhebung von mir):
DBCC-Ergebnisse für 'SALES2'.Es gibt 0 Zeilen in 1901-Seiten für Objekt "SALES2".
Sie können DBCC CHECKDB für Azure SQL-Datenbank ausführen, da Sie jedoch keine direkte Verbindung mit der ausgeweiteten Azure SQL-Datenbank herstellen können, können Sie DBCC CHECKDB derzeit nicht speziell für die ausgeweiteten Daten manuell ausführen. Ich kann keine Dokumentation finden, die besagt, dass Azure Konsistenzprüfungen für diese Datenbanken durchführt.
Dies birgt meiner Meinung nach ein erhebliches Risiko.
Zusammenfassung
Stretch Database ist eine einfache Möglichkeit, Archivdaten nach Microsoft Azure zu migrieren, sofern Ihre Datenbank dies unterstützt. Derzeit gibt es in SQL Server 2016 RTM viele Einschränkungen bei Tabellen-, Daten- und Spalteneigenschaften, Daten- und Spaltentypen, Einschränkungen und Indizes. Wenn Sie nicht durch diese Einschränkungen eingeschränkt sind, ist Stretch Database eine einfache Möglichkeit, historische Daten in Azure SQL-Datenbank zu migrieren, um lokalen Speicherplatz freizugeben und die Wiederherstellungszeiten dieser Datenbanken zu verkürzen, wenn sich die Kosten lohnen. Sie müssen sich zumindest vorläufig auch damit auskennen, dass Sie DBCC CHECKDB nicht für migrierte Daten ausführen können. Das Verwalten von Wiederherstellungen wird auch etwas kniffliger, da die Verbindung zwischen der SQL Server-Datenbank und der Remote-Azure-Datenbank wiederhergestellt werden muss.
