Hochverfügbarkeit für Microsoft SQL Server – häufige Fehler

Es gibt einen Moment, den kennt jeder, der lange genug mit Datenbanken zu tun hatte. Freitagabend, halb sieben, das Telefon klingelt. Am anderen Ende jemand, der sehr ruhig spricht, weil er innerlich schon schreit: „Der Cluster ist weg. Alle drei Knoten sind weg. Und der Listener antwortet auch nicht mehr.“ Und dann kommt der Satz, der die nächsten sechs Stunden bestimmt: „Aber wir haben doch Hochverfügbarkeit.“

Ja. Ihr habt Hochverfügbarkeit. Ihr habt sie sogar teuer bezahlt. Nur hat sie leider niemand zu Ende gedacht. Das ist der Kern der Sache: Availability Groups, Failover Cluster Instances und Log Shipping sind erstaunlich gut gebaute Technologien. Sie fallen selten von selbst um. Sie fallen um, weil bei der Planung eine Kleinigkeit übersehen wurde, die im Normalbetrieb nie auffällt und genau dann zuschlägt, wenn es zählt. Ein fehlender Witness. Eine DNS-Einstellung, die 20 Minuten lang die falsche Adresse ausliefert. Ein Backup-Job, der auf dem Secondary steht und nie läuft.

Dieser Artikel geht die acht Fehler durch, die mir in der Praxis am häufigsten begegnen. Nicht die abstrakten („zu wenig geplant“), sondern die konkreten, die du in deiner Umgebung nachprüfen kannst. Zu jedem Fehler gibt es das Symptom, an dem du ihn erkennst, die Ursache dahinter und die Gegenmaßnahme, die wirklich hilft. Nimm dir eine Stunde, geh die Liste durch und hak ab. Wenn du dabei mehr als zwei Haken nicht setzen kannst, hast du keine Hochverfügbarkeit, sondern eine Hoffnung mit Cluster-Symbol.

Was Hochverfügbarkeit verspricht – und was sie nicht verspricht

Bevor wir über Fehler reden, kurz die Messlatte. Hochverfügbarkeit ist keine Eigenschaft, die ein System hat oder nicht hat. Sie ist eine Zusage in zwei Zahlen: Wie lange darf der Dienst weg sein (RTO, Recovery Time Objective) und wie viele Daten dürfen verloren gehen (RPO, Recovery Point Objective)? Wenn diese beiden Zahlen nicht schriftlich existieren, kannst du gar nicht falsch bauen – aber eben auch nicht richtig.

Und noch etwas: Hochverfügbarkeit ist kein Backup. Sie schützt gegen Hardware, gegen Betriebssystem, gegen einen Knoten, der sich verabschiedet. Sie schützt nicht gegen ein versehentliches DELETE ohne WHERE, nicht gegen Ransomware und nicht gegen eine kaputte Anwendungslogik – all das repliziert die Availability Group brav und in Sekundenbruchteilen auf jedes Replikat. Wer HA und Datensicherung in einen Topf wirft, hat den teuersten Weg gefunden, einen logischen Fehler dreifach zu spiegeln.

Verfahren	Schutz gegen	typisches RTO	typisches RPO	wo es wehtut
Failover Cluster Instance (FCI)	Serverausfall, OS-Patch	1 bis 5 Minuten	0 (gemeinsamer Speicher)	Storage ist Single Point of Failure
AG synchron, automatisches Failover	Serverausfall, Storage-Ausfall	Sekunden bis 1 Minute	0	Commit-Latenz wirkt auf jede Transaktion
AG asynchron, manuelles Failover	Standortausfall	Minuten bis Stunden	> 0, abhängig von Send-Queue	Datenverlust ist eingebaut, nicht Ausnahme
Log Shipping	Standortausfall, logische Fehler mit Verzögerung	Stunden	Intervall des Logbackups	kein Automatismus, viel Handarbeit
Backup und Restore	alles, auch logische Fehler	Stunden bis Tage	Intervall des Logbackups	muss regelmäßig getestet werden

 

Faktenkasten: Was sich zuletzt geändert hat SQL Server 2025 (17.x) hat an der Hochverfügbarkeit spürbar geschraubt. Die wichtigsten Punkte, die deine Planung betreffen: • Vollständige und differenzielle Sicherungen sind jetzt auf jedem sekundären Replikat möglich, nicht mehr nur COPY_ONLY-Vollsicherungen und Protokollsicherungen. • Die Commit-Wartezeit der Availability Group („availability group commit time“) ist über sp_configure in Millisekunden einstellbar; vorher waren 10 ms fest verdrahtet. • Mit RestartThreshold = 0 fällt die AG-Ressource bei anhaltenden Gesundheitsproblemen sofort um, statt erst mehrere Neustarts durchzuprobieren. • Die Diagnose bei Health-Check-Timeouts ist deutlich besser: SQL Server schreibt jetzt Leistungsindikatoren in das Clusterprotokoll. • Standard Edition darf nun bis 32 Kerne und 256 GB Pufferpool nutzen – für viele Mittelstandslasten reicht das, ohne auf Enterprise zu gehen. • Über ALTER AVAILABILITY GROUP lässt sich eine Listener-IP einzeln entfernen, ohne den ganzen Listener zu löschen und neu anzulegen.

 

Der Aufbau selbst, mit allen Varianten und Entscheidungswegen, steht in Hochverfügbarkeit für Microsoft SQL Server. Hier geht es ausschließlich um das, was in der Praxis schiefgeht. Die thematische Klammer über alle SQL-Server-Themen findest du auf der Übersichtsseite Microsoft SQL Server.

Skizze 1: Eine typische Availability Group über zwei Rechenzentren. Vier Stimmen, Mehrheit ab drei – der Witness steht bewusst an einem dritten Ort.

Fehler 1 bis 4: Fundament, Netzwerkname, Modus und Sicherungen

Fehler 1: Availability Group ohne durchdachtes Quorum und ohne Witness

