SQL Server Always On: Vollständiger Leitfaden für Datenbankadministratoren [2026]

SQL Server Always On ist Microsofts umfassende Hochverfügbarkeits- und Notfallwiederherstellungslösung, die mit SQL Server 2012. Es stellt einen bedeutenden Fortschritt gegenüber früheren Technologien wie Datenbankspiegelung und Protokollversand dar und gewährleistet den kontinuierlichen Zugriff auf Daten bei gleichzeitiger Minimierung von Ausfallzeiten und Datenverlusten.

1.2 Warum Unternehmen Always-On-Lösungen benötigen

In der heutigen digitalen Wirtschaft bedeuten Datenbankausfälle unmittelbare Umsatzeinbußen, Reputationsschäden und Probleme bei der Einhaltung gesetzlicher Bestimmungen. Unternehmen benötigen hochverfügbare Lösungen, die einen nahezu unterbrechungsfreien Betrieb gewährleisten und gleichzeitig Schutz vor verschiedenen Ausfallszenarien bieten.

Herkömmliche Backup- und Wiederherstellungsverfahren genügen den Anforderungen moderner Unternehmen nicht mehr. Fällt eine kritische Datenbank aus, können sich Unternehmen die stundenlange Wiederherstellung aus Backups nicht leisten. Always-On-Lösungen bieten automatisiertes Failover, das den Betrieb innerhalb von Sekunden oder Minuten statt Stunden wiederherstellt und so die Auswirkungen von Systemausfällen drastisch reduziert.

Über die grundlegende Verfügbarkeit hinaus müssen Unternehmen leseintensive Arbeitslasten von Produktionsdatenbanken auslagern, Wartungsarbeiten ohne Ausfallzeiten durchführen und sich vor Katastrophen auf Standortebene schützen können. SQL Server Always On erfüllt all diese Anforderungen durch eine einheitliche Architektur, die von kleinen Installationen bis hin zu global verteilten Systemen skalierbar ist.

1.3 Schlüsselkonzepte: RTO, RPO, HA und DR

Wiederherstellungszeitziel (RTO) Definiert die maximal zulässige Ausfallzeit nach einem Fehler – wie schnell die Datenbank wieder online sein muss.

Wiederherstellungspunktziel (RPO) definiert den maximal akzeptablen Datenverlust, gemessen in Zeit – wie viele kürzlich übertragene Daten das Unternehmen sich leisten kann zu verlieren.

Hochverfügbarkeit (HA) Der Fokus liegt auf der Minimierung von Ausfallzeiten, die durch routinemäßige Störungen wie Hardwarefehlfunktionen oder Softwareabstürze innerhalb desselben Rechenzentrums verursacht werden.

Notfallwiederherstellung (DR) Hochverfügbarkeit (HA) zielt auf die Minimierung von Ausfallzeiten ab, während Disaster Recovery (DR) den Datenschutz und die Geschäftskontinuität bei schwerwiegenden Vorfällen sicherstellt.

SQL Server Always On unterstützt sowohl Hochverfügbarkeit (HA) als auch Disaster Recovery (DR) in einer einheitlichen Architektur. Der synchrone Commit-Modus bietet RPO = 0 mit automatischem Failover für nahezu null RTO; der asynchrone Commit-Modus akzeptiert potenziellen Datenverlust zugunsten geringerer Latenzzeiten an entfernten Standorten.

1.4 Always-On-Lösungen

SQL Server Always On bietet drei Bereitstellungsoptionen, die jeweils auf unterschiedliche Verfügbarkeits- und Infrastrukturanforderungen zugeschnitten sind. Dieser Leitfaden behandelt alle drei Optionen:

Always On Verfügbarkeitsgruppen (AG): Hochverfügbarkeit und Notfallwiederherstellung auf Datenbankebene ohne gemeinsam genutzten Speicher.
Always On Failover Cluster Instances (FCI): Hohe Verfügbarkeit auf Instanzebene durch gemeinsam genutzten Speicher.
AG + FCI kombiniert: Zweischichtiger Schutz, der Failover auf Instanz- und Datenbankebene für maximale Ausfallsicherheit kombiniert.

2. Always On-Verfügbarkeitsgruppen

