SH

Sascha Hess xenosystems.de - IT-Consulting & Data Management

www.xenosystems.de

 

	NOTFALL-KIT – SQL SERVER 2026
	SQL Server
	Performance Tuning
	Sofort-Lösungen für mittelständische Umgebungen

WAS SIE IN DIESEM KIT ERHALTEN:

1

10 Performance-Killer Erkannt & behoben in unter 30 Min - mit fertigen SQL-Skripten

 

2

Schnell-Diagnose 3 DMV-Skripte lokalisieren das Problem in unter 5 Minuten

 

3

30-Tage-Checkliste Strukturierter Plan für 40-80 % Geschwindigkeitsgewinn

 

4

SQL Server 2025 Fallen Upgrade-Probleme & offizielle Microsoft-Workarounds

 

5

Automatisierung Backups, Index-Rebuild, Statistics - dauerhaft automatisiert

 

 

 

Alle Skripte und Empfehlungen wurden sorgfältig erarbeitet. Da jede Umgebung individuell ist, übernimmt der Autor keinerlei Haftung für Datenverlust, Systemausfälle oder sonstige Schäden. Erstellen Sie vor jeder Änderung ein vollständiges Backup.

 

 

Die genannten Performance-Gewinne (typisch 40-80 %) sind Erfahrungswerte aus realen KMU-Umgebungen und keine verbindliche Zusicherung. Tatsächliche Ergebnisse können je nach Hardware, Datenvolumen und Anwendungsarchitektur abweichen.

 

 

Die Inhalte beziehen sich auf SQL Server 2022 (16.x) und SQL Server 2025 (17.x), Stand März 2026. Durch künftige Updates von Microsoft können Abweichungen entstehen.

 

 

Dieses Dokument ist für den persönlichen oder betriebsinternen Gebrauch des Käufers lizenziert. Weiterverkauf, Weitergabe an Dritte und öffentliche Veröffentlichung sind ohne schriftliche Genehmigung nicht gestattet.

 

 

Dieses Kit ist ein unabhängiges Werk und steht in keinerlei Verbindung zur Microsoft Corporation. SQL Server ist eine eingetragene Marke der Microsoft Corporation.

 

Eine ausführliche Version dieses Haftungsausschlusses befindet sich am Ende dieses Dokuments.

 

 

 

01  Einleitung

Warum Ihr SQL-Server 2026 plötzlich langsamer ist

02  Die 10 Performance-Killer

Erkennen & beheben in unter 30 Minuten

03  Schnell-Diagnose

3 DMV-Skripte in unter 5 Minuten

04  Index-Optimierung

Der größte Hebel — Fragmentierung & Missing Indexes

05  Query-Tuning

Von schlecht zu blitzschnell

06  Neue Fallen 2026

SQL Server 2025 Upgrade-Probleme & Workarounds

07  Server- & Instanz-Tuning

Memory, TempDB, Resource Governor, Always On

08  Wartung & Automatisierung

Backups, Statistics, Reorg — dauerhaft automatisiert

09  Berechtigungskonzept

Bonus: Sicherheit & Performance kombiniert

10  30-Tage-Checkliste

40-80 % Geschwindigkeitsgewinn — strukturiert umgesetzt

 

 

Einleitung

 

 

Viele IT-Verantwortliche in mittelständischen Unternehmen erleben aktuell dasselbe Phänomen: Der SQL-Server läuft trotz ausreichend dimensionierter Hardware spürbar langsamer als noch vor ein oder zwei Jahren. Abfragen, die früher in Millisekunden antworteten, brauchen plötzlich mehrere Sekunden. Reports hängen, ERP-Systeme wirken träge und die Frustration in den Fachabteilungen steigt.

 

Der Grund ist nicht immer die Hardware.

 

Seit der Einführung von SQL Server 2025 (Version 17.x) haben sich mehrere Dinge grundlegend verändert:

 

→  Neue Sicherheitsfeatures wie PBKDF2-Passworthashing sind standardmäßig aktiv und können Login-Zeiten spürbar verlängern.

 

→  Persisted Statistics für Secondary Replicas erzeugen pro Datenbank zusätzliche Background-Worker-Threads — auch wenn gar keine Always-On-Verfügbarkeitsgruppe genutzt wird.

 

→  Das Cardinality-Estimation-Modell wurde weiter optimiert, was bei älteren Compatibility Levels zu unerwartet schlechten Ausführungsplänen führt.

 

→  Gleichzeitig wachsen die Datenmengen durch Digitalisierung, BI und ERP-Systeme schneller denn je.

 

Dieses Buch ist kein umfangreicher Theoriewälzer mit 400 Seiten. Es ist ein kompaktes, sofort einsetzbares Notfall-Kit für die Praxis — mit fertigen Skripten, Checklisten und klaren Schritt-für-Schritt-Anleitungen.

 

WAS SIE IN DIESEM BUCH ERWARTEN DÜRFEN ■  Sofort-Diagnose — Drei einfache DMV-Abfragen lokalisieren das Problem in unter 5 Minuten. ■  10 Performance-Killer — Inklusive der neuen 2025/2026-Fallen — mit sofort kopierbaren Skripten. ■  30-Tage-Checkliste — Strukturierter Plan für 40-80 % Geschwindigkeitsgewinn — oft ohne neue Hardware. ■  2025-Upgrade-Fallen — Spezielle Probleme, die kein klassisches Tuning-Buch behandelt. ■  Bonus-Kapitel — Optimierte Berechtigungskonzepte und Wartungsautomatisierungen.

 

