एक डीबीए की सात घातक आदतें और उनका इलाज कैसे करें
डेटाबेस प्रशासन में व्यापक बुरी आदतों को “घातक” कहना प्रतीत हो सकता है
चरम। हालाँकि, जब आप अधिकांश डेटा की महत्वपूर्ण प्रकृति पर विचार करते हैं, और कैसे
हानिकारक डेटा हानि या भ्रष्टाचार एक निगम के लिए हो सकता है, “घातक” सुंदर लगता है
बिल्कुल ठीक।
हालांकि ये आदतें डीबीए के बीच चिंताजनक रूप से आम हैं, लेकिन इनका इलाज किया जा सकता है
कुछ चतुर प्रबंधन हस्तक्षेप। नीचे हम सात आदतों की सूची दे रहे हैं
उन्हें खत्म करने के तरीके के बारे में कुछ विचारों के साथ-साथ सबसे घातक पर विचार करें।
आदत # 1।
विश्वास की छलांग: “हमें अपने बैकअप पर विश्वास है।”
अंध विश्वास प्यारा हो सकता है, लेकिन जब डेटाबेस का बैकअप लेने की बात नहीं आती है। बैकअप
उन पर तभी तक भरोसा किया जाना चाहिए जब तक उनका परीक्षण और सत्यापन किया जा चुका हो।
इलाज:
क्या आपके डीबीए सत्यापित करते हैं कि बैकअप नियमित रूप से सफल हो रहा है, अधिमानतः एक का उपयोग करके
स्क्रिप्ट जो कोई समस्या होने पर उन्हें सूचित करती है।
अपने बैकअप के लिए एक बैकअप बनाए रखें। डीबीए को हमेशा कम से कम दो बैकअप का उपयोग करना चाहिए
तरीके। बैकअप के रूप में पुराने जमाने के निर्यात का उपयोग करना एक सामान्य तकनीक है
ऑनलाइन बैकअप के लिए।
जितनी बार व्यावहारिक हो संसाधन परीक्षण पुनर्प्राप्ति। एक प्रारंभिक संकेत है कि आपकी DBA टीम है
या तो अधिक काम किया गया है या सही ढंग से प्राथमिकता नहीं दे रहा है, एक चौथाई के बिना एक चौथाई गुजर रहा है
परीक्षण वसूली। टेस्ट रिकवरी पुष्टि करती है कि आपकी बैकअप रणनीति ट्रैक पर है, जबकि
आपकी टीम को पुनर्प्राप्ति गतिविधियों का अभ्यास करने की अनुमति देना ताकि वे उन्हें प्रभावी ढंग से संभाल सकें
जब समय आएगा।
आदत # 2।
बड़ी उम्मीदें: “यह हमारी उम्मीद के मुताबिक काम करेगा। चलो चलते हैं
आगे।”
हालांकि पारंपरिक अर्थों में उपयोगकर्ता के अनुकूल नहीं है, Oracle बहुत शक्तिशाली उपयोगकर्ता है
दोस्ताना– एक बार जब आप इसके साथ कुछ समय के लिए काम कर रहे होते हैं, तो आप इसके लिए एक वृत्ति विकसित करते हैं
जिस तरह से चीजें “चाहिए” काम करती हैं। हालांकि वह वृत्ति अक्सर सही होती है, सबसे अधिक में से एक
किसी भी डीबीए के पास खतरनाक आदतें हो सकती हैं, यह धारणा है कि ओरेकल “बस काम करेगा”
जिस तरह से यह चाहिए।
इलाज:
पूरे संगठन में एक “अभ्यास, अभ्यास, अभ्यास” मानसिकता पैदा करें। डीबीए
डिज़ाइन किए गए परीक्षण वातावरण के सुरक्षित सैंडबॉक्स में गतिविधियों का पूर्वाभ्यास करने की आवश्यकता है
उत्पादन प्रणाली के व्यवहार की बारीकी से नकल करने के लिए। संस्था को चाहिए
उन्हें ऐसा करने के लिए समय और पैसा दें।
जब भी संभव हो वरिष्ठ लोगों के साथ अनुभवहीन डीबीए की जोड़ी बनाएं- या उन्हें नीचे ले जाएं
आपका अपना पंख। नए डीबीए निडर होते हैं, लेकिन किसी और से सीखते हैं
अनुभव कुछ आवश्यक व्यामोह पैदा करने में मदद कर सकता है।
हर चीज के लिए योजनाओं की समीक्षा करें। यह आश्चर्यजनक है कि डीबीए कितनी बार कहते हैं, “मैंने वह किया है
सौ बार, मुझे किसी योजना की आवश्यकता नहीं है।” यदि वे निष्पादन मोड में जा रहे हैं, तो वे
बिल्कुल योजना की जरूरत है।
आदत #3।
अहस्तक्षेप प्रशासन: “हमें सिस्टम की निगरानी करने की आवश्यकता नहीं है।
जब कुछ गलत होता है तो उपयोगकर्ता हमेशा हमें बताते हैं।”
यदि आप डीबीए टीम को सूचित करने के लिए उपयोगकर्ताओं पर निर्भर हैं कि कोई समस्या है, तो यह हो सकती है
पहले ही बहुत देर हो चुकी है।
इलाज:
उपलब्धता और प्रदर्शन निगरानी प्रणाली स्थापित करें ताकि समस्याओं की पहचान की जा सके
और सेवा-प्रभावित विफलताओं का कारण बनने से पहले उनका समाधान किया जाता है।
डेवलपर और परीक्षकों के साथ काम करके रिलीज़-पश्चात सॉफ़्टवेयर समस्याओं से बचें
सुनिश्चित करें कि सभी उत्पादन-तैयार सॉफ़्टवेयर स्थिर और उच्च-प्रदर्शन वाले हैं।
आदत # 4
। स्मृति परीक्षण: “हम याद रखेंगे कि यह कैसे हुआ, और हमने क्या किया
चीजों को फिर से शुरू करने के लिए।”
यह असंभव प्रतीत हो सकता है कि एक डीबीए टीम एक बड़ी प्रक्रिया को भूल जाएगी
ठीक होने में उन्हें हफ्ता लग जाता है, और फिर भी यह हर समय होता है। रोकने के लिए
आवर्ती गलतियों और प्राप्त अनुभव का लाभ उठाएं, दस्तावेज़ीकरण है
ज़रूरी।
इलाज:
आवश्यकता है कि आपके डीबीए एक व्यापक प्रलेखन पुस्तकालय बनाए रखें और
गतिविधि डायरी, जिसमें तर्काधार, वाक्य-विन्यास और कार्यप्रवाह विवरण का एक महत्वपूर्ण स्तर शामिल है।
अपनी टीम को अपने इंट्रानेट पर ग्रुपवेयर प्रदान करें ताकि ये दस्तावेज़
आपात स्थिति में खोजा जा सकता है।
प्रलेखन के अनुशासन को लागू करें और समय-समय पर इसकी जांच करें। अपने डीबीए से पूछें:
यह टेबलस्पेस कब, किसके द्वारा और किस SQL से बनाया गया था? कौन से कार्य थे
किसी विशेष दिन पर किया जाता है? अगर वे जल्दी से जवाब नहीं दे सकते हैं, तो आपको पता चल जाएगा कि वे जा चुके हैं
स्मृति पर निर्भर को लौटें।
आदत # 5।
दोष का खेल: “मुझे मत देखो, यह डेवलपर की गलती है कि एसक्यूएल है
उत्पादन में”
जब डेवलपर्स की बात आती है तो कुछ डीबीए में वास्तविक “हम बनाम वे” मानसिकता होती है
उनका संगठन। वे खुद को डेवलपर्स की मदद करने वाले सूत्रधार के रूप में नहीं देखते हैं
डेटाबेस के दृष्टिकोण से गुणवत्ता कोड विकसित करें, बल्कि अभिभावकों के रूप में जो
खराब-गुणवत्ता वाले कोड को उत्पादन में लाने से रोकें। ऐसा लग सकता है
शब्दार्थ, लेकिन डेवलपर्स और डीबीए परिणामों के बीच एक टकरावपूर्ण संबंध
डेवलपर पहल की कमी और रिलीज चक्रों में महत्वपूर्ण मंदी के कारण।
इलाज:
डीबीए का चयन करें जो एक एकीकृत टीम के रूप में काम करना अपनी जिम्मेदारी समझते हैं
डेवलपर्स के साथ वे समर्थन करते हैं।
हर परियोजना में निरंतर DBA भागीदारी की संरचना करके एक टीम रवैया विकसित करें
मील के पत्थर की समीक्षा करने के बजाय।
डेवलपर समर्थन भूमिका में एक व्यक्तिगत DBA असाइन करने पर विचार करें। यदि यह स्पष्ट रूप से है
नौकरी का विवरण, इसे अच्छी तरह से करने के लिए और अधिक प्रेरणा है।
आदत # 6।
सोलो एक्ट: “मुझे पता है कि मैं क्या कर रहा हूं और मुझे किसी मदद की ज़रूरत नहीं है।”
डेटाबेस प्रशासन उत्तरोत्तर जटिल होता जा रहा है और यहां तक कि सबसे वरिष्ठ डीबीए भी
संभवतः हर अंतिम विवरण नहीं जान सकता। डीबीए की अलग-अलग खासियतें होती हैं, जिनकी जरूरत होती है
निकाल कर उपयोग में लाया जाए। जब डीबीए को लगता है कि वे सब कुछ जानते हैं, या जानना चाहिए,
वे सवाल नहीं पूछते हैं और मूल्यवान ज्ञान से चूक जाते हैं जिसे वे प्राप्त कर सकते हैं
दूसरों से।
इलाज:
एक टीमवर्क संस्कृति को बढ़ावा देना जहां डीबीए के लिए यह स्वीकार करना स्वीकार्य है कि वे नहीं जानते हैं
उत्तर और मदद माँगना।
अपने डीबीए को एक बाहरी सहकर्मी समूह को एक मंच के रूप में खोजने के लिए प्रोत्साहित करें
बुद्धिशीलता और उनकी धारणाओं का परीक्षण। की बराबरी कोई नहीं कर सकता
एक अपेक्षाकृत छोटे समूह की विशेषज्ञता और अनुभव भी।
संदर्भ सामग्री, पाठ्यक्रम, और जैसे तकनीकी संसाधनों का सुरक्षा जाल प्रदान करें
कॉल पर बाहर के विशेषज्ञ या सलाहकार।
आदत #7।
टेक्नो-लस्ट: “चीजें बहुत बेहतर काम करती अगर केवल हमारे पास …”
डीबीए अक्सर नवीनतम तकनीक के शीर्ष पर होते हैं, जो उन्हें कुछ करने में मदद कर सकता है
अति उत्तम कार्य। लेकिन जब नई तकनीक की इच्छा के कारण डीबीए अनुशंसा करते हैं
अनावश्यक हार्डवेयर खरीद या सॉफ़्टवेयर ऐड-ऑन, लागतें आसमान छूती हैं
जल्दी – समस्याओं के रूप में।
इलाज:
पहले सभी ट्यूनिंग को समाप्त किए बिना कभी भी अपने हार्डवेयर इन्फ्रास्ट्रक्चर को अपग्रेड न करें
अवसर। याद रखें, दस साल पहले सर्वरों पर बड़े उद्यम चलाए जाते थे
क्षमता का दसवां हिस्सा – सभी आवश्यकता और कौशल के लिए धन्यवाद।
उन्नत या नई सुविधाओं का उपयोग करने के लिए कभी सहमति न दें जब तक कि आप इसके बारे में अच्छी तरह से अवगत न हों
चल रहे रखरखाव प्रतिबद्धता और परिणामी लागत।
डीबीए समर्थन सॉफ़्टवेयर के लिए देखें जो कठिन के लिए अनुकूल जीयूआई इंटरफेस प्रस्तुत करता है
कार्यों। इस प्रकार का इंटरफ़ेस एक शुरुआती DBA को मध्यवर्ती DBA के रूप में कार्य करने की अनुमति देता है
कुछ परिस्थितियों में, लेकिन साथ ही साथ उस शुरुआत को रोकता है
कार्यों के पीछे वास्तविक कौशल सीखना। इसके अलावा, ये उपकरण वास्तविक छिपाने की प्रवृत्ति रखते हैं
DBA से जोखिम, संभावित रूप से हानिकारक गतिविधियों को पॉइंट-एंड- जितना आसान बना देता है
क्लिक करें।
चाहे वह बारह-चरणीय कार्यक्रम हो या एक छोटा सा समायोजन, ये सभी घातक हैं
डीबीए की आदतों को लात मारी जा सकती है। बेशक, पहला कदम समस्या को पहचान रहा है। द्वारा
इस सूची के साथ शुरू करना और सफलताओं और असफलताओं की सावधानीपूर्वक सूची बनाना
आपकी टीम का डेटाबेस प्रशासन, आप इलाज खोजने के रास्ते पर होंगे।