लेन-देन लॉग निगरानी

पिछले एक साल में मैंने SQLPerformance.com पर लेन-देन लॉग प्रदर्शन के मुद्दों (यहां देखें) के बारे में कई बार ब्लॉग किया है और मैंने लेन-देन लॉग मॉनिटरिंग पर चर्चा करने का वादा किया है, जो मैं इस पोस्ट में करूँगा। मैं कुछ मीट्रिक प्रस्तुत करने जा रहा हूँ जिन्हें आप ट्रैक कर सकते हैं, आपको क्यों ध्यान रखना चाहिए, और संकेतित समस्या से निपटने के लिए कोई सलाह।

DMV

लेन-देन लॉग I/O विलंबता की निगरानी करने का सबसे आसान तरीका sys.dm_io_virtual_file_stats का उपयोग करना है डीएमवी। उपयोगी परिणाम प्राप्त करने के लिए आपको कुछ गणित करने की आवश्यकता होगी और आप इस डेमो ज़िप फ़ाइल में VirtualFileStats.sql स्क्रिप्ट में कुछ उदाहरण कोड प्राप्त कर सकते हैं। आप वास्तव में लेन-देन लॉग के लिए 5ms से कम की लेखन विलंबता देखना चाहते हैं।

इससे पहले नवंबर में मैंने दुनिया भर के 25,000 से अधिक डेटाबेस (यहां देखें) के लिए लेनदेन लॉग और tempdb डेटा फ़ाइल विलंबता दिखाने वाले एक सर्वेक्षण के परिणामों को ब्लॉग किया था, जिसमें 80% डेटाबेस लेनदेन लॉग लिखने की विलंबता के लिए 5ms या उससे कम अंक तक पहुंच गए थे।

यदि आपकी लेखन विलंबता 5ms से अधिक है, तो आप यह कर सकते हैं:

जनरेट किए जा रहे लॉग की मात्रा और/या छोटे लेन-देन से होने वाले लॉग फ्लश की मात्रा को कम करने के लिए काम करें, जैसा कि मैंने पहले की पोस्ट में बताया था।
उपरोक्त सर्वेक्षण ब्लॉग पोस्ट में वर्णित कुछ समस्या निवारण चरणों का पालन करें।
एक तेज़ I/O सबसिस्टम पर जाएं, यह याद रखते हुए कि यदि आप SSD का उपयोग करने का निर्णय लेते हैं, तो आपको RAID-1 कॉन्फ़िगरेशन में दो का उपयोग करने की आवश्यकता है।

एक और चीज जो आप देख सकते हैं वह यह सुनिश्चित करने के लिए है कि आप 2008 R2 में और उससे पहले (SQL सर्वर 2012 से 2012 तक बढ़ाए गए) प्रत्येक डेटाबेस के लेन-देन लॉग के लिए 32 बकाया राइट I/Os की हार्ड लिमिट को हिट नहीं कर रहे हैं। आप भौतिक डिस्क/औसत को देखकर ऐसा करने का प्रयास कर सकते हैं। डिस्क कतार की लंबाई लिखें, लेकिन यह पूरी मात्रा के लिए है, प्रति फ़ाइल के लिए नहीं, इसलिए यदि आपकी रुचि वाली लॉग फ़ाइल के अलावा वॉल्यूम पर कुछ और है, तो यह आपको एक वैध संख्या नहीं देगा। sys.dm_io_pending_io_requests के परिणामों को एकत्रित करने का एक बेहतर तरीका है DMV, जो सभी बकाया I/Os को सूचीबद्ध करता है। ऐसा करने के लिए यहां कुछ कोड दिया गया है:

सेलेक्ट COUNT (*) AS [PendingIOs], DB_NAME ([vfs]।[database_id]) AS [DBName], [mf]।[name] AS [FileName], [mf]।[type_desc] AS [FileType ], SUM ([pior]। [io_handle] [mf] पर [mf] के रूप में sys.master_files में शामिल हों। ] =1 ग्रुप बाय [वीएफएस]। [डेटाबेस_आईडी], [एमएफ]। [नाम], [एमएफ]। [टाइप_डेस्क] ऑर्डर बाय [वीएफएस]।

