SQL सर्वर सिस्टम डेटाबेस रखरखाव

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

SQL सर्वर सिस्टम डेटाबेस

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

सिस्टम डेटाबेस हैं:

• मास्टर - डिफ़ॉल्ट रूप से स्थापित
• Msdb - डिफ़ॉल्ट रूप से स्थापित
• मॉडल - डिफ़ॉल्ट रूप से स्थापित
• Tempdb - डिफ़ॉल्ट रूप से स्थापित
• संसाधन - डिफ़ॉल्ट रूप से स्थापित . SQL सर्वर 2005 में पेश किया गया और बाद के SQL सर्वर संस्करणों में उपलब्ध है और इसलिए SQL Server 2000 और पुराने संस्करणों में उपलब्ध नहीं है।
• वितरण - उपयोगकर्ता कार्रवाई द्वारा निर्मित . प्रतिकृति को कॉन्फ़िगर करने के लिए उपयोगकर्ता वितरण डेटाबेस बना सकते हैं।

SQL सर्वर में स्थापित सिस्टम डेटाबेस को देखने के लिए, हम SSMS का उपयोग कर सकते हैं।

अपने SQL सर्वर इंस्टेंस से कनेक्ट करें, विस्तृत करें डेटाबेस > सिस्टम डेटाबेस :

क्या आपने देखा है कि संसाधन उपरोक्त सूची में डेटाबेस गायब है? बात यह है कि, संसाधन डेटाबेस एक विशेष सिस्टम डेटाबेस है जो SSMS ऑब्जेक्ट एक्सप्लोरर में सूचीबद्ध नहीं है। हालांकि, हम sys.sysaltfiles नामक सिस्टम DMV से संसाधन डेटाबेस विवरण को क्वेरी कर सकते हैं और क्वेरी निष्पादित करें:

SELECT dbid, db_name(dbid) database_name, fileid, name, filename
FROM sys.sysaltfiles
WHERE dbid NOT BETWEEN 5 AND 11

परिणामों में, हम सिस्टम डेटाबेस को क्रम में देख सकते हैं:मास्टर, tempdb, मॉडल, msdb, वितरण , और अंत में, dbid 32767 जो एक संसाधन डेटाबेस है। हालाँकि, यह संसाधन डेटाबेस कोई डेटाबेस नाम प्रदर्शित नहीं करता है क्योंकि इसमें sys.databases में कोई प्रविष्टि नहीं है। . मैंने dbid 5 और 11 के बीच कुछ उपयोगकर्ता डेटाबेस को बाहर रखा है और इसमें AdventureWorks_REPL शामिल किया है। एक उदाहरण के रूप में यह दिखाने के लिए कि DMV उपयोगकर्ता डेटाबेस को भी प्रदर्शित कर सकता है। हम बाद में संसाधन डेटाबेस और अन्य सिस्टम डेटाबेस के बारे में अधिक विस्तार से जानेंगे।

SQL सिस्टम डेटाबेस प्रतिबंध

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

सिस्टम डेटाबेस को ऑफ़लाइन नहीं लिया जा सकता

हम नीचे दिखाए गए अनुसार ALTER DATABASE कमांड का उपयोग करके उपयोगकर्ता डेटाबेस को ऑफ़लाइन ले सकते हैं:

ALTER DATABASE AdventureWorks SET OFFLINE WITH ROLLBACK IMMEDIATE
GO

हालाँकि, यदि हम उपरोक्त कमांड का उपयोग करके किसी भी सिस्टम डेटाबेस को ऑफ़लाइन लेने का प्रयास करते हैं, तो हमें एक त्रुटि प्राप्त होगी जैसा कि नीचे दिखाया गया है:

सिस्टम डेटाबेस को छोड़ा नहीं जा सकता

जबकि हम DROP DATABASE कमांड को निष्पादित करके उपयोगकर्ता डेटाबेस को छोड़ सकते हैं

DROP DATABASE AdventureWorks

यदि हम किसी भी सिस्टम डेटाबेस को DROP करने का प्रयास करते हैं, तो हमें त्रुटि प्राप्त होगी जैसा कि नीचे दिखाया गया है:

सिस्टम डेटाबेस के मालिक को बदला नहीं जा सकता

सिस्टम डेटाबेस का स्वामी sa . है डिफ़ॉल्ट रूप से। इसे बदला नहीं जा सकता। सिस्टम डेटाबेस स्वामी का नाम बदलने का प्रयास त्रुटियों को भड़काएगा।

हालाँकि, एक अपवाद है। msdb . के स्वामी को संशोधित करना संभव है डेटाबेस।

use [master];
GO
ALTER AUTHORIZATION ON DATABASE::[master] TO [RRJ\RRJ]
GO

सिस्टम डेटाबेस का डेटाबेस नाम बदला नहीं जा सकता

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

ALTER DATABASE master MODIFY NAME = RRJ_master;
GO

सिस्टम डेटाबेस के संयोजन को बदला नहीं जा सकता

सिस्टम डेटाबेस SQL ​​सर्वर स्थापना के समय चुने गए Collation नाम के साथ बनाए जाते हैं। एक बार स्थापित होने के बाद, सिस्टम डेटाबेस के संयोजन को बदला नहीं जा सकता है। सिस्टम डेटाबेस संयोजन को बदलने का एकमात्र तरीका SQL सर्वर इंस्टेंस को सही संयोजन के साथ पुनर्स्थापित करना है।

सिस्टम डेटाबेस के प्राथमिक फ़ाइल समूह को READ_ONLY मोड पर सेट नहीं किया जा सकता

चूंकि सिस्टम डेटाबेस SQL ​​सर्वर इंस्टेंस से संबंधित महत्वपूर्ण जानकारी को कैप्चर करता है, SQL सर्वर प्राथमिक फ़ाइल समूह में रहने वाली प्राथमिक डेटा फ़ाइलों को केवल पढ़ने के लिए के रूप में सेट करने की अनुमति नहीं देता है। ।

डेटा कैप्चर बदलें फ़ीचर सिस्टम डेटाबेस पर सक्षम नहीं किया जा सकता

इस सुविधा का उपयोग ट्रैक किए गए टेबल पर डेटाबेस पर होने वाले प्रत्येक डीएमएल परिवर्तन को ट्रैक करने के लिए किया जाता है। यदि हम किसी सिस्टम डेटाबेस पर डेटा कैप्चर बदलें सुविधा को सक्षम करने का प्रयास करते हैं, तो त्रुटि होगी:

use master
GO
exec sys.sp_cdc_enable_db

अब जब हम सिस्टम डेटाबेस और उपयोगकर्ता डेटाबेस के बीच अंतर के बारे में स्पष्ट हैं, तो हम प्रत्येक सिस्टम डेटाबेस के उद्देश्यों की अधिक विस्तार से जांच कर सकते हैं।

SQL सर्वर में मास्टर डेटाबेस

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

मास्टर डेटाबेस में संग्रहीत इन प्रमुख विवरणों में लॉगिन खाते, लिंक किए गए सर्वर विवरण, समापन बिंदु, सिस्टम कॉन्फ़िगरेशन सेटिंग्स और सभी उपयोगकर्ता डेटाबेस के बारे में विवरण शामिल हैं।

अब सवाल आता है। SQL सर्वर सेवा कैसे जानती है कि मास्टर डेटाबेस का डेटा और लॉग फ़ाइलें कहाँ उपलब्ध हैं? उत्तर SQL सर्वर सेवा के स्टार्टअप कॉन्फ़िगरेशन पैरामीटर में निहित है।

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

एसक्यूएल सर्वर सेवाएं पर क्लिक करें इस सर्वर या पीसी पर उपलब्ध सेवाओं की सूची देखने के लिए:

एक सेकंड रुको! यह services.msc से परिचित लगता है सर्वर में उपलब्ध सभी सेवाओं को सूचीबद्ध करना लेकिन केवल SQL सर्वर से संबंधित सेवाओं को प्रदर्शित करना।

आइए खोलें services.msc यह देखने के लिए कि यह कैसा दिखता है और SQL सर्वर कॉन्फ़िगरेशन प्रबंधक और services.msc में अंतरों को सत्यापित करने के लिए तुलना करने के लिए कि कौन सा बेहतर है।