ZIEL DIESES BUCHES Nach dem Lesen und Umsetzen dieses Buches haben Sie spürbar schnellere Systeme — und verbringen weniger Zeit mit Feuerlöschen. Keine teuren Lizenz-Tools, keine monatelangen Projekte. Nur klare, sofort umsetzbare Maßnahmen.

 

 

Die 10 Performance-Killer

 

 

In mittelständischen Umgebungen treten immer wieder dieselben zehn Performance-Probleme auf. Die meisten lassen sich mit einfachen Diagnose-Skripten und gezielten Maßnahmen schnell und dauerhaft lösen — oft ohne neue Hardware und ohne teure Tools.

 

 

Der Klassiker Nummer 1. Fehlende Indizes führen zu Table Scans statt schneller Index Seeks. Fragmentierte Indizes verursachen unnötige I/O-Operationen.

 

LÖSUNG:

 

✓  CREATE INDEX mit INCLUDE-Spalten für Covering anlegen.

✓  REORGANIZE bei < 30 % Fragmentierung, REBUILD bei > 30 %.

✓  Bei BI-Reports (Power BI) zusätzlich nicht-geclusterte Columnstore-Indizes prüfen.

 

-- Missing Indexes (Priorisierung nach Nutzen) SELECT migs.avg_total_user_cost * (migs.avg_user_impact * 0.01)        * (migs.user_seeks + migs.user_scans) AS improvement_measure,        'CREATE INDEX [IX_' + OBJECT_NAME(mid.object_id) + '_'        + ISNULL(mid.equality_columns,'') + ']' AS Create_Index_Statement FROM sys.dm_db_missing_index_groups mig JOIN sys.dm_db_missing_index_group_stats migs   ON mig.index_group_handle = migs.group_handle JOIN sys.dm_db_missing_index_details mid   ON mig.index_handle = mid.index_handle WHERE migs.avg_total_user_cost * (migs.avg_user_impact * 0.01)       * (migs.user_seeks + migs.user_scans) > 10 ORDER BY improvement_measure DESC;

 

 

 

 

 

 

 

 

 

 

 

Der Query Optimizer trifft falsche Entscheidungen, weil er die aktuelle Datenverteilung nicht kennt. Nach Upgrades auf SQL Server 2025 ändert sich das CE-Modell — alte Statistiken passen nicht mehr.

 

 

 

 

LÖSUNG:

 

✓  UPDATE STATISTICS mit FULLSCAN für kritische Tabellen.

✓  SQL Agent Job für tägliches Update einrichten.

✓  Nicht auf AUTO_UPDATE_STATISTICS allein verlassen.

 

SELECT OBJECT_NAME(s.object_id) AS TableName,        STATS_DATE(s.object_id, s.stats_id) AS LastUpdated,        sp.rows, (sp.rows_sampled * 100.0 / NULLIF(sp.rows,0)) AS SamplePct FROM sys.stats s CROSS APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) sp WHERE STATS_DATE(s.object_id, s.stats_id) < DATEADD(DAY, -7, GETDATE())   AND sp.rows > 10000 ORDER BY LastUpdated ASC;

 

 

 

Viele gleichzeitige Queries kämpfen um dieselben TempDB-Dateien → PAGELATCH-Waits.

 

LÖSUNG:

 

✓  Mindestens 8 TempDB-Dateien (eine pro CPU-Kern).

✓  Alle Dateien gleich groß, auf SSD platzieren.

✓  TempDB-Governance-Features von SQL Server 2025 nutzen.

 

SELECT session_id, wait_type, wait_duration_ms FROM sys.dm_os_waiting_tasks WHERE wait_type LIKE 'PAGELATCH%';

 

 

 

Eine Abfrage ist mit Parameter A blitzschnell, mit Parameter B extrem langsam. SQL Server cached den ersten Plan für alle Folgeaufrufe.

 

 

LÖSUNG:

 

✓  Optional Parameter Plan Optimization (OPPO) bei Compat. Level 170 aktivieren.

✓  OPTION (OPTIMIZE FOR UNKNOWN) als schnellen Fix verwenden.

✓  OPTION (RECOMPILE) bei seltenen, kritischen Abfragen.

 

CREATE OR ALTER PROCEDURE dbo.GetOrders @CustomerID int AS BEGIN     SELECT * FROM Orders     WHERE CustomerID = @CustomerID     OPTION (OPTIMIZE FOR UNKNOWN); -- oder RECOMPILE END

 

 

 

Microsoft Known Issue: Pro Datenbank wird ein Background-Worker-Thread gestartet — auch ohne Always-On. Bei > 30-50 Datenbanken wird der Server langsam oder unresponsive.

 

LÖSUNG:

 

✓  Startup-Traceflag 15608 in SQL Server Configuration Manager eintragen.

✓  Server neu starten — das Problem ist sofort behoben.

✓  Offizieller Microsoft Workaround, voll supported.

 

