SQL Server Performance analysieren und optimieren mit PowerShell - Wait Statistics, Blocking, Deadlocks

14 PowerShell-Funktionen fuer tiefgreifende SQL Server Performance-Analyse: von Wait Statistics und Deadlock-Reports ueber fehlende Indexes und Blocking bis zu Query Store, TempDB-Empfehlungen und Extended Events.

14 Funktionen DMV-basiert Query Store Extended Events

Performance-Analyse - Funktionen im Ueberblick

Get-sqmWaitStatistics - SQL Server Wait Statistics analysieren PowerShell: Top Waits mit Interpretation und Empfehlung

Was macht die Funktion?

Liest Wait Statistics aus sys.dm_os_wait_stats und gibt die Top-N Waits mit Kategorie (CPU, IO, Lock, Memory, Network), prozentualer Verteilung und konkreter Optimierungsempfehlung aus. Unterstuetzt Snapshot-Vergleich: zwei Messungen im Abstand von N Sekunden werden differenziert um aktuelle Waits statt kumulierte Werte zu zeigen.

Wann nutzt man sie?

Als erster Schritt jeder Performance-Analyse um den dominanten Engpass zu identifizieren. Waehrend eines Performance-Problems live um zu sehen welche Wait Types gerade aktiv sind. Als Baseline-Messung vor und nach Optimierungsmassnahmen um die Wirkung zu messen.

Typische Probleme

  • Kumulierte Wait Stats seit SQL Server Start zeigen historische nicht aktuelle Probleme
  • PAGEIOLATCH Waits werden als IO-Problem interpretiert obwohl Missing Indexes die Ursache sind
  • Benigne Wait Types (SLEEP_DBSTARTUP etc.) verfaelschen die Analyse ohne Filterung

Vorteile

  • Snapshot-Modus zeigt aktuelle Waits statt kumulierter Werte seit SQL Server Start
  • Automatische Filterung benigener Wait Types fuer klare Ergebnisse
  • Konkrete Optimierungsempfehlung pro Wait-Kategorie direkt in der Ausgabe
# Top 10 Waits mit Empfehlung (kumuliert seit Start)
Get-sqmWaitStatistics -SqlInstance "SQL01" -Top 10

# Snapshot: aktuelle Waits ueber 30 Sekunden messen
Get-sqmWaitStatistics -SqlInstance "SQL01" -SnapshotSeconds 30

Get-sqmPerfCounters - SQL Server Performance Counter PowerShell: PLE, Buffer Hit Rate, Batch Requests, Memory

Was macht die Funktion?

Liest die wichtigsten SQL Server Performance Counter aus sys.dm_os_performance_counters: Page Life Expectancy (PLE), Buffer Cache Hit Ratio, Batch Requests/sec, SQL Compilations/sec, Lock Waits/sec und Memory Grants Pending. Bewertet jeden Counter gegen Best-Practice-Schwellenwerte und kennzeichnet kritische Werte.

Wann nutzt man sie?

Fuer ein schnelles Gesundheits-Assessment einer Instanz ohne SQL Server Profiler oder Extended Events. Bei Beschwerden ueber langsame Performance zur Eingrenzung ob Memory, CPU oder IO der Engpass ist. Als taeglich automatisierter Check mit Alerting bei Unterschreitung von PLE-Schwellenwerten.

Typische Probleme

  • PLE unter 300 deutet auf Speicherdruck hin - wird oft erst bei Endkunden-Beschwerden bemerkt
  • Hohe SQL Recompilations/sec - unnoetige Compilationskosten durch fehlende Planstabilitaet
  • Memory Grants Pending groesser 0 - Queries warten auf Ausfuehrungsspeicher

Vorteile

  • Automatische Bewertung gegen Best-Practice-Schwellenwerte mit Ampelfarben
  • Alle relevanten Counter in einem Aufruf ohne mehrere DMV-Abfragen
  • Pipeline-faehig fuer Integration in Monitoring-Loesungen (SCOM, Zabbix)
# Alle wichtigen Performance Counter abrufen
Get-sqmPerfCounters -SqlInstance "SQL01"

# Nur Memory-Counter, Warnung wenn PLE unter Schwellenwert
Get-sqmPerfCounters -SqlInstance "SQL01" -Category "Memory" -WarnIfPLEBelow 500

Get-sqmConnectionStats - SQL Server aktive Verbindungen analysieren PowerShell: gruppiert nach Application, Login, Host

Was macht die Funktion?

