Microsoft AZ-104: Azure-Datenbanken und Datendienste — Lernleitfaden

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Teil des Microsoft Azure Administrator Associate AZ-104 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Die Datenbank- und Datendienste von Azure umfassen verwaltete relationale Engines, global verteilte NoSQL-Datenbanken, In-Memory-Caching, groß angelegte Analysen sowie Integration/Orchestrierung. Als Administrator müssen Sie Kaufmodelle, Service-Tiers, Netzwerk- und Sicherheitstopologie, Backup/DR-Semantik und wie Dienste für Leistung, Kosten und Ausfallsicherheit kombiniert werden, verstehen. Dieser Abschnitt konzentriert sich auf operative Entscheidungen und Plattformfunktionen, die Sie im täglichen Betrieb konfigurieren: Bereitstellungsmodelle (DTU vs. vCore), elastische Pools, Backup und Langzeitaufbewahrung, Geo-Replikation und Failover, in VNets eingebundene Managed Instances, Verteilung und Konsistenz bei Cosmos DB, HA/Lesereplikate für Open-Source-relationale Datenbanken, Synapse-Engines und Data Factory-Runtimes.

Relationale Azure-Datenbanken (SQL Database, Managed Instance, MySQL/PostgreSQL)

Azure SQL Database bietet zwei Kaufmodelle. Das DTU-Modell bündelt CPU, Arbeitsspeicher und IOPS in Database Transaction Units (DTUs) mit den Tiers Basic, Standard und Premium; es ist einfach, aber intransparent und eignet sich gut für stabile, vorhersagbare Workloads und die Dimensionierung von Altsystemen. Das vCore-Modell legt die CPU-Generation/-Anzahl und den Arbeitsspeicher offen, gepaart mit Steuerelementen für Speicher und IOPS. vCore ermöglicht eine transparente Dimensionierung, den Azure Hybrid Benefit und Rabatte für reservierte Kapazitäten. Innerhalb von vCore sind die Service-Tiers auf Workload- und Verfügbarkeitsmuster abgestimmt: General Purpose verwendet entfernten Premium-SSD- oder Azure Premium-Speicher mit einer Standard-Verfügbarkeitsarchitektur; Business Critical platziert Compute und Speicher auf lokalen SSDs mit mehreren Replikaten, geringer Latenz und integrierter Leseskalierung (Read Scale-Out); Hyperscale entkoppelt Compute und Speicher mit Page-Servern für nahezu sofortige Skalierung und sehr große Datenbanken. Für einzelne Datenbanken skaliert der serverlose Compute-Tier (vCore) die CPU elastisch und kann automatisch pausieren, um Kosten im Leerlauf zu senken.

Elastische Pools teilen die Rechenleistung auf mehrere Datenbanken auf, um spitzenlastige, phasenverschobene Workloads zu geringeren Gesamtkosten abzufangen. Pools sind in DTU- (eDTU) und vCore-Varianten verfügbar. Sie legen pro Datenbank Min/Max-Grenzwerte fest, um „laute Nachbarn“ (Noisy Neighbors) einzudämmen, und einen Pool-Maximalwert, um die Ausgaben zu kontrollieren. Eine Überbuchung (Oversubscription) ist akzeptabel, wenn die Lastspitzen kurz und unkorreliert sind. Die Dimensionierung des Pools hängt vom summierten durchschnittlichen Verbrauch plus einem Puffer für Gleichzeitigkeit ab; die Überwachung der Metriken pro Datenbank und des Pools ist entscheidend für die Einhaltung von SLOs.

Backups erfolgen automatisch. Azure SQL pflegt vollständige, differenzielle und Transaktionsprotokoll-Backups mit Point-in-Time-Restore (PITR) zu jeder Sekunde innerhalb des Aufbewahrungsfensters (typischerweise 7–35 Tage, abhängig von Tier und Speicherkonfiguration). Die Langzeitaufbewahrung (Long-Term Retention, LTR) speichert wöchentliche vollständige Backups für Jahre in RA-GRS-Speicher; Sie können ein LTR-Backup als neue Datenbank auf jedem Server innerhalb derselben Subscription und Region wiederherstellen. Eine regionsübergreifende Wiederherstellung ist verfügbar, wenn georedundanter Backup-Speicher aktiviert ist. Wiederherstellungen erstellen eine neue Datenbank; sie überschreiben nicht die bestehende.