-- In SQL Server Configuration Manager → Startup Parameters: -T15608 -- Server neu starten

 

 

 

Viele Upgrades bleiben auf Level 140/150 → neue IQP-Features (Intelligent Query Processing) wie Memory Grant Feedback und Adaptive Joins bleiben deaktiviert.

 

LÖSUNG:

 

✓  Query Store aktivieren, dann schrittweise auf Level 170 hochsetzen.

✓  Regressions im Query Store prüfen und bei Bedarf mit Plan Forcing korrigieren.

✓  DOP Feedback, Memory Grant Feedback und Adaptive Joins nach Upgrade prüfen.

 

ALTER DATABASE IhreDatenbank SET QUERY_STORE = ON; -- Dann schrittweise: ALTER DATABASE IhreDatenbank SET COMPATIBILITY_LEVEL = 170;

 

 

Der "Flight Recorder" von SQL Server wird nicht genutzt → Regressions nach Upgrades und Patches bleiben unsichtbar.

 

LÖSUNG:

 

✓  Query Store auf allen produktiven Datenbanken aktivieren.

✓  Capture Mode auf Auto stellen.

✓  Regelmäßig Top-Ressource-Queries und Regressed Queries prüfen.

 

ALTER DATABASE DeineDB SET QUERY_STORE = ON (OPERATION_MODE = READ_WRITE,  QUERY_CAPTURE_MODE = AUTO,  MAX_STORAGE_SIZE_MB = 500);

 

 

 

Klassische Rowstore-Indizes bei großen BI-Abfragen verursachen enorme I/O. Columnstore-Indizes sind bei Aggregaten 5-10x schneller.

 

LÖSUNG:

 

✓  Nicht-geclusterte Columnstore-Indizes für Reporting-Tabellen anlegen.

✓  Besonders wirksam bei Tabellen > 1 Mio. Zeilen mit SUM/COUNT/GROUP BY.

✓  Mit gefilterten Indizes für aktuelle Daten kombinieren.

 

CREATE NONCLUSTERED COLUMNSTORE INDEX NCCI_FactSales ON dbo.FactSales (DateKey, ProductKey, CustomerKey, Amount, Qty);

 

 

 

SQL-Authentication verwendet jetzt standardmäßig PBKDF2 mit 100.000 SHA-512-Iterationen → spürbar längere Login-Zeiten ohne Connection Pooling.

 

LÖSUNG:

 

✓  Connection Pooling in der Anwendung aktivieren (Standard in .NET, Java).

✓  Bei Legacy-Anwendungen: Traceflag 4671 temporär testen.

✓  Langfristig: Umstellung auf Windows-Authentication empfohlen.

 

-- Login-Zeiten prüfen: SELECT login_name, COUNT(*) AS LoginAttempts,        AVG(DATEDIFF(ms, connect_time, GETDATE())) AS Avg_Login_ms FROM sys.dm_exec_sessions GROUP BY login_name ORDER BY Avg_Login_ms DESC;

 

 

 

Backups, Index-Reorg, Statistics-Updates und Consistency Checks werden manuell oder gar nicht ausgeführt. Nach 3-6 Monaten ist die Performance wieder auf dem Ausgangsniveau.

 

LÖSUNG:

 

✓  Ola Hallengren Maintenance Solution installieren (kostenlos, SQL 2025-kompatibel).

✓  SQL Agent Jobs für täglichen Statistics-Update, wöchentliches Rebuild und Full-Backup einrichten.

✓  Neu: ZSTD-Kompression nutzen — bis 40 % kleinere Backups.

 

-- ZSTD Backup (neu SQL Server 2025) EXECUTE dbo.DatabaseBackup   @Databases = 'ALL_DATABASES',   @Directory = 'E:\Backup',   @BackupType = 'FULL',   @Compress = 'Y',   @CompressionAlgorithm = 'ZSTD';

 

 

 

Schnell-Diagnose in unter 5 Minuten

 

 

Bevor Sie mit Optimierungen beginnen, müssen Sie wissen, wo das eigentliche Problem liegt. Diese drei DMV-Abfragen liefern in unter 5 Minuten eine klare Prioritätenliste: Welche Abfragen sind am langsamsten? Wo fehlen Indizes? Wo gibt es Warteprobleme?

 

EMPFEHLUNG Führen Sie die drei Skripte nacheinander aus. Speichern Sie die Ergebnisse als CSV oder Excel. Sie erhalten damit eine professionelle Diagnose, die Sie auch in Kundengesprächen präsentieren können.

 

 

Zeigt die Abfragen, die am meisten Zeit kosten — sortiert nach tatsächlicher Laufzeit.

 

SELECT TOP 10     qs.total_elapsed_time / 1000000.0 AS Total_Seconds,     qs.execution_count AS ExecutionCount,     qs.total_elapsed_time / 1000000.0 / qs.execution_count AS Avg_Seconds,     SUBSTRING(st.text,         (qs.statement_start_offset / 2) + 1,         ((CASE qs.statement_end_offset             WHEN -1 THEN DATALENGTH(st.text)             ELSE qs.statement_end_offset           END - qs.statement_start_offset) / 2) + 1) AS QueryText,     qp.query_plan AS ExecutionPlan FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp ORDER BY qs.total_elapsed_time DESC;

 

 

