SQL Server Lastsimulator – UB.SimSQL für Windows

Realistische OLTP-, OLAP- und Blocking-Last per Knopfdruck. Mit eigener Datenbank, sechs Szenarien und Live-Auswertung. Lokal. Ohne Cloud. Ohne Abo.

 

Was UB.SimSQL macht

Wer die Performance einer SQL-Server-Umgebung wirklich verstehen will, kommt um eines nicht herum: Last erzeugen. Nicht synthetisches Bench-Marking-Geknöddel mit TPC-C-Tabellen, die mit deiner tatsächlichen Welt nichts zu tun haben. Sondern Lastmuster, die zu realen Workload-Situationen passen – und die du gezielt steuern kannst.

Genau dafür ist UB.SimSQL gebaut: ein Lastsimulator für SQL Server, der dir auf Knopfdruck OLTP-Last erzeugt, Reporting-Queries laufen lässt, gezielt Blocking provoziert, Deadlocks reproduziert oder Memory Pressure aufbaut. Mit eigener mitgelieferter Datenbank, realistischer Datenstruktur und vorkonfigurierten Szenarien – also nichts, was du selbst aufsetzen müsstest, bevor du loslegen kannst.

Dazu eine Live-Auswertung in Echtzeit, automatische Empfehlungen auf Basis der erkannten Wait-Type-Muster und ein Vergleichs-Modus, der bis zu vier Läufe nebeneinanderstellt. Plus DOCX-Reports für den Kunden.

 

→ Anfrage senden · Live-Demo vereinbaren

 

 

Der Workflow im Überblick

Von der Verbindung bis zum exportierten Bericht – sechs klar getrennte Schritte:

 

1 Verbinden SQL-Server-Verbindungsprofil wählen	2 Datenbank generieren Größe S/M/L/XL auswählen, Daten werden erzeugt	3 Szenario wählen OLTP, OLAP, Blocking, Deadlocks, Memory, Mixed
4 Last laufen lassen Live-Charts, Wait Types, aktive Sessions	5 Empfehlungen prüfen Regelbasierte Hinweise in Echtzeit	6 Report exportieren DOCX-Bericht mit Charts und Befunden

 

 

Warum ein neues Tool?

Wer SQL Server unter Last testen will, hat bisher folgende Optionen:

ostress / RML Utilities (Microsoft) – Kommandozeilentool ohne GUI, für Spezialisten. Konfiguration per Parameter, Ergebnisse nur in der Konsole. Funktioniert, wenn du genau weißt, was du tust.

HammerDB (Open Source) – Leistungsfähig, aber mit erheblicher Einarbeitungszeit. Arbeitet mit TPC-C/TPC-H-Benchmarks, die mit realen Unternehmensworkloads wenig gemein haben.

SQLQueryStress (Open Source) – Hat eine einfache GUI, erreicht aber bei hohem Durchsatz Grenzen und bietet keine vordefinierten Szenarien.

Das grundlegende Problem aller verfügbaren Tools: Du musst Datenbank und Queries selbst mitbringen. Die Tools sind reine Ausführungsrahmen. Wer sie produktiv einsetzen will, plant einen halben Tag Vorbereitung ein, bevor der erste Lasttest läuft.

UB.SimSQL geht einen anderen Weg: Datenbank, Datenstruktur, Queries und Szenarien sind alle eingebaut. Du verbindest dich mit deinem SQL Server, wählst eine Datenbank-Größe (S/M/L/XL), startest die Datengenerierung – und bist nach 5 bis 30 Minuten startklar. Danach drückst du auf einen Button, und der Lasttest läuft.

 

Die sechs Szenarien

UB.SimSQL bringt sechs vordefinierte Szenarien mit, die ohne Vorkonfiguration sofort einsatzbereit sind. Jedes Szenario hat seine eigenen Parameter, mit denen du Intensität und Verhalten fein steuerst.

 

OLTP-Last

Parallele Lese- und Schreibzugriffe mit realistischer Datenmischung. Kurze Transaktionen, hohe Parallelität, einstellbare Anzahl virtueller User und TPS-Ziel. Intensität stufenlos von Leicht bis Schwer regelbar.

Typischer Einsatz: Hardware-Sizing, Kapazitätsplanung, Validierung von Storage-Konfigurationen.

