इस लेख में, हम डीबीए की गलतियों की समीक्षा करने जा रहे हैं, जिसके परिणाम काफी बोधगम्य थे और जिनसे मुझे निपटना था।
लेख का उद्देश्य उपयोगकर्ताओं को इन गलतियों को दोहराने से रोकना है। कभी-कभी, एक बुरा अनुभव सकारात्मक अनुभव से भी अधिक मूल्यवान होता है।
- डेटाबेस फ़ाइलों का प्रतिशत वृद्धि
चूंकि डेटाबेस की फ़ाइल वृद्धि काफी संसाधन-गहन ऑपरेशन है, ऐसा लग सकता है कि इस वृद्धि को प्रतिशत अनुपात में सेट करना एक अच्छा विचार हो सकता है। मैं मानता हूं कि कई दिशानिर्देश प्रतिशत के बजाय एमबी में एक निश्चित वेतन वृद्धि निर्धारित करने की सलाह देते हैं। हालांकि, वे कारणों की व्याख्या नहीं करते हैं। अभ्यास के आधार पर, 1 जीबी से ऊपर डेटाबेस फ़ाइल की वृद्धि को सेट करने की अनुशंसा नहीं की जाती है, क्योंकि एमएस एसक्यूएल सर्वर एक बार में 2 जीबी के बजाय 1 जीबी 2 बार आवंटित करेगा।
इसके अलावा, यदि आप 32 एमबी से कम आवंटित करते हैं , जल्दी या बाद में डेटाबेस बस धीमा हो जाएगा। इसलिए, डेटाबेस फ़ाइलों पर 32 से 1024 एमबी तक एक निश्चित वेतन वृद्धि सेट करना बेहतर है। हालाँकि, डेटाबेस फ़ाइलों की वृद्धि को प्रतिशत के रूप में निर्दिष्ट करना असंभव क्यों है? यह पता चला है कि जैसे ही फ़ाइल 1 एमबी से कम होती है, डीबीएमएस इस मान को 0 एमबी तक बढ़ा देता है और इस फ़ाइल को बढ़ाना बंद कर देता है। नतीजतन, सिस्टम डाउन है। यह पता लगाने के लिए कि हमें फ़ाइल को कितना बढ़ाने की आवश्यकता है, बस एक दैनिक विश्लेषण करें ताकि यह जांचा जा सके कि एमबी में प्रत्येक फ़ाइल का लाभ कितना है और उपयुक्त संख्या को 32 से 1024 एमबी की सीमा में सेट करें। हम निम्नलिखित तरीके से डेटाबेस फ़ाइलों की वृद्धि पर आंकड़े एकत्र कर सकते हैं। - टेबल के लिए कई विदेशी कुंजियां हैं
क्या आपने कभी ऐसी तालिका से कम से कम एक पंक्ति को हटाते समय योजना की जांच करने का प्रयास किया है जिसे लगभग सैकड़ों अन्य तालिकाओं द्वारा संदर्भित किया गया है? आपको यह जानकर आश्चर्य होगा कि कितने नेस्टेड लूप हैं। ये सभी विदेशी कुंजी चेक हैं। इसलिए, यदि तालिकाएँ बड़ी हैं (दस लाख से अधिक रिकॉर्ड), तो उस तालिका के लिए विदेशी कुंजियों को अक्षम करना बेहतर है जिसमें डेटा हटा दिया जाएगा। फिर, आपको सभी आवश्यक और संबंधित डेटा को हटाना होगा। उसके बाद, विदेशी कुंजी सक्षम करें। ऐसी ही स्थिति कैस्केडिंग अद्यतनों और विलोपनों के साथ होती है। यदि बहुत सारे बाहरी लिंक (सैकड़ों) हैं, तो एक भी पंक्ति को हटाने से एक लंबी और बहुत व्यापक अवरोधन हो सकती है। - अनेक अनावश्यक अनुक्रमणिका
बहुत बार, आप दिशानिर्देशों में देख सकते हैं कि विदेशी कुंजी बनाते समय, अनुक्रमणिका बनाना आवश्यक है, खासकर जब इन चाबियों का उपयोग जुड़ने के लिए किया जाता है। आपको यह जांचना होगा कि इंडेक्स का उपयोग किया गया है, अन्यथा, ये अनावश्यक इंडेक्स केवल किसी भी डेटा संशोधन संचालन को धीमा कर देंगे। इसे जांचने के लिए, निम्न क्वेरी का उपयोग करें:select DB_NAME(t.database_id) as [DBName] , SCHEMA_NAME(obj.schema_id) as [SchemaName] , OBJECT_NAME(t.object_id) as [ObjectName] , obj.Type as [ObjectType] , obj.Type_Desc as [ObjectTypeDesc] , ind.name as [IndexName] , ind.Type as IndexType , ind.Type_Desc as IndexTypeDesc , ind.Is_Unique as IndexIsUnique , ind.is_primary_key as IndexIsPK , ind.is_unique_constraint as IndexIsUniqueConstraint , t.[Database_ID] , t.[Object_ID] , t.[Index_ID] , t.Last_User_Seek , t.Last_User_Scan , t.Last_User_Lookup , t.Last_System_Seek , t.Last_System_Scan , t.Last_System_Lookup from sys.dm_db_index_usage_stats as t inner join sys.objects as obj on t.[object_id]=obj.[object_id] inner join sys.indexes as ind on t.[object_id]=ind.[object_id] and t.index_id=ind.index_id where (last_user_seek is null or last_user_seek <dateadd(year,-1,getdate())) and (last_user_scan is null or last_user_scan <dateadd(year,-1,getdate())) and (last_user_lookup is null or last_user_lookup <dateadd(year,-1,getdate())) and (last_system_seek is null or last_system_seek <dateadd(year,-1,getdate())) and (last_system_scan is null or last_system_scan <dateadd(year,-1,getdate())) and (last_system_lookup is null or last_system_lookup <dateadd(year,-1,getdate())) and t.database_id>4 and t.[object_id]>0 -- system databases are excluded
- संसाधनों का अकुशल उपयोग
विभिन्न भंडारण उपकरणों पर लेनदेन लॉग और डेटाबेस फ़ाइल को संग्रहीत करने की अक्सर अनुशंसा की जाती है। यदि आप 4 या अधिक SSD-डिस्क के साथ RAID 10 का उपयोग करते हैं, तो फ़ाइलों को एक-दूसरे से अलग करने का कोई मतलब नहीं है। उच्च गति के लिए, यदि आवश्यक हो, tempdb डेटाबेस को RAM से विभाजित डिस्क पर संग्रहीत किया जा सकता है। साथ ही, डीबीएमएस को प्रदान की गई बहुत बड़ी मात्रा में रैम बाद में सभी मेमोरी को अप्रासंगिक क्वेरी योजनाओं से भर देगी। - खराब बैकअप
न केवल बनाए गए बैकअप की जांच करना बल्कि उन्हें परीक्षण स्टैंड पर ले जाना और उन्हें पुनर्स्थापित करना हमेशा आवश्यक होता है। यह सब समस्यात्मक और सफल पुनर्प्राप्ति दोनों के व्यवस्थापकों को आगे की अधिसूचना के साथ स्वचालित करने की आवश्यकता है। - खराब असफलता सहनशीलता
दो या दो से अधिक सर्वरों का क्लस्टर बनाने से पहले, आपको यह सुनिश्चित करने की आवश्यकता है कि डेटा स्टोरेज सिस्टम भी विफल सहनशील है। यदि बाद वाला विफल हो जाता है, तो संपूर्ण विफल सहनशीलता शून्य हो जाएगी। - जटिल बिना आसान जांच के निदान
यदि कोई सिस्टम डाउनटाइम है, तो पहले, आपको MS SQL सर्वर लॉग की जाँच करने और फिर गहराई से खुदाई करने की आवश्यकता है। आपको पहले साधारण जांच करनी चाहिए और फिर जटिल निदान के लिए आगे बढ़ना चाहिए। - खोई हुई टेबल
तालिकाओं को अनावश्यक डेटा के साथ बढ़ाया जा सकता है जिसे एक अलग डेटाबेस में संग्रहीत करने या हटाने की आवश्यकता होती है। इसके अलावा, तालिकाओं का अब उपयोग नहीं किया जा सकता है।
ये वे स्थितियां हैं जिनका मैं सामना कर चुका हूं। इसलिए, मैं उपरोक्त गलतियों को न दोहराने की सलाह देना चाहूंगा।
क्या आप डेटाबेस का प्रबंधन करते समय अपने अनुभव या ऐसी गलतियों को साझा करना चाहेंगे, बेझिझक मुझे बताएं - मुझे उन पर चर्चा करने में खुशी होगी।
