मार्गदर्शिका

एक मिशन-क्रिटिकल SQL database को 99.995% SLA, ज़ोन-रिडंडेंट HA, और रीड स्केल-आउट क्षमताओं की आवश्यकता है।

→ज़ोन रिडंडेंसी सक्षम के साथ Business Critical सेवा टियर का उपयोग करके Azure SQL Database को परिनियोजित करें।

क्यों: Business Critical उच्चतम SLA प्रदान करता है, कम विलंबता के लिए स्थानीय SSDs का उपयोग करता है, और इसमें बिना किसी अतिरिक्त लागत के अंतर्निहित पठनीय सेकेंडरी रेप्लिका शामिल हैं। General Purpose में कम SLA और कोई अंतर्निहित रीड रेप्लिका नहीं होती है।

संदर्भ↗

एक डेटाबेस में लंबे निष्क्रिय अवधियों के साथ अप्रत्याशित, रुक-रुक कर उपयोग पैटर्न होते हैं। लागत अनुकूलन महत्वपूर्ण है।

→Serverless कंप्यूट मॉडल के साथ General Purpose टियर का उपयोग करके Azure SQL Database को परिनियोजित करें।

क्यों: Serverless मांग के आधार पर कंप्यूट को स्वचालित रूप से स्केल करता है और निष्क्रियता के दौरान ऑटो-पॉज़ हो सकता है, केवल स्टोरेज के लिए शुल्क लेता है। यह गैर-निरंतर वर्कलोड के लिए Provisioned कंप्यूट की तुलना में अधिक लागत प्रभावी है।

संदर्भ↗

एक ऑन-प्रेमिसेस SQL Server को माइग्रेट करना जो SQL Server Agent, क्रॉस-डेटाबेस क्वेरीज़ और Service Broker जैसी सुविधाओं पर बहुत अधिक निर्भर करता है।

→Azure SQL Managed Instance पर माइग्रेट करें।

क्यों: Managed Instance ऑन-प्रेमिसेस SQL Server के साथ लगभग 100% अनुकूलता प्रदान करता है, इंस्टेंस-लेवल सुविधाओं को संरक्षित करता है जो Azure SQL Database में उपलब्ध नहीं हैं।

संदर्भ↗

एक एप्लिकेशन को OS-लेवल एक्सेस, फ़ाइल सिस्टम एक्सेस (जैसे, Filestream के लिए), या PaaS ऑफ़रिंग द्वारा समर्थित नहीं की गई सुविधाओं की आवश्यकता है, जैसे CLR EXTERNAL_ACCESS के साथ।

→Azure Virtual Machine (IaaS) पर SQL Server को परिनियोजित करें।

क्यों: IaaS ऑपरेटिंग सिस्टम और SQL Server इंस्टेंस पर पूर्ण नियंत्रण प्रदान करता है, जिससे ऑन-प्रेमिसेस कॉन्फ़िगरेशन के साथ अधिकतम अनुकूलता मिलती है, लेकिन प्रबंधन ओवरहेड बढ़ जाता है।

एक डेटाबेस के 4 TB से 100 TB तक बढ़ने की उम्मीद है, और इसे तीव्र स्टोरेज स्केलिंग और त्वरित रिस्टोर की आवश्यकता है।

→Hyperscale सेवा टियर का उपयोग करके Azure SQL Database को परिनियोजित करें।

क्यों: Hyperscale Very Large Databases (VLDBs) के लिए डिज़ाइन किया गया है, जो 100 TB तक का स्टोरेज प्रदान करता है जो स्वचालित रूप से स्केल होता है। यह आकार की परवाह किए बिना तेज़, स्थिर-समय डेटाबेस रिस्टोर के लिए पेज सर्वर के साथ एक अद्वितीय आर्किटेक्चर का उपयोग करता है।

संदर्भ↗

