SQL संकलक SQL सर्वर के प्रदर्शन को कितनी बुरी तरह से प्रभावित करते हैं?

Question

मैं एक SQL सर्वर 2005 का उदाहरण प्रस्तुत कर रहा हूं और मैं, PerfMon की SQLServer:SQL Statistics - SQL Compilations/secमीट्रिक के माध्यम से , मैं देखता हूं कि औसत लगभग 170 या तो है।

मैंने एसक्यूएल प्रोफाइलर को व्हीप्ड किया और एसपी के लिए देखा: कंपाइल या एसक्यूएल: कंपाइल इवेंट। जाहिरा तौर पर वे मौजूद नहीं हैं। मैंने पाया Stored Procedure/SP:Recompileऔर TSQL/SQL:StmtRecompileघटनाएँ। प्रोफाइलर में मेरे द्वारा देखे जाने वाले डेटा की मात्रा बताती है कि ये देखने की गलत घटनाएं हैं, हालांकि मुझे यकीन नहीं है।

तो मेरे सवाल। इनमें से किसी का भी उत्तर बहुत अच्छा होगा।

1. मैं कैसे देख सकता हूँ कि वास्तव में SQL सर्वर में क्या संकलन है?
2. क्या मैंने देखने के लिए गलत मैट्रिक्स चुना था? या तो Perfmon या SQL Profiler में?
3. SQL Profiler में घटनाओं Stored Procedure/SP:Recompileऔर TSQL/SQL:StmtRecompileघटनाओं के संबंध में ... वे अवधि मीट्रिक को शामिल नहीं करते हैं। अगर मैं सिस्टम को समय पर प्रभाव को देखने के लिए कोई रास्ता नहीं प्रदान करता तो मैं इन घटनाओं के प्रभाव को कैसे माप सकता हूं।

Answer 1

SQL संकलन / सेकंड एक अच्छा मीट्रिक है, लेकिन केवल बैच अनुरोध / सेकंड के साथ युग्मित होने पर । अपने आप से, प्रति सेकंड संकलन वास्तव में आपको बहुत कुछ नहीं बताता है।

आप 170 देख रहे हैं। यदि प्रति सेकंड बैच रीक केवल 200 (प्रभाव के लिए थोड़ा अतिरंजित) है, तो हाँ, आपको कारण की तह तक उतरने की आवश्यकता है (सबसे अधिक संभावना तदर्थ क्वेरी और एकल-उपयोग योजनाओं का अति प्रयोग)। लेकिन अगर आपके बैच प्रति सेकंड 5000 के बारे में माप रहे हैं, तो प्रति सेकंड 170 संकलन बिल्कुल भी खराब नहीं है। यह अंगूठे का एक सामान्य नियम है कि संकलन / सेकंड कुल बैच अनुरोध / सेकंड से 10% या कम होना चाहिए ।

यदि आप वास्तव में क्या कैश किया जा रहा है में ड्रिल करना चाहते हैं, तो निम्नलिखित डीएमवी का उपयोग करने वाले क्वेरी को चलाएं:

select
    db_name(st.dbid) as database_name,
    cp.bucketid,
    cp.usecounts,
    cp.size_in_bytes,
    cp.objtype,
    st.text
from sys.dm_exec_cached_plans cp
cross apply sys.dm_exec_sql_text(cp.plan_handle) st

सभी एकल-उपयोग योजनाओं (एक गणना) प्राप्त करने के लिए:

;with PlanCacheCte as 
(
    select
        db_name(st.dbid) as database_name,
        cp.bucketid,
        cp.usecounts,
        cp.size_in_bytes,
        cp.objtype,
        st.text
    from sys.dm_exec_cached_plans cp
    cross apply sys.dm_exec_sql_text(cp.plan_handle) st
)
select count(*)
from PlanCacheCte
where usecounts = 1

सभी कैश्ड प्लान की तुलना में आपके पास कितने सिंगल-यूज़ काउंट प्लान का अनुपात पाने के लिए:

declare @single_use_counts int, @multi_use_counts int

;with PlanCacheCte as 
(
    select
        db_name(st.dbid) as database_name,
        cp.bucketid,
        cp.usecounts,
        cp.size_in_bytes,
        cp.objtype,
        st.text
    from sys.dm_exec_cached_plans cp
    cross apply sys.dm_exec_sql_text(cp.plan_handle) st
    where cp.cacheobjtype = 'Compiled Plan'
)
select @single_use_counts = count(*)
from PlanCacheCte
where usecounts = 1