SQL सर्वर कॉन्फ़िगरेशन प्रबंधक वर्तमान में चल रही सेवाओं की प्रक्रिया ID प्रदर्शित करता है। हमें वह services.msc . में नहीं मिला . बेशक, हम यह जानकारी विंडोज टास्क मैनेजर से प्राप्त कर सकते हैं, लेकिन SQL सर्वर कॉन्फ़िगरेशन मैनेजर ने इसे एक ही स्थान पर देखने में हमारी मदद की।

अब, आइए विस्तार से देखें। SQL सर्वर सेवा पर services.msc . से राइट-क्लिक करें . आप नीचे दिए गए मेनू देखेंगे:सामान्य , लॉग ऑन करें , वसूली , और निर्भरता ।

SQL सर्वर कॉन्फ़िगरेशन प्रबंधक से, SQL सर्वर(MSSQLSERVER) पर राइट-क्लिक करें सेवा> गुण . यह नीचे दिए गए मेनू को सूचीबद्ध करता है - लॉग ऑन, सेवा। फ़ाइलस्ट्रीम, उन्नत, हमेशा उच्च उपलब्धता पर , और स्टार्टअप पैरामीटर्स ।

स्टार्टअप पैरामीटर सेवा का जो मास्टर डेटाबेस डेटा और लॉग फ़ाइलों के स्थान को संग्रहीत करता है केवल SQL सर्वर कॉन्फ़िगरेशन प्रबंधक में उपलब्ध था ।

स्टार्टअप पैरामीटर्स . पर क्लिक करें विवरण देखने के लिए - मौजूदा . के लिए पैरामीटर . आपको निम्न जानकारी दिखाई देगी:

• मास्टर डेटाबेस का भौतिक स्थान डेटा फ़ाइल
• मास्टर डेटाबेस का भौतिक स्थान लेन-देन लॉग फ़ाइल
• त्रुटि लॉग फ़ोल्डर का भौतिक स्थान जहां SQL सर्वर सेवा से संबंधित त्रुटियां स्थित हैं।

हम एकल उपयोगकर्ता मोड (-m) . जैसे अधिक स्टार्टअप पैरामीटर जोड़ सकते हैं , आदि। उसके लिए, हमें स्टार्टअप पैरामीटर निर्दिष्ट करें में आवश्यक मान निर्दिष्ट करने होंगे और जोड़ें . क्लिक करें ।

हमने देखा है कि SQL सर्वर कॉन्फ़िगरेशन प्रबंधक न केवल उन्नत विवरण प्रदर्शित करता है बल्कि हमें SQL सर्वर सेवा से संबंधित बहुत से उन्नत कॉन्फ़िगरेशन करने की अनुमति देता है। इसलिए, मैं व्यक्तिगत रूप से डिफ़ॉल्ट Services.msc विकल्प की तुलना में SQL सर्वर-संबंधित सेवाओं को रोकने/शुरू करने के लिए SQL सर्वर कॉन्फ़िगरेशन प्रबंधक का उपयोग करने की सलाह दूंगा।

मास्टर डेटाबेस के लिए अनुशंसित अभ्यास

चूंकि मास्टर डेटाबेस SQL ​​सर्वर इंस्टेंस के बारे में महत्वपूर्ण विवरण संग्रहीत करता है, इसलिए उस डेटाबेस को संभालने के दौरान सर्वोत्तम प्रथाओं का पालन करने की अनुशंसा की जाती है।

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

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

• SQL सर्वर स्टार्टअप प्रक्रिया विकल्प का समर्थन करता है SQL सर्वर इंस्टेंस शुरू करने पर कुछ संग्रहीत कार्यविधियाँ निष्पादित करने के लिए। यह sp_procoption . का उपयोग करता है प्रक्रिया। इस विकल्प का उपयोग करते समय सावधान रहें क्योंकि गैर-इष्टतम कोड या पुनरावर्ती तर्क होने से SQL सर्वर इंस्टेंस के स्टार्टअप समय पर असर पड़ सकता है।

