Wenn plötzlich alle gleichzeitig klicken

Kennst Du: Montagmorgen, 8:00 Uhr.
Alle starten gleichzeitig ihre ERP-Frontends.
Oder rufen die gleiche Auswertung auf.

Der SQL Server röchelt.
Abfragen dauern.
Und Du darfst erklären, warum wieder alles hängt.

Ich zeige Dir, wie ich in solchen Fällen vorgehe –
und wie ich die Situation stabilisiere, ohne gleich aufzurüsten.

Schritt 1: Aktive Verbindungen sichtbar machen

SELECT 
    session_id, 
    login_name, 
    host_name, 
    program_name, 
    status, 
    cpu_time, 
    memory_usage, 
    reads, 
    writes
FROM sys.dm_exec_sessions
WHERE is_user_process = 1;

So siehst Du, wer gerade was macht – und wie viele gleichzeitig online sind.

Schritt 2: Welche Sessions blockieren?

SELECT 
    blocking_session_id, 
    session_id, 
    wait_type, 
    wait_time, 
    wait_resource, 
    status, 
    DB_NAME(database_id) AS DB
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

Das hilft Dir, Blocker zu identifizieren.
Häufig sind das „dicke“ Reports oder Formulare ohne Filter.

Schritt 3: Maximalverbindungen im Blick behalten

SELECT 
    cntr_value AS [User Connections]
FROM sys.dm_os_performance_counters
WHERE counter_name = 'User Connections';

Wenn der Wert regelmäßig in Richtung 32767 (Standard-Limit) steigt, wird’s eng.

Lösung 1: Verbindungspooling kontrollieren

Viele KMU-Access-Anwendungen öffnen für jedes Formular eine neue Verbindung.
Fatal.

Besser: Dauerhafte Verbindung beim Start halten:

Public g_dbZentrale As DAO.Database

Public Sub HalteVerbindung()
    Set g_dbZentrale = OpenDatabase("\\server\backend.accdb")
End Sub

In SQL Server:

Verbindungspooling über ODBC aktivieren, aber in Grenzen halten.
Sonst bleiben zu viele Verbindungen offen.

Lösung 2: Zeitfresser erkennen und reduzieren

SELECT TOP 10 
    qs.total_elapsed_time / qs.execution_count AS Durchschnittszeit,
    qs.execution_count,
    SUBSTRING(st.text, qs.statement_start_offset / 2, 
              (CASE WHEN qs.statement_end_offset = -1 
               THEN LEN(CONVERT(NVARCHAR(MAX), st.text)) * 2 
               ELSE qs.statement_end_offset END - qs.statement_start_offset) / 2) AS Abfrage
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
ORDER BY Durchschnittszeit DESC;

So findest Du die langsamsten Anfragen.
Die sind oft Ursache für viele parallele Prozesse, die warten müssen.

Lösung 3: Ressourcensteuerung mit Resource Governor

Nur in der Enterprise Edition – aber effektiv:

CREATE WORKLOAD GROUP [ReportingUsers]  
USING [default_resource_pool]  
WITH (REQUEST_MAX_CPU_TIME_SEC = 10, MAX_DOP = 1);

ALTER RESOURCE GOVERNOR RECONFIGURE;

Berichte laufen langsamer – aber blockieren nicht mehr alles.

Lösung 4: Verbindungslimit temporär setzen

EXEC sp_configure 'user connections', 100;
RECONFIGURE;

Wichtig: Nur, wenn Du bewusst drosseln willst – etwa bei Wartung oder Debug-Phase.

Lösung 5: Heavy Queries zeitlich verschieben

Tägliche Reports laufen nicht um 8:05 Uhr – sondern um 6:30 Uhr.
Oder nachts.
Oder verteilt per SQL Agent Job mit Zeitsteuerung.

Lösung 6: Abfrage mit WITH (NOLOCK) gezielt entlasten

Für Leselast – mit Vorsicht bei Genauigkeit:

SELECT Name, Umsatz
FROM Kunden WITH (NOLOCK)
WHERE Status = 'aktiv';

Dirty Reads möglich. Nur für Reports, nie für Stammdaten.

Tabelle: Ursache – Maßnahme

Mein Setup für KMU mit vielen Nutzern

Nicht der SQL Server ist überlastet.

Meist sind es die Apps, die zu oft, zu schlecht und zur falschen Zeit fragen.

Mit etwas Disziplin, ein paar T-SQL-Views und gezieltem Pooling
läuft auch ein KMU-System mit 100 Nutzern auf einem soliden Server.
Ohne Stress. Ohne Klick-Stau.