पिछले 4 घंटों में अधिकांश क्वेरी प्लान पुनः बनाए गए

9

मुझे अपने SQL सर्वर डेटाबेस के प्रदर्शन के साथ एक समस्या मिली है। मुझे यह टूल sp_BlitzCache मिला है । कमांड के निष्पादन के बाद, मुझे यह कथन मिला:

आपके पास पिछले 24 घंटों में 92.00% योजनाएँ बनी हैं, और पिछले 4 घंटों में 92.00% योजनाएँ बनी हैं।

जब मैंने समस्या की पहचान की (एसक्यूएल सर्वर प्रोफाइलर का उपयोग करके, मैंने StmtRecompile ईवेंट आवृत्तियों की जाँच की है), मैं केवल कुछ पूर्ण-पाठ खोज प्रश्नों को खोजने में सक्षम था, जिन्हें अक्सर पुनर्निर्माण किया जाता है। हालाँकि, पूर्ण-पाठ खोज क्वेरीज़ सभी प्रश्नों के लगभग 5% का प्रतिनिधित्व करती है।

क्या आपके पास कोई सुझाव है जो शेष 87% योजनाओं के मनोरंजन का कारण हो सकता है?

मुझे SQL Server 2012 (संस्करण 11.0.6567.0) मिला है।

संपादित करें: मैंने अपने प्रदर्शन काउंटर जोड़े हैं 

+---------------------------+--------------------------------+--------------+
|        object_name        |          counter_name          |  cntr_value  |
+---------------------------+--------------------------------+--------------+
| SQLServer:Buffer Manager  | Background writer pages/sec    |            0 |
| SQLServer:Buffer Manager  | Buffer cache hit ratio         |        28436 |
| SQLServer:Buffer Manager  | Buffer cache hit ratio base    |        28436 |
| SQLServer:Buffer Manager  | Checkpoint pages/sec           |      8259452 |
| SQLServer:Buffer Manager  | Database pages                 |      4434337 |
| SQLServer:Buffer Manager  | Free list stalls/sec           |            9 |
| SQLServer:Buffer Manager  | Integral Controller Slope      |            0 |
| SQLServer:Buffer Manager  | Lazy writes/sec                |         5608 |
| SQLServer:Buffer Manager  | Page life expectancy           |       438901 |
| SQLServer:Buffer Manager  | Page lookups/sec               | 122694703703 |
| SQLServer:Buffer Manager  | Page reads/sec                 |     60994608 |
| SQLServer:Buffer Manager  | Page writes/sec                |    126076564 |
| SQLServer:Buffer Manager  | Readahead pages/sec            |     45305420 |
| SQLServer:Buffer Manager  | Target pages                   |    130990080 |
| SQLServer:Buffer Node     | Database pages                 |      4434337 |
| SQLServer:Buffer Node     | Page life expectancy           |       438901 |
| SQLServer:Buffer Node     | Local node page lookups/sec    |            0 |
| SQLServer:Buffer Node     | Remote node page lookups/sec   |            0 |
| SQLServer:Memory Manager  | External benefit of memory     |            0 |
| SQLServer:Memory Manager  | Connection Memory (KB)         |         3304 |
| SQLServer:Memory Manager  | Database Cache Memory (KB)     |     35474784 |
| SQLServer:Memory Manager  | Free Memory (KB)               |     13229808 |
| SQLServer:Memory Manager  | Granted Workspace Memory (KB)  |            0 |
| SQLServer:Memory Manager  | Lock Memory (KB)               |       455928 |
| SQLServer:Memory Manager  | Lock Blocks Allocated          |      1798154 |
| SQLServer:Memory Manager  | Lock Owner Blocks Allocated    |      3568588 |
| SQLServer:Memory Manager  | Lock Blocks                    |        10562 |
| SQLServer:Memory Manager  | Lock Owner Blocks              |        10617 |
| SQLServer:Memory Manager  | Maximum Workspace Memory (KB)  |     43368000 |
| SQLServer:Memory Manager  | Memory Grants Outstanding      |            0 |
| SQLServer:Memory Manager  | Memory Grants Pending          |            0 |
| SQLServer:Memory Manager  | Optimizer Memory (KB)          |         1400 |
| SQLServer:Memory Manager  | Reserved Server Memory (KB)    |            0 |
| SQLServer:Memory Manager  | SQL Cache Memory (KB)          |       229112 |
| SQLServer:Memory Manager  | Stolen Server Memory (KB)      |      8063232 |
| SQLServer:Memory Manager  | Log Pool Memory (KB)           |         4192 |
| SQLServer:Memory Manager  | Target Server Memory (KB)      |     56934400 |
| SQLServer:Memory Manager  | Total Server Memory (KB)       |     56767824 |
| SQLServer:Memory Node     | Database Node Memory (KB)      |     35474784 |
| SQLServer:Memory Node     | Free Node Memory (KB)          |     13229808 |
| SQLServer:Memory Node     | Foreign Node Memory (KB)       |            0 |
| SQLServer:Memory Node     | Stolen Node Memory (KB)        |      8063208 |
| SQLServer:Memory Node     | Target Node Memory (KB)        |     56934376 |
| SQLServer:Memory Node     | Total Node Memory (KB)         |     56767800 |
+---------------------------+--------------------------------+--------------+
sql-server  sql-server-2012  query-performance  sp-blitzcache 
— Marcin Topolewski
स्रोत
शायद किसी ने DBCC FREEPROCCACHE भाग लिया? : पी
— डैनियल ब्योर्क
@ डैनियलबॉजक मैं एकमात्र व्यक्ति हूं जिसे इस तरह की चीजें करने की अनुमति है, इसलिए मुझे नहीं लगता कि यह कारण है। हालांकि, मैं इसकी जांच करूंगा।
— मार्सिन टॉपोल्स्की
क्या आप पैरामीट्रिक प्रश्नों या संग्रहीत प्रक्रियाओं का उपयोग कर रहे हैं? या यह समस्या है कि आपके एसक्यूएल में स्ट्रिंग / नंबर शाब्दिक हैं, और इसलिए योजनाओं का पुन: उपयोग नहीं किया जा सकता है?
— जेम्स जेड
@JamesZ हां, मैं बहुत सारे पैराड्राइज्ड प्रश्नों का उपयोग कर रहा हूं। टूल जो मैंने अपनी पोस्ट में उल्लेख किया है, ब्लिट्ज़चेच का कहना है कि मुझे पैरामीटर सूँघने की समस्या है।
— Marcin Topolewski
1
क्या आप अनुक्रमित पुन: निर्माण कर रहे हैं या रात को आँकड़े अपडेट कर रहे हैं? शायद सर्वर पर मेमोरी का दबाव है?
— एरिक डार्लिंग