→  Total_Seconds > 10 und ExecutionCount hoch → Klassiker für Index-Tuning.

 

→  Avg_Seconds sehr hoch bei niedriger ExecutionCount → Parameter Sniffing oder schlechter Plan.

 

 

 

 

 

 

 

Zeigt genau, welche Indizes SQL Server vermisst und wie viel Performance-Gewinn sie bringen würden.

 

SELECT     migs.avg_total_user_cost * (migs.avg_user_impact * 0.01)     * (migs.user_seeks + migs.user_scans) AS Improvement_Measure,     'CREATE INDEX [IX_' + OBJECT_NAME(mid.object_id) + '_'     + ISNULL(mid.equality_columns, '') + ']' AS Create_Index_Statement,     mid.equality_columns, mid.inequality_columns,     mid.included_columns, mid.statement AS Affected_Table FROM sys.dm_db_missing_index_groups mig JOIN sys.dm_db_missing_index_group_stats migs   ON mig.index_group_handle = migs.group_handle JOIN sys.dm_db_missing_index_details mid   ON mig.index_handle = mid.index_handle WHERE migs.avg_total_user_cost * (migs.avg_user_impact * 0.01)       * (migs.user_seeks + migs.user_scans) > 10 ORDER BY Improvement_Measure DESC;

 

 

→  Improvement_Measure > 100.000 → sofort umsetzen.

 

→  Viele Einträge für dieselbe Tabelle → diese Tabelle zuerst priorisieren.

 

 

Zeigt, worauf der Server gerade wartet — der wichtigste Indikator für systemweite Engpässe.

 

SELECT     wait_type, waiting_tasks_count,     wait_time_ms / 1000.0 AS Wait_Time_Seconds,     (wait_time_ms / 1000.0) / waiting_tasks_count AS Avg_Wait_Seconds,     signal_wait_time_ms / 1000.0 AS Signal_Wait_Seconds FROM sys.dm_os_wait_stats WHERE wait_time_ms > 0 ORDER BY wait_time_ms DESC;

 

 

Wait Type	Bedeutung	Ursache	Schnell-Lösung
PAGELATCH_xx	TempDB-Contention	Zu wenige TempDB-Dateien	8+ Dateien pro Kern
CXPACKET	Parallelismus-Probleme	Zu hohes MAXDOP	MAXDOP 4-8 + Cost Threshold 50
PAGEIOLATCH_xx	Langsame I/O	Fehlende Indizes	Indizes + Columnstore anlegen
LCK_M_xx	Locking / Blocking	Lange Transaktionen	Query Store + Optimized Locking
ASYNC_NETWORK_IO	App holt Daten zu langsam	Schlechtes App-Design	Connection Pooling prüfen

 

 

Index-Optimierung

 

 

Ein gut gewählter Index verwandelt langsame Table Scans in schnelle Index Seeks. Ein falscher oder fragmentierter Index kann das genaue Gegenteil bewirken: mehr I/O, höhere CPU-Last und längere Wartezeiten.

 

 

SELECT OBJECT_NAME(ips.object_id) AS TableName,        i.name AS IndexName,        ips.avg_fragmentation_in_percent AS FragmentationPercent,        ips.page_count,        CASE            WHEN ips.avg_fragmentation_in_percent > 30 THEN 'REBUILD'            WHEN ips.avg_fragmentation_in_percent > 10 THEN 'REORGANIZE'            ELSE 'OK'        END AS RecommendedAction FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') ips JOIN sys.indexes i ON ips.object_id = i.object_id AND ips.index_id = i.index_id WHERE ips.avg_fragmentation_in_percent > 10 AND ips.page_count > 1000 ORDER BY ips.avg_fragmentation_in_percent DESC;

 

 

Fragmentierung	Aktion	Online möglich?	Bemerkung
10-30 %	REORGANIZE	Ja	Schnell, geringer Log-Aufwand
> 30 %	REBUILD	Ja (Enterprise)	Vollständige Neuerstellung
> 70 %	REBUILD + FILLFACTOR 80	Ja	Bei stark schreibenden Tabellen

 

 

Verwenden Sie Skript 3.2 aus Kapitel 3 als Ausgangsliste. Wichtige Regeln beim Anlegen:

 

→  Equality Columns zuerst in den Index-Key.

 

→  Inequality Columns danach.

 

→  Included Columns für Covering Queries — vermeidet Key Lookups.

 

→  Niemals mehr als 5-7 Spalten im Key (sonst wird der Index zu breit).

 

-- Typischer ERP-Index mit Covering Columns CREATE NONCLUSTERED INDEX IX_Orders_Customer_Date ON dbo.Orders (CustomerID, OrderDate) INCLUDE (TotalAmount, Status);

 

 

 

Bei großen Reporting-Tabellen sind Columnstore-Indizes oft 5-10x schneller als Rowstore.

 

-- Nicht-geclusterter Columnstore (empfohlen für KMU) CREATE NONCLUSTERED COLUMNSTORE INDEX NCCI_FactSales ON dbo.FactSales (DateKey, ProductKey, CustomerKey, Amount, Quantity);   -- Mit gefiltertem Index für aktuelle Daten kombinieren CREATE NONCLUSTERED INDEX IX_Orders_Recent ON dbo.Orders (OrderDate, Status) INCLUDE (TotalAmount) WHERE OrderDate >= '2025-01-01';

 

 

