Erläutern von Bereitstellungsoptionen
Azure SQL-Datenbank, eine PaaS-Lösung (Platform-as-a-Service), bietet hohe Skalierbarkeit und minimale Wartung. Dies macht sie zu einer hervorragenden Lösung für bestimmte Workloads. Sie eignet sich für die Entwicklung neuer Anwendungen und bietet Entwicklern erhebliche Flexibilität beim Erstellen neuer Dienste sowie präzise Bereitstellungsoptionen im großen Stil. Diese wartungsarme Lösung eignet sich ideal für verschiedene Workloads und stellt eine effiziente und effektive Anwendungsentwicklung sicher.
Grundlegendes zu Bereitstellungsmodellen
Bei der Bereitstellung von Azure SQL-Datenbank gibt es zwei primäre Bereitstellungsmodelle: einzelne Datenbank und elastische Pools. Im Modell mit Pools für elastische Datenbanken werden Ressourcen von mehreren Datenbanken innerhalb desselben Pools gemeinsam genutzt, während im Modell mit Einzeldatenbanken Ressourcen unabhängig für jede Datenbank verwaltet werden.
Ähnlich wie VMs kann SQL-Datenbank mithilfe verschiedener Methoden bereitgestellt werden, u. a. mit PowerShell, der Azure CLI oder dem Azure-Portal.
Einzeldatenbank
Das Bereitstellungsmodell für Einzeldatenbanken ist die einfachste Methode zur Verwendung von Azure SQL-Datenbank. In diesem Modell verwalten Sie jede Datenbank einzeln im Hinblick auf Skalierung und Datengröße. Jede Datenbank verfügt über eigene dedizierte Ressourcen, auch wenn mehrere Datenbanken auf demselben logischen Server bereitgestellt werden.
Sie können die Ressourcenauslastung jeder Datenbank über das Azure-Portal überwachen. Mit diesem Feature können Sie die Leistung Ihrer Datenbanken ganz einfach nachverfolgen und bewerten.
Pools für elastische Datenbanken
Mit Pools für elastische Datenbanken können Sie Speicher- und Computeressourcen einer Gruppe von Datenbanken zuordnen. Dies vereinfacht die Verwaltung verglichen mit der separaten Behandlung der einzelnen Datenbanken. Sie sind einfacher zu skalieren als Einzeldatenbanken, da Änderungen am Pool für elastische Datenbanken Ressourcen automatisch für alle enthaltenen Datenbanken anpassen.
Dieses Modell ist kosteneffizient für Software-as-a-Service-Anwendungen, da Ressourcen von allen Datenbanken gemeinsam genutzt werden. Sie können Ressourcen mithilfe des DTU-basierten oder des vCore-basierten Kaufmodells konfigurieren.
Es ist wichtig, Ressourcen kontinuierlich zu überwachen, um Leistungsspitzen zu identifizieren, die sich auf andere Datenbanken im Pool auswirken könnten. Durch die regelmäßige Überarbeitung Ihrer Zuordnungsstrategie wird sichergestellt, dass ausreichende Ressourcen für alle Datenbanken vorhanden sind.
Pools für elastische Datenbanken eignen sich ideal für eine mehrinstanzenfähige Architektur mit geringer durchschnittlicher Auslastung, bei der jeder Mandant über eine eigene Kopie der Datenbank verfügt.
Grundlegendes zu Kaufmodellen
Nachdem Sie das entsprechende Bereitstellungsmodell für Ihre SQL-Datenbank-Instanz ausgewählt haben, besteht der nächste Schritt darin, das Kaufmodell auszuwählen, das am besten zu Ihren Workload- und Budgetanforderungen passt. Azure SQL Database bietet zwei Einkaufsmodelle: das vCore-Modell und das DTU-basierte Modell. Jedes Modell hat seine eigenen Vorteile. Daher ist es wichtig zu wissen, welches Modell am besten zu Ihren Workloadanforderungen und Kostenüberlegungen passt.
vCore-basiertes Modell
Dies ist das empfohlene Kaufmodell, bei dem Compute- und Speicherressourcen entkoppelt sind. Dies bedeutet, dass Sie Speicher- und Computeressourcen unabhängig voneinander skalieren können. Diese Flexibilität stellt sicher, dass Sie Ressourcen entsprechend Ihren spezifischen Anforderungen anpassen können, ohne dass sich dies auf andere Komponenten auswirkt.
Im vCore-basierten Kaufmodell hängen Ihre Kosten von mehreren Faktoren ab, u. a. von der Dienstebene, der Hardwarekonfiguration, der Anzahl der V-Kerne und der Menge des Arbeitsspeichers, dem reservierten Datenbankspeicher und dem tatsächlichen Sicherungsspeicher.
Hinweis
Details zu den Preisen finden Sie auf der Azure SQL-Datenbank-Preisseite.
Eine Dienstebene ist eine vordefinierte Konfiguration, die die Leistung, den Speichertyp, die Hochverfügbarkeit, die Notfallwiederherstellungsoptionen und die Verfügbarkeit bestimmter Features für Ihre Datenbank bestimmt.
Das vCore-Kaufmodell bietet drei Optionen für die Dienstebene:
| Dienstebene | Funktion |
|---|---|
| Allgemeiner Zweck | Diese Dienstebene ist für weniger intensive Vorgänge konzipiert und bietet ein kostengünstiges Gleichgewicht von Compute- und Speicheroptionen. Sie umfasst sowohl bereitgestellte als auch serverlose Computeebenen, die Flexibilität bieten, unterschiedliche Workloadanforderungen zu erfüllen und gleichzeitig das Budget zu optimieren. |
| Unternehmenskritisch | Diese Ebene eignet sich ideal für Anwendungen, die Speicher mit geringer Latenz und Hochleistung erfordern. Sie unterstützt In-Memory-OLTP und enthält integrierte schreibgeschützte Replikate. Außerdem bietet sie mehr Arbeitsspeicher pro Kern und verwendet lokalen SSD-Speicher und eignet sich damit gut für leistungsempfindliche Workloads. |
| Hyperskala | Diese Ebene ist auf Anwendungen mit großen Datenbanken und Anforderungen an hohen Durchsatz zugeschnitten. Hyperscale führt erweiterte Funktionen für die horizontale Skalierung ein, die das Hinzufügen von Computeknoten bei wachsendem Datenvolumen ermöglichen. Dies wird ausschließlich für SQL-Einzeldatenbanken unterstützt und ermöglicht eine erhebliche Skalierung von Speicher- und Computeressourcen über die Grenzen der Dienstebenen „Universell“ und „Unternehmenskritisch“ hinaus. |
DTU-basiertes Modell
Im DTU-Modell gibt es drei Dienstebenen: Basic, Standard und Premium. Compute- und Speicherressourcen sind von der DTU-Ebene abhängig und bieten eine Reihe von Leistungsfunktionen mit einem festen Speicherlimit, einer festen Sicherungsaufbewahrung und festen Kosten.
Wenn Ihre Datenbank beispielsweise das maximale Speicherlimit erreicht, müssten Sie Ihre DTU-Kapazität erhöhen, auch wenn die Computeauslastung gering ist. Darüber hinaus können Skalierungsvorgänge in Azure SQL-Datenbank kurze Verbindungsunterbrechungen am Ende des Prozesses verursachen. Dies kann in zwei Standard-Szenarien auftreten:
- Initiieren eines Skalierungsvorgangs, der ein internes Failover erfordert.
- Hinzufügen oder Entfernen von Datenbanken zum oder aus dem Pool für elastische Datenbanken.
Hinweis
Um Verbindungsfehler zu behandeln, implementieren Sie die richtige Wiederholungslogik in Ihrer Anwendung.
Das Verständnis des Zusammenspiels zwischen Bereitstellungs- und Kaufmodellen ist entscheidend für die Optimierung von Leistung und Kosteneffizienz. Durch sorgfältige Auswahl der richtigen Kombination können Sie sicherstellen, dass Ihre Bereitstellung von Azure SQL-Datenbank die Anforderungen Ihrer Anwendung erfüllt, während Sie das Budget einhalten.
Wenn Sie sich beispielsweise für das Bereitstellungsmodell für Einzeldatenbanken entscheiden, bevorzugen Sie möglicherweise das vCore-Kaufmodell aufgrund seiner Flexibilität bei der unabhängigen Skalierung von Compute- und Speicherressourcen. Wenn Sie hingegen das Bereitstellungsmodell mit Pools für elastische Datenbanken auswählen, ist das DTU-basierte Kaufmodell u. U. kostengünstiger, da Sie Ressourcen für mehrere Datenbanken innerhalb des Pools freigeben können.
Ausführen von Sicherung und Wiederherstellung
Azure bietet nahtlose Sicherungs- und Wiederherstellungsfunktionen für SQL-Datenbank. Hier sind einige wichtige Features:
Fortlaufende Sicherung
Azure SQL-Datenbank stellt regelmäßige Sicherungen sicher und kopiert sie kontinuierlich in den georedundanten Speicher mit Lesezugriff (RA-GRS). Vollständige Sicherungen werden wöchentlich erstellt, differenzielle Sicherungen alle 12 bis 24 Stunden und Transaktionsprotokollsicherungen alle fünf bis zehn Minuten.
Geowiederherstellung
Mit georedundanten Sicherungen können Sie standardmäßig Datenbanken mühelos in verschiedenen Regionen wiederherstellen, was für weniger strenge Notfallwiederherstellungsszenarien nützlich ist. Der Sicherungsspeicher wird separat abgerechnet, aber ohne zusätzliche Kosten mit der maximalen Größe der ausgewählten Datenebene erstellt. Die Dauer der Geowiederherstellung hängt von der Datenbankgröße, Transaktionsprotokollen und gleichzeitigen Wiederherstellungsanforderungen ab.
Hinweis
Die Geowiederherstellung ist verfügbar, wenn die Redundanzeigenschaft des Sicherungsspeichers auf georedundanten Sicherungsspeicher festgelegt ist.
Zeitpunktwiederherstellung (Point in Time Restore, PITR)
Ermöglicht es Ihnen, eine bestimmte Zeitpunkt-Aufbewahrungsrichtlinie für jede Datenbank mit einer Dauer von 1 bis 35 Tagen zu konfigurieren. (Der Standardwert ist sieben Tage.) Sie können auch einen bestimmten Zeitpunkt von Datenbanken innerhalb desselben Servers wiederherstellen. Dazu können Sie das Azure-Portal, PowerShell, die CLI oder die REST-API verwenden.
Langzeitaufbewahrung (Long-Term Retention, LTR)
Langfristige Aufbewahrung ist nützlich für Szenarien, in denen Sie die Aufbewahrungsrichtlinie über den Zeitraum hinaus festlegen müssen, der von Azure angeboten wird. Sie können eine Aufbewahrungsrichtlinie für bis zu 10 Jahre festlegen, und diese Option ist standardmäßig deaktiviert.
Weitere Informationen zu automatisierten Sicherungen finden Sie unter Automatisierte Sicherungen – Azure SQL-Datenbank und azure SQL Managed Instance.
Aktivieren der automatischen Optimierung
Die automatische Optimierung ist ein leistungsstarkes integriertes Feature, das maschinelles Lernen anwendet, um die Abfrageleistung zu optimieren. Sie identifiziert automatisch Optimierungsmöglichkeiten und implementiert sie, um die Effizienz Ihrer Datenbank zu verbessern.
Automatische Optimierung umfasst derzeit die folgenden Features:
- Identifizieren teurer Abfragen
- Erzwingen des letzten guten Ausführungsplans
- Hinzufügen von Indizes
- Entfernen von Indizes
Azure-Dienste verwenden erweiterte Algorithmen, um die besten Indizes für Ihr Abfragemuster zu ermitteln. Diese Indizes werden zunächst für eine Kopie Ihrer Datenbank getestet, bevor sie auf die Liveumgebung angewendet werden, um minimale Unterbrechungen sicherzustellen.
Alle Datenbanken erben die Konfiguration vom übergeordneten Server, und Sie können dieses Feature bei Bedarf problemlos deaktivieren. Dank dieser Flexibilität behalten Entwickler die Kontrolle und profitieren gleichzeitig von automatisierten Leistungsverbesserungen.
Verwenden elastischer Abfragen
Mit elastischen Abfragen können Sie T-SQL-Abfragen in mehreren Datenbanken in SQL-Datenbank ausführen. Dieses Feature ist nützlich für Anwendungen, die drei- und vierteilige Namen verwenden, die nicht geändert werden können, und es verbessert die Portabilität durch Vereinfachung der Migration.
Elastische Abfragen unterstützen die folgenden Partitionierungsszenarien:
| Dienstebene | Funktion |
|---|---|
| Vertikale Partitionierung | Wird auch als datenbankübergreifende Abfragen bezeichnet. Daten werden vertikal über mehrere Datenbanken mit unterschiedlichen Schemas hinweg partitioniert. Sie haben z. B. eine Datenbank für Kundendaten und eine andere für Zahlungsinformationen. Mit der vertikalen Partitionierung können Sie datenbankübergreifende Abfragen zwischen diesen Datenbanken ausführen. |
| Horizontale Partitionierung | Wird auch als horizontales Partitionieren bezeichnet. Die Daten werden horizontal partitioniert, um Zeilen auf mehrere horizontal skalierte Datenbanken zu verteilen, die alle das gleiche Schema aufweisen. Diese Topologie unterstützt sowohl Modelle mit einem Mandanten als auch Modelle mit mehreren Mandanten. |
Diese Flexibilität macht elastische Abfragen zu einem leistungsfähigen Tool zum Verwalten und Abfragen von Daten über mehrere Datenbanken hinweg.
Konfigurieren elastischer Aufträge
Das Feature für elastische Aufträge dient als SQL Server-Agent-Ersatz für Azure SQL-Datenbank, ähnlich wie die Multiserververwaltungsfunktion in einer lokalen SQL Server-Instanz.
Mit elastischen Aufträgen können Sie T-SQL-Befehle für verschiedene Zielbereitstellungen ausführen, z. B. für SQL-Datenbank-Instanzen, Pools für elastische Datenbanken in SQL-Datenbank und SQL-Datenbank-Instanzen in Shardzuordnungen. Diese Datenbankressourcen können verschiedene Azure-Abonnements und -Regionen umfassen. Die Funktion für die parallele Ausführung ist nützlich zum Automatisieren von Wartungsaufgaben für Datenbanken und gewährleistet Effizienz und Konsistenz in Ihren Bereitstellungen.
Verschieben von Daten mithilfe der SQL-Datensynchronisierung
Die SQL-Datensynchronisierung ermöglicht die inkrementelle Synchronisierung von Daten über mehrere Datenbanken hinweg, unabhängig davon, ob sie in SQL-Datenbank oder lokal SQL Server ausgeführt werden. Dieses Feature ist nützlich, um intensive Produktionsworkloads für Analysevorgänge oder ungeplante Vorgänge in eine separate Datenbank auszulagern.
Die Datensynchronisierung wird auf einer Hubtopologie ausgeführt, in der eine Datenbank in der Synchronisierungsgruppe als Hub festgelegt ist. Die Synchronisierungsgruppe kann mehrere Mitgliedsdatenbanken enthalten, und die Synchronisierung erfolgt zwischen dem Hub und einzelnen Mitgliedsdatenbanken. Änderungen werden mithilfe von Einfüge-, Aktualisierungs- und Löschtriggern über eine Verlaufstabelle nachverfolgt, die für die Benutzerdatenbank erstellt wird.
Beim Erstellen einer Synchronisierungsgruppe müssen Sie eine Datenbank zum Speichern der Synchronisierungsgruppenmetadaten angeben. Diese Metadaten-Datenbank kann entweder neu oder vorhanden sein, solange sie sich in derselben Region wie Ihre Synchronisierungsgruppe befindet.
Weitere Informationen zum Konfigurieren der SQL-Datensynchronisierung finden Sie im Lernprogramm: Einrichten der SQL-Datensynchronisierung zwischen Datenbanken in Azure SQL-Datenbank und SQL Server.