Analysiert aktive Verbindungen aus sys.dm_exec_sessions und gruppiert diese nach Application, Login, Host-Name und Datenbank. Zeigt Anzahl der Sessions, durchschnittliche CPU und Memory-Nutzung sowie blockierende Sessions. Beachtet Connection-Pooling und unterscheidet echte User-Verbindungen von System-Sessions.

Wann nutzt man sie?

Wenn eine Instanz die max. Connection-Anzahl nahezu erreicht und die Ursache identifiziert werden muss. Bei Connection-Leaks um die fehlerhafte Applikation zu identifizieren. Zur Kapazitaetsplanung: welche Applikation benoetigt wie viele Verbindungen.

Typische Probleme

  • Connection-Leak durch Applikationen die Verbindungen nicht korrekt schliessen
  • Zu viele Verbindungen von einem einzelnen Host blockieren andere Applikationen
  • System-Sessions werden mit User-Sessions verwechselt - falsche Diagnose

Vorteile

  • Sofortige Identifikation von Connection-Leaks durch Applikations-Gruppierung
  • Zeigt blockierende Sessions direkt in der Ausgabe fuer schnelle Diagnose
  • Filterung von System-Sessions fuer fokussierte User-Connection-Analyse
# Alle aktiven Verbindungen gruppiert nach Applikation
Get-sqmConnectionStats -SqlInstance "SQL01"

# Nur User-Sessions, sortiert nach CPU-Verbrauch
Get-sqmConnectionStats -SqlInstance "SQL01" -ExcludeSystemSessions -SortBy "CPU"

Invoke-sqmPerfBaseline - SQL Server Performance Baseline erstellen und vergleichen PowerShell

Was macht die Funktion?

Erfasst (Capture), vergleicht (Compare) und listet (List) Performance-Baselines. Eine Baseline umfasst Wait Statistics, Performance Counter, Index-Fragmentierung und Connection Stats zu einem bestimmten Zeitpunkt. Der Vergleich zweier Baselines zeigt genau welche Kennzahlen sich veraendert haben.

Wann nutzt man sie?

Vor und nach Aenderungen an der Instanz-Konfiguration (Max Memory, MAXDOP etc.) um die Wirkung zu messen. Regelmaessig als Trend-Messung um Performance-Verschlechterungen fruehzeitig zu erkennen. Vor und nach Applikations-Releases um performance-relevante Regressionen zu identifizieren.

Typische Probleme

  • Keine Baseline vorhanden - Optimierungswirkung kann nicht objektiv gemessen werden
  • Subjektive Einschaetzung "es laeuft besser" statt messbarer Verbesserung
  • Performance-Trend wird erst bemerkt wenn Endkunden sich beschweren

Vorteile

  • Objektive Messung von Optimierungsmassnahmen durch Vorher/Nachher-Vergleich
  • Trend-Erkennung durch regelmaessige Baseline-Erfassung und automatischen Vergleich
  • Baselines werden mit Zeitstempel und Kommentar in OutputPath gespeichert
# Baseline vor Aenderung erfassen
Invoke-sqmPerfBaseline -SqlInstance "SQL01" -Action "Capture" -Comment "Vor MaxMemory-Aenderung"

# Aktuellen Stand mit letzter Baseline vergleichen
Invoke-sqmPerfBaseline -SqlInstance "SQL01" -Action "Compare"

Get-sqmIndexFragmentation - SQL Server Index-Fragmentierung analysieren PowerShell: REBUILD oder REORGANIZE Empfehlung

Was macht die Funktion?

Analysiert Index-Fragmentierung ueber sys.dm_db_index_physical_stats und gibt fuer jeden fragmentierten Index eine Empfehlung aus: REBUILD (Fragmentierung groesser 30%) oder REORGANIZE (Fragmentierung zwischen 5% und 30%). Optional direkte Ausfuehrung der empfohlenen Massnahmen moeglich.

Wann nutzt man sie?

Als Analyse-Schritt wenn IO-lastige Queries trotz korrekter Indexes langsam sind. Zur Kalibrierung der Ola Hallengren IndexOptimize-Parameter (Schwellenwerte fuer REBUILD vs. REORGANIZE). In Umgebungen ohne automatische Index-Wartung fuer manuelle, bedarfsgerechte Optimierung.

Typische Probleme

  • REBUILD auf kleinen Indexes unnoetig - Lock-Zeiten ohne Nutzen
  • Zu aggressive Fragmentierungs-Schwellenwerte fuehren zu uebermaessiger Index-Wartung
  • Online-REBUILD nicht verfuegbar in Standard Edition - kann zu Sperren fuehren