एक SaaS एप्लिकेशन कई छोटे डेटाबेस होस्ट करता है जिनमें अलग-अलग, अप्रत्याशित उपयोग पैटर्न होते हैं। साझा संसाधन प्रदान करते हुए लागतों को अनुकूलित करने की आवश्यकता है।

→डेटाबेस को Azure SQL Database elastic pool में समूहित करें।

क्यों: Elastic pools कई डेटाबेस को एक निश्चित मूल्य पर संसाधनों (eDTUs या vCores) के एक सेट को साझा करने की अनुमति देते हैं, जो व्यक्तिगत डेटाबेस को प्रोविज़न करने की तुलना में अधिक लागत प्रभावी है जब सभी किरायेदारों में उपयोग स्थिर नहीं होता है।

एक वर्चुअल नेटवर्क में Azure SQL Managed Instance को परिनियोजित करना।

→न्यूनतम /27 (32 पते) आकार के साथ एक समर्पित सबनेट बनाएं और इसे Microsoft.Sql/managedInstances को सौंपें।

क्यों: Managed Instance को अपने आंतरिक घटकों और भविष्य के स्केलिंग के लिए पर्याप्त IP पतों के साथ एक समर्पित, खाली सबनेट की आवश्यकता होती है। /27 न्यूनतम समर्थित आकार है।

न्यूनतम डाउनटाइम के साथ एक बड़े, मिशन-क्रिटिकल ऑन-प्रेमिसेस SQL Server डेटाबेस को Azure में माइग्रेट करना।

→ऑनलाइन माइग्रेशन मोड में Azure Database Migration Service (DMS) का उपयोग करें।

क्यों: DMS ऑनलाइन माइग्रेशन एक प्रारंभिक लोड करता है और फिर लक्ष्य को सिंक में रखने के लिए निरंतर डेटा सिंक्रनाइज़ेशन (लॉग शिपिंग) का उपयोग करता है, जिससे बहुत कम कटओवर विंडो मिलती है।

बड़े अनुक्रमिक रीड के साथ डेटा वेयरहाउस वर्कलोड होस्ट करने वाले Azure VM पर SQL Server के लिए स्टोरेज कॉन्फ़िगर करना।

→Premium SSDs का उपयोग करें। डेटा फ़ाइलों के लिए Read-only host caching कॉन्फ़िगर करें और लॉग फ़ाइलों के लिए None कॉन्फ़िगर करें।

क्यों: Read-only caching डेटा वेयरहाउस में सामान्य बड़े अनुक्रमिक रीड के लिए इष्टतम है। राइट ड्यूरेबिलिटी सुनिश्चित करने और डेटा हानि को रोकने के लिए लॉग फ़ाइलों में कैशिंग अक्षम होनी चाहिए।

एक सुरक्षा नीति के लिए सभी डेटाबेस कनेक्शनों को एन्क्रिप्ट करने और सर्वर प्रमाणपत्र को मान्य करने की आवश्यकता है।

→सर्वर पर न्यूनतम TLS संस्करण को 1.2 पर सेट करें। क्लाइंट कनेक्शन स्ट्रिंग्स में, `Encrypt=Strict` का उपयोग करें।

क्यों: सर्वर पर न्यूनतम TLS सेट करने से असुरक्षित प्रोटोकॉल वार्तालाप रुक जाता है। `Encrypt=Strict` (TDS 8.0+) एन्क्रिप्शन और पूर्ण प्रमाणपत्र सत्यापन को लागू करता है, जिससे man-in-the-middle हमलों को रोका जा सकता है।

विशिष्ट कॉलम (जैसे, SSN) में संवेदनशील डेटा को एन्क्रिप्ट किया जाना चाहिए, लेकिन एप्लिकेशन को एन्क्रिप्टेड डेटा पर समानता लुकअप और जॉइन करने की आवश्यकता है।

→खोज योग्य कॉलम के लिए deterministic encryption के साथ Always Encrypted का उपयोग करें।

