Handbuch

Eine geschäftskritische SQL-Datenbank erfordert 99,995 % SLA, zonenredundante Hochverfügbarkeit und Lese-Scale-Out-Funktionen.

→Bereitstellung einer Azure SQL-Datenbank mithilfe des Diensttiers „Business Critical“ mit aktivierter Zonenredundanz.

Warum: Business Critical bietet die höchste SLA, verwendet lokale SSDs für niedrige Latenz und enthält integrierte lesbare sekundäre Replikate ohne zusätzliche Kosten. General Purpose hat eine niedrigere SLA und keine integrierten Lesereplikate.

Referenz↗

Eine Datenbank weist unvorhersehbare, intermittierende Nutzungsmuster mit langen Leerlaufzeiten auf. Kostenoptimierung ist entscheidend.

→Bereitstellung einer Azure SQL-Datenbank mithilfe des „General Purpose“-Tiers mit dem Serverless-Computemodell.

Warum: Serverless skaliert die Compute-Ressourcen automatisch je nach Bedarf und kann bei Inaktivität automatisch pausieren, wobei nur für den Speicher Gebühren anfallen. Dies ist kostengünstiger als Provisioned Compute für nicht-kontinuierliche Workloads.

Referenz↗

Migration eines lokalen SQL Servers, der stark auf Funktionen wie SQL Server Agent, datenbankübergreifende Abfragen und Service Broker angewiesen ist.

→Migration zu Azure SQL Managed Instance.

Warum: Managed Instance bietet nahezu 100 % Kompatibilität mit lokalen SQL Servern und bewahrt Instanz-Level-Funktionen, die in Azure SQL Database nicht verfügbar sind.

Referenz↗

Eine Anwendung erfordert OS-Level-Zugriff, Dateisystemzugriff (z. B. für Filestream) oder Funktionen, die von PaaS-Angeboten wie CLR mit EXTERNAL_ACCESS nicht unterstützt werden.

→Bereitstellung von SQL Server auf einer Azure Virtual Machine (IaaS).

Warum: IaaS bietet volle Kontrolle über das Betriebssystem und die SQL Server-Instanz und bietet maximale Kompatibilität mit lokalen Konfigurationen auf Kosten eines erhöhten Verwaltungsaufwands.

Eine Datenbank wird voraussichtlich über 4 TB bis zu 100 TB wachsen und erfordert eine schnelle Speicherskalierung und schnelle Wiederherstellungen.

→Bereitstellung einer Azure SQL-Datenbank mithilfe des Hyperscale-Diensttiers.

Warum: Hyperscale ist für sehr große Datenbanken (VLDBs) konzipiert und bietet bis zu 100 TB Speicher, der automatisch skaliert. Es verwendet eine einzigartige Architektur mit Page-Servern für schnelle Datenbankwiederherstellungen in konstanter Zeit, unabhängig von der Größe.

Referenz↗

Eine SaaS-Anwendung hostet viele kleine Datenbanken mit variierenden, unvorhersehbaren Nutzungsmustern. Kosten müssen optimiert werden, während gemeinsame Ressourcen bereitgestellt werden.

→Gruppieren Sie die Datenbanken in einem Azure SQL Database Elastic Pool.

Warum: Elastic Pools ermöglichen es mehreren Datenbanken, eine Reihe von Ressourcen (eDTUs oder vCores) zu einem festen Preis zu teilen, was kostengünstiger ist als die Bereitstellung einzelner Datenbanken, wenn die Nutzung nicht über alle Mandanten hinweg konstant ist.

Bereitstellung einer Azure SQL Managed Instance in einem virtuellen Netzwerk.

→Erstellen Sie ein dediziertes Subnetz mit einer Mindestgröße von /27 (32 Adressen) und delegieren Sie es an Microsoft.Sql/managedInstances.

Warum: Managed Instance erfordert ein dediziertes, leeres Subnetz mit ausreichenden IP-Adressen für seine internen Komponenten und zukünftige Skalierung. Eine /27 ist die minimal unterstützte Größe.

Migration einer großen, geschäftskritischen lokalen SQL Server-Datenbank nach Azure mit minimaler Ausfallzeit.

→Verwenden Sie den Azure Database Migration Service (DMS) im Online-Migrationsmodus.