Vorteile

  • Automatische REBUILD/REORGANIZE-Empfehlung mit konfigurierbaren Schwellenwerten
  • Mindest-Seitenanzahl als Filter verhindert unnoetige Wartung kleiner Indexes
  • Direkte Ausfuehrung moeglich - kein separates Skript notwendig
# Fragmentierungsanalyse fuer alle User-Datenbanken
Get-sqmIndexFragmentation -SqlInstance "SQL01" -MinPageCount 100

# Analyse und direkte Ausfuehrung der Empfehlungen
Get-sqmIndexFragmentation -SqlInstance "SQL01" -Database "Produktion" -Execute

Get-sqmMissingIndexes - Fehlende SQL Server Indexes finden PowerShell: DMV-Empfehlungen nach Impact sortiert

Was macht die Funktion?

Liest fehlende Index-Empfehlungen aus den DMVs sys.dm_db_missing_index_details und sys.dm_db_missing_index_group_stats. Gibt fuer jeden empfohlenen Index den geschaetzten Impact (Seeks x Cost), die betroffene Tabelle, die empfohlenen Schluessel- und Include-Spalten sowie einen fertigen CREATE INDEX Befehl aus.

Wann nutzt man sie?

Wenn Queries mit Table Scans statt Seeks arbeiten und Index-Kandidaten gesucht werden. Als regelmaessige Auswertung um neue Applikations-Queries zu identifizieren die vom SQL Server als indexierbar erkannt wurden. Nach einem Applikations-Release wenn neue Query-Patterns den Index-Bedarf veraendern.

Typische Probleme

  • DMV-Empfehlungen unkritisch uebernehmen fuehrt zu Index-Ueberlastung (viele redundante Indexes)
  • Empfehlungen werden nach SQL Server Neustart zurueckgesetzt - Analyse muss timing-bewusst erfolgen
  • Doppelte Empfehlungen fuer aehnliche Queries werden nicht automatisch konsolidiert

Vorteile

  • Fertiger CREATE INDEX Befehl direkt in der Ausgabe - kein manuelles Skripten
  • Impact-Sortierung fokussiert auf die wirkungsvollsten Optimierungen zuerst
  • Duplikat-Erkennung verhindert Erstellung redundanter Indexes
# Top 20 fehlende Indexes nach Impact sortiert
Get-sqmMissingIndexes -SqlInstance "SQL01" -Top 20

# Nur Empfehlungen fuer eine spezifische Datenbank
Get-sqmMissingIndexes -SqlInstance "SQL01" -Database "Produktion" -MinImpact 100000

Get-sqmBlockingReport - SQL Server Blocking und Blockierungsketten PowerShell analysieren: Head Blocker identifizieren

Was macht die Funktion?

Ermittelt aktuelle Blockierungsketten aus sys.dm_exec_requests und sys.dm_exec_sessions. Zeigt den Head Blocker (die Session die alle anderen blockiert), alle blockierten Sessions, Wartezeit, Login, Applikation und den blockierenden sowie den blockierten Query-Text. Unterstuetzt automatisches Killing des Head Blockers.

Wann nutzt man sie?

Wenn Applikationen "haengen" und der Grund unbekannt ist. Bei regelmaessigen Blocking-Vorfaellen zur Identifikation des ursaechlichen Queries und der betroffenen Applikation. In automatisierten Monitoring-Scripts zur proaktiven Erkennung langer Blockierungsketten.

Typische Probleme

  • Blocking durch offene Transaktionen in Management-Tools (SSMS) ohne COMMIT
  • Einzelne lange Transaktion blockiert Hunderte von Sessions - Kaskadeneffekt
  • Blocking-Problem gelst sich vor Diagnose auf - keine Spurensicherung ohne Extended Events

Vorteile

  • Head-Blocker-Identifikation in komplexen Blockierungsketten sofort sichtbar
  • Query-Text beider Sessions (blockierend und blockiert) in einer Ansicht
  • Optionales automatisches Kill des Head Blockers mit vorheriger Bestaetigung
# Aktuelle Blockierungsketten anzeigen
Get-sqmBlockingReport -SqlInstance "SQL01"

# Nur Blockierungen laenger als 30 Sekunden, Head Blocker killen
Get-sqmBlockingReport -SqlInstance "SQL01" -MinWaitSeconds 30 -KillHeadBlocker