Reporting-Last (OLAP)

Schwere Aggregations-Queries mit mehreren JOINs, Datumsfiltern und großen Result Sets. Simuliert Reporting-Benutzer, die parallel zur produktiven OLTP-Last laufen – der klassische „warum ist der Server plötzlich langsam“-Fall.

Typischer Einsatz: Trennung OLTP/Reporting, Always-On-Read-Replica-Auslegung, Index-Strategie für gemischte Workloads.

Blocking

Erzeugt gezielt Blocking Chains mit konfigurierbarer Sperrdauer. Lang laufende Transaktionen, die absichtlich Locks halten und nachfolgende Transaktionen ausbremsen. Perfekt, um Blocking-Verhalten in einer kontrollierten Umgebung sichtbar zu machen.

Typischer Einsatz: Diagnose-Demonstration, Schulung, Test von Blocking-Monitoring-Lösungen.

Deadlocks

Provoziert reproduzierbare Deadlocks durch eine klassische Kreuz-Update-Sequenz. Zwei Worker-Threads sperren Ressourcen in unterschiedlicher Reihenfolge und blockieren sich gegenseitig.

Typischer Einsatz: Deadlock-Analyse, Auswertung von Deadlock-Graphen, Validierung von Isolations-Level-Änderungen.

Memory Pressure

Belastet den Buffer Pool durch große Result Sets ohne Paging. Zeigt Memory-Engpässe und Page-Life-Expectancy-Probleme auf, die unter normaler Last nicht sichtbar sind.

Typischer Einsatz: Infrastruktur-Tests, Auslegung von max server memory, Bewertung von Buffer-Pool-Verhalten unter Druck.

Mixed Workload

Kombiniert alle Szenarien mit konfigurierbarer Gewichtung. Simuliert realen Tagesbetrieb mit gemischten Zugriffsmustern – 80 Prozent OLTP, 20 Prozent Reporting, gelegentliche Blocking-Episoden, eine Prise Chaos.

Typischer Einsatz: Realistische Lasttests vor Produktivsetzung, Validierung von Performance-Optimierungen unter realen Bedingungen.

 

 

Die Oberfläche

Die Oberfläche von UB.SimSQL ist nach dem Prinzip der progressiven Erweiterung aufgebaut: Der Einsteiger findet alles, was er für den ersten Lauf braucht, im ersten Tab. Wer mehr will, geht weiter.

 

Tab 1 – Simulation

Der Hauptbildschirm. Verbindungsprofil wählen, Szenario aussuchen, virtuelle User einstellen, Start drücken. In der Mitte laufen drei Live-Charts: TPS-Verlauf, aktive Sessions, Top-3-Wait-Types. Rechts aktualisieren sich alle 10 Sekunden Empfehlungen mit Ampel-Farben. Unten ein Annotation-Knopf, mit dem du markante Stellen während des Laufs taggen kannst – die landen später im Report.

Tab 2 – Vergleich

Bis zu vier Läufe nebeneinanderstellen. Kennzahlen-Tabelle, Delta-Spalten mit Farbcodierung, automatisches Fazit in Klartext. Direkter Export als DOCX-Bericht für den Kunden.

Tab 3 – Recorder

Zeichnet eine bestehende Workload auf einem Produktiv-System auf (nur Hashes, kein Query-Text – DSGVO-konform). Spielt den aufgezeichneten Lastmix später auf einem Test-System ab, mit optionalem Skalierungsfaktor. So bekommst du echte Produktiv-Last auf deinem Test-Server – ohne Risiko.

Tab 4 – Testreihen („Lights Out“)

Mehrstufige Lastläufe definieren und nacheinander automatisch abarbeiten lassen. Beispiel-Testreihe „Kapazitätsrampe“: OLTP mit 10 / 25 / 50 / 100 / 200 Usern, jeweils 5 Minuten, Pausen dazwischen. Nach Abschluss: TPS-Kurve über User-Anzahl als einzelnes Overlay-Chart. Ideal für Skalierungs-Analysen.

Plus Zeitplaner: Geplante Läufe oder Testreihen einmalig oder wiederkehrend ausführen.

Tab 5 – Verlauf & Reports

