[{"content":"Intro psTerminalPerfCounter\nIm vorherigen Artikel habe ich einen kurzen Abriss in die Geschichte und Funktionsweise der Windows Performance Counter gemacht, jetzt folgt das Hands-on. Grundlage ist Release 0.4.1, das ganz im Zeichen von Visualisierung und Datenexport steht. Neu dabei: CSV-Export, eine Terminal GUI als Ablösung der textbasierten Ansicht und der HTML-Export via PSWriteHTML. Klingt spannend… ist es auch 🙂 Ich denke das siehst du genau so, sonst würdest du nicht mehr lesen. 🙂\nInstallation Installation eines PowerShell Moduls, nichts besonderes\n# Install psTerminalPerfcounter Install-Module psTerminalPerfCounter # List Cmdlets Get-Command -Module psTerminalPerfCounter # Install PSWriteHtml, required for HTML Export Install-Module PSWriteHtml Grundlegender Aufbau, Counterconfigs psTerminalPerfCounter arbeitet mit Konfigurationsdateien, in denen die Counter-Sets und deren Konfiguration beschrieben sind: Counter-IDs, Instanzen (ob zum Beispiel alle CPU-Cores oder nur Core 3 und 4 überwacht werden sollen), Wertkonvertierung, Units und die farbliche Kodierung der Graphen über die sogenannte ColorMap, die allerdings nur die Legacy-Visualisierung unterstützt.\nCounterconfigs können in beliebigen Pfaden gespeichert und von dort aufgerufen werden. Alternativ lassen sich Pfade registrieren, was den Aufruf einfach über denConfignamen ermöglicht. Der Default-Pfad ist der Config-Ordner im Modul selbst, der bereits einige vordefinierte Configs mitbringt.\n# List all registered paths Get-tpcConfigPaths # Add custom path Add-tpcConfigPath -Path \u0026#39;C:\\tpcConfig\u0026#39; # List all Counterconfigs and details in all paths Test-tpcAvailableCounterConfig Single Server Monitoring Die schnellste Methode ist ein einzelner Server, lokal oder remote.\n# Use CPU Config locally Start-tpcMonitor -Configname CPU Start-tpcMonitor -Confipath \u0026#39;C:\\Users\\labadmin\\Documents\\PowerShell\\Modules\\psterminalperfcounter\\0.4.0\\Config\\tpc_CPU.json\u0026#39; # Use CPU Config remote Start-tpcMonitor -Computername \u0026#39;dev-node1\u0026#39; -Configname CPU Start-tpcMonitor -Computername \u0026#39;dev-node1\u0026#39; -Confipath \u0026#39;C:\\Users\\labadmin\\Documents\\PowerShell\\Modules\\psterminalperfcounter\\0.4.0\\Config\\tpc_CPU.json\u0026#39; # Use CPU Config rmeote with different credentials Start-tpcMonitor -Computername \u0026#39;dev-node1\u0026#39; -Credentials $(Get-Credential) -Configname CPU Da die Legacy-Visualisierung spätestens bei Multiserver-Umgebungen an ihre Grenzen kommt, nutze ich für dieses Hands-on den -TUI Switch.\n# Use CPU Config locally with TUI Start-tpcMonitor -Configname CPU -TUI Multi Server Monitoring Das Multiserver-Monitoring funktioniert ebenfalls über Konfigurationsdateien, wobei mir beim Schreiben dieser Zeilen auffällt: Warum habe ich nie daran gedacht, einfach eine Counterconfig gegen eine Serverliste laufen zu lassen? Ab ins Backlog damit. Wie auch immer, in der Environment-Konfiguration lassen sich beliebig viele Server mit verschiedenen Configs definieren. Da ich zuletzt noch Probleme hatte, die Sparklines in der TUI scrollbar zu machen, sind diese in der Multiserver-Ansicht deaktiviert.\n# Start multi server monitoring Start-tpcEnvironmentMonitor -EnvConfigPath \u0026#39;C:\\tpcConfig\\ENV_SERVER_EXAMPLE.json\u0026#39; -TUI LAB-NODE03 ist in dem Fall ein deutsche Installation\nDie Spalte Duration zeigt die Zeit, die die Funktion auf dem jeweiligen Server gebraucht hat, um alle Werte einzusammeln. Den finalen Timestamp des gesamten Datensatzes definiert immer der langsamste Server, nur so ist eine homogene Zeitreihe möglich. Eine Varianz von in diesem Fall 1,3 Sekunden lässt sich dabei nicht vermeiden.\nDas wars auch schon zur Auführung, da dieses Modul nur das Framework bereitstellt. Das eigentliche Leben kommt mit den Counterconfigs. Wie diese erstellt werden schauen wir uns jetzt an.\nErstellung von Counterconfigs Am Anfang ist der Performance Counter. Bevor wir die Konfiguration schreiben können, brauchen wir die Counter-IDs statt der lokalisierten Namen. Dafür gibt es Get-tpcPerformanceCounterInfo, das in beide Richtungen funktioniert: Counterpath zu ID und umgekehrt.\n# List all counter and counter objects containing \u0026#39;processor time\u0026#39; Get-tpcPerformanceCounterInfo -ComputerName \u0026#39;dev-node1\u0026#39; -SearchTerm \u0026#39;processor time\u0026#39; Wichtig sind die letzten beiden Spalten. Es gibt Single-Instance-Counter mit nur einem Wert, aber auch Multi-Instance-Counter wie das Processor-Counterset, bei dem jede Instanz einem Core entspricht, oder halt gesamt (_Total).\nGenauso lässt sich mit dem Cmdlet herausfinden, welcher Counter sich hinter einer Composite-ID verbirgt.\n# Show counter name of composite ID Get-tpcPerformanceCounterInfo -ComputerName \u0026#39;dev-node1\u0026#39; -SearchTerm \u0026#39;238-6\u0026#39; Oder auf einem deutschen System\nNehmen wir noch Counter, die nicht standardmäßig auf einem Windows-System vorhanden sind: SQL Server. DEV22A ist in diesem Fall die erste Instanz auf dem System.\n# \u0026#34;Out-String -Stream\u0026#34; converts PowerShell\u0026#39;s internal formatting objects into actual strings line by # line, enabling string operations like `Select-String` to work on them. Get-tpcPerformanceCounterInfo -ComputerName \u0026#39;dev-node1\u0026#39; -SearchTerm \u0026#39;dev22a\u0026#39; | Out-String -Stream | Select-String \u0026#34;lookup\u0026#34; Nehmen wir zum Testen Page lookups/sec –\u0026gt; 12222-12272\nGet-tpcPerformanceCounterInfo -ComputerName \u0026#39;dev-node1\u0026#39; -SearchTerm \u0026#39;dev22a\u0026#39; | Out-String -Stream | Select-String \u0026#34;log flushes\u0026#34; Und log flush/sec auf der Instanz TempDB –\u0026gt; 12352-12446\nDie minimale Config sieht dann so aus. Bei den SQL-Server-Countern fehlen einige Werte, das ist aber nicht SQL-Server-spezifisch, sondern zeigt, dass die meisten Felder Defaults bekommen. Details dazu finden sich in der Doku im Repo. Erwähnenswert noch: bei CPU nutze ich \u0026quot;counterInstance\u0026quot;: \u0026quot;1|2\u0026quot;, wodurch automatisch zwei Counter erstellt werden, und bei den Page Lookups die Konvertierung durch 1000, damit die Zahlen lesbar bleiben.\\\n{ \u0026#34;name\u0026#34;: \u0026#34;CPU and Sql Server Page Usage\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;CPU Usage\u0026#34;, \u0026#34;counters\u0026#34;: [ { \u0026#34;title\u0026#34;: \u0026#34;CPU Usage\u0026#34;, \u0026#34;unit\u0026#34;: \u0026#34;%\u0026#34;, \u0026#34;conversionFactor\u0026#34;: 1, \u0026#34;conversionExponent\u0026#34;: 1, \u0026#34;conversionType\u0026#34;: \u0026#34;D\u0026#34;, \u0026#34;format\u0026#34;: \u0026#34;table\u0026#34;, \u0026#34;counterID\u0026#34;: \u0026#34;238-6\u0026#34;, \u0026#34;counterSetType\u0026#34;: \u0026#34;MultiInstance\u0026#34;, \u0026#34;counterInstance\u0026#34;: \u0026#34;0|1\u0026#34;, \u0026#34;colorMap\u0026#34;: { \u0026#34;20\u0026#34;: \u0026#34;Green\u0026#34;, \u0026#34;50\u0026#34;: \u0026#34;Yellow\u0026#34;, \u0026#34;70\u0026#34;: \u0026#34;RED\u0026#34; } }, { \u0026#34;title\u0026#34;: \u0026#34;Sql DEV22A Page Lookups/s\u0026#34;, \u0026#34;unit\u0026#34;: \u0026#34;#K\u0026#34;, \u0026#34;conversionFactor\u0026#34;: 1000, \u0026#34;conversionExponent\u0026#34;: 1, \u0026#34;conversionType\u0026#34;: \u0026#34;D\u0026#34;, \u0026#34;counterID\u0026#34;: \u0026#34;12222-12272\u0026#34;, \u0026#34;counterSetType\u0026#34;: \u0026#34;SingleInstance\u0026#34;, \u0026#34;counterInstance\u0026#34;: \u0026#34;\u0026#34; }, { \u0026#34;title\u0026#34;: \u0026#34;Sql DEV22A TempDB Log Flushes/s\u0026#34;, \u0026#34;unit\u0026#34;: \u0026#34;#\u0026#34;, \u0026#34;counterID\u0026#34;: \u0026#34;12352-12446\u0026#34;, \u0026#34;counterSetType\u0026#34;: \u0026#34;MultiInstance\u0026#34;, \u0026#34;counterInstance\u0026#34;: \u0026#34;tempdb\u0026#34; } ] } Das Ganze dann in einem registrierten Pfad speichern mit dem Präfix tpc_NAME.json und los geht’s.\nMonitoring einer Umgebung mit Environment File Auch hier keine Magic. Es können Confignamen oder Pfade angegeben werden. Eine noch nicht vollständig dokumentierte Funktion ist die Nutzung von SecretVaults: Über die PowerShell-Konnektoren lassen sich Credentials aus fast allen gängigen Lösungen laden, womit auch Nicht-Admins die Möglichkeit gegeben werden kann, Systeme zu überwachen.\n[ { \u0026#34;name\u0026#34;: \u0026#34;SQL_ENVIRONMENT_001\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;SQL Server Environment Production\u0026#34;, \u0026#34;interval\u0026#34;: 2, \u0026#34;secretvaultname\u0026#34;: \u0026#34;SecretStore\u0026#34;, \u0026#34;credentialname\u0026#34;: \u0026#34;integrated\u0026#34;, \u0026#34;servers\u0026#34;: [ { \u0026#34;computername\u0026#34;: \u0026#34;DEV-NODE1\u0026#34;, \u0026#34;comment\u0026#34;: \u0026#34;Sql Server Node A Production\u0026#34;, \u0026#34;counterConfig\u0026#34;: [ \u0026#34;SQLDEMO\u0026#34; ] }, { \u0026#34;computername\u0026#34;: \u0026#34;DEV-NODE2\u0026#34;, \u0026#34;comment\u0026#34;: \u0026#34;Sql Server Node B Production\u0026#34;, \u0026#34;counterConfig\u0026#34;: [ \u0026#34;C:\\Users\\devadmin\\Desktop\\tpc_SQLDEMO.json\u0026#34; ] } ] } ] # without TUI Start-tpcEnvironmentMonitor -EnvConfigPath \u0026#34;C:\\Users\\devadmin\\Desktop\\ENV_SERVER_EXAMPLE2.json\u0026#34; Datenexport CSV Um die Zeitreihen weiterzuverwenden, kann nach CSV exportiert werden. Achtung, aktuell noch ein bekannter Bug: der Export ist kommasepariert, Werte mit Komma werden dadurch ebenfalls getrennt, in 0.4.1 gefixt.\n# -CsvPath is default desktop Start-tpcEnvironmentMonitor -EnvConfigPath \u0026#34;C:\\Users\\devadmin\\Desktop\\ENV_SERVER_EXAMPLE2.json\u0026#34; -ExportCsv HTML Report Eine alternative Visualisierung als HTML, nützlich wenn ich eine Zeitreihe weitergeben möchte ohne Excel oder weitere Tools zu bemühen. Gruppiert werden kann nach Counter oder nach Server, je nachdem ob ich bei mehreren Servern alle Counter eines Servers in einem Diagramm sehen möchte, oder einen bestimmten Counter über mehrere Server hinweg. Details dazu finden sich in den Docs im Repo.\nZu beachten: das HTML enthält ein rollendes Datenset, das an die maximale Sample-Anzahl gebunden ist. Je mehr Samples, desto träger wird das HTML. Für große Zeitreihen lieber CSV nutzen.\n# -HTMLPath is default desktop Start-tpcEnvironmentMonitor -EnvConfigPath \u0026#34;C:\\Users\\devadmin\\Desktop\\ENV_SERVER_EXAMPLE2.json\u0026#34; -ExportHTML Das war’s als Schnelleinstieg, mehr Details zu den einzelnen Funktionen finden sich wie immer in den Docs und der READMEim Repository.\n","permalink":"https://dbavonnebenan.de/psterminalperfcounter-counter-in-terminal-handson/","summary":"Hands-on zu psTerminalPerfCounter: Windows Performance Counter im Terminal überwachen, inklusive TUI, Multiserver-Monitoring sowie CSV- und HTML-Export.","title":"psTerminalPerfCounter – Performance Counter im Terminal – HowTo"},{"content":"Intro psTerminalPerfCounter\nKnapp ein Jahr ist es nun her, dass ich mit der Entwicklung von psTerminalPerfCounter begann. Stolz auf die „grafische“ Implementierung, Sprachunabhängigkeit mittels 3rd-Party-Lib und den damaligen heiligen Gral: Klassen in PowerShell.\nNichts davon ist geblieben:\nGrafische Implementierung? Schön bunt aber… Bei Multiserver Umgebungen träge wie ein Stein Dynamisch und Skalierbar, Fehlanzeige Neuimplementierung in TUI (BETA) Multilanguage per 3rd Party Lib Geht alles direkt per Windows Registry, durch Zufall darüber gestolpert Klassen in PowerShell? Sehr schlechte Entscheidung. Nicht praktikabel, Instanzen nicht ohne weiteres serialisierbar, Methoden gehen verloren, Parallel Remoting mit Runspaces kaum umsetzbar Rebuild in C# Mit dem aktuellen Release 0.4.1 sind erst mal alle Funktionen implementiert, welche ich im Backlog hatte. Da mir die nächsten Monate dazu die Zeit für dieses Projekt fehlen wird, ist dies ein guter Moment ein HandsOn zu schreiben, da die README.md im Repo doch manchmal herausfordernd ist… wie es scheint 🙂 Bevor es zum HandsOn geht, aber erst mal ein wenig zur Technik und Geschichte der Performance Counter.\nGeschichte Windows Performance Counter gibt es in Windows seit NT 3.1 (1993), da hatte ich noch nicht mal einen Computer. Microsoft brauchte damals eine standardisierte Methode, um Systemzustände anzeigbar zu machen, ohne dass jede Anwendung eigene Monitoring-Mechanismen implementieren musste. Das hieẞ aber auch Messwerte aus der Registry kratzen und Deltas berechnen.\nMit Windows 2000 kam der Performance Data Helper (PDH) als komfortable High-Level-API dazu, die den Zugriff auf Performance Counter so gestaltet, wie wir ihn heute kennen. Gleichzeitig wurde WMI eingeführt, das Performance-Daten über eine objektorientierte Schnittstelle zugänglich machte. CIM war ja nicht proprietär und zu kompatibel 😛\nWindows Vista brachte das überarbeitete Provider V2-Modell: Statt einer DLL, die vom System in einen fremden Prozess geladen wurde (fehleranfällig, Absturz des Providers = Absturz des abfragenden Prozesses), registrieren sich Provider seitdem als eigenständige ausführbare Dateien oder Dienste. Das ist das heute noch gültige Modell.\nAufbau und Funktion Metadaten in der Registry Alle bekannten Counter sind unter HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Perflib registriert. Dort liegen Name, Beschreibung und eine numerische Index-Nummer pro Counter, getrennt nach Sprache (Unterkey 009 für Englisch, 007 für Deutsch usw.).\n# List available language packs (counter IDs) Get-ChildItem \u0026#34;HKLM:\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Perflib\u0026#34; Provider liefern die Rohdaten Jede Komponente (Kernel, Treiber, Dienste wie IIS oder SQL Server, die .NET-Runtime) kann eigene Counter registrieren. Der Provider wartet passiv und liefert Daten erst dann, wenn sie jemand abfragt. Es gibt keinen dauerhaften Sammeldienst im Hintergrund.\n# List all services that have a Performance subkey Get-ChildItem \u0026#34;HKLM:\\SYSTEM\\CurrentControlSet\\Services\u0026#34; | Where-Object { Test-Path \u0026#34;$($_.PSPath)\\Performance\u0026#34; } | ForEach-Object { $perf = Get-ItemProperty \u0026#34;$($_.PSPath)\\Performance\u0026#34; [PSCustomObject]@{ Service = $_.PSChildName FirstCounter = $perf.\u0026#39;First Counter\u0026#39; LastCounter = $perf.\u0026#39;Last Counter\u0026#39; Library = $perf.Library } } | Format-Table -AutoSize APIs für Anwendungen (CONSUMER) PDH (Performance Data Helper): Die bequeme API, die Werte bereits formatiert (z. B. Prozentwerte berechnet, Intervalle berücksichtigt). Get-Counter in PowerShell nutzt PDH. PerfLib / Registry direkt: Schneller, aber roh. WMI nutzt diesen Weg intern. Aufbau\n\\Prozessor(_Total)\\Prozessorzeit (%)\n└─ Objekt: „Prozessor“\n└─ Instanz: „_Total“ (Summe aller Kerne)\n└─ Counter: „Prozessorzeit (%)“\nMicrosofts Tools Der Großvater PerfMon Der Performance Monitor ist seit NT-Zeiten das offizielle Werkzeug von Microsoft und für das, wofür er gebaut wurde, nach wie vor ausgezeichnet: interaktive, grafische Tiefenanalyse einzelner Systeme, mit Aufzeichnung über Data Collector Sets, CSV-Export via relog und grundlegendem Remoting. Die Grenzen zeigen sich, sobald man skalieren, automatisieren oder schlicht im Terminal arbeiten will. Portable Konfigurationsdateien, mehrere Server gleichzeitig im Blick oder ein strukturierter Konsolenworkflow sind nicht seine Stärken.\nDer NewComer Windows Admin Center Microsofts browserbasierte Verwaltungsoberfläche bringt ebenfalls eine Performance-Ansicht mit, übersichtlicher als Perfmon und ohne lokale Installation auf dem verwalteten System. Für einen schnellen Blick auf CPU, Speicher und Netzwerk reicht das völlig aus. Zwei Punkte schränken den praktischen Nutzen jedoch ein: Erstens setzt WAC eine zentrale Installation voraus, mal eben auf einem Client oder beim Kunden starten geht nicht. Zweitens basiert die Counter-Auswahl wie überall auf der lokalisierten PDH-API, was Workspaces nicht wirklich transportabel macht.\nDas Evergreen – Get-Counter Get-Counter ist das PowerShell-Äquivalent für den Konsolenbetrieb und damit das flexibelste der drei Werkzeuge, solange man frickeln möchte bereit ist, selbst Hand anzulegen. Counter lassen sich direkt abfragen, per Schleife wiederholen und in die Pipeline schicken. Remoting funktioniert über den -ComputerName-Parameter. Das Problem ist dasselbe wie überall: Die Counter-Pfade sind sprachabhängig, ein auf einem deutschen System geschriebenes Skript schlägt auf einem englischen fehl. Hinzu kommt, dass Get-Counter Rohdaten liefert. Formatierung, Schwellenwerte, Verlaufsdarstellung und strukturierte Ausgabe sind vollständig Handarbeit. Für Einmalabfragen und schnelle Checks ist es ideal, für reproduzierbare, mehrsprachige Umgebungen stößt es schnell an seine Grenzen.\n# Query CPU, memory and disk counters every 5 seconds, format output as table $counters = @( \u0026#39;\\Processor(_Total)\\% Processor Time\u0026#39;, \u0026#39;\\Memory\\Available MBytes\u0026#39;, \u0026#39;\\PhysicalDisk(_Total)\\Disk Bytes/sec\u0026#39; ) # German Counternames # $counters = @( #\t\u0026#39;\\Processor(_Total)\\% Processor Time\u0026#39;, #\t\u0026#39;\\Memory\\Available MBytes\u0026#39;, #\t\u0026#39;\\PhysicalDisk(_Total)\\Disk Bytes/sec\u0026#39; # ) Get-Counter -Counter $counters -SampleInterval 5 -Continuous | ForEach-Object { $sample = $_.CounterSamples [PSCustomObject]@{ Timestamp = $_.Timestamp \u0026#39;CPU %\u0026#39; = [math]::Round(($sample | Where-Object Path -like \u0026#39;*processor*\u0026#39;).CookedValue, 1) \u0026#39;RAM frei (MB)\u0026#39; = [math]::Round(($sample | Where-Object Path -like \u0026#39;*available*\u0026#39;).CookedValue, 0) \u0026#39;Disk B/s\u0026#39; = [math]::Round(($sample | Where-Object Path -like \u0026#39;*disk bytes*\u0026#39;).CookedValue, 0) } | Format-Table -AutoSize } Der Weg in die Sprachunabhängigkeit Wie ihr seht, ist die Sprachabhängigkeit bei allen Implementierungen ein großes Problem. Dabei ist das gar nicht nötig. Unter der Haube hat jedes Counterobjekt und jeder Counter eine eindeutige ID. Schaut mal oben in den Screenshots, da steht immer First und Last Counter. Somit wird aus \\Processor(_Total)\\Processor Time (%) –\u0026gt; \\238(_Total)\\6 .\n# Read counter ID/name mapping from registry (English - key 009, German - key 007) Get-ItemProperty -Path \u0026#39;HKLM:\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Perflib\\009\u0026#39; -Name Counter | Select-Object -ExpandProperty Counter | Select-Object -First 20 That’s it. Nun müssen einmal das Counter-Objekt und der Pfad übersetzt werden und schon habe ich meinen sprachunabhängigen CounterPfad. Vor dem Ausführen wird er auf dem Zielsystem übersetzt und dann Get-Counter -Counter \u0026lt;TRANSLATION\u0026gt; ausgeführt. Das übernimmt in psTerminalPerfcounter das CMDLET get-tpcPerformanceCounterInfo\npsTerminalPerfCounter – Performance Counter im Terminal – HowTo\n","permalink":"https://dbavonnebenan.de/windows-performance-counters-how-the-os-monitors-itself/","summary":"Performance Counter sind seit Windows NT 3.1 ein fester Bestandteil des Betriebssystems. In diesem Artikel erkläre ich kurz, wie das System intern funktioniert, warum Counter-Namen sprachabhängig sind und wie mein PowerShell Modul psTerminalPerfCounter genau dieses Problem löst.","title":"Windows Performance Counter: Wie sich das OS selbst überwacht"},{"content":"GitHub – gabrielkoehl/DBAScriptBox: Useful stuff for DBAs\nIntro Wer kennt es nicht? Bevor man überhaupt mit der Installation von SQL Server loslegen kann, hat man sich entweder repetitiv durch seitenweise schlechte GUIs geklickt oder wenn verfügbar, mit einer losen Sammlung an Scripten jongliert und semiautomatisch alle Abhängigkeiten und Best Practices eingerichtet.\nNoch schlimmer ist der Fall, wenn man als Berater gar keinen Domain Admin hat (was auch so sein sollte) und man den Kunden, der dies vielleicht noch nie gemacht hat, per Teams \u0026amp; Co anleiten muss. Wenn dies nicht eh eine geplante Installation mit Know-how-Transfer ist, erzeugt so etwas Schmerz. 🤭\nDementsprechend habe ich nun mal all meine losen Scripte zusammengewürfelt und für jeden Themenbereich eine recht umfangreiche Funktion entwickelt, welche all diese Tasks automatisiert und für Archivzwecke loggt. Danke auch an Claude für die Unterstützung. Keiner kontrolliert und dokumentiert Code besser als Claude. 😋\nNun könnte man sich fragen: Es gibt doch dbatools und DSC? Klar, nutze ich auch gerne. Aber transparente, nachvollziehbare Scripts ohne Framework-Overhead vermitteln Wissen besser – gerade wenn angehenden DBAs der Blick fürs Ganze fehlt. Betrieb von SQL Server fängt auf dem Blech an, geht über Storage, Windows Server, Active Directory und hört bei einer Certificate Authority auf. Und bei KRITIS-Unternehmen oder kleinen Mittelständlern mit 3 Clustern will ich zu Beginn keine Grundsatzdiskussion über dbatools oder DSC führen.\nLos geht’s mit einem Production-Ready Windows Server Failover Cluster – inklusive CNO/VCO-Berechtigungen, DNS-Registrierung und Quorum-Konfiguration. Alles wiederholbar, alles geloggt, alles nachvollziehbar.\nDas Lab Szenario Um die Schritte greifbar zu machen, wird folgende Umgebung und Naming-Conventions genutzt\nNodes LAB-NODE01 (192.168.100.12) LAB-NODE02 (192.168.100.13) Cluster Name MSSQL-CL-01 (192.168.100.14) SQL Instanz LAB22A Domain lab.local Service Accounts Group Managed Service Accounts (gMSA) g-LAB22A-oltp g-LAB22A-agnt Windows Server Failover Cluster Deployment ⚒️ cluster_manageSQLCluster.ps1\n📓 cluster_manageSQLCluster.md\nDer WSFC bildet das Fundament für AlwaysOn Availability Groups. Das Script steuert den gesamten Lifecycle von der Feature-Installation bis zur Witness-Konfiguration.\nFeature Installation \u0026amp; Cluster Erstellung Zunächst wird das Feature Failover-Clustering auf den einzelnen Nodes installiert und der Cluster erstellt. Ein wichtiger Aspekt bei der Automatisierung ist das Cluster-Objekt (CNO): Es benötigt Schreibrechte im DNS und Active Directory um später automatisiert Listener-Records anlegen zu können.\n.\\cluster_manageSQLCluster.ps1 ` -Operation InstallFeature ` -Nodes \u0026#34;LAB-NODE01\u0026#34;,\u0026#34;LAB-NODE02\u0026#34; ` -LogPath \u0026#34;C:\\Temp\\Cluster_Feature_$(Get-Date -Format \u0026#39;yyyyMMdd_HHmmss\u0026#39;).log\u0026#34; Anschließend wird der Cluster erstellt. Das Script setzt zusätzlich die entsprechenden Berechtigungen in AD und DNS.\n.\\cluster_manageSQLCluster.ps1 ` -Operation CreateCluster ` -ClusterName \u0026#34;MSSQL-CL-01\u0026#34; ` -Nodes \u0026#34;LAB-NODE01\u0026#34;,\u0026#34;LAB-NODE02\u0026#34; ` -StaticIP \u0026#34;192.168.100.14\u0026#34; ` -DnsDomain \u0026#34;lab.local\u0026#34; ` -TargetOU \u0026#34;OU=lab_computer,DC=lab,DC=local\u0026#34; ` -LogPath \u0026#34;C:\\Temp\\Cluster_Create_$(Get-Date -Format \u0026#39;yyyyMMdd_HHmmss\u0026#39;).log\u0026#34; File Share Witness (Quorum) Für einen 2-Node Cluster ist ein Witness zwingend erforderlich, um Split-Brain-Szenarien zu vermeiden. Hier wird ein File Share auf dem Domain Controller (\\\\LAB-DC\\quorum$) genutzt.\nManueller Zwischenschritt\nDas Cluster-Computer-Objekt (MSSQL-CL-01$) benötigt Full Control auf Ebene der Share- und NTFS-Berechtigungen des Witness-Pfads (\\\\LAB-DC\\quorum$). Dies muss vor dem folgenden Befehl sichergestellt sein.\n.\\cluster_manageSQLCluster.ps1 ` -Operation SetWitness ` -ClusterName \u0026#34;MSSQL-CL-01\u0026#34; ` -WitnessShare \u0026#34;\\\\LAB-DC\\quorum$\u0026#34; ` -LogPath \u0026#34;C:\\Temp\\Cluster_Witness_$(Get-Date -Format \u0026#39;yyyyMMdd_HHmmss\u0026#39;).log\u0026#34; Verwendete Microsoft Cmdlets Das Script nutzt primär das FailoverClusters Modul\nNew-Cluster Erstellt den Cluster, bindet die Nodes ein und setzt die Management-IP Set-ClusterQuorum Konfiguriert den Witness-Modus (hier: File Share Witness) Install-WindowsFeature Installiert die RSAT-Tools und den Cluster-Dienst Identity Management: gMSA ⚒️ security_createGMSA.ps1\n📓 security_createGMSA.md\nDie Nutzung von Standard-Usern als Service Accounts kann zu abgelaufenen Passwörtern und Downtime führen. Die empfohlene Methode für SQL Server sind Group Managed Service Accounts (gMSA). Hierbei übernimmt der Key Distribution Service (KDS) des Active Directory die Passwortrotation; Niemand muss das Passwort kennen.\nKDS Root Key Bevor der erste gMSA erstellt werden kann, muss einmalig pro Forest ein KDS Root Key existieren. Sollte bereits ein Key existieren, wird die Erstellung übersprungen.\n.\\security_createGMSA.ps1 ` -InitializeKDS ` -LogPath \u0026#34;C:\\Temp\\KDS_Init.log\u0026#34; gMSA Erstellung Anstatt Server direkt einem gMSA zuzuordnen, ist es Best Practice, eine Security Group zu erstellen (SQL_LAB_CL01), welche die Computerkonten der Cluster-Nodes enthält. Neben der Einrichtung der eigentlichen gMSA kann dieses Script auch die Security Gruppen erstellen und die Zuordnungen vornehmen. Und immer schön die Beschreibungen bei AD-Objekten pflegen.\n.\\security_createGMSA.ps1 ` -AccountName @( ` @(\u0026#34;g-LAB22A-oltp\u0026#34;, \u0026#34;SQL Server Engine Account for LAB22A\u0026#34;), ` @(\u0026#34;g-LAB22A-agnt\u0026#34;, \u0026#34;SQL Server Agent Account for LAB22A\u0026#34;) ) ` -SecurityGroupName \u0026#34;SQL_LAB_CL01\u0026#34; ` -SecurityGroupDescription \u0026#34;SQL Server Cluster CL01 gMSA Group\u0026#34; ` -ServerNames \u0026#34;LAB-NODE01\u0026#34;,\u0026#34;LAB-NODE02\u0026#34; ` -CreateSecurityGroup ` -SecurityGroupOU \u0026#34;OU=lab_secgrp,DC=lab,DC=local\u0026#34; ` -PasswordIntervalDays 90 ` -LogPath \u0026#34;C:\\Temp\\gMSA_Creation_$(Get-Date -Format \u0026#39;yyyyMMdd_HHmmss\u0026#39;).log\u0026#34; Nach diesem Schritt ist ein Neustart der Nodes erforderlich, damit die neue Gruppenmitgliedschaft wirksam wird.\nLokale Registrierung Nach der Erstellung müssen die gMSA lokal auf den Nodes registriert werden. Hierzu kann folgendes Script genutzt werden.\n# Wichtig für lokale Einrichtung ( Local Admin ) Add-WindowsFeature -Name RSAT-AD-PowerShell $gMSAs = @( \u0026#39;g-LAB22A-oltp\u0026#39;, \u0026#39;g-LAB22A-agnt\u0026#39; ) foreach ($gMSA in $gMSAs) { if (Test-ADServiceAccount -Identity $gMSA -ErrorAction SilentlyContinue) { try { Install-ADServiceAccount -Identity $gMSA -ErrorAction Stop Write-Host \u0026#34;$gMSA installiert\u0026#34; -ForegroundColor Green } catch { Write-Host \u0026#34;$gMSA - Fehler bei Installation: $($_.Exception.Message)\u0026#34; -ForegroundColor Red } } else { Write-Host \u0026#34;$gMSA existiert nicht\u0026#34; -ForegroundColor Yellow } } Nach diesem Schritt ist ein Neustart der Nodes erforderlich, damit die neue Gruppenmitgliedschaft (TGT) wirksam wird.\nVerwendete Microsoft Cmdlets Das Script nutzt primär das ActiveDirectory Modul\nAdd-KdsRootKey Erzeugt den Root Key für den Group Key Distribution Service New-ADServiceAccount Erstellt das gMSA Objekt im AD Set-ADServiceAccount Konfiguriert, welche Computer (PrincipalsAllowedToRetrieveManagedPassword) das Passwort lesen dürfen Kerberos und Service Principal Names (SPN) ⚒️ security_setSqlSpn.ps1\n📓 security_setSqlSpn.md\nEin gMSA besitzt standardmäßig nicht das Recht, seine eigenen SPNs im AD zu schreiben. Startet der SQL Dienst, schlägt die Registrierung oft fehl, was zu NTLM-Fallbacks führt. Auch wenn ich SPNs bevorzugt kontrolliert und manuell setze, muss die automatische Registrierung technisch möglich sein, um Fallbacks zu vermeiden.\nDas Script löst dieses Problem, indem es zusätzlich zur SPN Erstellung dem gMSA die Rechte im AD gewährt, seine eigenen SPNs zu verwalten. Es setzt ACLs der Nodes für Read, Write und Validated write auf das Attribut servicePrincipalName.\n.\\security_setSqlSpn.ps1 ` -ServiceAccount \u0026#34;LAB\\g-LAB22A-oltp\u0026#34; ` -InstanceName \u0026#34;LAB22A\u0026#34; ` -Port 51101 ` -Hostnames \u0026#34;LAB-NODE01\u0026#34;,\u0026#34;LAB-NODE02\u0026#34; ` -Domain \u0026#34;lab.local\u0026#34; ` -IsGMSA ` -SetADPermissions ` -LogPath \u0026#34;C:\\Temp\\SPN_AlwaysOn_$(Get-Date -Format \u0026#39;yyyyMMdd_HHmmss\u0026#39;).log\u0026#34; Verwendete Microsoft Cmdlets Zum einen wird setspn.exe für Verwaltung der SPN genutzt, zum anderen wieder das ActiveDirectory Modul, um Accounts zu verifizieren und die SIDs zu extrahieren.\nDa keines der Module Active Directory Permsission manipulieren kann, wird hierfür direkt das .NET Framework System.DirectoryServices genutzt, welches diverse Klassen bereitstellt, um das AD komplett auf Links zu drehen.\nLokale Sicherheitsrichtlinien (Local Security Policies) ⚒️ security_setSqlLocalSec.ps1\n📓 security_setSqlLocalSec.md\nWie überall in der IT sollte auch beim Sql Server nach dem PoLP gearbeitet werden, weshalb kein Service Account den lokalen Administrator bekommt.Damit SQL Server trotzdem fehlerfrei und performant läuft, benötigt der Service Account spezifische Rechte im Betriebssystem („User Rights Assignment“). Wer dies ein paar mal manuell gemacht hat, wird sich sehr über diese Lösung freuen. Diese muss lokal auf dem jeweiligen Node ausgeführt werden.\n# ===== Set Engine Permissions for gMSA ===== .\\security_setSqlLocalSec.ps1 ` -ServiceAccount \u0026#34;g-LAB22A-oltp$\u0026#34; ` -ServiceType \u0026#34;engine\u0026#34; ` -IsGMSA ` -LogPath \u0026#34;C:\\Temp\\LAB22A_Engine_$(Get-Date -Format \u0026#39;yyyyMMdd_HHmmss\u0026#39;).log\u0026#34; # ===== Set Agent Permissions for gMSA ===== .\\security_setSqlLocalSec.ps1 ` -ServiceAccount \u0026#34;g-LAB22A-agnt$\u0026#34; ` -ServiceType \u0026#34;agent\u0026#34; ` -IsGMSA ` -LogPath \u0026#34;C:\\Temp\\LAB22A_Agent_$(Get-Date -Format \u0026#39;yyyyMMdd_HHmmss\u0026#39;).log\u0026#34; Verwendete Microsoft Cmdlets Da PowerShell keine nativen Cmdlets besitzt, um lokale Sicherheitsrichtlinien (LSA) zu bearbeiten, wird das Windows-Tool secedit.exe genutzt und der Export manipuliert.\nSummary Mit diesen vier Bausteinen wurde das Fundament für eine Sql Server Installation gelegt. Es wurde nicht nur eine Installation durchgeführt, sondern eine valide, dokumentierte Konfiguration geschaffen, die Identität (gMSA), Netzwerk (DNS/SPN) und OS-Performance (LSA) berücksichtigt. Im nächsten Schritt kann die eigentliche SQL Server Instanz installiert werden.\nSchaut euch auch die verlinkten MD-Files an, dort stehen Hintergrundinfos zu den Best Practices und weiterführende Artikel von Microsoft\n","permalink":"https://dbavonnebenan.de/automate-sql-server-ha-ad-spn-and-cluster-setup/","summary":"Production-Ready Windows Cluster Deployment: Automatisierung von Failover Cluster, gMSA, Kerberos und lokalen Rechten via PowerShell.","title":"SQL Server HA: AD, SPN und Cluster Setup automatisieren"},{"content":"Current Release ( 2026-06-08 ) psTerminalPerfCounter 0.4.0\nChangelog Documentation Intro Die Windows Performance Counter sind absolut mächtig, aber wenn es mal schnell gehen muss oder ich genau passend zu einem Problem ein Monitoring benötige, bin ich schnell genervt. Meistens nutze ich dann doch andere Möglichkeiten, PowerShell Native Get-Counter, CIM oder greife auf vorhandene Monitoring-Lösungen bei meinen Kunden zurück. Aber auch das geht nie AdHoc aber ich habe es akzeptiert.\nNun habe ich beim letzten DataSaturday Uwe Ricken beim Performance Tuning Workshop begleiten dürfen und auch er hat die Performance Counter noch mal klar als Musthave im Werkzeugkoffer eines jeden DBA benannt. Was mir bis dahin nicht bewusst war: SQL Server legt individuelle Counter wie Compile/sec, AdHoc Queries/sec usw. an.\nDie Möglichkeiten, Abhängigkeiten direkt zu visualisieren – endlos. Aber wie lange soll ich da sitzen, bis ich das im Windows Performance Monitor abgebildet habe, am besten Adhoc bei einem Kunden?\nUwe zeigte die Möglichkeiten im Windows Admin Center auf, welches Templates ermöglicht, die man flexibel auf Servern nutzen kann. Für System oder Umgebungen, in denen das Admin Center strategisch genutzt wird, definitiv eine sehr gut Wahl.\nAber zwei Probleme bleiben: Als Berater kann ich nicht bei jedem Kunden erst Software installieren und wenn das Admin Center doch läuft, scheitern meine englischen Templates an deutschen Systemen.\nNun war ich trotzdem so unglaublich angefixt von der Template-Idee und den Sql Server Möglichkeiten, dass nach Feierabend 4 Wochen Crunchtime im Kopf waren. Somit möchte ich euch an dieser Stelle mein erstes Modul in der PowerShell Gallery vorstellen\npsTerminalPerfCounter 0.1.0-preview\nDie technischen Details, Entwicklungsstand findet ihr alle im Repository, ich möchte hier einfach die verschiedenen Möglichkeiten zeigen.\nMain Features 100% PowerShell keine externen Abhängigkeiten Terminal-Grafiken natürlich ist es keine richtige Engine, je mehr Counter desto Hakeliger wird es, aber es reicht Als Basis dient die Lösung von Prateek Singh. Ohne diesen Fund hätte ich wohl dieses Problem erst lösen müssen, wofür ich vermutlich keine Zeit gehabt hätte. DANKE!!! Configuration Templates jedes Element der Ausgabe wird über Configuration Files gesteuert flexibel, transportabel Individualisierung der Datenausgaben für jeden Counter im Configuration-File kann eine eigene Ausgabe genutzt werden Table, Graph oder Beide beliebige Skalierungen der Achsen in Steps und Max beliebige Einfärbung der Values auf Basis einer benutzerdefinierten ColorMap per Counter Konvertierung der Values per Configuration-File ( Byte -\u0026gt; KB -\u0026gt; MB -\u0026gt; GB ) Sprachunabhängig Configuration Files basieren nicht auf den Counter-Pfaden sondern IDs\nimmer noch transportabel, egal welche Systemsprache\nTranslation von ID zu Counterpfad erfolgt erst zur Laufzeit\nkeine externen Abhängigkeiten\nIch wusste gar nicht, dass dies möglich ist mit Windows Bordmitteln. Auch hier bin ich durch Zufall über einen Blog gestolpert bei PowerShell.ONE. Auch hier ein dickes DANKE!!! Meine eigentliche Lösung sah mehrere Sprachvarianten ( DE, EN, FR, ES) vor, welche dann per auslesen der Systemlokalen gesetzt wurden.\nDemo mit CPU Configuration # Install module with required dependency (GripDevJsonSchemaValidator) Install-Module -Name psTerminalPerfCounter -AllowPrerelease # Import the module Import-Module psTerminalPerfCounter # Start Default Cpu Configuration Start-tpcMonitor -ConfigName CPU Beim Laden der Konfiguration werden die Counter IDs zu Counterpfaden übersetzt und getestet\nWenn das erfolgreich war, werden die ersten Samples gesammelt, damit ein Graph angezeigt werden kann\nThats IT!\nInnerhalb von 10 Sekunden 2 Performance Counter am Laufen, ohne Installation, ohne Sprachprobleme.\nDemo Counter Translation # Translate ID -\u0026gt; Path Get-tpcPerformanceCounterInfo 238-6 # Search Counter -\u0026gt; Including ID Get-tpcPerformanceCounterInfo \u0026#34;Queue\u0026#34; Die Ausgabe ist stark beschnitten, da das ResultSet enorm ist\n# Search Counter -\u0026gt; Including ID Get-tpcPerformanceCounterInfo \u0026#34;Processor Queue\u0026#34; Wie geht’s weiter? Die Basis läuft, die planned Feature Liste ist lang und das, was ich wirklich brauche bezüglich Sql Server ist noch in weiter Ferne. Ich hoffe ich habe nicht ein Problem bedient, was es gar nicht gibt, aber dieses Modul adressiert einfach alle Probleme, die ich schon immer mit den Performance Countern hatte, siehe oben.\nWeiterhin ist das mein erstes größeres Projekt, was ich Public entwickle, somit könnte Github nicht immer den erwarteten Standards entsprechen. Über Feedback und Hinweise freue ich mich immer.\nGitHub – gabrielkoehl/psTerminalPerfCounter: psTerminalPerfCounter is a PowerShell module that provides predefined, language-independent performance counter configurations for real-time terminal-based monitoring, enabling admins to quickly deploy tailored system performance presets with graphical visualization instead of manually configuring Windows Performance Monitor.\n","permalink":"https://dbavonnebenan.de/psterminalperfcounter-speedup-your-performance-counters/","summary":"Visualisiere Windows Performance Counter direkt im Terminal mit psTerminalPerfCounter. Sprachunabhängige Templates, maximale Anpassbarkeit. Perfekt für schnelles AdHoc-Monitoring.","title":"psTerminalPerfCounter – SpeedUp your Performance Counters in Terminal"},{"content":"GitHub – gabrielkoehl/DBAScriptBox: Useful stuff for DBAs\nIntro Aktuell bin ich bei einem Kunden an einem Code Review beteiligt. Dabei beleuchten wir neben der Applikation auch alle Schnittstellen.. Dazu gehört natürlich auch die Sql Server Landschaft, welche ich Anfang des Jahres aufgesetzt habe.\nDas Ergebnis waren doch mehr Findings in meine Richtung als erwartet und ich fühlte mich sofort gechallenged. Das Meiste konnte ich widerlegen, bei einigen Themen war der Kunde in der Pflicht und ein Thema hat mich rein interessenhalber gepackt.\nRead- und Write Latenzen der TempDB ( und jeder anderen DB )\nVorgeschichte Der Kunde betreibt kein eigenes Rechenzentrum, ist somit vom Hoster abhängig, welcher leider nicht sehr kommunikativ ist. Somit musste ich mir auf diverse andere Wege ein Bild von der total overcommitteten Hardware machen und den Hoster Challengen. Dies war auch der Grund, warum ich ziemlich genau im Bilde war, was die Hosts und Storage Systeme des Hosters im Stande waren zu leisten.\nDeshalb hat es mich doch sehr gewundert, dass als Finding 32ms Write Latency aufgeführt waren. Keine Frage, das ist ein schlechter Wert für AllFlash NVMe aber der stand da einfach so im Report, ohne Differenzierung oder tiefere Analysen. Nur die Aussage schlechter Storage. Also habe ich meine Werkzeuge ausgepackt, mir das noch mal angeschaut und auch eine neue Lösung entwickelt, die ich mit euch teilen möchte.\nDISKSPD Repo: perf_diskspeed/DISKSPD\nMicrosoft: https://github.com/microsoft/diskspd\nMit DISKSPD sollte man auf unbekannten Systemen immer anfangen, oft liegt hier schon ein großer Anteil an Problemen versteckt. Bei diesem Kudnen lief zum Beispiel eine DB mit hohem Workload auf Spindeln, mit Latenzen in der .2 Perzentile mit 15 Sekunden Latenz, dazu 14MB Durchsatz. Da brauche ich mir um Indexe usw. keine Gedanken mehr machen.\nUm schnell an Ergebnisse zu kommen, habe ich mir einen Wrapper für DISKSP gebaut, welcher immer 3 Standardtests ausführt\nSql Server Workload Random 64KB Workload Sequenziell 64KB Workload Die Dateien werden separat im Unterordner _Output gespeichert und ermöglichen somit recht gute Hinweise auf Storage-Probleme. Nun waren das wie erwartet super Werte, welche NVMe Storage entsprechen. Also weiter zu Sql Server und wir schauen mal was uns dieser so sagt.\nsys.dm_io_virtual_file_stats Sql Server bietet eine View, in der alle Metriken der Files sauber aufgelistet werden.\nselect * from sys.dm_io_virtual_file_stats(null,null) microsoft.com Darauf basierend habe ich ein Analyse Script gebaut, welches mir mehr Infos gibt und ich auch weitere Rückschlüsse wie ReadWrite Ratio, wahrscheinliche IOPS auf Basis der Anzahl der Vorgänge und auch Mengen. Damit kann man schon ganz gut Storage Systeme zu speziellen Workloads aufbauen.\nUnd auch dieser Wert hat mir 32ms Write Latency der TempDB angezeigt. Dann habe ich angefangen mich zu fragen, wie entstehet dieser Wert überhaupt?\nGrundlegende Berechnung der Werte SQL Server misst I/O-Latenz durch einfache Division der kumulativen Wartezeiten durch die Anzahl der Operationen:\n-- Read Latency in ms io_stall_read_ms / num_of_reads = durchschnittliche Read-Latenz -- Write Latency in ms io_stall_write_ms / num_of_writes = durchschnittliche Write-Latenz Thats it!!! Und nun sollte klar sein, dass die punktuelle Nutzung dieser DMV nicht wirklich aussagekräftig ist, im Gegenteil. Die Werte können wie bei dem Review Unternehmen, was sich auf solche Prozesse spezialisiert hat, zu falschen Rückschlüssen und Handlungsempfehlungen führen. Gruselig.\nWenn das Storagesystem seit dem Start von Sql Server mal hart Schluckauf hatte, sind die Metriken verunreiningt. Laut meinen Recherchen kann man diese nicht flushen, nur durch das Offline nehmen der DB, was ich üblicherweise in produktiven Umgebungen vermeide.\nNach ein paar weiteren Runden in meinem Kopf kam recht schnell die Lösung. Das sind alles SnapShot Values, ich brauche ja nur das Delta zwischen zwei Werten und schon habe ich reale Werte. Und das Ganze kann ich auch noch in eine Zeitreihe packen und habe eine Langzeitanalyse. Mindblowing 😝\nGoogle hat auch schnell entsprechende Lösungen aufgezeigt, die ich als Basis Idee genutzt habe. Danke an Paul Randal ( sqlskills.com )\nFür die Analyse einer kompletten Woche ist dies aber auch nicht geeignet. Somit habe ich das Ganze auf eine Langzeitanalyse mit persistenten Table erweitert.\nDie Lösung –\u0026gt; snapDiskLatency Repo: perf_diskspeed/snapDiskLatency\nWas macht snapDiskLatency? Das Problem ist bekannt – die Standard-DMV sys.dm_io_virtual_file_stats zeigt kumulative Werte seit dem SQL Server Start. Ein einziger Storage-Schluckauf vor Wochen und die Latenzwerte sind nicht mehr repräsentativ.\nsnapDiskLatency löst das Problem mit zwei simplen Stored Procedures:\nDie Erste sammelt stündlich die Rohdaten aus der DMV und schreibt sie in einen permanenten Table. Warum stündlich? Kürzere Intervalle führen zu unzuverlässigen Delta-Berechnungen – zu wenig I/O zwischen den Snapshots macht die Werte ungenau. Dies kann aber individuell angepasst werden, da der Agent die Prozedur triggert.\nDie Zweite macht die Delta-Berechnungen zwischen den Snapshots und erstellt das Resultset. Somit werden reale Latenzwerte für definierte Zeiträume erzeugt, ohne historischen Schluckauf, welche dann mit anderen Metriken abgeglichen werden können.\nHier sehen wir zum Beispiel im TRUNCATE Table einen Aureißer ( hier liegt auch NVMe drunter ). Auf dem LAB System ist keine Last, DOXIS ist nur ein Table mit 2 Spalten und wurde künstlich mit Workload bearbeitet.\nDas Ergebnis Statt möglicherweise verunreinigten Werten\nDurchschnittliche Latenzen pro Intervall Read/Write-Verhältnisse Aufschlüsselung nach Datenbank und File-Type Setup Agent Job erstellen, stündlich laufen lassen, fertig. Die komplette Anleitung steht in der README, copy \u0026amp; paste \u0026amp; freuen\nDiagramme Da dies auch jedes gute propritäre DatabaseMonitoringTool macht und hübsch grafisch darstellt, will ich zumindest eine Möglichkeit in Excel im Ergebnis zeigen. Dazu muss das Ergebnis der DataSource oder Copy pivotiert werden und schon kann man gut seine Daily Peaks erkennen.\n","permalink":"https://dbavonnebenan.de/sql-server-disk-latency/","summary":"Wie du richtige SQL Server Disk Latency Werte erhältst statt verfälschter DMV-Daten. Open Source snapDiskLatency Lösung für Langzeitanalyse.","title":"SQL Server Disk Latency richtig messen – snapDiskLatency"},{"content":"Intro Seit eh und je nutze ich PowerShell nach Schema F, so ungefähr war auch mein Lernpfad entsprechend PowerShell Best Practices.\nQuick and Dirty Einzeiler in der Konsole, mittlerweile Terminal Nach und nach wurden aus den Einzeilern PowerShell Scripte mit besser organisierten Einzeilern Es kamen Variablen, dann Funktionen, die Wiederverwendbarkeit stieg Aus Funktionen wurden Module, persistente Datenhalden in Json und technologisch war das erstmal das Ende Das letzte HighLight war Threading und Runspaces Auf den letzten beiden Ebenen habe ich mich nun sehr lange bewegt, natürlich immer effizienter und allgemein wurde das PowerShell Wissen breiter.\nWährend dieser Entwicklung merkte ich jedoch ein Problem: Ich bin ein sehr organisierter Mensch, zumindestens im beruflichen Umfeld 😉, und so soll auch mein Code sein, strukturiert. Von Clean Code halte ich nichts, Kommentare sind einfach punktuell wichtig, für mich, für andere, für meine Kunden. Neben Kommentaren ist aber auch die Struktur wichtig, was bringen mir Kommentare an einem ‚Bucket of Chars‘ ? Ebenfalls liebe ich symmetrischen Code, ja lacht ruhig, aber es macht sofort ersichtlich, was ist eine Variable, was eine Zusweisung und was der Value. Wenn ich sowas sehe…\n$userInfo = @{ Name = $varSurename Address = $varStreet Data = $varRandomLongVar } $configSettings = @{ ServerName = \u0026#39;localhost\u0026#39; Port = 5432 Database = \u0026#39;mydb\u0026#39; Timeout = 30 } $employee = @{ Personal = @{ FirstName = $varSurename LastName = \u0026#39;Doe\u0026#39; Street = $varStreet } Work = @{ Department = \u0026#39;IT\u0026#39; Position = \u0026#39;Developer\u0026#39; } } … da kehrt sich mein Innerstes nach Außen 🤣 Ist vielleicht auch eine Krankheit. Dies ist eine normale Schreibweise, die als sauber gilt, ich weiß, aber das sollte doch so aussehen..\n$userInfo = @{ Name = $varSurename Address = $varStreet Data = $varRandomLongVar } $configSettings = @{ ServerName = \u0026#39;localhost\u0026#39; Port = 5432 Database = \u0026#39;mydb\u0026#39; Timeout = 30 } $employee = @{ Personal = @{ FirstName = $varSurename LastName = \u0026#39;Doe\u0026#39; Street = $varStreet } Work = @{ Department = \u0026#39;IT\u0026#39; Position = \u0026#39;Developer\u0026#39; } } $users = @( @{ Name = \u0026#39;Alice\u0026#39;; Role = \u0026#39;Admin\u0026#39; } @{ Name = $varSurename; Role = \u0026#39;User\u0026#39; } ) Wie auch immer, darum solls hier nicht gehen. Es ist grundsätzlich so, dass die Struktur und Ordnung bei größeren Projekten nach und nach abnimmt und Klassen genau auf dieses Thema einspielen. Aber warum jetzt erst? Klassen gibt es seit PowerShell 5.0 .\nAI Assisted Coding Natürlich war ich early Adopter der ganzen KI Chatbots und war erstaunt, was ChatGPT vor 2 Jahren schon konnte. Natürlich war der Code, egal welche Sprache, unbrauchbar, aber für Wissenserzeugung allemal nützlich. So wurde mit fortlaufender Qualität der Code besser und auch die Lösungswege wurden immer interessanter.\nIrgendwann sind in den Vorschlägen Klassen aufgetaucht und ich habe es konsequent ignoriert 😝. Durch meine C# Reisen wusste ich, dass Klassen einfach der Standard sind, man aber schon grundlegend Wissen sollte, was ich damit machen will im Projekt, um diese sauber zu entwerfen. Und diesen Aufwand wollte ich mir nicht machen.\nDas neue Projekt Es war an der Zeit, eine 4 Jahre alte Lösung an neue Anforderungen anzupassen, wie das halt manchmal so der Fall ist. Da mein Wissen ja auch nicht stehen bleibt, habe ich nach kurzem überfliegen des Codes entschieden:\nDAS FASSE ICH NICHT MEHR AN, DAS MUSS ALLES NEU!!\nNun war ich in der entspannten Lage, dass für die Lösung alles vorhanden war\nProgrammablaufplan (PAP) Funktionsbeschreibungen Programmatische Lösung der benötigten Funktionen auf unterster Ebene 4 Jahre Lessons learned Somit musste ich mich nur um die Orchestrierung aller Schritte kümmern und habe entschieden, dass ich den Klassen mal eine Chance geben werde. In der Theorie ist dies nämlich die sauberste und strukturierteste Möglichkeit zu Coden.\nDas Ergebnis hat meine Art zu Coden nicht völlig, aber nachhaltig verändert – aber dazu später mehr.\nFazit nach 5 Wochen im Projekt Klassen in PowerShell sind so unglaublich simpel, so strukturiert, so wunderschön❤️. Natürlich muss der UseCase passen, da die Implementierung initial mehr Struktur verlangt, aber wenn dieser gegeben ist, wird für mich kein Weg mehr an Klassen vorbei führen.\nWarum dieser Artikel, gibt doch genug? Es gibt einige Artikel über Klassen in PowerShell und Objektorientierung aber trotzdem wird dieses Thema kaum in einem klassischen Tutorial behandelt. Es sind immer die Funktionen und man muss um dieses Thema wissen um es zu finden. Somit schreibe ich einfach noch einen Artikel, auch mal in deutsch, um vielleicht doch den ein oder anderen zusätzlich zu erreichen, weil…\nHintergrundinfos zu PowerShell Klassen – OOP seit Version 5.0 Klassen gibt es in PowerShell seit PowerShell 5.0 also 2016… und ich habe vor einem Jahr erst davon erfahren 🤦‍♂️. PowerShell Klassen bringen objektorientierte Programmierkonzepte in PowerShell und haben somit auch haben alle grundlegenden Features einer Klasse.\nEigenschaften (Properties): Eigenschaften sind stark typisiert und unterstützen die meisten Validierungsattribute wie [ValidateNotNull()], [ValidateRange()] etc. Methoden: Methoden sind Funktionen, die an ein Objekt gebunden sind und explizit den Rückgabetyp definieren müssen Konstruktoren: Ermöglichen die Initialisierung von Objekten mit spezifischen Werten Vererbung: Erlaubt es, neue Klassen von bestehenden Klassen zu erstellen und deren Funktionalität zu erweitern Eine Klasse ist nach dem Laden ein eigener Datentyp, später mehr dazu.\nUnd wie funktioniert das jetzt? Ich weiß noch, wie ich mich vor vielen Jahren mit OOP schwer tat und allgemein davon auszugehen ist, dass sich doch eher Admins als vollblut Software Entwickler initial mit PowerShell auseinander setzen. Somit versuche ich es mal total simpel.\nIch nehme mal ein fiktives Modul, welche per Remoting Serverproperties abfragt und lokal auswertet, ein klassischer AdminTask.\nACHTUNG: Natürlich ist dieses Beispiel sehr konstruiert und nicht zwingend praktikabel aber es zeigt meiner Meinung nach die Zusammenhänge recht gut.\nDieses PowerShell Klassen Tutorial zeigt dir die wichtigsten Konzepte für objektorientierte Programmierung mit PowerShell.\nEigenschaften (Properties) Eine Klasse hat zu jeder Zeit ein fest definierten Satz an Eigenschaften. Dieser kann zur Laufzeit nicht geändert werden, sondern muss in der Definition der Klasse beschrieben werden.\nDie Klasse class Server { # All Possible properties for the Server class [string] $ServerName [string] $Status [ipaddress] $IP [string] $Location [datetime] $LastBootTime [string] $OperatingSystem # ------------------------------------------- } Konstruktoren Ein Konstruktor erzeugt die Instanz einer Klasse. Dabei kann die Klasse default Values erhalten, oder der Konstruktor erwartet Parameter. In unserem Fall ist ein Servername sinnvoll. Somit gebe ich der Property ServerName direkt beim Laden einen Wert.\nclass Server { # All Possible properties for the Server class [string] $ServerName [string] $Status [ipaddress] $IP [string] $Location [datetime] $LastBootTime [string] $OperatingSystem # ------------------------------------------- # Constructor Server([string]$name) { $this.ServerName = $name } } Nun haben wir zwar ein Klasse aber wie bekommen wir nun einen Server da rein? Indem wir die Klasse in eine Variable laden und am besten auch noch dynamisch für alle Server.\nclass Server { # All Possible properties for the Server class [string] $ServerName [string] $Status [ipaddress] $IP [string] $Location [datetime] $LastBootTime [string] $OperatingSystem # ------------------------------------------- # Constructor Server([string]$name) { $this.ServerName = $name } } $serverlist = @(\u0026#39;Server1\u0026#39;,\u0026#39;Server2\u0026#39;,\u0026#39;Server3\u0026#39;) foreach ( $server in $serverlist ) { # Create a new Server object for each server name New-Variable -Name \u0026#34;obj_$server\u0026#34; -Value ([Server]::new($server)) -Force } Methoden Methoden machen meiner Meinung nach die Klassen erst richtig interessant. Methoden sind die Funktionen mit denen ich Eigenschaften der Klassen manipulieren kann oder auf Basis von Argumenten, welche ich dem Aufruf hinzufüge, RETURNS erzeugen kann. Hierbei gebe ich bereits in der Methodendefintion den Typ der Rückgabe an. VOID erzeugt somit logischerweise keine Rückgabe.\nclass Server { [string] $ServerName [string] $Status [ipaddress] $IP [string] $Location [datetime] $LastBootTime [string] $OperatingSystem Server([string]$name) { $this.ServerName = $name } [void] GetServerInfo() { try { $osInfo = Invoke-Command -ComputerName $this.ServerName -ScriptBlock { Get-CimInstance Win32_OperatingSystem | Select-Object Caption, LastBootUpTime } -ErrorAction Stop $this.IP = Invoke-Command -ComputerName $this.ServerName -ScriptBlock { (Get-NetIPAddress -AddressFamily IPv4 | Where-Object {$_.IPAddress -notlike \u0026#39;169.*\u0026#39;} | Select-Object -First 1).IPAddress } -ErrorAction Stop $this.OperatingSystem = $osInfo.Caption $this.LastBootTime = $osInfo.LastBootUpTime $this.Status = \u0026#34;Online\u0026#34; } catch { $this.Status = \u0026#34;Offline\u0026#34; } } } $serverlist = @(\u0026#39;Server1\u0026#39;,\u0026#39;Server2\u0026#39;,\u0026#39;Server3\u0026#39;) foreach ($server in $serverlist) { New-Variable -Name \u0026#34;obj_$server\u0026#34; -Value ([Server]::new($server)) -Force } $obj_Server1.GetServerInfo() $obj_Server2.GetServerInfo() $obj_Server3.GetServerInfo() Hier habe ich die Methode GetServerInfo() eingefügt, die nun die Informationen zum Server sammelt. Dabei muss ich weder ein Argument mitgeben oder ein Cmdlet starten, da die Instanz (Servername) der Klasse (Server) alles vererbt bekommen hat. Ich brauche keine externen Funktionen, Variablen oder sonst was, alles in der Klasse vorhanden. ❤️ Folgend ein Beispiel aus dem LAB\nLAB Results\nUnd jetzt, wo ist der Nutzen? Natürlich ist das nicht der optimalste Use Case, dafür verständlich. Eine Möglichkeit wäre, eine LoggingKlasse zu erstellen. Anbei aus meinem Projekt:\nclass PatchLogger { [string] $ServerName [string] $LogPathServer [string] $LogLevel = \u0026#39;INFO\u0026#39; [hashtable] $LogTargets [bool] $ConsoleOutput [bool] $StreamOutput [string] $VerbosePreference [string] $DebugPreference # Constructor PatchLogger(\t[string]$LogPathServer, [string]$ServerName, [string]$MessageFile, [string]$ErrorFile, [string]$VerboseFile, [string]$DebugFile, [string]$SqlServerFile, [bool]$ConsoleOutput = $true, [bool]$StreamOutput = $false) { $this.LogPathServer = $LogPathServer $this.ServerName = $ServerName $this.ConsoleOutput = $ConsoleOutput $this.StreamOutput = $StreamOutput $this.LogTargets = @{ Main = $MessageFile Error = $ErrorFile Verbose = $VerboseFile Debug = $DebugFile SqlServer = $SqlServerFile } $this.VerbosePreference = $Global:VerbosePreference $this.DebugPreference = $Global:DebugPreference if ( -not (Test-Path $this.LogPathServer) ) { New-Item -Path $this.LogPathServer -ItemType Directory -Force | Out-Null } } } Eine Instanz der Klasse wird direkt beim Laden des Moduls in die Variable $PatchLogger geladen und ab jetzt kann ich mit $PatchLogger.Info($message) schon direkt loslegen. Wie? So ein kurzer Befehl bei einer so komplexen Klasse? Kommen wir zum letzten, was meiner Meinung nach der Vorteil schlechthin ist: Überladung.\nÜberladung Überladung heisst nichts anderes als die Anzahl der Argumente, die ich einer Methode übergebe. Anhand der Anzahl kann die Engine unterscheiden, welche Methode genutzt wird, da ich mehrer mit den gleichen Namen haben kann. Der Fachbegriff wäre Method Overloading.\nDer Mehrwert liegt darin, dass ich nicht wie bei Funktionen mit BoundParams, Switch oder IF SChleifen arbeiten muss. Wenn eine Helfer Methode mit nur einem Argument aufgerufen wird, werden intern die fehlenden Argumente aufgefüllt und die Hauptmethode aufgerufen.\nNehmen wir das Beispiel $PatchLogger.Info($message)\n# Hauptmethode [hashtable] WriteLog([string]$Level, [string]$Message, [string]$MessageCode, [int]$Severity, [string]$Target, [bool]$ReturnObject) {...} # Helfermethode [hashtable] Info([string]$Message) { return $this.WriteLog(\u0026#39;INFO\u0026#39;, $Message, $null, 0, \u0026#39;Main\u0026#39;, $true) } # Helfermethode 2 [hashtable] Info([string]$Message, [string]$MessageCode) { return $this.WriteLog(\u0026#39;INFO\u0026#39;, $Message, $MessageCode, 0, \u0026#39;Main\u0026#39;, $true) } Was wird das meiste sein, was ich ich einem großen Modul benötige? Eine einfache Message ins Main Log, ohne Messagecode und SchnickSchnack. Somit ruft die Helfermethode die Hauptmethode mit den Defaultwerten auf, die genau das bewirken.\nSchauen wir uns Helfermethode 2 an. Diese erwartet 2 Argumente, nämlich einen MessageCode. Schon kann ich mit $PatchLogger.Info(„Prozess XY abgeschlossen“,“I0002″) eine registrierte Message schreiben.\nNatürlich kann ich das auch alles mit Funktionen realisieren aber ich denke nicht so strukturiert und hübsch.\nGesamte PatchLogger Klasse class PatchLogger { [string] $ServerName [string] $LogPathServer [string] $LogLevel = \u0026#39;INFO\u0026#39; [hashtable] $LogTargets [bool] $ConsoleOutput [bool] $StreamOutput [string] $VerbosePreference [string] $DebugPreference # Constructor PatchLogger([string]$LogPathServer, [string]$ServerName, [string]$MessageFile, [string]$ErrorFile, [string]$VerboseFile, [string]$DebugFile, [string]$SqlServerFile, [bool]$ConsoleOutput = $true, [bool]$StreamOutput = $false) { $this.LogPathServer = $LogPathServer $this.ServerName = $ServerName $this.ConsoleOutput = $ConsoleOutput $this.StreamOutput = $StreamOutput $this.LogTargets = @{ Main = $MessageFile Error = $ErrorFile Verbose = $VerboseFile Debug = $DebugFile SqlServer = $SqlServerFile } $this.VerbosePreference = $Global:VerbosePreference $this.DebugPreference = $Global:DebugPreference if ( -not (Test-Path $this.LogPathServer) ) { New-Item -Path $this.LogPathServer -ItemType Directory -Force | Out-Null } } [void] UpdatePreferences([string]$VerbosePreference, [string]$DebugPreference) { $this.VerbosePreference = $VerbosePreference $this.DebugPreference = $DebugPreference } # Central WriteLog method - all other methods call this one [object] WriteLog([string]$Level, [string]$Message, [string]$MessageCode, [int]$Severity, [string]$Target, [bool]$ReturnObject) { $timestamp = Get-Date -Format \u0026#34;yyyy-MM-dd HH:mm:ss\u0026#34; $severityText = if ($Severity -ne 9999) { \u0026#34;S$Severity\u0026#34; } else { \u0026#34;\u0026#34; } $messageCodeText = if ($MessageCode) { \u0026#34; $MessageCode\u0026#34; } else { \u0026#34;\u0026#34; } $paddedLevel = \u0026#34;{0,-9}\u0026#34; -f \u0026#34;[$Level]\u0026#34; $additionalInfo = \u0026#34;$severityText$messageCodeText\u0026#34; $logEntry = if ( $level -eq \u0026#39;BLANK\u0026#39; ) { \u0026#34;\u0026#34; } elseif ( $Level -notin @(\u0026#39;VERBOSE\u0026#39;,\u0026#39;DEBUG\u0026#39;) -and -not [string]::IsNullOrEmpty($additionalInfo) ) { \u0026#34;[$timestamp] $paddedLevel [$($this.ServerName)] $Message ($additionalInfo)\u0026#34; } else { \u0026#34;[$timestamp] $paddedLevel [$($this.ServerName)] $Message\u0026#34; } $targetFile = $this.LogTargets[$Target] if ( $targetFile ) { try { Add-Content -Path $targetFile -Value $logEntry -Encoding UTF8 $verboseFile = $this.LogTargets[\u0026#39;Verbose\u0026#39;] if ( $verboseFile -and $Level -ne \u0026#39;VERBOSE\u0026#39; ) { Add-Content -Path $verboseFile -Value $logEntry -Encoding UTF8 # for unbroken verbose stream } } catch { Invoke-ScriptError $_ } } if ( $this.ConsoleOutput ) { switch ( $Level ) { \u0026#39;ERROR\u0026#39; { Write-Host $logEntry -ForegroundColor Red } \u0026#39;WARNING\u0026#39; { Write-Host $logEntry -ForegroundColor Yellow } \u0026#39;INFO\u0026#39; { Write-Host $logEntry -ForegroundColor Green } \u0026#39;BLANK\u0026#39; { Write-Host $logEntry} \u0026#39;VERBOSE\u0026#39; { if ( $this.VerbosePreference -ne \u0026#39;SilentlyContinue\u0026#39; ) { Write-Host $logEntry -ForegroundColor Cyan } } \u0026#39;DEBUG\u0026#39; { if ( $this.DebugPreference -ne \u0026#39;SilentlyContinue\u0026#39; ) { Write-Host $logEntry -ForegroundColor Magenta } } } } # PowerShell streams for integration - only if explicitly enabled if ( $this.StreamOutput ) { switch ($Level) { \u0026#39;ERROR\u0026#39; { Write-Error $Message -ErrorAction Continue } \u0026#39;WARNING\u0026#39; { Write-Warning $Message } \u0026#39;VERBOSE\u0026#39; { Write-Verbose $Message } \u0026#39;DEBUG\u0026#39; { Write-Debug $Message } } } # Return object only when requested if ( $ReturnObject ) { return @{ HasError = $Level -eq \u0026#39;ERROR\u0026#39; HasWarning = $Level -eq \u0026#39;WARNING\u0026#39; MessageCode = if ( $MessageCode ) { $MessageCode } else { $null } Message = $Message Severity = $Severity Level = $Level Target = $Target } } return $null } # BLANK Line [void] BlankLine() { $this.WriteLog(\u0026#39;BLANK\u0026#39;, \u0026#39;\u0026#39;, $null, 0, \u0026#39;Main\u0026#39;, $false) } # INFO Methods - standard return hashtable [hashtable] Info([string]$Message) { return $this.WriteLog(\u0026#39;INFO\u0026#39;, $Message, $null, 0, \u0026#39;Main\u0026#39;, $true) } [hashtable] Info([string]$Message, [string]$MessageCode) { return $this.WriteLog(\u0026#39;INFO\u0026#39;, $Message, $MessageCode, 0, \u0026#39;Main\u0026#39;, $true) } # INFO NoReturn [void] InfoNoReturn([string]$Message) { $this.WriteLog(\u0026#39;INFO\u0026#39;, $Message, $null, 0, \u0026#39;Main\u0026#39;, $false) } [void] InfoNoReturn([string]$Message, [string]$MessageCode) { $this.WriteLog(\u0026#39;INFO\u0026#39;, $Message, $MessageCode, 0, \u0026#39;Main\u0026#39;, $false) } # WARNING Methods - standard return hashtable [hashtable] Warning([string]$Message) { return $this.WriteLog(\u0026#39;WARNING\u0026#39;, $Message, $null, 1, \u0026#39;Main\u0026#39;, $true) } [hashtable] Warning([string]$Message, [string]$MessageCode) { return $this.WriteLog(\u0026#39;WARNING\u0026#39;, $Message, $MessageCode, 1, \u0026#39;Main\u0026#39;, $true) } # WARNING NoReturn [void] WarningNoReturn([string]$Message) { $this.WriteLog(\u0026#39;WARNING\u0026#39;, $Message, $null, 1, \u0026#39;Main\u0026#39;, $false) } [void] WarningNoReturn([string]$Message, [string]$MessageCode) { $this.WriteLog(\u0026#39;WARNING\u0026#39;, $Message, $MessageCode, 1, \u0026#39;Main\u0026#39;, $false) } # ERROR Methods - standard return hashtable [hashtable] Error([string]$Message) { return $this.WriteLog(\u0026#39;ERROR\u0026#39;, $Message, $null, 2, \u0026#39;Error\u0026#39;, $true) } [hashtable] Error([string]$Message, [string]$MessageCode) { return $this.WriteLog(\u0026#39;ERROR\u0026#39;, $Message, $MessageCode, 2, \u0026#39;Error\u0026#39;, $true) } # ERROR NoReturn [void] ErrorNoReturn([string]$Message) { $this.WriteLog(\u0026#39;ERROR\u0026#39;, $Message, $null, 2, \u0026#39;Error\u0026#39;, $false) } [void] ErrorNoReturn([string]$Message, [string]$MessageCode) { $this.WriteLog(\u0026#39;ERROR\u0026#39;, $Message, $MessageCode, 2, \u0026#39;Error\u0026#39;, $false) } # VERBOSE \u0026amp; DEBUG - NoReturn [void] Verbose([string]$Message) { $this.WriteLog(\u0026#39;VERBOSE\u0026#39;, $Message, $null, 0, \u0026#39;Verbose\u0026#39;, $false) } [void] Debug([string]$Message) { $this.WriteLog(\u0026#39;DEBUG\u0026#39;, $Message, $null, 0, \u0026#39;Debug\u0026#39;, $false) } # Step/SQL/AG Methods - NoReturn [void] StepStart([int]$Step, [string]$StepName) { $this.BlankLine() $message = \u0026#34;========================= STEP $Step START: $StepName =========================\u0026#34; $this.WriteLog(\u0026#39;INFO\u0026#39;, $message, $null, 9999, \u0026#39;Main\u0026#39;, $false) } [void] StepEnd([int]$Step, [string]$StepName, [bool]$Success) { $status = if ( $Success ) { \u0026#34;SUCCESS\u0026#34; } else { \u0026#34;FAILED\u0026#34; } $message = \u0026#34;========================= STEP $Step END: $StepName - $status =========================\u0026#34; $this.WriteLog(\u0026#39;INFO\u0026#39;, $message, $null, 9999, \u0026#39;Main\u0026#39;, $false) $this.BlankLine() } } Zusammenfassung PowerShell Klassen revolutionieren die Art, wie du größere Projekte strukturierst. Seit PowerShell 5.0 verfügbar, bieten sie objektorientierte Programmierung mit Eigenschaften, Methoden, Konstruktoren und Method Overloading. Der anfängliche Mehraufwand zahlt sich durch sauberen, wartbaren Code aus – besonders bei Modulen und komplexeren Funktionssammlungen.\nDie wichtigsten Vorteile auf einen Blick\nStark typisierte Properties mit Validierung gekapselte Funktionalität durch Methoden elegante Überladung statt komplexer Parameter-Logik und eine Struktur, die auch nach Monaten noch verständlich bleibt Für Daily-Doing-Scripts bleibt der klassische Ansatz praktischer, aber sobald Wiederverwendbarkeit und Struktur wichtig werden, führt für mich kein Weg mehr an Klassen vorbei. 🫡\n","permalink":"https://dbavonnebenan.de/powershell-classes-for-beginner/","summary":"Intro Seit eh und je nutze ich PowerShell nach Schema F, so ungefähr war auch mein Lernpfad entsprechend PowerShell Best Practices. Auf den letzten beiden Ebenen habe ich mich nun sehr lange bewegt, natürlich immer effizienter und allgemein wurde das PowerShell Wissen breiter. Während dieser Entwicklung merkte ich jedoch ein Problem: Ich bin ein sehr","title":"PowerShell Klassen für Anfänger – Strukturierter Code statt Funktions-Chaos"},{"content":"Kürzlich bin ich über einen LinkedIn-Post zu TRUNCATE vs. DELETE gestolpert, wie so viele andere auch. Typischerweise posten zufällige Mitglieder einfache SQL Server Tipps, schön verpackt in Grafiken und allgemein gehalten. Obwohl das für Anfänger absolut legitim ist – da diese einfachen Einstiegspunkte vielen Neulingen helfen können zu verstehen und einen großartigen Startpunkt bieten – ist die Tatsache, dass dieselben Themen dann viral über verschiedene Accounts gehen, klar eine ganz andere Sache.\nWie auch immer. Wenn du beim Thema schon etwas weiter bist und bereits weißt, dass die Aussprache nicht „SQL“ sondern „Sequel“ ist 😊, solltest du diese Posts grundsätzlich hinterfragen, da sie meist verallgemeinern.\nSo war es auch bei einem Post über die Top 3 SQL-Fehler, die „jeder“ macht. Und hier kommen wir zum Punkt – TRUNCATE TABLE und seine Besonderheiten.\nLinkedIn\nDasselbe passierte mit Vedran Kesegic, der den Hinweis gab, dass TRUNCATE TABLE anscheinend rollback-fähig ist, wenn es in einer Transaktion gekapselt wird. Dann sprang Carsten Saastamoinen-Jakobsen ein und die Sache wurde wild. So wild, dass mich das ganze Thema dermaßen gepackt hat, dass ich einen Deep Dive gemacht habe. Außerdem fiel in diesem Austausch so viel Wissen ab, dass es schade wäre, wenn es in einem Kommentarbereich verschwindet.\nWas dich hier erwartet – TRUNCATE TABLE im Detail Ich habe den Austausch verglichen und mir die Kernaussagen angeschaut. Ich habe auch separat mit beiden etwas mehr getextet, und Carsten gab mir Auszüge aus einer seiner Publikationen, wo das Thema technisch behandelt wird.\nTechnisch gesehen sind sich beide einig, auch wenn sie es nicht sagen 🤣. Aber was am Ende wirklich wild war, war die Frage zum TRUNCATE TABLE Befehl:\nIch kann es vorwegnehmen. Diese Frage zur TRUNCATE TABLE Klassifizierung ist eine philosophische. Ich konnte mir basierend auf meiner Recherche eine Meinung bilden, mehr dazu später, aber grundsätzlich liegt es an jedem selbst zu entscheiden.\nDie Diskussion – TRUNCATE TABLE als DML oder DDL? Vedran Kesegic Kernposition: TRUNCATE TABLE ist DDL\n„TRUNCATE modifies internal system tables sys.sysallocunits and sys.sysrowsets. DELETE modifies indexes and stats“\n„DML writes data (rows in user tables), while DDL writes metadata (rows in system tables, data that describes other/user objects). Truncate happens to write metadata (system tables) and thus is classified as DDL.“\nTechnische Argumente für TRUNCATE TABLE als DDL\nVerwendet SCH-M (Schema Modification) Lock Modifiziert System-Metadaten-Tabellen Microsoft-Dokumentation klassifiziert es als DDL Loggt Page-Deallocations, nicht Row-Deletions Kernaussage zum TRUNCATE TABLE Befehl\n„TRUNCATE modifies internal system tables sys.sysallocunits and sys.sysrowsets. DELETE modifies indexes and stats – see attached“\nCarsten Saastamoinen-Jakobsen Kernposition: TRUNCATE TABLE ist DML\n„It is not an argument to call TRUNCATE a DDL statement because a certain lock is used! When statements are categorized, it must be based on what happens and not how a given database system solves the task.“\n„We may have to recognize that a previous error categorization should not continue to call TRUNCATE a DDL, but recognize that it is a DML.“\nLogische Argumente für TRUNCATE TABLE als DML\nDaten werden gelöscht, Struktur bleibt erhalten Keine Änderungen an der Tabellendefinition Folgt semantischen Regeln der Datenmanipulation Kann nur bestimmte Partitionen löschen (nicht alle Daten) Kernaussage zur TRUNCATE TABLE Klassifizierung\n„I say that MS is right in the documentations because they are not telling that TRUNCATE is as DDL, because they know that TRUNCATE is a DML!“\nANMERKUNG Gabriel\nIch denke, das ist wirklich etwas fragwürdig, weil die Dokumentation absolut klar zu diesem Punkt ist –\u0026gt; DDL (microsoft.com)\nZitat aus der Publikation zum TRUNCATE TABLE\n„As of version 2016, it is possible to delete only some of the data in a table with TRUNCATE, so it is even more cor­rect to call it manipulation than definition, because it is changing some of the data but not changing the structure.“\nEinigungspunkte bei TRUNCATE TABLE TRUNCATE TABLE kann in einer Transaktion zurückgerollt werden allgemeine Demo bei sqlauthority.com detaillierte Demo sqlshack.com TRUNCATE TABLE ist eine geloggte Operation TRUNCATE TABLE ist schneller als DELETE bei großen Datensätzen Beide verstehen die technische Implementierung Hauptstreitpunkt bei TRUNCATE TABLE Klassifizierungskriterien für TRUNCATE TABLE Implementierungsdetails Autorität Vendor-Dokumentation (Vedran) vs. Logische Begründung (Carsten) Perspektive zum TRUNCATE TABLE Befehl Wie es intern funktioniert (Vedran) vs. Was es funktional macht (Carsten) Meine Einschätzung zu TRUNCATE TABLE Wie du siehst, passt es technisch, aber wie betrachtest du das Ganze? Vielleicht ist es gut, dass ich nicht mit so viel Wissen vorab beladen bin wie beide, denn aus meiner Sicht ist es ziemlich klar: TRUNCATE TABLE ist DDL!!\nEntgegen Carstens Aussage, dass keine Systemtabellen geändert werden, ist Vedrans Aussage absolut korrekt. Sieh warum…\n… und natürlich weil Microsoft sagt, dass TRUNCATE TABLE DDL ist 😊 ( microsoft.com )\nUnd Partitionierung ist DML… ich weiß nicht, auch hier sind es zumindest Systemspalten, die die Partitionierung definieren.\nWie TRUNCATE TABLE funktioniert – Schritt für Schritt Ich würde gerne sagen, dass ich es einfach beschreibe, aber das ist einfach meine normale Beschreibung. Das Thema TRUNCATE TABLE ist wirklich komplex ✌️\n1 – TRUNCATE TABLE Befehl initiiert TRUNCATE TABLE dbo.MyTable; Erste Aktion: Akquiriert SCH-M (Schema Modification) Lock auf gesamte Tabelle Effekt: Tabelle ist komplett gesperrt – keine Reads, keine Writes, nichts 2 – Extents identifizieren bei TRUNCATE TABLE DEEP DIVE Extents –\u0026gt; microsoft.com SQL Server liest IAM-Pages Listet alle Extents auf, die zur Tabelle gehören Hält weiterhin: SCH-M Lock auf Tabelle 3 – Einzelne Extents bei TRUNCATE TABLE sperren Platziert X (Exclusive) Locks auf jeden Extent Das sind reguläre Data-Locks, KEINE Schema-Locks Hält jetzt: SCH-M Lock auf Tabelle (verhindert Zugriff) X Locks auf Extents (markiert sie für Deallocation) 4 – TRUNCATE TABLE Operation loggen Schreibt ins Transaction-Log: „Deallocate extents 8:8, 8:16, etc.“ Hält weiterhin: Beide Lock-Typen 5a – Bei COMMIT der TRUNCATE TABLE Operation Aktualisiert IAM – markiert Extents als frei Gibt frei alle X Locks auf Extents Gibt frei SCH-M Lock auf Tabelle Tabelle ist wieder zugänglich 5b – Bei ROLLBACK der TRUNCATE TABLE Operation Verwirft Deallocation-Marker Gibt frei alle X Locks auf Extents Gibt frei SCH-M Lock auf Tabelle Alles bleibt unverändert Warum zwei verschiedene Lock-Typen bei TRUNCATE TABLE? SCH-M Lock:\n„Niemand rührt diese Tabelle ÜBERHAUPT an“ Typisch für DDL-Operationen Verhindert sogar Metadaten-Abfragen X Locks auf Extents:\n„Diese spezifischen Datenblöcke werden modifiziert“ Typisch für Daten-Operationen Stellt sicher, dass Extents nicht von anderen Sessions wiederverwendet werden bis commit/rollback Meine bescheidene Meinung zu TRUNCATE TABLE Mit diesem Wissen ist der Fall eigentlich klar für mich, aber wie siehst du es? Tatsächlich werden hier keine Benutzerdaten manipuliert; stattdessen werden System-Level-Zuweisungen angepasst. Folglich erlaube ich mir, trotz meines neuen Halbwissens, den folgenden Vergleich zu ziehen:\n„Ich sage auch nicht, dass ich Text in einem Word-Dokument lösche, wenn ich die Festplatte schnell formatiere und nur die Block-Allocation lösche.“\nJa, ich denke das ist ein schöner Vergleich… Fall abgeschlossen, jetzt ein paar technisch interessante Aspekte und Lösungen zum TRUNCATE TABLE Befehl\nTechnischer Teil, Hacks und TRUNCATE TABLE How-To … praktisch, nicht technisch 😉\nTRUNCATE TABLE mit Survivor Table (Temporary Table) Daten, die noch benötigt werden, werden einfach in eine temporäre Tabelle verschoben und nach TRUNCATE TABLE wieder abgerufen\n-- Step 1: Create temp table with rows to keep SELECT * INTO #SurvivorRows FROM MyTable WHERE DateColumn \u0026gt;= \u0026#39;2024-01-01\u0026#39; -- Step 2: Truncate the entire table TRUNCATE TABLE MyTable -- Step 3: Re-insert survivor rows INSERT INTO MyTable SELECT * FROM #SurvivorRows -- Step 4: Clean up DROP TABLE #SurvivorRows TRUNCATE TABLE mit PARTITION Option (2016++) Seit SQL Server 2016 (jede Edition) ist es möglich, Partitionen oder Bereiche von Partitionen bei TRUNCATE TABLE zu spezifizieren\n-- Truncate specific partitions TRUNCATE TABLE MyPartitionedTable WITH (PARTITIONS (2, 4 TO 6)) -- Check partition status SELECT partition_number ,rows FROM sys.partitions WHERE OBJECT_NAME(OBJECT_ID) = \u0026#39;MyPartitionedTable\u0026#39; TRUNCATE TABLE ist immer eine Transaktion… …. und muss beim RESTORE berücksichtigt werden. Carsten hat das ganze sehr schön in seiner Publikation illustriert. Ich beschreibe es nur, das muss an dieser Stelle reichen 😝\nObwohl wir nur TRUNCATE TABLE schreiben, verwendet SQL Server trotzdem BEGIN und COMMIT TRANSACTION, was natürlich im TLog aufgezeichnet wird. Entsprechend bleiben bei einer POINT IN TIME RECOVERY die Daten in der Tabelle verfügbar, bis das TLog mit der entsprechenden TRANSACTION wiederhergestellt wird, oder die Zeit der TRUNCATE TABLE Transaktion überschritten wurde.\nDu kannst also auch die Daten wiederherstellen 👌\nTransaction Log File Daten kontinuierlich lesen mit fn_dblog und fn_dump_dblog Vedran schrieb in einem seiner Posts, dass es eine undokumentierte Funktion gibt, wo du Log-Records zur Laufzeit lesen kannst. Es gibt auch einen sehr coolen Artikel dazu auf sqlshack.com\nNICHT empfohlen für Produktion, sondern nur für Test / Bildung.\nHow to continuously read Transaction log file data directly in a SQL Server database with fn_dblog and fn_dump_dblog\nFazit zu TRUNCATE TABLE Kommen wir zu meinem eingangs erwähnten Punkt, dass all diese SQL Server Tipps von randoms hinterfragt werden sollten. Denn die Aussage, dass TRUNCATE TABLE nicht rollback-sicher ist, ist schlichtweg falsch. Der Weg zu dieser Erkenntnis war für mich lang, eingeleitet durch die Unterhaltung zwischen Vedran und Carsten. Ich habe wirklich viel links und rechts dazugelernt, was ich auch hier nochmal für die Nachwelt festhalten wollte.\nAm Ende ist es egal, ob TRUNCATE TABLE DDL oder DML ist. Im allgemeinen SQL Server Standard wird es beispielsweise als DML beschrieben, die meisten RDBMSs im Dialekt mit DDL. Wir einigen uns einfach auf DDL und gut ist. Viel spannender ist, was unter der Haube beim TRUNCATE TABLE Befehl passiert.\nBester Kommentar von Vedran 🤣\n„Or you are trying to argue with SQL Certified Master about SQL? Good luck Mr :)“\nLinks aus dem Text Transact-SQL statements – SQL Server\nTRUNCATE TABLE (Transact-SQL) – SQL Server\nSQL SERVER – Rollback TRUNCATE Command in Transaction – SQL Authority with Pinal Dave\nThe internals of SQL Truncate and SQL Delete statements\nHow to continuously read Transaction log file data directly in a SQL Server database with fn_dblog and fn_dump_dblog\nTruncate (SQL) – Wikipedia\nPages and Extents Architecture Guide – SQL Server\nFull Conversation Expand Vedran Kesegic\nIn sql server, truncate can be rolled back (if encapsulated within transaction). It is a logged operation.\nCarsten Saastamoinen-Jakobsen\nWith DELETE we can specify the WHERE clause and some or all rows can be removed. All deleted rows are logged with BEFORE IMAGE/the data values. With TRUNCATE we can delete all rows or only the rows in one or more partitions, if we have a partition table. The only information logged is the pageid. The physical removing/releasing to unused pages happens in a background task after COMMIT. No data is stored in the log, so less and faster! And it is not possible to restore to point in time because no data is logged. The pageid in the log can already have being ‚released‘ to unused pages and therefore already used to data from another object – table/index. Before COMMIT the pages is still allocated to the table and still with data. If no explicit transaction is specified the transaction is already committed!\nVedran Kesegic\n„No data is stored in the log“ and „not possible to restore to point in time“ is both incorrect for TRUNCATE. The difference is, truncate logs only deallocation of pages, which is multiple orders of magnitude less (basically insignifficant) compared to DELETE which logs data that is deleted. That is why truncate is „instant“. If you delete eg. 10GB of data, you wait for 10GB to be written to transaction log, which takes time. Truncate logs maybe 1KB for deallocation info, which is instant. If you do not want to delete all rows, you can still use TRUNCATE by storing survivor rows aside before truncating, and inserting them back after truncate. Even better, you can use SWITCH into some dummy table (even with not-partitioned tables) to remove rows quickly, and then insert survivor rows back from that dummy into original table. That is the fastest way to delete when a smaller percent of rows needs to survive.\nVedran Kesegic\nObvious difference is that truncate removes all rows from table („truncate table“) or from partition(s), when using „trancate table xy with partitions (…)“. You cannot choose which rows to delete, they all are gone. With delete you can have a WHERE clause to choose which rows to delete. Delete is more appropriate if you need to delete a small percentage of table rows (or partition rows).\nVedran Kesegic\nTruncate is a metadata operation, requires a different lock (SCH_M, schema modification lock). If also has some restrictins regarding foreign keys etc. Check the documentation for the list of limitations: https://learn.microsoft.com/en-us/sql/t-sql/statements/truncate-table-transact-sql\nCarsten Saastamoinen-Jakobsen\nIt is not an argument to call TRUNCATE a DDL statement because a certain lock is used! When statements are categorized, it must be based on what happens and not how a given database system solves the task. Data is deleted, the structure is preserved and only some data may be deleted. When one or more partitions are deleted, the condition is also well-known, but just limited. In previous versions of database systems – and perhaps still – a TRUNCATE was performed by a DROP TABLE + CREATE TABLE. Hence DDL rights. It just shows that it is problematic to categorize based on how it is performed and not based on what actually happens. If we look at the documentation for SQL Server, it is not mentioned that TRUNCATE is a DDL. We may have to recognize that a previous error categorization should not continue to call TRUNCATE a DDL, but recognize that it is a DML. We will also be free from erroneous claims about only deleting all rows, that space is not released, that the transaction cannot be rolled back, …. A DELETE operation without a user-defined transaction cannot be rolled back either! But DELETE is DML and not DDL. TRUNCATE is ‚created‘ for having af fast way of deleting rows, and extended for only deleting some of the rows – DML!!!\nVedran Kesegic\nNo, the SCH-M lock (the „king of all locks“) is not the sole reason why TRUNCATE is DDL. DML writes data (rows in user tables), while DDL writes metadata (rows in system tables, data that describes other/user objects). Truncate happens to write metadata (system tables) and thus is classified as DDL. See the doc: https://learn.microsoft.com/en-us/previous-versions/sql/sql-server-2012/ff848799(v=sql.110)\nCarsten Saastamoinen-Jakobsen\nCan you tell which data is written to the system tables that is not written when removing rows by DELETE? The only additional information is, that with TRUNCATE of all rows without specifying partitions is, that the ‚identity‘ is reset to the initial values. Removing some or all rows with specifying partitions, this value is not reset to the initial value. Empty page are handled in the same way as empty page after DELETE! All indexes are preserved, the table definition is NOT changed, ….\nVedran Kesegic\nBetter than that – you can see for yourself! The exact difference and details are present in transaction log records after you do TRUNCATE and compare that to log records that DELETE generates. Use fn_dblog() function, but only on the test system because it is undocumented and might have an impact.\nOr you are trying to say that Microsoft is wrong in documentation? If so, report it to MS so doc can be fixed. But in this case there is nothing to fix.\nOr you are trying to argue with SQL Certified Master about SQL? Good luck Mr 🙂\nCarsten Saastamoinen-Jakobsen\nI say that MS is right in the documentations because they are not telling that TRUNCATE is as DDL, because they know that TRUNCATE is a DML!. Of course there is less in the log – it is the idea wit TRUNCATE!!!!!!!! Just te functionality and te reason for implementing TRUNCATE as an alternative to DELETE. But the log is NOT the system tables!!!!! So please tell which system tables are updated as they are updated when CRAETE, ALTER and DROP but NOT updated when INSERT, DELETE or UPDATE.\nVedran Kesegic\nTRUNCATE modifies internal system tables sys.sysallocunits and sys.sysrowsets. DELETE modifies indexes and stats – see attached pictures. You could do that yourself using fn_dblog as instructed, but I did that for you so you don’t have to. If you want to know more about deep SQL Server internals you can attend one of my trainings, or trainings of other SQL Masters like Brent Ozar, Paul Randal (sqlskills), etc.\nCarsten Saastamoinen-Jakobsen\nOf course they are modified as INSERT DELETE and UPDATE modify this informations. But INSERT, DELETE and UPDATE are still only DML and not DDL. And I am not impressed of your job by showing me this information. If you was showing the same for the other DML statements it would be fine. So maybe you should modify your course material and also shows the same for the other DML statements!!!!\n","permalink":"https://dbavonnebenan.de/sql-server-truncate-vs-delete-dml-or-ddl/","summary":"Kürzlich bin ich über einen LinkedIn-Post zu TRUNCATE vs. DELETE gestolpert, wie so viele andere auch. Typischerweise posten zufällige Mitglieder einfache SQL Server Tipps, schön verpackt in Grafiken und allgemein gehalten. Obwohl das für Anfänger absolut legitim ist – da diese einfachen Einstiegspunkte vielen Neulingen helfen können zu verstehen und einen großartigen Startpunkt bieten –","title":"TRUNCATE TABLE Operationen im Detail – ROLLBACK ist doch möglich"},{"content":"Heute hatte ich wieder einen Fall auf dem Tisch, bei dem eine Fehlermeldung einer Anwendung besagte, dass auf ein Objekt in der SQL Server DB nicht zugegriffen werden kann. Der Hersteller behauptete „Verbindungsproblem“, ich sagte „DB oder zumindest Server-Problem“, Kunde sagt „früher hat alles funktioniert“.\nDie Extended Events waren schnell aufgesetzt, „Remote Procedure Call Starting“ zeigt mir ein Statement ohne vollqualifizierten Tabellennamen. Das Zielobjekt liegt in der Database unter dem db_owner Schema. Najaaa, das ist schon fragwürdig, aber OK. Warum nicht als dbo belassen?\nJedenfalls war mir das Verhalten an diesem Punkt wirklich unverständlich, da alles korrekt konfiguriert war: Default Schema des Users, db_owner auf der DB. Und der SysAdmin. Das war mir aufgefallen, aber nun ja, Entscheidung des Kunden. Sowas notiere ich mir in einer Session, ändere aber nichts, um gewachsene Abhängigkeiten nicht zu gefährden.\nNach langem Suchen gab ich fast auf, verwies an den Vendor und beendete den Call. Leider kann ich solche Sachen nicht loslassen, also feuerte ich das Lab an, baute die Umgebung nach und siehe da, fand den Fehler.\nDas Problem ist die SysAdmin-Rolle. Sie mappt den Login direkt auf den dbo-User der Database – egal ob der eigentliche User existiert oder nicht, erbt somit das Default Schema von dbo. Mindblowing, wusste ich nicht. 🙂\nSysAdmin Role inaktiv SysAdmin Role aktiv T-SQL CODE für die Screenshots DECLARE @IsSysAdmin INT SELECT @IsSysAdmin = IS_SRVROLEMEMBER(\u0026#39;sysadmin\u0026#39;) SELECT SYSTEM_USER AS CurrentLoginName; SELECT \u0026#39;Current User\u0026#39; AS Info, USER_NAME() AS Username, SCHEMA_NAME() AS CurrentSchema, CASE WHEN @IsSysAdmin = 1 THEN \u0026#39;Yes\u0026#39; ELSE \u0026#39;No\u0026#39; END AS IsSysAdmin SELECT \u0026#39;Default Schema\u0026#39; AS Info, dp.name AS Username, dp.default_schema_name AS DefaultSchema FROM sys.database_principals dp WHERE dp.name = USER_NAME() SELECT \u0026#39;DB Role Membership\u0026#39; AS Info, USER_NAME() AS Username, r.name AS RoleName FROM sys.database_principals u JOIN sys.database_role_members m ON u.principal_id = m.member_principal_id JOIN sys.database_principals r ON m.role_principal_id = r.principal_id WHERE u.name = USER_NAME() -------------------- -- select * from [customSchema].[userTable] \u0026lt;\u0026lt;\u0026lt;\u0026lt;\u0026lt; ALWAYS WORKING !!!!! select * from [userTable] Verwende immer vollqualifizierte Objektnamen, irgendwann wirst du froh sein, dass du es getan hast. Das kannst du in vielen Blogs lesen. Arbeite immer nach POLP (Principle of Least Privilege), ein App-User sollte keine SysAdmin-Rechte haben! 🙂 Gabriel, der DBAvonNebenan\n","permalink":"https://dbavonnebenan.de/sql-server-sysadmin-role-can-override-the-default-schema/","summary":"Heute hatte ich wieder einen Fall auf dem Tisch, bei dem eine Fehlermeldung einer Anwendung besagte, dass auf ein Objekt in der SQL Server DB nicht zugegriffen werden kann. Der Hersteller behauptete „Verbindungsproblem“, ich sagte „DB oder zumindest Server-Problem“, Kunde sagt „früher hat alles funktioniert“. Die Extended Events waren schnell aufgesetzt, „Remote Procedure Call Starting“","title":"SysAdmin Role ignoriert das Default User Schema – Eine verwirrende Fehlersuche"},{"content":"Zu wissen, dass SQL Server Blocking- oder Deadlock-Probleme hat, ist noch ziemlich einfach. Man merkt das normalerweise in der Anwendung und mit den richtigen Queries kann man auch die entsprechenden Blocking-Ketten anzeigen. Am einfachsten geht das mit http://whoisactive.com.\nSELECT blocking_session_id AS blocking_session, session_id AS blocked_session, wait_time / 1000.0 AS waiting_sec, wait_type AS waittype, resource_description AS ressource FROM sys.dm_os_waiting_tasks WHERE blocking_session_id IS NOT NULL ORDER BY wait_time DESC Ich hab auch noch eine eigene Entwicklung dazu, die werde ich in einem späteren Blogpost vorstellen, die meinen individuellen Anforderungen besser entspricht.\nDas Problem Jetzt kann ich AdHoc Blockings anzeigen, aber bei Deadlocks wird’s interessanter. Dafür muss die System Health Session gecheckt werden, die ist auch noch flüchtig.\n-- Query System Health Session for Deadlocks SELECT event_data.value(\u0026#39;(event/@timestamp)[1]\u0026#39;, \u0026#39;datetime2\u0026#39;) AS DeadlockDateTime, event_data.query(\u0026#39;.\u0026#39;) AS DeadlockGraph FROM ( SELECT CAST(target_data AS XML) AS target_data FROM sys.dm_xe_session_targets AS st JOIN sys.dm_xe_sessions AS s ON s.address = st.event_session_address WHERE s.name = \u0026#39;system_health\u0026#39; AND st.target_name = \u0026#39;ring_buffer\u0026#39; ) AS data CROSS APPLY target_data.nodes(\u0026#39;//RingBufferTarget/event[@name=\u0026#34;xml_deadlock_report\u0026#34;]\u0026#39;) AS XEventData(event_data) ORDER BY DeadlockDateTime DESC; Dieses Problem hatte ich bei einem Kunden, der extrem mit Deadlocks in einer 3rd Party Anwendung zu kämpfen hatte, aber der Support war bisschen… sagen wir mal zurückhaltend. 😉\nWir mussten denen alles transparent melden, damit die anfangen eine Lösung zu finden. Query-Resultsets kann man natürlich als transparent betrachten, wenn man sie versteht oder verstehen will. Leider sind die XML von Health Sessions oder Extended Events nicht gerade dafür berühmt, lesbar zu sein. Der Kunde wollte aber einfach nur, dass das Problem gelöst wird.\nAlso haben wir gemeinsam eine Reporting-Lösung entwickelt.\nDie Idee Mit Extended Events hab ich XML-Daten und mit PowerShell kann ich XML parsen wie ich will, auch zu einem Report meiner Wahl.\nDas Ziel Wir wollten eine Möglichkeit, abseits von SQL Server Resultsets, Anwendungsprobleme mit Anomalien in den SQL Server Metriken zu überlagern, um schnell Lösungen herbeizuführen.\nIn der Woche nach dem Livegang der Lösung gab’s viele, viele „Aha“-Momente. Von falsch konfigurierten ERP-Parametern bis hin zu schlechtem Transaction-Handling.\nDer Weg Persistente Daten Das Wichtigste ist, Blocking Session und Deadlock Events persistent zu speichern. Das geht perfekt mit Extended Events. Dafür gibt’s zwei Bereiche:\n-- SNIPPET!! ADD EVENT sqlserver.blocked_process_report( ACTION(sqlserver.client_app_name, sqlserver.client_hostname, sqlserver.database_name) ), ADD EVENT sqlserver.xml_deadlock_report( ACTION(sqlserver.client_app_name, sqlserver.client_hostname, sqlserver.database_name) ) Das ganze wird in einem eigenen Extended Event konfiguriert und die Aufzeichnungen laufen bereits. Fast! Wir müssen noch SQL Server konfigurieren, damit Blocked Process als Extended Events behandelt werden.\nEXEC sp_configure \u0026#39;show advanced options\u0026#39;, 1; GO RECONFIGURE; GO EXEC sp_configure \u0026#39;blocked process threshold\u0026#39;, \u0026#39;5\u0026#39;; -- 5 Sekunden RECONFIGURE GO Daten auslesen 100% PowerShell Nachdem die Events geloggt werden, müssen sie ausgewertet werden. Was mir sofort eingefallen ist, waren die dbatools mit Read-DbaXEFile. Das Problem ist, dass die aktuell geschriebene Datei damit nicht gelesen werden kann. Du kannst dir vorstellen, dass Blocking- und Deadlock-Events nicht in solchen Massen auftreten, dass dutzende File-Rotationen innerhalb von 24h durchgeführt werden. Falls doch, hast du definitiv ein anderes Problem als es nur zu reporten. Also haben wir den Umweg über SQL Server genommen, da auch hier die aktuelle Datei gelesen werden kann.\nPowerShell + TSql XML mit Queries zu lesen, fällt mir immer noch sehr schwer, aber DANKE an Brent Ozar, uns allen bekannt, für die grundlegende Query, auf der ich aufbauen konnte. Zumindest hatte ich jetzt ein Resultset zur Orientierung und ein separates XML für jedes Event im Log.\n-- Snippet select * FROM sys.fn_xe_file_target_read_file (\u0026#39;C:\\temp\\XEventSessions\\blocked_process*.xel\u0026#39;, \u0026#39;C:\\temp\\XEventSessions\\blocked_process*.xem\u0026#39;, null, null) CROSS APPLY (SELECT CAST(event_data AS XML) AS event_data) as xevents Finalisierung mit PowerShell Da ich endlich mein XML-Event hatte, konnte ich es mit PowerShell parsen, transformieren und letztendlich in einen schönen Text-Report verpacken.\nSql Server Deadlock Analysis | Event Time: 2025-04-08T11:16:07.447 ================================================================================ SQL STATEMENTS INVOLVED -------------------------------------------------------------------------------- Process ID: process261b00cfc28 SPID: 643 Database: DATABASENAME Query: **DETAILED QUERY** ---------------------------------------- Process ID: process258294fbc28 SPID: 650 Database: DATABASENAME Query: **DETAILED QUERY** ---------------------------------------- VICTIM LIST -------------------------------------------------------------------------------- Process ID: process261b00cfc28 SPID: 643 Database: DATABASENAME PROCESS LIST -------------------------------------------------------------------------------- Process ID: process261b00cfc28 SPID: 643 Isolation Level: read uncommitted (1) Logical Reads: 700 Wait Resource: KEY: 6:72058005407662080 (fb04e1bc7788) Wait Time (ms): 2247 Transaction: user_transaction Last Transaction Started: 2025-04-08T11:16:07.447 Client: \u0026#39;dbserver_dll \u0026amp;lt;ID@APPSERVER:34784\u0026gt;\u0026#39; Hostname: APPSERVER User: USERNAME EXECUTED SQL STATEMENT ---------------------------------------- **DETAILED QUERY** Process Details ================================================================================ Process ID: process258294fbc28 SPID: 650 Isolation Level: read uncommitted (1) Logical Reads: 1904 Wait Resource: KEY: 6:72057996178358272 (2a9726d2d061) Wait Time (ms): 2278 Transaction: user_transaction Last Transaction Started: 2025-04-08T11:16:07.330 Client: \u0026#39;dbserver_dll \u0026amp;lt;ID@APPSERVER:11664\u0026gt;\u0026#39; Hostname: APPSERVER User: USERNAME EXECUTED SQL STATEMENT ---------------------------------------- **DETAILED QUERY** Process Details ================================================================================ RESOURCE LIST -------------------------------------------------------------------------------- Resource: Type: keylock Database: 6 Object: DATABASENAME.dbo.tcprmp300100 Index: Itcprmp300100_1a Lock Mode: X HOBT ID: 72058005407662080 Associated Object ID: 72058005407662080 Owners: Process ID: process258294fbc28, Mode: X Waiting Processes: Process ID: process261b00cfc28, Mode: U, Request Type: wait ================================================================================ Resource: Type: keylock Database: 6 Object: DATABASENAME.dbo.tcprrp011100 Index: Itcprrp011100_1a Lock Mode: X HOBT ID: 72057996178358272 Associated Object ID: 72057996178358272 Owners: Process ID: process261b00cfc28, Mode: X Waiting Processes: Process ID: process258294fbc28, Mode: U, Request Type: wait ================================================================================ Umsetzung Es wurde gewünscht, die Ergebnisse in den Daily Report zu integrieren, den wir bereits mit PowerShell umgesetzt hatten. Jetzt ist es nicht geil, potenziell jeden Morgen 200 Textdateien an eine E-Mail zu hängen, deshalb gibt das PowerShell-Script eine Tabelle zurück, die zeigt, wie Blocks und Locks in Zeitraum X aufgetreten sind, und bei Bedarf kann man proaktiv die Ordnerstruktur checken.\nFür den dramatischen Effekt und schnellen Überblick wird auch noch eine Excel-Datei generiert. In diesem Beispiel gab’s einen schönen Kollateralfund, dass die DWH-Jobs massive Probleme hatten 🙂\nUnd schon hatten wir ein paar Reports, die wir dem Vendor in die Hand drücken konnten, und dann ging’s sehr schnell.\nDie Ordnerstruktur _report/ ├── text_reports/ │ └── YYYY/ │ └── MM/ │ └── DD/ │ ├── 20231120_123456_dbname_blocked.txt │ ├── 20231120_123456_dbname_blocked.xml │ └── 20231120_123456_dbname_deadlock.txt └── excel_reports/ └── BlockReport_20231120_123456.xlsx Leider erlebe ich immer wieder, dass Anwendungsvendoren denken, ihre Kunden sind zu blöd und können die Anwendung nicht bedienen. Hört auf damit und glaubt euren Kunden manchmal auch ohne 101% Daten, die man nur sammeln kann, wenn man bereits Sachkenntnis hat.\nRepository ansehen GitHub – gabrielkoehl/get-snapBlockEvents: SQL Server Block Event Reporter that automatically captures, analyzes, and visualizes blocking events and deadlocks using PowerShell and Extended Events, providing detailed text reports and aggregated Excel summaries.\nDas Script hat verschiedene Parameter und Optionen, Details stehen in der README.MD. Falls du Fragen hast, lass sie in den Kommentaren oder kontaktier mich.\nAnderes Erik Darling hat auch eine Lösung entwickelt, um Extended Events lesbar zu machen, falls andere Ansätze gebraucht werden. (sp_HumanEvents)\nGabriel, der DBAvonNebenan\n","permalink":"https://dbavonnebenan.de/reporting-sql-server-blocks/","summary":"Zu wissen, dass SQL Server Blocking- oder Deadlock-Probleme hat, ist noch ziemlich einfach. Man merkt das normalerweise in der Anwendung und mit den richtigen Queries kann man auch die entsprechenden Blocking-Ketten anzeigen. Am einfachsten geht das mit \u003ca href=\"http://whoisactive.com\"\u003ehttp://whoisactive.com\u003c/a\u003e. Ich hab auch noch eine eigene Entwicklung dazu, die werde ich in einem späteren Blogpost vorstellen, die","title":"Dokumentation von Blocks und Deadlocks – Wenn der 3rd-Party Vendor Beweise fordert"},{"content":"Über mich Ich bin Gabriel Köhl – SQL Server DBA und PowerShell-Enthusiast. Nach Jahren in der Inhouse-IT, wo alles zunehmend vorhersehbar wurde, bin ich Anfang 2021 ins Consulting gewechselt. Hier gibt es täglich neue Herausforderungen in unterschiedlichen Umgebungen.\nWas ich mache SQL Server Administration, Performance Tuning, Migrationen – das komplette Spektrum. PowerShell für alles, was sich automatisieren lässt. Und ja, manchmal entstehen dabei auch neue Probleme, die es dann zu lösen gilt.\nWarum dieser Blog? Die Community lebt vom Teilen. Tools wie dbatools oder sp_Blitz haben mir schon oft weitergeholfen. Jetzt gebe ich etwas zurück – mit praxisnahen Lösungen statt theoretischen Abhandlungen.\nTrotz der Qualität dieser großen Lösungen nutze ich für spezielle Anforderungen jenseits der Standard-Administration oft lieber eigene Ansätze. sp_Blitz ist hervorragend, keine Frage, aber für bestimmte Fälle brauche ich von den hundert Prozent Metriken oft nur fünf Prozent – diese dann aber mit mehr Tiefe. Ähnlich bei dbatools: Der Overhead ist manchmal zu groß, dann schreibe ich lieber selbst. So bleibt auch deutlich mehr Wissen hängen.\nWas dich erwartet Echte Geschichten aus dem DBA-Alltag. Keine perfekten Lösungen, sondern solche, die funktionieren. Manchmal elegant, manchmal pragmatisch zusammengebaut – aber sie erledigen ihren Job.\nFalls du Accidental DBA geworden bist oder einfach pragmatische Ansätze suchst: Hier bist du richtig.\nKI und so Natürlich nutze ich KI-Tools. Sie machen mich effizienter. Aber bis neues Wissen wirklich sitzt und produktionstauglich ist, braucht es Zeit. Erfahrung schlägt nach wie vor Hype. Die Artikel werden übrigens auch mit KI ins Englische übersetzt. 🙂\nKontakt Fragen, Feedback oder einfach Fachsimpeln? LinkedIn oder GitHub – ich höre gern von dir.\nDu hast SQL Server Herausforderungen im Business-Umfeld oder möchtest Prozesse automatisieren? Schau gern bei Opitz Consulting vorbei – dort bin ich buchbar.\n","permalink":"https://dbavonnebenan.de/about/","summary":"\u003ch2 id=\"über-mich\"\u003eÜber mich\u003c/h2\u003e\n\u003cp\u003eIch bin Gabriel Köhl – SQL Server DBA und PowerShell-Enthusiast. Nach Jahren in der Inhouse-IT, wo alles zunehmend vorhersehbar wurde, bin ich Anfang 2021 ins Consulting gewechselt. Hier gibt es täglich neue Herausforderungen in unterschiedlichen Umgebungen.\u003c/p\u003e\n\u003ch2 id=\"was-ich-mache\"\u003eWas ich mache\u003c/h2\u003e\n\u003cp\u003eSQL Server Administration, Performance Tuning, Migrationen – das komplette Spektrum. PowerShell für alles, was sich automatisieren lässt. Und ja, manchmal entstehen dabei auch neue Probleme, die es dann zu lösen gilt.\u003c/p\u003e","title":"About Me – Gabriel Köhl"},{"content":"Allgemeines\nDiese Website wird als privater Blog ohne kommerzielle Absichten betrieben. Der Schutz deiner Daten ist mir wichtig. Verantwortlich im Sinne der DSGVO ist der im Impressum genannte Betreiber. Die Website ist eine statische Seite. Es gibt keine Kommentarfunktion, kein Kontaktformular, keinen Newsletter, kein Tracking und keine Analyse-Werkzeuge. Hosting\nDie Website wird über GitHub Pages bereitgestellt. Anbieter ist GitHub Inc., 88 Colin P. Kelly Jr. Street, San Francisco, CA 94107, USA. Beim Aufruf der Seiten verarbeitet GitHub technisch notwendige Zugriffsdaten, insbesondere deine IP-Adresse, Datum und Uhrzeit des Abrufs, die aufgerufene Seite sowie Browser- und Systemangaben. Das dient der Auslieferung und der Sicherheit des Dienstes. Dabei können Daten in die USA übermittelt werden. GitHub ist nach dem EU-US Data Privacy Framework zertifiziert. Ich selbst habe keinen Zugriff auf diese Zugriffsdaten. Art, Umfang und Speicherdauer der Verarbeitung durch GitHub beschreibt die Datenschutzerklärung von GitHub. Cookies und lokale Speicherung\nDiese Website setzt keine Cookies. Im lokalen Speicher deines Browsers (Local Storage) werden nur die von dir gewählte Darstellung (hell oder dunkel) und die Scrollposition des Menüs abgelegt. Diese Angaben verlassen deinen Browser nicht und werden nicht an mich oder Dritte übertragen. Du kannst sie jederzeit über die Einstellungen deines Browsers löschen. Die Suche auf dieser Website läuft vollständig in deinem Browser. Suchbegriffe werden nicht übertragen. Externe Inhalte und Links\nDie Website lädt keine Inhalte von Drittanbietern nach, also keine externen Schriftarten, Skripte, Videos oder Social-Media-Plugins. Links auf externe Seiten (zum Beispiel GitHub oder LinkedIn) sind einfache Verweise. Erst wenn du einen solchen Link anklickst, werden Daten an den jeweiligen Anbieter übertragen. Dafür gilt dessen Datenschutzerklärung. Rechtsgrundlage\nBerechtigtes Interesse am sicheren und funktionsfähigen Betrieb der Website (Art. 6 Abs. 1 lit. f DSGVO). Die lokale Speicherung der Darstellungseinstellung ist für die von dir ausdrücklich gewünschte Funktion erforderlich (§ 25 Abs. 2 Nr. 2 TDDDG). Deine Rechte\nDu hast das Recht auf Auskunft, Berichtigung, Löschung, Einschränkung der Verarbeitung, Datenübertragbarkeit und Widerspruch (Art. 15 bis 21 DSGVO). Kontakt über die im Impressum genannten Wege. Du hast außerdem das Recht, dich bei einer Datenschutz-Aufsichtsbehörde zu beschweren (Art. 77 DSGVO). ","permalink":"https://dbavonnebenan.de/privacy-policy/","summary":"\u003cp\u003e\u003cstrong\u003eAllgemeines\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eDiese Website wird als privater Blog ohne kommerzielle Absichten betrieben. Der Schutz deiner Daten ist mir wichtig.\u003c/li\u003e\n\u003cli\u003eVerantwortlich im Sinne der DSGVO ist der im \u003ca href=\"/impressum/\"\u003eImpressum\u003c/a\u003e genannte Betreiber.\u003c/li\u003e\n\u003cli\u003eDie Website ist eine statische Seite. Es gibt keine Kommentarfunktion, kein Kontaktformular, keinen Newsletter, kein Tracking und keine Analyse-Werkzeuge.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eHosting\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eDie Website wird über GitHub Pages bereitgestellt. Anbieter ist GitHub Inc., 88 Colin P. Kelly Jr. Street, San Francisco, CA 94107, USA.\u003c/li\u003e\n\u003cli\u003eBeim Aufruf der Seiten verarbeitet GitHub technisch notwendige Zugriffsdaten, insbesondere deine IP-Adresse, Datum und Uhrzeit des Abrufs, die aufgerufene Seite sowie Browser- und Systemangaben. Das dient der Auslieferung und der Sicherheit des Dienstes.\u003c/li\u003e\n\u003cli\u003eDabei können Daten in die USA übermittelt werden. GitHub ist nach dem EU-US Data Privacy Framework zertifiziert.\u003c/li\u003e\n\u003cli\u003eIch selbst habe keinen Zugriff auf diese Zugriffsdaten. Art, Umfang und Speicherdauer der Verarbeitung durch GitHub beschreibt die \u003ca href=\"https://docs.github.com/de/site-policy/privacy-policies/github-general-privacy-statement\"\u003eDatenschutzerklärung von GitHub\u003c/a\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eCookies und lokale Speicherung\u003c/strong\u003e\u003c/p\u003e","title":"Datenschutzerklärung"}]