Wenn Berichte träge werden

Kennst Du das?
Ein Klick auf den Bericht – und dann: Ladebalken. Kaffeezeit.
Der Nutzer schimpft. Und Du darfst suchen, woran’s liegt.

Oft liegt’s nicht an der Hardware.
Sondern am SQL. Oder am Bericht selbst.

Ich zeig Dir, wo Du anfangen kannst – ohne gleich neue Server zu kaufen.

Ursache 1: SQL-Abfragen ohne Plan

Viele SSRS-Berichte nutzen direkte SELECT *-Abfragen.
Oder Views mit Views mit Views.
Und oft ohne Parameter-Filterung.

Beispiel: besser filtern

-- Schlecht:
SELECT * FROM dbo.Auftraege;

-- Besser:
SELECT 
    auftragsnummer, kunde_id, summe
FROM dbo.Auftraege
WHERE auftragsdatum >= @Von
AND auftragsdatum <= @Bis;

SSRS übergibt Parameter – nutze sie auch im SQL.

Ursache 2: Parameter-Vorbelegung killt den Cache

Jeder neue Parameterwert = neue Abfrage = kein Caching.
Gerade bei Drop-Down-Listen mit 1.000+ Einträgen.

Tipp: Reduziere die Parameter auf sinnvolle Werte.

-- statt:
SELECT DISTINCT land FROM kunden;

-- lieber:
SELECT land FROM kunden 
WHERE status = 'aktiv'
ORDER BY land;

Oder: Parameter nicht automatisch laden, sondern erst bei Bedarf.

Ursache 3: Kein Dataset-Reuse

Wenn mehrere Tabellen im Bericht die gleiche Datenbasis nutzen:
Mach ein zentrales Dataset.

Und filtere im Bericht, nicht im SQL.

So läuft die Abfrage einmal – nicht dreimal.

Ursache 4: Subreports ohne Ende

Subreports klingen erstmal gut.
Sind aber Performance-Killer, wenn sie in Tabellen gerendert werden.

-- Besser:
Nutze LOOKUP() statt Subreport.

=Lookup(Fields!kunde_id.Value, Fields!kunde_id.Value, Fields!plz.Value, "KundenDataset")

Damit musst Du nicht für jede Zeile einen neuen Report rendern.

Ursache 5: Zu große Zwischenmengen

SSRS lädt das komplette Ergebnis in den Speicher, bevor der erste Pixel kommt.

Begrenze also früh:

-- SQL auf nur die nötigen Spalten + Zeilen
-- Kein OVER(), kein LEFT JOIN auf 10 Tabellen ohne WHERE

Und: Keine 30.000 Zeilen in ein Reporting Grid.
Nutzer lesen keine Excel-Dumps im Browser.

Ursache 6: Kein Report Cache / Snapshot

Für Berichte mit wenig Änderungen:

• Caching aktivieren in SSRS Report Manager
• Snapshots planen (z. B. nachts)

-- T-SQL, um Snapshots zu prüfen:
SELECT 
    ReportPath, 
    ExecutionDateTime, 
    TimeDataRetrieval + TimeProcessing + TimeRendering AS Gesamtzeit_ms
FROM ExecutionLog3
ORDER BY ExecutionDateTime DESC;

Ursache 7: Keine Indizes auf Berichtstabellen

Wenn Du Berichte auf DWH-Tabellen oder Staging-Daten fährst,
dann setz gezielt Indizes auf Filterspalten.

CREATE NONCLUSTERED INDEX ix_auftraege_datum
ON dbo.Auftraege(auftragsdatum)
INCLUDE (kunde_id, summe);

Keine Angst vor „Reporting only“-Indizes.
Wenn’s hilft, ist’s erlaubt.

Bonus: ExecutionLog auswerten

SELECT 
    c.name AS ReportName,
    el.TimeDataRetrieval,
    el.TimeProcessing,
    el.TimeRendering,
    el.ByteCount / 1024 AS Größe_kb,
    el.[RowCount]
FROM ReportServer.dbo.ExecutionLog3 el
JOIN ReportServer.dbo.Catalog c ON el.ReportID = c.ItemID
WHERE el.TimeStart > DATEADD(DAY, -7, GETDATE())
ORDER BY el.TimeDataRetrieval DESC;

So findest Du die Berichte, die am längsten brauchen.
Und kannst gezielt optimieren.

Mein Fazit

Langsame SSRS-Berichte sind kein Schicksal.
Du brauchst gutes SQL, saubere Datasets, wenig Schnickschnack.

Wenn Du willst, analysier ich Dir den Bericht.
Und sag Dir, was die Ladezeit killt – ehrlich, direkt, lösungsorientiert.