क्यों: Deterministic encryption किसी दिए गए plaintext मान के लिए समान ciphertext उत्पन्न करता है, जिससे समानता तुलना की अनुमति मिलती है। Randomized encryption मजबूत सुरक्षा प्रदान करता है लेकिन इन ऑपरेशनों की अनुमति नहीं देता है।

डेटा-एट-रेस्ट एन्क्रिप्शन की आवश्यकता है, लेकिन संगठन को एन्क्रिप्शन कुंजियों पर पूर्ण नियंत्रण बनाए रखना होगा।

→Azure Key Vault में संग्रहीत ग्राहक-प्रबंधित कुंजियों (BYOK) के साथ Transparent Data Encryption (TDE) सक्षम करें।

क्यों: यह कॉन्फ़िगरेशन संगठन को अपने स्वयं के Key Vault में कुंजी जीवनचक्र (रोटेशन, निरसन) का प्रबंधन करने की अनुमति देता है, जिससे कुंजी स्वामित्व के लिए नियंत्रण और अनुपालन आवश्यकताओं को पूरा किया जा सके।

एक Azure SQL Database केवल एक विशिष्ट Azure Virtual Network से ही सुलभ होना चाहिए, जिसमें सार्वजनिक इंटरनेट एक्सेस पूरी तरह से अवरुद्ध हो।

→SQL Server के लिए एक Private Endpoint कॉन्फ़िगर करें और "Deny public network access" को Yes पर सेट करें।

क्यों: एक Private Endpoint SQL डेटाबेस को आपके VNet के भीतर एक निजी IP देता है। सार्वजनिक एक्सेस को अक्षम करने से यह सुनिश्चित होता है कि यह कनेक्ट करने का एकमात्र तरीका है, जिससे पूर्ण नेटवर्क आइसोलेशन मिलता है।

एक मल्टी-टेनेंट एप्लिकेशन को यह सुनिश्चित करना चाहिए कि उपयोगकर्ता केवल एक साझा तालिका के भीतर अपना डेटा देख सकें।

→एक security predicate (इनलाइन टेबल-वैल्यूड फ़ंक्शन) और एक सुरक्षा नीति बनाकर Row-Level Security (RLS) लागू करें जो इसे तालिका पर लागू करती है।

क्यों: RLS उपयोगकर्ता संदर्भ (जैसे, USER_NAME() या SESSION_CONTEXT) के आधार पर पंक्तियों को पारदर्शी रूप से फ़िल्टर करता है, एप्लिकेशन परिवर्तनों के बिना डेटाबेस इंजन स्तर पर डेटा आइसोलेशन लागू करता है।

डेटाबेस प्रशासकों को डेटाबेस का प्रबंधन करने की आवश्यकता है, लेकिन उन्हें कुछ कॉलम में संवेदनशील डेटा देखने में सक्षम नहीं होना चाहिए।

→संवेदनशील कॉलम पर Dynamic Data Masking (DDM) लागू करें। DBAs को UNMASK अनुमति न दें।

क्यों: DDM संग्रहीत डेटा को बदले बिना गैर-विशेषाधिकार प्राप्त उपयोगकर्ताओं के लिए क्वेरी परिणामों में डेटा को अस्पष्ट करता है। यह DBAs को वास्तविक संवेदनशील जानकारी देखने से रोकते हुए अपने कर्तव्यों का पालन करने की अनुमति देता है।

एक सुरक्षा नीति Azure SQL DB या Managed Instance के लिए केंद्रीकृत पहचान प्रबंधन और MFA लागू करने के लिए SQL authentication को अक्षम करने का आदेश देती है।

→सर्वर के लिए एक Azure AD एडमिन सेट करें और "Azure AD-only authentication" प्रॉपर्टी सक्षम करें।

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

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

→Microsoft Defender for SQL (पूर्व में Advanced Threat Protection) सक्षम करें।