Always On Verfügbarkeitsgruppen (AG) ist eine Hochverfügbarkeits- und Disaster-Recovery-Lösung auf Datenbankebene, die eine Reihe von Benutzerdatenbanken durch kontinuierliches Versenden von Transaktionsprotokollen auf bis zu acht sekundäre Replikate repliziert.

2.1-Hauptmerkmale

Failover auf Datenbankebene: Einzelne Datenbanken oder Gruppen können unabhängig von der Gesamtdatenbank ausfallen. SQL Server Beispiel;
bis zu neun Replikate (ein primäres, acht sekundäre) in der Enterprise Edition;
Synchroner Commit-Modus für null Datenverlust; asynchroner Commit für entfernte DR-Replikate;
automatisches Failover für synchrone Replikate, wenn das primäre Replikat nicht verfügbar ist;
Lesbare sekundäre Replikate zur Auslagerung von Berichts- und Sicherungs-Workloads;
Der Verfügbarkeitsgruppenlistener stellt einen einzigen Verbindungsendpunkt bereit, der automatisch zum aktuellen primären Server weiterleitet.

2.2 Implementierungsschritte

Bereiten Sie Active Directory-Dienstkonten vor und konfigurieren Sie die Berechtigungen auf allen Knoten;
Windows Server Failover Clustering auf allen beteiligten Servern installieren und validieren;
installieren SQL Server als eigenständige Instanz auf jedem Knoten unter Verwendung konsistenter Pfade und Einstellungen;
Aktivieren Sie die Funktion „Immer verfügbare Verfügbarkeitsgruppen“ über SQL Server Configuration Manager oder PowerShell;
Datenbanken auf vollständiges Wiederherstellungsmodell einstellen und vollständige Backups sowie Protokollsicherungen erstellen;
Verfügbarkeitsgruppe erstellen, Replikate hinzufügen und Verfügbarkeits- und Failovermodi konfigurieren;
Sekundäre Replikate mithilfe automatischer Seeding-Methode oder manueller Sicherung und Wiederherstellung initialisieren;
Erstellen Sie den Verfügbarkeitsgruppenlistener und überprüfen Sie die Clientkonnektivität.

Eine vollständige Schritt-für-Schritt-Anleitung finden Sie in unserer Vollständiger Leitfaden zu Always On-Verfügbarkeitsgruppen.

2.3 Am besten für

Geschäftskritische Datenbanken, die keinen Datenverlust und automatisches Failover erfordern;
Arbeitslasten, die lesbare Sekundärserver für Berichtszwecke oder Backup-Auslagerung benötigen;
Bereitstellungen über mehrere Standorte zur Notfallwiederherstellung;
Umgebungen ohne vorhandene gemeinsame Speicherinfrastruktur.

2.4 Vorteile

Kein gemeinsamer Speicher erforderlich – jede Replik verwendet einen unabhängigen lokalen Speicher;
unterstützt sowohl HA als auch DR in einer einzigen Konfiguration;
Gut lesbare Sekundärtexte reduzieren die Arbeitsbelastung der Primärtexte;
Die Granularität auf Datenbankebene ermöglicht unterschiedliche Failover-Richtlinien pro Datenbankgruppe.

2.5 Nachteile

Für den vollen Funktionsumfang ist die Enterprise Edition erforderlich (die Standardversion unterstützt Basic AG mit erheblichen Einschränkungen);
Der synchrone Commit-Modus führt zu einer Schreiblatenz, die proportional zur Netzwerk-Roundtrip-Zeit ist;
Anmeldungen, SQL-Agent-Aufträge und verknüpfte Server erfordern eine manuelle Synchronisierung in SQL Server 2019 und früher;
Alle Replikate müssen sich auf Knoten desselben Windows Server-Failoverclusters befinden.

2.6 Referenzen

Offizielles Microsoft-Dokument: Was ist eine Always On-Verfügbarkeitsgruppe?
Offizielles Microsoft-Dokument: Erste Schritte mit Always On-Verfügbarkeitsgruppen

3. Immer aktive Failover-Clusterinstanzen

Always On Failover Cluster Instances (FCI) bietet hohe Verfügbarkeit auf Instanzebene durch den Betrieb einer einzelnen SQL Server Die Instanz wird über mehrere physische Knoten verteilt, die denselben Speicher nutzen. Wenn der aktive Knoten ausfällt, SQL Server Die Instanz auf einem Standby-Knoten wird automatisch neu gestartet, wodurch der Übergang für Clientanwendungen transparent wird.