WANN COLUMNSTORE SINNVOLL IST Tabellen > 1 Million Zeilen mit vielen Aggregat-Abfragen (SUM, COUNT, GROUP BY) und wenigen Spalten pro Query — typisch bei Power BI, DeltaMaster und anderen BI-Tools.

 

 

Query-Tuning

 

 

 

Der Execution Plan ist Ihr wichtigstes Diagnosewerkzeug. Ctrl + L zeigt den geschätzten Plan, Ctrl + M den tatsächlichen.

 

Operator	Problem, wenn teuer	Schnell-Lösung
Table Scan / CIS	Fehlender Index	Index anlegen
Key Lookup	Nicht-Covering Index	INCLUDE-Spalten hinzufügen
Hash Match (Join)	Schlechte Join-Reihenfolge	Bessere Statistiken oder Index
Sort	Hoher Memory Grant	Index mit ORDER BY-Spalten
Window Spool	Für Window Functions	Columnstore oder Materialized View

 

ESTIMATED VS. ACTUAL ROWS Eine Abweichung > 10-fach bedeutet fast immer veraltete Statistiken oder Parameter Sniffing. Dieser Indikator ist der wichtigste erste Hinweis im Execution Plan.

 

 

-- SCHLECHT: Subquery wird pro Zeile einzeln ausgeführt SELECT OrderID,     (SELECT SUM(Amount) FROM OrderLines WHERE OrderID = o.OrderID) AS Total FROM Orders o;   -- GUT: CTE wird einmal berechnet WITH OrderTotals AS (     SELECT OrderID, SUM(Amount) AS Total     FROM OrderLines GROUP BY OrderID ) SELECT o.OrderID, ot.Total FROM Orders o LEFT JOIN OrderTotals ot ON o.OrderID = ot.OrderID;

 

 

 

 

 

Optional Parameter Plan Optimization (OPPO) ist automatisch bei Compatibility Level 170 aktiv. SQL Server speichert dann mehrere Pläne pro Abfrage und wählt den passenden.

 

-- Klassische Lösung für ältere Compatibility Levels CREATE OR ALTER PROCEDURE dbo.GetOrders @CustomerID int AS BEGIN     SELECT * FROM Orders     WHERE CustomerID = @CustomerID     OPTION (OPTIMIZE FOR UNKNOWN); END

 

 

 

Neue Fallen 2026

 

 

Diese neuen Fallen sind in keinem älteren Tuning-Buch beschrieben — und genau deshalb bleiben sie in der Praxis so lange unentdeckt.

 

 

Seit SQL Server 2025 wird pro Datenbank ein Hintergrund-Worker-Thread gestartet — auch ohne Always-On. Bei > 30-50 Datenbanken (typisch in ERP-Umgebungen) wird der Server träge oder teilweise unresponsive.

 

-- Offizieller Microsoft Workaround (voll supported): -- SQL Server Configuration Manager → Startup Parameters: -T15608 -- Server neu starten → Problem sofort behoben

 

 

 

SQL Server 2025 verwendet PBKDF2 mit 100.000 SHA-512-Iterationen. Ohne Connection Pooling führt das zu 2-5x längeren Login-Zeiten.

 

→  Connection Pooling in der Anwendung aktivieren (Standard in .NET, Java).

 

→  Bei Legacy-Anwendungen: Traceflag 4671 temporär testen.

 

→  Langfristig: Umstellung auf Windows-Authentication.

 

 

Reduziert Blocking um bis zu 50 % — wird aber bei Upgrades nicht automatisch aktiviert.

-- Prüfen: SELECT name, is_optimized_locking_enabled FROM sys.databases;   -- Aktivieren: ALTER DATABASE IhreDatenbank SET OPTIMIZED_LOCKING = ON;

 

 

Compat. Level	IQP-Features aktiv	Empfehlung für KMU
140 / 150	Nein	Nur temporär — Migration planen
160	Teilweise	Übergangsschritt
170	Vollständig	Zielwert — schrittweise migrieren

 

 

Server- & Instanz-Tuning

 

 

 

Faustregel: 4-6 GB für OS freilassen, Rest für SQL Server.

 

Server RAM	Max Server Memory (empfohlen)
32 GB	24-26 GB
64 GB	52-56 GB
128 GB	112-118 GB
256 GB	240-246 GB

 

EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'max server memory (MB)', 55000; -- Beispiel 64 GB Server RECONFIGURE;

 

 

 

TempDB wird von fast allen Abfragen genutzt. Falsche Konfiguration → massive PAGELATCH-Waits.

 

→  Mindestens 8 Datenbankdateien (1 pro CPU-Kern, max. 1 pro Kern).

 

→  Alle Dateien gleich groß (z.B. 1 GB Initial Size, 512 MB Autogrowth).

 

→  Dateien auf separaten SSDs oder schnellem NVMe-Storage.

 

-- 8 TempDB-Dateien anlegen (Beispiel) ALTER DATABASE tempdb ADD FILE (NAME = 'tempdev2', FILENAME = 'D:\TempDB\tempdev2.ndf',           SIZE = 1024MB, FILEGROWTH = 512MB); -- (Für Dateien 3 bis 8 wiederholen)

 

 

 