क्यों: Defender for SQL संदिग्ध गतिविधियों के लिए डेटाबेस लॉग का विश्लेषण करता है और सुरक्षा अलर्ट उत्पन्न करता है, जो बुनियादी एक्सेस नियंत्रणों से परे खतरे का पता लगाने की एक महत्वपूर्ण परत प्रदान करता है।

एक Azure SQL Database के लिए ऑडिट लॉग को कई वर्षों तक बनाए रखा जाना चाहिए और अनुपालन और सुरक्षा जांच के लिए खोज योग्य होना चाहिए।

→आवश्यक डेटा रिटेंशन कॉन्फ़िगरेशन के साथ लॉग को Log Analytics workspace पर भेजने के लिए Azure SQL Auditing को कॉन्फ़िगर करें।

क्यों: Log Analytics दीर्घकालिक प्रतिधारण और शक्तिशाली KQL-आधारित क्वेरी क्षमताओं प्रदान करता है, जिससे यह खोज योग्य, दीर्घकालिक ऑडिट डेटा के लिए Blob Storage से बेहतर है।

समस्या निवारण के लिए DevOps टीम को डेटाबेस तक अस्थायी, समय-सीमाबद्ध और अनुमोदन-गेटेड एक्सेस प्रदान करें।

→डेटाबेस एक्सेस वाले Azure AD समूह के लिए पात्रता प्रबंधित करने के लिए Azure AD Privileged Identity Management (PIM) का उपयोग करें।

क्यों: PIM जस्ट-इन-टाइम (JIT) एक्सेस प्रदान करता है जो ऑडिटेबल है, औचित्य की आवश्यकता है, और स्वचालित रूप से समाप्त हो जाता है, जिससे कम विशेषाधिकार के सिद्धांत का पालन होता है।

एक सिस्टम को सख्त नियामक अनुपालन को पूरा करने के लिए सभी डेटा संशोधनों का एक सत्यापन योग्य, छेड़छाड़-स्पष्ट इतिहास की आवश्यकता है।

→Azure SQL Database ledger सुविधा का उपयोग करें।

क्यों: Ledger तालिकाएं क्रिप्टोग्राफिक रूप से डेटा परिवर्तनों को लिंक करने के लिए ब्लॉकचेन अवधारणाओं का उपयोग करती हैं, एक अपरिवर्तनीय इतिहास बनाती हैं जिसे स्वतंत्र रूप से सत्यापित किया जा सकता है। यह temporal tables से अधिक मजबूत है, जो छेड़छाड़-स्पष्ट नहीं हैं।

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

→Query Store को सक्षम और उपयोग करें।

क्यों: Query Store क्वेरी प्रदर्शन के लिए अंतर्निहित "फ्लाइट डेटा रिकॉर्डर" है। यह स्वचालित रूप से क्वेरी इतिहास, प्लान और वेट स्टैट्स को कैप्चर करता है, जिससे यह समय के साथ प्रदर्शन समस्याओं का निदान करने के लिए प्राथमिक उपकरण बन जाता है।

संदर्भ↗

एक क्वेरी कभी-कभी अच्छा प्रदर्शन करती है लेकिन parameter sniffing समस्याओं के कारण अन्य समय में खराब प्रदर्शन करती है, जहां एक execution plan एक गैर-प्रतिनिधि पैरामीटर मान के लिए अनुकूलित होती है।

→विभिन्न प्लान्स की पहचान करने और लगातार अच्छी execution plan को लागू करने के लिए Query Store का उपयोग करें।

क्यों: Query Store में प्लान फ़ोर्सिंग कोड परिवर्तनों के बिना समस्याग्रस्त क्वेरीज़ के प्रदर्शन को स्थिर करने का एक त्वरित और प्रभावी तरीका प्रदान करती है। यह एक ज्ञात-अच्छी योजना के साथ ऑप्टिमाइज़र की पसंद को ओवरराइड करता है।

