Ich habe einen SSRS-Bericht, der langsam lädt, vermutlich von Sperrfehlern. Hier ist, was ich weiß.SSRS-Bericht dauert länger als Abfrage; versuchte Parameter sniffing & nolock Fixes
Wenn ich die Abfrage, die den Bericht steuert, in ein Abfragefenster von Management Studio versetzen, dauert die Ausführung etwa 50 ms.
Wenn die Berichtskriterien läuft ich von der Browser-Schnittstelle zu testen habe, die Zeitwerte von ReportServer..ExecutionLog (WHERE Status = 'rsSuccess UND ReportID = [der Report]) liegen wie folgt:
TimeDataRetrieval: 95000-120000
TimeProcessing: 35000-50000
TimeRendering: 75-125
Weil ich weiß, einen besseren Weg, es nicht zu tun, überwachte ich die sys.dm_exec_requests als ich den Bericht ein paar mal lief und diese Abfrage scheint die hangup zu sein:
CREATE PROCEDURE [dbo].[CheckSessionLock]
@SessionID as varchar(32) AS
DECLARE @Selected nvarchar(32)
SELECT @Selected=SessionID
FROM [ReportServerTempDB].dbo.SessionLock
WITH (ROWLOCK) WHERE SessionID = @SessionID
es scheint, dieser Befehl nimmt ungefähr die gleiche Zeit wie TimeDataRetrieval + TimeProcessin g Werte oben, so glaube ich, dass es der Schuldige ist. Ich habe es auch bei der Erstellung von CleanOrphanedSnapshots entdeckt, daher stelle ich mir vor, dass es sich um normale SSRS-Operationen handelt. Bislang hatte ich noch kein Glück, ähnliche Konfigurationseinstellungen im Report Builder oder im Code selbst zu finden.
Lösungsvorschläge, die ich online gefunden habe, haben mit "parameter sniffing" und WITH (nolock) zu tun. Ersteres scheint nur im Zusammenhang mit dem Aufruf einer gespeicherten Prozedur zu stehen, was dies nicht tut. Ich habe einen SP erstellt, um zu sehen, ob die Behandlung von Vorbelegungsparametern das Ergebnis ändern würde und es scheint dasselbe zu sein. Ich habe den Hinweis WITH (nolock) hinzugefügt und die Isolation so eingestellt, dass ich ohne Erfolg non Committed lesen kann.
Ich bin sicher, ich vermisse etwas Einfaches. Hoffentlich weiß jemand, was es ist. Danke für Ihre Hilfe.
Parameter Sniffing - Fast query runs slow in SSRS nolock Ansatz - SSRS is locking table
Ist dies nur mit diesem Bericht oder alle Ihre Berichte passiert? – GayanSanjeewa
Ah ha! Danke, GayanSanjeewa. Das hilft mir zu sehen, was ich vermisst habe. Keiner der anderen Berichte hat das gleiche Problem, und tatsächlich enthielt ein anderer Bericht die GENAUE gleiche Kernabfrage. Das hat mir gezeigt, dass ich innerhalb des Problemberichts zwei Unterberichte übersehen habe. Wenn ich dieses Recht lese, werden sie für jeden Datensatz im primären Berichts-Return ausgeführt (und sind selbst nicht sehr effizient). Ich vermute, dass ich den Bericht entweder mit einer besseren Kernabfrage neu gestalten oder prüfen muss, ob ich die Unterberichtabfragen optimieren kann, um effizient zu arbeiten. Danke noch einmal! – tetch
UPDATE: Ja, ich hatte zwei abscheuliche Ansichten, die ich optimiert (oder zumindest verbessert) habe und die Berichtszeit von 2-3 Minuten auf 20-25 Sekunden gesenkt habe. Die CheckSessionLock tritt immer noch auf, also denke ich, dass SSRS so funktioniert. – tetch