ऑनलाइन रहते हुए SQL सर्वर डेटाबेस को एक नई डिस्क पर ले जाना

11

मेरे पास 1.4TB SQL सर्वर डेटाबेस है जो डिस्क I / O के साथ बड़े पैमाने पर संघर्ष कर रहा है। हमने सर्वर में एक नया SSD सरणी स्थापित किया है जो हमारी सभी समस्याओं को हल कर देगा, हम सिर्फ डेटाबेस को स्थानांतरित करने के सर्वोत्तम तरीके पर बहस कर रहे हैं। आदर्श रूप से अगर हम इसे डाउनटाइम के बिना कर सकते हैं, तो यह सबसे अच्छा है। लेकिन जहां चुनाव दो दिनों के खराब प्रदर्शन के बीच होता है (जैसे डेटा कॉपी करते समय) डाउनटाइम के दो घंटे बनाम, बाद वाला बेहतर हो सकता है।

अब तक, हम जिन समाधानों के साथ आए हैं वे हैं:

सरल प्रति। DB ऑफ़लाइन लें, फ़ाइलों को कॉपी करें, SQL सर्वर में स्थानों को बदलें और इसे ऑनलाइन वापस लाएं। किसी भी आंकड़े का अनुमान है कि इसमें पांच घंटे लगेंगे, जो वास्तव में स्वीकार्य नहीं है, लेकिन यह सबसे आसान समाधान है।
ब्लॉक स्तरीय प्रति। Rsync जैसी उपयोगिता का उपयोग करते हुए, हम DB भरते समय पृष्ठभूमि में फ़ाइलों की प्रतिलिपि बनाते हैं। जब हम माइग्रेट करने के लिए तैयार होते हैं, तो हम डीबी को ऑफ़लाइन लेते हैं, इस उपयोगिता का उपयोग करके एक अंतर कॉपी करते हैं, फिर नई फाइलों पर SQL सर्वर को इंगित करते हैं और इसे ऑनलाइन लाते हैं। यहाँ समय अज्ञात है। हम नहीं जानते कि 1.4TB के विभेदक विश्लेषण को करने में कितना समय लगेगा और उस पर प्रतिलिपि बनाई जाएगी। हमारी अन्य चिंता यह है कि ब्लॉक स्तर की प्रतिलिपि SQL सर्वर द्वारा अपठनीय कुछ राज्यों में फ़ाइलों को छोड़ देगी और हम अपना समय बर्बाद करेंगे।
एसक्यूएल प्रवास। नई डिस्क पर एक नई 1.4TB SQL डेटा फ़ाइल बनाएं और अन्य सभी फ़ाइलों पर ऑटोग्रॉथ को अक्षम करें। फिर बारी-बारी से अन्य सभी डेटा फ़ाइलों पर DBBC SHRINKFILE (-file_name-, EMPTYFILE) चलाएं। एक बार डेटा के सभी पार हो जाने के बाद, मैं एसएसडी से अधिक एमडीएफ फ़ाइल को स्थानांतरित करने और अन्य उपयोग की गई फ़ाइलों को हटाने के लिए किसी बिंदु पर एक निर्धारित विंडो ले लूंगा। मुझे यह पसंद है क्योंकि यह डाउनटाइम को कम करता है। लेकिन मुझे नहीं पता कि इसमें कितना समय लगेगा और क्या यह होने पर प्रदर्शन में गिरावट का कारण होगा।

इसका परीक्षण करने के लिए हमारे पास किसी भी तरह का भार और प्रदर्शन का माहौल नहीं है। मैं यह सत्यापित कर सकता हूं कि रणनीति हमारे मंचन के माहौल पर काम करेगी, लेकिन प्रभाव नहीं और प्रदर्शन नहीं।

sql-server ssd

— सीमस
स्रोत

आपके डेटाफ़ाइल्स को LVM विभाजन पर संग्रहीत किया जाता है?

— मार्को

1