3.1-Hauptmerkmale

Failover auf Instanzebene: Alle Datenbanken der Instanz werden gemeinsam als eine Einheit umgeschaltet;
Gemeinsamer Speicher (Storage Area Network (SAN), iSCSI, Storage Spaces Direct oder SMB), auf den alle Knoten zugreifen können;
Virtueller Netzwerkname und virtuelle IP-Adresse gewährleisten einen stabilen Verbindungsendpunkt, unabhängig davon, welcher Knoten aktiv ist;
Windows Server Failover Clustering verwaltet die Knotenzustandsüberwachung, das Quorum und die Failover-Orchestrierung;
Unterstützt die Knotenkonfigurationstypen Aktiv/Standby, Aktiv/Aktiv, N+1 und N+M.

3.2 Implementierungsschritte

Bereitstellung und Anbindung von gemeinsam genutztem Speicher an alle Clusterknoten;
Installieren Sie die Failover-Clustering-Funktion und überprüfen Sie die Clusterkonfiguration;
Windows Server-Failovercluster erstellen und Quorum konfigurieren;
führen Sie das SQL Server Installation mit Auswahl der Failovercluster-Option und Angabe des virtuellen Netzwerknamens und der Pfade zum gemeinsam genutzten Speicher;
Füge dem SQL Server Failover-Clusterinstanz;
Das Failover-Verhalten lässt sich durch Testen eines manuellen Failovers zwischen den Knoten überprüfen.

Eine vollständige Schritt-für-Schritt-Anleitung finden Sie in unserer SQL Server Failover-Cluster – vollständiger Leitfaden.

3.3 Am besten für

Umgebungen mit bestehender gemeinsam genutzter Speicherinfrastruktur (SAN oder iSCSI);
Anwendungen, die ein Failover auf Instanzebene erfordern, bei dem alle Datenbanken gleichzeitig ausfallen müssen;
Szenarien, in denen Kundentransparenz von entscheidender Bedeutung ist und keine anwendungsseitigen Änderungen akzeptabel sind;
Organisationen, die der Einfachheit eines Single-Instance-Failover-Modells Priorität einräumen.

3.4 Vorteile

Automatisches Failover auf Instanzebene ohne erforderliche Client-Neukonfiguration;
Kein Aufwand für die Datenreplikation – alle Knoten greifen auf denselben Speicher zu;
vorhersagbares Failover-Verhalten für alle Datenbanken gleichzeitig;
Unterstützt flexible Knotenkonfigurationen (Aktiv/Aktiv, N+1, N+M) zur Optimierung der Hardwareauslastung.

3.5 Nachteile

Gemeinsam genutzter Speicher stellt einen potenziellen Single Point of Failure dar, es sei denn, der Speicher selbst ist redundant.
nur ein Knoten läuft SQL Server jeweils nur einmal – kein Leselastausgleich auf sekundären Knoten;
Keine integrierte Notfallwiederherstellung ohne Kopplung mit einer Verfügbarkeitsgruppe;
Gemeinsam genutzte Speicherinfrastruktur verursacht im Vergleich zu AG zusätzliche Kosten und Komplexität.

3.6 Referenzen

Offizielles Microsoft-Dokument: Always On Failover Cluster Instances (SQL Server)

4. Verfügbarkeitsgruppen mit Failoverclusterinstanzen kombinieren

Für Organisationen, die sowohl Schutz auf Instanzebene als auch auf Datenbankebene benötigen, SQL Server Unterstützt das Hosting von Verfügbarkeitsgruppenreplikaten auf Failoverclusterinstanzen (FCI). In dieser Konfiguration fungiert jeder FCI-Knoten als einzelnes Verfügbarkeitsreplikat, sodass ein FCI-Failover für die Verfügbarkeitsgruppe transparent ist, während ein AG-Failover standortübergreifenden Schutz auf Datenbankebene bietet. Diese Kombination bietet die umfassendste Hochverfügbarkeits- und Disaster-Recovery-Abdeckung, die derzeit verfügbar ist. SQL Server.

4.1-Hauptmerkmale