Warum: Die DMS-Online-Migration führt eine initiale Ladung durch und verwendet dann die kontinuierliche Datensynchronisierung (Log Shipping), um das Ziel synchron zu halten, was ein sehr kurzes Cutover-Fenster ermöglicht.

Konfiguration des Speichers für einen SQL Server auf einer Azure VM, der eine Data-Warehouse-Workload mit großen sequentiellen Lesevorgängen hostet.

→Verwenden Sie Premium SSDs. Konfigurieren Sie schreibgeschütztes Host-Caching für Datendateien und „Keine“ für Protokolldateien.

Warum: Schreibgeschütztes Caching ist optimal für die großen sequentiellen Lesevorgänge, die in Data Warehouses üblich sind. Protokolldateien müssen ein deaktiviertes Caching haben, um die Schreibbeständigkeit zu gewährleisten und Datenverlust zu verhindern.

Eine Sicherheitsrichtlinie erfordert, dass alle Datenbankverbindungen verschlüsselt werden und das Serverzertifikat validiert wird.

→Legen Sie die minimale TLS-Version auf 1.2 auf dem Server fest. Verwenden Sie in Client-Verbindungszeichenfolgen `Encrypt=Strict`.

Warum: Das Festlegen der minimalen TLS-Version auf dem Server verhindert unsichere Protokollverhandlungen. `Encrypt=Strict` (TDS 8.0+) erzwingt Verschlüsselung und vollständige Zertifikatsvalidierung, wodurch Man-in-the-Middle-Angriffe verhindert werden.

Sensible Daten in bestimmten Spalten (z. B. SSN) müssen verschlüsselt werden, aber die Anwendung muss Gleichheitssuchen und Joins auf den verschlüsselten Daten durchführen.

→Verwenden Sie Always Encrypted mit deterministischer Verschlüsselung für die durchsuchbaren Spalten.

Warum: Deterministische Verschlüsselung erzeugt den gleichen Ciphertext für einen bestimmten Klartextwert, was Gleichheitsvergleiche ermöglicht. Randomisierte Verschlüsselung bietet stärkeren Schutz, erlaubt diese Operationen jedoch nicht.

Daten im Ruhezustand müssen verschlüsselt werden, aber die Organisation muss die volle Kontrolle über die Verschlüsselungsschlüssel behalten.

→Aktivieren Sie Transparent Data Encryption (TDE) mit kundenverwalteten Schlüsseln (BYOK), die in Azure Key Vault gespeichert sind.

Warum: Diese Konfiguration ermöglicht es der Organisation, den Schlüssel-Lebenszyklus (Rotation, Widerruf) in ihrem eigenen Key Vault zu verwalten, was Kontrolle bietet und Compliance-Anforderungen für den Schlüsselbesitz erfüllt.

Eine Azure SQL-Datenbank darf nur von einem bestimmten Azure Virtual Network aus zugänglich sein, wobei der öffentliche Internetzugang vollständig blockiert ist.

→Konfigurieren Sie einen privaten Endpunkt für den SQL Server und setzen Sie „Öffentlichen Netzwerkzugriff verweigern“ auf Ja.

Warum: Ein privater Endpunkt weist der SQL-Datenbank eine private IP innerhalb Ihres VNets zu. Das Deaktivieren des öffentlichen Zugriffs stellt sicher, dass dies der einzige Verbindungsweg ist, was eine vollständige Netzwerkisolation bietet.

Eine Multi-Tenant-Anwendung muss sicherstellen, dass Benutzer nur ihre eigenen Daten innerhalb einer freigegebenen Tabelle sehen können.

→Implementieren Sie Row-Level Security (RLS) durch Erstellen eines Sicherheitspredikats (inline table-valued function) und einer Sicherheitsrichtlinie, die es auf die Tabelle anwendet.

Warum: RLS filtert Zeilen transparent basierend auf dem Benutzerkontext (z. B. USER_NAME() oder SESSION_CONTEXT) und erzwingt die Datenisolation auf Ebene der Datenbank-Engine ohne Anwendungsänderungen.

Datenbankadministratoren müssen die Datenbank verwalten, dürfen aber sensible Daten in bestimmten Spalten nicht einsehen.

→Implementieren Sie Dynamic Data Masking (DDM) auf den sensiblen Spalten. Erteilen Sie DBAs nicht die UNMASK-Berechtigung.