Zu den Geo-Replikationsoptionen gehören die aktive Geo-Replikation für einzelne Datenbanken und Pools (bis zu vier lesbare sekundäre Replikate mit asynchroner Replikation) und Auto-Failover-Gruppen auf der Ebene des logischen Servers. Failover-Gruppen bündeln mehrere Datenbanken (oder einen ganzen Server) mit Geo-DR, einem Lese-/Schreib-Listener-Endpunkt, einem schreibgeschützten Endpunkt zur Auslagerung von Lesevorgängen, einem zustandsbasierten automatischen Failover und einer DNS-basierten Umleitung. Business Critical bietet zudem Read Scale-Out über ein lokales lesbares Replikat, was eine sofortige Auslagerung von Leseworkloads ohne die Komplexität einer regionsübergreifenden Konfiguration ermöglicht.

Azure SQL Managed Instance (MI) bietet eine Kompatibilität von nahezu 100 % mit der SQL Server-Engine, einschließlich SQL Agent, datenbankübergreifenden Abfragen, CLR, Verbindungsservern (Linked Servers), Service Broker und nativer Sicherung/Wiederherstellung von .bak-Dateien aus Azure Blob Storage. MI wird in ein VNet eingebunden (VNet-injected): Sie stellen es in einem dedizierten, delegierten Subnetz mit privaten IPs und NSG/UDR-Steuerelementen bereit; planen Sie die Subnetzgröße und den Adressraum im Voraus, da eine spätere Größenänderung von Subnetzen komplex ist. Migrationspfade umfassen den Azure Database Migration Service (Online-/Offline-Umstellungen), die native Sicherung/Wiederherstellung zu einer URL in MI und die Transaktionsreplikation von einem lokalen SQL Server zu MI. Wählen Sie MI, wenn Sie eine Parität der Angriffsfläche (Surface Area) oder instanzbezogene Funktionen benötigen, die einzelne Datenbanken nicht bieten.

Azure Database for MySQL und Azure Database for PostgreSQL (Flexible Server) bieten verwaltete OSS-Engines mit Kontrolle über Wartungsfenster, Start/Stopp zur Kosteneinsparung, burstable und universelle Compute-Optionen, automatisches Speicherwachstum (Auto-Grow) und VNet-Integration. Flexible Server bietet Hochverfügbarkeit mit synchroner Replikation; Sie können zwischen zonenredundanter HA über Verfügbarkeitszonen (Availability Zones) für eine stärkere Fehlerisolierung oder Same-Zone-HA für eine geringere Schreiblatenz wählen. Lesereplikate (Read Replicas) sind für die Skalierung von Lesevorgängen verfügbar und können innerhalb einer Region oder regionsübergreifend bereitgestellt werden; sie verwenden asynchrone Replikation und sind ideal für Analysen, Reporting oder leselastige Microservices. Stufen Sie bei Bedarf ein Replikat für ein Failover oder eine regionale Erweiterung hoch, wobei eine potenzielle Replikationsverzögerung (Replication Lag) zu berücksichtigen ist.

Verteilte Daten und Caching (Cosmos DB und Azure Cache for Redis)

Azure Cosmos DB ist eine global verteilte Multi-Model-Datenbank, die APIs für Core (SQL), MongoDB, Cassandra, Gremlin (Graph) und Table anbietet. Die Wahl der API bestimmt die Kompatibilität der Client-Treiber und die Semantik des Datenmodells; im Betrieb verwalten Sie den Durchsatz (bereitgestellte RUs oder Autoskalierung) und die Partitionen unabhängig von der API. Die Daten werden horizontal durch einen Partitionsschlüssel partitioniert, der eine hohe Kardinalität und eine gleichmäßige Zugriffsverteilung aufweisen muss, um Hot Partitions zu vermeiden; vermeiden Sie monoton ansteigende Schlüssel und ziehen Sie hierarchische Partitionsschlüssel in Betracht, wenn zusammengesetzte Zugriffsmuster existieren. Partitionsübergreifende Abfragen werden unterstützt, verbrauchen aber mehr RUs; platzieren Sie zusammengehörige Daten nach Möglichkeit über den Partitionsschlüssel am selben Ort (Co-Location).

