जैसे-जैसे समय बीतता है, अधिक कंपनियां, परिसर में SQL सर्वर चलाने की उच्च लागत के विकल्प के रूप में, Azure SQL डेटाबेस में माइग्रेट कर रही हैं, या कम से कम मूल्यांकन कर रही हैं।
संगतता जांचा जा रहा है
अपने डेटाबेस को Azure SQL डेटाबेस में ले जाने के पहले पहलुओं में से एक संगतता की जांच करना है और Microsoft आपको कई Azure SQL डेटाबेस V12 के लिए ऐसा करने के तरीके (इसके बाद केवल 'V12' के रूप में संदर्भित)। इन विधियों में से एक विजुअल स्टूडियो (एसएसडीटी) के लिए SQL सर्वर डेटा टूल्स का उपयोग कर रहा है जो V12 असंगतताओं का पता लगाने के लिए नवीनतम संगतता नियमों का उपयोग करता है। SSDT में आप अपने डेटाबेस स्कीमा को आयात कर सकते हैं और V12 परिनियोजन के लिए एक प्रोजेक्ट बना सकते हैं, और यदि कोई असंगतता पाई जाती है, तो उन्हें SSDT के भीतर ठीक किया जा सकता है और फिर स्रोत डेटाबेस में वापस सिंक्रनाइज़ किया जा सकता है।
आप SqlPackage नामक कमांड-लाइन टूल का भी उपयोग कर सकते हैं जो संगतता समस्याओं की रिपोर्ट उत्पन्न कर सकता है (और हमेशा सुनिश्चित करें कि आपके पास नवीनतम संस्करण है)। SQL सर्वर प्रबंधन स्टूडियो इसे करने का एक और तरीका है, निर्यात डेटा-स्तरीय एप्लिकेशन सुविधा का उपयोग करके, जो स्क्रीन पर त्रुटियों का पता लगा सकता है और रिपोर्ट कर सकता है। यदि कोई त्रुटि नहीं पाई जाती है, तो आप अपने डेटाबेस को V12 में माइग्रेट कर सकते हैं। यदि असंगतताएं पाई जाती हैं, तो उन्हें माइग्रेशन से पहले SSMS का उपयोग करके ठीक किया जा सकता है।
डेटा माइग्रेशन असिस्टेंट एक स्टैंड-अलोन टूल है (एसक्यूएल सर्वर माइग्रेशन असिस्टेंट के साथ आसानी से भ्रमित) जिसका उपयोग अपग्रेड के प्रयास को कम करने में मदद के लिए किया जा सकता है, और SQL सर्वर 2016 अपग्रेड एडवाइजर प्रीव्यू को बदल देता है। डीएमए प्रदर्शन और विश्वसनीयता में सुधार की भी सिफारिश कर सकता है। एक अन्य उपकरण, SQL Azure माइग्रेशन विज़ार्ड (SAMW), एक कोडप्लेक्स उपकरण है जो V12 असंगतताओं का पता लगाने के लिए Azure SQL डेटाबेस V11 संगतता नियमों का उपयोग करता है। SAMW भी V12 में माइग्रेशन को पूरा कर सकता है और कुछ संगतता समस्याओं को ठीक कर सकता है। SAMW का उपयोग करते समय ध्यान देने योग्य बात यह है कि यह उन असंगतताओं का पता लगा सकता है जिन्हें ठीक करने की आवश्यकता नहीं है।
डेटा माइग्रेट करना
एक बार जब आपका डेटाबेस संगतता जांच पास कर लेता है, तो आपको माइग्रेट करने का सबसे अच्छा तरीका निर्धारित करना होगा। कुछ अधिक सामान्य तरीकों में SSMS माइग्रेशन विज़ार्ड का उपयोग करना, BACPAC को निर्यात करना, लेन-देन संबंधी प्रतिकृति का उपयोग करना, या डेटाबेस को मैन्युअल रूप से स्क्रिप्ट करना और अपना डेटा सम्मिलित करना शामिल है।
SSMS माइग्रेशन विज़ार्ड का उपयोग करना SQL सर्वर 2005 और ऊपर के डेटाबेस के लिए बहुत अच्छा है जो छोटे से मध्यम आकार के हैं। आप डेटाबेस पर राइट क्लिक करके, SSMS 2016 में इस विज़ार्ड को सक्रिय कर सकते हैं, कार्य चुनें, और फिर डेटाबेस को Microsoft Azure SQL डेटाबेस में परिनियोजित करें। SSMS 2014 में इसे Windows Azure SQL डेटाबेस में डिप्लॉय डेटाबेस कहा जाता है। इस विज़ार्ड का उपयोग करने से आप माइग्रेट करने के लिए डेटाबेस निर्दिष्ट कर सकते हैं, अपनी Azure सदस्यता से कनेक्ट कर सकते हैं, .bacpac फ़ाइल के लिए स्थान चुन सकते हैं, नया डेटाबेस नाम और किस स्तर पर माइग्रेट करना है। जब आप समाप्त पर क्लिक करते हैं, तो विज़ार्ड स्कीमा को निकालेगा और मान्य करेगा और फिर डेटा निर्यात करेगा। एक बार डेटा निर्यात हो जाने पर, यह एक परिनियोजन योजना बनाएगा और डेटा को नए V12 डेटाबेस में आयात करना शुरू कर देगा।
बहुत हद तक SSMS माइग्रेशन विजार्ड से मिलता-जुलता है, एक्सपोर्ट डेटा-टियर एप्लिकेशन। इस विकल्प को चुनने के लिए, डेटाबेस पर राइट क्लिक करें, टास्क को चुनें और फिर डेटा-टियर एप्लिकेशन को एक्सपोर्ट करें। निर्यात सेटिंग्स में आप निर्दिष्ट करते हैं कि आप .bacpac फ़ाइल कहाँ बनाना चाहते हैं। आप इसे स्थानीय रूप से सहेज सकते हैं, या इसे सीधे अपने Azure संग्रहण खाते में सहेज सकते हैं। एक उन्नत टैब भी है जहाँ आप चुन सकते हैं कि किन तालिकाओं को शामिल करना है। यह मददगार है यदि आपके स्थानीय डेटाबेस में उन तालिकाओं की प्रतियां हैं जिन्हें आप V12 में माइग्रेट नहीं करना चाहते हैं। जब आप समाप्त चुनते हैं, तो यह आपके डेटा को निर्यात करेगा। फिर आप SSMS के माध्यम से अपने Azure सर्वर से जुड़ सकते हैं और डेटा-स्तरीय एप्लिकेशन आयात करना चुन सकते हैं। आप फ़ाइल का स्थान, डेटाबेस का नाम और Azure SQL डेटाबेस का स्तर निर्दिष्ट करेंगे। जब आप फिनिश चुनते हैं, तो डेटाबेस आयात करना शुरू कर देगा। यह विधि आपको प्रक्रिया पर थोड़ा अधिक नियंत्रण देती है क्योंकि यह निर्यात को आयात से अलग करती है। यह आपको अपने Azure संग्रहण खाते में .bacpac फ़ाइल को संग्रहीत करने का विकल्प भी देता है ताकि अधिक असुरक्षित आयात प्रक्रिया आपके इंटरनेट कनेक्शन पर निर्भर न हो।
SSMS माइग्रेशन विज़ार्ड या निर्यात डेटा-स्तरीय एप्लिकेशन का उपयोग करते समय एक विकल्प SQL सर्वर के साथ एक Azure VM बनाना और लॉग शिपिंग सेट करना है। यह डेटाबेस के आयात समय को कम करने में मदद करने के लिए आपके डेटाबेस को Azure क्लाउड में प्री-स्टेज करेगा। जब माइग्रेशन करने का समय आता है, तो आप सेकेंडरी पर अंतिम लॉग बैकअप को पुनर्स्थापित करते हैं और फिर लॉग शिपिंग को हटा देते हैं। डेटाबेस को ऑनलाइन लाने के लिए, पुनर्प्राप्ति के साथ पुनर्स्थापना करें। यह अनिवार्य रूप से आपके डेटाबेस को आपके डेटा केंद्र से Azure डेटा केंद्र में कॉपी करने में लगने वाले समय को समाप्त कर देगा।
V12 में माइग्रेट करने के डाउनटाइम को कम करने में मदद करने के लिए लेनदेन संबंधी प्रतिकृति एक और तरीका है। यदि डेटाबेस ट्रांजेक्शनल प्रतिकृति का समर्थन कर सकता है, तो यह सबसे अच्छा विकल्प है यदि आपके पास V12 पर स्विच करने के लिए बहुत छोटी रखरखाव विंडो है। ट्रांजेक्शनल प्रतिकृति की स्थापना के लिए प्रत्येक प्रकाशित तालिका के लिए प्राथमिक कुंजी की आवश्यकता होती है, जो बहुत सारे डेटाबेस के लिए समस्याग्रस्त हो सकती है। लेन-देन संबंधी प्रतिकृति को कॉन्फ़िगर करना भी जटिल हो सकता है, क्योंकि आपको वितरण डेटाबेस सेट करना होगा, प्रकाशक और ग्राहक को सेट करना होगा और नौकरियों की निगरानी करनी होगी।
आप जनरेट स्क्रिप्ट विज़ार्ड का उपयोग करके और डेटाबेस स्कीमा और/या डेटा को स्क्रिप्टिंग करके मैन्युअल रूप से माइग्रेट भी कर सकते हैं। फिर आप Azure में एक खाली डेटाबेस बना सकते हैं और स्क्रिप्ट निष्पादित करके अपनी स्कीमा और या डेटा आयात कर सकते हैं। मैंने कुछ लोगों के बारे में सुना है जो खाली डेटाबेस बनाने के लिए इस पद्धति का उपयोग करते हैं और फिर एसएसएमएस और एक लिंक किए गए सर्वर का उपयोग करके एक समय में अपना डेटा एक टेबल मैन्युअल रूप से सम्मिलित करते हैं। यह विधि आपके लिए काम कर सकती है, लेकिन यह बहुत जटिल भी हो सकती है यदि आपके पास विदेशी कुंजी संबंध और पहचान कॉलम जैसी बहुत सी स्कीमा संरचनाएं हैं, तो इस स्थिति में उपरोक्त अन्य विधियां अधिक विश्वसनीय और कुशल होंगी।
अन्य माइग्रेशन विचार
परिसर डेटाबेस पर V12 में माइग्रेट करने की योजना बनाते समय, डेटाबेस का आकार माइग्रेशन में कितना समय लगेगा, इसका एक बड़ा कारक है। डेटाबेस का निर्यात, डेटा का स्थानांतरण, और आयात सभी डेटाबेस के आकार के अनुपात में बढ़ेंगे।
अपने डेटाबेस को V12 में ले जाते समय पुनर्स्थापना/आयात समय में एक और बड़ा कारक प्रदर्शन स्तर है जिसे आप भी पुनर्स्थापित कर रहे हैं। पुनर्स्थापना/आयात प्रक्रिया के लिए बहुत अधिक अश्वशक्ति की आवश्यकता होती है, इसलिए अपने प्रवास में तेजी लाने में सहायता के लिए, आपको उच्च प्रदर्शन स्तर पर पुनर्स्थापित करने पर विचार करना चाहिए। जब डेटाबेस ऑनलाइन होता है, तो आप आसानी से और जल्दी से कम स्तर पर जा सकते हैं जो आपकी दैनिक प्रदर्शन आवश्यकताओं को पूरा करता है। कुछ माउस क्लिक के साथ प्रदर्शन स्तरों को बदलने में सक्षम होना Azure SQL डेटाबेस के बड़े लाभों में से एक है।
निगरानी
किसी भी डेटाबेस को प्रशासित करने का एक महत्वपूर्ण हिस्सा निगरानी कर रहा है। यदि आप किसी चीज की निगरानी नहीं कर रहे हैं, तो आप उसे माप नहीं सकते। यदि आप नहीं जानते कि जब चीजें सामान्य रूप से काम कर रही हैं तो आपके मेट्रिक्स क्या हैं, तो आपको कैसे पता चलेगा कि प्रदर्शन खराब होने पर कौन सी चीजें बदतर हैं? ऑन-प्रिमाइसेस डेटाबेस के साथ, हमारे पास ऐसे उपकरण हैं जिनसे हम परिचित हैं:SQL सर्वर प्रबंधन स्टूडियो, प्रदर्शन मॉनिटर, कार्य प्रबंधक, DMV, और इसी तरह। जब हम अपने डेटाबेस को V12 में ले जाते हैं, तो हम OS के दृष्टिकोण से निगरानी करने की क्षमता खो देते हैं, और अन्य अवधारणाएँ भी थोड़ी बदल जाती हैं। अब हमारे पास काम करने के लिए डीटीयू नामक यह मीट्रिक है, जो डेटाबेस लेनदेन इकाइयों के लिए है। इसे CPU, डेटा और ट्रांजैक्शन लॉग I/O, और मेमोरी के संयोजन के रूप में सोचें। Azure पोर्टल में एक मॉनिटरिंग चार्ट शामिल होता है जो डिफ़ॉल्ट रूप से DTU प्रतिशत की जाँच करता है, और आप अतिरिक्त मीट्रिक शामिल करने के लिए इस चार्ट को संपादित कर सकते हैं, जैसे:
- फ़ायरवॉल द्वारा अवरोधित
- सीपीयू%
- डीटीयू सीमा
- डीटीयू का इस्तेमाल किया
- डेटा I/O%
- डेटाबेस आकार%
- गतिरोध
- विफल कनेक्शन
- इन-मेमोरी OLTP स्टोरेज %
(पूर्वावलोकन)
- लॉग I/O%
- सत्र%
- सफल कनेक्शन
- कुल डेटाबेस आकार
- श्रमिक%
कम से कम, मैं CPU प्रतिशत, डेटा I/O प्रतिशत, गतिरोध और डेटाबेस आकार प्रतिशत जोड़ूंगा। वर्तमान में, यह चार्ट संसाधन उपयोग के पिछले घंटे को प्रदर्शित करता है।
व्यक्तिगत डेटाबेस मेट्रिक्स से संबंधित कुछ नए डीएमवी और डेटाबेस आकार की गणना कैसे करें, इसके अलावा, डीएमवी द्वारा निगरानी में ज्यादा बदलाव नहीं आया है। मेरे पिछले लेखों में से एक, Azure SQL डेटाबेस में ट्यूनिंग प्रदर्शन शुरू करना, कुछ सामान्य स्क्रिप्ट में अंतर को शामिल करता है जो कि Azure SQL डेटाबेस के संबंध में डिस्क विलंबता और प्रतीक्षा आँकड़े एकत्र करने के लिए उपयोग किया जाता है।
तृतीय-पक्ष टूल ने Azure SQL डेटाबेस में हुक भी शामिल करना शुरू कर दिया है, जैसे कि SentryOne और DB Sentry। DB संतरी आपको प्रदर्शन की निगरानी करने और आपके सिस्टम में होने वाली घटनाओं को प्रबंधित करने की क्षमता देता है। एक अच्छी विशेषता शीर्ष SQL फ़ंक्शन है जो आपको उन प्रश्नों को देखने की अनुमति देता है जो आपके समग्र प्रदर्शन पर सबसे अधिक प्रभाव डालते हैं ताकि आप उस क्वेरी के साथ किसी भी समस्या को ट्यून/ठीक कर सकें। एक अन्य समय के साथ DTU को चार्ट कर रहा है और अन्य महत्वपूर्ण मेट्रिक्स के साथ एक डैशबोर्ड पर इसकी कल्पना कर रहा है।
 SentryOne क्लाइंट में शीर्ष SQL |  DB संतरी डैशबोर्ड पर DTU उपयोग |
ये मीट्रिक एक समर्पित डेटाबेस में संग्रहीत होते हैं, जो आपको समय के साथ बेसलाइन और प्रदर्शन के साथ रुझान प्रदान करने की क्षमता प्रदान करते हैं, जो आपको वर्तमान में Azure पोर्टल में मिलने वाले सीमित चार्ट से बहुत बेहतर है।
सारांश
यदि आपका डेटाबेस संगत है, तो Azure SQL डेटाबेस V12 में माइग्रेट करने के कई लाभ हैं, इसलिए V12 के साथ अपनी संगतता जांचने के लिए उपलब्ध टूल में से किसी एक का लाभ उठाएं। यदि आपका डेटाबेस संगत है, या संगत बनने के लिए आसानी से संशोधित किया जा सकता है, तो आप आसानी से Azure SQL डेटाबेस V12 में माइग्रेट कर सकते हैं और अपने एप्लिकेशन और वर्कलोड का परीक्षण और बेंचमार्किंग शुरू कर सकते हैं।