जवाबों:

6

योजना निर्माण समय का परीक्षण करने के लिए उपयोग की जाने वाली क्वेरी यह है 

WITH x AS (
SELECT SUM(CASE WHEN DATEDIFF(HOUR, deqs.creation_time, SYSDATETIME()) <= 24 THEN 1 ELSE 0 END) AS [plans_24],
       SUM(CASE WHEN DATEDIFF(HOUR, deqs.creation_time, SYSDATETIME()) <= 4 THEN 1 ELSE 0 END) AS [plans_4],
       SUM(CASE WHEN DATEDIFF(HOUR, deqs.creation_time, SYSDATETIME()) <= 1 THEN 1 ELSE 0 END) AS [plans_1],
       COUNT(deqs.creation_time) AS [total_plans]
FROM sys.dm_exec_query_stats AS deqs
)
SELECT CONVERT(DECIMAL(3,2), NULLIF(x.plans_24, 0) / (1. * NULLIF(x.total_plans, 0))) * 100 AS [percent_24],
       CONVERT(DECIMAL(3,2), NULLIF(x.plans_4 , 0) / (1. * NULLIF(x.total_plans, 0))) * 100 AS [percent_4],
       CONVERT(DECIMAL(3,2), NULLIF(x.plans_1 , 0) / (1. * NULLIF(x.total_plans, 0))) * 100 AS [percent_1],
       @@SPID AS SPID
INTO #plan_creation
FROM x
OPTION (RECOMPILE) ;

साथ ही एसपी कुछ सुराग भी प्रदान करता है जहां पर आपके आगे के शोध को शुरू करना है

यदि ये प्रतिशत अधिक हैं, तो यह मेमोरी दबाव या योजना कैश अस्थिरता का संकेत हो सकता है

उपरोक्त सुराग के अलावा, जांचें कि क्या आपका सर्वर फिर से चालू हो गया है।

यदि आपके सर्वर को पुनरारंभ नहीं किया गया है, तो नीचे दृष्टिकोण है जो मैं ले जाऊंगा

  • जाँच करें कि क्या आपका सामना कर रहे स्मृति दबाव