कोड परिवर्तनों के बिना क्वेरी प्रदर्शन में सुधार करने के लिए, rowstore पर batch mode, memory grant feedback, और table variable deferred compilation जैसी सुविधाओं का लाभ उठाना।

→डेटाबेस कंपैटिबिलिटी स्तर को 150 (SQL 2019 सुविधाओं के लिए) या उससे अधिक पर सेट करें।

क्यों: Intelligent Query Processing (IQP) फीचर सेट डेटाबेस कंपैटिबिलिटी स्तर द्वारा सक्षम किया जाता है। स्तर 150+ क्वेरी प्रोसेसर में "नो-कोड-चेंज" प्रदर्शन सुधारों की एक विस्तृत श्रृंखला को सक्रिय करता है।

ऑपरेशंस टीम को सूचित किया जाना चाहिए जब मुख्य प्रदर्शन मेट्रिक्स, जैसे CPU प्रतिशत या deadlocks, एक परिभाषित सीमा से अधिक हो जाते हैं।

→CPU के लिए metric alerts और deadlocks के लिए log alerts बनाने के लिए Azure Monitor का उपयोग करें जो एक Action Group को ट्रिगर करता है।

क्यों: Azure Monitor Azure संसाधनों की निगरानी और अलर्टिंग के लिए केंद्रीकृत प्लेटफ़ॉर्म है। Action Groups लचीले नोटिफिकेशन चैनल (ईमेल, SMS, वेबहुक, आदि) प्रदान करते हैं।

किसी भी रीड क्वेरी द्वारा उपयोग नहीं किए जा रहे indexes की पहचान करके और उन्हें हटाकर राइट प्रदर्शन में सुधार करें।

→`sys.dm_db_index_usage_stats` DMV को क्वेरी करें।

क्यों: यह DMV इंडेक्स उपयोग (सीक, स्कैन, लुकअप) बनाम अपडेट को ट्रैक करता है। उच्च अपडेट वाले लेकिन शून्य या बहुत कम उपयोग वाले indexes हटाने के लिए प्रमुख उम्मीदवार होते हैं, जिससे रखरखाव ओवरहेड कम होता है।

बीच-बीच में होने वाली ब्लॉकिंग समस्याओं के बारे में विस्तृत जानकारी कैप्चर करने की आवश्यकता है, जिसमें ब्लॉकिंग चेन में शामिल स्टेटमेंट और सेशन शामिल हैं।

→एक Extended Events सेशन कॉन्फ़िगर करें जो `blocked_process_report` इवेंट को कैप्चर करता है।

क्यों: यह इवेंट ब्लॉकिंग चेन की विस्तृत XML रिपोर्ट प्रदान करता है जब `blocked process threshold` पार हो जाता है, जो DMVs में उपलब्ध न होने वाली गहन नैदानिक ​​जानकारी प्रदान करता है।

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

→Azure SQL Database Automatic tuning में CREATE_INDEX विकल्प सक्षम करें।

क्यों: यह सुविधा Azure को वर्कलोड का विश्लेषण करने, उच्च प्रभाव वाले missing indexes की पहचान करने, उन्हें बनाने और उनके प्रदर्शन लाभ को मान्य करने की अनुमति देती है, जिससे एक प्रमुख DBA कार्य स्वचालित हो जाता है।

Business Critical या Premium टियर में प्राथमिक OLTP डेटाबेस से रीड-हैवी रिपोर्टिंग वर्कलोड को ऑफलोड करें।

→एप्लिकेशन की रीड-ओनली कनेक्शन स्ट्रिंग्स को `ApplicationIntent=ReadOnly` शामिल करने के लिए संशोधित करें।

क्यों: इन टियर में एक मुफ्त, अंतर्निहित पठनीय सेकेंडरी रेप्लिका शामिल है। कनेक्शन स्ट्रिंग में `ApplicationIntent` प्रॉपर्टी स्वचालित रूप से रीड-ओनली कनेक्शन को इस रेप्लिका पर रूट करती है, जिससे रीड वर्कलोड को अलग किया जाता है।