Konsistenzebenen sind pro Konto, Datenbank oder Anfrage einstellbar: Strong garantiert Linearisierbarkeit; Bounded Staleness begrenzt die Veraltung nach Zeit oder Version; Session (Standard) bietet Read-Your-Writes für eine Sitzung; Consistent Prefix garantiert die Reihenfolge ohne vollständige Konsistenz; Eventual maximiert Verfügbarkeit und Leistung. Wählen Sie für Schreibvorgänge in mehreren Regionen eine geeignete Konfliktlösungsrichtlinie (LastWriterWins oder benutzerdefiniert über Stored Procedures) und definieren Sie Failover-Prioritäten. Die globale Verteilung fügt Regionen mit einem Klick hinzu; der Dienst kümmert sich um Replikation, Failover und latenzoptimiertes Routing mit SLAs für Durchsatz, Latenz, Verfügbarkeit und Konsistenz.

Azure Cache for Redis bietet Latenzzeiten im Sub-Millisekunden-Bereich, unterstützt durch Redis. Die Tiers unterscheiden sich in ihren Fähigkeiten: Basic (einzelner Knoten, Dev/Test), Standard (repliziertes Zwei-Knoten-Setup mit Primär-/Replikat-Knoten und SLA), Premium (größere Instanzen, Clustering, Persistenz, VNet-Injektion, Geo-Replikation und Redis-Module wie Bloom), Enterprise und Enterprise Flash (basierend auf Redis Enterprise mit erweitertem Clustering, aktiver Geo-Replikation für Multi-Primary-Schreibvorgänge und Flash-gestützten größeren Caches). Eviction Policies (Verdrängungsrichtlinien) definieren das Verhalten bei Speicherdruck: noeviction (Fehler bei Schreibvorgängen), allkeys-lru/lfu/random (berücksichtigt alle Schlüssel) und volatile-lru/lfu/ttl/random (berücksichtigt nur Schlüssel mit TTL). Für das Session-Caching verwenden Sie den Premium-Tier oder höher für Persistenz, wenn Sie sich keinen Sitzungsverlust leisten können, aktivieren Sie TTLs für Schlüssel, um das Wachstum zu begrenzen, und ziehen Sie Clustering für Durchsatz und Skalierung in Betracht. Platzieren Sie den Cache in derselben Region und demselben virtuellen Netzwerk wie die App-Server, um die Latenz zu minimieren; verwenden Sie Managed Identity oder Zugriffsschlüssel und erzwingen Sie die Netzwerkisolierung über Private Link oder VNet-Injektion.

Analytik und Integration (Synapse Analytics und Data Factory)

Azure Synapse Analytics vereint Data Warehousing, Big Data und Datenintegration. Der dedizierte SQL-Pool (ehemals SQL DW) ist eine MPP-Engine mit Hash-/Round-Robin-Verteilungen, replizierten Tabellen und Result-Set Caching. Sie können die Rechenleistung hoch- oder herunterskalieren, um SLA-Fenster einzuhalten, und sie anhalten, um nur für den Speicher zu bezahlen. Workload-Isolierung kann mit Workload-Gruppen und Wichtigkeitseinstellungen erreicht werden, um kritische Abfragen zu schützen. Der serverlose SQL-Pool bietet On-Demand-T-SQL für Daten in Azure Data Lake Storage Gen2 ohne Bereitstellung; Sie zahlen pro gescanntem TB und können Schemata mithilfe von Views für semantische Ebenen externalisieren. Spark-Pools bringen Apache Spark in Synapse mit Autoskalierung und On-Demand-Clustern und ermöglichen so Notebooks, Delta Lake und Machine Learning mit integrierter Sicherheit und Data Lineage; Sie können Lakehouse-Daten zwischen Spark- und SQL-Engines gemeinsam nutzen.

Azure Data Factory (ADF) orchestriert die Verschiebung und Transformation von Daten. Pipelines koordinieren Aktivitäten wie Copy, Data Flow (Spark-basierte Mapping Flows) und externe Berechnungen (Databricks, Synapse, Functions). Datasets definieren die Form und den Speicherort der Daten, während Linked Services die Verbindungsdetails (Authentifizierung, Endpunkte) zu Quellen/Zielen kapseln. Integration Runtimes (IRs) stellen die Rechen- und Netzwerkebene bereit: Azure IR für cloud-native Verschiebungen und Transformationen, Self-hosted IR für On-Premises- oder private Netzwerkquellen über ausgehendes HTTPS und Azure-SSIS IR für das Lift-and-Shift von SSIS-Paketen. Trigger (Zeitplan, Tumbling Window, ereignisbasiert) ermöglichen eine wiederholbare Orchestrierung; ein verwaltetes virtuelles Netzwerk und private Endpunkte können für den Schutz vor Datenexfiltration und für konforme Konnektivität aktiviert werden. Parametrisierung und Key Vault-Integration unterstützen wiederverwendbare, sichere Muster für die Überführung zwischen Umgebungen (Dev/Test/Prod).