आप इसे आसानी से केवल लॉग फ़ाइलों के लिए परिणाम प्रदर्शित करने के लिए संशोधित कर सकते हैं (type_desc ='LOG' पर फ़िल्टर करें) ) और केवल उस डेटाबेस आईडी के लिए जिसमें आप रुचि रखते हैं।

यदि आप पाते हैं कि आप किसी विशेष डेटाबेस के लिए 32 की सीमा को पार कर रहे हैं, तो आप यह कर सकते हैं:

छोटे लेन-देन की संख्या को कम करके और डेटा संशोधन कार्यों के दौरान पेज स्प्लिट और अप्रयुक्त/डुप्लिकेट इंडेक्स को बदलने जैसी चीजों को देखकर लॉग फ्लश की मात्रा को कम करें। आप इस ब्लॉग पोस्ट में लॉग फ्लश को अनुकूलित करने के बारे में अधिक पढ़ सकते हैं
एक तेज़ I/O सबसिस्टम का उपयोग करके देखें
एसक्यूएल सर्वर 2012 या उच्चतर में अपग्रेड करें, जहां सीमा 112 है
delayed durability feature आज़माएं DMV जिसे SQL Server 2014 में जोड़ा गया था
अंतिम उपाय के रूप में, कार्यभार को एकाधिक डेटाबेस या सर्वर पर विभाजित करें

यदि आप यह देखना चाहते हैं कि आपके लेन-देन से कितना लेन-देन लॉग उत्पन्न हो रहा है, तो आप sys.dm_tran_database_transactions का उपयोग कर सकते हैं DMV, नीचे दिए गए कोड के समान:

BEGIN TRAN;GO -- कुछ ऐसा करें जिसका आप मूल्यांकन करना चाहते हैंGO चुनें [database_transaction_log_bytes_used]FROM sys.dm_tran_database_transactionsWHERE [database_id] =DB_ID (N'YourTestDB');GO

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

प्रदर्शन मॉनिटर काउंटर

लॉग-संबंधित प्रदर्शन काउंटर सभी डेटाबेस प्रदर्शन ऑब्जेक्ट में हैं। यहां देखने के लिए कुछ मुख्य हैं (या तो प्रदर्शन मॉनिटर के साथ, या SQL एजेंट अलर्ट का उपयोग करके, या sys.dm_os_performance_counters DMV का उपयोग करके, या अपने पसंदीदा तृतीय-पक्ष निगरानी उपकरण में):

लॉग ग्रोथ

आप इस काउंटर को बढ़ते हुए नहीं देखना चाहते क्योंकि यह कहता है कि डेटाबेस में कुछ ऐसा हो रहा है जिससे वर्तमान स्थान की तुलना में अधिक लेन-देन लॉग उत्पन्न हो रहा है। इसका तात्पर्य है कि लेन-देन लॉग साफ़ नहीं हो पा रहा है, इसलिए आपको sys.databases के log_reuse_wait_desc फ़ील्ड को क्वेरी करके कारण की जांच करनी चाहिए और जो भी आवश्यक कार्रवाई करनी चाहिए (देखें पुस्तकें ऑनलाइन विषय कारक जो लॉग ट्रंकेशन को विलंबित कर सकते हैं अधिक विवरण के लिए)। कुछ उदाहरण कोड होंगे:

चुनें [log_reuse_wait_desc] जहां [name] =N'YourDB';GO

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

लॉग सिकोड़ें

जब तक आप नियंत्रण से बाहर के लेन-देन लॉग को वापस नियंत्रण में लाने के लिए सिकुड़न ऑपरेशन करने वाले व्यक्ति नहीं हैं, तब तक आप इस काउंटर को बढ़ते हुए नहीं देखना चाहते। अगर कोई बिना किसी अच्छे कारण के लेन-देन लॉग को छोटा कर देता है, तो यह फिर से बढ़ने की संभावना है, जिससे समस्याएँ पैदा हो सकती हैं जैसा कि मैंने पहले ब्लॉग किया था।

प्रयुक्त लॉग का प्रतिशत

आपको इस काउंटर की निगरानी करनी चाहिए और यदि मूल्य 90% से अधिक हो जाता है, तो चिंतित होना चाहिए, क्योंकि यह इंगित करता है कि एक लॉग वृद्धि आसन्न हो सकती है और लेनदेन लॉग सही ढंग से साफ़ नहीं हो पा रहा है, जैसा कि मैंने ऊपर चर्चा की है।

