Microsoft SQL सर्वर के बैकअप के बारे में पूछने के लिए आप सभी शर्मिंदा थे

बैकअप के बारे में प्रस्तुतियाँ देते समय और SQL सर्वर डेटाबेस को पुनर्स्थापित करते समय, दो प्रकार के प्रश्न आमतौर पर पूछे जाते हैं। दर्शकों से प्रस्तुति के दौरान पहले वाले को सही सेट किया जाता है, दूसरे को निजी बातचीत में पहले से ही सेट किया जाता है। ये "निजी" सवाल अक्सर अधिक दिलचस्प होते हैं और मैं सबसे जटिल और दिलचस्प जवाब देने की कोशिश करूंगा, बजाय इसके कि आप कैसे बैकअप बनाएं, या आपको बैकअप क्यों बनाना चाहिए, या यहां तक ​​कि आपको क्यों करना चाहिए, इसके बारे में एक और लेख लिखने के बजाय अपने बैकअप की जांच करें (लेकिन आपको वास्तव में अपने बैकअप की जांच करनी चाहिए)।

क्या मैं SQL सर्वर के एक संस्करण पर बैकअप को उस पर लागू करने के अलावा किसी अन्य पर लागू कर सकता हूं? क्या समस्याएं पैदा हो सकती हैं?

आप SQL सर्वर के किसी भिन्न संस्करण के लिए बैकअप को पुनर्स्थापित कर सकते हैं, लेकिन केवल अगर SQL सर्वर का बैकअप जिस पर आप तैनात करते हैं, उस संस्करण से नया है, जिस पर आपने इसे बनाया था। दूसरे शब्दों में, आप SQL Server 2000 से SQL सर्वर 2005, SQL Server 2005 से SQL Server 2008 R2, या SQL सर्वर 2008 से SQL सर्वर 2012 में बैकअप को तैनात कर सकते हैं, लेकिन आप इसके विपरीत दिशा में कभी नहीं कर सकते। SQL सर्वर का प्रत्येक संस्करण डेटाबेस और फ़ाइलों को संग्रहीत करने के लिए अपने स्वयं के परिवर्तन करता है। Microsoft इन परिवर्तनों का समर्थन करने के लिए SQL सर्वर के पिछले संस्करणों को "समय में वापस नहीं" जाएगा और फिर से लिखेगा। यदि आपको वास्तव में SQL सर्वर के पुराने संस्करण में अपग्रेड करने की आवश्यकता है, तो आपको स्कीमा और डेटा को स्वयं स्क्रिप्ट करने की आवश्यकता होगी (उदाहरण के लिए, इस संक्रमण के बारे में एक लेख )

SQL सर्वर का बैकअप किस संस्करण में बनाया गया था, यह निर्धारित करने के लिए, आपको बैकअप फ़ाइल के शीर्षलेख को देखने की आवश्यकता है:

RESTORE HEADERONLY FROM DISK = 'd:\bu\mm.bak'; 

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



SQL सर्वर के नए संस्करण के लिए डेटाबेस को पुनर्स्थापित करते समय, यह हो सकता है कि SQL सर्वर के इस संस्करण के साथ कुछ असंगत है। SQL सर्वर के नए संस्करण में अपग्रेड करने के लिए सबसे सुरक्षित तरीका Microsoft Upgrad सलाहकार (SQL सर्वर के प्रत्येक संस्करण के लिए एक मुफ्त उपयोगिता उपलब्ध है) को उस आधार पर लॉन्च करना है जिसे आप स्थानांतरित करना चाहते हैं, यह सुनिश्चित करें कि यह तैयार है, और फिर बैकअप लें और इसे एक नए इंस्टेंस पर पुनर्स्थापित करें (लेकिन केवल इस क्रम में, और पहले बैकअप को स्थानांतरित करने का प्रयास न करें, और फिर सहायक शुरू करें)।

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

 ALTER DATABASE MyDB SET COMPATIBILITY_LEVEL = 110; 