यदि SQL सर्वर मास्टर डेटाबेस के साथ किसी भी समस्या के कारण प्रारंभ नहीं हो पाता है, तो हमें पिछले ज्ञात अच्छे बैकअप से मास्टर डेटाबेस को पुनर्स्थापित करने की आवश्यकता है।

SQL सर्वर में मॉडल डेटाबेस

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

मॉडल डेटाबेस में बनाए गए टेबल, प्रक्रियाओं आदि जैसी कोई भी उपयोगकर्ता ऑब्जेक्ट भी उस SQL ​​सर्वर इंस्टेंस में नए उपयोगकर्ता डेटाबेस में स्वचालित रूप से बनाई जाएगी।

आइए मॉडल डेटाबेस में एक नई तालिका बनाकर इसे सत्यापित करें:

आइए देखें कि क्या यह तालिका मॉडल डेटाबेस में मौजूद है:

मॉडल डेटाबेस उपयोगकर्ता डेटाबेस के डिफ़ॉल्ट फ़ाइल पथ को भी संग्रहीत करता है जैसा कि नीचे डेटाबेस गुण में दिखाया गया है। msdb . के डेटाबेस।

वर्तमान कॉन्फ़िगरेशन के अनुसार, प्रारंभिक फ़ाइल आकार दोनों का डेटा और लॉग फ़ाइलें उन दोनों के लिए ऑटो-ग्रोथ के साथ 8 एमबी पर सेट है, दोनों 64 एमबी पर सेट हैं।

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

SSMS में, सर्वर पर राइट-क्लिक करें > गुण > डेटाबेस सेटिंग . डेटाबेस डिफ़ॉल्ट स्थान देखें:

फ़ाइल पथ को इच्छित पथ में बदलें और ठीक . क्लिक करें . उपयोगकर्ता डेटाबेस डेटा और लॉग करें फ़ाइलें आपके द्वारा प्रदान किए गए नए पथ में बनाई जाएंगी।

आइए model_test . नाम से एक नया डेटाबेस बनाएं और आरंभिक और ऑटोग्रोथ फ़ाइल गुणों और model_verify के साथ नए डेटाबेस डेटा और लॉग फ़ाइल पथों की जांच करें नए डेटाबेस पर तालिका।

आइए model_test की पुष्टि करें डेटा और लॉग फ़ाइल पथ। model_test . पर राइट-क्लिक करें डेटाबेस> गुण > फ़ाइलें :

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

अब, हम जांचेंगे कि क्या model_verify तालिका model_test . में बनाई गई है डेटाबेस। हम इस नए डेटाबेस को देख सकते हैं।

तालिकाओं के अलावा, यह दृश्य, संग्रहीत कार्यविधियों, कार्यों और मॉडल डेटाबेस में बनाए गए किसी भी ऑब्जेक्ट पर लागू होता है।

मॉडल डेटाबेस के लिए अनुशंसित अभ्यास

चूंकि मॉडल डेटाबेस किसी भी नए उपयोगकर्ता डेटाबेस निर्माण के लिए एक टेम्पलेट के रूप में कार्य करता है, इसलिए हमें इसके साथ व्यवहार करते समय नीचे दिए गए अभ्यासों को लागू करना चाहिए:

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

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

• डेटा और लॉग फ़ाइलों के लिए प्रारंभिक फ़ाइल आकार और ऑटोग्रोथ पैरामीटर कॉन्फ़िगर करें। यह उपयोगकर्ता डेटाबेस में डेटा और लॉग फ़ाइल आकार को बेहतर ढंग से प्रबंधित करने और प्रदर्शन में सुधार करने में मदद करता है।

MSDB डेटाबेस

msdb सिस्टम डेटाबेस सिस्टम टेबल में नीचे दी गई महत्वपूर्ण जानकारी को स्टोर करता है:

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

दूसरे शब्दों में, msdb सिस्टम डेटाबेस SQL ​​सर्वर एजेंट सेवाओं और कुछ अन्य संबंधित सेवाओं से संबंधित सभी महत्वपूर्ण जानकारी संग्रहीत करता है।

msdb डेटाबेस के लिए अनुशंसित अभ्यास