Zweistufiges Failover: FCI kümmert sich um Ausfälle auf Instanzebene; AG kümmert sich um Ausfälle auf Standort- oder Replikatebene;
Jede FCI zählt innerhalb der Verfügbarkeitsgruppe als eine einzelne Replik, unabhängig davon, wie viele Knoten die FCI enthält;
FCI-gehostete Replikate benötigen weiterhin gemeinsam genutzten Speicher gemäß den Standardanforderungen von FCI;
Auf FCIs gehostete AG-Replikate unterstützen nur manuelles Failover – automatisches Failover ist für auf FCIs gehostete Replikate nicht verfügbar;
Eigenständige Instanzen können zusammen mit FCI-gehosteten Replikaten an derselben Verfügbarkeitsgruppe teilnehmen.

4.2 Implementierungsschritte

Jede FCI-Einheit wird gemäß den Standard-Einrichtungsverfahren unabhängig voneinander eingesetzt und validiert;
sicherstellen, dass alle FCI-Knoten und eigenständigen Replikatknoten zum selben Windows Server-Failovercluster gehören;
Aktivieren Sie die Funktion „Always On Availability Groups“ auf jeder FCI-Instanz;
überprüfen, ob nach einem möglichen FCI-Failover kein einzelner WSFC-Knoten zwei Replikate derselben Verfügbarkeitsgruppe hostet;
Erstellen Sie die Verfügbarkeitsgruppe, kennzeichnen Sie FCI-Instanzen als Replikate und konfigurieren Sie den manuellen Failover-Modus für alle FCI-gehosteten Replikate;
Sekundäre Replikate initialisieren und den Verfügbarkeitsgruppen-Listener konfigurieren.

Einzelheiten zur FCI-Einrichtung finden Sie in unserer SQL Server Vollständiger Leitfaden für Failovercluster. Details zur Einrichtung von Verfügbarkeitsgruppen finden Sie in unserem vollständigen Leitfaden zu Always On-Verfügbarkeitsgruppen.

4.3 Am besten für

Missionskritische Umgebungen, die sowohl Schutz vor Ausfällen einzelner Knoten als auch vor Katastrophen auf Standortebene erfordern;
Organisationen, die bereits FCI betreiben und die standortübergreifende Notfallwiederherstellung hinzufügen müssen;
regulierte Branchen, in denen maximale Datenschutz- und Verfügbarkeits-SLAs vorgeschrieben sind;
groß angelegte Implementierungen, bei denen Failover-Richtlinien auf Instanz- und Datenbankebene parallel existieren müssen.

4.4 Vorteile

Maximaler Schutz: Knotenausfälle werden von FCI, Standortausfälle von AG behandelt;
Ein FCI-Failover ist für die Verfügbarkeitsgruppe transparent – die AG sieht während eines FCI-Failovers keine Replikatänderung.
Flexible Topologie: Mischung aus FCI-gehosteten und eigenständigen Replikaten in derselben Verfügbarkeitsgruppe.

4.5 Nachteile

FCI-gehostete Replikate unterstützen nur manuelles AG-Failover – automatisches AG-Failover ist für diese Replikate nicht verfügbar;
Erfordert eine sorgfältige Planung der WSFC-Knoten, um zu verhindern, dass ein einzelner Knoten nach einem FCI-Failover zwei Replikate derselben AG hostet;
höhere Infrastrukturkosten und operative Komplexität als bei AG oder FCI allein;
Für jede FCI-Komponente wird weiterhin gemeinsamer Speicher benötigt.

4.6 Referenzen

Offizielles Microsoft-Dokument: Failover-Clustering und Always On-Verfügbarkeitsgruppen (SQL Server)
Offizielles Microsoft-Dokument: Was ist eine Always On-Verfügbarkeitsgruppe?
Offizielles Microsoft-Dokument: Erste Schritte mit Always On-Verfügbarkeitsgruppen
Offizielles Microsoft-Dokument: Always On Failover Cluster Instances (SQL Server)

5. Vergleich von Always-On-Lösungen

5.1 Vergleichstabelle der Merkmale