Verhindert, dass ein BI-Report den gesamten Server blockiert.

 

-- ERP-Pool (kritisch, priorisiert) CREATE RESOURCE POOL ERP_Pool WITH (MIN_CPU_PERCENT = 30, MAX_CPU_PERCENT = 80,  MIN_MEMORY_PERCENT = 40, MAX_MEMORY_PERCENT = 90);   -- Reporting-Pool (begrenzt) CREATE RESOURCE POOL Reporting_Pool WITH (MIN_CPU_PERCENT = 10, MAX_CPU_PERCENT = 30,  MIN_MEMORY_PERCENT = 10, MAX_MEMORY_PERCENT = 40);

 

 

 

Wartung & Automatisierung

 

 

Selbst die beste manuelle Optimierung nutzt nichts, wenn sie nicht regelmäßig und zuverlässig ausgeführt wird. Nach 3-6 Monaten ohne Wartung ist die Performance wieder auf dem Ausgangsniveau — oder schlechter.

 

 

Die kostenlose "Ola Hallengren Maintenance Solution" ist der Standard in KMU-Umgebungen und wird auch 2026 von Microsoft empfohlen. Installation: ola.hallengren.com — SQL 2025-kompatibel.

 

Job	Ausführung	Wichtige Parameter	Nutzen
IndexOptimize	Sa. 22:00	@FragmentationMedium = REORGANIZE	Automatische Index-Wartung
UpdateStatistics	Tägl. 01:00	@OnlyModifiedStatistics = Y	Frische Statistiken
DatabaseBackup FULL	So. 23:00	@Compress = Y, @BackupType = FULL	Komprimierte Full-Backups
DatabaseBackup LOG	Stündlich	@BackupType = LOG	Point-in-Time Recovery
DatabaseIntegrityCheck	Monatlich	@CheckCommand = CHECKDB	Früherkennung Korruption

 

 

EXECUTE dbo.DatabaseBackup   @Databases = 'ALL_DATABASES',   @Directory = 'E:\Backup',   @BackupType = 'FULL',   @Compress = 'Y',   @CompressionAlgorithm = 'ZSTD'; -- bis 40% kleinere Backups

 

 

BACKUP-STRATEGIE FÜR KMU Full Backup einmal pro Woche · Differential täglich · Transaction Log alle 15-60 Min. · Aufbewahrung: 4 Wochen Full + 7 Tage Log. Zusätzlich: wöchentlicher Test-Restore auf separatem Server für Datensicherheitsnachweis.

 

Bonus: Berechtigungskonzept

 

 

Ein gut durchdachtes Berechtigungskonzept ist nicht nur ein Sicherheits-Thema — es ist auch ein echter Performance-Hebel. Zu breite Rechte führen zu zusätzlichen Berechtigungsprüfungen, unnötigem Row-Level-Security-Overhead und langsameren Abfragen.

 

 

Rolle	Rechte	Typische Nutzer	Performance-Tipp
db_datareader	SELECT alle Tabellen	BI-Analysten	Nur wo wirklich nötig
ERP_ReadOnly	SELECT ERP-Schemata	Fachabteilung	Via View statt Tabelle
BI_Reporting	SELECT Fact/Dim-Tabellen	Power BI / DeltaMaster	Columnstore + RLS nur bei Bedarf
App_ERP_Service	EXECUTE Stored Procs	ERP-Anwendungskonto	Keine direkten Tabellenrechte
DBA_Full	db_owner temporär	Administrator	Niemals dauerhaft vergeben

 

 

SELECT dp.name AS Principal, o.name AS Object,        p.permission_name, p.state_desc FROM sys.database_permissions p JOIN sys.objects o ON p.major_id = o.object_id JOIN sys.database_principals dp ON p.grantee_principal_id = dp.principal_id WHERE p.state_desc <> 'DENY' ORDER BY dp.name;   -- Rollen anlegen und Rechte vergeben CREATE ROLE ERP_ReadOnly; GRANT SELECT ON SCHEMA::dbo TO ERP_ReadOnly; GRANT SELECT ON SCHEMA::Sales TO ERP_ReadOnly;   -- Benutzer zu Rolle hinzufügen ALTER ROLE ERP_ReadOnly ADD MEMBER [domain\maxmustermann];

 

 

 

30-Tage-Performance-Boost Checkliste

 

 

Diese Checkliste führt Sie in 30 Tagen durch alle wesentlichen Optimierungsschritte — von der ersten Diagnose bis zur vollständigen Automatisierung. Typisches Ergebnis: 40-80 % Geschwindigkeitsgewinn — oft ohne neue Hardware.

 

VOR DEM START Erstellen Sie ein vollständiges Backup aller Datenbanken. Aktivieren Sie den Query Store auf allen produktiven Datenbanken. Notieren Sie aktuelle Baseline-Werte (Avg. Query Time, PAGELATCH-Waits).

 

 

■ TAG 1-2: BASELINE ERSTELLEN

 

■  Skript 3.1 ausführen: Top 10 langsamste Abfragen identifizieren

■  Skript 3.2 ausführen: Missing Indexes mit Improvement_Measure > 10.000 notieren

