Wenn Du nichts misst, kannst Du nichts verbessern

SQL Server läuft – bis er’s nicht mehr tut.
Dann wird gesucht, gerätselt, geschimpft.

Ohne Monitoring siehst Du erst was, wenn die Nutzer meckern.
Dann ist’s zu spät.

Ich zeige Dir, wie ich Performance-Probleme früh erkenne –
und wie ich mir Meldungen schicken lasse, bevor’s knallt.

Was Du mindestens beobachten solltest

• CPU-Auslastung
• RAM-Druck
• Lang laufende Queries
• Lock-Wartezeiten
• TempDB-Auslastung
• Auto Growth Events
• fehlgeschlagene Jobs
• freie Speicherplatz-Prozentwerte

Schritt 1: Resource Usage in regelmäßigen Snapshots erfassen

SELECT 
    GETDATE() AS Zeitstempel,
    r.session_id,
    r.status,
    r.cpu_time,
    r.total_elapsed_time,
    r.logical_reads,
    s.text AS Abfrage
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) s
WHERE r.cpu_time > 1000;

Diese Abfrage kannst Du stündlich per SQL Agent Job erfassen.
In eine eigene Log-Tabelle schreiben.

Schritt 2: Alerts bei Grenzwerten

SQL Server Agent bietet Alerts über WMI-Events, Fehlernummern oder Performance-Counter.
Beispiel: CPU über 90 %.

EXEC msdb.dbo.sp_add_alert  
    @name = N'Hohe CPU',  
    @message_id = 0,  
    @severity = 0,  
    @enabled = 1,  
    @delay_between_responses = 900,  
    @include_event_description_in = 1,  
    @performance_condition = N'SQLServer:SQL Statistics|Batch Requests/sec|>|500',  
    @job_name = N'Sende_CPU_Alarm';

Alternativ: Täglicher Health-Check mit E-Mail:

-- Wenn CPU-Spitzen in den letzten 60 Minuten aufgetreten sind
IF EXISTS (
    SELECT 1
    FROM sys.dm_exec_requests
    WHERE cpu_time > 3000
)
BEGIN
    EXEC msdb.dbo.sp_send_dbmail
        @profile_name = 'DB-Alarm',
        @recipients = 'admin@firma.de',
        @subject = 'SQL Server CPU-Alarm',
        @body = 'CPU-Zeit eines Prozesses > 3 Sekunden.';
END

Schritt 3: Failed Jobs überwachen

SELECT j.name AS JobName, h.run_date, h.run_time, h.message
FROM msdb.dbo.sysjobhistory h
JOIN msdb.dbo.sysjobs j ON h.job_id = j.job_id
WHERE h.run_status <> 1
AND h.run_date = CONVERT(INT, CONVERT(CHAR(8), GETDATE(), 112));

Tipp: Diese Query täglich per Mail versenden lassen.

Schritt 4: Lock-Wartezeiten und Blocker sichtbar machen

SELECT 
    r.blocking_session_id,
    r.wait_type,
    r.wait_time,
    r.session_id,
    t.text
FROM sys.dm_exec_requests r
JOIN sys.dm_exec_sessions s ON r.session_id = s.session_id
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.blocking_session_id <> 0;

Das zeigt, wer wen blockiert – und womit.
Wichtig für ERP-Umgebungen.

Schritt 5: TempDB-Wachstum kontrollieren

SELECT 
    name AS Datei,
    size * 8 / 1024 AS Größe_MB,
    FILEPROPERTY(name, 'SpaceUsed') * 8 / 1024 AS Genutzt_MB
FROM sys.database_files
WHERE type_desc = 'ROWS';

Auch das als regelmäßigen Check einbauen.
Wenn TempDB jeden Tag voll ist: Problem.

Tabelle: Was ich überwache und wie oft

Mein Setup in der Praxis

Monitoring ist wie Öl im Motor.

Sieht man nicht. Spürt man aber, wenn’s fehlt.

Du musst kein Rechenzentrum betreiben –
aber Du solltest wissen, wann’s warm wird.
Dann kannst Du eingreifen, bevor was kaputt geht.