Das ist der Klassiker unter den Klassikern, und er ist besonders bitter, weil er im Normalbetrieb vollkommen unsichtbar bleibt. Zwei Knoten, eine Availability Group, alles grün. Bis einer der beiden Knoten ausfällt – und der überlebende sich weigert, die Datenbanken online zu bringen.

Symptom: Nach dem Ausfall eines einzelnen Knotens steht die gesamte Availability Group. Die Datenbanken stehen auf „Nicht synchronisiert“ oder direkt auf „Wird aufgelöst“ (Resolving). Im Clusterprotokoll findest du Meldungen über verlorenes Quorum, der Clusterdienst hat sich sauber selbst beendet. Der Cluster ist nicht kaputt, er weigert sich nur, ohne Mehrheit weiterzumachen. Das ist übrigens korrektes Verhalten und rettet dich vor Split-Brain – nur ist das im laufenden Ausfall ein schwacher Trost.

Ursache: Ein Windows Server Failover Cluster arbeitet mit Stimmen. Zwei Knoten sind zwei Stimmen; fällt einer weg, bleibt eine von zwei übrig, und eine von zwei ist keine Mehrheit. Ohne eine dritte Stimme in Form eines Witness kippt der Cluster beim ersten Knotenausfall. Genauso beliebt ist die Variante mit drei Knoten und Witness – vier Stimmen, gerade Zahl, ohne dynamisches Quorum wieder eine Patt-Situation. Oder der Witness liegt auf einer Dateifreigabe, die zufällig genau im Rechenzentrum steht, in dem auch zwei der drei Knoten stehen: Fällt dieser Standort aus, sind sofort drei von vier Stimmen weg, und der überlebende Standort schaltet sich selbst ab.

Gegenmaßnahme: Konfiguriere immer einen Witness. Windows Server verwaltet die Stimmgewichte seit Windows Server 2012 R2 dynamisch (dynamisches Quorum und dynamischer Witness) und passt die Rechnung an – aber das funktioniert nur, wenn ein Witness überhaupt existiert. Als Witness stehen drei Bauformen zur Wahl. Und der wichtigste Satz überhaupt: Der Witness gehört an einen dritten Ort, nicht in eines der beiden produktiven Rechenzentren. Ein Witness, der zusammen mit der Hälfte deiner Knoten ausfällt, ist kein Schiedsrichter, sondern ein Mitspieler.

Witness-Typ	wofür geeignet	Voraussetzung	Fallstrick
Cloud Witness	Standardfall, gestreckte Cluster, Cluster ohne gemeinsamen Speicher	Azure-Speicherkonto vom Typ General Purpose v2, Port 443 nach außen offen	Schlüsselrotation vergessen; Proxy blockiert core.windows.net
Dateifreigabe (File Share Witness)	klassisches Rechenzentrum mit drittem Standort	SMB 2 oder neuer, ausschließlich für einen Cluster, mindestens 5 MB frei	DFS und replizierte Freigaben werden nicht unterstützt; Freigabe steht im falschen Brandabschnitt
Datenträger (Disk Witness)	FCI mit gemeinsamem Speicher	gemeinsamer Datenträger, NTFS oder ReFS, größer als 512 MB	bei Availability Groups meist gar nicht vorhanden

 

Warnung: Der Zwei-Knoten-Cluster ohne Witness Wenn du nur eines aus diesem Artikel mitnimmst, dann das: Ein Zwei-Knoten-Cluster ohne Witness überlebt keinen einzigen Knotenausfall. Nicht „mit Einschränkungen“, nicht „mit kurzer Störung“ – er steht. Genau der Fall, für den du die Availability Group gebaut hast, ist der Fall, den sie nicht abfangen kann. Prüfe das jetzt mit Get-ClusterQuorum und Get-ClusterNode | Select Name, NodeWeight, DynamicWeight. Das dauert zwei Minuten und beantwortet die Frage endgültig.

 

Fehler 2: Listener und DNS – der Ausfall, der zwanzig Minuten dauert

Ein Failover, das technisch nach acht Sekunden durch ist und für die Anwendungen trotzdem eine Viertelstunde dauert: Das ist fast immer ein DNS-Thema. Und es ist der Fehler, bei dem die Betriebsmannschaft am längsten in die falsche Richtung sucht, weil auf SQL-Seite alles grün ist.

Symptom: Das Failover läuft laut Clusterprotokoll und AG-Dashboard sauber durch. Die neue primäre Instanz ist online, die Datenbanken sind lesbar und schreibbar. Trotzdem melden die Anwendungen minutenlang Zeitüberschreitungen, teilweise auch das schöne „Die angegebene Netzwerkadresse ist nicht erreichbar“. Manche Clients kommen sofort zurück, andere erst nach 15 bis 20 Minuten. Ein Neustart des Anwendungsservers „behebt“ das Problem – was die Fehlersuche zuverlässig in die Sackgasse schickt.

Ursache: Der Listener ist ein Netzwerkname im Cluster mit einer oder mehreren IP-Adressen. Über mehrere Subnetze hinweg hat er pro Subnetz eine eigene Adresse. Jetzt kommen zwei Stellschrauben ins Spiel, die gerne falsch stehen. RegisterAllProvidersIP steuert, ob alle Listener-Adressen im DNS registriert werden oder nur die des gerade aktiven Knotens. HostRecordTTL bestimmt, wie lange Clients den DNS-Eintrag zwischenspeichern – der Standardwert ist 1200 Sekunden, also 20 Minuten. Und drittens muss der Client mitspielen: Ohne MultiSubnetFailover=True in der Verbindungszeichenfolge probiert der Treiber die Adressen nacheinander durch, statt parallel.

Dazu ein Detail, das viele überrascht: Legst du den Listener per T-SQL oder über den SSMS-Assistenten an, steht RegisterAllProvidersIP auf 1. Legst du ihn im Failovercluster-Manager als Netzwerknamen an, steht er auf 0. Zwei Wege, zwei Ergebnisse, ein sehr unterschiedliches Failover-Verhalten. Wer die Umgebung nicht selbst gebaut hat, sollte den Wert grundsätzlich nachsehen statt annehmen.