■  Skript 3.3 ausführen: Warte-Statistiken in Excel festhalten

■  Query Store auf allen produktiven DBs aktivieren (falls noch nicht geschehen)

■  Max Server Memory prüfen und nach Faustregel konfigurieren

 

■ TAG 3-4: TEMPDB & INSTANZ-CHECK

 

■  Anzahl TempDB-Dateien prüfen — auf min. 8 erhöhen falls nötig

■  TempDB-Dateien auf SSD/NVMe legen und gleichgroß machen

■  SQL Server 2025 Upgrade-Fallen prüfen: Traceflag 15608 bei vielen DBs

■  Compatibility Level aller Datenbanken prüfen, ggf. auf 170 planen

■  Optimized Locking prüfen und aktivieren: ALTER DATABASE ... SET OPTIMIZED_LOCKING = ON

 

■ TAG 5-7: TOP-3 MISSING INDEXES ANLEGEN

 

■  Improvement_Measure-Liste sortieren — Top 3 identifizieren

■  Equality + Inequality Columns + INCLUDE-Spalten für jeden Index definieren

■  Indizes in Wartungsfenster anlegen, vorher Execution Plan notieren

■  Performance-Verbesserung messen und dokumentieren

■  Baseline-Vergleich: Warte-Statistiken erneut ausführen

 

 

■ TAG 8-10: FRAGMENTIERUNG BEHEBEN

 

■  Fragmentierungs-Skript aus Kapitel 4.1 auf allen produktiven DBs ausführen

■  Indizes > 30 % Fragmentierung: REBUILD in Wartungsfenster durchführen

■  Indizes 10-30 % Fragmentierung: REORGANIZE-Job einrichten

■  Veraltete Statistiken identifizieren (Skript Kapitel 2, Punkt 2) und updaten

 

■ TAG 11-13: QUERY-TUNING DER TOP-ABFRAGEN

 

■  Top 5 langsamste Abfragen aus Baseline-Liste: Execution Plans öffnen

■  Estimated vs. Actual Rows vergleichen — Abweichungen > 10x markieren

■  Key Lookups identifizieren und durch INCLUDE-Spalten eliminieren

■  Correlated Subqueries in CTEs oder JOINs umschreiben

■  Parameter Sniffing-Kandidaten mit OPTION (OPTIMIZE FOR UNKNOWN) testen

 

■ TAG 14: COLUMNSTORE-ANALYSE

 

■  BI/Reporting-Tabellen identifizieren (> 1 Mio. Zeilen, viele Aggregationen)

■  Nicht-geclusterten Columnstore-Index auf Top-1-Reporting-Tabelle anlegen

■  Power BI / DeltaMaster-Abfragezeiten vorher/nachher messen

 

 

■ TAG 15-17: OLA HALLENGREN EINRICHTEN

 

■  Ola Hallengren Maintenance Solution von ola.hallengren.com herunterladen

■  Installation auf allen Instanzen durchführen

■  SQL Agent Job IndexOptimize einrichten (Samstag, 22:00)

■  SQL Agent Job UpdateStatistics einrichten (täglich, 01:00)

■  SQL Agent Job DatabaseBackup FULL einrichten (Sonntag, 23:00, ZSTD)

■  SQL Agent Job DatabaseBackup LOG einrichten (stündlich)

 

■ TAG 18-20: BACKUP-STRATEGIE FINALISIEREN

 

■  ZSTD-Kompression in Backup-Jobs aktivieren (@CompressionAlgorithm = ZSTD)

■  Backup-Pfade und Aufbewahrungsdauer konfigurieren (4 Wochen Full, 7 Tage Log)

■  RESTORE VERIFYONLY für alle aktuellen Backups ausführen

■  Test-Restore auf separatem Server durchführen und dokumentieren

 

 

 

 

■ TAG 21: BERECHTIGUNGSKONZEPT-AUDIT

 

■  Berechtigungs-Audit-Skript aus Kapitel 9 ausführen

■  Direkte GRANTs an einzelne Benutzer identifizieren und durch Rollen ersetzen

■  Anwendungskonten prüfen: Nur EXECUTE auf Stored Procs, keine direkten Tabellenrechte

■  db_owner-Mitgliedschaften prüfen — keine dauerhaften db_owner außer DBA

 

 

■ TAG 22-25: MONITORING EINRICHTEN

 

■  SQL Agent Job DatabaseIntegrityCheck einrichten (monatlich, CHECKDB)

■  Resource Governor einrichten: ERP_Pool vs. Reporting_Pool trennen

■  Query Store Retention und Storage Size final konfigurieren

■  Warte-Statistiken-Monitoring-Skript als regelmäßigen Job einrichten

■  Power BI / SSRS Dashboard für Job-Status und Performance aufbauen

 

■ TAG 26-28: COMPATIBILITY LEVEL MIGRATION

 

■  Query Store Regressions-Analyse nach Compat.-Level-Erhöhung durchführen

■  Top-5-Abfragen auf Level 170 testen, bei Regressions Plan Forcing setzen

■  Compatibility Level schrittweise auf 170 heben (DB für DB)

■  IQP-Features (Memory Grant Feedback, DOP Feedback) nach Migration prüfen

 

■ TAG 29-30: ABSCHLUSS & DOKUMENTATION

 

