Sorgu hızlı çalışıyor, ancak saklı yordamda yavaş çalışıyor

Question

SQL 2005 profiler kullanarak bazı testler yapıyorum.

Sadece bir SQL sorgusu çalıştıran saklı yordamım var.

Kayıtlı yordamı çalıştırdığımda, uzun bir zaman alır ve 800.000 disk okuma gerçekleştirir.

Aynı sorguyu saklı yordamla çalıştırdığımda 14.000 disk okuması yapar.

Aynı sorguyu OPTION (recompile) ile çalıştırırsam 800.000 disk okuması gerektiğini buldum. Bundan

, ben saklı yordam her seferinde yeniden derlemeye ve bundan soruna neden olduğunu (muhtemelen hatalı) varsayımını.

Bu konuda biraz ışık tutabilir mi?

ARITHABORT ON ayarlı.

DECLARE 
@Contract_ID INT, 
@dt_From smalldatetime, 
@dt_To smalldatetime, 
@Last_Run_Date datetime, 
    @rv int 


SET @Contract_ID=38 
SET @dt_From='2010-09-01' 
SET @dt_To='2010-10-01' 
SET @Last_Run_Date='2010-10-08 10:59:59:070' 


-- This takes over fifteen seconds 
exec GET_IF_SETTLEMENT_ADJUSTMENT_REQUIRED @Contract_ID=@Contract_ID,@dt_From=@dt_From,@dt_To=@dt_To,@Last_Run_Date=@Last_Run_Date 

-- This takes less than one second! 
SELECT @rv = (CASE WHEN EXISTS 
(
select * from 
view_contract_version_last_volume_update 
inner join contract_version 
on contract_version.contract_version_id = view_contract_version_last_volume_update.contract_version_id 
where contract_version.contract_id=@Contract_ID 
and volume_date >= @dt_From 
and volume_date < @dt_To 
and last_write_date > @Last_Run_Date 
) 
THEN 1 else 0 end) 


-- With recompile option. Takes 15 seconds again! 
SELECT @rv = (CASE WHEN EXISTS 
(
select * from 
view_contract_version_last_volume_update 
inner join contract_version 
on contract_version.contract_version_id = view_contract_version_last_volume_update.contract_version_id 
where contract_version.contract_id=@Contract_ID 
and volume_date >= @dt_From 
and volume_date < @dt_To 
and last_write_date > @Last_Run_Date 
) 
THEN 1 else 0 end) OPTION(recompile) 

Answer 1

: Burada

CREATE PROCEDURE [dbo].[GET_IF_SETTLEMENT_ADJUSTMENT_REQUIRED] 
@Contract_ID int, 
@dt_From smalldatetime, 
@dt_To smalldatetime, 
@Last_Run_Date datetime 
AS 
BEGIN 
DECLARE @rv int 


SELECT @rv = (CASE WHEN EXISTS 
(
    select * from 
    view_contract_version_last_volume_update 
    inner join contract_version 
    on contract_version.contract_version_id = view_contract_version_last_volume_update.contract_version_id 
    where contract_version.contract_id=@Contract_ID 
    and volume_date >= @dt_From 
    and volume_date < @dt_To 
    and last_write_date > @Last_Run_Date 
) 
THEN 1 else 0 end) 

-- Note that we are RETURNING a value rather than SELECTING it. 
-- This means we can invoke this function from other stored procedures 
return @rv 
END 

bu sorunu göstermektedir koşuyorum bir komut dosyası: Burada

tüm saklı prosedürdür (Bu stackoverflow benzer bir sorun çözüldü, ama benimkini çözmedi)

Tamam, daha önce benzer sorunları yaşadık.

biz bu sabit şekilde, SP içindeki yerel parametreleri yaparak

DECLARE @LOCAL_Contract_ID int, 
     @LOCAL_dt_From smalldatetime, 
     @LOCAL_dt_To smalldatetime, 
     @LOCAL_Last_Run_Date datetime 

SELECT @LOCAL_Contract_ID = @Contract_ID, 
     @LOCAL_dt_From = @dt_From, 
     @LOCAL_dt_To = @dt_To, 
     @LOCAL_Last_Run_Date = @Last_Run_Date 

Sonra ziyade geçirildi parametrelere göre SP içindeki yerel parametreleri kullanmak gibi oldu.

Bu genellikle bizim için sorunu çözdü.

Biz bu koklama parametresine bağlı olduğuna inandığımız, ancak herhangi bir kanıt, üzgünüm ... X-) yok

DÜZENLEME:

bazı anlayışlı örnekler için Different Approaches to Correct SQL Server Parameter Sniffing göz at, açıklamalar ve düzeltmeler.

Answer 2

Bu özellikle datetime parametreleri ile, parametersniffing.

Answer 3

bir toplu ssms SQL parametre koklama ile ilgisi var bir SQL saklı yordam henüz anında çalıştırır içinde çalıştırmak için sonsuza kadar sürer neden konusunun neden olur sanırım.

Orada koklama parametresiyle ilgili birçok mükemmel makale var.

İşte bunlardan biri (ben yazmadım, sadece geçiyorum). Diğerleri de söylediğim gibi

http://www.sommarskog.se/query-plan-mysteries.html

Answer 4

, bu bir 'parametresi koklama' sorun olabilir.hat dahil deneyin:

OPTION (RECOMPILE) 

SQL sorgusu sonunda. http://blogs.technet.com/b/mdegre/archive/2012/03/19/what-is-parameter-sniffing.aspx

Answer 5

ben de bugün aynı problem var:

ne parametre koklama açıklayan burada bir makale vardır. SP'yi bıraktım ve yeniden oluşturdum ve işe yaradı. Bu SP önbelleği ile bir şeydir ve SP'yi bıraktığınızda önbelleğe alınmış plan kaldırılmıştır. Aynı şeyi deneyebilir veya önbelleği silmek için 'DBCC FREEPROCCACHE' kullanabilirsiniz. Benim konuda

Answer 6

Ben karşılaştık:

exec sp_updatestats 

ve 120s sadece 3'ler bu hız yukarıya benim sp. Güncelleme İstatistikleri hakkında daha fazla bilgiye buradan ulaşabilirsiniz https://msdn.microsoft.com/en-us/library/ms173804.aspx