Einstellung	Standard	moderne Clients	Altanwendungen ohne MultiSubnetFailover
RegisterAllProvidersIP	1 bei Anlage per T-SQL, 0 bei Anlage im Cluster-Manager	1	0 – sonst antwortet DNS mit einer Adresse, die gerade offline ist
HostRecordTTL	1200 Sekunden	1200 Sekunden sind unkritisch	300 Sekunden oder weniger, besser 60
MultiSubnetFailover	nicht gesetzt	True – auch bei nur einem Subnetz	nicht verfügbar, daher DNS-seitig kompensieren
Listener-Port	1433	1433 spart die Portangabe	abweichender Port muss in jede Verbindungszeichenfolge

 

Tipp: MultiSubnetFailover gehört immer in die Verbindungszeichenfolge Microsoft empfiehlt MultiSubnetFailover=True ausdrücklich auch dann, wenn deine Availability Group heute nur ein einziges Subnetz umfasst. Der Treiber öffnet dann die TCP-Verbindungen zu allen bekannten Adressen parallel und nimmt die erste, die antwortet. Das beschleunigt auch das Failover innerhalb eines Subnetzes – und wenn ihr in drei Jahren ein zweites Rechenzentrum anbindet, muss niemand hunderte Verbindungszeichenfolgen anfassen. Zweiter Punkt aus derselben Ecke: Wenn ihr mit erzwungener Verschlüsselung arbeitet, muss der Listener-Name im Subject Alternative Name des Zertifikats stehen. Sonst schlägt die Verbindung über den Listener fehl, während sie direkt auf den Instanznamen funktioniert – ein Fehlerbild, das erfahrungsgemäß einen halben Tag frisst.

 

Fehler 3: Synchron oder asynchron – geraten statt gerechnet

„Wir nehmen synchron, das ist sicherer.“ Ein Satz, der in Planungsrunden erstaunlich oft fällt und erstaunlich selten hinterfragt wird. Er ist nicht falsch. Er ist nur unvollständig, weil er die Rechnung auf der anderen Seite unterschlägt.

Symptom bei falsch gewähltem Synchronmodus: Die Anwendung wird nach der Einführung der Availability Group spürbar langsamer, und zwar ausgerechnet bei Schreiblast. Batch-Läufe, die vorher 20 Minuten brauchten, dauern jetzt 50. In den Wartestatistiken dominiert HADR_SYNC_COMMIT. Jede einzelne Transaktion wartet darauf, dass das Protokoll auf dem sekundären Replikat auf Platte geschrieben ist – bei einer Netzwerklaufzeit von 4 ms und 50.000 Commits ist das keine Kleinigkeit mehr, sondern die Hauptzeit.

Symptom bei falsch gewähltem Asynchronmodus: Alles ist schnell, bis es knallt. Beim ungeplanten Failover fehlen die letzten Transaktionen. Wie viele genau, weiß niemand, weil niemand die Send-Queue überwacht hat. Und weil asynchrone Replikate kein automatisches Failover können, muss jemand von Hand eingreifen – mit FORCE_FAILOVER_ALLOW_DATA_LOSS, einem Befehl, dessen Name erfreulich ehrlich ist.

Ursache: Es ist eine bewusste Abwägung zwischen Commit-Latenz und Datenverlust, und diese Abwägung gehört dem Fachbereich, nicht der IT. Die IT liefert die Zahlen, der Fachbereich entscheidet, ob fünf Minuten verlorene Buchungen akzeptabel sind oder ob dafür jede Transaktion 6 ms länger dauern darf. Wird diese Frage nie gestellt, entscheidet der Standardwert im Assistenten.

Gegenmaßnahme: Miss zuerst, dann entscheide. Die Netzwerklaufzeit zwischen den Standorten ist die harte Grenze für den synchronen Modus. Als Faustregel aus der Praxis: Unter 1 ms Round-Trip ist synchron unproblematisch, zwischen 1 und 5 ms wird es je nach Commit-Rate spürbar, oberhalb von 5 ms wird synchroner Commit für Systeme mit hoher Schreiblast zur Bremse. Der gängige Aufbau ist deshalb gemischt: zwei synchrone Replikate im selben Standort für automatisches Failover, ein asynchrones Replikat im entfernten Rechenzentrum für den Standortausfall. Seit SQL Server 2025 lässt sich die Commit-Wartezeit zusätzlich über sp_configure feinjustieren, statt mit einem fest eingebauten Wert von 10 ms zu leben.

Kriterium	Synchroner Commit	Asynchroner Commit
Datenverlust bei Failover	keiner, sofern der Zustand SYNCHRONIZED ist	möglich, Umfang entspricht der Send-Queue
Automatisches Failover	ja, mit Failovermodus Automatisch	nein, nur erzwungen von Hand
Wirkung auf die Anwendung	jede Transaktion wartet auf das Replikat	keine spürbare Wirkung auf den Commit
Empfohlene Netzwerklaufzeit	möglichst unter 1 ms, praktikabel bis etwa 5 ms	auch über WAN mit 30 ms und mehr
Typischer Einsatz	zweites Replikat im selben Standort	Replikat im entfernten Rechenzentrum
Was du überwachen musst	HADR_SYNC_COMMIT, Commit-Latenz	log_send_queue_size, letzte gehärtete LSN

 

Wichtig: Synchron heißt nicht automatisch verlustfrei Ein synchrones Replikat garantiert nur dann null Datenverlust, wenn es tatsächlich im Zustand SYNCHRONIZED ist. Hängt es hinterher – etwa weil auf dem Secondary gerade eine große Sicherung läuft oder das Storage klemmt – steht es auf SYNCHRONIZING, und ein automatisches Failover findet gar nicht statt. Die AG bleibt dann lieber stehen, als Daten zu verlieren. Genau deshalb ist die Überwachung des Synchronisationszustands kein Nice-to-have. Wer nur prüft, ob die Replikate „verbunden“ sind, prüft die falsche Spalte.

 