Get-sqmDeadlockReport - SQL Server Deadlock-Analyse PowerShell aus System Health Extended Event Session

Was macht die Funktion?

Liest Deadlock-Ereignisse aus der System Health Extended Event Session (immer aktiv seit SQL Server 2008 R2) und bereitet sie lesbar auf: beteiligte Sessions, Query-Texte, beteiligte Objekte und Deadlock-Opfer. Kein separates Trace-Setup notwendig - die Daten sind immer vorhanden.

Wann nutzt man sie?

Wenn Applikationen sporadisch Deadlock-Fehler melden und die Ursache identifiziert werden muss. Als postmortem-Analyse nach Deadlock-Vorfaellen ohne vorherige Trace-Konfiguration. Zur Priorisierung von Deadlock-Optimierungen nach Haeufigkeit und betroffenen Objekten.

Typische Probleme

  • Deadlock-Analyse erfordert normalerweise aktivierten Trace-Flag 1222 oder Extended Events
  • Deadlock-Informationen im Event Log sind schwer lesbar und schwer filterbar
  • Zyklische Deadlocks zwischen mehr als zwei Parteien sind ohne Visualisierung schwer nachzuvollziehen

Vorteile

  • Keine Vorab-Konfiguration notwendig - nutzt die immer vorhandene System Health Session
  • Strukturierte Ausgabe mit beteiligten Queries und Objekten fuer schnelle Analyse
  • Zeitbereich-Filter um nur Deadlocks der letzten N Stunden zu analysieren
# Alle Deadlocks der letzten 24 Stunden
Get-sqmDeadlockReport -SqlInstance "SQL01" -HoursBack 24

# Deadlocks fuer spezifische Datenbank, detaillierte Ausgabe
Get-sqmDeadlockReport -SqlInstance "SQL01" -Database "Produktion" -Detailed

Get-sqmLongRunningQueries - Lang laufende SQL Server Queries finden PowerShell mit Query-Text und Ausfuehrungsplan

Was macht die Funktion?

Ermittelt aktuell laufende Queries die einen konfigurierbaren Zeitsschwellenwert ueberschreiten. Zeigt Session-ID, Login, Applikation, Datenbank, Wartezeit, CPU, Reads und den vollstaendigen Query-Text. Optional kann der Ausfuehrungsplan (XML) fuer die Analyse direkt abgerufen werden.

Wann nutzt man sie?

Waehrend aktiver Performance-Probleme um sofort zu sehen welche Queries die Ressourcen binden. In automatisierten Monitoring-Scripts die bei Queries laenger als X Minuten eine Benachrichtigung senden. Als Grundlage fuer Query-Optimierungen wenn "das System langsam laeuft".

Typische Probleme

  • Lange laufende Batch-Jobs werden als Performance-Problem interpretiert - tatsaechlich erwartet
  • Query-Text ohne Ausfuehrungsplan reicht nicht aus fuer Optimierung
  • Problem-Query beendet sich bevor Diagnose gestartet wird

Vorteile

  • Schwellenwert-basierte Filterung konzentriert sich auf tatsaechliche Problemqueries
  • Ausfuehrungsplan-Download direkt integriert fuer sofortige Analyse
  • Whitelist fuer bekannte Batch-Jobs verhindert False-Positive-Alerts
# Alle Queries laenger als 60 Sekunden anzeigen
Get-sqmLongRunningQueries -SqlInstance "SQL01" -ThresholdSeconds 60

# Queries mit Ausfuehrungsplan, Ergebnis in Datei speichern
Get-sqmLongRunningQueries -SqlInstance "SQL01" -ThresholdSeconds 30 -IncludeExecutionPlan

Invoke-sqmExtendedEvents - SQL Server Extended Events PowerShell starten, stoppen und abfragen

Was macht die Funktion?

Steuert Extended Event Sessions: starten (Start), stoppen (Stop), abfragen (Query) und Ergebnisse auslesen. Unterstuetzt vordefinierte Session-Templates fuer gaengige Szenarien (Deadlocks, Blocking, Query-Analyse). Ergebnisse werden als strukturierte PowerShell-Objekte ausgegeben.

Wann nutzt man sie?

Wenn eine tiefgreifende Analyse benoetigt wird die ueber DMV-Abfragen hinausgeht. Fuer zeitlich begrenzte Spurensicherung bei intermittierenden Performance-Problemen. Als leichtgewichtige Alternative zu SQL Server Profiler fuer Produktionssysteme.