एमएसडीबी डेटाबेस SQL सर्वर एजेंटों, नौकरियों और डेटाबेस मेल से संबंधित बहुत सारी महत्वपूर्ण कॉन्फ़िगरेशन जानकारी संग्रहीत करता है। यह ऐतिहासिक विवरण भी संग्रहीत करता है। इसलिए, हमें msdb डेटाबेस के साथ व्यवहार करते समय नीचे दिए गए अभ्यासों को लागू करना चाहिए:

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

• भले ही SQL सर्वर उपयोगकर्ताओं को msdb डेटाबेस पर उपयोगकर्ता ऑब्जेक्ट बनाने की अनुमति देता है, यह अनुशंसा की जाती है कि msdb डेटाबेस में कोई उपयोगकर्ता तालिका या ऑब्जेक्ट न बनाएं और msdb डेटाबेस के आकार को और बढ़ाएँ।

• msdb डेटाबेस आकार को नियंत्रण में रखने और कई तालिकाओं में विशाल डेटा होने के प्रदर्शन प्रभावों से बचने के लिए msdb सिस्टम तालिकाओं की नियमित सफाई करें।

Tempdb डेटाबेस

tempdb सिस्टम डेटाबेस को एक वैश्विक कार्य क्षेत्र के रूप में माना जा सकता है जो SQL सर्वर इंस्टेंस से जुड़े सभी उपयोगकर्ताओं के लिए उनके चयन या अन्य संचालन करने के लिए उपलब्ध है ।

जब उपयोगकर्ता अपना संचालन करते हैं तो Tempdb डेटाबेस नीचे दिए गए ऑब्जेक्ट प्रकारों को धारण करेगा:

• उपयोगकर्ताओं द्वारा स्पष्ट रूप से बनाई गई अस्थायी वस्तुएं या तो स्थानीय या वैश्विक अस्थायी टेबल और इंडेक्स, टेबल वेरिएबल, टेबल-वैल्यू फ़ंक्शन में उपयोग की जाने वाली टेबल और कर्सर हो सकती हैं।
• डेटाबेस इंजन द्वारा बनाई गई आंतरिक वस्तुएं, जैसे:
  • स्पूल, कर्सर, सॉर्ट और अस्थायी बड़े ऑब्जेक्ट (LOB) के लिए मध्यवर्ती परिणामों के लिए उपयोग की जाने वाली कार्य तालिका
  • हैश जॉइन या हैश एग्रीगेट ऑपरेशंस के लिए वर्क फाइल्स
  • यदि SORT_IN_TEMPDB को ON पर सेट किया गया है और GROUP BY, ORDER BY, या UNION क्वेरीज़ जैसे अन्य संचालन पर सेट किया गया है, तो अनुक्रमणिका बनाने या पुनर्निर्माण करने के दौरान इंटरमीडिएट सॉर्ट परिणाम
• संस्करण स्टोर जो पंक्ति संस्करण सुविधा का समर्थन करते हैं या तो सामान्य संस्करण स्टोर या ऑनलाइन इंडेक्स बिल्ड संस्करण स्टोर।

जब भी SQL सर्वर सेवा प्रारंभ या पुनरारंभ होती है, तो मॉडल डेटाबेस की सहायता से tempdb डेटाबेस नए सिरे से बनाया जाएगा। इस प्रकार, tempdb एकमात्र सिस्टम डेटाबेस है जिसका बैकअप नहीं लिया जा सकता ।

यदि हम इसका बैकअप लेने का प्रयास करते हैं, तो हमें त्रुटियाँ प्राप्त होंगी:

चूंकि हम लगभग सभी उपयोगकर्ता संचालन में tempdb का उपयोग करते हैं, यह डेटाबेस SQL ​​सर्वर के कई संस्करणों में एक महत्वपूर्ण प्रदर्शन बाधा उत्पन्न करता है। SQL सर्वर 2016 से शुरू होकर, Microsoft द्वारा कई अनुकूलन तकनीकों को लागू किया गया था - हम उन पर बाद में चर्चा करेंगे।