Fehler 4: Sicherungen auf dem Secondary – vergessen, doppelt oder mit gerissener Kette

Backups auf das sekundäre Replikat auszulagern ist eine gute Idee. Die primäre Instanz wird entlastet, die Sicherung läuft dort, wo gerade Luft ist. Nur ist die Umsetzung anspruchsvoller, als der Schalter im Assistenten vermuten lässt – und der Fehler fällt typischerweise erst auf, wenn du wiederherstellen musst.

Symptom: Drei Varianten, alle drei habe ich in freier Wildbahn gesehen. Erstens: Nach dem ersten Failover läuft überhaupt keine Sicherung mehr, weil die Aufträge nur auf dem ursprünglichen Primärknoten angelegt wurden. Zweitens: Die Sicherungsaufträge laufen auf allen Knoten und melden „Erfolg“, tun aber nichts, weil die Skripte die Sicherungspräferenz auswerten und sich auf allen Knoten für unzuständig erklären. Drittens, der teuerste Fall: Die Protokollsicherungen liegen verstreut auf drei verschiedenen Servern, und beim Restore fehlt genau das Stück, das jemand mit einer COPY_ONLY-Sicherung überschrieben zu haben glaubte.

Ursache: Die Availability Group kennt eine automatisierte Sicherungspräferenz (AUTOMATED_BACKUP_PREFERENCE) und pro Replikat eine Priorität (BACKUP_PRIORITY). Diese Einstellung steuert aber nichts von allein – sie ist reine Information. Ausgewertet wird sie von der Funktion sys.fn_hadr_backup_is_preferred_replica, und zwar nur, wenn dein Sicherungsskript sie auch aufruft. Wer das nicht weiß, konfiguriert eine Präferenz, wundert sich und hat am Ende entweder gar keine oder mehrere konkurrierende Sicherungen.

Dazu kommen die Regeln, welche Sicherungsarten überhaupt auf einem sekundären Replikat erlaubt sind. Bis einschließlich SQL Server 2022 galt: Vollsicherungen nur als COPY_ONLY, differenzielle Sicherungen gar nicht, Protokollsicherungen ganz normal – und die dürfen ausdrücklich nicht COPY_ONLY sein, weil sie sonst die Kette nicht fortschreiben. Seit SQL Server 2025 sind zusätzlich vollständige und differenzielle Sicherungen auf jedem sekundären Replikat möglich. Wenn du eine gemischte Landschaft betreibst, gilt für die Skripte weiterhin die Regel der ältesten Version.

Sicherungsart	auf dem Primary	auf dem Secondary bis SQL Server 2022	auf dem Secondary ab SQL Server 2025
Vollsicherung	ja	nur mit COPY_ONLY	ja, auch regulär
Differenzielle Sicherung	ja	nicht unterstützt	ja
Protokollsicherung	ja	ja, ohne COPY_ONLY	ja, ohne COPY_ONLY
COPY_ONLY-Protokollsicherung	möglich, aber selten sinnvoll	nicht unterstützt	nicht unterstützt
RESTORE	nicht erlaubt in einer AG	nicht erlaubt in einer AG	nicht erlaubt in einer AG

 

Warnung: Die Protokollkette lebt über alle Replikate hinweg Protokollsicherungen bilden eine durchgehende Kette – unabhängig davon, auf welchem Replikat sie erzeugt wurden. Das ist die gute Nachricht: SQL Server sorgt dafür, dass die Kette konsistent bleibt, egal ob synchron oder asynchron repliziert wird. Die schlechte Nachricht: Wenn die Sicherungsdateien auf drei lokalen Laufwerken verteilt liegen, nützt dir die konsistente Kette wenig. Sichere grundsätzlich auf eine Freigabe oder ein Ziel, das alle Replikate erreichen – und das im Ernstfall auch dann noch erreichbar ist, wenn eines der Rechenzentren fehlt. Und noch ein Stolperstein: Gleichzeitige Sicherungen werden nicht unterstützt. Eine Protokollsicherung auf dem Primary, während auf dem Secondary eine Vollsicherung läuft, ist kein unterstütztes Szenario.

 

Wie du Sicherungen, Konsistenzprüfungen und Indexpflege sauber über alle Replikate hinweg planst, ist ein Thema für sich. Die Details dazu stehen in Wartungspläne für Microsoft SQL Server. Der wichtigste Grundsatz vorab: Ein Wartungsauftrag, der in einer Availability Group nicht weiß, auf welchem Replikat er gerade läuft, ist ein Auftrag, der irgendwann das Falsche tut.

Fehler 5 bis 8: Betrieb, Konsistenz, Leistung und Lizenzen

Fehler 5: Das Failover wurde nie geübt

Von allen acht Fehlern ist dieser der billigste zu beheben und der teuerste, wenn man ihn lässt. Es kostet nichts außer einem Wartungsfenster und etwas Mut. Trotzdem ist er der häufigste.

Symptom: Auf die Frage „Wann habt ihr zuletzt ein Failover durchgeführt?“ kommt eine kurze Pause und dann eine von drei Antworten. „Bei der Einführung.“ „Ungeplant, letztes Jahr, das war unschön.“ Oder mein Favorit: „Wir trauen uns nicht, das ist ein Produktivsystem.“ Genau. Es ist ein Produktivsystem. Deshalb muss es funktionieren. Ein Failover-Mechanismus, den niemand auszulösen wagt, ist im Ernstfall nur Dekoration.

Ursache: Die Ursache ist nicht technisch, sondern organisatorisch. Niemand ist für den Test zuständig, es gibt kein Wartungsfenster dafür, und jeder Test bindet Fachbereiche, die lieber arbeiten würden. Also verschiebt man ihn. Ein Jahr später hat sich die Umgebung an vier Stellen geändert, und keine dieser Änderungen wurde jemals gegen ein Failover geprüft.

