डिफ़ॉल्ट ट्रेस हटाना - भाग 1

[ भाग 1 | भाग 2 | भाग 3 ]

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

हमारे परिवेश में, यह सभी 200+ उत्पादन सर्वरों पर सक्षम है, और यह बहुत सारा कचरा एकत्र करता है जिसकी हम कभी जांच नहीं करेंगे। इतना कचरा, वास्तव में, वह महत्वपूर्ण घटनाएँ जो हमें कभी भी मौका मिलने से पहले ट्रेस फ़ाइलों के समस्या निवारण के लिए उपयोगी लग सकती हैं। इसलिए मैंने इसे बंद करने की संभावना पर विचार करना शुरू कर दिया, क्योंकि:

• यह मुफ़्त नहीं है (ट्रेस गतिविधि का पर्यवेक्षक ओवरहेड, ट्रेस फ़ाइलों को लिखने के साथ शामिल I/O, और उनके द्वारा उपभोग की जाने वाली जगह);
• अधिकांश सर्वरों पर, इसे कभी नहीं देखा गया; दूसरों पर, शायद ही कभी; और,
• इसे वापस चालू करना आसान है विशिष्ट, पृथक समस्या निवारण के लिए।

कुछ अन्य चीजें डिफ़ॉल्ट ट्रेस के मान को प्रभावित करती हैं। यह किसी भी तरह से कॉन्फ़िगर करने योग्य नहीं है — आप यह नहीं बदल सकते कि यह कौन-सी ईवेंट एकत्रित करता है, आप फ़िल्टर नहीं जोड़ सकते हैं, और आप यह नियंत्रित नहीं कर सकते कि यह कितनी फ़ाइलें रखता है (5), वे कितनी बड़ी प्राप्त कर सकते हैं (प्रत्येक में 20 एमबी) , या जहां वे संग्रहीत हैं (SERVERPROPERTY('ErrorLogFileName') ) इसलिए हम पूरी तरह से कार्यभार की दया पर हैं - किसी भी सर्वर पर, हम यह अनुमान नहीं लगा सकते हैं कि डेटा कितनी दूर जा सकता है (बड़े TextData वाले ईवेंट) मान, उदाहरण के लिए, बहुत अधिक स्थान ले सकते हैं, और पुरानी घटनाओं को अधिक तेज़ी से आगे बढ़ा सकते हैं)। कभी-कभी यह एक सप्ताह पीछे जा सकता है, कभी-कभी यह कुछ ही मिनटों में वापस जा सकता है।

वर्तमान स्थिति का विश्लेषण करना

मैंने 224 उत्पादन उदाहरणों के खिलाफ निम्नलिखित कोड चलाया, यह समझने के लिए कि हमारे पर्यावरण में किस प्रकार का शोर डिफ़ॉल्ट ट्रेस भर रहा है। यह शायद जरूरत से ज्यादा जटिल है, और मेरे द्वारा उपयोग की जाने वाली अंतिम क्वेरी जितना जटिल भी नहीं है, लेकिन यह उच्च-स्तरीय ईवेंट प्रकारों के विश्लेषण के लिए एक अच्छा प्रारंभिक बिंदु है जो वर्तमान में कैप्चर किए जा रहे हैं:

