Mam raport SSRS, który ładuje się powoli, prawdopodobnie z powodu blokowania błędów. Oto, co wiem.Raport SSRS trwa dłużej niż zapytanie; wypróbowany parametr sniffing i poprawki nolock
Po umieszczeniu zapytania, które doprowadza raport do okna zapytania Management Studio, uruchomienie trwa około 50 ms.
Uruchamiając kryteria raportu Byłem testów z interfejsu przeglądarki, wartości czasu od ReportServer..ExecutionLog (gdzie status = 'rsSuccess' AND ReportId = [thereport]) wahają się w następujący sposób:
TimeDataRetrieval: 95000-120000
TimeProcessing: 35000-50000
TimeRendering: 75-125
Ponieważ nie znam lepszego sposobu, aby to zrobić, ja monitorował sys.dm_exec_requests jak wpadłem raportu kilka razy i to zapytanie wydaje się być hangup:
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
wydaje polecenie to trwa mniej więcej tyle samo czasu co TimeDataRetrieval + TimeProcessin g wartości powyżej, więc uważam, że jest winowajcą. Też złapałem to robiącego podobną kreację CleanOrphanedSnapshots, więc wyobrażam sobie, że to jest część normalnych operacji SSRS. Do tej pory nie miałem szczęścia znajdowania powiązanych ustawień konfiguracyjnych w konstruktorze raportów lub samego kodu.
Sugerowane rozwiązania, które znalazłem w Internecie, dotyczą "parametru sniffing" i WITH (nolock). Pierwsza wydaje się być tylko w kontekście wywoływania procedury przechowywanej, której nie robi. Stworzyłem SP, aby sprawdzić, czy traktowanie parametrów wyprzedzających zmieni wynik i wydaje się być takie samo. Dodałem podpowiedź WITH (nolock), a także ustawienie izolacji, aby czytać bez zobowiązań bez powodzenia.
Jestem pewien, że brakuje mi czegoś prostego. Oto nadzieja, że ktoś wie, co to jest. Dzięki za pomoc.
Parametr wąchania - Fast query runs slow in SSRS nolock podejście - SSRS is locking table
Czy dzieje się to tylko z tym raportem lub ze wszystkimi raportami? – GayanSanjeewa
Ah ha! Dzięki, GayanSanjeewa. To mi pomoże zobaczyć, czego mi brakowało. Żaden z pozostałych raportów nie ma tego samego problemu, a w rzeczywistości w jednym innym raporcie znajdowało się to samo podstawowe zapytanie. Uświadomiłem sobie, że przeoczyłem dwa podraporty w raporcie o problemie. Jeśli czytam to prawo, to każdy z nich jest uruchamiany dla każdego rekordu w głównym raporcie zwrotnym (i same w sobie nie są zbyt wydajne). Zgaduję, że albo będę musiał przeprojektować raport z lepszą podstawową kwerendą, albo sprawdzić, czy mogę poprawić zapytania podraportów, aby działały efektywnie. Dzięki jeszcze raz! – tetch
AKTUALIZACJA: Tak, miałem dwa nienormalne poglądy, które zoptymalizowałem (lub przynajmniej ulepszyłem) i otrzymałem czas zgłoszenia od 2-3 minut do 20-25 sekund. Blokada CheckSessionLock nadal występuje, więc domyślam się, że właśnie tak działa SSRS. – tetch