Muhtemelen kilitleme hatalarından kaynaklanan bir SSRS raporum var. İşte bildiğim.SSRS Raporu, sorgudan daha uzun sürüyor; parametre sniffing & nolock fixes parametresini denediniz
Raporu bir Management Studio sorgu penceresine yönlendiren sorguyu koyarsam, çalıştırması yaklaşık 50 ms sürer. Ben tarayıcı arabiriminden test ettik rapor kriterlerini çalıştırırken aşağıdaki gibi
, ReportServer..ExecutionLog (Durum = 'rsSuccess' VE ReportID = [thereport]) den saat değerleri aralığı:
TimeDataRetrieval: 95000-120000
TimeProcessing: 35000-50000
TimeRendering: 75-125
Ben raporu bir kaç kere koşarken ben sys.dm_exec_requests izlenir, bunu yapmak için daha iyi bir yol bilmiyorum çünkü ve bu sorgu mesele gibi görünüyor:
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
görünüyor bu komut alır TimeDataRetrieval + TimeProcessin ile aynı miktarda Yukarıdaki g değerleri, bu yüzden suçlu olduğuna inanıyorum. Ben de benzer bir CleanOrphanedSnapshot yapısını yakaladım, bu yüzden bu normal SSRS işlemleri olduğunu hayal ediyorum. Şimdiye kadar rapor oluşturucuda veya kodun kendisinde ilgili konfigürasyon ayarlarını bulma şansım olmadı.
Önerilen çözümlerin çevrimiçi bulunduğunu "parameter sniffing" ve WITH (nolock) ile yapmak zorundayım. Birincisi, bunun yapılmadığı saklı bir prosedürün çağrılması bağlamında görünmektedir. Önceden tanımlı parametrelerin tedavisinin sonucu değiştirip değiştirmeyeceğini görmek için bir SP oluşturdum ve aynı görünüyor. WITH (nolock) ipucunu ekledim, ayrıca şanssızlıkla okunan okumaya yönelik izolasyonu da ekledim.
Eminim basit bir şey eksik. İşte birilerinin ne olduğunu bilmesini umuyoruz. Yardım ettiğin için teşekkür ederim. koklama
Parametre - Fast query runs slow in SSRS nolock yaklaşımı - Yukarıdaki Martin Smith tarafından açıklama talebi Başına SSRS is locking table
Bu, yalnızca bu raporda veya tüm raporlarınızda oluyor mu? – GayanSanjeewa
Ah ha! Sağol GayanSanjeewa. Bu, neyi kaçırdığımı görmeme yardım et. Diğer raporların hiçbiri aynı soruna sahip değildir ve aslında başka bir raporda da aynı temel sorgu EXACT vardı. Bu, sorun raporunda iki alt raporları gözden kaçırdığımı anlamamı sağladı. Bu hakkı okuyorsam, her biri birincil rapor geri dönüşündeki her bir kayıt için çalıştırılıyor (ve kendileri çok verimli değiller). Sanırım, raporu daha iyi bir çekirdek sorguyla yeniden tasarlamalıyım ya da verimli bir şekilde çalışmak için alt rapor sorgularını değiştirip değiştiremeyeceğimi göreceğim. Tekrar teşekkürler! – tetch
GÜNCELLEME: Evet En iyi duruma getirilmiş (veya en azından gelişmiş) ve rapor süresini 2-3 dakikadan 20-25 saniyeye düşürdüğüm iki berbat görüşüm vardı. CheckSessionLock hala gerçekleşir, bu yüzden SSRS'nin nasıl çalıştığını tahmin ediyorum. – tetch