Geschäftskontinuität, Geo-Funktionen und elastische Pools

Sicherungs- und Wiederherstellungsstrategien unterscheiden sich je nach Dienst, haben aber gemeinsame Kernthemen: Automatisieren Sie, testen Sie Wiederherstellungen regelmäßig und trennen Sie PITR (für Betriebsfehler) von LTR (für Compliance). In Azure SQL verwenden Sie PITR für versehentlich gelöschte Objekte oder fehlerhafte Bereitstellungen; speichern Sie wöchentliche vollständige LTR-Backups in RA-GRS für die regulatorische Aufbewahrung und die Wiederherstellung im Rahmen der regionsübergreifenden Notfallwiederherstellung. Für MySQL/PostgreSQL Flexible Server aktivieren Sie automatisierte Backups mit georedundantem Speicher, wo dies unterstützt wird, legen Sie die Aufbewahrungsdauer gemäß der Richtlinie fest und validieren Sie Point-in-Time-Wiederherstellungen auf alternativen Servern. Cosmos DB-Konten mit mehreren Regionen ermöglichen ein automatisches Failover; kombinieren Sie dies mit Multi-Region-Schreibvorgängen, wenn das RPO null sein muss und die Anwendung Konflikte deterministisch lösen kann.

Georeplikation und Auto-Failover-Gruppen in Azure SQL bieten DR und die Auslagerung von Lesevorgängen. Verwenden Sie die aktive Georeplikation für eine einzelne Datenbank/einen Pool, wenn Sie Sekundärinstanzen explizit verwalten möchten; verwenden Sie Auto-Failover-Gruppen, um viele Datenbanken zu gruppieren und DNS-basierte Listener sowie automatisches Failover zu erhalten. Wo Lesevorgänge mit geringer Latenz wichtig sind, aber DR nicht das Ziel ist, verwenden Sie die horizontale Leseskalierung (Read Scale-Out) von Business Critical oder benannte Replikate von Hyperscale, um Analyse- und Reporting-Workloads von der primären Instanz fernzuhalten. Überwachen Sie die Replikationsverzögerung und die Signale zum Failover-Zustand und testen Sie Failover-Übungen, um RTO/RPO zu validieren.

Elastische Pools sind Hebel zur Kostenoptimierung für mandantenfähige SaaS-Lösungen und Flotten kleiner Datenbanken. In DTU-basierten Pools weisen Sie eDTUs mit Obergrenzen pro Datenbank zu; in vCore-Pools weisen Sie vCores, Arbeitsspeicher und E/A-Durchsatz mit maximalen vCores pro Datenbank und E/A-Steuerung zu. Dimensionieren Sie die Pools richtig, indem Sie die Nutzung im 95. Perzentil pro Datenbank messen und die Poolkapazität an die Parallelitätsmuster anpassen; erhöhen Sie die Obergrenzen pro Datenbank für Mandanten mit höheren SLOs und erwägen Sie, die Pools nach Workload-Klassen aufzuteilen (z. B. intensive vs. leichte Mandanten). Verwenden Sie Warnungen für Pool- und Datenbanklimits, um eine Sättigung frühzeitig zu erkennen. Wenn eine Handvoll Datenbanken konstant die maximalen Obergrenzen erreichen, verschieben Sie sie auf dedizierte Rechenleistung oder in einen separaten Pool, um die Vorhersagbarkeit aufrechtzuerhalten.

Praktisches Problemszenario

Starbucks muss seine globale Loyalty-Plattform modernisieren, um Spitzenlasten während Werbeaktionen zu bewältigen, den Betriebsaufwand zu reduzieren und Analysen zu unterstützen, ohne den weltweiten Filialbetrieb zu stören.

1. Partitionieren des operativen Datenspeichers:

• Wählen Sie Azure Cosmos DB (Core SQL API) für Kundeninteraktionen und Prämienereignisse, um eine globale Verteilung mit geringer Latenz zu erreichen. Konfigurieren Sie Multi-Region-Schreibvorgänge in Regionen nahe der wichtigsten Kundenpopulationen und wählen Sie die Sitzungskonsistenz (Session), um das Lesen eigener Schreibvorgänge mit der Leistung in Einklang zu bringen. Wählen Sie einen Partitionsschlüssel mit hoher Kardinalität wie customerId oder einen zusammengesetzten hierarchischen Schlüssel (customerId, eventMonth), um den Durchsatz zu verteilen und gängige Abfragemuster zu unterstützen.