एक डेटा वेयरहाउस में एक बड़ी फैक्ट तालिका का अक्सर एकत्रीकरण क्वेरी (SUM, COUNT, AVG) के लिए उपयोग किया जाता है जो धीरे-धीरे प्रदर्शन कर रही हैं।

→फैक्ट तालिका पर एक clustered columnstore index बनाएं।

क्यों: Columnstore indexes डेटा को कॉलम फ़ॉर्मेट में संग्रहीत करते हैं, जिससे बहुत अधिक डेटा कम्प्रेशन मिलता है और batch mode execution सक्षम होता है, जो एग्रीगेशन और स्कैन-हैवी एनालिटिकल क्वेरीज़ को नाटकीय रूप से तेज करता है।

एक डेटाबेस रीड क्वेरीज़ (रिपोर्ट) और राइट क्वेरीज़ (ट्रांजेक्शन) के बीच महत्वपूर्ण ब्लॉकिंग कंटेन्शन का अनुभव करता है।

→डेटाबेस पर Read Committed Snapshot Isolation (RCSI) सक्षम करें।

क्यों: RCSI row versioning का उपयोग करता है, जिससे रीडर्स को साझा लॉक लिए बिना डेटा का अंतिम कमिटेड संस्करण देखने की अनुमति मिलती है, जिससे लेखकों से ब्लॉक समाप्त हो जाते हैं। लेखक रीडर्स को ब्लॉक नहीं करते हैं।

एक Serverless डेटाबेस का उपयोग करने वाला एक एप्लिकेशन निष्क्रियता की अवधि के बाद प्रारंभिक धीमे कनेक्शन समय का अनुभव करता है।

→ऑटो-पॉज़ देरी को कम करें या शून्य से अधिक न्यूनतम vCore मान कॉन्फ़िगर करें।

क्यों: यह देरी डेटाबेस के पॉज़ किए गए स्टेट (cold start) से फिर से शुरू होने के कारण होती है। एक न्यूनतम vCore मान सेट करने से डेटाबेस को पूरी तरह से पॉज़ होने से रोका जा सकता है, जिससे कुछ निरंतर कंप्यूट बिलिंग की लागत पर रेज़्यूमे विलंबता समाप्त हो जाती है।

स्वचालित, संस्करण-नियंत्रित और दोहराए जाने योग्य डेटाबेस स्कीमा डिप्लॉयमेंट के लिए एक CI/CD पाइपलाइन लागू करें।

→DACPAC फ़ाइल उत्पन्न करने के लिए एक SQL Database Project (जैसे, Visual Studio में) का उपयोग करें। DACPAC को डिप्लॉय करने के लिए Azure DevOps pipelines का उपयोग करें।

क्यों: यह SQL स्कीमा के लिए मानक Infrastructure as Code (IaC) पैटर्न है। DACPAC स्कीमा का एक घोषणात्मक मॉडल है, और परिनियोजन उपकरण अंतर स्क्रिप्ट उत्पन्न करने का काम करते हैं, जिससे स्थिरता सुनिश्चित होती है।

एक Azure SQL Database को एक शेड्यूल या मीट्रिक थ्रेशोल्ड (जैसे, उच्च CPU) के आधार पर स्वचालित रूप से स्केल अप या डाउन करने की आवश्यकता है।

→एक शेड्यूल या Azure Monitor अलर्ट द्वारा ट्रिगर किए गए Azure Automation runbook (PowerShell) का उपयोग करें।

क्यों: Azure SQL Database (Provisioned tier) में अंतर्निहित ऑटोस्केलिंग नहीं है। Azure Automation स्क्रिप्ट और शेड्यूल का उपयोग करके इस प्रकार के ऑपरेशनल कार्य को व्यवस्थित करने के लिए मानक उपकरण है।