Alle bisherigen Läufe in einem DataGrid: Datum, Szenario, Größe, Dauer, Peak TPS, Peak Sessions, Deadlocks, Tags. Doppelklick öffnet das Detail-Fenster mit allen Charts. Drei Report-Typen pro Lauf: Executive Summary in Klartext für die Geschäftsführung, Vollständiger Report als DOCX mit allen Charts, Empfehlungen als priorisierte Liste.

Tab 6 – Plugins

Geladene Plugins mit Status. Eigene Szenarien lassen sich als Plugins ergänzen – über eine MEF-basierte Schnittstelle. So erweiterst du UB.SimSQL um deine eigenen, kundenspezifischen Lastmuster, ohne den Kern zu ändern.

 

 

Die Empfehlungs-Engine

UB.SimSQL beobachtet während eines Laufs kontinuierlich die DMV-Daten der getesteten Instanz und gleicht sie mit einer regelbasierten Empfehlungs-Engine ab. Das Ziel: Du sollst nicht nur sehen, was passiert, sondern auch verstehen, warum – und was du als Nächstes tun kannst.

Beispiel-Regeln aus der Engine:

• PAGEIOLATCH_SH > 30 Prozent der Waits → Storage-Engpass auf Datendateien, Latenzen prüfen, Index-Strategie überdenken.
• LCK_M_X > 20 Prozent der Waits → Blocking-Problem, Transaktions-Längen prüfen, Isolation Level evaluieren.
• CXPACKET > 25 Prozent der Waits → Parallelismus-Konfiguration prüfen, MAXDOP und Cost Threshold for Parallelism evaluieren.
• Deadlocks > 5 pro Minute → kritisch, Code-Review der beteiligten Transaktionen erforderlich.
• TPS-Einbruch > 30 Prozent ohne Lasterhöhung → kritisch, Memory-Pressure oder externes Event prüfen.

 

Die Empfehlungen sind nach Schweregrad farbig markiert (Info / Warning / Critical) und erscheinen in der Sidebar des Simulation-Tabs in Echtzeit. Im Report werden sie als priorisierte Liste übernommen.

 

Wichtig: Die Engine ersetzt keinen Beratungsdialog. Sie ist ein systematischer Filter, der dir die naheliegenden Problemmuster aus dem Wait-Type-Profil herausarbeitet und einen Startpunkt für die tiefere Analyse liefert.

 

 

 

Architektur und Zusammenspiel

UB.SimSQL ist eine Windows-Anwendung, die als Lasterzeuger gegen eine separate SQL-Server-Instanz arbeitet. Die zu testende Instanz bleibt unangetastet – UB.SimSQL erzeugt Last und liest DMVs, mehr nicht. Optional kannst du parallel das PowerShell-Skript Collect-SqlPerf.ps1 starten, das eine Bestandsaufnahme der Instanz liefert.

 

UB.SimSQL Anwendung (Windows) WPF · MVVM · LiveCharts · Empfehlungs-Engine · Plugin-System

↓

Microsoft.Data.SqlClient Verbindung zur SQL-Server-Instanz · DMV-Auswertung in Echtzeit

↓

Ziel-SQL-Server (Test/Sandbox) Mitgelieferte Datenbank (S/M/L/XL): Customers · Products · Orders · OrderItems · Inventory · AuditLog

↓

Optional: Collect-SqlPerf.ps1 (PowerShell) Parallele Bestandsaufnahme der Instanz: Konfiguration · Wait Stats · Index-Daten · Best Practices

 

 

Technische Eckdaten

• Plattform: Windows 10/11, Windows Server 2019+
• Framework: .NET 10, C# 13
• Oberfläche: WPF mit MVVM-Architektur (CommunityToolkit.Mvvm)
• Visualisierung: LiveCharts in Echtzeit
• Datenbank-Zugriff: Microsoft.Data.SqlClient
• Lokale Persistenz: SQLite (Verlauf, Konfigurationen, Empfehlungen)
• Erweiterbar: Plugin-System via MEF
• Verteilung: Lokale Installation, ohne Cloud-Abhängigkeit

 

Datenbank-Größen: S (ca. 100 MB), M (ca. 1 GB), L (ca. 10 GB), XL (ca. 100 GB) – je nach Szenario und gewünschter Last-Tiefe.

Datengenerierung: Realistische Stammdaten (Bogus-Library), Batch-Inserts via SqlBulkCopy, 1 Million Datensätze in unter 30 Sekunden.