Typische Probleme

  • Extended Event Sessions die versehentlich nach der Diagnose aktiv bleiben und Overhead erzeugen
  • Grosse XEL-Dateien wenn Session ohne Groessenbeschraenkung laeuft
  • Komplexe XEvent-Konfiguration ohne Template-Unterstuetzung fehleranfaellig

Vorteile

  • Vordefinierte Templates fuer gaengige Analyse-Szenarien ohne manuelles Konfigurieren
  • Automatisches Stoppen nach konfigurierbarer Laufzeit verhindert unkontrollierten Overhead
  • Ergebnisse direkt als PowerShell-Objekte ohne XML-Parsing
# Vordefinierte Blocking-Session starten (laeuft 5 Minuten)
Invoke-sqmExtendedEvents -SqlInstance "SQL01" -Action "Start" -Template "Blocking" -DurationMinutes 5

# Ergebnisse der Session abfragen
Invoke-sqmExtendedEvents -SqlInstance "SQL01" -Action "Query" -SessionName "sqm_Blocking"

Invoke-sqmQueryStore - SQL Server Query Store Analyse PowerShell: regressierte Queries und Plan-Erzwingung

Was macht die Funktion?

Analysiert den Query Store: findet Top-Regressed-Queries (Queries deren Performance sich verschlechtert hat), vergleicht Ausfuehrungsplaene verschiedener Zeitraeume und unterstuetzt das Erzwingen (Force) eines bestimmten Plans. Alle Aktionen werden mit Zeitstempel protokolliert.

Wann nutzt man sie?

Nach SQL Server Upgrades oder Statistik-Updates wenn bekannte Queries ploetzlich langsamer werden. Zur gezielten Plan-Stabilisierung nach einer Plan-Regression ohne Parameter-Sniffing-Workarounds. Als regelmaessige Analyse um query-seitige Performance-Trends zu erkennen.

Typische Probleme

  • Plan-Regression nach Statistik-Update nicht sofort erkannt - Endkunden beschweren sich zuerst
  • Manuelles Erzwingen von Plaenen ohne Dokumentation - nach dem naechsten Update unbekannt
  • Query Store nicht aktiviert oder in Read-Only-Modus - keine Daten vorhanden

Vorteile

  • Schnelle Identifikation von Plan-Regressionen ohne aufwandige manuelle DMV-Abfragen
  • Plan-Erzwingung mit vollstaendiger Protokollierung und Wirkungsueberpruefung
  • Zeitbasierter Vergleich: Performance heute vs. gestern oder letzte Woche
# Top 10 regressierte Queries der letzten 24 Stunden
Invoke-sqmQueryStore -SqlInstance "SQL01" -Database "Produktion" -Action "TopRegressed" -HoursBack 24

# Plan fuer Query-ID 1234 erzwingen (Plan-ID 5678)
Invoke-sqmQueryStore -SqlInstance "SQL01" -Database "Produktion" -Action "ForcePlan" -QueryId 1234 -PlanId 5678

Get-sqmTempDbRecommendation - SQL Server TempDB Konfiguration analysieren PowerShell nach Best Practice

Was macht die Funktion?

Analysiert die TempDB-Konfiguration: Dateianzahl vs. CPU-Kern-Anzahl, Dateigroesse und Gleichmaessigkeit, AutoGrowth-Einstellungen und aktuelle Nutzung (Version Store, User Objects, Internal Objects). Gibt konkrete Empfehlungen gemaess Microsoft Best Practice aus.

Wann nutzt man sie?

Bei der Ersteinrichtung neuer SQL Server Instanzen um TempDB korrekt zu konfigurieren. Wenn PAGELATCH_EX Waits auf TempDB-Seiten (2:1:1 bis 2:1:3) auftreten - klassisches TempDB-Contention-Problem. Als Best-Practice-Check im Rahmen regelmaessiger Instanz-Reviews.

Typische Probleme

  • Nur eine TempDB-Datei auf Mehrkern-Systemen fuehrt zu PAGELATCH-Contention
  • Unterschiedliche Dateigroessen - TempDB nutzt nur groesste Datei zuerst (proportional fill)
  • TempDB auf System-Drive - bei Wachstum wird OS-Laufwerk voll

Vorteile

  • Konkrete Empfehlung fuer optimale Dateianzahl basierend auf CPU-Kern-Anzahl
  • Erkennt ungleichmaessige Dateigroessen und empfiehlt Korrektur
  • Zeigt aktuelle TempDB-Nutzung fuer Kapazitaetsplanung