विभिन्न संख्याएँ SQL सर्वर के विभिन्न संस्करणों को दर्शाती हैं: SQL Server 2005 के लिए 90, SQL सर्वर 2008 और 2008 R2 के लिए 100 और SQL सर्वर 2012 के लिए 110 ( SQL सर्वर संस्करणों के बारे में अधिक जानकारी के लिए , यहाँ देखें - अनुवादक का नोट )।

यह जोड़ने योग्य है कि सभी "संक्रमण" संभव नहीं हैं। SQL सर्वर आपको केवल दो संस्करणों पर "आगे कूदने" की अनुमति देगा। उदाहरण के लिए, आप SQL Server 2000 द्वारा SQL सर्वर 2012 में बनाया गया बैकअप लागू नहीं कर सकते। सबसे पहले, आपको इसे SQL Server 2008 में परिनियोजित करना होगा, उपयुक्त संगतता स्तर स्थापित करना होगा, एक नया बैकअप बनाना होगा, और फिर इसे SQL सर्वर 2012 में परिनियोजित करना होगा।

क्या मैं डेटाबेस की प्रतिलिपि बनाने के लिए पुनर्स्थापना कार्रवाई का उपयोग कर सकता हूं? क्या गलत हो सकता है?

हाँ आप कर सकते हैं। यदि आप किसी अन्य सर्वर पर बैकअप तैनात कर रहे हैं, तो आपको यह सुनिश्चित करने की आवश्यकता है कि नए सर्वर पर आपके पास "पुराने" सर्वर के समान तार्किक ड्राइव हैं, या मैन्युअल रूप से MOVE विकल्प का उपयोग करके डेटाबेस फ़ाइलों के लिए सही पथ पंजीकृत करें पुनर्वसन DATABASE:

 RESTORE DATABASE NewDBName FROM DISK = 'c:\bu\mm.bak' WITH MOVE 'OldDB' TO 'c:\data\new_mm.mdf', MOVE 'OldDB_Log' TO 'c:\data\new_mm_log.ldf'; 

डेटाबेस फ़ाइलों में तार्किक नाम और भौतिक फ़ाइल नाम दोनों होते हैं। आपको बस सभी तार्किक फ़ाइल नामों को पंजीकृत करने और उनमें से प्रत्येक के लिए एक नया भौतिक स्थान निर्धारित करने की आवश्यकता है।

आपके द्वारा सामना की जा सकने वाली मुख्य समस्याएं डिस्क पर खाली स्थान की कमी से संबंधित त्रुटियां हैं, जिनसे आप डेटाबेस को पुनर्स्थापित कर रहे हैं, या आप डेटाबेस के लिए एक नया नाम निर्दिष्ट करना भूल सकते हैं और SQL सर्वर मौजूदा डेटाबेस के शीर्ष पर डेटाबेस को पुनर्स्थापित करने का प्रयास करेगा।

जब आप एक नए सर्वर पर एक डेटाबेस को पुनर्स्थापित करते हैं, तो आप "अनाथ उपयोगकर्ता" समस्या का सामना कर सकते हैं ( जो उपयोगकर्ता एमएसडीएन में लगभग अनुवाद के अनुसार खाते से संपर्क खो चुके हैं। अनुवादक ), यदि डेटाबेस उपयोगकर्ता नए सर्वर पर प्रतिनिधित्व नहीं किए गए खाते से जुड़ा है। । आपको इस त्रुटि को ठीक करने की आवश्यकता होगी।

यदि मेरे पास लेनदेन लॉग फ़ाइल नहीं है, तो क्या मैं एक एमडीएफ फ़ाइल को डेटाबेस के रूप में संलग्न कर सकता हूं?