don't know how long it will take to do a differential analysis of 1.4TBकम से कम जब तक उस डेटा को पढ़ने में समय लगता है। मुझे नहीं लगता कि rsync विचार कुछ भी बचाता है। rsync को धीमे नेटवर्क के साथ सामना करने के लिए बनाया गया है।

— यूआर

2

EMPTYFILE का उपयोग करने के बजाय, मैं SSD पर निहित एक नए फ़ाइल समूह पर सभी अनुक्रमितों का पुनर्निर्माण करूंगा। इस तरह से अनुक्रमित अच्छे और डीफ़्रेग्मेंटेड दिखाई देते हैं। EMPTYFILE उन्हें खंडित कर सकता है, निश्चित नहीं।

— यूएसआर

14

पूरे डेटाबेस को स्थानांतरित करने का एक तरीका BACKUPऔर है RESTORE। अंतिम स्विच के दौरान डेटाबेस अनुपलब्ध रहेगा लेकिन नियोजन के साथ डाउनटाइम न्यूनतम होना चाहिए। यह प्रक्रिया मानती है FULLया BULK_LOGGEDपुनर्प्राप्ति मॉडल:

1) पूर्ण बैकअप करें (या अपने मौजूदा का उपयोग करें)।

2) नवीनतम पूर्ण बैकअप को एक अलग डेटाबेस के नाम WITH MOVEपर पुनर्स्थापित करें, एसएसडी स्टोरेज पर फ़ाइलों को स्थानांतरित करने के विकल्प को वांछित और NORECOVERYविकल्प के रूप में निर्दिष्ट करें ताकि बाद के अंतर और लॉग बैकअप को बहाल किया जा सके।

3) लेन-देन लॉग बैकअप के साथ अंतिम कट-ओवर के समय तक नए डेटाबेस में वृद्धिशील परिवर्तन लागू करें और RESTORE...WITH NORECOVERY। यह नए डेटाबेस के अंतिम स्विच के लिए डाउनटाइम को कम करेगा।

4) नए डेटाबेस में जाने के लिए, एप्लिकेशन को ऑफलाइन ले जाएं, एक अंतिम लेनदेन लॉग बैकअप करें, और नए डेटाबेस पर लागू करें WITH RECOVERY। अंत में, मूल डेटाबेस को एक अलग नाम पर नाम बदलें और मूल नाम में स्थानांतरित डेटाबेस का नाम बदलें। अपनी सुविधानुसार पुराने डेटाबेस को छोड़ें।

SIMPLE रिकवरी मॉडल में, आप एक समान प्रक्रिया का उपयोग कर सकते हैं, लेकिन चरण 3 के बिना लेन-देन लॉग बैकअप / पुनर्स्थापना। इसके बजाय, अंतिम चरण में एक विभेदक डेटाबेस बैकअप / पुनर्स्थापना का उपयोग करें। प्रारंभिक FULLबैकअप के बाद से परिवर्तनों की मात्रा के आधार पर, अधिक डाउनटाइम की आवश्यकता हो सकती है ।

— डैन गुज़मैन
स्रोत

हाँ, एक ही सर्वर डीबी आंदोलन के लिए सबसे सरल और सबसे तेज़ के रूप में कुछ भी नहीं आता है।

— मैरियन

-6

Good approach is to use SQL REPLICATION between two server
once all data replicated on SSD server then take current server offline 
and switch to SSD server.

— अविनाश मेंडसे
स्रोत

2

आप नीचे उतर रहे हैं क्योंकि आप सवाल का जवाब नहीं दे रहे हैं। चर्चा के तहत स्थिति में केवल एक सर्वर है।

— आकाशवाणी

इसके अलावा dbs को स्थानांतरित करने के लिए एक अच्छा तरीका मिररिंग, लॉग शिपिंग, उपलब्धता समूह, बैकअप और .. अन्य हैं। यह दुर्भाग्य से समस्याओं को हल नहीं करता है।

— मैरियन

एक सर्वर पर हम दो उदाहरण बना सकते हैं और दो उदाहरणों के बीच प्रतिकृति बना सकते हैं।

— अविनाश मेंडे