Tempdb डेटाबेस के लिए अनुशंसित प्रथाओं में जाने से पहले, आइए नीचे दिखाए गए डिफ़ॉल्ट कॉन्फ़िगरेशन के तहत इसकी डेटा फ़ाइलों पर एक त्वरित नज़र डालें:

मेरे वर्तमान SQL सर्वर इंस्टेंस के लिए, हमारे पास tempdb डेटाबेस के लिए 4 डेटा फ़ाइलें और एक लॉग फ़ाइल है।

SQL सर्वर 2016 से शुरू होकर, हमारे पास SQL ​​​​सर्वर इंस्टॉलर है जो हमें tempdb में कई फाइलें जोड़ने की अनुमति देता है। 8 एमबी के शुरुआती आकार और 64 एमबी के ऑटोग्रोथ आकार वाली उपरोक्त 4 फाइलें नीचे दिखाए गए डिफ़ॉल्ट विकल्पों का उपयोग करके बनाई गई थीं।

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

एकाधिक डेटा फ़ाइलें होने से तार्किक रूप से कुछ कोर को एक फ़ाइल में जोड़ दिया जाएगा। इस प्रकार, हमारे पास tempdb डेटा फ़ाइलों पर कम विवाद है। यह tempdb डेटा फ़ाइलों पर प्रदर्शन प्रभाव में सुधार करेगा।

tempdb डेटाबेस के लिए अनुशंसित अभ्यास

चूंकि tempdb डेटाबेस सभी उपयोगकर्ता गतिविधियों के लिए एक वैश्विक कार्य क्षेत्र की तरह है, इसलिए उपयोगकर्ता की गतिविधियों के आधार पर tempdb का आकार बढ़ता है। यह संपूर्ण SQL सर्वर आवृत्ति के लिए एक प्रदर्शन बाधा हो सकती है।

इसलिए, हमें निम्नलिखित प्रथाओं को लागू करना चाहिए:

1. बेहतर प्रदर्शन के लिए उच्च IOPS प्राप्त करने के लिए tempdb डेटा और लॉग फ़ाइलों को उच्च-प्रदर्शन संग्रहण पर रखें।
2. सुनिश्चित करें कि tempdb डेटाबेस विवाद को कम करने और tempdb डेटाबेस पर प्रदर्शन बाधाओं से बचने के लिए कई डेटा फ़ाइलों में विभाजित है।
   • यदि लॉजिकल कोर की संख्या 8 से कम है, तो हमारे पास प्रति लॉजिकल कोर में एक tempdb डेटा फ़ाइल हो सकती है। हमारे परीक्षण उदाहरण में, हमारे पास 4 तार्किक कोर थे। इसलिए, tempdb पर 4 डेटा फ़ाइलें पर्याप्त होनी चाहिए।
   • यदि तार्किक कोर की संख्या 8 से अधिक है, तो 8 डेटा फ़ाइलों के साथ प्रारंभ करें और यदि tempdb डेटाबेस पर विवाद और प्रदर्शन के मुद्दे देखे जाते हैं, तो 4 डेटा फ़ाइलों से वृद्धि करें।
   • यदि सर्वर में लॉजिकल कोर की संख्या 32 या 64 है, तो हम 8 डेटा फाइलों से शुरू कर सकते हैं। इसका मतलब है कि एक डेटा फ़ाइल के लिए 4 कोर या 8 कोर तार्किक रूप से जुड़े हुए हैं।
     
     एकाधिक tempdb डेटा फ़ाइलों के बारे में अधिक स्पष्टता के लिए, मैं आपको पॉल रान्डल के उत्कृष्ट लेख की अनुशंसा करता हूं।
     
