SQL Server AlwaysOn Availability Groups mit PowerShell verwalten und automatisieren

8 spezialisierte PowerShell-Funktionen für alle Aspekte von SQL Server AlwaysOn Availability Groups – von Gesundheitsberichten und kontrolliertem Failover über AutoSeeding bis zur automatischen Reparatur ausgefallener Replikate.

8 Funktionen AlwaysOn AG SQL Server 2016–2022

AlwaysOn Availability Group – Funktionen im Überblick

Get-sqmAgHealthReport – AlwaysOn Availability Group Zustandsbericht automatisiert erstellen

Was macht die Funktion?

Erstellt einen detaillierten Zustandsbericht aller Availability Groups auf einer SQL Server Instanz. Der Bericht umfasst Synchronisierungsstatus, Redo-Queue-Größe, Replikat-Status und Latenzwerte aller sekundären Replikate. Die Ausgabe erfolgt strukturiert als PowerShell-Objekte, die direkt in HTML, CSV oder per Pipeline weiterverarbeitet werden können.

Wann nutzt man sie?

Im täglichen Monitoring-Betrieb als Basis für Alerting und Dashboards. Vor geplanten Wartungsfenstern zur Überprüfung ob alle Replikate synchron sind. Nach einem automatischen Failover um den neuen Zustand der AG zu dokumentieren und an das Change-Management zu melden.

Typische Probleme

  • Replikate zeigen SYNCHRONIZING statt SYNCHRONIZED – Redo-Queue läuft über
  • Latenz zwischen Primary und Secondary steigt unkontrolliert an
  • Fehlende Sichtbarkeit über den AG-Zustand ohne SQL Server Management Studio

Vorteile

  • Vollständiger AG-Zustand auf einen Blick – ohne GUI und ohne SSMS
  • Pipeline-fähig: direkte Integration in Monitoring- und Reporting-Workflows
  • Erkennt kritische Zustände (SUSPENDED, NOT SYNCHRONIZING) und kennzeichnet sie
# Einfacher Health-Report für eine Instanz
Get-sqmAgHealthReport -SqlInstance "SQL01"

# Detaillierter Bericht mit Latenz und Redo-Queue, Ausgabe als HTML
Get-sqmAgHealthReport -SqlInstance "SQL01" -Detailed | ConvertTo-Html | Out-File "AG-Report.html"

Invoke-sqmFailover – SQL Server AlwaysOn Failover PowerShell automatisieren mit Pre- und Post-Checks

Was macht die Funktion?

Führt einen kontrollierten Failover einer Availability Group durch. Vor dem Failover werden automatisch Pre-Checks ausgeführt: Redo-Queue-Größe, Sync-State aller Replikate und Datenverlustprüfung. Nach dem Failover erfolgen Post-Checks zur Verifikation des neuen Primary und zur Protokollierung im Audit-Log.

Wann nutzt man sie?

Bei geplanten Wartungsfenstern für Betriebssystem-Patching des Primary-Servers. Bei Hardwarearbeiten an einem Node mit anschließendem kontrollierten Rückschwenk. In automatisierten Disaster-Recovery-Tests um den Failover-Prozess regelmäßig zu üben.

Typische Probleme

  • Manueller Failover ohne vorherige Queue-Prüfung führt zu unerwartetem Datenverlust
  • Kein Nachweis im Audit-Log wer wann den Failover durchgeführt hat
  • Vergessene Post-Checks: neuer Primary ist nicht korrekt konfiguriert

Vorteile

  • Automatische Pre-Checks verhindern unkontrollierten Datenverlust
  • Lückenlose Protokollierung aller Failover-Aktionen für Compliance-Audit
  • WhatIf-Modus: Simulation des Failovers ohne tatsächliche Ausführung
# Kontrollierten Failover mit WhatIf simulieren
Invoke-sqmFailover -SqlInstance "SQL01" -AGName "AG_Production" -TargetReplica "SQL02" -WhatIf

# Tatsächlicher Failover mit Protokollierung
Invoke-sqmFailover -SqlInstance "SQL01" -AGName "AG_Production" -TargetReplica "SQL02" -Confirm

Invoke-sqmSqlAlwaysOnAutoseeding – AlwaysOn Automatic Seeding PowerShell aktivieren ohne manuelles Backup/Restore

Was macht die Funktion?

Aktiviert das Automatic Seeding Feature auf allen Replikaten einer Availability Group. Dabei werden die Seeding-Mode-Einstellungen sowohl auf der AG-Ebene als auch auf der Datenbankebene konfiguriert. Anschließend wird der Seeding-Fortschritt überwacht und im Log protokolliert.

Wann nutzt man sie?

Bei der initialen Einrichtung einer neuen Availability Group statt des umständlichen Backup-auf-Secondary-Restore-Verfahrens. Beim Hinzufügen neuer Replikate zu einer bestehenden AG. Als Alternative zum manuellen Seeding bei großen Datenbanken über schnelle Netzwerkverbindungen.

