SQL सर्वर की अपेक्षा के आँकड़े या कृपया मुझे बताएं कि यह कहाँ दर्द होता है

आपने कितनी बार SQL सर्वर प्रदर्शन समस्याओं का अनुभव किया है और निर्णय लिया है कि कहाँ देखना है?

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

बड़ी खबर यह है कि एसक्यूएल सर्वर को पता है कि प्रदर्शन की समस्याएं क्या हैं, और आपको जो कुछ भी करने की ज़रूरत है, वह उससे पूछ रहा है ... और फिर सही ढंग से व्याख्या करता है कि वह क्या कहता है और थोड़ा जटिल हो सकता है।

निम्नलिखित जानकारी उन लोगों के लिए है जो हर अपेक्षा के बारे में चिंता करते हैं और समझते हैं कि इसका क्या कारण है। उम्मीदें हमेशा पैदा होती हैं। यह SQL सर्वर का कार्य शेड्यूलिंग सिस्टम कैसे काम करता है।

थ्रेड प्रोसेसर का उपयोग करता है और "RUNNING" की स्थिति रखता है जब तक कि उसे संसाधन तक पहुंचने की प्रतीक्षा करने की आवश्यकता का सामना नहीं करना पड़ता है। इस स्थिति में, इसे निलंबित स्थिति (SUSPENDED) में थ्रेड की एक अनियंत्रित सूची में रखा गया है। इसी समय, प्रोसेसर की पहुंच की प्रतीक्षा कर रहे थ्रेड्स की कतार में अगला धागा, FIFO सिद्धांत (पहले-पहले आउट) के अनुसार आयोजित किया जाता है, और स्थिति "रन करने के लिए तैयार" (RUNNABLE) प्रोसेसर तक पहुंच जाती है और "रनिंग" हो जाती है। यदि "निलंबित" स्थिति में एक थ्रेड एक सूचना प्राप्त करता है कि उसका संसाधन उपलब्ध है, तो यह "निष्पादन के लिए तैयार" हो जाता है और निष्पादन के लिए तैयार धागे की कतार के अंत में रखा जाता है। प्रवाह "चल" श्रृंखला के साथ अपने चक्रीय आंदोलन को जारी रखता है - "निलंबित" - "निष्पादन के लिए तैयार" जब तक कार्य पूरा नहीं हो जाता। आप डायनेमिक मैनेजमेंट व्यू (DMV) sysinos_exec_requests का उपयोग करके प्रक्रियाओं और उनकी स्थितियों को देख सकते हैं।

SQL सर्वर उस समय की निगरानी करता है जो किसी रनिंग स्थिति से बाहर निकलने वाले थ्रेड के बीच समाप्त हो जाता है और उस स्थिति में वापस आ जाता है, इसे "प्रतीक्षा समय" और तैयार राज्य में बिताए समय के रूप में परिभाषित करते हुए, इसे "समय" के रूप में परिभाषित करता है संकेत प्रतीक्षा समय ”, अर्थात् प्रोसेसर तक पहुंच प्राप्त करने के लिए संसाधनों की उपलब्धता के बारे में संकेत प्राप्त करने के बाद धागे को कितना समय चाहिए। हमें यह समझने की जरूरत है कि कुल टाइमआउट से सिग्नल टाइमआउट को घटाकर थ्रेड को "पॉज़्ड" अवस्था में, "रिसोर्स वेट टाइम" कहा जाता है।

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

आप DMV sysinos_os_wait_stats का उपयोग करके संचित प्रतीक्षा आँकड़ों के लिए SQL सर्वर को क्वेरी कर सकते हैं। बहुत से लोग किसी प्रकार के सारांश कोड में DMV कॉल को लपेटना पसंद करते हैं। नीचे 2016 के रूप में मेरी स्क्रिप्ट का नवीनतम संस्करण है, जो सभी संस्करणों के साथ काम करता है और इसमें SQL सर्वर 2016 के लिए प्रतीक्षा प्रकार शामिल हैं ( यहां Azure में उपयोग के लिए स्क्रिप्ट का संस्करण देखें):

