अपने ग्राहक के लिए मैं कभी-कभार अपने लाइव डेटाबेस में काम करता हूं ताकि वे अपने लिए बनाई गई समस्या को ठीक कर सकें, या अपने उत्पाद के कीड़े के खराब डेटा को ठीक कर सकें। यूनिक्स रूट एक्सेस की तरह, यह सिर्फ खतरनाक है। मुझे समय से पहले क्या सबक सीखना चाहिए?
लाइव डेटा पर काम करने में सावधानी बरतने के लिए आप # 1 चीज़ क्या है?
जवाबों:
तीन चीजें मैंने वर्षों में कठिन तरीके से सीखी हैं ...
सबसे पहले, यदि आप लाइव डेटा पर अपडेट या डिलीट कर रहे हैं, तो पहले WHECT क्लॉज के साथ एक सेलेक्ट क्वेरी लिखें, जिसका आप उपयोग कर रहे हैं। सुनिश्चित करें कि यह काम करता है। सुनिश्चित करें कि यह सही है। फिर ज्ञात कार्य के लिए अद्यतन / संक्षिप्त विवरण प्रस्तुत करें।
आप कभी नहीं करना चाहते हैं
DELETE FROM Customers
आपके क्वेरी एनालाइज़र में बैठे हुए आप प्रतीक्षा कर रहे हैं कि आप WHERE क्लॉज़ कैसे लिखें ... गलती से "निष्पादित" हो गया और आपने अपनी ग्राहक तालिका को मार दिया है। उफ़।
इसके अलावा, अपने प्लेटफ़ॉर्म के आधार पर, यह पता करें कि टेबल का क्विक'डाइनहाइट बैकअप कैसे लिया जाए। SQL Server 2005 में,
SELECT *
INTO CustomerBackup200810032034
FROM Customer
ग्राहक की पूरी तालिका से प्रत्येक पंक्ति को एक नई तालिका में कॉपी कर देगा जिसे CustomerBackup200810032034 कहा जाता है, जिसे आप अपने अपडेट करने के बाद हटा सकते हैं और सुनिश्चित कर सकते हैं कि सब कुछ ठीक है। यदि सबसे खराब होता है, तो डिस्क या टेप से पिछली रात के बैकअप को पुनर्स्थापित करने की तुलना में इस तालिका से लापता डेटा को पुनर्स्थापित करना बहुत आसान है।
अंत में, कैस्केड हटाए जाने से सावधान रहें सामान से छुटकारा पाने के लिए जिसे आप हटाने का इरादा नहीं करते थे - कुछ भी संशोधित करने से पहले अपने तालिकाओं के रिश्तों और महत्वपूर्ण बाधाओं की जांच करें।
BEGIN TRANSACTION;
इस तरह आप एक गलती के बाद रोलबैक कर सकते हैं।
पहले एक बैकअप करें: यह वैसे भी sysadmining का नंबर 1 कानून होना चाहिए
संपादित करें : दूसरों ने जो कुछ भी कहा है उसे शामिल करते हुए, सुनिश्चित करें कि आपके अपडेट में उचित क्लॉज़ हैं।
आदर्श रूप से, एक जीवित डेटाबेस बदलना कभी भी नहीं होना चाहिए (INSERTs और बुनियादी रखरखाव से परे)। लाइव डीबी की संरचना को बदलना विशेष रूप से संभावित बुरे कर्म से भरा हुआ है।
एक कॉपी में अपने बदलाव करें, और जब आप संतुष्ट हों, तब लाइव पर फिक्स लागू करें।
अक्सर मैं एक अद्यतन या DELETE करने से पहले, मैं बराबर चयन लिखता हूं।
जब तक आप BEGIN TRAN t1 में नहीं होते हैं, तब तक कोई अपडेट न करें - एक देव डेटाबेस में, उत्पादन में नहीं, कहीं भी नहीं। हमेशा एक टिप्पणी के बाहर एक कमाना टी 1 चलाएं - हमेशा टाइप करें
--COMMIT TRAN t1
और फिर इसे चलाने के लिए कथन का चयन करें। (जाहिर है, यह केवल GUI क्वेरी क्लाइंट पर लागू होता है।) यदि आप इन चीजों को करते हैं, तो यह उन्हें करने के लिए दूसरा स्वभाव बन जाएगा और आप किसी भी समय शायद ही खो देंगे।
मेरे पास वास्तव में "अपडेट" मैक्रो है जो इस प्रकार का है। मैं हमेशा अपने अपडेट सेट करने के लिए इसे पेस्ट करता हूं। आप डिलीट और इन्सर्ट के लिए एक समान बना सकते हैं।
begin tran t1
update
set
where
rollback tran t1
--commit tran t1
हमेशा सुनिश्चित करें कि आपके UPDATE और DELETE में उचित WHERE क्लॉज़ हो।
मेरे अपने प्रश्न का उत्तर देने के लिए:
अपडेट स्टेटमेंट लिखते समय, इसे क्रम से लिखें।
UPDATE [table-name]WHERE [conditions]SET [columns-and-values]उन पंक्तियों को चुनना जिन्हें आप अपडेट करना चाहते हैं, यह कहने से पहले कि आप किन मूल्यों को बदलना चाहते हैं, दूसरे क्रम में करने से ज्यादा सुरक्षित है। यह update person set email = 'bob@bob.com'आपकी क्वेरी विंडो में बैठे होने के लिए असंभव बनाता है , गलत तरीके से कीस्ट्रोके द्वारा चलाने के लिए तैयार है, तालिका में हर पंक्ति को गड़बड़ करने के लिए तैयार है।
संपादित करें: जैसा कि दूसरों ने कहा है, लिखने से WHEREपहले अपने हटाए जाने के लिए खंड लिखें DELETE।
एक उदाहरण के रूप में, मैं इस तरह SQL बनाता हूं
--Update P Set
--Select ID, Name as OldName,
Name='Jones'
From Person P
Where ID = 1000
मैं टेक्स्ट को अंत से चुनकर हाइलाइट करता हूं और उस एसक्यूएल को चलाता हूं। एक बार जब मैं यह सत्यापित कर लेता हूं कि यह उस रिकॉर्ड को खींच रहा है जिसे मैं अपडेट करना चाहता हूं, तो मैंने अपडेट स्टेटमेंट को हाईलाइट करने के लिए शिफ्ट-अप मारा और उसे चलाया।
ध्यान दें कि मैंने एक उपनाम का उपयोग किया है। मैं कभी भी तालिका नाम की खोज को अद्यतन नहीं करता। मैं हमेशा एक उपनाम का उपयोग करता हूं।
यदि मैं लेन-देन और रोलबैक / कमिट्स के साथ मिलकर ऐसा करता हूं, तो मैं वास्तव में, वास्तव में सुरक्षित हूं।
लाइव डेटाबेस से सावधान रहने के लिए मेरा # 1 तरीका? इसे मत छुओ। :)
बैकअप नुकसान को नष्ट कर सकता है जिसे आप डेटाबेस में डालते हैं, लेकिन आप उस समय के दौरान नकारात्मक दुष्प्रभावों को पेश करने की संभावना रखते हैं।
कोई फर्क नहीं पड़ता कि आप जो स्क्रिप्ट के साथ काम कर रहे हैं वह कितना ठोस है, इसे एक परीक्षण चक्र के माध्यम से चलाएं। यहां तक कि अगर एक "परीक्षण चक्र" का अर्थ है डेटाबेस के अपने उदाहरण के खिलाफ स्क्रिप्ट को चलाना, सुनिश्चित करें कि आप इसे करते हैं। उत्पादन परिवेश की तुलना में अपने स्थानीय बॉक्स पर दोषों को लागू करना बेहतर है।
कुछ अन्य चीजें जो मुझे मददगार लगी हैं:
यदि MySQL का उपयोग कर रहे हैं, तो सुरक्षित अपडेट सक्षम करें
यदि आपके पास एक डीबीए है, तो उन्हें ऐसा करने के लिए कहें।
मैंने पाया है कि इन 3 चीजों ने मुझे कोई गंभीर नुकसान नहीं पहुंचाया है।
खैर, यह अब मैं सोच सकता हूं। साहसिक मार्ग अपनाएं और आप मेरे लिए # 1 देखें। ;-)
यदि आप Oracle या किसी अन्य डेटाबेस का उपयोग कर रहे हैं, जो COMMIT करने से पहले अपने परिवर्तनों को सत्यापित करता है।
डेटा को हमेशा स्क्रिप्ट के माध्यम से लाइव करने के लिए तैनात किया जाना चाहिए, जिसे कई बार रिहर्सल किया जा सकता है क्योंकि इसे देव पर अधिकार प्राप्त करने के लिए आवश्यक है। जब देव पर सही ढंग से चलने के लिए स्क्रिप्ट के लिए निर्भर डेटा होता है, तो इसे उचित रूप से चरणबद्ध करें - यदि आप वास्तव में सावधान रहना चाहते हैं तो आप इस कदम से दूर नहीं हो सकते।
बैकअप या शुरू करने से पहले डेटाबेस को डंप करें।
@ वेन ने जो कहा, उस पर जोड़ने के लिए , WHEREकिसी तालिका DELETEया UPDATEविवरण में तालिका नाम से पहले अपना लिखें ।
पर्यावरण के अनुसार अलग-अलग रंग: हमने अपने PL \ SQL डेवलपर (Oracle के लिए IDE) को सेटअप किया है ताकि जब आप उत्पादन DB में लॉगऑन करें तो सभी विंडो चमकीले लाल रंग में हों। कुछ लोग देव और परीक्षण के लिए एक अलग रंग प्रदान करने के लिए भी गए हैं।
सुनिश्चित करें कि आप रिकॉर्ड हटाते समय एक क्लॉज़ निर्दिष्ट करें।
हमेशा यह सुनिश्चित करने के लिए कि यह सही प्रभाव है, विकास डेटा पर चयन से परे किसी भी प्रश्न का परीक्षण करें।
यदि मैं किसी स्क्रिप्ट के साथ डेटाबेस को अपडेट कर रहा हूं, तो मैं हमेशा सुनिश्चित करता हूं कि मैंने अपनी स्क्रिप्ट की शुरुआत में एक ब्रेकपॉइंट या दो लगाए, बस अगर मैं रन से टकराता / दुर्घटना को अंजाम देता।
मैं आपके UPDATE से पहले BEGIN TRAN करने की सिफारिशों को जोड़ूंगा, बस वास्तव में COMMIT करना न भूलें; अगर आप अपने अनकमिज्ड ट्रांजैक्शन को खुला छोड़ देते हैं तो आप उतना ही नुकसान कर सकते हैं। अपडेट के बीच में फोन, सह-कार्यकर्ता, दोपहर के भोजन आदि से विचलित न हों या आप पाएंगे कि जब तक आप कमिट या रोलबैक नहीं करेंगे, तब तक आप सभी को लॉक किया जाएगा।
क्वेरी विश्लेषक में एडहॉक क्वेरीज़ लिखते समय मैं हमेशा किसी भी विनाशकारी प्रश्नों (सम्मिलित करना, अद्यतन करना, हटाना, बदलना) पर टिप्पणी करता हूं। इस तरह, उन्हें चलाने का एकमात्र तरीका है, उन्हें उजागर करना, बिना टिप्पणी किए हुए भाग का चयन करना, और F5 दबाएं।
मुझे यह भी लगता है कि यह एक अच्छा विचार है, जैसा कि पहले ही उल्लेख किया गया है, जहां आपके कथन को पहले लिखने के लिए, एक चयन के साथ, और यह सुनिश्चित करें कि आप सही डेटा को बदल रहे हैं।
केवल पढ़ने वाला उपयोगकर्ता बनाएं (या इसे करने के लिए DBA प्राप्त करें) और केवल DB को देखने के लिए उस उपयोगकर्ता का उपयोग करें। स्कीमा में उचित अनुमतियाँ जोड़ें ताकि आप संग्रहीत प्रक्रियाओं / विचारों / ट्रिगर / आदि की सामग्री देख सकें। लेकिन उन्हें बदलने की क्षमता नहीं है।