आपके टूलबॉक्स से हटाने के लिए बहिष्कृत सुविधाएँ - भाग 1

Microsoft इन दिनों चीजों को कम करने की आदत में नहीं है, लेकिन जब वे ऐसा करते हैं, तो यह एक कारण से होता है - और यह निश्चित रूप से इसलिए नहीं है क्योंकि वे आपके जीवन को कठिन बनाना चाहते हैं। इसके विपरीत, यह लगभग हमेशा होता है क्योंकि उन्होंने उन्हीं समस्याओं को हल करने के लिए बेहतर और अधिक आधुनिक तरीके विकसित किए हैं।

लेकिन आदतों को तोड़ना मुश्किल है; मुझसे पूछो मुझे कैसे पता। बहुत बार, मैं देखता हूं कि लोग किसी कार्य को पूरा करने के पुराने तरीके से चिपके रहते हैं, भले ही एक बेहतर तरीका मौजूद हो।

मैं हाल के कुछ उदाहरण साझा करना चाहता हूं जो यह स्पष्ट करने में सहायता करते हैं कि कैसे बहिष्कृत SQL सर्वर सुविधाओं का उपयोग हमें काटने के लिए जारी है। इस पहले भाग में, मैं बात करना चाहता हूँ…

sysprocesses

सिस्टम टेबल sys.sysprocesses SQL सर्वर 2005 में डायनेमिक मैनेजमेंट व्यू (DMVs) के एक सेट द्वारा बदल दिया गया था, विशेष रूप से sys.dm_exec_requests , sys.dm_exec_sessions , और sys.dm_exec_connections . sys.sysprocesses . के लिए आधिकारिक दस्तावेज चेतावनी देता है:

एक हालिया उदाहरण

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

उन्होंने निर्धारित किया, मान लें कि समय पर t0 , कि एक निश्चित सत्र में लॉग रीडर प्रक्रिया को अवरुद्ध करने वाला एक खुला लेनदेन था। उन्होंने सबसे पहले DBCC INPUTBUFFER . के आउटपुट की जांच की , यह निर्धारित करने का प्रयास करने के लिए कि यह सत्र क्या चला, लेकिन परिणामों ने केवल यह संकेत दिया कि उन्होंने अपने लेन-देन के दौरान अन्य बैच भी जारी किए:

event_type       parameters   event_info
--------------   ----------   ---------------
Language Event   0            SET ROWCOUNT 0;

ध्यान दें कि DBCC INPUTBUFFER आधुनिक संस्करणों में भी अधिक सक्षम प्रतिस्थापन है:sys.dm_exec_input_buffer . और जबकि इसमें स्पष्ट बहिष्करण चेतावनी नहीं है, DBCC . के लिए आधिकारिक दस्तावेज़ीकरण कमांड में यह कोमल कुहनी है:

इनपुट बफ़र से कुछ नहीं मिलने के बाद, उन्होंने sys.sysprocesses . से पूछताछ की :

SELECT 
  spid, 
  [status], 
  open_tran, 
  waittime, 
  [cpu], 
  physical_io, 
  memusage, 
  last_batch
FROM sys.sysprocesses 
WHERE spid = 107;

परिणाम समान रूप से बेकार थे, कम से कम यह निर्धारित करने के संदर्भ में कि सत्र उनके लेन-देन को खुला रखने और लॉग रीडर को बाधित करने के लिए क्या कर रहा था:

मैं physical_io को हाइलाइट कर रहा हूं कॉलम क्योंकि इस मूल्य ने इस बारे में चर्चा की कि क्या वे स्लीपिंग सेशन को मारने का जोखिम उठाना चाहते हैं या नहीं। सोच यह थी कि, उन सभी भौतिक I/Os के लिखे जाने की स्थिति में, लेन-देन को समाप्त करने से एक लंबा और विघटनकारी रोलबैक हो सकता है - संभावित रूप से समस्या को और भी बदतर बना सकता है। मैं इस पर वास्तविक समय नहीं डालूंगा, लेकिन मान लीजिए कि यह एक लंबी बातचीत में बदल गया, और इसने इस स्थिति में सिस्टम को समय से छोड़ दिया t0 समय के लिए t1 ऊपर दिए गए ग्राफ़ पर.

यह एक समस्या क्यों है