पहले देखें, यदि आपकी मेमोरी सेटिंग्स को बेहतर तरीके से कॉन्फ़िगर किया गया है। यदि आप मेमोरी दबाव का सामना कर रहे हैं, तो यह देखने के लिए आप काउंटरों का उपयोग कर सकते हैं

मेमोरी: उपलब्ध एमबी
एसक्यूएल बफर: नि: शुल्क पेज
एसक्यूएल बफर: पेज लाइफ
एसक्यूएल बफर: आलसी राइट्स

यदि आप स्मृति दबाव का सामना कर रहे हैं, तो आप उन प्रश्नों को देख और ट्यून कर सकते हैं जो अधिक मेमोरी का उपयोग कर रहे हैं या अधिक मेमोरी जोड़ने का प्रयास कर रहे हैं

आपके पास पुनरावृत्ति का कारण बनने वाले क्वेरीज़ हो सकते हैं । उनमें से कुछ में शामिल हैं

  • एक तालिका या दृश्य द्वारा किए गए परिवर्तन क्वेरी द्वारा संशोधित (वैकल्पिक तालिका और अन्य दृश्य)।

  • एकल प्रक्रिया में किए गए परिवर्तन, जो उस प्रक्रिया के लिए सभी योजनाओं को कैश से बदल देंगे (अलर्ट प्रक्रिया)।

  • निष्पादन योजना द्वारा उपयोग किए जाने वाले किसी भी सूचकांक में परिवर्तन

  • निष्पादन योजना द्वारा उपयोग किए गए आंकड़ों पर अपडेट, या तो स्पष्ट रूप से एक स्टेटमेंट, जैसे कि अद्यतन सांख्यिकी, या स्वचालित रूप से उत्पन्न।

  • निष्पादन योजना द्वारा उपयोग किए गए सूचकांक को छोड़ना।

आप प्लान कैशिंग के बारे में अधिक जानकारी के लिए इस श्वेत पत्र को भी देख सकते हैं

https://technet.microsoft.com/en-us/library/ee343986(v=sql.100).aspx

— TheGameiswar
स्रोत
मैंने अपने प्रदर्शन काउंटर जोड़े हैं, क्या आप मुझे इस मूल्यों की व्याख्या करने में मदद कर सकते हैं?
— Marcin Topolewski
आप यहां विस्तृत मेमोरी से संबंधित काउंटर देख सकते हैं: blogs.msdn.microsoft.com/teekamg/2007/11/06/…
— TheGameiswar
@ TheGameiswar आप कहते हैं "आप प्रश्नों को चला सकते हैं जो पुनर्मूल्यांकन का कारण बनते हैं ... जैसे कि सूचकांक में परिवर्तन, आंकड़ों पर अपडेट"। अगर मैं हर रात विखंडन + अद्यतन आँकड़ों के आधार पर इंडेक्स रीगॉर / पुनर्निर्माण करता हूं, तो क्या इसका मतलब है कि मेरी योजनाएं हर दिन (या लगभग सभी) फिर से बनाई जाएंगी? क्या यही समस्या है?
— डेनियल पैक्वे-हार्वे
2

जोड़ने के लिए @ TheGameiswar ने कहा कि आप इस क्वेरी को उन योजनाओं का विवरण देखने के लिए भी चला सकते हैं जो कैश से प्राप्त नहीं होती हैं।

;with
    xmlnamespaces (N'http://schemas.microsoft.com/sqlserver/2004/07/showplan' as DYN)
select
    db_name(st.dbid) as DBName
    , object_schema_name(st.objectid, st.dbid) as SchemaName
    , object_name(st.objectid, st.dbid) as ObjectName
    , ecp.objtype
    , st.text
    , qp.query_plan.value('(/DYN:ShowPlanXML/DYN:BatchSequence/DYN:Batch/DYN:Statements/DYN:StmtSimple/@RetrievedFromCache)[1]', 'varchar(100)') as RetrievedFromCache
    , qp.query_plan
into #temp
from sys.dm_exec_cached_plans ecp
    outer apply sys.dm_exec_query_plan(ecp.plan_handle) qp
    outer apply sys.dm_exec_sql_text(ecp.plan_handle) st

select
    *
from #temp t
where t.RetrievedFromCache is null
    and t.DBName is not null
order by t.DBName, t.SchemaName, t.ObjectName;
— डीन सावोविक
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.