यह स्वीकार्य होने पर एकमात्र विकल्प यह है कि क्या डेटाबेस कार्रवाई सही ढंग से पूरा होने के बाद लेनदेन लॉग खो गया था। किसी भी मामले में, यह एक अच्छा विचार नहीं है। डेटाबेस संलग्न करते समय , डेटाबेस रिकवरी फ़ाइल, साथ ही डेटा फ़ाइल, डेटाबेस पुनर्प्राप्ति प्रक्रिया के संचालन के लिए आवश्यक है ( यहाँ, डेटाबेस पुनर्प्राप्ति को RESTORE DATABASE संचालन के रूप में नहीं समझा जाता है, लेकिन पुनर्प्राप्ति एक प्रक्रिया है जो SQL सर्वर प्रारंभ होने पर, SQL सर्वर "से होकर गुजरती है" »लेन-देन लॉग के अनुसार और डेटा फ़ाइलों को एक सुसंगत स्थिति में लाता है - लगभग। अनुवादक )। हालाँकि, कुछ मामलों में लेन-देन लॉग फ़ाइल के बिना डेटा फ़ाइल को संलग्न करना संभव है, लेकिन यह सुविधा केवल उन मामलों के लिए है जब हार्डवेयर समस्याओं के कारण और बैकअप की अनुपस्थिति में लेन-देन लॉग फ़ाइल क्षतिग्रस्त या खो गई थी। बेशक, एक लेन-देन लॉग के बिना एक डेटाबेस मौजूद नहीं हो सकता है, और जब आप एक लेन-देन लॉग फ़ाइल के बिना एक डेटाबेस संलग्न करते हैं, तो SQL सर्वर बस इसे पुनः बनाएगा।

लेन-देन लॉग फ़ाइल के बिना डेटा फ़ाइल संलग्न करना लॉग की श्रृंखला को नष्ट कर देता है और, इसके अलावा, यह पता चला सकता है कि डेटाबेस में लेन-देन या संरचनात्मक अखंडता का उल्लंघन किया जाता है (लेन-देन लॉग के "नुकसान" के समय डेटाबेस की स्थिति के आधार पर)। इस तरह के डेटाबेस को संलग्न करने की कार्रवाई विफल हो सकती है, भले ही इस तरह की कार्रवाई की जाए।

डिटैच ऑपरेशन पूरा होने के बाद, या SQL सर्वर प्रक्रिया सही ढंग से पूरा हो जाने के बाद ही, डेटा फ़ाइलों और ट्रांजेक्शन लॉग फ़ाइलों को कॉपी करने की अनुमति है, इससे यह सुनिश्चित होगा कि सभी लेनदेन सही तरीके से पूरे हो गए हैं। किसी अन्य सर्वर के लिए डेटाबेस फ़ाइलों को कॉपी / मूविंग करना एक बैकअप बनाने / तैनात करने की तुलना में डेटाबेस को किसी अन्य सर्वर में स्थानांतरित करने का एक तेज़ तरीका है, लेकिन यह इतना सुरक्षित नहीं है (यदि आप प्रतिलिपि बनाए बिना डेटाबेस फ़ाइलों को सीधे स्थानांतरित करते हैं)। इसके अलावा, आपको यह याद रखने की आवश्यकता है कि आप केवल SQL सर्वर के समान या नए संस्करण पर डेटाबेस में शामिल हो सकते हैं।

मेरा डीबी SAN पर है। मैंने सुना है कि SAN बैकअप पर्याप्त हैं। क्या यह सच है?

यह सच हो सकता है। मुख्य बात यह है कि आपका SAN ( संग्रहण, नेटवर्क / डेटा संग्रहण प्रणाली - लगभग। अनुवादक ) SQL सर्वर लेनदेन का समर्थन करता है। यदि ऐसा है, तो उसे पता चलेगा कि डेटाबेस में लेनदेन हैं और इन लेनदेन की उपस्थिति का मतलब यह हो सकता है कि डेटा फ़ाइलों में डेटा पूर्ण नहीं हो सकता है, क्योंकि इन लेन-देन में परिवर्तित डेटा को लिखने की प्रक्रिया हार्ड डिस्क में हो सकती है बैकअप के समय पूरा नहीं हुआ। SQL सर्वर स्वयं उन बैकअप को स्वाभाविक रूप से इन बिंदुओं को ध्यान में रखते हैं।

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

