Ich habe eine gespeicherte Prozedur, die ungefähr 50000 Datensätze in 10 Sekunden mit höchstens 2 Kernen in SSMS zurückgibt. Der SSRS-Bericht, der die gespeicherte Prozedur verwendet, benötigte 20 Minuten und würde den Prozessor für die gesamte Zeit auf einem 8-Core-Server auslasten. Der Bericht war relativ einfach (d. H. Keine Graphen, Berechnungen). Der Bericht schien nicht das Problem zu sein, da ich die 50K-Zeilen in eine temporäre Tabelle geschrieben habe und der Bericht die Daten in wenigen Sekunden anzeigen konnte. Ich habe viele verschiedene Ideen ausprobiert, um die gespeicherte Prozedur jedes Mal zu ändern, aber den ursprünglichen Code in einem separaten Fenster zu behalten. Nach einer Änderung der gespeicherten Prozedur, die auf den ursprünglichen Code zurückging, wurde die Bericht- und Serverauslastung schnell gestartet, vergleichbar mit der Leistung der gespeicherten Prozedur. Im Moment ist alles in Ordnung, aber ich möchte dem, was das verursacht hat, auf den Grund gehen, falls es wieder passiert. Irgendwelche Ideen?
Ich würde mit einer SQL Profiler-Ablaufverfolgung der gespeicherten Prozedur starten, wenn Sie sie normal ausführen, und dann denselben SP, wenn sie von SSRS aufgerufen wird. Stellen Sie sicher, dass Sie die Ausführungspläne mit einschließen, damit Sie sehen können, ob es einige schlechte Entscheidungen trifft (obwohl dies unwahrscheinlich erscheint - der SQL Server sollte unabhängig von der Quelle der Abfrage einen optimalen - oder zumindest konsistenten - Plan ausführen).
Wir hatten Fälle, in denen Business Objects gespeicherte Prozeduren dutzende Male ohne ersichtlichen Grund ausführen würden und es zu gelegentlich schrecklichen Leistungen führte, obwohl ich nie das gleiche Verhalten mit SSRS gesehen habe. Es könnte jedoch irgendwo beginnen. Sie sehen auch die Start- / Endzeiten der Ausführung - das macht es deutlich, wenn die Datenbankschicht auflegt oder wenn der SQL Server die Daten in 10 Sekunden zurückgibt und dann der SSRS-Dienst irgendwo erstickt.
Die primäre Lösung zur Beschleunigung von SSRS-Berichten besteht darin, die Berichte zu cachen . Wenn man das tut (entweder lädt ich den Cache zum Beispiel um 7:30 Uhr vor) oder speichert die Berichte auf Treffer, wird man massive Ladegeschwindigkeitsgewinne finden.
Möglicherweise finden Sie auch die monatlichen Neustarts der SSRS-Anwendungsdomäne, um Ihr Problem zu beheben.
Bitte beachtet, dass ich das täglich und professionell mache und nicht einfach auf SSRS poetisch werde
Zwischenspeichern in SSRS Ссылка
Laden Sie den Cache vor Ссылка
Wenn Sie nicht möchten, dass die ersten Berichte lange dauern und Ihre Daten statisch sind, dh ein tägliches Hauptbuch oder Ähnliches, dh die Daten über den Tag relativ statisch sind, können Sie die Cache-Lebensdauer erhöhen .
Schließlich können Sie sich auch dafür entscheiden, diese Berichte stattdessen über E-Mail-Abonnements zu erhalten, damit sie einen Excel-Bericht erhalten, den sie möglicherweise leichter finden und systematischer.
Sie können Parameter auch in SSRS verwenden, um eine einfache Analyse durch den Benutzer und schnellere Abfragen zu ermöglichen. Im Abfrage-Builder geben Sie IN (@SSN) in der Filter-Spalte ein, die Sie parametrisieren möchten. Sie finden diese dann im Parameter-Ordner oberhalb der Datenquellen oben links in Ihrer BIDS-GUI. [Wenn Sie den Datenquellenbereich in SSRS nicht sehen, drücken Sie STRG + ALT + D.
Siehe eine fast identische Frage hier: Performance-Issues mit SSRS
Tags und Links performance sql-server-2008 reporting-services ssrs-2008