Funktion	Verfügbarkeitsgruppen	Failoverclusterinstanzen	AG + FCI kombiniert
Failover-Bereich	Datenbankebene	Instanzebene	Beides
Gemeinsamer Speicherplatz erforderlich	Nein	Ja	Ja (für die FCI-Komponente)
Datenreplikation	Protokollbasiert für jede Replik	Keine (gemeinsamer Speicher)	Log-basiert zwischen FCIs
Automatisches Failover	Ja (synchrone Replikate)	Ja	FCI: Ja; AG: Nein
Lesbare Sekundärdaten	Ja	Nein	Ja (AG-Komponente)
Katastrophale Erholung	Eingebaut	Nicht eingebaut	Eingebaut
Max-Repliken	9 (Unternehmen)	N / A	9 (Unternehmen)
Komplexität der Infrastruktur	Medium	Medium	Hoch
Kosten	Niedriger (kein SAN erforderlich)	Höher (SAN erforderlich)	Höchste

5.2 Wählen Sie Ihre Always-On-Lösung.

Beginnen Sie mit Ihrer Speicherinfrastruktur: Wenn Sie noch keinen gemeinsam genutzten Speicher verwenden, sind Verfügbarkeitsgruppen die naheliegende und kostengünstigste Wahl für Hochverfügbarkeit und Disaster Recovery. Betreiben Sie bereits eine SAN-Umgebung und benötigen Sie ein Failover auf Instanzebene, ist FCI die einfachere Option – planen Sie jedoch die spätere Hinzufügung von Verfügbarkeitsgruppen ein, falls standortübergreifendes Disaster Recovery zukünftig erforderlich sein sollte.

Wählen Sie die Kombination aus Verfügbarkeitsgruppe (AG) und FCI nur dann, wenn Sie einen tatsächlichen Bedarf an beiden Schutzebenen haben und über die nötige operative Reife verfügen, um die erhöhte Komplexität zu bewältigen. Wichtig zu beachten ist, dass FCI-gehostete AG-Replikate kein automatisches AG-Failover unterstützen. Daher erfordert diese Topologie manuelle Eingriffe für Failover auf Verfügbarkeitsgruppenebene.

Für die meisten Greenfield-Implementierungen ist heutzutage Always On Availability Groups der empfohlene Ausgangspunkt: Es deckt sowohl HA als auch DR ab, benötigt keinen gemeinsam genutzten Speicher und unterstützt lesbare Sekundärserver – Fähigkeiten, die FCI allein nicht bieten kann.

6. Best Practices für SQL Server Always On Solutions

6.1 Planung und Entwurf

Definieren Sie die RTO- und RPO-Anforderungen, bevor Sie sich für eine Always On-Lösung entscheiden – diese Ziele bestimmen direkt, ob ein synchroner oder asynchroner Commit-Modus angemessen ist und ob ein automatisches Failover möglich ist.
Die sekundären Replikate sollten so dimensioniert sein, dass sie die gesamte primäre Arbeitslast während eines Failover-Ereignisses bewältigen können, einschließlich Szenarien mit Spitzenlast.
Bei AG-Bereitstellungen sollten synchrone Replikate im selben Rechenzentrum oder Netzwerk mit geringer Latenz platziert werden, um die Auswirkungen der Schreiblatenz zu minimieren. Der asynchrone Modus ist für geografisch weit entfernte DR-Replikate reserviert.
Ein Quorum mit einer ungeraden Anzahl von Stimmen ist erforderlich. Bei Clustern mit zwei Knoten sollte eine Dateifreigabe oder ein Cloud-Zeuge als dritte Stimme hinzugefügt werden, um Split-Brain-Szenarien zu vermeiden.
Planen Sie Ihre Netzwerktopologie für Multi-Subnetz-Bereitstellungen sorgfältig. Jedes Subnetz benötigt eine eigene Listener-IP-Adresse, und Clients benötigen MultiSubnetFailover=True in ihren Verbindungszeichenfolgen.

6.2 Umsetzungsleitfaden

