Warum funktioniert eine SSRS Bericht Zeit, wenn die gespeicherte Prozedur wird auf liefert Ergebnisse innerhalb von wenigen Sekunden basiert?

Question

Ich habe einen Bericht, die Daten aus einer gespeicherten Prozedur zurück macht. Profiler kann ich den Aufruf der gespeicherten Prozedur aus den Reporting Services fangen.

Der Bericht schlägt fehl besagt der Bericht Zeitüberschreitung noch kann ich die gespeicherte Prozedur aus SSMS ausführen und es gibt die Daten zurück in fünf bis sechs Sekunden.

Beachten Sie, im Beispiel Testlauf nur zwei Reihen an den Bericht zurückgegeben, obwohl innerhalb der gespeicherten Prozedur für das Rendern es Tausende oder sogar, um Millionen von Datensätzen arbeiten über wurden möglicherweise das Ergebnis zurück an Reporting-Diensten zusammenzustellen.

Ich weiß, dass die gespeicherte Prozedur mehr optimiert werden könnte, aber ich verstehe nicht, warum SSRS Timeout würde, wenn die Ausführung nur ein paar Sekunden zu nehmen scheint von SSMS auszuführen.

Auch hat ein anderes Problem aufgetaucht. Wenn ich die gespeicherte Prozedur neu erstellen, beginnt der Bericht perfekt zu machen, wieder in Ordnung. Das ist in Ordnung, außer nach kurzer Zeit beginnt der Bericht wieder ein Timeout.

Die Rückkehr der Zeit scheint, um neue Daten bezogen wird wobei die Haupttabelle hinzugefügt in dem Bericht gegen ausgeführt wird. Im Beispiel teste ich, nur hundert neue Aufzeichnungen waren genug eingeführt werden, um den Bericht zu vermasseln.

Ich stelle mir vor mehr richtig sein nicht den Bericht aus, die Ursache ist. Es wird die gespeicherte Prozedur, die die Zeit aus verursacht, wenn sie von SSRS ausgeführt wird.

Sobald es wieder timeing aus, die ich am besten fix ich bisher habe, ist die gespeicherte Prozedur neu zu erstellen. Dies scheint nicht eine ideale Lösung zu sein.

Das Problem scheint auch nur auf der Produktionsumgebung werden auftritt. Unsere Test- und Entwicklungsplattformen scheinen nicht das gleiche Problem aufweisen werden. Obwohl Entwickler und Test nicht das gleiche Volumen von Aufzeichnungen als Produktion haben.

Answer 1

Das Problem, wie Sie es beschrieben wird, scheint von Variationen des Ausführungsplan einiger Teile in Ihrer gespeicherten Prozedur zu kommen. Schauen Sie, was Statistiken werden auf den Tischen gehalten verwendet und wie das Hinzufügen neuer Zeilen beeinflussen sie.

  

Wenn Sie eine Menge von Zeilen in dem sind das Hinzufügen   Ende des Bereichs von einer Säule (denken   über das Hinzufügen automatische Nummerierung oder   Zeitstempel), das Histogramm für die   Spalte wird schnell veralten.   Sie können eine sofortige Aktualisierung erzwingen aus   T-SQL Ausführung des Updates   STATISTICS-Anweisung.

Answer 2

Ich habe auch dieses Problem, wo die SPROC Sekunden dauert, laufen noch SSRS einfach mal aus.

Ich habe aus meiner eigenen Erfahrung festgestellt, dass es ein paar verschiedener Methoden, dieses Problem zu überwinden.

1. Ist Parameter Sniffing! Wenn Sie Ihre gespeicherte Prozedur von SSRS ausgeführt wird, wird es „sniff“ out Ihre Parameter zu sehen, wie Ihr SPROC sie verwendet. SQL Server wird dann einen Ausführungsplan erzeugt auf der Grundlage ihrer Erkenntnisse. Das ist gut, das erste Mal, wenn Sie Ihre SPROC ausführen, aber Sie wollen nicht, dass es diese jedes Mal zu tun Sie Ihren Bericht ausführen. So erkläre ich einen neuen Satz von Variablen an der Spitze meiner SPROC ist, die einfach die Parameter in der Abfrage übergeben speichern und diese neuen Parameter in der Abfrage verwenden.

Beispiel:

CREATE PROCEDURE [dbo].[usp_REPORT_ITD001]
@StartDate DATETIME,
@EndDate DATETIME,
@ReportTab INT
AS

-- Deter parameter sniffing
DECLARE @snf_StartDate DATETIME = @StartDate
DECLARE @snf_EndDate DATETIME = @EndDate
DECLARE @snf_ReportTab INT = @ReportTab

... Dies bedeutet, dass, wenn Ihr SPORC von SSRS ausgeführt wird es nur in den ersten paar Zeilen in der Abfrage für die übergebenen Parameter nicht die ganze Ihre Anfrage suchen. Welche schneidet in SSRS Ausführungszeit erheblich.

1. Wenn Ihr SPROC viele temporäre Tabellen hat, die als Variablen (DECLARE @MyTable AS TABLE) deklariert sind, sind diese auf dem Server wirklich intensiv (In Bezug auf Speicher), wenn die Erstellung von Berichten. Durch die Verwendung von Hash-Temptabellen (SELECT MyCol1, MyCol2 INTO #MyTable) statt, wird SQL Server speichern Sie Ihre temporären Tabellen in TempDB auf dem Server statt im System memeory, so dass die Erstellung von Berichten weniger intensiv.

Answer 3

Hinzufügen irgendwann Option WITH RECOMPILE in der CREATE-Anweisung der gespeicherten Prozedur hilft. Dies ist wirksam, in Situationen, in denen die Anzahl der Datensätze durch die Prozedur Änderungen in der Art und Weise untersucht, dass der ursprüngliche Ausführungsplan nicht optimal ist.

Answer 4

Im Grunde alles, was ich habe, war bisher getan die sproc ein bisschen mehr zu optimieren und es scheint zumindest vorübergehend das Problem zu lösen.

Ich würde noch gerne wissen, was der Unterschied ist die sproc von SSMS und SSRS zwischen aufrufen.