2. Implementieren von Transaktionskonto- und Katalogdaten:

• Stellen Sie Azure SQL Managed Instance für Kontostände, Einlösungen und SKU/Katalogdaten bereit, da eine nahezu 100%ige SQL Server-Kompatibilität für bestehende gespeicherte Prozeduren und datenbankübergreifende Logik erforderlich ist. Platzieren Sie die MI in einem dedizierten, delegierten Subnetz mit NSGs und Routing-Tabellen, wie es für die VNet-Integration erforderlich ist, um den privaten Zugriff von Anwendungs-Subnetzen und ExpressRoute zu ermöglichen.

3. Bereitstellen von globaler Leseskalierung und DR für relationale Workloads:

• Für neue Microservices, die Azure SQL Database verwenden, nutzen Sie vCore Business Critical für geringe Latenz und horizontale Leseskalierung. Erstellen Sie eine Auto-Failover-Gruppe zu einer gekoppelten Region mit schreibgeschützten Listener-Endpunkten für lokalisierte Lesevorgänge und automatisches Failover, um die DR-Ziele zu erreichen.

4. Hinzufügen eines Sitzungsmanagements mit geringer Latenz:

• Stellen Sie Azure Cache for Redis Premium mit Clustering und Datenpersistenz für Web- und mobile Sitzungstoken bereit. Legen Sie eine allkeys-lfu-Entfernungsrichtlinie fest, um häufig aufgerufene Sitzungen im Speicher zu halten. Integrieren Sie den Cache im selben VNet und in derselben Region wie die Anwendungsschicht, um die Latenz zu minimieren.

5. Orchestrieren der Datenverschiebung und Aufbau von Analysen:

• Verwenden Sie Azure Data Factory, um operative Daten (aus dem Cosmos DB-Änderungsfeed und SQL MI) in Azure Data Lake Storage Gen2 zu kopieren. Setzen Sie eine Managed VNet IR mit privaten Endpunkten ein, um Datenexfiltration zu verhindern. Parametrisieren Sie Pipelines und verwenden Sie Tumbling-Window-Trigger, um eine geordnete Verarbeitung zu garantieren.

6. Ermöglichen von Unternehmensanalysen mit elastischer Kostenkontrolle:

• In Azure Synapse Analytics verwenden Sie einen serverlosen SQL-Pool für die Ad-hoc-Exploration von Parquet-Daten und einen dedizierten SQL-Pool für kuratierte BI-Modelle mit hoher Parallelität und vorhersagbarer Leistung. Erstellen Sie Spark-Pools für das Feature-Engineering zum Loyalitätsverhalten und schreiben Sie Delta-Tabellen in den Lake, um die Interoperabilität zwischen Spark und SQL zu gewährleisten.

7. Governance, Backups und Aufbewahrung:

• Konfigurieren Sie die Prioritäten für das automatische Failover von Cosmos DB und überwachen Sie Konflikte mithilfe von LastWriterWins mit einem Zeitstempelfeld. Für Azure SQL Database und MI überprüfen Sie die PITR-Fenster und aktivieren Sie LTR, um die Aufbewahrungsanforderungen zur Einhaltung von Compliance zu erfüllen. Für Flexible Server-Instanzen, die unterstützende OSS-Dienste unterstützen (z. B. regionale Filialtelemetrie in PostgreSQL), aktivieren Sie zonenredundante Hochverfügbarkeit und konfigurieren Sie Lesereplikate für das Reporting.

Warum diese Dienste: Die globale Verteilung und anpassbare Konsistenz von Cosmos DB adressieren weltweite latenzempfindliche Interaktionen; MI bewahrt komplexe SQL Server-Funktionen und bietet gleichzeitig einen verwalteten Betrieb; Business Critical-Datenbanken liefern lokale Leseskalierung ohne regionsübergreifende Latenz; Redis gewährleistet den Sitzungszugriff im Sub-Millisekunden-Bereich bei Lastspitzen; ADF ermöglicht eine sichere, gesteuerte Datenverschiebung aus privaten Netzwerken; Synapse kombiniert On-Demand- und bereitgestellte Analysen für kosteneffiziente, skalierbare Einblicke. Diese Zusammensetzung erfüllt die Performance-SLOs während Werbeaktionen, reduziert den administrativen Aufwand durch verwaltetes PaaS und setzt klare RTO/RPO- und Compliance-Grenzen durch.

← Azure App Service und PaaS-Compute · Alle Domänen · Azure Monitor →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Microsoft durchsuchen →