;WITH filesrc ([path]) AS
(
  SELECT REVERSE(SUBSTRING(p, CHARINDEX(N'\', p), 260)) + N'log.trc'
  FROM (SELECT REVERSE([path]) FROM sys.traces WHERE is_default = 1) s(p)
),
tracedata AS 
(
  SELECT Context = CASE 
    WHEN DDL = 1 THEN 
      CASE WHEN LEFT(ObjectName,8) = N'_WA_SYS_' 
                THEN 'AutoStat: ' + DBType
           WHEN LEFT(ObjectName,2) IN (N'PK', N'UQ', N'IX') AND ObjectName LIKE N'%[_#]%' 
                THEN UPPER(LEFT(ObjectName,2)) + ': tempdb'
           WHEN ObjectType = 17747 AND ObjectName LIKE N'TELEMETRY%' 
                THEN 'Telemetry' 
                ELSE 'Other DDL in ' + DBType END
    WHEN EventClass = 116 THEN 
      CASE WHEN TextData LIKE N'%checkdb%' THEN 'DBCC CHECKDB'
           -- several more of these ...
           ELSE UPPER(CONVERT(nchar(32), TextData)) END
    ELSE DBType END,
    EventName = CASE WHEN DDL = 1 THEN 'DDL' ELSE EventName END, 
    EventSubClass,
    EventClass, 
    StartTime
  FROM
  (
    SELECT DDL = CASE WHEN t.EventClass IN (46,47,164) THEN 1 ELSE 0 END, 
      TextData = LOWER(CONVERT(nvarchar(512), t.TextData)), 
      EventName = e.[name],
      t.EventClass, 
      t.EventSubClass, 
      ObjectName = UPPER(t.ObjectName), 
      t.ObjectType, 
      t.StartTime,
      DBType = CASE WHEN t.DatabaseID = 2 OR t.ObjectName LIKE N'#%' THEN 'tempdb'
                    WHEN t.DatabaseID IN (1,3,4)  THEN 'System database'
                    WHEN t.DatabaseID IS NOT NULL THEN 'User database' ELSE '?' END
    FROM filesrc CROSS APPLY sys.fn_trace_gettable(filesrc.[path], DEFAULT) AS t
    LEFT OUTER JOIN sys.trace_events AS e ON t.EventClass = e.trace_event_id
  ) AS src WHERE (EventSubClass IS NULL) 
           OR (EventSubClass = CASE WHEN DDL = 1 THEN 1 ELSE EventSubClass END) -- ddl_phase
)
SELECT [Instance] = @@SERVERNAME, 
       EventName,   
       Context, 
       EventCount = COUNT(*), 
       FirstSeen  = MIN(StartTime), 
       LastSeen   = MAX(StartTime) 
INTO #t FROM tracedata 
GROUP BY GROUPING SETS ((), (EventName, Context));

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

लगभग सभी शोर (99.94%)। डिफ़ॉल्ट ट्रेस से हमें केवल एक ही उपयोगी चीज़ की आवश्यकता थी, वह थी फ़ाइल वृद्धि और सिकुड़न की घटनाएँ, क्योंकि वे एकमात्र ऐसी चीज़ थीं जिन्हें हम किसी न किसी तरह से कहीं और कैप्चर नहीं कर रहे थे। लेकिन यहां तक ​​कि हम हमेशा भरोसा करने में सक्षम नहीं होते हैं, क्योंकि डेटा इतनी जल्दी खत्म हो जाता है।

एक और तरीका मैंने डेटा को काट दिया:प्रति उदाहरण सबसे पुरानी घटना। कुछ उदाहरणों में इतना शोर था कि वे कुछ मिनटों से अधिक के लिए डिफ़ॉल्ट ट्रेस डेटा पर पकड़ नहीं बना सके! मैंने सर्वर नामों को धुंधला कर दिया लेकिन यह वास्तविक डेटा है (ये सबसे छोटे इतिहास वाले 20 सर्वर हैं - बड़ा करने के लिए क्लिक करें):

भले ही ट्रेस केवल एकत्रित कर रहे थे प्रासंगिक जानकारी, और कुछ दिलचस्प हुआ, हमें सर्वर के आधार पर इसे पकड़ने के लिए जल्दी से कार्य करना होगा। अगर ऐसा हुआ:

• 20 मिनट पहले , तो यह पहले ही 15 उदाहरणों . पर चला जाएगा .
• इस बार कल , यह 105 उदाहरणों . पर चला जाएगा .
• दो दिन पहले , यह 115 उदाहरणों पर चला जाएगा .
• एक सप्ताह से अधिक समय पहले , यह 139 उदाहरणों . पर चला जाएगा .

हमारे पास दूसरे छोर पर भी मुट्ठी भर सर्वर थे, लेकिन वे इस संदर्भ में रुचिकर नहीं हैं; वे सर्वर इस तरह से हैं क्योंकि वहां कुछ भी दिलचस्प नहीं होता है (उदाहरण के लिए वे व्यस्त नहीं हैं या किसी महत्वपूर्ण कार्यभार का हिस्सा नहीं हैं)।

प्लस साइड पर...

डिफ़ॉल्ट ट्रेस की जांच करने से हमारे कुछ सर्वरों पर कुछ गलत कॉन्फ़िगरेशन का पता चला:

• कई सर्वरों में अभी भी टेलीमेट्री सक्षम था . मैं कुछ विशेष वातावरणों में Microsoft की मदद करने के लिए तैयार हूं, लेकिन व्यावसायिक महत्वपूर्ण प्रणालियों पर किसी भी ऊपरी लागत पर नहीं।
• कुछ पृष्ठभूमि समन्वयन कार्य थे सदस्यों को भूमिकाओं में आँख बंद करके जोड़ना , बार-बार, यह जाँचे बिना कि क्या वे पहले से ही उन भूमिकाओं में थे। यह प्रति से हानिकारक नहीं है, खासकर जब से ये घटनाएं अब डिफ़ॉल्ट ट्रेस नहीं भरेंगी, लेकिन वे शोर के साथ ऑडिट भी भर रहे हैं, और शायद उसी पैटर्न में अन्य अंधा पुन:लागू संचालन हो रहे हैं।
• किसी ने ऑटोश्रिंक सक्षम किया है कहीं (अच्छा दुःख!), तो यह कुछ ऐसा था जिसे मैं ट्रैक करना चाहता था और फिर से होने से रोकना चाहता था (नया एक्सई इन घटनाओं को भी कैप्चर करेगा)।

इससे इन मुद्दों को ठीक करने और/या पहले से मौजूद मौजूदा स्वचालन में शर्तों को जोड़ने के लिए अनुवर्ती कार्य हुए। इसलिए हम भविष्य में कुछ डिफ़ॉल्ट ट्रेस समीक्षा में उन पर होने के लिए पर्याप्त भाग्यशाली होने पर भरोसा किए बिना पुनरावृत्ति को रोक सकते हैं, इससे पहले कि वे रोल आउट हो जाएं।

...लेकिन समस्या बनी हुई है

अन्यथा, सब कुछ या तो ऐसी जानकारी है जिस पर हम संभवतः कार्रवाई नहीं कर सकते हैं या, जैसा कि ऊपर दिए गए ग्राफ़िक में वर्णित है, ऐसी घटनाएँ जिन्हें हम पहले ही कहीं और कैप्चर कर चुके हैं। और फिर से, केवल वही डेटा जिसमें मुझे डिफ़ॉल्ट ट्रेस से दिलचस्पी है, जिसे हम पहले से ही अन्य माध्यमों से कैप्चर नहीं करते हैं, फ़ाइल वृद्धि और सिकुड़ने से संबंधित घटनाएं हैं (भले ही डिफ़ॉल्ट ट्रेस केवल स्वचालित विविधता को कैप्चर करता है)।

लेकिन बड़ी समस्या वास्तव में शोर की मात्रा नहीं है। मैं बहुत सारे कचरे के साथ बड़ी विशाल ट्रेस फ़ाइलों को संभाल सकता हूं, क्योंकि इस उद्देश्य के लिए WHERE क्लॉज का आविष्कार किया गया था। वास्तविक समस्या यह है कि महत्वपूर्ण घटनाएं बहुत जल्दी गायब हो रही थीं।

जवाब

उत्तर, हमारे परिदृश्य में, कम से कम, सरल था:डिफ़ॉल्ट ट्रेस को अक्षम करें, क्योंकि यह चलने लायक नहीं है अगर इस पर भरोसा नहीं किया जा सकता है।

लेकिन ऊपर शोर की मात्रा को देखते हुए, इसे क्या बदलना चाहिए? कुछ भी?

हो सकता है कि आप एक विस्तारित ईवेंट सत्र चाहते हैं जो सब कुछ को कैप्चर करे डिफ़ॉल्ट ट्रेस कैप्चर किया गया। यदि हां, तो जोनाथन केहैयस ने आपको कवर कर लिया है। यह आपको वही जानकारी देगा, लेकिन अवधारण जैसी चीज़ों पर नियंत्रण के साथ, जहां डेटा संग्रहीत हो जाता है और, जैसे-जैसे आप अधिक सहज होते जाते हैं, समय के साथ, धीरे-धीरे, कुछ कम या कम उपयोगी घटनाओं को हटाने की क्षमता।

मेरी योजना थोड़ी अधिक आक्रामक थी, और वातावरण में सभी सर्वरों पर (सीएमएस के माध्यम से) निम्नलिखित कार्य करने के लिए शीघ्र ही एक "सरल" प्रक्रिया बन गई:

1. एक विस्तारित ईवेंट सत्र विकसित करें जो केवल फ़ाइल परिवर्तन ईवेंट (मैनुअल और स्वचालित दोनों) को कैप्चर करता है
2. डिफ़ॉल्ट ट्रेस अक्षम करें
3. हमारी टीमों के लिए लक्ष्य डेटा का उपभोग करना आसान बनाने के लिए एक दृश्य बनाएं

ध्यान दें कि मैं आपको डिफ़ॉल्ट ट्रेस को आँख बंद करके अक्षम करने का सुझाव नहीं दे रहा हूँ , बस यह समझाते हुए कि मैंने अपने परिवेश में ऐसा करने का चुनाव क्यों किया। इस श्रृंखला की आगामी पोस्टों में, मैं नया विस्तारित ईवेंट सत्र दिखाऊंगा, वह दृश्य जो अंतर्निहित डेटा को उजागर करता है, वह कोड जिसका उपयोग मैंने इन परिवर्तनों को सभी सर्वरों पर परिनियोजित करने के लिए किया था, और संभावित दुष्प्रभाव जिन्हें आपको ध्यान में रखना चाहिए।

[ भाग 1 | भाग 2 | भाग 3 ]