Typische Probleme

  • AutoSeeding schlägt fehl wenn die Datenbank-Verzeichnisse auf dem Secondary nicht existieren
  • Langsames Seeding bei unzureichender Netzwerkbandbreite ohne Fortschrittsanzeige
  • Fehlende Berechtigungen des SQL Server Service Accounts für Automatic Seeding

Vorteile

  • Kein manuelles Backup und Restore auf dem Secondary erforderlich
  • Integrierte Fortschrittsüberwachung und automatische Fehlerbehandlung
  • Spart Stunden bei der Einrichtung von AGs mit vielen oder großen Datenbanken
# Automatic Seeding auf allen Replikaten der AG aktivieren
Invoke-sqmSqlAlwaysOnAutoseeding -SqlInstance "SQL01" -AGName "AG_Production"

# Mit Fortschrittsüberwachung (wartet bis Seeding abgeschlossen)
Invoke-sqmSqlAlwaysOnAutoseeding -SqlInstance "SQL01" -AGName "AG_Production" -WaitForCompletion

Invoke-sqmAddDatabaseToAG – Datenbank per AutoSeed zur AlwaysOn AG hinzufügen mit Voraussetzungsprüfung

Was macht die Funktion?

Fügt eine oder mehrere Datenbanken per AutoSeed zu einer bestehenden Availability Group hinzu. Vor dem Hinzufügen werden Voraussetzungen geprüft: Recovery Model (muss FULL sein), vorhandene Full-Backups, Netzwerkverbindung zum Secondary und ausreichende Berechtigungen. Fehlgeschlagene Voraussetzungen werden klar protokolliert.

Wann nutzt man sie?

Wenn neue Datenbanken nach einem Applikationsrollout in die bestehende AG aufgenommen werden müssen. Bei der Migration von eigenständigen Datenbanken in eine AlwaysOn-Umgebung. Als Teil eines automatisierten Deployment-Prozesses für neue Mandanten in Multi-Tenant-Umgebungen.

Typische Probleme

  • Datenbank im SIMPLE Recovery Model – muss vor dem Hinzufügen auf FULL umgestellt werden
  • Kein Full-Backup vorhanden – AutoSeeding erfordert ein initiales Backup
  • Fehlende GRANT CREATE ANY DATABASE Berechtigung auf dem Secondary für AutoSeeding

Vorteile

  • Vollständige Voraussetzungsprüfung verhindert halbfertige AG-Zustände
  • Unterstützt mehrere Datenbanken gleichzeitig via Pipeline
  • Automatische Protokollierung des Seeding-Fortschritts und Abschluss-Verifikation
# Einzelne Datenbank zur AG hinzufügen
Invoke-sqmAddDatabaseToAG -SqlInstance "SQL01" -AGName "AG_Production" -Database "NeueDatenbank"

# Mehrere Datenbanken per Pipeline
@("DB1","DB2","DB3") | Invoke-sqmAddDatabaseToAG -SqlInstance "SQL01" -AGName "AG_Production"

Remove-sqmDatabaseFromAG – Datenbank sauber aus AlwaysOn Availability Group entfernen mit optionalem Cleanup

Was macht die Funktion?

Entfernt eine Datenbank sauber aus einer Availability Group. Dabei wird die Datenbank zuerst auf dem Primary aus der AG ausgetragen und optional auf allen Secondaries in den normalen Betrieb zurückversetzt (RECOVERY) oder vollständig entfernt (DROP). Alle Schritte werden mit Vorher/Nachher-Status protokolliert.

Wann nutzt man sie?

Bei der Stilllegung einer Applikation wenn die Datenbank aus der AG entfernt werden soll. Bei Performance-Problemen wenn einzelne Datenbanken temporär aus dem Synchronisierungsverbund herausgenommen werden. Bei der AG-Restrukturierung wenn Datenbanken zwischen verschiedenen AGs verschoben werden.

Typische Probleme

  • Datenbank auf Secondary bleibt im RESTORING-Zustand wenn kein sauberes Remove erfolgt
  • Vergessene Cleanup-Schritte führen zu verwaisten Datenbanken auf Secondaries
  • Fehlende Dokumentation welche Datenbanken wann und warum entfernt wurden

Vorteile

  • Sauberer Remove-Prozess ohne verwaiste RESTORING-Datenbanken
  • Optional: automatisches Cleanup auf allen Secondaries nach dem Austragen
  • Lückenlose Protokollierung für Compliance und Change-Management
# Datenbank aus AG entfernen, auf Secondaries in RECOVERY versetzen
Remove-sqmDatabaseFromAG -SqlInstance "SQL01" -AGName "AG_Production" -Database "AlteDatenbank" -RecoverSecondaries

# Datenbank entfernen und auf Secondaries komplett droppen
Remove-sqmDatabaseFromAG -SqlInstance "SQL01" -AGName "AG_Production" -Database "AlteDatenbank" -DropSecondaries

Repair-sqmAlwaysOnDatabases – AlwaysOn-Datenbanken im RECOVERY/RESTORING-Zustand automatisch reparieren

Was macht die Funktion?