आमतौर पर, बैकअप बनाते समय, SQL सर्वर-सक्षम SAN SQL सर्वर VDI इंटरफ़ेस का उपयोग करता है और बैकअप की अवधि के लिए डेटाबेस को जमा देता है। यदि आप इस तरह के बैकअप को बनाने के लिए तंत्र चलाते हैं और SQL सर्वर त्रुटि लॉग को देखते हैं, तो आपको संदेश दिखाई देंगे कि IO ऑपरेशंस जमे हुए हैं।

यदि आप SAN द्वारा बनाए गए बैकअप पर भरोसा करते हैं, तो आपको अभी भी डेटाबेस की अखंडता की जाँच करने की आवश्यकता है या तो जीवित डेटाबेस पर या सैन बैकअप से बहाल प्रतियों पर। अन्यथा, आप लंबे समय के लिए क्षतिग्रस्त डेटाबेस का बैकअप बना सकते हैं और इसके बारे में भी नहीं जानते हैं।

मैं Windows द्वारा बैकअप के रूप में बनाई गई डेटा फ़ाइलों की प्रतियों का उपयोग क्यों नहीं कर सकता हूं? मुझे समय पर एक मनमाना बिंदु पर पुनर्प्राप्त करने की क्षमता की आवश्यकता नहीं है।

SQL सर्वर एक नियमित डेस्कटॉप अनुप्रयोग नहीं है। वह अपनी फाइलों को इस तरह प्रबंधित करता है ताकि यह सुनिश्चित किया जा सके कि सभी ACID संपत्तियाँ पूरी हो चुकी हैं (Atomic, Consistency, Isolated, Durable - थोड़ा और विस्तार - टिप्पणी अनुवादक )। संक्षेप में, लेन-देन के सफल समापन को सुनिश्चित करने के लिए, SQL सर्वर किसी को भी इसकी फ़ाइलों तक पहुँच देने की कोशिश नहीं करता है और उन्हें आवश्यकतानुसार संशोधित करता है।

यदि आप केवल डेटा फ़ाइल की प्रतिलिपि बनाते हैं, तो वर्तमान में चल रहे ताले और लेनदेन को अनदेखा कर सकते हैं, इसका मतलब है कि जब आप बाद में इस फ़ाइल को संलग्न करने का प्रयास करते हैं, तो यह असंगत स्थिति में होगा, जिससे त्रुटियां हो सकती हैं।

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

अंतर्निहित SQL सर्वर इंजन का उपयोग करना अधिक सुरक्षित और आसान है।
बैकअप बनाने के लिए। ऐसा बैकअप आपके डेटाबेस की पूरी प्रतिलिपि होगा, और सभी एसीआईडी ​​संपत्तियों को निष्पादित किया जाएगा।

मेरा एक बहुत छोटा डेटाबेस है। मैं बैकअप बनाने के लिए डिस्क पर प्रत्येक तालिका को "अनलोड" क्यों नहीं कर सकता?

आप SQLCMD जैसी किसी चीज़ का उपयोग कर सकते हैं और टेबल्स को एक साधारण टेक्स्ट फ़ाइल में अपलोड कर सकते हैं, लेकिन फिर, केवल एक कमांड के साथ डेटाबेस को पुनर्स्थापित करने के बजाय, आपको कई कमांड को निष्पादित करना होगा। सबसे पहले, आपको एक खाली डेटाबेस बनाने की आवश्यकता होगी। फिर, आपको फ़ाइल से प्रत्येक तालिका बनाने और लोड करने की आवश्यकता होगी। यदि किसी तालिका में कोई पहचान स्तंभ है, तो आपको इनमें से प्रत्येक तालिका पर SET IDENTITY_INSERT करना होगा। साथ ही, आपको उस आदेश को सावधानीपूर्वक निर्धारित करना होगा जिसमें आप अखंडता सुनिश्चित करने के लिए डेटा को तालिकाओं में लोड करेंगे।

