SQL Server Datenbanken verwalten mit PowerShell - Health, Dokumentation und Recovery

7 PowerShell-Funktionen fuer das vollstaendige Datenbank-Management: Gesundheitszustand pruefen, HTML-Dokumentation erstellen, Objekte suchen, Linked-Server-Abhaengigkeiten analysieren und Transaktionslogs sauber verkleinern.

7 Funktionen Health & Dokumentation Recovery Model

Datenbank-Management - Funktionen im Ueberblick

Get-sqmDatabaseHealth - SQL Server Datenbank Health-Check PowerShell: Status, Recovery, AutoGrowth, letzte Sicherung

Was macht die Funktion?

Prueft den Gesundheitszustand aller Datenbanken einer Instanz: Status (Online/Offline/Suspect), Recovery Model, AutoGrowth-Konfiguration, Dateigroessen und freier Speicher, letzte erfolgreiche Sicherung und ob Datenbanken auf vorhandene Backups verweisen. Alle kritischen Zustaende werden farbig markiert.

Wann nutzt man sie?

Als morgendlicher Routine-Check um sicherzustellen dass alle Datenbanken Online sind und aktuelle Backups existieren. Nach Wartungsfenstern zur Verifikation dass alle Datenbanken wieder im gewuenschten Zustand sind. Als Basis-Assessment bei der Uebernahme einer fremden Instanz.

Typische Probleme

  • Datenbanken im SUSPECT-Status werden nicht sofort bemerkt
  • Fehlende Backups auf einzelnen Datenbanken fallen erst beim Notfall auf
  • AutoGrowth-Konfiguration (Prozent statt feste Groesse) auf Produktions-DBs unerkannt

Vorteile

  • Vollstaendiger Gesundheits-Ueberblick aller Datenbanken in einer Ausgabe
  • Backup-Status-Check direkt integriert - keine separate Backup-Abfrage noetig
  • Automatisierbar als taeglicher SQL Agent Job mit E-Mail-Report
# Gesundheitszustand aller Datenbanken pruefen
Get-sqmDatabaseHealth -SqlInstance "SQL01"

# Nur Datenbanken ohne aktuelles Backup (aelter als 24h)
Get-sqmDatabaseHealth -SqlInstance "SQL01" -BackupOlderThanHours 24

Export-sqmDatabaseDocumentation - SQL Server Datenbank als HTML und CSV dokumentieren PowerShell: Tabellen, Views, Stored Procedures

Was macht die Funktion?

Erstellt eine vollstaendige HTML- und CSV-Dokumentation einer Datenbank: alle Tabellen (mit Spalten, Datentypen, Constraints), Views, Stored Procedures, Functions, Groessen und Eigenschaften. Der HTML-Report ist navigierbar und geeignet fuer Change-Management-Dokumentation.

Wann nutzt man sie?

Vor Migrationen um den Ausgangszustand einer Datenbank vollstaendig zu dokumentieren. Fuer Applikations-Uebergaben an andere Teams mit vollstaendiger Datenbank-Struktur-Dokumentation. Als Basis fuer Compliance-Dokumentation und Datenschutz-Inventar (welche Tabellen enthalten welche Daten).

Typische Probleme

  • Datenbank-Dokumentation manuell im Wiki gepflegt - schnell veraltet und inkonsistent
  • Kein Ueberblick ueber alle Objekte in einer Datenbank vor einem Upgrade
  • Fehlende Dokumentation erschwert Support und Fehleranalyse durch Dritte

Vorteile

  • Vollstaendige Datenbank-Dokumentation auf Knopfdruck statt manuellem Aufwand
  • HTML-Report navigierbar mit Sprung zu Tabellen und Objekten
  • CSV-Export fuer Import in CMDB oder Datenschutz-Management-Systeme
# Datenbank-Dokumentation als HTML und CSV erstellen
Export-sqmDatabaseDocumentation -SqlInstance "SQL01" -Database "Produktion" -OutputPath "D:\Doku"

# Alle User-Datenbanken einer Instanz dokumentieren
Export-sqmDatabaseDocumentation -SqlInstance "SQL01" -AllDatabases -OutputPath "D:\Doku"

Find-sqmDatabaseObject - SQL Server Datenbankobjekte instanzweit suchen PowerShell: Tabellen, Views, Stored Procedures

Was macht die Funktion?

Sucht Datenbankobjekte (Tabellen, Views, Stored Procedures, Functions) nach Name oder Inhalt ueber alle oder ausgewaehlte Datenbanken einer Instanz. Unterstuetzt Wildcard-Suche und regulaere Ausdruecke. Die Suche nach Inhalt (Stored Procedure enthaelt bestimmten Text) ist besonders nuetzlich bei Refactoring.