Skizze 2: Der Ablauf eines ungeplanten Failovers. Die Technik ist meist nach Sekunden fertig – die Zeit verbrennt in der Wiederherstellung und beim Verbindungsaufbau der Anwendungen.

Gegenmaßnahme: Übe beides, geplant und ungeplant, und zwar getrennt. Ein geplantes Failover über ALTER AVAILABILITY GROUP … FAILOVER ist harmlos und beantwortet nur die halbe Frage: Es prüft, ob der Rollenwechsel funktioniert. Ein ungeplantes Failover simulierst du, indem du dem primären Knoten wirklich den Stecker ziehst – Netzwerkkarte deaktivieren, Dienst hart beenden, virtuelle Maschine ausschalten. Nur so siehst du, wie lange Erkennung, Arbitrierung und Wiederherstellung tatsächlich dauern und ob deine Anwendungen den Verbindungsverlust überhaupt sauber abfangen.

Testfall	Wie	Was du dabei misst	Rhythmus
Geplantes Failover	ALTER AVAILABILITY GROUP … FAILOVER	Dauer des Rollenwechsels, Verhalten der Anwendungen	vierteljährlich, im Wartungsfenster
Ungeplantes Failover	Netzwerkkarte des Primary deaktivieren oder Instanz hart beenden	Erkennungszeit, Recovery-Dauer, tatsächliches RTO	halbjährlich
Standortausfall	gesamtes Rechenzentrum simulieren, erzwungenes Failover	Quorum-Verhalten, Datenverlust, manuelle Schritte	jährlich
Wiederherstellung aus Sicherung	Restore auf einen separaten Server	Vollständigkeit der Protokollkette, RTO ohne AG	vierteljährlich
Rückfall auf den alten Primary	Failback nach dem Test	Nachsynchronisation, Dauer bis SYNCHRONIZED	bei jedem Failover-Test

 

Tipp: Das Protokoll ist wichtiger als der Test Schreib bei jedem Test mit: Uhrzeit des Auslösers, Uhrzeit, zu der die Datenbanken online waren, Uhrzeit, zu der die erste Anwendung wieder gearbeitet hat. Diese drei Zeitstempel sind deine echten Kennzahlen – nicht das, was im Konzept steht. In der Praxis liegen sie regelmäßig um den Faktor drei bis zehn auseinander. Wenn die Geschäftsführung ein RTO von fünf Minuten zugesagt bekommen hat und dein gemessener Wert liegt bei 22 Minuten, dann ist das eine Erkenntnis, die du im Test haben willst und nicht im Ausfall.

 

Fehler 6: Die halbe Instanz – Logins, Aufträge, Verbindungsserver und Zertifikate

Eine Availability Group repliziert Datenbanken. Sie repliziert keine Instanz. Dieser eine Satz ist die Ursache für die meisten „Es hat alles funktioniert, außer …“-Momente nach einem Failover.

Symptom: Das Failover war technisch einwandfrei, die Datenbanken sind online – und trotzdem funktioniert die halbe Landschaft nicht. Anwendungen melden „Fehler beim Anmelden für den Benutzer“, obwohl der Benutzer in der Datenbank existiert. Nächtliche Aufträge laufen nicht mehr. Berichte, die über einen Verbindungsserver auf ein anderes System zugreifen, brechen ab. Datenbanken mit Verschlüsselung (TDE) lassen sich auf dem neuen Primary gar nicht erst öffnen.

Ursache: Alles, was in der master-, msdb- oder model-Datenbank lebt, gehört zur Instanz und nicht zur Availability Group. Anmeldungen liegen in master, SQL-Server-Agent-Aufträge in msdb, Verbindungsserver in master, Datenbank-E-Mail-Profile in msdb, Zertifikate und Verschlüsselungsschlüssel ebenfalls in master. Beim Aufbau richtet man das auf dem ersten Knoten ein, kopiert die Datenbanken – und der Rest bleibt einfach zurück. Besonders tückisch bei Anmeldungen: Kopierst du einen SQL-Login ohne die ursprüngliche SID, entsteht ein verwaister Benutzer. Der Name stimmt, die SID nicht, die Anmeldung schlägt fehl. Alles sieht richtig aus.

Gegenmaßnahme: Führe eine Liste dessen, was zur Instanz gehört, und gleiche sie regelmäßig ab – am besten skriptgesteuert und nicht per Sichtprüfung. Für Anmeldungen überträgst du SID und Passwort-Hash mit, nicht nur den Namen. Agent-Aufträge legst du auf allen Knoten an und lässt sie zu Beginn prüfen, ob die aktuelle Instanz überhaupt der primäre Knoten ist. Und wenn du auf SQL Server 2022 oder neuer arbeitest: Contained Availability Groups nehmen dir einen guten Teil dieser Arbeit ab, weil sie eigene Instanzen von master und msdb innerhalb der Availability Group führen. Seit SQL Server 2025 lassen sich sogar verteilte Availability Groups zwischen zwei Contained AGs aufbauen.

Objekt	lebt in	wird von der AG repliziert?	Was du tun musst
Anmeldungen (Logins)	master	nein	mit SID und Hash übertragen, regelmäßig abgleichen, verwaiste Benutzer prüfen
Serverrollen und Berechtigungen	master	nein	skriptgesteuert auf allen Replikaten anlegen
SQL-Server-Agent-Aufträge	msdb	nein	auf allen Knoten anlegen, Rollenprüfung als ersten Schritt einbauen
Verbindungsserver (Linked Server)	master	nein	inklusive Anmeldezuordnungen überall einrichten
Datenbank-E-Mail und Operatoren	msdb	nein	identisch konfigurieren, sonst kommt keine Meldung an
Zertifikate und Schlüssel (TDE)	master	nein	Zertifikat mit privatem Schlüssel auf jedes Replikat übertragen, vor dem Hinzufügen der Datenbank
Serverkonfiguration (sp_configure)	master	nein	MAXDOP, Kostenschwelle, Arbeitsspeichergrenzen angleichen
Ablaufverfolgungsflags	Startparameter	nein	auf allen Knoten identisch setzen
Anmeldeauslöser	master	nein	mitpflegen, sonst greift die Absicherung nur auf einem Knoten

 

