क्वेरी तेजी से चलती है, लेकिन संग्रहित प्रक्रिया में धीमी गति से चलती है

Question

मैं SQL 2005 प्रोफाइलर का उपयोग करके कुछ परीक्षण कर रहा हूं।

मेरे पास एक संग्रहीत प्रक्रिया है जो केवल एक SQL क्वेरी चलाती है।

जब मैं संग्रहीत प्रक्रिया चलाता हूं, तो इसमें काफी समय लगता है और 800,000 डिस्क पढ़ता है।

जब मैं संग्रहीत प्रक्रिया से अलग एक ही क्वेरी चलाता हूं, तो यह 14,000 डिस्क पढ़ता है।

मुझे पता चला कि यदि मैं OPTION (recompile) के साथ एक ही क्वेरी चलाता हूं, तो इसमें 800,000 डिस्क पढ़ने लगते हैं।

इससे, मैं (संभावित रूप से गलत) धारणा करता हूं कि संग्रहीत प्रक्रिया हर बार फिर से संकलित होती है, और इससे समस्या आती है।

क्या कोई इस पर कुछ प्रकाश डाल सकता है?

मैंने ARITHABORT चालू किया है। (यह stackoverflow पर एक ऐसी ही समस्या हल हो, लेकिन मेरा समाधान नहीं)

यहाँ पूरे संग्रहीत प्रक्रिया है:

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

:

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 

यहाँ एक स्क्रिप्ट मैं चलाने कि समस्या को दर्शाता है है

ठीक है, हमारे पास पहले इसी तरह के मुद्दे थे।

जिस तरह से हम यह तय, अंदर सपा स्थानीय पैरामीटर बनाकर किया गया था, ऐसा है कि

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 

हम तो बल्कि पैरामीटर में पारित किया गया था की तुलना में अंदर सपा स्थानीय पैरामीटर का उपयोग करें।

यह आम तौर पर हमारे लिए मुद्दा तय करता है।

हम मानते हैं कि यह सूँघने पैरामीटर के लिए कारण हो सकता है, लेकिन किसी भी सबूत, खेद ... एक्स) की जरूरत नहीं है

संपादित करें:

कुछ व्यावहारिक उदाहरण के लिए Different Approaches to Correct SQL Server Parameter Sniffing पर एक नज़र डालें, स्पष्टीकरण और फिक्स।

Answer 2

मैं इस विशेष रूप से दिनांक मानकों के साथ, द्वारा parametersniffing.

Answer 3

क्यों एक बैच के अंदर किसी SQL संग्रहित प्रक्रिया अभी तक तत्क्षण चलाता SSMS में एसक्यूएल पैरामीटर सूँघने से कोई लेना देना नहीं है चलाने के लिए हमेशा के लिए ले जाता है के मुद्दे के कारण होता है लगता है।

वहां पैरामीटर स्नीफिंग पर कई उत्कृष्ट लेख हैं।

यहां उनमें से एक है (मैंने इसे लिखा नहीं है, बस इसे पास कर रहा है)।

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

Answer 4

दूसरों के रूप में उल्लेख किया है, यह एक 'पैरामीटर सूँघने' समस्या हो सकती है।लाइन सहित:

OPTION (RECOMPILE) 

आपकी SQL क्वेरी के अंत में प्रयास करें। http://blogs.technet.com/b/mdegre/archive/2012/03/19/what-is-parameter-sniffing.aspx

Answer 5

मैं भी आज एक ही समस्या है:

एक लेख यहाँ समझा क्या पैरामीटर सूंघने है नहीं है। मैंने एसपी को गिरा दिया और फिर से बनाया और यह काम किया। यह एसपी कैश के साथ कुछ है और जब एसपी गिरा दिया गया तो कैश की गई योजना हटा दी गई है। कैश हटाने के लिए आप इसे भी कोशिश कर सकते हैं या 'डीबीसीसी फ्रीप्रोकैच' का उपयोग कर सकते हैं।

Answer 6

मेरी मुद्दे पर मैं हुई:

exec sp_updatestats 

और 120S के लिए सिर्फ 3s से मेरी एसपी इस गति को। सांख्यिकी अद्यतन करने के बारे में अधिक जानकारी यहां मिल सकती है https://msdn.microsoft.com/en-us/library/ms173804.aspx