Wann nutzt man sie?

Wenn bei einem Deployment eine gespeicherte Prozedur auf mehreren Datenbanken existiert und alle Vorkommen gefunden werden muessen. Bei der Suche nach Objekten die einen bestimmten Tabellennamen oder Server-Namen referenzieren. Als erstes Diagnosewerkzeug wenn eine Applikation einen bestimmten Objektnamen sucht.

Typische Probleme

  • Stored Procedures mit aehlichem Namen in verschiedenen Datenbanken - welche ist die richtige?
  • Hard-codierte Server-Namen in Stored Procedures werden bei Migration nicht gefunden
  • Suche ueber viele Datenbanken manuell mit SSMS sehr zeitaufwandig

Vorteile

  • Instanzweite Suche ueber alle Datenbanken in einem Befehl
  • Inhalt-Suche findet hard-codierte Referenzen in SP-Definitionen
  • Regex-Unterstuetzung fuer praezise Suchmuster
# Alle Stored Procedures suchen die "OldServer" enthalten
Find-sqmDatabaseObject -SqlInstance "SQL01" -SearchText "OldServer" -ObjectType "StoredProcedure"

# Alle Tabellen mit "Kunde" im Namen instanzweit suchen
Find-sqmDatabaseObject -SqlInstance "SQL01" -ObjectName "*Kunde*" -ObjectType "Table"

Get-sqmLinkedServerUsage - SQL Server Linked Server Abhaengigkeiten PowerShell pruefen vor Migration oder Deaktivierung

Was macht die Funktion?

Analysiert welche Datenbankobjekte (Stored Procedures, Views, Functions) einen bestimmten Linked Server referenzieren. Durchsucht die Objektdefinitionen aller Datenbanken und zeigt alle Abhaengigkeiten. Essentiell vor der Deaktivierung oder dem Umbenennen eines Linked Servers.

Wann nutzt man sie?

Vor der Deaktivierung eines Linked Servers zur Identifikation aller abhaengigen Objekte. Bei der Migration eines Quell-Servers der als Linked Server referenziert wird. Wenn ein Linked Server umbenannt werden muss und alle Referenzen angepasst werden muessen.

Typische Probleme

  • Linked Server deaktiviert ohne Kenntnis der Abhaengigkeiten - Applikation bricht zusammen
  • Hard-codierte Linked-Server-Namen in Stored Procedures schwer zu finden
  • Indirekte Referenzen durch Views die ihrerseits wieder aufgerufen werden

Vorteile

  • Vollstaendige Abhaengigkeitsanalyse vor jeder Linked-Server-Aenderung
  • Verhindert ungeplante Applikationsausfaelle durch unbekannte Abhaengigkeiten
  • Ausgabe mit Datenbankname, Objekt-Typ und vollstaendigem Objektnamen
# Alle Objekte die Linked Server "OLAP_SERVER" referenzieren
Get-sqmLinkedServerUsage -SqlInstance "SQL01" -LinkedServerName "OLAP_SERVER"

# Alle Linked Server und deren Abhaengigkeiten pruefen
Get-sqmLinkedServerUsage -SqlInstance "SQL01" -AllLinkedServers

Get-sqmOrphanedFiles - Verwaiste SQL Server MDF LDF NDF Dateien finden PowerShell: Dateisystem vs. sys.master_files

Was macht die Funktion?

Findet verwaiste Datenbankdateien (MDF, LDF, NDF) auf SQL Server Datenlaufwerken: Dateien die im Dateisystem vorhanden sind aber nicht in sys.master_files registriert sind. Diese Dateien belegen wertvollen Speicherplatz ohne genutzt zu werden. Zeigt Groesse, Erstellungsdatum und empfiehlt Loeschen nach Pruefung.

Wann nutzt man sie?

Wenn Datenlaufwerke unerwartet voll sind und unbekannte Dateien den Speicherplatz belegen. Nach dem Loeschen oder Verschieben von Datenbanken um sicherzustellen dass alle Dateien entfernt wurden. Bei der Kapazitaetsoptimierung von SQL Server Storage.

Typische Probleme

  • Nach DROP DATABASE bleiben physische Dateien oft auf dem Laufwerk zurueck
  • Restore-Reste: Dateien aus fehlgeschlagenen Restore-Versuchen belegen Platz
  • Test-Datenbanken auf Produktions-Storage vergessen und nie geloescht

Vorteile

  • Identifiziert verwaiste Dateien die manuell kaum zu finden waeren
  • Sicherheitscheck: Dateien werden nur aufgelistet, nicht automatisch geloescht
  • Zeigt potentiell rueckgewinnbaren Speicherplatz fuer Kapazitaetsplanung