इसके अलावा, ध्यान रखें कि आपके सभी तालिकाओं को अलग-अलग समय पर डिस्क पर अपलोड किया जाता है, इसलिए यदि पुनर्प्राप्ति के दौरान डेटा किसी तरह बदल गया, तो पुनर्प्राप्ति के बाद आपको डेटाबेस को सुसंगत स्थिति में नहीं मिलेगा और आपको मैन्युअल रूप से त्रुटियों की तलाश करनी होगी और उन्हें ठीक करना होगा।

बेशक, आपको ऐसा करने का अधिकार है। दूसरी ओर, आप बस बैकअप DATABASE कमांड निष्पादित कर सकते हैं, और फिर, जब आवश्यक हो, इस बैकअप को पुनर्स्थापित करें।

यदि SQL सर्वर स्वयं ऐसा कर सकता है तो बैकअप उपयोगिताओं के लिए पैसे क्यों दें?

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

SQL सर्वर द्वारा बनाए गए बैकअप स्वयं ठीक काम करते हैं, लेकिन उन्हें स्वचालित करने के लिए आपको और भी अधिक काम करने के लिए बहुत सारे काम करने की आवश्यकता होती है। एक अच्छा तृतीय-पक्ष उपयोगिता स्वचालन प्रक्रिया को बहुत आसान बना देगा। इसके अलावा, इसकी मदद से आप बैकअप से संबंधित अन्य प्रक्रियाओं को स्वचालित कर सकते हैं, जैसे कि लॉग की मिररिंग / डिलीवरी और बैकअप की अखंडता की जांच करना।

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

यदि बैकअप नेटवर्क शेयर पर है, तो क्या कोई इसे पढ़ सकता है?

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

इसके अलावा, बैकअप से आप डेटाबेस स्कीमा या डेटा प्राप्त कर सकते हैं वह भी इसे बहाल किए बिना। यदि आपके पास SQL ​​डेटा तुलना उपयोगिता है, तो यह / निर्यात स्विच के साथ चल रहा है, CSV प्रारूप में बैकअप से सभी डेटा को निकालने में सक्षम होगा, इस बैकअप की तुलना खाली डेटाबेस के साथ और बिना किसी पासवर्ड के पूछे। साथ ही, समान SQL डेटा तुलना आपके लिए एक स्क्रिप्ट बना सकता है जो डेटाबेस स्कीमा बनाता है।

बैकअप में अनधिकृत पहुंच को रोकने के लिए, आपको कुछ चीजें करनी होंगी। सबसे पहले, सुनिश्चित करें कि जिस पर बैकअप संग्रहीत है वह गेंद सीमित लोगों के लिए सुलभ है। दूसरे, आपको केवल उन बैकअप को स्टोर करना चाहिए जिनकी आपको वास्तव में आवश्यकता है। अंत में, यदि आप तृतीय-पक्ष बैकअप उपयोगिताओं (जैसे SQL बैकअप प्रो) का उपयोग करते हैं, तो आप बैकअप को एन्क्रिप्ट कर सकते हैं, इसलिए यदि किसी को फ़ाइल तक सीधे पहुंच मिलती है, तो वे वहां से कुछ भी पढ़ने में सक्षम नहीं होंगे।

तृतीय-पक्ष उपयोगिताओं के बिना, आप इसे पारदर्शी डेटा एन्क्रिप्शन (TDE) का उपयोग करके प्राप्त कर सकते हैं।