Warnung: TDE-Zertifikate zuerst, Datenbank danach Wenn du eine mit TDE verschlüsselte Datenbank zu einer Availability Group hinzufügen willst, muss das Zertifikat samt privatem Schlüssel vorher auf allen Replikaten liegen. Sonst schlägt schon das Hinzufügen fehl – und wenn du es über Umwege doch schaffst, steht die Datenbank auf dem Secondary im Zustand „Wiederherstellung ausstehend“ und lässt sich nicht öffnen. Das ist einer der Fälle, in denen ein Failover-Test das Problem sofort zeigt, ein Blick ins Dashboard hingegen nicht.

 

Fehler 7: Netzwerk und Speicher als blinder Fleck

Availability Groups verschieben Transaktionsprotokoll. Nichts sonst. Wenn Netzwerk oder Speicher nicht mitkommen, staut sich das Protokoll – und zwar an zwei sehr unterschiedlichen Stellen mit sehr unterschiedlichen Folgen. Wer nur „Replikat verbunden: ja“ überwacht, sieht davon nichts.

Skizze 3: Der Weg einer Änderung vom primären zum sekundären Replikat. Die Send-Queue bestimmt dein RPO, die Redo-Queue dein RTO.

Symptom: Die Availability Group ist grün, aber das Transaktionsprotokoll auf dem Primary wächst und wächst und lässt sich nicht abschneiden. In sys.databases steht als log_reuse_wait_desc der Wert AVAILABILITY_REPLICA. Oder umgekehrt: Alles läuft rund, bis das Failover kommt – und dann dauert die Wiederherstellung 25 Minuten, weil das Secondary erst noch aufholen muss, was es zwar empfangen, aber nie angewendet hat. Ein drittes Symptom sind sporadische Failover ohne erkennbaren Grund: Das sind meist Health-Check- oder Lease-Timeouts, weil das Speichersystem für Sekunden nicht antwortet.

Ursache: Zwischen primärem und sekundärem Replikat liegen zwei Warteschlangen. Die Send-Queue enthält Protokoll, das noch nicht gesendet wurde – das ist dein potenzieller Datenverlust. Die Redo-Queue enthält Protokoll, das angekommen und auf Platte geschrieben, aber noch nicht in die Datenbank eingearbeitet wurde – das ist deine Wiederherstellungszeit beim Failover. Beide Zahlen stehen in sys.dm_hadr_database_replica_states, und beide werden erschreckend selten überwacht. Die Redo-Queue leidet besonders unter langsamem Speicher auf dem Secondary. Und genau da wird gern gespart, nach dem Motto „ist ja nur das Standby“. Das ist ein Denkfehler: Das Standby muss im Ernstfall die volle Produktivlast tragen. Wenn es das nicht kann, hast du kein Failover, sondern einen kontrollierten Übergang in eine langsamere Störung.

Kennzahl	Quelle	Was sie bedeutet	Schwelle, ab der du hinsehen solltest
log_send_queue_size	sys.dm_hadr_database_replica_states	noch nicht übertragenes Protokoll – dein Datenverlust	dauerhaft über wenigen MB
log_send_rate	sys.dm_hadr_database_replica_states	tatsächlicher Durchsatz zum Replikat	unter der Protokollerzeugungsrate des Primary
redo_queue_size	sys.dm_hadr_database_replica_states	empfangen, aber nicht angewendet – deine Failover-Dauer	wenn Größe geteilt durch redo_rate über dem RTO liegt
redo_rate	sys.dm_hadr_database_replica_states	Abarbeitungsgeschwindigkeit auf dem Secondary	Einbrüche deuten auf Speicher oder blockierende Lesevorgänge
log_reuse_wait_desc	sys.databases	warum das Protokoll nicht abgeschnitten wird	Wert AVAILABILITY_REPLICA über längere Zeit
HADR_SYNC_COMMIT	Wartestatistiken	Wartezeit auf synchrone Replikate	wenn die Wartezeit in den oberen Rängen auftaucht
Lease- und Health-Check-Timeout	Clusterprotokoll, Ereignisanzeige	Instanz antwortet dem Cluster nicht rechtzeitig	jedes Auftreten ist eine Untersuchung wert

 

Diese Werte gehören nicht in eine Abfrage, die jemand im Störungsfall heraussucht, sondern in eine dauerhafte Überwachung mit Schwellwerten und Alarmierung. Wie das aussieht und welche Kennzahlen darüber hinaus wichtig sind, steht in SQL Server Monitoring und Überwachung. Ein Hinweis noch zum Netzwerk selbst: Trenne den Replikationsverkehr möglichst vom Anwendungsverkehr und prüfe, dass Jumbo Frames, Energiesparoptionen der Netzwerkkarten und Firewallregeln auf allen Knoten identisch konfiguriert sind. Asymmetrische Netzwerkeinstellungen zwischen zwei Knoten produzieren Fehlerbilder, die niemand gerne sucht.

Fehler 8: Die Lizenzfalle passiver Knoten

Der achte Fehler ist der einzige, der nicht in der Ereignisanzeige auftaucht. Er taucht in einer E-Mail auf, die mit „im Rahmen einer Überprüfung Ihrer Lizenzierung“ beginnt. Und er ist besonders ärgerlich, weil er meist aus einer gut gemeinten technischen Entscheidung entsteht.

Symptom: Bei einer Lizenzprüfung stellt sich heraus, dass ein Replikat nachlizenziert werden muss, das die IT jahrelang als „passiv, kostenfrei“ geführt hat. Bei Enterprise-Kernlizenzen sind das schnell sechsstellige Beträge. Der zweite typische Fall: Die Software Assurance ist irgendwann ausgelaufen und niemand hat gemerkt, dass damit auch das Recht auf den kostenfreien passiven Knoten verfallen ist.