3. सुनिश्चित करें कि tempdb डेटा फ़ाइलें इष्टतम प्रारंभिक फ़ाइल आकार के साथ कॉन्फ़िगर की गई हैं। आदर्श रूप से, यह एक परीक्षण और त्रुटि दृष्टिकोण के माध्यम से प्राप्त किया जाना चाहिए। इष्टतम प्रारंभिक फ़ाइल आकार के साथ Tempdb कम प्रारंभिक फ़ाइल आकार के साथ कॉन्फ़िगर किए गए tempdb की तुलना में कम बार बढ़ता है जो विखंडन के लिए कई बार बढ़ता है। उदाहरण के लिए, वर्तमान कॉन्फ़िगरेशन में, सभी फ़ाइलों को 8 एमबी प्रारंभिक फ़ाइल आकार के साथ कॉन्फ़िगर किया गया है जो SQL वर्कलोड को संभालने के लिए बहुत कम है। इस प्रकार, परीक्षण और त्रुटि दृष्टिकोण लागू करें और प्रारंभिक फ़ाइल आकार को 512 एमबी या 1 जीबी, या कुछ अन्य मान पर सेट करें।
4. सुनिश्चित करें कि सभी tempdb डेटा फ़ाइलें समान फ़ाइल आकार पर सेट हैं। ऑटो-ग्रोथ प्रॉपर्टी को समान रूप से परिभाषित किया जाना चाहिए। हमारे परिदृश्य में, सभी फाइलें 64 एमबी ऑटोग्रोथ पर सेट हैं। ऑटोग्रोथ आकार को 512 एमबी या 1 जीबी, या किसी अन्य उपयुक्त मान पर सेट करने से tempdb डेटा फ़ाइलों पर लगातार ऑटोग्रोथ को कम करने में मदद मिलती है।
5. सुनिश्चित करें कि tempdb लॉग फ़ाइल के लिए प्रारंभिक फ़ाइल आकार और ऑटोग्रोथ को tempdb डेटा फ़ाइलों के समान इष्टतम मान के लिए कॉन्फ़िगर किया गया है। चूंकि tempdb का पुनर्प्राप्ति मॉडल डिफ़ॉल्ट रूप से सरल पर सेट है और इसे संशोधित नहीं किया जा सकता है, इसलिए tempdb लॉग फ़ाइल की प्रारंभिक फ़ाइल आकार और ऑटोग्रोथ प्रॉपर्टी को कॉन्फ़िगर करना पर्याप्त होना चाहिए।

Tempdb SQL सर्वर इंस्टेंस प्रदर्शन के लिए महत्वपूर्ण है। हम अपने अगले लेखों में tempdb पर आने वाली लगातार समस्याओं और इसे बेहतर तरीके से सिकोड़ने के बारे में विस्तृत रूप से देखेंगे।

SQL सर्वर में संसाधन डेटाबेस

संसाधन प्रणाली डेटाबेस एकमात्र रीड-ओनली सिस्टम डेटाबेस है जो SSMS में सिस्टम डेटाबेस के अंतर्गत सूचीबद्ध नहीं है जैसा कि पहले देखा गया था।

डेटाबेस आईडी (dbid) सभी उदाहरणों में संसाधन डेटाबेस की संख्या 32767 होगी जो कि SQL सर्वर इंस्टेंस के भीतर समर्थित डेटाबेस की अधिकतम संख्या भी है। इसे sys.sysaltfiles . से क्वेर किया जा सकता है सिस्टम डीएमवी। sys.sysaltfiles . पर निम्न चयन क्वेरी निष्पादित करना परिणाम लौटाएगा दिखा रहा है कि संसाधन डेटाबेस की डेटा और लॉग फ़ाइलें कहाँ स्थित हैं:

हम उपर्युक्त पथ में उपलब्ध संसाधन डेटाबेस की भौतिक फ़ाइलें देख सकते हैं। संशोधित दिनांक SQL सर्वर इंस्टेंस इंस्टॉलेशन के समय को इंगित करता है या पिछली बार सर्विस पैक (SP) या संचयी अपडेट (CU) को इस इंस्टेंस पर लागू किया गया है।

संसाधन डेटाबेस में सभी सिस्टम ऑब्जेक्ट होते हैं, जैसे sys.objects , sys.databases , sys.sysaltfiles , आदि शारीरिक रूप से इसके अंदर। यह डेटाबेस तार्किक रूप से इन सभी वस्तुओं को सूचीबद्ध करता है sys स्कीमा के तहत उदाहरण में उपलब्ध सभी डेटाबेस में . चूंकि संसाधन डेटाबेस केवल पढ़ने के लिए है, इस पर कोई उपयोगकर्ता ऑब्जेक्ट या डेटा नहीं बनाया जा सकता है।