इस विशिष्ट मामले में मुद्दा यह है कि उन्होंने उस समय को अधूरी जानकारी के आधार पर निर्णय पर विचार करने में बिताया। क्या वे I/Os पढ़ते या लिखते हैं? यदि उपयोगकर्ता के पास एक खुला लेन-देन है और उसने केवल बहुत सारा डेटा पढ़ा है, तो उस लेन-देन को वापस रोल करने में बहुत कम प्रभाव पड़ता है यदि उन्होंने बदल दिया बहुत सारा डेटा। तो, sys.sysprocesses . के बजाय , आइए देखें कि अधिक आधुनिक DMV क्या है, sys.dm_exec_sessions , हमें इस सत्र के बारे में दिखा सकते हैं:

SELECT 
  session_id, 
  [status], 
  open_transaction_count, 
  cpu_time, 
  [reads], 
  writes, 
  logical_reads, 
  last_request_start_time,
  last_request_end_time
FROM sys.dm_exec_sessions 
WHERE session_id = 107;

परिणाम:

यहां हम देखते हैं कि sys.dm_exec_sessions भौतिक I/O को अलग से पढ़ने और लिखने में विभाजित करता है। यह हमें t1 - t0 , संभावित रोलबैक के प्रभाव के बारे में। यदि I/O सभी लिखते हैं, और संख्या कितनी अधिक है, इस पर निर्भर करते हुए, हम थोड़ा और संकोच कर सकते हैं और शायद उपयोगकर्ता का पता लगाने की कोशिश में समय व्यतीत कर सकते हैं (इसलिए हम उनके पोर को मार सकते हैं या उनसे पूछ सकते हैं कि उनके पास एक खुला लेनदेन क्यों है ) अगर हम जानते हैं कि यह ज्यादातर पढ़ा जाता है, तो हम इसके बजाय सत्र को खत्म करने और लेनदेन को वापस रोल करने के लिए मजबूर करने की ओर झुक सकते हैं।

ज़रूर, sys.sysprocesses में dbid है और waittime . लेकिन dbid वैसे भी अविश्वसनीय और मामूली रूप से उपयोगी है, विशेष रूप से क्रॉस-डेटाबेस प्रश्नों के लिए; sys.dm_tran_locks . में बहुत बेहतर जानकारी है . प्रतीक्षा जानकारी (समय और अंतिम प्रतीक्षा प्रकार) sys.dm_exec_requests में पाई जा सकती है , लेकिन अधिक विस्तृत जानकारी sys.dm_exec_session_wait_stats में दी गई है (एसक्यूएल सर्वर 2016 में जोड़ा गया)। एक बहाना जो मैं बहुत सुनता था वह यह था कि sys.dm_exec_sessions अनुपलब्ध था open_tran , लेकिन open_transaction_count SQL सर्वर 2012 में वापस जोड़ा गया था। इसलिए sys.sysprocesses का उपयोग करने के बारे में सोचने का बहुत कम कारण है। आज।

यदि आप यह जानना चाहते हैं कि sys.sysprocesses . कितनी बार SQL सर्वर के अंतिम बार पुनरारंभ होने के बाद से संदर्भित किया गया है, आप इस क्वेरी को प्रदर्शन काउंटर DMV के विरुद्ध चला सकते हैं:

SELECT instance_name, cntr_value
  FROM sys.dm_os_performance_counters
  WHERE [object_name] LIKE N'%:Deprecated Features%'
    AND instance_name = N'sysprocesses' 
  ORDER BY cntr_value DESC;

यदि आप वास्तव में आज रात सोने से बचना चाहते हैं, या आप केवल उन चीज़ों की लॉन्ड्री सूची में लगातार जोड़ना चाहते हैं जिनके बारे में आप चिंतित हैं, तो instance_name के सामने विधेय हटा दें . यह आपको एक डरावना, उच्च स्तरीय विचार देगा कि आपके उदाहरण कितनी चीजें चल रहे हैं जिन्हें आपको अंततः बदलने की आवश्यकता होगी।

इस बीच, डाउनलोड करें sp_WhoIsActive . पर जाएं , वास्तविक समय में SQL सर्वर प्रक्रियाओं की निगरानी और समस्या निवारण के लिए एडम मचानिक की अति उपयोगी संग्रहीत प्रक्रिया। हमने इस संग्रहीत कार्यविधि को अपने परिवेश में प्रत्येक उदाहरण के लिए परिनियोजित किया है, और आपको भी करना चाहिए, भले ही आप अन्य उच्च-स्तरीय निगरानी उपकरणों का भी उपयोग कर रहे हों।

अगली बार

भाग 2 में, मैं SQL सर्वर प्रोफाइलर के बारे में कुछ बात करने जा रहा हूँ, एक ऐसा अनुप्रयोग जिसे लोग किसी अन्य चीज़ की तुलना में परिचित होने के कारण अधिक उपयोग करते हैं - यह जाने बिना कि यह कितना खतरनाक हो सकता है।