Warum: DDM verschleiert Daten in Abfrageergebnissen für nicht privilegierte Benutzer, ohne die gespeicherten Daten zu ändern. Dies ermöglicht es DBAs, ihre Aufgaben zu erfüllen, während verhindert wird, dass sie die tatsächlichen sensiblen Informationen sehen.

Eine Sicherheitsrichtlinie schreibt vor, die SQL-Authentifizierung zu deaktivieren, um eine zentralisierte Identitätsverwaltung und MFA für eine Azure SQL DB oder Managed Instance zu erzwingen.

→Legen Sie einen Azure AD-Administrator für den Server fest und aktivieren Sie die Eigenschaft „Azure AD-only authentication“.

Warum: Diese Einstellung deaktiviert den SQL-Authentifizierungsendpunkt vollständig und zwingt alle Verbindungen zur Verwendung von Azure AD. Dies ist ein entscheidender Schritt zur Durchsetzung moderner Authentifizierungsrichtlinien.

Es müssen Warnmeldungen für anomale Datenbankaktivitäten erkannt und empfangen werden, einschließlich potenzieller SQL-Injektionen, ungewöhnlicher Zugriffsmuster und Brute-Force-Angriffe.

→Aktivieren Sie Microsoft Defender for SQL (ehemals Advanced Threat Protection).

Warum: Defender for SQL analysiert Datenbankprotokolle auf verdächtige Aktivitäten und generiert Sicherheitswarnungen, was eine entscheidende Schicht der Bedrohungserkennung jenseits grundlegender Zugriffskontrollen bietet.

Audit-Protokolle für eine Azure SQL-Datenbank müssen über mehrere Jahre aufbewahrt und für Compliance- und Sicherheitsuntersuchungen durchsuchbar sein.

→Konfigurieren Sie Azure SQL Auditing so, dass Protokolle an einen Log Analytics-Arbeitsbereich gesendet werden, in dem die erforderliche Datenaufbewahrung konfiguriert ist.

Warum: Log Analytics bietet langfristige Aufbewahrung und leistungsstarke KQL-basierte Abfragefunktionen, was es für durchsuchbare, langfristige Auditdaten Blob Storage überlegen macht.

Einem DevOps-Team soll temporärer, zeitlich begrenzter und genehmigungsgesteuerter Zugriff auf eine Datenbank zur Fehlerbehebung gewährt werden.

→Verwenden Sie Azure AD Privileged Identity Management (PIM), um die Berechtigung für eine Azure AD-Gruppe zu verwalten, die Datenbankzugriff hat.

Warum: PIM bietet Just-in-Time (JIT)-Zugriff, der auditierbar ist, eine Begründung erfordert und automatisch abläuft, wodurch das Prinzip der geringsten Rechte eingehalten wird.

Ein System benötigt eine überprüfbare, manipulationssichere Historie aller Datenänderungen, um strenge behördliche Compliance-Anforderungen zu erfüllen.

→Verwenden Sie die Ledger-Funktion der Azure SQL-Datenbank.

Warum: Ledger-Tabellen verwenden Blockchain-Konzepte, um Datenänderungen kryptografisch zu verknüpfen und eine unveränderliche Historie zu erstellen, die unabhängig überprüft werden kann. Dies ist stärker als temporale Tabellen, die nicht manipulationssicher sind.

Eine Datenbank leidet unter Leistungsverschlechterung. Es müssen die ressourcenintensivsten Abfragen identifiziert, Planänderungen verfolgt und Leistungsregressionen gefunden werden.

→Aktivieren und nutzen Sie Query Store.

Warum: Query Store ist der integrierte „Flugschreiber“ für die Abfrageleistung. Es erfasst automatisch die Abfragehistorie, Pläne und Wartezustände, was es zum primären Werkzeug zur Diagnose von Leistungsproblemen im Zeitverlauf macht.

Referenz↗

Eine Abfrage funktioniert manchmal gut, manchmal schlecht aufgrund von Parameter-Sniffing-Problemen, bei denen ein Ausführungsplan für einen nicht-repräsentativen Parameterwert optimiert wird.

→Verwenden Sie Query Store, um die verschiedenen Pläne zu identifizieren und den durchgängig guten Ausführungsplan zu erzwingen.

Warum: Planerzwingung in Query Store bietet eine schnelle und effektive Möglichkeit, die Leistung problematischer Abfragen ohne Codeänderungen zu stabilisieren. Sie überschreibt die Wahl des Optimierers mit einem bekanntermaßen guten Plan.