SQL सर्वर को या तो SP या CU के नए संस्करण में तेजी से अपग्रेड करने के लिए SQL सर्वर 2005 से शुरू होने वाले संसाधन सिस्टम डेटाबेस को पेश किया गया था। उस विकल्प को शुरू करने से पहले, ऐसे सभी अपग्रेड और अपडेट का मतलब था कि परिवर्तन सभी डेटाबेस में लागू होंगे, जिससे अपग्रेड प्रक्रिया अधिक जटिल और समय लेने वाली हो जाएगी। अब, कोई भी SQL सर्वर संस्करण अपग्रेड या SP या CU अपडेट केवल संसाधन डेटाबेस को अपग्रेड या प्रतिस्थापित करता है।

चूंकि संसाधन डेटाबेस केवल-पढ़ने के लिए है और उपयोगकर्ताओं के लिए दृश्यमान नहीं है, इसमें किसी उपयोगकर्ता के हस्तक्षेप की आवश्यकता नहीं है। यदि आप अपनी उच्च उपलब्धता या आपदा पुनर्प्राप्ति योजना में बैक अप संसाधन डेटाबेस को शामिल करना चाहते हैं, तो बस SQL ​​सर्वर सेवाओं को रोकने के बाद mssqlsystemresource.mdf और mssqlsystemresource.ldf फ़ाइलों का फ़ाइल बैकअप बनाएं (SQL सर्वर सेवा फ़ाइलों की प्रतिलिपि बनाने की अनुमति नहीं देगी जबकि SQL सर्वर सेवा चालू है और चल रही है) और इसे किसी सुरक्षित स्थान पर सहेजें। SP या CU स्तरों के भिन्न संस्करण के साथ चलने वाले SQL सर्वर के किसी भी उदाहरण पर इसे अद्यतन न करने का दोहरा ध्यान रखें, क्योंकि इससे अनपेक्षित समस्याएँ हो सकती हैं।

SQL सर्वर में वितरण डेटाबेस

वितरण प्रणाली डेटाबेस प्रतिकृति का दिल है। उपयोगकर्ता या तो वितरण विज़ार्ड कॉन्फ़िगर करें या प्रकाशन विज़ार्ड बनाएं की सहायता से प्रतिकृति सेटअप के भाग के रूप में वितरण डेटाबेस बना या कॉन्फ़िगर कर सकते हैं। हमने SQL सर्वर ट्रांजेक्शनल प्रतिकृति आंतरिक के बारे में मेरे पिछले लेख के हिस्से के रूप में वितरण डेटाबेस निर्माण चरणों का विस्तार से वर्णन किया है।

वितरण डेटाबेस के लिए अनुशंसित अभ्यास

चूंकि वितरण डेटाबेस प्रतिकृति कार्यक्षमता के लिए आवश्यक है, इसलिए हमें निम्नलिखित अभ्यासों को लागू करना चाहिए:

• वितरण डेटाबेस डेटा और लॉग फ़ाइलों को वितरण प्रदर्शन समस्याओं से बचने के लिए अच्छे IOPS के साथ ड्राइव पर ले जाएँ।

• डिस्ट्रीब्यूशन डेटाबेस के प्रारंभिक फ़ाइल आकार और ऑटोग्रोथ गुणों को बेहतर मूल्य पर कॉन्फ़िगर करें ताकि विखंडन की समस्याओं से बचा जा सके।

• डेटाबेस में वितरण डेटाबेस को पूर्ण बैकअप रखरखाव कार्य शामिल करें।

• विखंडन और प्रदर्शन के मुद्दों से बचने के लिए वितरण डेटाबेस को इंडेक्स रखरखाव कार्यों में शामिल करें।

SQL सर्वर ट्रांजेक्शनल प्रतिकृति इंटर्नल के बारे में मेरे लेख में, आपको अन्य कुशल प्रथाओं के बारे में सिफारिशें भी मिलेंगी।

निष्कर्ष

एक और सशक्त लेख पढ़ने के लिए धन्यवाद!

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