Repariert AlwaysOn-Datenbanken die sich im Zustand RECOVERY PENDING, RESTORING oder NOT SYNCHRONIZING befinden. Der Reparaturprozess folgt dem Muster: Remove aus AG → Cleanup auf Secondary → AutoSeed-Neuaufnahme in AG. Alle Schritte laufen automatisch und werden detailliert protokolliert.

Wann nutzt man sie?

Nach einem ungeplanten Failover wenn Datenbanken auf dem alten Primary im RESTORING-Zustand verbleiben. Nach Netzwerkproblemen die zu korrupten Synchronisierungszuständen geführt haben. Als Teil eines automatisierten Recovery-Prozesses nach Clusterausfällen.

Typische Probleme

  • Datenbanken im RECOVERY PENDING blockieren den Neustart des SQL Server Dienstes
  • Manueller Remove/Re-Add Prozess ist fehleranfällig und zeitintensiv
  • Fehlende Automatisierung führt zu langen Ausfallzeiten außerhalb der Arbeitszeiten

Vorteile

  • Vollautomatische Reparatur ohne manuellen Eingriff möglich
  • Erkennt automatisch alle betroffenen Datenbanken auf einem Replikat
  • Reduziert MTTR (Mean Time To Recovery) bei AG-Ausfällen erheblich
# Alle Datenbanken im RESTORING-Zustand auf SQL02 reparieren
Repair-sqmAlwaysOnDatabases -SqlInstance "SQL02" -AGName "AG_Production"

# Nur spezifische Datenbank reparieren
Repair-sqmAlwaysOnDatabases -SqlInstance "SQL02" -AGName "AG_Production" -Database "ProblematischDB"

New-sqmAlwaysOnRepairJob – SQL Agent Job für automatische AlwaysOn AG-Reparatur bei Ausfall erstellen

Was macht die Funktion?

Erstellt einen SQL Server Agent Job der Repair-sqmAlwaysOnDatabases regelmäßig ausführt und so AG-Datenbanken automatisch repariert ohne manuellen Eingriff. Der Job prüft den Zustand der AG-Datenbanken und löst bei Bedarf den Reparaturprozess aus. Konfigurierbar mit Zeitplan, E-Mail-Alerting und Schwellenwert-Einstellungen.

Wann nutzt man sie?

In Umgebungen ohne 24/7-Rufbereitschaft um Nachtausfälle selbstheilend zu gestalten. Als Sicherheitsnetz nach geplanten Patchnächten wenn Replikate aus dem Synchronisierungsverbund fallen. In großen Umgebungen mit vielen AGs als automatischer Watchdog-Mechanismus.

Typische Probleme

  • Nachtausfälle werden erst am Morgen bemerkt – Recovery-Zeit ist unnötig lang
  • Manueller Eingriff außerhalb der Arbeitszeiten erfordert Rufbereitschaft
  • Kein automatisches E-Mail-Alerting wenn die Reparatur fehlschlägt

Vorteile

  • Selbstheilende AlwaysOn-Umgebung ohne 24/7-Rufbereitschaft
  • Konfigurierbares E-Mail-Alerting bei Start und Abschluss der Reparatur
  • Standardisierter Job-Name und -Zeitplan nach Unternehmensstandards
# AG-Reparatur-Job erstellen, läuft alle 15 Minuten
New-sqmAlwaysOnRepairJob -SqlInstance "SQL01" -AGName "AG_Production" -IntervalMinutes 15 -NotifyEmail "dba@firma.de"

Sync-sqmAgNode – SQL Server Logins, Jobs und Linked Server von Primary auf AG-Replikate synchronisieren

Was macht die Funktion?

Synchronisiert SQL Server-Objekte die nicht Teil der Availability Group sind – Logins (inkl. Passwort-Hash und SID), SQL Agent Jobs, Linked Server Definitionen und Server-Credentials – vom Primary-Replikat auf alle Secondaries. Unterstützt selektive Synchronisierung einzelner Objekt-Typen.

Wann nutzt man sie?

Nach dem Anlegen neuer Logins oder Änderung von Passwörtern auf dem Primary. Nach dem Erstellen neuer SQL Agent Jobs die auch im Failover-Fall funktionieren müssen. Als regelmäßiger Sync-Job um Drift zwischen Primary und Secondaries zu vermeiden.

Typische Probleme

  • Nach Failover können sich Applikationen nicht anmelden weil Logins fehlen
  • Orphaned Users (SID-Mismatch) entstehen wenn Logins manuell neu erstellt werden
  • SQL Agent Jobs laufen nach Failover nicht weil sie auf dem Secondary nicht existieren

Vorteile

  • Korrekte SID-Synchronisierung verhindert Orphaned-User-Probleme nach Failover
  • Granulare Steuerung: nur Logins, nur Jobs oder alle Objekte synchronisieren
  • Vollständige Protokollierung aller synchronisierten Objekte für den Audit
# Alle Objekte von Primary auf alle Secondaries synchronisieren
Sync-sqmAgNode -SourceInstance "SQL01" -AGName "AG_Production"

# Nur Logins synchronisieren (inkl. Passwort-Hash und Rollen)
Sync-sqmAgNode -SourceInstance "SQL01" -AGName "AG_Production" -SyncLogins -SyncLinkedServers
Zurück zum Index