Ursache: Das Recht, ein passives Replikat ohne eigene Lizenz zu betreiben, ist kein Bestandteil der Lizenz selbst. Es ist ein Vorteil der Software Assurance beziehungsweise eines Abonnements. Ohne aktive Software Assurance musst du jedes Replikat vollständig lizenzieren – auch das, das nur danebensteht und wartet. Und der zweite Teil der Ursache: Der Begriff „passiv“ ist enger gefasst, als die meisten annehmen. Ein Replikat, auf dem Berichte laufen, auf das über Read-Only-Routing Leseabfragen verteilt werden oder das für Testzwecke abgefragt wird, ist nicht passiv. Es ist aktiv, und es kostet.

Gegenmaßnahme: Klär drei Dinge schriftlich, bevor du baust. Erstens: Läuft die Software Assurance, und bis wann? Zweitens: Wie viele passive Replikate deckt sie in eurem Vertrag ab? Üblich ist ein passives Replikat für Hochverfügbarkeit und eines für die Notfallwiederherstellung. Drittens: Was genau läuft auf jedem einzelnen Replikat? Und da wird es interessant – denn ausgerechnet die technisch sinnvolle Auslagerung von Sicherungen und Konsistenzprüfungen auf das Secondary ist ein Punkt, an dem sich die Aussagen im Lizenzierungsleitfaden und in den Produktbestimmungen historisch nicht immer gedeckt haben. Wenn du hier Geld in nennenswerter Höhe im Spiel hast, hol dir die Auslegung für deinen konkreten Vertrag schriftlich vom Lizenzgeber oder deinem Partner. Ein Bauchgefühl ist keine Vertragsgrundlage.

Nutzung des Replikats	Einordnung	Lizenzbedarf
Reines Standby, synchron, kein Zugriff	passiv	durch Software Assurance abgedeckt, sofern diese aktiv ist
Standby im entfernten Rechenzentrum, asynchron	passiv	durch Software Assurance abgedeckt, in der Regel als zweites passives Replikat
Lesbares Secondary mit Berichten oder Read-Only-Routing	aktiv	voll zu lizenzieren, gleiche Kernzahl wie das Primary
Secondary, auf dem Sicherungen laufen	Auslegungssache	im Vorfeld für den eigenen Vertrag klären, schriftlich
Kein Software-Assurance-Vertrag vorhanden	irrelevant	jedes Replikat einzeln zu lizenzieren, auch das reine Standby
Kurzer Failover-Test	zulässig	regelmäßige Tests sind vorgesehen, Umfang und Häufigkeit vertraglich prüfen

 

Wichtig: Lesbares Secondary klingt gratis, ist es aber nicht Die Verlockung ist groß: Das zweite Replikat steht ohnehin da, warum sollen die Berichte nicht dorthin? Technisch ist das eine gute Idee, lizenzrechtlich verwandelt sie ein kostenfreies passives Replikat in ein voll zu lizenzierendes aktives. Rechne das vorher durch. Bei Enterprise-Kernlizenzen kann die Entscheidung, ein paar Berichte auszulagern, teurer sein als der zusätzliche Server, den man sich damit sparen wollte.

 

Die Prüfliste für deine Umgebung

Acht Fehler, acht Prüfungen. Geh die Liste durch und beantworte jede Frage mit Ja oder Nein – nicht mit „müsste eigentlich“. Bei jedem Nein hast du eine Aufgabe, und die Reihenfolge in dieser Liste ist ungefähr die Reihenfolge, in der du sie abarbeiten solltest.

Es existiert ein Witness, er steht an einem dritten Ort, und die Stimmverteilung ist dokumentiert.

RegisterAllProvidersIP, HostRecordTTL und die Verbindungszeichenfolgen der Anwendungen sind aufeinander abgestimmt – geprüft, nicht angenommen.

Für jedes Replikat ist schriftlich festgehalten, warum es synchron oder asynchron läuft, und der Fachbereich kennt die Entscheidung.

Sicherungsaufträge liegen auf allen Replikaten, werten die Sicherungspräferenz aus und schreiben auf ein Ziel, das im Ernstfall erreichbar ist.

Ein geplantes und ein ungeplantes Failover wurden in den letzten sechs Monaten durchgeführt und die Zeiten protokolliert.

Anmeldungen, Agent-Aufträge, Verbindungsserver, Zertifikate und Serverkonfiguration sind auf allen Replikaten abgeglichen.

Send-Queue, Redo-Queue und die Wartezeiten der Synchronisation werden dauerhaft überwacht und alarmieren.

Der Lizenzstatus jedes Replikats ist schriftlich geklärt, inklusive Laufzeit der Software Assurance.

Ein realistischer Blick zum Schluss dieses Abschnitts: In den meisten Umgebungen, die ich zum ersten Mal sehe, lassen sich drei bis fünf dieser Punkte nicht mit Ja beantworten. Das ist kein Vorwurf – das ist der Normalzustand, weil HA-Landschaften über Jahre wachsen und niemand die Zeit hat, das Gesamtbild regelmäßig zu prüfen. Wichtig ist nur, dass du es weißt, bevor es jemand anders für dich herausfindet.

Weiterlesen › Microsoft SQL Server – die Übersicht über alle Themen rund um SQL Server › Hochverfügbarkeit für Microsoft SQL Server – Architekturen, Verfahren und Entscheidungswege › SQL Server Monitoring und Überwachung – welche Kennzahlen du dauerhaft im Blick behalten musst › Wartungspläne für Microsoft SQL Server – Sicherungen, Konsistenzprüfungen und Indexpflege in einer AG › SQL Server Beratung – wenn du die Prüfliste nicht allein abarbeiten willst

 

Häufige Fragen

Brauche ich wirklich einen Witness, wenn ich drei Knoten habe?