WITH [Waits] AS (SELECT [wait_type], [wait_time_ms] / 1000.0 AS [WaitS], ([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS], [signal_wait_time_ms] / 1000.0 AS [SignalS], [waiting_tasks_count] AS [WaitCount], 100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage], ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum] FROM sys.dm_os_wait_stats WHERE [wait_type] NOT IN ( N'BROKER_EVENTHANDLER', N'BROKER_RECEIVE_WAITFOR', N'BROKER_TASK_STOP', N'BROKER_TO_FLUSH', N'BROKER_TRANSMITTER', N'CHECKPOINT_QUEUE', N'CHKPT', N'CLR_AUTO_EVENT', N'CLR_MANUAL_EVENT', N'CLR_SEMAPHORE', -- Maybe uncomment these four if you have mirroring issues N'DBMIRROR_DBM_EVENT', N'DBMIRROR_EVENTS_QUEUE', N'DBMIRROR_WORKER_QUEUE', N'DBMIRRORING_CMD', N'DIRTY_PAGE_POLL', N'DISPATCHER_QUEUE_SEMAPHORE', N'EXECSYNC', N'FSAGENT', N'FT_IFTS_SCHEDULER_IDLE_WAIT', N'FT_IFTSHC_MUTEX', -- Maybe uncomment these six if you have AG issues N'HADR_CLUSAPI_CALL', N'HADR_FILESTREAM_IOMGR_IOCOMPLETION', N'HADR_LOGCAPTURE_WAIT', N'HADR_NOTIFICATION_DEQUEUE', N'HADR_TIMER_TASK', N'HADR_WORK_QUEUE', N'KSOURCE_WAKEUP', N'LAZYWRITER_SLEEP', N'LOGMGR_QUEUE', N'MEMORY_ALLOCATION_EXT', N'ONDEMAND_TASK_QUEUE', N'PREEMPTIVE_XE_GETTARGETSTATE', N'PWAIT_ALL_COMPONENTS_INITIALIZED', N'PWAIT_DIRECTLOGCONSUMER_GETNEXT', N'QDS_PERSIST_TASK_MAIN_LOOP_SLEEP', N'QDS_ASYNC_QUEUE', N'QDS_CLEANUP_STALE_QUERIES_TASK_MAIN_LOOP_SLEEP', N'QDS_SHUTDOWN_QUEUE', N'REDO_THREAD_PENDING_WORK', N'REQUEST_FOR_DEADLOCK_SEARCH', N'RESOURCE_QUEUE', N'SERVER_IDLE_CHECK', N'SLEEP_BPOOL_FLUSH', N'SLEEP_DBSTARTUP', N'SLEEP_DCOMSTARTUP', N'SLEEP_MASTERDBREADY', N'SLEEP_MASTERMDREADY', N'SLEEP_MASTERUPGRADED', N'SLEEP_MSDBSTARTUP', N'SLEEP_SYSTEMTASK', N'SLEEP_TASK', N'SLEEP_TEMPDBSTARTUP', N'SNI_HTTP_ACCEPT', N'SP_SERVER_DIAGNOSTICS_SLEEP', N'SQLTRACE_BUFFER_FLUSH', N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP', N'SQLTRACE_WAIT_ENTRIES', N'WAIT_FOR_RESULTS', N'WAITFOR', N'WAITFOR_TASKSHUTDOWN', N'WAIT_XTP_RECOVERY', N'WAIT_XTP_HOST_WAIT', N'WAIT_XTP_OFFLINE_CKPT_NEW_LOG', N'WAIT_XTP_CKPT_CLOSE', N'XE_DISPATCHER_JOIN', N'XE_DISPATCHER_WAIT', N'XE_TIMER_EVENT') AND [waiting_tasks_count] > 0 ) SELECT MAX ([W1].[wait_type]) AS [WaitType], CAST (MAX ([W1].[WaitS]) AS DECIMAL (16,2)) AS [Wait_S], CAST (MAX ([W1].[ResourceS]) AS DECIMAL (16,2)) AS [Resource_S], CAST (MAX ([W1].[SignalS]) AS DECIMAL (16,2)) AS [Signal_S], MAX ([W1].[WaitCount]) AS [WaitCount], CAST (MAX ([W1].[Percentage]) AS DECIMAL (5,2)) AS [Percentage], CAST ((MAX ([W1].[WaitS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgWait_S], CAST ((MAX ([W1].[ResourceS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgRes_S], CAST ((MAX ([W1].[SignalS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgSig_S], CAST ('https://www.sqlskills.com/help/waits/' + MAX ([W1].[wait_type]) as XML) AS [Help/Info URL] FROM [Waits] AS [W1] INNER JOIN [Waits] AS [W2] ON [W2].[RowNum] <= [W1].[RowNum] GROUP BY [W1].[RowNum] HAVING SUM ([W2].[Percentage]) - MAX( [W1].[Percentage] ) < 95; -- percentage threshold GO 

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

आप इस कोड का उपयोग करके सर्वर द्वारा संचित आँकड़ों को भी रीसेट कर सकते हैं:

 DBCC SQLPERF (N'sys.dm_os_wait_stats', CLEAR); GO 

और, ज़ाहिर है, आप हर कुछ घंटों या हर दिन परिणामों को बचाने और कुछ समय विश्लेषण करने के लिए आ सकते हैं ताकि परिवर्तनों की दिशा का पता लगाया जा सके, या स्वचालित रूप से उन समस्याओं को ट्रैक करें जब वे दिखाई देने लगते हैं।
आप SQL Server 2005 और SQL Server 2008 में डेटा कलेक्टर में परिणामों को प्रदर्शित करने के लिए प्रदर्शन डैशबोर्ड का उपयोग भी कर सकते हैं। SQL Server 2000 में आप DBCC SQLPERF (N'waitstats ') का उपयोग कर सकते हैं ।

एक बार जब आप परिणाम प्राप्त करते हैं, तो आप यह सोचना शुरू कर देंगे कि उन्हें कैसे व्याख्या करना है और कहां देखना है। पहले जिस दस्तावेज़ को मैंने संदर्भित किया था, उसमें अधिकांश प्रकार की अपेक्षाओं (SQL Server 2008 में जोड़े गए अपवादों के साथ) पर जानकारी का खजाना है।

अब मैं कुछ समय पहले प्रकाशित एक अध्ययन के परिणाम प्रदान करना चाहूंगा। मैंने लोगों से उपरोक्त कोड चलाने और परिणामों को बताने के लिए कहा। मुझे 1823 के सर्वर से - परिणामों की एक बड़ी राशि मिली - धन्यवाद!

नीचे परिणामों का चित्रमय प्रतिनिधित्व है:



मैं शीर्ष 4 परिणामों पर बिल्कुल भी आश्चर्यचकित नहीं हूं, क्योंकि मैंने उन्हें अपने क्लाइंट सिस्टम पर बार-बार देखा है।

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

• 505: CXPACKET
  मतलब संगामिति, लेकिन जरूरी नहीं कि समस्या। एक समानांतर अनुरोध में समन्वयक धागा हमेशा इन अपेक्षाओं को जमा करता है। यदि समानांतर धागे व्यस्त नहीं हैं या थ्रेड्स में से एक अवरुद्ध है, तो प्रतीक्षा थ्रेड्स भी CXPACKET प्रतीक्षा को जमा करते हैं, जिससे इस प्रकार के आंकड़ों का तेजी से संचय होता है - यह समस्या है। एक धागे में दूसरों की तुलना में अधिक काम हो सकता है, और इस कारण से जब तक एक लंबा धागा अपना काम पूरा नहीं करता, तब तक पूरा अनुरोध अवरुद्ध हो जाता है। यदि इस प्रकार के प्रतीक्षा को बड़े प्रतीक्षा अंकों के साथ जोड़ दिया जाता है PAGEIOLATCH_XX, तो यह गलत गैर-संकुलित अनुक्रमित या खराब क्वेरी निष्पादन योजना के कारण बड़ी तालिकाओं का स्कैन हो सकता है। यदि यह कारण नहीं है, तो आप समस्याग्रस्त प्रश्नों के लिए या पूरे सर्वर उदाहरण के लिए 4, 2, या 1 के मान के साथ MAXDOP विकल्प का उपयोग करने का प्रयास कर सकते हैं (यह "अधिकतम डिग्री के समानांतर" पैरामीटर के साथ सर्वर पर सेट है)। यदि आपका सिस्टम NUMA सर्किटरी पर आधारित है, तो यह निर्धारित करने के लिए एक एकल NUMA नोड में प्रोसेसर की संख्या के लिए MAXDOP सेट करने का प्रयास करें कि क्या यह समस्या है। आपको मिश्रित-लोड सिस्टम पर MAXDOP स्थापित करने के प्रभाव को भी निर्धारित करना होगा। ईमानदार होने के लिए, मैं पूरे उदाहरण के लिए MAXDOP मान को कम करने से पहले "समानांतरता के लिए लागत सीमा" पैरामीटर (शुरुआत के लिए इसे बढ़ाकर 25) के साथ खेलूंगा। और SQL Server 2008 के एंटरप्राइज़ संस्करण में संसाधन गवर्नर के बारे में मत भूलना, जो आपको सर्वर कनेक्शन के एक विशिष्ट समूह के लिए प्रोसेसर की संख्या निर्धारित करने की अनुमति देता है।
• 304: PAGEIOLATCH_XX
  यह वह जगह है जहाँ एसक्यूएल सर्वर डिस्क से मेमोरी तक डेटा पेज पढ़ने का इंतजार करता है। इस प्रकार के प्रतीक्षा से I / O प्रणाली में समस्या का संकेत हो सकता है (जो इस प्रकार की प्रतीक्षा की पहली प्रतिक्रिया है), लेकिन I / O प्रणाली को इतने सारे पाठों की सेवा क्यों देनी चाहिए? शायद बफ़र पूल / मेमोरी (किसी विशिष्ट लोड के लिए पर्याप्त मेमोरी नहीं) द्वारा अचानक दबाव डाला जाता है, निष्पादन योजनाओं में अचानक परिवर्तन, खोज के बजाय बड़े समानांतर स्कैन की ओर अग्रसर होता है, योजना कैश या कुछ अन्य कारणों से। यह मत समझो कि इनपुट / आउटपुट सिस्टम में मुख्य समस्या है।
• 275: ASYNC_NETWORK_IO
  यहां, SQL सर्वर क्लाइंट को डेटा प्राप्त करने के लिए इंतजार करता है। इसका कारण यह हो सकता है कि क्लाइंट ने बहुत अधिक डेटा का अनुरोध किया है या बस इसे खराब कोड के कारण धीरे-धीरे प्राप्त करता है - मैंने लगभग कभी नेटवर्क में समस्या नहीं देखी। ग्राहक एक बार में एक पंक्ति पढ़ते हैं - तथाकथित RBAR या रो-बाय-एगोनिजिंग-रो - क्लाइंट पर डेटा को कैशिंग करने के बजाय और तुरंत पढ़ने के लिए SQL सर्वर को सूचित करने के लिए।
• 112: WRITELOG
  लॉग प्रबंधन सबसिस्टम लॉग के डिस्क पर लिखे जाने की प्रतीक्षा कर रहा है। एक नियम के रूप में, इसका मतलब है कि इनपुट / इनपुट सिस्टम लॉग की पूरी मात्रा का समय पर रिकॉर्ड प्रदान नहीं कर सकता है, लेकिन अत्यधिक लोड किए गए सिस्टम पर यह लॉग रिकॉर्डिंग की सामान्य सीमाओं के कारण हो सकता है, जिसका अर्थ हो सकता है कि आपको कई डेटाबेस के बीच लोड साझा करना चाहिए, या फिर अपना लेनदेन करना चाहिए। लॉग एंट्री की संख्या को डिस्क में कम करने के लिए थोड़ी देर। यह सत्यापित करने के लिए कि कारण I / O सिस्टम में है, लॉग फ़ाइल के लिए I / O विलंब की जांच करने के लिए DMV sysinos_io_virtual_file_stats का उपयोग करें और देखें कि यह WRITELOG विलंब समय से मेल खाता है या नहीं। यदि WRITELOG अधिक समय तक रहता है, तो आपको डिस्क पर लिखने के लिए आंतरिक प्रतियोगिता प्राप्त हुई है और इसे लोड साझा करना होगा। यदि नहीं, तो पता करें कि आप इतने बड़े लेनदेन लॉग क्यों बना रहे हैं। यहाँ (eng।) और यहाँ (eng।) कुछ विचारों को चमकाया जा सकता है।
  (अनुवादक का नोट: निम्नलिखित प्रश्न आपको सरल और सुविधाजनक तरीके से सर्वर पर प्रत्येक डेटाबेस की प्रत्येक फ़ाइल के लिए I / O देरी पर आँकड़े प्राप्त करने की अनुमति देता है:
  
  छिपा हुआ पाठ

   -- : .   > 20  USE master GO SELECT cast(db_name(a.database_id) AS VARCHAR) AS Database_Name , b.physical_name --, a.io_stall , a.size_on_disk_bytes , a.io_stall_read_ms / a.num_of_reads '.   ' , a.io_stall_write_ms / a.num_of_writes '.   ' --, * FROM sys.dm_io_virtual_file_stats(NULL, NULL) a INNER JOIN sys.master_files b ON a.database_id = b.database_id AND a.file_id = b.file_id where num_of_writes > 0 and num_of_reads > 0 ORDER BY Database_Name , a.io_stall DESC 

• 109: BROKER_RECEIVE_WAITFOR
  यहां, सर्विस ब्रोकर नए संदेशों की प्रतीक्षा कर रहा है। मैं इस अपेक्षा को बहिष्करण सूची में जोड़ने और प्रतीक्षा आंकड़ों के साथ क्वेरी को फिर से निष्पादित करने की सलाह दूंगा।
• 086: MSQL_XP
  यहां, SQL सर्वर निष्पादित करने के लिए विस्तारित संग्रहीत प्रक्रियाओं की प्रतीक्षा करता है। यह आपके विस्तारित संग्रहीत कार्यविधियों के कोड में एक समस्या का संकेत दे सकता है।
• 074: OLEDB
  जैसा कि नाम से पता चलता है, यह OLEDB का उपयोग करके बातचीत की एक उम्मीद है - उदाहरण के लिए, एक लिंक किए गए सर्वर के साथ। हालाँकि, DMV और DBCC CHECKDB टीम में भी OLEDB का उपयोग किया जाता है, इसलिए यह मत समझिए कि समस्या आवश्यक रूप से लिंक किए गए सर्वर के साथ है - यह एक बाहरी निगरानी प्रणाली हो सकती है जो DMV कॉल का अत्यधिक उपयोग करती है। यदि यह वास्तव में एक लिंक्ड सर्वर है, तो लिंक किए गए सर्वर पर उम्मीदों का विश्लेषण करें और निर्धारित करें कि उस पर प्रदर्शन समस्या क्या है।
• 054: बैकपीओ
  दिखाता है जब आप सीधे टेप का बैकअप लेते हैं, जो बहुत धीमा है। मैं इस अपेक्षा को फ़िल्टर करूंगा। (अनुवादक का नोट: मुझे डिस्क के लिए बैकअप लिखते समय इस तरह की उम्मीद थी, जबकि एक छोटे डेटाबेस का बैकअप बहुत लंबा समय लगा, तकनीकी ब्रेक के दौरान निष्पादित करने का समय नहीं होने और उपयोगकर्ताओं के लिए प्रदर्शन समस्याएं पैदा करने वाला। यदि यह आपका मामला है, तो यह इनपुट सिस्टम हो सकता है। / बैकअप के लिए उपयोग किए जाने वाले आउटपुट, आपको इसकी उत्पादकता बढ़ाने की संभावना पर विचार करना चाहिए या सेवा योजना को संशोधित करना चाहिए (लघु तकनीकी विराम में पूर्ण बैकअप को पूरा नहीं करना है, उन्हें अंतर के साथ बदलना है))
• 041: LCK_M_XX
  यहां, थ्रेड बस ऑब्जेक्ट पर लॉक करने के लिए एक्सेस की प्रतीक्षा करता है और ताले के साथ समस्याओं का मतलब है। यह तालों के अवांछित वृद्धि या खराब कोड के कारण हो सकता है, लेकिन यह आई / ओ संचालन के कारण बहुत लंबा और सामान्य से अधिक समय तक ताले रखने के कारण भी हो सकता है। DMV sysinos_os_waiting_tasks का उपयोग करके लॉक से संबंधित संसाधनों को देखें। यह मत समझो कि मुख्य समस्या ताले है।
• 032: ONDEMAND_TASK_QUEUE
  यह सामान्य है और बैकग्राउंड टास्क सिस्टम का हिस्सा है (जैसे विलंबित रीसेट, बैकग्राउंड क्लीनअप)। मैं इस अपेक्षा को बहिष्करण सूची में जोड़ूंगा और प्रतीक्षा आंकड़ों के साथ क्वेरी को फिर से निष्पादित करूंगा।
• 031: BACKUPBUFFER
  दिखाता है जब आप सीधे टेप का बैकअप लेते हैं, जो बहुत धीमा है। मैं इस अपेक्षा को फ़िल्टर करूंगा।
• 027: IO_COMPLETION
  SQL सर्वर I / O के पूरा होने की प्रतीक्षा कर रहा है और इस प्रकार का प्रतीक्षा I / O सिस्टम समस्या का संकेतक हो सकता है।
• 024: SOS_SCHEDULER_YIELD
  सबसे अधिक बार यह कोड है जो अन्य प्रकार की अपेक्षाओं में नहीं आता है, लेकिन कभी-कभी यह एक परिपत्र लॉक में एक प्रतियोगिता हो सकती है।
• 022: DBMIRROR_EVENTS_QUEUE
  022: DBMIRRORING_CMD
  ये दो प्रकार बताते हैं कि डेटाबेस मिररिंग सिस्टम बैठा है और कुछ करने की प्रतीक्षा कर रहा है। मैं इन अपेक्षाओं को बहिष्करण सूची में शामिल करूंगा और प्रतीक्षा आंकड़ों के साथ अनुरोध को फिर से निष्पादित करूंगा।
• 018: PAGELATCH_XX
  यह स्मृति में पृष्ठों की प्रतियों तक पहुंच के लिए एक प्रतियोगिता है। सबसे प्रसिद्ध मामले पीएफएस, एसजीएएम और जीएएम के बीच प्रतिस्पर्धा है, जो कुछ विशेष प्रकार के भारों के लिए अस्थायी डेटाबेस में होते हैं । यह पता लगाने के लिए कि कौन से पृष्ठ आपके लिए प्रतिस्पर्धा कर रहे हैं, आपको यह पता लगाने के लिए DMV sysinos_os_waiting_tasks का उपयोग करने की आवश्यकता है कि कौन से पृष्ठ रुकावट पैदा करते हैं। Tempdb डेटाबेस की समस्याओं के बारे में, रॉबर्ट डेविस (उनका ब्लॉग , ट्विटर ) ने एक अच्छा लेख लिखा है जिसमें बताया गया है कि उन्हें कैसे हल किया जाए । एक और सामान्य कारण जो मैंने देखा था वह था अनुक्रमिक आवेषण के साथ एक अनुक्रमिक कुंजी (IDENTITY) का उपयोग करके अक्सर अपडेट किया गया इंडेक्स।
• 016: LATCH_XX
  यह SQL सर्वर में किसी भी गैर-पृष्ठ संरचनाओं के लिए एक प्रतियोगिता है - इसलिए यह सामान्य रूप से I / O और डेटा से संबंधित नहीं है। इस प्रकार की देरी का कारण समझना मुश्किल हो सकता है और आपको DMV sysinos_os_latch_stats का उपयोग करने की आवश्यकता है।
• 013: PREEMPTIVE_OS_PIPEOPS
  यहां, SQL सर्वर विंडोज से कुछ का अनुरोध करने के लिए सक्रिय शेड्यूलिंग पर स्विच करता है। 2008 के संस्करण में इस तरह की प्रतीक्षा को जोड़ा गया था और अभी तक इसका दस्तावेजीकरण नहीं किया गया है। यह पता लगाने का सबसे आसान तरीका है कि प्रारंभिक PREEMPTIVE_OS_ को निकालना और MSDN में जो कुछ बचा है उसे देखना है - यह विंडोज एपीआई का नाम होगा।
• 013: थ्रेडेडोल
  यह प्रकार कहता है कि अनुरोध को पूरा करने के लिए सिस्टम में पर्याप्त वर्कफ़्लोज़ नहीं हैं। आमतौर पर, इसका कारण बड़ी संख्या में अत्यधिक समानांतर अनुरोधों को निष्पादित करने की कोशिश करना है। (अनुवादक का नोट: यह "अधिकतम वर्कर थ्रेड्स" सर्वर पैरामीटर का एक जानबूझकर छोटा मूल्य हो सकता है)
• 009: BROKER_TRANSMITTER
  यहां, सेवा ब्रोकर नए संदेश भेजे जाने की प्रतीक्षा कर रहा है। मैं इस अपेक्षा को बहिष्करण सूची में जोड़ने और प्रतीक्षा आंकड़ों के साथ क्वेरी को फिर से निष्पादित करने की सलाह दूंगा।
• 006: SQLTRACE_WAIT_ENTRIES
  SQL सर्वर का ट्रेस भाग। मैं इस अपेक्षा को बहिष्करण सूची में जोड़ने और प्रतीक्षा आंकड़ों के साथ क्वेरी को फिर से निष्पादित करने की सलाह दूंगा।
• 005: DBMIRROR_DBM_MUTEX
  यह अनिर्दिष्ट प्रकारों में से एक है और इसमें डेटाबेस मिररिंग सत्रों के बीच साझा किए जाने वाले बफर को भेजने की प्रतियोगिता है। इसका मतलब यह हो सकता है कि आपके पास बहुत सारे मिररिंग सत्र हैं।
• 005: RESOURCE_SEMAPHORE
  यहां, क्वेरी मेमोरी को निष्पादित करने के लिए प्रतीक्षा करता है (क्वेरी ऑपरेटरों को संसाधित करने के लिए उपयोग की जाने वाली मेमोरी - जैसे सॉर्टिंग)। यह एक प्रतिस्पर्धी लोड पर स्मृति की कमी हो सकती है।
• 003: PREEMPTIVE_OS_AUTHENTICATIONOPS
  003: PREEMPTIVE_OS_GENERICOPS
  यहां, SQL सर्वर विंडोज से कुछ का अनुरोध करने के लिए सक्रिय शेड्यूलिंग पर स्विच करता है। 2008 के संस्करण में इस तरह की प्रतीक्षा को जोड़ा गया था और अभी तक इसका दस्तावेजीकरण नहीं किया गया है। यह पता लगाने का सबसे आसान तरीका है कि प्रारंभिक PREEMPTIVE_OS_ को निकालना और MSDN में जो कुछ बचा है उसे देखना है - यह विंडोज एपीआई का नाम होगा।
• 003: SLEEP_BPOOL_FLUSH
  इस उम्मीद को अक्सर देखा जा सकता है, और इसका मतलब है कि ब्रेकपाइंट I / O सिस्टम को ओवरलोड करने से बचने के लिए खुद को सीमित करता है। मैं इस अपेक्षा को बहिष्करण सूची में जोड़ने और प्रतीक्षा आंकड़ों के साथ क्वेरी को फिर से निष्पादित करने की सलाह दूंगा।
• 002: MSQL_DQ
  यहाँ, SQL सर्वर वितरित क्वेरी को निष्पादित करने के लिए प्रतीक्षा करता है। यह वितरित अनुरोधों के साथ समस्याओं का संकेत दे सकता है, या यह सिर्फ आदर्श हो सकता है।
• 002: RESOURCE_SEMAPHORE_QUERY_COMPILE
  जब सिस्टम में प्रश्नों की बहुत अधिक प्रतिस्पर्धा होती है, तो SQL सर्वर उनके निष्पादन को सीमित कर देता है। मुझे प्रतिबंध का स्तर याद नहीं है, लेकिन इस उम्मीद का मतलब अत्यधिक पुनर्मूल्यांकन हो सकता है या, शायद, एक बार की योजनाओं का बहुत अधिक उपयोग।
• 001: DAC_INIT
  मैंने इसे पहले कभी नहीं देखा है और बीओएल कहता है कि इसका कारण प्रशासनिक कनेक्शन की शुरुआत है। मैं नहीं सोच सकता कि यह किसी की प्रणाली पर एक प्राथमिकता की उम्मीद कैसे हो सकती है ...
• 001: MSSEARCH
  पूर्ण-पाठ संचालन में यह प्रकार सामान्य है। यदि यह एक पूर्वनिर्धारित अपेक्षा है, तो इसका मतलब यह हो सकता है कि आपका सिस्टम पूर्ण-पाठ प्रश्नों को करने में सबसे अधिक समय बिताता है। आप बहिष्करण सूची में इस प्रकार के प्रतीक्षा को जोड़ने पर विचार कर सकते हैं।
• 001: PREEMPTIVE_OS_FILEOPS
  001: PREEMPTIVE_OS_LIBRARYOPS
  001: PREEMPTIVE_OS_LOOKUPACCOUNTSID
  001: PREEMPTIVE_OS_QUERYREGISTRY
  यहां, SQL सर्वर विंडोज से कुछ का अनुरोध करने के लिए सक्रिय शेड्यूलिंग पर स्विच करता है। 2008 के संस्करण में इस तरह की प्रतीक्षा को जोड़ा गया था और अभी तक इसका दस्तावेजीकरण नहीं किया गया है। यह पता लगाने का सबसे आसान तरीका है कि प्रारंभिक PREEMPTIVE_OS_ को निकालना और MSDN में जो कुछ बचा है उसे देखना है - यह विंडोज एपीआई का नाम होगा।
• 001: SQLTRACE_LOCK
  SQL सर्वर का ट्रेस भाग। मैं इस अपेक्षा को बहिष्करण सूची में जोड़ने और प्रतीक्षा आंकड़ों के साथ क्वेरी को फिर से निष्पादित करने की सलाह दूंगा।

उम्मीद है कि यह दिलचस्प था! मुझे पता है कि क्या आप कुछ विशेष रूप से रुचि रखते हैं या आप इस लेख को पढ़ चुके हैं और इसका आनंद लिया है!