Verbesserung der Abfrageleistung ohne Codeänderungen durch Nutzung von Funktionen wie Batch-Modus bei Rowstore, Memory Grant Feedback und verzögerter Kompilierung von Tabellenvariablen.

→Setzen Sie den Datenbankkompatibilitätsgrad auf 150 (für SQL 2019-Funktionen) oder höher.

Warum: Das Feature-Set für Intelligent Query Processing (IQP) wird durch den Datenbankkompatibilitätsgrad aktiviert. Level 150+ aktiviert eine breite Palette von Leistungsverbesserungen im Abfrageprozessor, die keine Codeänderungen erfordern.

Das Betriebsteam muss benachrichtigt werden, wenn wichtige Leistungsmetriken, wie CPU-Prozentsatz oder Deadlocks, einen definierten Schwellenwert überschreiten.

→Verwenden Sie Azure Monitor, um Metrikwarnungen (für CPU) und Protokollwarnungen (für Deadlocks) zu erstellen, die eine Aktionsgruppe auslösen.

Warum: Azure Monitor ist die zentralisierte Plattform für die Überwachung und Warnung von Azure-Ressourcen. Aktionsgruppen bieten flexible Benachrichtigungskanäle (E-Mail, SMS, Webhook usw.).

Verbessern Sie die Schreibleistung, indem Sie Indizes identifizieren und entfernen, die von keinen Leseabfragen verwendet werden.

→Abfragen Sie die `sys.dm_db_index_usage_stats` DMV.

Warum: Diese DMV verfolgt die Indexnutzung (Suchvorgänge, Scans, Lookups) im Vergleich zu Updates. Indizes mit vielen Updates, aber keiner oder sehr geringer Nutzung sind Hauptkandidaten für die Entfernung, was den Wartungsaufwand reduziert.

Es müssen detaillierte Informationen über intermittierende Blockierungsprobleme erfasst werden, einschließlich der Anweisungen und Sitzungen, die an der Blockierungskette beteiligt sind.

→Konfigurieren Sie eine Extended Events-Sitzung, die das Ereignis `blocked_process_report` erfasst.

Warum: Dieses Ereignis liefert einen detaillierten XML-Bericht über Blockierungsketten, wenn der `blocked process threshold` überschritten wird, und bietet tiefe Diagnoseinformationen, die in DMVs nicht verfügbar sind.

Eine Datenbank muss ihre Indexstrategie automatisch an sich ändernde Workload-Muster anpassen, ohne manuelles Eingreifen.

→Aktivieren Sie die CREATE_INDEX-Option in der automatischen Optimierung der Azure SQL-Datenbank.

Warum: Diese Funktion ermöglicht es Azure, die Workload zu analysieren, fehlende Indizes mit hoher Auswirkung zu identifizieren, diese zu erstellen und ihren Leistungsvorteil zu validieren, wodurch eine wichtige DBA-Aufgabe automatisiert wird.

Auslagerung leseintensiver Berichtsworkloads von der primären OLTP-Datenbank in einem Business Critical- oder Premium-Tier.

→Ändern Sie die schreibgeschützten Verbindungszeichenfolgen der Anwendung so, dass sie `ApplicationIntent=ReadOnly` enthalten.

Warum: Diese Tiers enthalten ein kostenloses, integriertes lesbares sekundäres Replikat. Die Eigenschaft `ApplicationIntent` in der Verbindungszeichenfolge leitet schreibgeschützte Verbindungen automatisch an dieses Replikat weiter und isoliert Lese-Workloads.

Eine große Faktentabelle in einem Data Warehouse wird häufig für Aggregationsabfragen (SUM, COUNT, AVG) verwendet, die langsam ausgeführt werden.

→Erstellen Sie einen gruppierten Columnstore-Index auf der Faktentabelle.

Warum: Columnstore-Indizes speichern Daten in einem spaltenbasierten Format, bieten eine sehr hohe Datenkomprimierung und ermöglichen die Batch-Modus-Ausführung, was Aggregations- und scanlastige Analyseabfragen dramatisch beschleunigt.

Eine Datenbank erfährt erhebliche Blockierungskonflikte zwischen Leseabfragen (Berichte) und Schreibabfragen (Transaktionen).

→Aktivieren Sie Read Committed Snapshot Isolation (RCSI) auf der Datenbank.