एक रखरखाव स्क्रिप्ट (जैसे, index rebuild) को सैकड़ों Azure SQL डेटाबेस के विरुद्ध निष्पादित करने की आवश्यकता है।

→Elastic Jobs का उपयोग करें।

क्यों: Elastic Jobs एक PaaS सेवा है जिसे विशेष रूप से डेटाबेस के एक लक्ष्य समूह में T-SQL जॉब चलाने, क्रेडेंशियल, शेड्यूलिंग और लॉगिंग को केंद्रीय रूप से प्रबंधित करने के लिए डिज़ाइन किया गया है।

सुनिश्चित करें कि किसी सदस्यता में सभी नए बनाए गए Azure SQL Servers में TDE या Auditing जैसी एक विशिष्ट सुविधा डिफ़ॉल्ट रूप से सक्षम हो।

→`DeployIfNotExists` या `Modify` प्रभाव के साथ एक Azure Policy बनाएं।

क्यों: Azure Policy बड़े पैमाने पर शासन प्रदान करता है। `DeployIfNotExists` प्रभाव संसाधन निर्माण के दौरान गुम सेटिंग को स्वचालित रूप से कॉन्फ़िगर करेगा, मैन्युअल हस्तक्षेप के बिना अनुपालन लागू करेगा।

Azure SQL Managed Instance पर एक आवर्ती T-SQL स्क्रिप्ट या रखरखाव कार्य को शेड्यूल करें।

→अंतर्निहित SQL Server Agent का उपयोग करें।

क्यों: Managed Instance में पूर्ण SQL Server Agent शामिल है, जो ऑन-प्रेमिसेस SQL Server के समान परिचित जॉब शेड्यूलिंग क्षमताएं प्रदान करता है, बिना किसी बाहरी ऑटोमेशन सेवा की आवश्यकता के।

यह नियंत्रित करें कि Azure व्यवसाय संचालन पर प्रभाव को कम करने के लिए Azure SQL Database या Managed Instance पर नियोजित रखरखाव कब करता है।

→संसाधन के लिए एक Maintenance Window कॉन्फ़िगर करें।

क्यों: यह सुविधा आपको Azure को अपडेट लागू करने के लिए एक पूर्वनिर्धारित समय स्लॉट (जैसे, सप्ताहांत) चुनने की अनुमति देती है, जिससे आपको सेवा-प्रभावित रखरखाव पर पूर्वानुमेयता मिलती है।

एक एप्लिकेशन को डिजास्टर रिकवरी के लिए सेकेंडरी रीजन में स्वचालित failover की आवश्यकता है, बिना कनेक्शन स्ट्रिंग परिवर्तनों की आवश्यकता के।

→प्राथमिक और द्वितीयक डेटाबेस/उदाहरणों के बीच एक Auto-Failover Group कॉन्फ़िगर करें।

क्यों: Failover groups रीड-राइट और रीड-ओनली लिसनर एंडपॉइंट प्रदान करते हैं। ये एंडपॉइंट failover के बाद ट्रैफिक को स्वचालित रूप से वर्तमान प्राथमिक/द्वितीयक सर्वर पर रीडायरेक्ट करते हैं, जिससे यह प्रक्रिया एप्लिकेशन के लिए पारदर्शी हो जाती है।

कानूनी या नियामक अनुपालन आवश्यकताओं को पूरा करने के लिए डेटाबेस बैकअप को कई वर्षों (जैसे, 7-10 वर्ष) तक बनाए रखा जाना चाहिए।

→एक Long-Term Backup Retention (LTR) नीति कॉन्फ़िगर करें।

क्यों: मानक Point-in-Time Restore (PITR) बैकअप अधिकतम 35 दिनों के लिए रखे जाते हैं। LTR पूर्ण बैकअप को अलग Azure Blob Storage में 10 साल तक संग्रहीत करता है, विशेष रूप से अनुपालन आवश्यकताओं के लिए।