DSGVO-Konformität: Bauartbedingt. Alle Daten bleiben lokal. Keine Cloud-Verbindung. Keine externe API. Keine Datenübertragung an Dritte. Auch der Recorder erfasst nur Query-Hashes, niemals Query-Text oder Daten.

 

 

Integration mit Collect-SqlPerf.ps1

UB.SimSQL ist so gebaut, dass es nahtlos mit dem PowerShell-Skript Collect-SqlPerf.ps1 zusammenarbeitet – dem Werkzeug, das ich seit Jahren in jeder Performance-Analyse einsetze.

Beim Start einer Simulation kann UB.SimSQL das Skript automatisch parallel auf der Ziel-Instanz starten. Während die Last läuft, sammelt das Skript Konfiguration, Wait Statistics, Index-Daten und Best-Practices-Auffälligkeiten ein. Nach Beendigung des Laufs hast du zwei Datensätze: das, was UB.SimSQL gemessen hat – und das, was Collect-SqlPerf.ps1 als Bestandsaufnahme der Instanz geliefert hat.

Damit wird aus „Last erzeugen“ ein vollständiger Performance-Analyse-Workflow: Last generieren → messen → bewerten → berichten, alles in einer Tool-Kette.

 

 

Typische Einsatzszenarien

Hardware-Sizing vor der Beschaffung. Du planst einen neuen SQL-Server. Wie viele Cores brauchst du wirklich? Reichen 64 GB RAM? Ist NVMe nötig oder reichen SATA-SSDs? Mit UB.SimSQL spielst du die geplante Last auf einem Test-Server in verschiedenen Hardware-Konfigurationen durch und siehst, wo die Grenzen liegen.

Validierung nach Konfigurationsänderungen. Du hast MAXDOP geändert, eine neue Indexstrategie umgesetzt oder den Buffer Pool angepasst. War’s wirksam? Mit dem Vergleichs-Modus stellst du Vorher- und Nachher-Lauf nebeneinander und siehst die Auswirkungen in Zahlen.

Test von HA-Konfigurationen. Always-On-Failover unter Last testen, Read-Replica-Verhalten validieren, Latenz-Effekte unter synchroner Replikation messen. UB.SimSQL liefert die nötige Last in reproduzierbarer Form.

Schulung und Demo. In Workshops und Kundengesprächen Probleme wie Blocking, Deadlocks oder Memory Pressure auf Knopfdruck zeigen – statt sie mühsam zu erklären. Das Tool hat genau dafür eigene Szenarien.

Vor Produktivsetzung. Du hast eine neue Anwendung, einen neuen Workload oder ein Migrationsprojekt. Bevor’s auf den Produktiv-Server geht: Lasttest unter realistischen Bedingungen. Mit Recorder kannst du echte Produktivlast aufzeichnen und auf das Test-System spielen.

 

 

Nicht im Lieferumfang – bewusst

Damit es klar ist: UB.SimSQL ist kein Performance-Monitor für Produktivumgebungen. Es ist kein APM-Tool und kein Ersatz für SolarWinds, Redgate Monitor oder vergleichbare Lösungen. Es ist kein Reporting-Tool für Management-Dashboards.

UB.SimSQL ist ein Lastsimulator für Tests, Demos und Validierung. In dieser Rolle macht es genau einen Job, und den richtig.

Was es nicht hat und auch nicht haben wird:

• Cloud-Anbindung
• SaaS-Modus
• Telemetrie-Übertragung
• Abo-Modell
• Customer Success Manager
• Webinar-Einladungen

 

 

Interesse?

UB.SimSQL ist einsatzbereit. Wenn du Interesse an einer Live-Demo hast, einen konkreten Anwendungsfall besprechen willst oder das Tool in deinem Unternehmen einsetzen möchtest – sprich mich an.

→ Anfrage senden

Wer Updates zu UB.SimSQL und meinen anderen Werkzeugen verfolgen will, abonniert am besten das Consulting Briefing.

→ Consulting Briefing abonnieren

 

 

Mehr zum Thema SQL Server

Beratungsangebote, Schulungen, Bücher und Fachartikel zum Thema SQL Server findest du auf der SQL-Server-Übersichtsseite.

→ Zur SQL Server Übersicht