Verwenden Sie konsistente SQL Server Version, Edition und kumulative Update-Stände auf allen Replikaten. Unterschiedliche Patch-Stände können beim Failover zu unerwartetem Verhalten führen.
Konfigurieren Sie dedizierte Netzwerkschnittstellen für den Cluster-Heartbeat-Datenverkehr, getrennt vom Anwendungsdatenverkehr.
Automatische Initialisierung der Datenbanksynchronisierung aktivieren in SQL Server Ab 2016 entfällt in den meisten Fällen die Notwendigkeit, Backups manuell auf sekundäre Replikate zu kopieren.
Bei AG + FCI-Topologien muss nach jeder Änderung der FCI-Knotenkonfiguration überprüft werden, ob ein einzelner WSFC-Knoten am Ende zwei Replikate derselben Verfügbarkeitsgruppe hostet.
Verwenden Sie immer SQL Server Verwenden Sie Management Studio oder Transact-SQL zur Verwaltung von Verfügbarkeitsgruppen-Failovern – verwenden Sie niemals den Failover Cluster Manager direkt, da dieser den Synchronisierungsstatus der Verfügbarkeitsgruppe nicht kennt und zu längeren Ausfallzeiten oder Datenverlust führen kann.

6.3 Überwachung und Wartung

Überwachen Sie regelmäßig den Synchronisierungsstatus, die Sendewarteschlange und die Wiederherstellungswarteschlange mithilfe des Dashboards der Verfügbarkeitsgruppe in SQL Server Management Studio oder Dynamic Management Views (DMVs). Eine wachsende Redo-Warteschlange auf einem sekundären Server deutet auf einen E/A-Engpass hin, der die Failover-Wiederherstellung verzögert.
Führen Sie DBCC CHECKDB auf sekundären Replikaten aus, um Integritätsprüfungen vom primären Replikat zu entlasten. Siehe unsere DBCC CHECKDB-Leitfaden .
Tragen Sie SQL Server Patches werden mittels rollierender Upgrades installiert: Zuerst werden die sekundären Replikate gepatcht, dann wird ein geplantes manuelles Failover auf ein gepatchtes sekundäres Replikat durchgeführt und anschließend das ehemalige primäre Replikat gepatcht. Dadurch wird die Ausfallzeit auf die Dauer eines einzelnen Failovers begrenzt.
Testen Sie Failover regelmäßig in Nicht-Produktionsumgebungen. Ein automatisches Failover, das nie getestet wurde, ist keine zuverlässige Wiederherstellungsstrategie.
Konfigurieren Sie Warnungen für Änderungen des Integritätsstatus von Verfügbarkeitsgruppen, Replikatrollenübergänge und Synchronisierungsfehler mithilfe von SQL Server Agent oder ein spezielles Überwachungstool wie z. B. SQL Server Performance Monitor.

7. FAQ

F: Was ist SQL Server Immer eingeschaltet?

A: SQL Server Always On ist Microsofts Plattform für Hochverfügbarkeit und Notfallwiederherstellung, die im Jahr 2000 eingeführt wurde. SQL Server 2012. Es umfasst zwei Technologien – Always On Availability Groups und Always On Failover Cluster Instances –, die automatisiertes Failover, Datenredundanz und kontinuierlichen Zugriff auf Datenbanken im Falle von Hardware-, Software- oder Standortausfällen gewährleisten.

F: Worin besteht der Unterschied zwischen Always On-Verfügbarkeitsgruppen und Failoverclusterinstanzen?

A: Verfügbarkeitsgruppen arbeiten auf Datenbankebene, replizieren Daten über Log Shipping auf unabhängige sekundäre Replikate und benötigen keinen gemeinsam genutzten Speicher. Failoverclusterinstanzen arbeiten auf Instanzebene, benötigen gemeinsam genutzten Speicher, auf den alle Knoten zugreifen können, und führen ein Failover aller Datenbanken als Einheit durch. Verfügbarkeitsgruppen unterstützen lesbare sekundäre Replikate und integrierte Disaster Recovery; Failoverclusterinstanzen hingegen nicht.

F: Benötige ich gemeinsam genutzten Speicher für Always On-Verfügbarkeitsgruppen?

A: Nein. Jede AG-Replik verwaltet ihre eigene, unabhängige Kopie der Datenbanken auf lokalem Speicher. Gemeinsamer Speicher ist nur erforderlich, wenn Sie Failovercluster-Instanzen zum Hosten von AG-Repliken verwenden.

F: Kann ich Always On mit SQL Server Standardausgabe?