एक डेटाबेस को एक ही Azure क्षेत्र के भीतर एक डेटासेंटर (Availability Zone) विफलता के दौरान उपलब्ध रहना चाहिए।

→Business Critical या Premium टियर डेटाबेस के लिए ज़ोन-रिडंडेंट कॉन्फ़िगरेशन सक्षम करें।

क्यों: ज़ोन रिडंडेंसी एक ही क्षेत्र के भीतर विभिन्न भौतिक डेटासेंटर में सिंक्रोनस सेकेंडरी रेप्लिका तैनात करती है, जो ज़ोन-लेवल आउटेज के लिए RPO नियर-जीरो के साथ स्वचालित failover प्रदान करती है।

एक Azure SQL Managed Instance को स्वचालित failover क्षमता के साथ एक युग्मित Azure क्षेत्र में एक डिजास्टर रिकवरी समाधान की आवश्यकता है।

→Managed Instance के लिए एक Auto-Failover Group कॉन्फ़िगर करें।

क्यों: यह Managed Instance के लिए कैनोनिकल DR पैटर्न है, जो एसिंक्रोनस रेप्लिकेशन, पारदर्शी एप्लिकेशन failover के लिए लिसनर एंडपॉइंट और एक स्वचालित failover विकल्प प्रदान करता है।

पिछले महीने से किसी भी विशिष्ट सेकंड तक एक डेटाबेस को रिस्टोर करने में सक्षम होने की आवश्यकता है।

→शॉर्ट-टर्म बैकअप रिटेंशन (PITR) अवधि को 30-35 दिनों पर कॉन्फ़िगर करें।

क्यों: Azure SQL स्वचालित रूप से पूर्ण, अंतर और लगातार ट्रांजेक्शन लॉग बैकअप लेता है। PITR रिटेंशन सेटिंग (1-35 दिन) यह निर्धारित करती है कि ये बैकअप कितने समय तक रखे जाते हैं, पॉइंट-इन-टाइम रिस्टोर के लिए विंडो को परिभाषित करती है।

Azure VMs पर SQL Server Always On Availability Group के लिए एक Windows Server Failover Cluster कॉन्फ़िगर करना।

→quorum witness के रूप में एक Cloud Witness का उपयोग करें।

क्यों: एक Cloud Witness Azure Blob Storage का उपयोग करता है और Azure में क्लस्टर के लिए अनुशंसित, सबसे लचीला विकल्प है। यह एक फाइल शेयर विटनेस या जटिल साझा डिस्क कॉन्फ़िगरेशन के लिए तीसरे VM की आवश्यकता से बचा जाता है।

Azure VMs पर SQL Server Failover Cluster Instance (FCI) लागू करना जिसके लिए साझा स्टोरेज की आवश्यकता होती है।

→Azure Shared Disks का उपयोग करें (एक प्रबंधित डिस्क को कई VMs से जोड़ना)।

क्यों: Azure Shared Disks ब्लॉक स्टोरेज प्रदान करने के लिए मूल Azure समाधान है जिसे कई VMs द्वारा एक्सेस किया जा सकता है, जो एक पारंपरिक FCI के लिए एक पूर्व-आवश्यकता है।

एक failover group के लिए डिजास्टर रिकवरी प्रक्रिया को उत्पादन प्राथमिक डेटाबेस को प्रभावित किए बिना परीक्षण करने की आवश्यकता है।

→कम-प्रभाव वाले रखरखाव विंडो के दौरान एक नियोजित (मैन्युअल) failover शुरू करें, एप्लिकेशन कनेक्टिविटी को मान्य करें, और फिर fail back करें।

क्यों: एक नियोजित failover कोई डेटा हानि सुनिश्चित करता है और DNS प्रसार और एप्लिकेशन पुनर्जोड़ सहित पूरी DR प्रक्रिया को मान्य करने का सबसे गहन तरीका है। यह एक संक्षिप्त, नियंत्रित उत्पादन घटना है।