Warum: RCSI verwendet Zeilenversionierung, wodurch Leser die zuletzt committete Version von Daten sehen können, ohne gemeinsame Sperren zu setzen, wodurch Blockaden von Schreibvorgängen eliminiert werden. Schreiber blockieren Leser nicht.

Eine Anwendung, die eine Serverless-Datenbank verwendet, erfährt nach einer Inaktivitätsphase anfänglich langsame Verbindungszeiten.

→Verringern Sie die Auto-Pause-Verzögerung oder konfigurieren Sie einen Mindest-vCore-Wert größer als Null.

Warum: Die Verzögerung wird dadurch verursacht, dass die Datenbank aus einem pausierten Zustand (Kaltstart) wieder aufgenommen wird. Das Festlegen eines Mindest-vCore-Werts verhindert, dass die Datenbank vollständig pausiert, wodurch die Wiederaufnahme-Latenz auf Kosten einer kontinuierlichen Compute-Abrechnung entfällt.

Implementieren Sie eine CI/CD-Pipeline für automatisierte, versionskontrollierte und wiederholbare Datenbankschema-Bereitstellungen.

→Verwenden Sie ein SQL-Datenbankprojekt (z. B. in Visual Studio), um eine DACPAC-Datei zu generieren. Verwenden Sie Azure DevOps-Pipelines, um das DACPAC bereitzustellen.

Warum: Dies ist das Standard-Infrastructure as Code (IaC)-Muster für SQL-Schemas. Das DACPAC ist ein deklaratives Modell des Schemas, und die Bereitstellungstools übernehmen die Generierung des differentiellen Skripts, um Konsistenz zu gewährleisten.

Eine Azure SQL-Datenbank muss automatisch basierend auf einem Zeitplan oder Metrikschwellenwerten (z. B. hohe CPU-Auslastung) hoch- oder herunterskaliert werden.

→Verwenden Sie ein Azure Automation Runbook (PowerShell), ausgelöst durch einen Zeitplan oder eine Azure Monitor-Warnung.

Warum: Azure SQL-Datenbank (Provisioned Tier) verfügt nicht über integrierte Autoskalierung. Azure Automation ist das Standardwerkzeug zur Orchestrierung dieser Art von Betriebsaufgaben mithilfe von Skripten und Zeitplänen.

Ein Wartungsskript (z. B. Indexwiederaufbau) muss gegen Hunderte von Azure SQL-Datenbanken ausgeführt werden.

→Verwenden Sie Elastic Jobs.

Warum: Elastic Jobs ist ein PaaS-Dienst, der speziell für die Ausführung von T-SQL-Jobs über eine Zielgruppe von Datenbanken hinweg entwickelt wurde, um Anmeldeinformationen, Planung und Protokollierung zentral zu verwalten.

Stellen Sie sicher, dass alle neu erstellten Azure SQL Server in einem Abonnement standardmäßig eine bestimmte Funktion, wie TDE oder Auditing, aktiviert haben.

→Erstellen Sie eine Azure Policy mit einem `DeployIfNotExists`- oder `Modify`-Effekt.

Warum: Azure Policy bietet Governance in großem Maßstab. Der `DeployIfNotExists`-Effekt konfiguriert die fehlende Einstellung während der Ressourcenerstellung automatisch und erzwingt so die Compliance ohne manuelles Eingreifen.

Planen Sie ein wiederkehrendes T-SQL-Skript oder eine Wartungsaufgabe auf einer Azure SQL Managed Instance.

→Verwenden Sie den integrierten SQL Server Agent.

Warum: Managed Instance enthält den vollständigen SQL Server Agent, der die gleichen vertrauten Funktionen zur Jobplanung wie lokale SQL Server bietet, ohne dass ein externer Automatisierungsdienst erforderlich ist.

Steuern Sie, wann Azure geplante Wartungsarbeiten an einer Azure SQL-Datenbank oder Managed Instance durchführt, um die Auswirkungen auf den Geschäftsbetrieb zu minimieren.

→Konfigurieren Sie ein Wartungsfenster für die Ressource.

Warum: Diese Funktion ermöglicht es Ihnen, einen vordefinierten Zeitraum (z. B. Wochenenden) für Azure auszuwählen, um Updates anzuwenden, was Ihnen Vorhersehbarkeit bei dienstbeeinflussenden Wartungsarbeiten bietet.

