बफर कैश:यह क्या है और यह डेटाबेस के प्रदर्शन को कैसे प्रभावित करता है?

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

मुझे बफ़र कैश की निगरानी करने की आवश्यकता क्यों है?

मेमोरी का उपयोग प्रदर्शन पर महत्वपूर्ण प्रभाव डाल सकता है। जब मेमोरी अपर्याप्त होती है, तो डेटा पेज बफर कैश से बार-बार शुद्ध हो जाते हैं। यह प्रश्नों को धीमा कर देता है क्योंकि SQL सर्वर को डेटा पृष्ठ को खोजने के लिए डिस्क पर जाना होता है, इसे बफर कैश में पुनर्स्थापित करना होता है, और फिर क्वेरी परिणाम वापस करने से पहले पृष्ठ को पढ़ना होता है।

क्वेरी के धीरे-धीरे चलने के कई कारण हैं। लेकिन अगर आप मेमोरी की समस्या को दूर करना चाहते हैं, तो देखें कि बफर कैश के अंदर क्या चल रहा है। इसके अंदर झांकने से पता चलेगा कि कौन सा डेटाबेस, टेबल या इंडेक्स मेमोरी को हॉगिंग कर रहा है और बफर पर दबाव डाल रहा है।

यह देखने के लिए कि कौन सा डेटाबेस सबसे अधिक मेमोरी की खपत करता है, क्वेरी का उपयोग करें:

चयन करें डेटाबेस_आईडीजब 32767 फिर 'ResourceDb'ELSE db_name(database_id)END AS डेटाबेस_नाम, COUNT(1)/128 AS megabytes_in_cacheFROM sys.dm_os_buffer_descriptorsGROUP BY DB_DESC (database_id), megabytes_id) , megabytes_id> में; 

 सबसे अधिक मेमोरी की खपत करने वाली तालिका या अनुक्रमणिका की पहचान करने के लिए, इस क्वेरी को उस डेटाबेस में चलाएँ जिसका आप निरीक्षण करना चाहते हैं:
 
सेलेक्ट COUNT(1)/128 AS मेगाबाइट्स_इन_कैश,नाम,index_idFROM sys.dm_os_buffer_descriptors AS bdINNER JOIN(SELECT object_name(object_id) AS name,index_id ,allocation_unit_idFROM sys.allocation_units as p auINNER. .hobt_idAND (au.type =1 या au.type =3)यूनियन ALLSELECT object_name(object_id) AS नाम,index_id, आबंटन_unit_idFROM sys.allocation_units AS AUINNER जॉइन sys.partitions AS pON au.container_id =p.partition_idऔर au.partition_id ) AS objON bd.allocation_unit_id =obj.allocation_unit_idWHERE database_id =DB_ID()GROUP by name, index_idORDER BY megabytes_in_cache DESC;
 
मैट्रिक्स के साथ मेमोरी प्रबंधित करें
 

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

 स्मृति से संबंधित प्रदर्शन समस्याओं को सुधारने के लिए निगरानी करने के लिए शीर्ष पांच मीट्रिक यहां दिए गए हैं:
 <एच3>1. बफर कैश हिट अनुपात 
 
यह मीट्रिक दिखाता है कि SQL सर्वर बफर कैश का उपयोग कैसे करता है
 
हिट अनुपात उन पेज अनुरोधों के प्रतिशत की पहचान करता है जो बफ़र कैश से डेटा पेजों बनाम सभी डेटा पेज अनुरोधों द्वारा पूरे किए गए थे
 
वे पृष्ठ जो बफ़र कैश में नहीं मिलते हैं उन्हें डिस्क से पढ़ा जाता है, जो बहुत धीमा होता है
 
आदर्श बफर कैश अनुपात 100 है (यानी, SQL सर्वर बफर कैश से सभी पृष्ठों को पढ़ता है और डिस्क से कोई नहीं)
 
अनुशंसित बफर कैश मान 90 से अधिक है
 
 <एच3>2. पृष्ठ जीवन प्रत्याशा (पीएलई) 
 
पेज लाइफ एक्सपेक्टेंसी यह मापता है कि डेटा पेज बफर कैश में कितनी देर (सेकंड में) रहता है
 
पीएलई जितना लंबा होगा, SQL सर्वर बफ़र कैश से पृष्ठों को पढ़ेगा और डिस्क पर जाने की आवश्यकता नहीं होगी, इसकी संभावना उतनी ही अधिक होगी
 
अगर पर्याप्त मेमोरी नहीं है, तो नए पेजों के लिए जगह खाली करने के लिए डेटा पेजों को बफर कैश से अधिक बार फ्लश किया जाता है
 
ऐतिहासिक रूप से, जब सिस्टम में अब की तुलना में बहुत कम मेमोरी थी, एक "सामान्य" PLE मान 300 सेकंड था
 
आज, "अच्छा" PLE निर्धारित करने के लिए एक सूत्र का उपयोग किया जाता है:पृष्ठ जीवन प्रत्याशा =आपके सर्वर पर प्रत्येक 4 GB RAM के लिए 300 सेकंड
 
यदि समय के साथ निगरानी की जाए तो PLE स्थिर रहना चाहिए
 
तेज़, बार-बार कम होना स्मृति समस्याओं का संकेत देता है
 
50% से अधिक की एक बूंद की तुरंत जांच की जानी चाहिए
 
 <एच3>3. पृष्ठ पढ़ता/सेकंड (सर्वर स्तर) 
 
यह मीट्रिक दिखाता है कि एक उदाहरण पर सभी डेटाबेस में एक सेकंड में कितने भौतिक रीड (यानी डिस्क से पढ़े गए) हुए हैं
 
शारीरिक पढ़ना महंगा और धीमा है
 
बड़े डेटा कैश, इंटेलिजेंट इंडेक्स और अधिक कुशल क्वेरी का उपयोग करके या डेटाबेस डिज़ाइन को बदलकर भौतिक पठन को कम करें
 
अनुशंसित मान 90 से कम है
 
90 से अधिक मान अपर्याप्त स्मृति और अनुक्रमण समस्याओं को इंगित करता है
 
 <एच3>4. पेज राइट/सेकंड 
 
यह मीट्रिक एक सेकंड में सर्वर स्तर पर डिस्क पर लिखे गए पृष्ठों की संख्या दिखाता है
 
अनुशंसित मान 90 से कम है
 
 
5. पेज इनपुट/सेकंड और पेज आउटपुट/सेकंड (मेमोरी काउंटर)
 
 
पेज इनपुट/सेकंड हर सेकेंड डिस्क से लाए गए पेजों की संख्या है
 
पेज आउटपुट/सेकंड बफर कैश में जगह बनाने के लिए हर सेकेंड डिस्क पर लिखे गए पेजों की संख्या है
 
पेज/सेकंड पेज इनपुट/सेकंड और पेज आउटपुट/सेकंड का योग है
 
यदि पृष्ठ/सेकंड का मान लगातार 50 से अधिक है, तो अतिरिक्त जांच की आवश्यकता है
 
 

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