Ja. Mit drei Knoten überlebst du zwar den Ausfall eines Knotens auch ohne Witness, aber nicht den Ausfall von zweien – und im gestreckten Cluster über zwei Standorte ist genau das der Fall, gegen den du dich absicherst. Microsoft empfiehlt seit Windows Server 2012 R2 grundsätzlich, immer einen Witness zu konfigurieren. Das dynamische Quorum passt die Stimmgewichte dann selbstständig an, sodass eine gerade Stimmzahl kein Problem mehr ist. Der Witness ist billig, der Ausfall ohne ihn nicht.

Kann ich mit einer Availability Group auf Backups verzichten?

Nein, und die Frage kommt trotzdem regelmäßig. Eine Availability Group repliziert jede Änderung – auch die falsche. Ein versehentlich gelöschter Datenbestand, eine fehlerhafte Migration, eine Verschlüsselung durch Schadsoftware: All das landet innerhalb von Sekunden auf jedem Replikat. Sicherungen sind der einzige Weg zurück in einen früheren Zustand. Die Availability Group hilft dir beim Wo, die Sicherung beim Wann.

Warum dauert mein Failover viel länger als die versprochenen Sekunden?

In aller Regel aus zwei Gründen, und beide stehen in Skizze 2. Erstens die Redo-Queue: Wenn das sekundäre Replikat empfangenes Protokoll noch nicht eingearbeitet hat, muss es das vor dem Onlinegehen nachholen. Zweitens die Anwendungsseite: DNS-Zwischenspeicherung, fehlendes MultiSubnetFailover und Verbindungspools, die tote Verbindungen zu lange festhalten. Miss beide Anteile getrennt, sonst optimierst du an der falschen Stelle.

Synchron oder asynchron – was nehme ich, wenn ich es nicht genau weiß?

Dann nimm die gemischte Variante: zwei synchrone Replikate am selben Standort mit automatischem Failover, ein asynchrones Replikat im entfernten Rechenzentrum. Damit deckst du den Serverausfall ohne Datenverlust ab und den Standortausfall mit begrenztem Verlust. Bevor du synchron über eine WAN-Strecke schaltest, miss die Netzwerklaufzeit und rechne sie gegen deine Commit-Rate. Diese Rechnung ersetzt jede Faustregel.

Wie oft sollte ich ein Failover testen?

Geplantes Failover vierteljährlich, ungeplantes halbjährlich, den vollständigen Standortausfall einmal im Jahr. Zusätzlich nach jeder größeren Änderung: neues kumulatives Update, Änderungen am Netzwerk, neue Anwendung an der Availability Group. Wer seltener testet, testet im Ernstfall – und das ist die einzige Testumgebung, in der Fehler richtig teuer sind.

Muss ich für ein sekundäres Replikat eine SQL-Server-Lizenz kaufen?

Nur wenn es aktiv genutzt wird oder wenn keine Software Assurance läuft. Mit aktiver Software Assurance beziehungsweise einem Abonnement sind passive Replikate für Hochverfügbarkeit und Notfallwiederherstellung abgedeckt. Passiv heißt dabei wirklich passiv: keine Berichte, keine Leseabfragen über Read-Only-Routing, keine Anwendungslast. Läuft die Software Assurance aus, entfällt dieses Recht – und zwar sofort, nicht erst beim nächsten Neukauf.

Was ändert sich mit SQL Server 2025 an meiner HA-Planung?

Vier Dinge sind für die Praxis relevant. Vollständige und differenzielle Sicherungen sind jetzt auf jedem sekundären Replikat möglich, was die Auslagerung der Sicherungslast deutlich einfacher macht. Die Commit-Wartezeit der Availability Group lässt sich in Millisekunden einstellen, statt mit einem festen Wert zu leben. Mit RestartThreshold = 0 kannst du bei anhaltenden Gesundheitsproblemen sofortiges Failover erzwingen. Und die Standard Edition darf nun 32 Kerne und 256 GB Pufferpool nutzen – das verschiebt für viele Umgebungen die Grenze, ab der Enterprise nötig wird.

Reicht eine Availability Group, oder brauche ich zusätzlich eine Failover Cluster Instance?

In den meisten Fällen reicht die Availability Group, und sie ist die flexiblere Wahl, weil sie keinen gemeinsamen Speicher braucht. Eine Failover Cluster Instance ist dann sinnvoll, wenn du die gesamte Instanz schützen willst – inklusive Systemdatenbanken, Agent-Aufträgen und Anmeldungen – und ein verlässliches, geteiltes Speichersystem hast. Beide Verfahren lassen sich auch kombinieren: eine FCI als Replikat innerhalb einer Availability Group ist ein bewährter Aufbau für Umgebungen mit hohen Anforderungen.

Fazit

Hochverfügbarkeit scheitert selten an der Technik. Sie scheitert an den Kleinigkeiten drumherum: am fehlenden Witness, an einer DNS-Zwischenspeicherung von 20 Minuten, an Sicherungsaufträgen, die auf dem falschen Knoten liegen, an Anmeldungen, die es nur auf einem Server gibt. Jeder dieser Punkte ist für sich genommen banal. Zusammen ergeben sie den Unterschied zwischen einem Failover, das niemand bemerkt, und einem Freitagabend, den alle Beteiligten lange in Erinnerung behalten.

Die gute Nachricht: Alle acht Fehler sind prüfbar, und die meisten sind in wenigen Tagen behoben. Du brauchst dafür keine neue Architektur und kein Projekt mit Lenkungsausschuss. Du brauchst eine Stunde für die Bestandsaufnahme, ein Wartungsfenster für den ersten ehrlichen Failover-Test und die Bereitschaft, die gemessenen Zahlen gegen die zugesagten zu halten. Wenn beide auseinanderliegen, ist das kein Grund für schlechte Laune, sondern der Anfang einer belastbaren HA-Landschaft.

Und wenn du bei der Bestandsaufnahme lieber jemanden dabeihast, der die typischen Fallen schon ein paar Dutzend Mal gesehen hat: Genau dafür gibt es die SQL Server Beratung. Ein Blick von außen findet in aller Regel innerhalb eines Tages die zwei bis drei Punkte, an denen es im Ernstfall wirklich klemmen würde.