Eine Anwendung erfordert ein automatisches Failover in eine sekundäre Region zur Notfallwiederherstellung, ohne dass Änderungen an der Verbindungszeichenfolge erforderlich sind.

→Konfigurieren Sie eine Auto-Failover-Gruppe zwischen den primären und sekundären Datenbanken/Instanzen.

Warum: Failover-Gruppen bieten Lese-/Schreib- und Nur-Lese-Listener-Endpunkte. Diese Endpunkte leiten den Datenverkehr nach einem Failover automatisch an den aktuellen primären/sekundären Server um, wodurch der Prozess für die Anwendung transparent wird.

Datenbank-Backups müssen über viele Jahre (z. B. 7-10 Jahre) aufbewahrt werden, um gesetzliche oder behördliche Compliance-Anforderungen zu erfüllen.

→Konfigurieren Sie eine Richtlinie zur langfristigen Sicherungsaufbewahrung (LTR).

Warum: Standard-Point-in-Time Restore (PITR)-Backups werden maximal 35 Tage aufbewahrt. LTR speichert vollständige Backups in einem separaten Azure Blob Storage für bis zu 10 Jahre, speziell für Compliance-Anforderungen.

Eine Datenbank muss während eines Rechenzentrumsausfalls (Availability Zone) innerhalb einer einzelnen Azure-Region verfügbar bleiben.

→Aktivieren Sie die zonenredundante Konfiguration für eine Business Critical- oder Premium-Tier-Datenbank.

Warum: Zonenredundanz stellt synchrone sekundäre Replikate in verschiedenen physischen Rechenzentren innerhalb derselben Region bereit und bietet ein automatisches Failover mit RPO nahe Null bei Ausfällen auf Zonenebene.

Eine Azure SQL Managed Instance erfordert eine Notfallwiederherstellungslösung in einer gekoppelten Azure-Region mit automatischer Failover-Fähigkeit.

→Konfigurieren Sie eine Auto-Failover-Gruppe für die Managed Instance.

Warum: Dies ist das kanonische DR-Muster für Managed Instance, das asynchrone Replikation, Listener-Endpunkte für transparentes Anwendungs-Failover und eine automatisierte Failover-Option bietet.

Eine Datenbank muss auf eine beliebige Sekunde des letzten Monats wiederhergestellt werden können.

→Konfigurieren Sie den kurzfristigen Sicherungsaufbewahrungszeitraum (PITR) auf 30-35 Tage.

Warum: Azure SQL erstellt automatisch vollständige, differenzielle und häufige Transaktionsprotokollsicherungen. Die PITR-Aufbewahrungseinstellung (1-35 Tage) bestimmt, wie lange diese Sicherungen aufbewahrt werden, und definiert das Fenster für Point-in-Time-Wiederherstellungen.

Konfiguration eines Windows Server Failover Clusters für eine SQL Server Always On Availability Group auf Azure VMs.

→Verwenden Sie einen Cloud Witness als Quorumzeugen.

Warum: Ein Cloud Witness verwendet Azure Blob Storage und ist die empfohlene, widerstandsfähigste Option für Cluster in Azure. Er vermeidet die Notwendigkeit einer dritten VM für einen Dateifreigabezeugen oder komplexe gemeinsame Festplattenkonfigurationen.

Implementierung einer SQL Server Failover Cluster Instance (FCI) auf Azure VMs, die freigegebenen Speicher erfordert.

→Verwenden Sie Azure Shared Disks (Anhängen eines verwalteten Datenträgers an mehrere VMs).

Warum: Azure Shared Disks ist die native Azure-Lösung zur Bereitstellung von Blockspeicher, auf den mehrere VMs zugreifen können, was eine Voraussetzung für eine traditionelle FCI ist.

Der Notfallwiederherstellungsprozess für eine Failover-Gruppe muss getestet werden, ohne die primäre Produktionsdatenbank zu beeinträchtigen.

→Initiieren Sie ein geplantes (manuelles) Failover während eines Wartungsfensters mit geringer Auswirkung, validieren Sie die Anwendungsverbindung und führen Sie dann ein Failback durch.

Warum: Ein geplantes Failover gewährleistet keinen Datenverlust und ist die gründlichste Methode zur Validierung des gesamten DR-Prozesses, einschließlich DNS-Propagation und Anwendungsverbindung. Es ist ein kurzes, kontrolliertes Produktionsereignis.