# Verwaiste Datenbankdateien auf SQL01 finden
Get-sqmOrphanedFiles -SqlInstance "SQL01"

# Spezifischen Pfad auf verwaiste Dateien pruefen
Get-sqmOrphanedFiles -SqlInstance "SQL01" -ScanPath "D:\SQLData"

Invoke-sqmLogShrink - SQL Server Transaktionslog LDF verkleinern PowerShell sicher: Log-Backup zuerst, dann Shrink

Was macht die Funktion?

Verkleinert das Transaktionslog (LDF-Datei) einer Datenbank auf kontrollierte Weise: zuerst Log-Backup um aktive Transaktionen abzuschliessen, dann DBCC SHRINKFILE mit konfigurierbarer Zielgroesse. Prueft vorher ob die Datenbank im FULL Recovery Model ist und ob ein Log-Backup moeglich ist.

Wann nutzt man sie?

Wenn eine Logdatei durch einen einmaligen Massenladevorgang auf eine ungewoehnliche Groesse angewachsen ist. Nach der Umstellung vom FULL auf SIMPLE Recovery Model wenn das Log verkleinert werden soll. Wenn ein Laufwerk voll laeuft und die Logdatei der Hauptverursacher ist.

Typische Probleme

  • DBCC SHRINKFILE ohne vorheriges Log-Backup schrumpft das Log nicht (VLF noch aktiv)
  • Unkontrolliertes Shrinking und sofortiges Wiederwachstum - Fragment-Log-Kette
  • Log-Shrink auf SIMPLE-Datenbank bricht die Backup-Kette wenn Recovery-Modus unterschieden wird

Vorteile

  • Log-Backup vor Shrink stellt sicher dass VLFs inaktiv sind fuer effektives Shrinking
  • Validierung nach dem Shrink zeigt tatstaechlich erzielte Groesse
  • Schutz der Backup-Kette durch integrierten Log-Backup-Schritt
# Transaktionslog auf 500 MB verkleinern (mit vorherigem Log-Backup)
Invoke-sqmLogShrink -SqlInstance "SQL01" -Database "Produktion" -TargetSizeMB 500

# Log-Shrink ohne Backup (nur fuer SIMPLE Recovery oder nach manuellem Backup)
Invoke-sqmLogShrink -SqlInstance "SQL01" -Database "TestDB" -TargetSizeMB 100 -SkipLogBackup

Invoke-sqmSetDatabaseRecoveryMode - SQL Server Recovery-Modus PowerShell aendern: FULL, SIMPLE, BULK_LOGGED auf mehreren Datenbanken

Was macht die Funktion?

Aendert das Recovery Model (FULL / SIMPLE / BULK_LOGGED) auf einer oder mehreren Datenbanken gleichzeitig. Prueft vor der Aenderung ob ein Log-Backup benoetigt wird und erstellt es optional automatisch. Alle Aenderungen werden protokolliert. Unterstuetzt Whitelist fuer Ausnahmen.

Wann nutzt man sie?

Wenn Entwicklungs- oder Test-Datenbanken faelschlicherweise im FULL Recovery Model laufen und Log-Wachstum verursachen. Vor grossen Bulk-Ladeoperationen wenn temporaer auf BULK_LOGGED umgestellt werden soll. Bei der Standardisierung des Recovery Models in einer heterogenen Umgebung.

Typische Probleme

  • Umstellung auf SIMPLE bricht die Log-Backup-Kette - naechstes Differential-Backup moeglicherweise ungueltig
  • DEV-Datenbanken im FULL-Modus: Log waechst bis Laufwerk voll ohne Log-Backup-Job
  • Rueckstellen auf FULL nach BULK_LOGGED vergessen - Backup-Kette weiter unterbrochen

Vorteile

  • Massenbearbeitung: Recovery-Modus auf allen DEV-Datenbanken in einem Befehl
  • Automatisches Log-Backup vor der Umstellung schuetzt die Backup-Kette
  • Protokoll aller Aenderungen mit vorherigem und neuem Recovery Model
# Alle DEV-Datenbanken auf SIMPLE umstellen
Invoke-sqmSetDatabaseRecoveryMode -SqlInstance "SQL01" -Database "DevDB" -RecoveryMode "SIMPLE"

# Alle Datenbanken auf FULL umstellen, Ausnahmen per Whitelist
Invoke-sqmSetDatabaseRecoveryMode -SqlInstance "SQL01" -AllDatabases -RecoveryMode "FULL" -Exclude @("tempdb","model")
Zurueck zum Index