;with PlanCacheCte as 
(
    select
        db_name(st.dbid) as database_name,
        cp.bucketid,
        cp.usecounts,
        cp.size_in_bytes,
        cp.objtype,
        st.text
    from sys.dm_exec_cached_plans cp
    cross apply sys.dm_exec_sql_text(cp.plan_handle) st
    where cp.cacheobjtype = 'Compiled Plan'
)
select @multi_use_counts = count(*)
from PlanCacheCte
where usecounts > 1

select
    @single_use_counts as single_use_counts,
    @multi_use_counts as multi_use_counts,
    @single_use_counts * 1.0 / (@single_use_counts + @multi_use_counts) * 100
        as percent_single_use_counts

SQL सर्वर ट्रेस के माध्यम से कैप्चर किए गए ड्यूरेशन के लिए, यह रिकॉम्पाइल ईवेंट के लिए उपलब्ध नहीं है। यह अवधि या दर्द देखने के लिए इतना महत्वपूर्ण नहीं है कि योजना संकलन का कारण बन रहा है, क्योंकि मामला-दर-मामला स्थिति के लिए आप बहुत कुछ नहीं कर सकते हैं। समाधान योजना पुन: उपयोग (पैरामीटरकृत क्वेरी, संग्रहीत कार्यविधियाँ, आदि) के माध्यम से संकलन और पुनर्मिलन को सीमित करने का प्रयास करना है।

Answer 2

तीन प्रासंगिक काउंटर हैं जिन्हें PerfMon (या किसी अन्य 3 पार्टी समाधान) का उपयोग करके रिकॉर्ड किया जाना चाहिए। मुख्य बात यह है कि इन आँकड़ों को किसी तरह रिकॉर्ड किया जाए ।

• SQL सांख्यिकी \ बैच अनुरोध / सेकंड
• SQL सांख्यिकी \ SQL संकलन / सेकंड
• SQL सांख्यिकी \ SQL पुन: संकलन / सेकंड

जैसा कि थॉमस स्ट्रिंगर ने उल्लेख किया है , संकलन / बैच अनुरोध के अनुपात पर नज़र रखना अच्छा है। जाहिर है, कम बेहतर है, लेकिन "अच्छा" क्या है, इसके लिए केवल दिशानिर्देश हैं, और केवल आप ही तय कर सकते हैं कि क्या स्वीकार्य है। संकलन की संख्या को कम करके आप जो संपूर्ण लाभ प्राप्त करेंगे, वह कई कारकों पर निर्भर करता है।

मैं क्वेरी योजना के पुन: उपयोग की मात्रा का बोध पाने के लिए पुनर्मिलन / संकलन के अनुपात को देखना पसंद करता हूं । फिर, कम बेहतर है। इस मामले में, हालांकि, आप चाहते हैं कि सिस्टम में recompiles हो रहे हैं क्योंकि आँकड़े बदल जाते हैं (यदि DB केवल पढ़ा गया है और आपके पास recompiles हैं ... कुछ गलत हो सकता है)। जैसा कि मैंने पहले कहा था, "अच्छा" क्या है, इसके लिए केवल दिशानिर्देश हैं।

आप वास्तव में क्या करना चाहते हैं, समय के साथ इन नंबरों को ट्रेंड करें, इसलिए यदि आप अनुपातों में से किसी एक में एक विशाल स्पाइक देखते हैं, तो कुछ को तैनात किया गया है जो क्वेरी योजनाओं का सही उपयोग नहीं कर रहा है (आदर्श रूप से, यह परीक्षण के दौरान पकड़ा जाता है) - शार्क का उपयोग करें अपराधियों को खोजने के लिए विश्लेषण क्वेरी। इसके अलावा, यहाँ अक्सर पूछे जाने वाले प्रश्नों को खोजने के लिए एक है:

SELECT TOP 50
    qs.plan_generation_num,
    qs.execution_count,
    qs.statement_start_offset,
    qs.statement_end_offset,
    st.text
    FROM sys.dm_exec_query_stats qs
    CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
    WHERE qs.plan_generation_num > 1
    ORDER BY qs.plan_generation_num DESC

यदि आप CPU उपयोग के लिए आँकड़े भी रिकॉर्ड कर रहे हैं, तो सभी आँकड़ों को एक साथ सहसंबद्ध किया जा सकता है ताकि यह पता लगाया जा सके कि कितना दर्द होता है, और आपके सुधार में कितनी मदद मिलती है। व्यवहार में, मैंने पाया है कि एक कोर स्पोक पर सिर्फ एक खराब क्वेरी प्लान रणनीति भी एक सर्वर को अपने घुटनों पर ला सकती है; जाहिर है YMMV।