A: SQL Server Die Standard Edition unterstützt Basic Availability Groups ab Version 1.0 ... SQL Server 2016, jedoch mit erheblichen Einschränkungen: eine Datenbank pro Verfügbarkeitsgruppe, maximal zwei Replikate und keine Unterstützung für lesbare sekundäre Replikate. FCI ist in der Standard Edition ohne diese Einschränkungen verfügbar. Für den vollen Funktionsumfang von Always On ist die Enterprise Edition erforderlich.

F: Wie viele Replikate kann eine Verfügbarkeitsgruppe maximal enthalten?

A: SQL Server Die Enterprise Edition unterstützt bis zu neun Replikate: ein primäres und acht sekundäre. Verteilte Verfügbarkeitsgruppen können dies auf 18 Replikate in zwei separaten Verfügbarkeitsgruppen erweitern.

F: Können auf FCI gehostete Replikate das automatische AG-Failover nutzen?

A: Nein. Wenn eine Verfügbarkeitsreplik auf einer Failoverclusterinstanz gehostet wird, wird ein automatisches Failover der Verfügbarkeitsgruppe für diese Replik nicht unterstützt. Alle AG-Failover mit FCI-gehosteten Replikaten erfordern einen manuellen Eingriff.

F: Worin besteht der Unterschied zwischen synchronem und asynchronem Commit-Modus?

A: Im synchronen Commit-Modus muss der primäre Server warten, bis der sekundäre Server die Protokolleinträge gehärtet hat, bevor er die Änderungen übernimmt. Dadurch wird Datenverlust (RPO = 0) vermieden, allerdings auf Kosten einer höheren Schreiblatenz. Im asynchronen Commit-Modus kann der primäre Server die Änderungen ohne Wartezeit übernehmen. Dies reduziert die Latenz, birgt aber das Risiko von Datenverlust, falls der primäre Server ausfällt, bevor der sekundäre Server alle Protokolleinträge empfangen hat. Verwenden Sie den synchronen Modus für lokale HA-Replikate und den asynchronen Modus für entfernte DR-Replikate.

F: Wie lange dauert ein/e SQL Server Immer eingeschaltete Ausfallsicherung?

A: Ein automatisches Failover für eine synchrone AG-Replik ist unter normalen Bedingungen in der Regel in weniger als 30 Sekunden abgeschlossen. Ein FCI-Failover dauert üblicherweise 20–60 Sekunden, abhängig von der Wiederherstellungszeit der Datenbank. Die tatsächliche Dauer hängt von der Arbeitslast, der Datenbankgröße und den in WSFC konfigurierten Timeout-Einstellungen für die Integritätsprüfung ab.

F: Was geschieht mit den Client-Verbindungen während eines Failovers?

A: Bestehende Verbindungen werden beim Failover getrennt. Anwendungen, die den Verfügbarkeitsgruppen-Listener verwenden und eine Logik zum Wiederherstellen der Verbindung enthalten, stellen nach Abschluss des Failovers automatisch eine neue Verbindung zum neuen primären Netzwerk her. Das Hinzufügen von „MultiSubnetFailover=True“ zu Verbindungszeichenfolgen verbessert die Geschwindigkeit der Wiederverbindung in Umgebungen mit mehreren Subnetzen.

F: Wie bewerbe ich mich? SQL Server Patches mit minimalen Ausfallzeiten in einer Always-On-Umgebung?

A: Verwenden Sie rollierende Upgrades: Patchen Sie zuerst die sekundären Replikate, führen Sie dann ein geplantes manuelles Failover auf ein gepatchtes sekundäres Replikat durch und patchen Sie schließlich das ehemalige primäre Replikat. Dadurch wird die Ausfallzeit auf die Dauer eines einzelnen geplanten Failovers begrenzt – typischerweise unter einer Minute.

F: Kann ich Always On-Verfügbarkeitsgruppen mit Failoverclusterinstanzen kombinieren?

A: Ja. Sie können AG-Replikate auf FCI-Instanzen hosten, um sowohl auf Instanz- als auch auf Datenbankebene einen Failover-Schutz zu erreichen. Jede FCI zählt als ein einzelnes AG-Replikat. Diese Topologie erfordert eine sorgfältige WSFC-Knotenplanung, um sicherzustellen, dass nach einem möglichen FCI-Failover kein einzelner Knoten zwei Replikate derselben AG hostet.

F: Was soll ich tun, wenn meine Datenbank in einer Always On-Umgebung beschädigt wird?