# TempDB-Konfiguration analysieren und Empfehlungen ausgeben
Get-sqmTempDbRecommendation -SqlInstance "SQL01"

# Empfehlungen mit aktueller Nutzungsstatistik
Get-sqmTempDbRecommendation -SqlInstance "SQL01" -IncludeUsageStats

Get-sqmAutoGrowthReport - SQL Server AutoGrowth-Ereignisse analysieren PowerShell: Datenbanken mit Wachstumsproblemen

Was macht die Funktion?

Analysiert AutoGrowth-Ereignisse aus dem Standard-SQL-Server-Trace oder aus Extended Events. Zeigt fuer jede Datenbank wie haeufig AutoGrowth ausgeloest wurde, um wieviel gewachsen wurde und wie lange das Wachstum gedauert hat. Identifiziert Datenbanken mit problematischen AutoGrowth-Einstellungen (Prozent statt fester Groesse).

Wann nutzt man sie?

Wenn Queries sporadisch langsam werden - moegliche Ursache sind AutoGrowth-Ereignisse waehrend der Query-Ausfuehrung. Zur Kapazitaetsplanung um zu verstehen wie schnell Datenbanken wachsen. Bei der Konfigurationsreviews um Datenbanken mit Prozent-AutoGrowth auf feste Groessen umzustellen.

Typische Probleme

  • Prozent-AutoGrowth: bei grossen Datenbanken wachsen Dateien um Gigabytes - lange Wartezeiten
  • Haeufige kleine AutoGrowth-Ereignisse: Datei-Fragmentierung auf dem Storage
  • AutoGrowth auf vollem Laufwerk schlaegt fehl - Datenbank geht offline

Vorteile

  • Erkennt Prozent-AutoGrowth-Konfigurationen und empfiehlt feste Groessen
  • Zeigt Dauer der AutoGrowth-Ereignisse um Performance-Auswirkungen einzuschaetzen
  • Wachstumstrend-Analyse fuer vorausschauende Kapazitaetsplanung
# AutoGrowth-Ereignisse der letzten 30 Tage analysieren
Get-sqmAutoGrowthReport -SqlInstance "SQL01" -DaysBack 30

# Nur Datenbanken mit mehr als 5 AutoGrowth-Ereignissen
Get-sqmAutoGrowthReport -SqlInstance "SQL01" -MinGrowthEvents 5

Invoke-sqmUpdateStatistics - SQL Server Statistiken aktualisieren PowerShell: manuell oder mit Sampling-Rate

Was macht die Funktion?

Aktualisiert SQL Server Statistiken fuer alle oder ausgewaehlte Tabellen einer Datenbank. Unterstuetzt FULLSCAN fuer maximale Genauigkeit oder Sampling-Rate fuer schnellere Ausfuehrung bei grossen Tabellen. Optional koennen nur Statistiken aktualisiert werden die seit einer bestimmten Zeit nicht aktualisiert wurden.

Wann nutzt man sie?

Nach grossen Datenladeoperationen (ETL, Bulk Insert) wenn der Optimizer veraltete Statistiken hat. Bei Plan-Regressionen nach einem Cardinality Estimator Update als erster Loesungsansatz. In Datenbanken ohne automatische Statistik-Aktualisierung oder mit Trace-Flag 2371.

Typische Probleme

  • Veraltete Statistiken nach grossen ETL-Ladeoperationen fuehren zu schlechten Ausfuehrungsplaenen
  • FULLSCAN auf sehr grossen Tabellen zu Stosszeiten blockiert den Query-Optimizer
  • Statistik-Update loesst Planinvalidierung aus - kurze Performance-Verschlechterung durch Recompilation

Vorteile

  • Alter-basierter Filter aktualisiert nur wirklich veraltete Statistiken
  • Sampling-Rate-Konfiguration balanciert Genauigkeit und Ausfuehrungszeit
  • Protokoll aller aktualisierten Statistiken mit Zeitdauer fuer Nachvollziehbarkeit
# Alle Statistiken mit FULLSCAN aktualisieren
Invoke-sqmUpdateStatistics -SqlInstance "SQL01" -Database "Produktion" -FullScan

# Nur Statistiken aelter als 7 Tage, mit 50% Sampling
Invoke-sqmUpdateStatistics -SqlInstance "SQL01" -Database "Produktion" -SamplePercent 50 -OlderThanDays 7
Zurueck zum Index