सुरक्षा के सर्वोत्तम स्तर को सुनिश्चित करने के लिए, आपको उपरोक्त सभी कार्यों को करने की आवश्यकता है।

क्या कोई बैकअप की सामग्री को बदल सकता है?

बैकअप फ़ाइल की सामग्री को संशोधित करने की क्षमता प्रदान नहीं की गई है। चूँकि बैकअप डेटाबेस की एक प्रति की प्रतिलिपि है (जिस रूप में यह बैकअप के समय मौजूद था), इस डेटाबेस की पुनर्स्थापित प्रतिलिपि बैकअप के समय मूल रूप में ठीक उसी स्थिति में होगी।
जब SQL सर्वर डेटाबेस पुनर्प्राप्ति के दौरान प्रत्येक पृष्ठ को पढ़ता है, तो वह अपने चेकसम की गणना करता है, जो उसकी सामग्री पर निर्भर करता है, और इसकी तुलना उस मूल्य से करता है जो बैकअप बनाए जाने के समय मूल पृष्ठ से पढ़ा गया था (यह समझा जाता है कि आपने बनाते समय CHECUMUM पैरामीटर का उपयोग किया था बैकअप कॉपी)। यदि किसी ने बैकअप फ़ाइल में परिवर्तन किए हैं, तो ये मान मेल नहीं खाएंगे और SQL सर्वर पृष्ठ को दूषित के रूप में चिह्नित करेगा।

क्या कोई ऐसा ध्वज है जिसे सेट करते समय बैकअप बनाते समय, मुझे यकीन है कि मैं हमेशा इससे उबर सकता हूं?

यदि इस ध्वज से आपका मतलब है कि आपकी बैकअप प्रक्रिया में बैकअप बनाने के बाद RESTORE VERIFYONLY संचालन करना शामिल है, तो नहीं, आप यह सुनिश्चित नहीं कर सकते कि आप इस बैकअप से डेटाबेस को पुनर्स्थापित कर सकते हैं। पहले से ही निश्चित रूप से दो चेक का एक सेट कर सकते हैं।

सबसे पहले, वह यह सुनिश्चित करने के लिए बैकअप हेडर की जांच करती है कि इसमें कोई त्रुटि तो नहीं है। यदि शीर्ष लेख क्षतिग्रस्त है, तो आप डेटाबेस को इस बैकअप से पुनर्स्थापित नहीं कर सकते।

 RESTORE VERIFYONLY FROM DISK= '<Backup_location>' 

दूसरी जांच तभी संभव है जब आपने बैकअप प्रक्रिया की शुरूआत CHECKSUM पैरामीटर के साथ की हो। इसका मतलब यह है कि बैकअप प्रक्रिया के दौरान, SQL सर्वर पढ़े गए सभी पेजों के लिए चेकसम की गणना और सत्यापन करता है। यदि वह किसी ऐसे पृष्ठ पर ठोकर खाता है जिसके लिए ये राशि नहीं जुटती हैं, तो बैकअप कार्रवाई विफल हो जाएगी। यदि जाँच सफल हो जाती है, तो चेक के साथ BACKUP गणना की हुई कॉपी की जांच और गणना करेगा।

तदनुसार, पहले से ही जाँच का पुनरावर्तन करने और यह सत्यापित करने के लिए उपयोग किया जा सकता है कि संग्रहण के दौरान बैकअप प्रतिलिपि क्षतिग्रस्त नहीं हुई थी।

 RESTORE VERIFYONLY FROM DISK= '<Backup_location>' WITH CHECKSUM 

दो जगहों पर समस्या पैदा हो सकती है। सबसे पहले, निष्पादन के दौरान हेडर की जाँच करना, निश्चित रूप से कुछ भी जाँच नहीं करता है जो पुनर्प्राप्ति प्रक्रिया को प्रभावित कर सकता है। इसका मतलब यह है कि अधिक महत्वपूर्ण त्रुटियों के बिना पूरा हो सकता है, लेकिन डेटाबेस अभी भी "सत्यापित" प्रतिलिपि से बहाल नहीं किया जा सकता है।