लॉग फ्लश प्रतीक्षा/सेकंड

आप चाहते हैं कि यह मान वही रहे या घटे। यदि यह बढ़ता है, तो इसका मतलब है कि आपके पास लॉग फ्लश तंत्र के अंदर एक I/O सबसिस्टम अड़चन या एक अड़चन है क्योंकि आप लॉग के कई छोटे हिस्से को फ्लश कर रहे हैं। लॉग के लिए 32 बकाया I/Os को हिट करने के साथ यहां वृद्धि भी सहसंबद्ध हो सकती है। sys.dm_io_pending_io_requests . की चर्चा देखें अधिक विवरण के लिए ऊपर।

लॉग बाइट फ्लश/सेकंड और लॉग फ्लश/सेकंड

ये दो काउंटर आपको पहले काउंटर को दूसरे काउंटर से विभाजित करके औसत लॉग फ्लश आकार का पता लगाने की अनुमति देते हैं। परिणाम 512 और 61440 के बीच का मान होगा (लॉग फ्लश का न्यूनतम और अधिकतम आकार, क्रमशः)। लॉग फ्लश प्रतीक्षा/सेकंड बढ़ने के साथ कम मान के सहसंबद्ध होने की अधिक संभावना है। फिर से, sys.dm_io_pending_io_requests . की चर्चा देखें अधिक विवरण के लिए ऊपर।

विस्तारित ईवेंट

आप में से अधिक उन्नत लोगों के लिए, कुछ विस्तारित ईवेंट हैं जिनका उपयोग आप यह देखने के लिए कर सकते हैं कि लॉग के साथ क्या हो रहा है। मेरा सुझाव है कि आप SQL Server 2012 SSMS में डेटाबेस लॉग फ़ाइल IO ट्रैकिंग टेम्पलेट का उपयोग करके प्रारंभ करें। आप ऑब्जेक्ट एक्सप्लोरर पर जाकर और फिर अपने उदाहरण -> प्रबंधन -> विस्तारित ईवेंट और नए सत्र विज़ार्ड का चयन करने के लिए सत्र पर राइट-क्लिक करके इसे प्राप्त कर सकते हैं। सामने आने वाली विंडो में, एक सत्र का नाम टाइप करें और ड्रॉप डाउन से ट्रैकिंग टेम्प्लेट चुनें। फिर Ctrl+Shift+N दबाएं और सत्र को एक क्वेरी विंडो में स्क्रिप्ट किया जाएगा। वहाँ सब कुछ का विवरण इस पोस्ट के दायरे से बाहर है, दुर्भाग्य से, लेकिन टेम्पलेट विवरण बहुत व्याख्यात्मक है:

यह टेम्पलेट एसिंक्रोनस आईओ, डेटाबेस लॉग फ्लश, फाइल राइट्स, LOGFLUSHQ प्रकार के स्पिनलॉक बैकऑफ और WRITELOG प्रकार की प्रतीक्षा करके सर्वर पर डेटाबेस लॉग फ़ाइलों के लिए IO की निगरानी करता है। यह टेम्प्लेट दो तरह से डेटा एकत्र करता है:कच्चे डेटा को रिंग बफर में एकत्र किया जाता है और स्पिनलॉक बैकऑफ़ जानकारी को इनपुट बफर (sql_text) के आधार पर एकत्रित किया जाता है। प्रति डेटाबेस एक लॉग फ़ाइल के लिए सत्र को फ़िल्टर किया जाता है; यदि आपके पास एकाधिक लॉग फ़ाइलें हैं तो आप file_write_completed और file_write ईवेंट के लिए फ़िल्टर को संशोधित कर सकते हैं ताकि केवल file_id =2 से अधिक शामिल हो सकें।

SQL सर्वर 2012 में एक नया एक्सटेंडेड इवेंट भी है जिसे transaction_log कहा जाता है जिसका उपयोग सभी प्रकार के दिलचस्प विश्लेषण करने के लिए किया जा सकता है कि कौन से लॉग रिकॉर्ड उत्पन्न किए जा रहे हैं। यह निश्चित रूप से एक विषय है जिसे मैं भविष्य की पोस्ट में शामिल करूंगा।

सारांश

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