SQL सर्वर समुदाय में DBCC श्रिंक कमांड चलाना काफी विवादास्पद मुद्दा है। इस लेख में, हम इस कमांड के बारे में विवरण की समीक्षा करेंगे और इसके उपयोग का एक संक्षिप्त अवलोकन प्रदान करेंगे और आपको इस कमांड को चलाने के जोखिमों के बारे में चेतावनी भी देंगे। डीबीए के रूप में, कई डेटाबेस अन्य टीमों या विक्रेताओं से सौंपे गए थे, और यह हमेशा हमारे द्वारा बनाए गए डेटाबेस को प्रबंधित करने के लिए नहीं होता है। डीबीए के रूप में, जब भी हम प्रवासन या नई परियोजनाओं में शामिल होते हैं, तो हमें यह सुनिश्चित करने की आवश्यकता होती है कि हम उत्पादन और नियमित उपयोग के लिए डेटाबेस के सुचारू संक्रमण की सावधानीपूर्वक योजना बनाते हैं। यह इस स्तर पर है कि हमें डेटाबेस के आकार को ध्यान में रखना होगा। क्या आप कल्पना कर सकते हैं कि आपने पहले वर्ष के विकास के पूर्वानुमान पर विचार किए बिना एक डेटाबेस एप्लिकेशन सेट किया है। आप इतने छोटे आकार के साथ एक SQL सर्वर डेटाबेस कैसे बना सकते हैं कि इसे हर दूसरे दिन बढ़ने की जरूरत है, रात के मध्य में क्षमता डिस्क अलर्ट बढ़ाना? यह मूर्खतापूर्ण लग सकता है, लेकिन वास्तव में ऐसा होता है, और यह कभी-कभी आपके नियंत्रण में नहीं हो सकता है।
प्रोएक्टिव डीबीए पर विचार करने के लिए कुछ बिंदु
उत्पादन डेटाबेस का समर्थन लेने से पहले, अपने पूर्ववर्ती से जांचना सुनिश्चित करें कि डेटाबेस वृद्धि के संदर्भ में पूर्वानुमान क्या हैं। क्या डेटाबेस का प्रारंभिक आकार आप पर्याप्त रूप से आकार का प्रबंधन करेंगे? यदि डेटाबेस का वर्तमान आकार वर्तमान में मौजूद डेटा से बहुत बड़ा है तो बहुत अधिक चिंता न करें। याद रखें, आप उन डिस्क क्षमता कॉल को सुबह 3:00 बजे नहीं चाहते हैं, जब आप एक सही आकार का डेटाबेस होने से इसे पूरी तरह से टाल सकते थे। पूरे उद्योग में डेटाबेस प्रशासकों के लिए यह एक सामान्य प्रवृत्ति है कि वे सांसारिक मुद्दों पर देर रात तक अपने जीवन का बलिदान करते हैं, जो पहले स्थान पर नहीं होना चाहिए था। साथ ही डेटाबेस साइज के साथ सर्वर की डिस्क क्षमता का भी ध्यान रखें। आप नहीं चाहते कि डिस्क का आकार डेटाबेस की तुलना में बहुत छोटा हो। ये सभी साधारण चीजें हैं जो योजना बनाते समय काम आती हैं। हालाँकि, जैसा कि आप जानते हैं, यह हमेशा एक डेटाबेस पेशेवर नहीं होता है जो पहले स्थान पर डेटाबेस को स्थापित या कॉन्फ़िगर कर रहा होता है। ध्यान देने योग्य महत्वपूर्ण बिंदु आकार के संदर्भ में अपने डेटाबेस के साथ मूल बातें प्राप्त करना है और आपको इस आदेश को कभी भी चलाने की आवश्यकता नहीं हो सकती है। हालांकि, हमेशा की तरह, एक डीबीए के रूप में, ऐसे समय होते हैं जब चीजें आपके नियंत्रण में नहीं होती हैं और इस दौरान आप कुशल उपयोग के लिए डीबीसीसी श्रिंक फाइल कमांड का उपयोग कर सकते हैं।
मैं DBCC ShrinkFile का उपयोग कब कर सकता हूं?
आपको अपनी नींद के ठीक बीच में एक डिस्क स्थान अलर्ट प्राप्त हुआ है और आपको सख्त SLA मिलने हैं। प्राथमिकता स्तर P2 है और SLA बहुत जल्द भंग हो सकता है। और आप महसूस करते हैं कि डिस्क का विस्तार जल्द ही किसी भी समय नहीं होने वाला है, ठीक है, उस स्थिति में, अपने डीबीसीसी श्रिंकफाइल कमांड को संभाल कर रखें ताकि आप अंतरिक्ष को पुनः प्राप्त करने के लिए उनका उपयोग कर सकें। जैसा कि नाम से पता चलता है, यह डेटाबेस के डेटा या लॉग फ़ाइल की फ़ाइल को सिकोड़ता है। लेकिन इससे पहले कि आप DBCC ShrinkFile कमांड चलाना शुरू करें, यह जांचने की कोशिश करें कि डेटाबेस फ़ाइल पहले स्थान पर क्यों बढ़ रही है।
- क्या कुछ लंबे समय तक चलने वाले लेन-देन के कारण फ़ाइल बढ़ी?
- क्या सर्वर पर किसी प्रकार का अवरोध है?
- क्या कोई बड़ी एप्लिकेशन रिलीज हो रही है जिसके बारे में आपको सूचित नहीं किया गया है? (ऐसा ज्यादातर समय होता है)
- क्या डेटाबेस की वृद्धि के कारण किसी प्रकार की डेटाबेस प्रतिकृति या मिररिंग समस्या है?
इन सवालों के जवाब जल्द से जल्द पाना जरूरी है। आम तौर पर इन सभी सवालों का एक ही जवाब होता है और यह एक बेहतरीन फ्री टूल है जिसे sp_whoisactive कहा जाता है। इस उपकरण के विशाल उपयोग का वर्णन करने के लिए कोई शब्द नहीं हैं और मैंने कई अवसरों पर उत्पादन से संबंधित कई मुद्दों को ठीक करने के लिए इसका इस्तेमाल किया है। आप इस लिंक से नवीनतम कोड डाउनलोड कर सकते हैं:http://whoisactive.com/। इसका उपयोग करना आसान और सरल है और कुछ ही समय में आउटपुट लौटाता है। यदि आप अनुभवी डीबीए हैं, तो आपके पास यह पहले से ही आपके पास होगा।
DBCC श्रिंकफाइल उदाहरणों के साथ
DBCC ShrinkFile का सिंटैक्स सरल और सीधा है, नीचे दिए गए इस उदाहरण को देखें।
YORDATABASEgoDBCC श्रिंकफाइल (फ़ाइलनाम,1024) का उपयोग करें
उपरोक्त उदाहरण आपके डेटाबेस से संबंधित फ़ाइल नाम को 1024 एमबी तक कम कर देता है। आप SQL सर्वर प्रबंधन स्टूडियो (SSMS) का उपयोग करके एक ही ऑपरेशन कर सकते हैं। डेटाबेस पर राइट-क्लिक करें, कार्य पर जाएं , सिकोड़ें . चुनें , और फिर फ़ाइलें ।
एक बार जब आप फ़ाइलें . क्लिक करते हैं , आपको यह विंडो मिलेगी।
यहां, आपके पास फ़ाइल प्रकार का चयन करने का विकल्प है:डेटा, लॉग या फाइलस्ट्रीम डेटा और आवश्यकतानुसार "सिकोड़ें क्रिया" करें। सिकुड़ते उद्देश्यों के लिए स्वयं DBCC कमांड का उपयोग करना आसान है।
अतिरिक्त विकल्पों के साथ DBCC ShrinkFile का उपयोग करना
आप अतिरिक्त विकल्पों के साथ डीबीसीसी श्रिंकफाइल कमांड चला सकते हैं - खालीफाइल, नॉटरनकेट या ट्रंकट।
खाली फ़ाइल
आप नीचे की तरह खाली फ़ाइल कमांड का उपयोग कर सकते हैं।
YourDATABASEgodbcc श्रिंकफाइल (फाइलनाम,खाली फाइल) का उपयोग करें
यह डेटा को उसी फ़ाइल समूह के भीतर अन्य फ़ाइलों में स्थानांतरित करने में मदद करेगा। एक बार हो जाने के बाद, यदि आवश्यक नहीं है तो आप डेटाबेस फ़ाइल को हटाने में सक्षम होंगे। हालाँकि, इस खाली फ़ाइल विकल्प के साथ ध्यान देने योग्य कुछ बातें हैं क्योंकि आप फ़ाइल आईडी 1 के साथ प्राथमिक डेटा फ़ाइल की सामग्री को खाली करने के लिए बहुत कुछ नहीं कर पाएंगे। फ़ाइल आईडी संख्या प्राप्त करने के लिए, इस स्क्रिप्ट को चलाएँ।पी>
sys.database_files से file_id, name, Physical_name चुनें
यहां, इस उदाहरण में, फ़ाइल नाम "मो" है और फ़ाइल_आईडी 1 है। जब आप फ़ाइल मो को खाली करने का प्रयास करते हैं जिसमें file_id 1 है, तो आपको यह त्रुटि संदेश मिलेगा।
ऐसा इसलिए है क्योंकि मूल फ़ाइल में सिस्टम जानकारी है, जिसे खाली नहीं किया जा सकता है। लेकिन, यदि आप अन्य डेटा फ़ाइल "mo2data" पर समान कमांड का प्रयास करते हैं, तो खाली फ़ाइल कमांड सफल होगी।
छोड़ना
जैसा कि नाम से पता चलता है, ओएस में वापस कोई स्थान जारी नहीं किया गया है। यह फ़ाइल के भीतर एक आंतरिक ऑपरेशन की तरह है जहां डेटाबेस फ़ाइल के समग्र आकार को बदले बिना पृष्ठों को फ़ाइल के भीतर ही पुनर्वितरित किया जाता है। इस वजह से, विखंडन शुरू होने की एक बड़ी संभावना है। नीचे दिया गया उदाहरण देखें।
-- केवल उदाहरण के लिए YourDatabase goDBCC SHRINKFILE का उपयोग करें (फ़ाइल नाम, notruncate); जाओ
केवल छोटा करें
जैसा कि नाम से पता चलता है, फ़ाइल के अंत से मुक्त स्थान OS में वापस जारी किया जाएगा। यह अब तक का सबसे सुरक्षित ऑपरेशन है जिसे आप DBCC ShrinkFile का उपयोग करके चला सकते हैं। नीचे दिया गया उदाहरण देखें।
-- उदाहरण केवल YourDatabase goDBCC SHRINKFILE का उपयोग करें (फ़ाइल नाम, केवल छोटा करें); जाओ
क्या करें जब लेन-देन लॉग पर DBCC ShrinkFile अपेक्षानुसार काम नहीं कर रहा है? समस्या को ठीक करने के लिए यह सुरक्षित तरीका देखें
ऐसे समय होते हैं जब यह आदेश अपेक्षा के अनुरूप काम नहीं कर सकता है। मान लें कि आपके पास ऐसी स्थिति है जहां आप डेटाबेस की लॉग फ़ाइल को कम करने का प्रयास कर रहे हैं और ऐसा लगता है कि यह काम नहीं कर रहा है। नीचे कुछ कदम दिए गए हैं जिनसे आप समझ सकते हैं कि सिकुड़न अपेक्षा के अनुरूप काम क्यों नहीं कर रही है। आप देखेंगे कि सिकुड़ी हुई फ़ाइल सफल के रूप में दिखाई देगी, हालाँकि, लॉग फ़ाइल के आकार में कोई कमी नहीं हुई है। उस स्थिति में, लॉग फ़ाइल के उपयोग के बारे में कुछ चीज़ों की जाँच करने के लिए इस कमांड को चलाएँ।
sys.डेटाबेस सेनाम चुनें,log_reuse_wait_desc,*
स्क्रीनशॉट से, आप देख सकते हैं कि लॉग बैकअप पर log_reuse_wait_desc कॉलम प्रतीक्षा कर रहा है।
यहां, आप देख सकते हैं कि लॉग फ़ाइल को वास्तव में सिकोड़ने से पहले डेटाबेस के लिए लॉग बैकअप को निष्पादित करने की आवश्यकता है। यदि यह उत्पादन डेटाबेस पर है, तो लॉग बैकअप को किसी अन्य ड्राइव पर करने का प्रयास करें जहां स्थान उपलब्ध है। लॉग बैकअप करने के लिए, नीचे दिए गए नमूना आदेश का उपयोग करें।
बैकअप लॉग DBName to डिस्क='C:\Program Files\Microsoft SQL Server\MSSQL15.A1\MSSQL\Backup\DBName.trn' with init,stats,compression
बैकअप कमांड चलाने के बाद, log_reuse_wait_desc कॉलम की स्थिति देखने के लिए नीचे दिए गए कमांड को फिर से चलाएँ।
sys.डेटाबेस सेनाम चुनें,log_reuse_wait_desc,*
स्क्रीनशॉट से, आप देख सकते हैं कि log_reuse_wait_desc कॉलम की स्थिति "कुछ नहीं" में बदल गई है।
यहां, आप देख सकते हैं कि "log_reuse_wait_desc" कॉलम की स्थिति "कुछ नहीं" में बदल गई है। आपके मामले में, यह अभी भी "LOG_BACKUP" के रूप में दिखाई दे सकता है। डेटाबेस के लिए लॉग बैकअप करना जारी रखें जब तक कि स्थिति "कुछ नहीं" में बदल जाती है। लेन-देन लॉग बैकअप करने के बाद भी आपको "LOG_BACKUP" स्थिति दिखाई दे सकती है, इसका कारण यह है कि लेन-देन लॉग बैकअप चलाने के बाद कोई भी वीएलएफ साफ़ नहीं हो सकता है। वीएलएफ का मतलब वर्चुअल लॉग फाइल है और यह ट्रांजेक्शन लॉग की आंतरिक संरचना का हिस्सा है। लेन-देन लॉग फ़ाइलें इन वीएलएफ से बनी होती हैं। आप इस कमांड को चलाकर वीएलएफ के बारे में जानकारी प्राप्त कर सकते हैं।
sys.dm_db_log_info(5) सेचुनें*यहां 5 डेटाबेस_आईडी का प्रतिनिधित्व करता है। आउटपुट का स्क्रीनशॉट दिखाया गया है। लौटाई गई पंक्तियों की संख्या डेटाबेस में वर्चुअल लॉग फ़ाइलों (वीएलएफ) की वास्तविक संख्या का प्रतिनिधित्व करती है। वर्चुअल लॉग फ़ाइल की स्थिति की जाँच करने के लिए आप "vlf_status" कॉलम की जाँच कर सकते हैं। मान 2 का अर्थ है कि यह सक्रिय है। इस आदेश के साथ, आप लेन-देन लॉग फ़ाइल के भीतर आंतरिक झंडों की जांच कर सकते हैं यह समझने के लिए कि लॉग बैकअप करने के बाद भी लेनदेन लॉग मुक्त क्यों नहीं हो रहा है।
पहले, जिस कमांड का उपयोग किया जाता था वह DBCC LOGINFO था जो समान जानकारी प्रदान करता था।
क्या करें जब लेन-देन लॉग पर DBCC ShrinkFile अपेक्षानुसार काम नहीं कर रहा है? कुछ ऐसा जो आप गैर-उत्पादक वातावरण पर कर सकते हैं। हालांकि, उत्पादन परिवेश पर अनुशंसित नहीं है
आपने कई वेबसाइटों पर देखा होगा जो लोग पुनर्प्राप्ति मॉडल को एक साधारण में बदलने की सिफारिश करते हैं और फिर ओएस को स्थान वापस करने के लिए एक सिकुड़ फ़ाइल चलाते हैं। ध्यान रखें कि पुनर्प्राप्ति मॉडल को सरल में बदलने से आपके डेटाबेस की पुनर्प्राप्ति प्रभावित होगी क्योंकि आप किसी विशिष्ट समय पर पुनर्प्राप्त करने में सक्षम नहीं होंगे। यह फिर से आपके व्यवसाय SLA पर निर्भर करता है। आप पुनर्प्राप्ति मॉडल को T-SQL (नीचे) या GUI का उपयोग करके बदल सकते हैं।
डेटाबेस को बदलें DB_NAME ने पुनर्प्राप्ति को सरल सेट कियाGUI का उपयोग करके, पुनर्प्राप्ति मॉडल को दिखाए अनुसार बदलें। डेटाबेस पर राइट-क्लिक करें, "गुण" पर जाएं, "विकल्प" पर क्लिक करें। "विकल्प" के अंतर्गत, "रिकवरी मॉडल" चुनें।
आप देखेंगे कि केवल पुनर्प्राप्ति मॉडल को सरल में बदलने से OS में वापस स्थान नहीं आएगा। फ़ाइल को सिकोड़ने और स्थान को पुनः प्राप्त करने के लिए आपको DBCC ShrinkFile कमांड को स्पष्ट रूप से चलाने की आवश्यकता होगी। नीचे नमूना स्क्रिप्ट देखें। यह आदेश आपके फ़ाइल नाम को 1024 एमबी तक छोटा कर देगा।
YORDATABASEgoDBCC श्रिंकफाइल (फ़ाइलनाम,1024) का उपयोग करेंडेटाबेस को ऑटो सिकोड़ें विकल्प
आप देखेंगे कि डेटाबेस गुणों के भीतर "ऑटो श्रिंक" के रूप में जाना जाने वाला एक विकल्प है। डेटाबेस गुण देखने के लिए बस डेटाबेस पर राइट-क्लिक करें। विकल्प अनुभाग के तहत, आपको यह विकल्प दिखाई देगा जैसा कि दिखाया गया है। मॉडल डेटाबेस सेटिंग से, आप देख सकते हैं कि "ऑटो सिकोड़ें" विकल्प डिफ़ॉल्ट रूप से अक्षम है। इसलिए, जब भी कोई नया डेटाबेस बनाया जाता है, तो यह विकल्प अक्षम अवस्था में भी होता है। ऐसे कुछ मामले हो सकते हैं जहां डेटाबेस पेशेवर अनजाने में इस विकल्प को छोड़ देने के नकारात्मक परिणामों से अवगत हुए बिना इस विकल्प को सक्षम छोड़ सकते हैं।
सर्वर पर डेटाबेस के लिए इस विकल्प की स्थिति की जाँच करने के लिए इस कमांड को चलाएँ।
sys.databases सेनाम चुनें,is_auto_shrink_on,*आप यह आउटपुट देखेंगे।
यदि संयोग से, आप देखते हैं कि यह सक्षम है, तो आप इसे या तो GUI का उपयोग करके अक्षम कर सकते हैं या आप डेटाबेस के विरुद्ध निम्न आदेश चला सकते हैं।
डेटाबेस को अपने_DATABASE में बदलें AUTO_SHRINK बंद करेंअन्य रखरखाव सुझाव
डेटाबेस वृद्धि की समस्या से बचने के लिए इन कुछ अतिरिक्त युक्तियों का संदर्भ लें, जिसके कारण आपको DBCC ShrinkFile कमांड चलाने की आवश्यकता होती है।
- सुनिश्चित करें कि आपके डेटाबेस का पुनर्प्राप्ति मॉडल व्यावसायिक SLA के साथ संरेखित है। यदि आपके व्यवसाय को परीक्षण डेटाबेस के लिए समय-समय पर पुनर्प्राप्ति की आवश्यकता नहीं है, तो बस उन्हें एक साधारण पुनर्प्राप्ति मॉडल में छोड़ दें। मैंने ऐसे कई अवसर देखे हैं जहां नवीनतम पूर्ण बैकअप का उपयोग करके पुनर्प्राप्ति के साथ चीजें ठीक होने पर डेटाबेस का पुनर्प्राप्ति मॉडल पूरा हो गया था
- विशेष रूप से डेटाबेस वृद्धि के साथ, उचित निगरानी सुनिश्चित करें। जब लॉग फ़ाइल का उपयोग 85% तक पहुंच जाए तो आपको सतर्क हो जाना चाहिए। यह आपको अंतरिक्ष की समस्या को हल करने के लिए कुछ समय देगा
- सुनिश्चित करें कि यदि डेटाबेस पूर्ण पुनर्प्राप्ति मॉडल में है तो नियमित लॉग बैकअप बनाए जाते हैं और यदि कोई लॉग बैकअप विफल हो जाता है तो आपको सतर्क रहना चाहिए
- सुनिश्चित करें कि स्थान की कमी के मुद्दों से बचने के लिए डेटाबेस ड्राइव पर पर्याप्त जगह है
- ऐसे डेटाबेस के लिए जिन्हें संग्रहीत किया जा सकता है, कुछ संग्रह रणनीतियां विकसित करें ताकि आप रिपोर्ट बनाने और उस डेटाबेस को केवल पढ़ने के लिए पुराने डेटा को दूसरे डेटाबेस में स्थानांतरित कर सकें। यह आपको डेटाबेस आकार के संदर्भ में अधिक नियंत्रण प्रदान करेगा
- DBCC CheckDB का उपयोग करके अपने डेटाबेस पर नियमित रूप से अखंडता जांच करना सुनिश्चित करें। अधिक जानकारी के लिए, इस लेख को देखें:https://codingsight.com/dbcc-checkdb-overview/
निष्कर्ष
- इस लेख से, आपको DBCC ShrinkFile कमांड का उपयोग करने की अच्छी समझ मिली है
- आपने DBCC ShrinkFile कमांड चलाने के जोखिमों के बारे में सीखा
- आपने उन विभिन्न विकल्पों के बारे में सीखा जो हम DBCC श्रिंकफाइल कमांड का उपयोग करके प्रदान कर सकते हैं
- आपने उन विकल्पों को देखा जिन्हें हम आजमा सकते हैं यदि लेन-देन लॉग DBCC श्रिंकफाइल कमांड का उपयोग करके सिकुड़ नहीं रहा है
- आपने डेटाबेस प्रॉपर्टी में डिफ़ॉल्ट ऑटो सिकोड़ने की सेटिंग के बारे में सीखा
- आपने अपने डेटाबेस को स्वस्थ रखने के लिए अन्य डेटाबेस रखरखाव सुझावों को भी सीखा
- आखिरकार, किसी भी मामले में उन ऑफ दिनों के लिए तैयार रहना सुनिश्चित करें जो आपके नियंत्रण में नहीं हो सकते हैं