दूसरी बात, CHECKSUM मेमोरी में हुई क्षति का पता नहीं लगा सकता है। यदि मेमोरी में डेटा पेज अपडेट किया गया था और तब डिस्क में लिखे जाने से पहले यह क्षतिग्रस्त हो गया था (और, तदनुसार, बैकअप के लिए), तो चेकसम की गणना में कोई त्रुटि नहीं दिखाई देगी, लेकिन बस पुष्टि करें कि बैकअप के लिए वही लिखा गया था पृष्ठ, जो बैकअप के समय डेटाबेस में निहित था। यानी यदि बैकअप के समय पृष्ठ पहले से ही क्षतिग्रस्त था, तो चेकसम का उपयोग करके त्रुटि नहीं पाई जा सकती है और इस बैकअप से बहाली विफल हो सकती है।

यह सुनिश्चित करने का एकमात्र तरीका है कि आप बैकअप से पुनर्प्राप्त कर सकते हैं और परिणामी डेटाबेस क्षतिग्रस्त नहीं है, इसे पुनर्स्थापित करना है और, अधिमानतः, बहाल प्रतिलिपि पर एक डेटाबेस अखंडता की जांच करें।

क्या बैकअप में डेटा के अलावा कुछ भी शामिल है? क्या कोई इससे पासवर्ड पढ़ सकता है?

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

हालाँकि, स्टैंड-अलोन डेटाबेस में (डेटाबेस निहित - लगभग अनुवादक ), पासवर्ड के साथ USER की अवधारणा है, क्योंकि स्टैंड-अलोन डेटाबेस का विचार सर्वर के साथ इस तरह के डेटाबेस के न्यूनतम कनेक्शन का तात्पर्य है। इस स्थिति में, पासवर्ड बैकअप में होगा, जिससे इसे वहां से प्राप्त करने का प्रयास किया जा सकता है। पासवर्ड स्पष्ट पाठ में संग्रहीत नहीं किए जाते हैं, वे खाते के पासवर्ड की तरह हैशेड (जो मास्टर सिस्टम डेटाबेस में संग्रहीत होते हैं और स्वाभाविक रूप से, इसके बैकअप में आते हैं)।

Microsoft स्वायत्त डेटाबेस हासिल करने के लिए कई सर्वोत्तम अभ्यास प्रदान करता है।

बैकअप इंडेक्स, सांख्यिकी और अन्य चीजों में क्यों आसान है जिन्हें फिर से बनाना आसान है? क्या यह सिर्फ समय की बर्बादी है?

और मेरी राय में, समय की हानि इस तरह से चीजों को अलग करने और केवल एक हिस्से का बैकअप बनाने का प्रयास है। सबसे पहले, यह कैसे करना है? उदाहरण के लिए, क्लस्टर इंडेक्स का बैकअप लिए बिना डेटा बैकअप कैसे करें? यह संभव नहीं है क्योंकि क्लस्टर इंडेक्स का पत्ता स्तर डेटा पेज है। .., , – , . , , , , , . ?

. SQL Server ( , , , , 200 ) . , , , . , , , .

, « », , , , , , , .

, . , . , , , , , , , .

! ! , . ?

, SQL Server . DELETE TRUNCATE . DELETE , . TRUNCATE , , . . , , . , , . , , 6 ( MSDN – . ).

– , SQL Backup Pro, online .

, …?

SQL Server . , , SQL Compare, . GUI, PowerShell:

& 'C:\Program Files (x86)\Red Gate\SQL Compare 8\SQLCompare.exe' /Backup1:C:\MyBackups\MyBackupFile.bak /MakeScripts:"C:\MyScripts\MyBackupScript"

, SQL Virtual Restore. SQL Server , , , . .

अनुवादक से:
, . , - – ( ).
, .