Wenn einer fragt: „Was ist mit Ausfall?“ – und keiner hat ’ne Antwort

SQL Server läuft.
Aber nur, wenn er läuft.
Kein Cluster. Kein Failover. Kein Notfallplan.

Dann reicht ein Stromausfall,
ein Patch,
eine versehentliche VM-Pause –
und das System steht.

Ich zeig Dir, wie ich Hochverfügbarkeit im SQL Server sauber aufziehe –
von pragmatisch bis anspruchsvoll.

Optionen für High Availability

Technik	Verfügbarkeit	Failover	Aufwand	Lizenzbedarf
Windows Failover Cluster	hoch	automatisch	hoch	Enterprise / Standard
Always On FCI	hoch	automatisch	hoch	WSFC + shared storage
Always On AG	sehr hoch	automatisch	hoch	Enterprise (voll), ab 2016 auch Basic AG
Log Shipping	mittel	manuell	mittel	auch mit Standard möglich
Database Mirroring	veraltet	automatisch	mittel	Standard bis 2016
Replikation	speziell	kein Failover	hoch	nur für bestimmte Use-Cases
Azure SQL / MI	sehr hoch	automatisch	gering	Cloud only

Beispiel: Always On Availability Group

Ab SQL Server 2016 geht’s auch mit Standard Edition (Basic AG).
Für bis zu 2 Knoten, 1 Datenbank.

Voraussetzungen

• Windows Server Failover Cluster (WSFC)
• Gleiche SQL Server-Version + Patchstand
• Gemeinsames Domänennetzwerk
• Listener (für automatische Verbindung)

Schritt 1: Cluster vorbereiten

# Windows PowerShell
New-Cluster -Name SQLCLUSTER01 -Node SQL01,SQL02 -StaticAddress 192.168.1.100

Dann SQL Server auf beiden Knoten installieren.
SQL Services als Clusterressource einrichten.

Schritt 2: Availability Group konfigurieren

Im SQL Server Management Studio (SSMS):

• Neue Availability Group anlegen
• Primäre Datenbank auswählen
• Backup/Restore auf Sekundärknoten automatisieren
• Listener konfigurieren (Name + Port)

Beispiel-T-SQL:

ALTER AVAILABILITY GROUP [AG_ERP]
ADD DATABASE [ERPDB];

Schritt 3: Verbindung über Listener

Die Clients (z. B. Access, Anwendungen) verbinden sich nicht mehr mit dem Servernamen,
sondern mit dem Listener:

Server=tcp:AGLISTENER01,1433;Database=ERPDB;Integrated Security=true;

Im Failoverfall übernimmt der zweite Knoten –
ohne dass Du oder der Client etwas tun müssen.

Monitoring per T-SQL

Status prüfen

SELECT ag.name AS AGName, 
       rs.role_desc AS Knotenrolle, 
       drs.synchronization_state_desc AS SyncStatus
FROM sys.availability_groups ag
JOIN sys.dm_hadr_availability_replica_states ars ON ag.group_id = ars.group_id
JOIN sys.dm_hadr_database_replica_states drs ON ag.group_id = drs.group_id
JOIN sys.dm_hadr_availability_replica_cluster_states rs ON ars.replica_id = rs.replica_id

Letztes Failover prüfen

SELECT * 
FROM sys.dm_hadr_cluster_events 
WHERE event_type_desc = 'FAILOVER_OCCURRED'
ORDER BY time_stamp DESC;

Tipp: Basic AG in der Standard Edition

Ab SQL Server 2016 SP1.
Eine Datenbank.
Kein Listener – aber failoverfähig.

CREATE AVAILABILITY GROUP [AG_Basic]
WITH (AUTOMATED_BACKUP_PREFERENCE = PRIMARY)
FOR DATABASE [MeineDatenbank]
REPLICA ON 
  'SQL01' WITH (
    ENDPOINT_URL = 'TCP://SQL01:5022',
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
    FAILOVER_MODE = AUTOMATIC),
  'SQL02' WITH (
    ENDPOINT_URL = 'TCP://SQL02:5022',
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
    FAILOVER_MODE = AUTOMATIC);

Client muss dann aktiv die aktuelle Rolle anfragen oder DNS nutzen.

Tabelle: Vergleich AG vs. FCI

Kriterium	Always On AG	Always On FCI
Speicher	getrennt pro Knoten	Shared Storage (SAN, S2D)
Failoverdauer	sehr kurz (Sekunden)	etwas länger
Wartbarkeit	einzelne DBs möglich	nur ganze Instanz
Patching	online möglich	Knotenweise (Rolling Patch)
Lizenzbedarf	AG = mind. Standard 2x	FCI = Standard 1x (aktive Instanz)
Komplexität	mittel bis hoch	hoch

Mein Setup bei KMU-Kunden

Firmengröße	Lösung
< 50 User	SQL Standard mit Log Shipping
50–150 User	SQL Standard mit Basic AG
> 150 User	SQL Enterprise mit Always On AG + Listener
Remote only	Azure SQL mit Geo-Replication

Ein SQL Server ohne Hochverfügbarkeit ist wie ein Segelboot ohne Ruder.

Läuft. Aber nur bis zum ersten Sturm.

Wenn’s kritisch ist – brauchst Du ein Konzept. Keins von Microsoft, sondern eins, das Du verstehst und pflegst.