■  Abschlussmessung: Warte-Statistiken, Top-10-Abfragen, Query Store vergleichen

■  Verbesserungen dokumentieren (Baseline vs. aktuell)

■  Nicht umgesetzte Punkte in Backlog priorisieren

■  Wartungsplan-Kalender für nächste 12 Monate erstellen

■  Ergebnis feiern — typisch sind 40-80 % Geschwindigkeitsgewinn! ■

 

ERGEBNIS NACH 30 TAGEN Ihr Ergebnis nach 30 Tagen: Schnellere Abfragen, automatisierte Wartung, saubere Berechtigungen, zuverlässige Backups — und ein Server, der auch in den nächsten Monaten performant bleibt. Ohne neue Hardware, ohne teure Tools.

 

 

 

 

Die in diesem Dokument enthaltenen Informationen, Skripte, Empfehlungen und Konfigurationshinweise wurden nach bestem Wissen und Gewissen auf der Grundlage langjähriger praktischer Erfahrung erstellt. Dennoch kann keine Gewähr für die Vollständigkeit, Richtigkeit oder Aktualität der bereitgestellten Inhalte übernommen werden.

 

Der Autor übernimmt ausdrücklich keinerlei Haftung für unmittelbare oder mittelbare Schäden, einschließlich, aber nicht beschränkt auf: Datenverlust oder -korruption, Systemausfälle, Produktionsunterbrechungen, entgangenen Gewinn sowie Kosten für die Wiederherstellung von Daten.

 

Die Nutzung der bereitgestellten Skripte und Empfehlungen erfolgt ausschließlich auf eigenes Risiko des Anwenders. Es wird dringend empfohlen, vor jeder Implementierung ein vollständiges Datenbank-Backup durchzuführen und Änderungen zunächst in einer Testumgebung zu validieren.

 

 

Alle in diesem Dokument enthaltenen SQL-Skripte, T-SQL-Anweisungen, Traceflags und Konfigurationsempfehlungen wurden in realen KMU-Umgebungen erprobt. Dennoch können aufgrund unterschiedlicher Systemkonfigurationen, Datenbankversionen und Hardware unerwartete Verhaltensweisen auftreten.

 

Insbesondere Traceflags wie -T15608 oder 4671 greifen tief in das Systemverhalten von SQL Server ein und sind stets zunächst in einer Testumgebung zu prüfen. Der Autor übernimmt keine Verantwortung für Folgen aus unsachgemäßem Einsatz.

 

 

Angaben wie "40-80 % Geschwindigkeitsgewinn" oder "Diagnose in unter 5 Minuten" basieren auf Erfahrungswerten aus realen mittelständischen Umgebungen und stellen keine rechtsverbindliche Zusicherung dar.

 

 

Die Inhalte beziehen sich auf SQL Server 2022 (Version 16.x) und SQL Server 2025 (Version 17.x), Stand März 2026. Microsoft veröffentlicht regelmäßig kumulative Updates, die das Verhalten von SQL Server ändern können.

 

 

Dieses Dokument und alle Inhalte sind urheberrechtlich geschützt. © 2026 Sascha Hess, xenosystems.de. Alle Rechte vorbehalten.

 

 

SQL Server, Azure, Microsoft und weitere Produktnamen sind eingetragene Marken der Microsoft Corporation. Oracle ist eine eingetragene Marke der Oracle Corporation.

 

 

Es gilt ausschließlich deutsches Recht. Gerichtsstand für alle Streitigkeiten ist, soweit gesetzlich zulässig, Weimar, Thüringen, Deutschland.

 

 

 

Sascha Hess ist Diplom-Biologe und IT-Professional mit über 20 Jahren Erfahrung in der Administration von ERP-, BI- und Datenbanksystemen. Er hat mehr als 300 Oracle- und SQL-Server-Instanzen administriert und betreut — von mittelständischen KMU bis zu Universitäten und Energieversorgern.

 

Sein Ansatz verbindet naturwissenschaftliche Präzision mit hochgradiger IT-Spezialisierung. Schwerpunkte: SQL Server Performance-Tuning, ERP-Einführungen, Business Intelligence (Power BI, DeltaMaster), Prozessdigitalisierung und IT-Interim-Management.

 

Web: www.xenosystems.de | E-Mail: info@xenosystems.de | Standort: Weimar, Thüringen / Remote

 

Service	Beschreibung
SQL Server DB Health Check	Professioneller Audit Ihres SQL Servers — Managementreport, Risikobewertung und Maßnahmenplan. Scope: 3-5 Tage.
ERP-Einführungsberatung	Begleitung von ERP-Projekten (MACH, Dynamics NAV, APplus) — Datenmigration, Schnittstellenentwicklung, Go-Live-Support.
BI-Dashboard-Aufbau	Power BI / DeltaMaster Dashboards inkl. ETL-Strecken und Data-Warehouse-Aufbau — für KMU ab 1 Woche Projektumfang.
KI-Readiness Assessment	Bewertung Ihrer Datenqualität, Systemlandschaft und Prozessreife für den KI-Einstieg — mit konkretem Fahrplan.
Interim IT-Management	Übernahme der IT-Steuerung auf Zeit — Budgetplanung, Dienstleister-Management, strategische IT-Ausrichtung.