A: Prüfen Sie zunächst, ob die Beschädigung alle Replikate oder nur das primäre Replikat betrifft. Falls ein intaktes sekundäres Replikat vorhanden ist, führen Sie umgehend ein Failover auf dieses durch. Bei Beschädigung aller Replikate stellen Sie die Daten aus einem sauberen Backup wieder her. Führen Sie regelmäßig DBCC CHECKDB auf den sekundären Replikaten aus, um Beschädigungen frühzeitig zu erkennen. Falls auch Backups betroffen sind, ist ein spezialisiertes Tool erforderlich. SQL Server Datenwiederherstellungswerkzeug Als letzten Ausweg kann versucht werden, Daten aus beschädigten MDF-Dateien zu extrahieren.

F: Wie verhalten sich Always On-Verfügbarkeitsgruppen im Vergleich zu älteren Versionen? SQL Server HA-Lösungen?

A: AG ersetzt ältere Technologien wie z. B. Holztransport und ReplikationLogversand erfordert manuelles Failover und bietet keine automatische Rollenübergabe; Replikation ist für die Datenverteilung und nicht für Hochverfügbarkeit ausgelegt. Verfügbarkeitsgruppen (AG) bieten automatisiertes Failover, null Datenverlust durch synchrones Commit und lesbare Sekundärserver – Funktionen, die andere Technologien nicht bieten können.

8. Fazit

SQL Server Always On bietet eine flexible Plattform der Enterprise-Klasse für Hochverfügbarkeit und Disaster Recovery. Always On Availability Groups sind die optimale Lösung für die meisten modernen Bereitstellungen: Sie machen gemeinsam genutzten Speicher überflüssig, unterstützen lesbare Sekundärserver und ermöglichen sowohl lokale Hochverfügbarkeit als auch standortübergreifende Disaster Recovery in einer einzigen Konfiguration. Failover-Clusterinstanzen bleiben eine solide Option, wenn Failover auf Instanzebene und eine bestehende gemeinsam genutzte Speicherinfrastruktur die Hauptanforderungen darstellen. Die Kombination beider Technologien bietet den umfassendsten verfügbaren Schutz – allerdings auf Kosten höherer Infrastrukturinvestitionen und einer komplexeren Betriebsführung.

Unabhängig von der gewählten Lösung bleiben die Grundlagen gleich: Definieren Sie zunächst Ihre RTO- und RPO-Anforderungen, entwerfen Sie Ihre Topologie entsprechend und testen Sie den Failover regelmäßig. Eine gut implementierte und gründlich getestete Always-On-Lösung stellt sich bei Produktionsausfällen zuverlässig wieder her.

Über den Autor

Yuan Sheng ist ein erfahrener Datenbankadministrator (DBA) mit über 10 Jahren Erfahrung in SQL Server Umgebungen und Unternehmensdatenbankverwaltung. Er hat Hunderte von Datenbankwiederherstellungsszenarien in Finanzdienstleistungs-, Gesundheits- und Fertigungsunternehmen erfolgreich gelöst.

Yuan ist spezialisiert auf SQL Server Datenbankwiederherstellung, Hochverfügbarkeitslösungen und Leistungsoptimierung. Seine umfangreiche praktische Erfahrung umfasst die Verwaltung von Multi-Terabyte-Datenbanken, die Implementierung von Always On Availability Groups und die Entwicklung automatisierter Backup- und Wiederherstellungsstrategien für unternehmenskritische Geschäftssysteme.

Durch sein technisches Fachwissen und seinen praktischen Ansatz konzentriert sich Yuan auf die Erstellung umfassender Anleitungen, die Datenbankadministratoren und IT-Experten bei der Lösung komplexer SQL Server Herausforderungen effizient. Er bleibt auf dem Laufenden mit den neuesten SQL Server und die sich entwickelnden Datenbanktechnologien von Microsoft und testet regelmäßig Wiederherstellungsszenarien, um sicherzustellen, dass seine Empfehlungen den bewährten Vorgehensweisen der Praxis entsprechen.

Haben Sie Fragen zu SQL Server Wiederherstellung oder benötigen Sie zusätzliche Anleitung zur Datenbank-Fehlerbehebung? Yuan begrüßt Feedback und Vorschläge zur Verbesserung dieser technischen Ressourcen.