Microsoft SQL सर्वर पर डेटाबेस को ध्वस्त करते समय DBREPLICATION का उपयोग करना

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

परिचय

यह आलेख MS SQL सर्वर प्लेटफ़ॉर्म पर विशेष रूप से बड़े डेटाबेस को तह करने की समस्या पर चर्चा करता है। सॉफ्टपॉइंट से प्रतिकृति तकनीक DBREPLICATION का उपयोग करके इस समस्या का समाधान वर्णित है।

समस्याओं

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

दृष्टिकोण नंबर 1: हार्डवेयर

हार्डवेयर संसाधनों को बढ़ाने के लिए सबसे स्पष्ट और तकनीकी रूप से पारदर्शी समाधान है। यह या तो अधिक उत्पादक सर्वर, डिस्क भंडारण, आदि की खरीद हो सकती है, या तीसरे पक्ष के डेटा केंद्र या क्लाउड में अधिक शक्तिशाली उपकरणों के किराये पर हो सकती है।

यदि आप इस तरह से जाते हैं, तो Microsoft Azure क्लाउड में डेटाबेस रखने के लिए एक अच्छा विकल्प है। Azure डेटाबेस को होस्ट करने के लिए कई आर्किटेक्चर विकल्प प्रदान करता है: Azure वर्चुअल मशीन पर MS SQL और क्लाउड में Azure SQL डेटाबेस के लिए तीन विकल्प। इसलिए, किसी विशेष डेटाबेस की विशेषताओं और इसकी परिचालन स्थितियों के आधार पर सबसे इष्टतम प्लेसमेंट विकल्प चुनना संभव है।

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

हालांकि, इसकी सापेक्ष सादगी के बावजूद, हार्डवेयर संसाधनों में वृद्धि एक सार्वभौमिक समाधान नहीं है। सबसे पहले, सकारात्मक प्रभाव अक्सर वित्तीय निवेश के आनुपातिक से दूर होता है (कई निवेश हैं - थोड़ा प्रभाव है)। दूसरे, प्रभाव अस्थायी है, क्योंकि आधार लगातार बढ़ रहा है और अधिक संसाधनों, अधिक वित्तीय निवेश की आवश्यकता है।

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

दृष्टिकोण नंबर 2: आधार का दृढ़ संकल्प

एक अधिक कट्टरपंथी समाधान डेटाबेस का दृढ़ संकल्प है, अर्थात्, इससे प्रासंगिक ऐतिहासिक डेटा को नहीं हटाना। ध्वस्त डेटाबेस में अपेक्षाकृत छोटे परिचालन अवधि के लिए केवल डेटा होते हैं, आमतौर पर यह 1-2 साल से अधिक नहीं होता है। जाहिर है, प्रत्येक मामले में कमी की डिग्री अलग है, और किसी भी विशिष्ट संख्या को नाम देना मुश्किल है। और फिर भी, एक दिशानिर्देश के लिए, हम आधार में 50-70% की कमी का एक संकेतक लेंगे, अर्थात, लगभग 2-3 बार, एक ही राशि के बारे में सबसे अधिक बार और यह व्यवहार में निकला, कम या इसके विपरीत अधिक - यह दुर्लभ है।

हम परिणामी जीत पर ध्यान केन्द्रित नहीं करेंगे। जाहिर है, यदि आधार 2-3 या अधिक बार कम हो जाता है, तो प्रदर्शन प्रभाव बहुत शक्तिशाली और दीर्घकालिक होगा, और हार्डवेयर घटक में अतिरिक्त निवेश से बचा जा सकता है। और एक बार विकसित और रन-इन, कन्वेंशन तंत्र, भविष्य में पुन: उपयोग किया जा सकता है। सामान्य तौर पर, गारंटीकृत परिणामों के साथ यह एक शानदार प्रभावी उपाय है।

दृढ़ संकल्प कार्यान्वयन की जटिलता

लेकिन इसकी सभी प्रभावशीलता के लिए, दृढ़ संकल्प में एक बहुत बड़ी समस्या है। और यह स्वयं कनवल्शन मैकेनिज्म को विकसित करने की बात भी नहीं है। हां, यह विकास भी एक मुश्किल काम है, लेकिन इसे किसी तरह हल किया जाता है। बात अलग है। जब डेटाबेस में कई सौ गीगाबाइट का आकार होता है या टेराबाइट लाइन को पार कर जाता है, तो यह पता चलता है कि तह ऑपरेशन करना केवल शारीरिक रूप से बहुत मुश्किल है। अनिवार्य रूप से, परस्पर कठिनाइयों का एक पूरा परिसर उत्पन्न होता है, आइए हम उन पर विचार करें।

• तह संचालन की संसाधन तीव्रता - उपकरण भारी रूप से भरा हुआ है।
  
  • सजा के दौरान, न केवल डेटा का एक बड़ा सरणी भौतिक रूप से हटा दिया जाता है, बल्कि संबंधित संसाधन-गहन संचालन भी बहुत सारे किए जाते हैं: विभिन्न चयन, चेक, ग्रुपिंग, इंडेक्सिंग, लॉगिंग, टेबल के बीच डेटा को स्थानांतरित करना आदि। यह तथ्य विशेष रूप से महत्वपूर्ण है क्योंकि बंधनेवाला डेटाबेस, एक नियम के रूप में, पहले से ही भारी भरा हुआ है, और इसमें अधिक क्षमता नहीं है।
• उपयोगकर्ताओं के लिए हस्तक्षेप।
  
  • कनवल्शन प्रक्रिया द्वारा बनाए गए उच्च अतिरिक्त लोड और लॉक्स के कारण उपयोगकर्ता के कार्य के समानांतर कार्यशील डेटाबेस में सीधे कन्वेंशन करना अत्यंत कठिन या असंभव है।
• कोई तकनीकी खिड़की नहीं है।
  
  • पर्याप्त अवधि की एक तकनीकी विंडो, जब उपयोगकर्ता काम नहीं करते हैं, बस दृढ़ संकल्प के लिए उपलब्ध नहीं है। आखिरकार, इस आकार के डेटाबेस के लिए तह प्रक्रिया आमतौर पर दसियों घंटे या कई दिनों की होती है।
• काम के आधार पर सीधे तह करते समय उच्च जोखिम।
  
  • दृष्टिकोण, जब कनवल्शन एल्गोरिथ्म को सीधे कार्यशील आधार पर लागू किया जाता है, कई कारणों से स्वयं अत्यधिक जोखिम भरा होता है। उनमें से एक - सजा के परिणामों के अंतिम सत्यापन के लिए संभावनाएं बहुत सीमित हैं (कोई समय नहीं)।
• एक पुनरावृत्त दृष्टिकोण की अस्वीकार्य अवधि।
  
  • आप एक अड़चन से बचने की कोशिश कर सकते हैं - एक तकनीकी खिड़की, और उत्पादक आधार में सीधे छोटे भागों में पुनरावृत्ति का प्रदर्शन करें, प्रत्येक भाग के आकार का चयन करें ताकि यह मौजूदा तकनीकी खिड़कियों में फिट हो। लेकिन यह पथ भी सबसे अधिक बार लागू नहीं होता है, क्योंकि, सबसे पहले, ट्रिमिंग प्रक्रिया एक अस्वीकार्य रूप से लंबी अवधि (कई सप्ताह या महीने) तक फैलती है, और दूसरी बात, तह तंत्र की जटिलता बढ़ जाती है, इतने लंबे समय तक निर्बाध ट्रिमिंग प्रक्रिया सुनिश्चित करने की कुल लागत। समग्र रूप से परियोजना के जोखिम मौलिक रूप से बढ़ रहे हैं।
• डेटा फ़ाइल में voids को कैसे संपीड़ित करें?!
  
  • डेटाबेस से ऐतिहासिक जानकारी को हटाने के दौरान, इसकी डेटा फ़ाइल वास्तव में घटती नहीं है (और अक्सर थोड़ा बढ़ जाती है), यह बस इसके साथ बहुत बड़ी गड़बड़ी पैदा करता है। और आपको किसी तरह उनसे छुटकारा पाने की आवश्यकता है ताकि डेटा फ़ाइल कम हो जाए। अन्यथा, डिस्क स्थान के संदर्भ में लाभ खो जाता है। एक विकल्प एक ठेठ SHRINK निष्पादित करना है। और ऐसे संस्करणों पर यह बहुत लंबी प्रक्रिया है (कई घंटे, या दसियों घंटे भी)।

इस प्रकार, दृढ़ संकल्प एक बहुत ही गैर-तुच्छ कार्य है। यह एक कन्वेंशन तंत्र विकसित करने के लिए पर्याप्त नहीं है, इसे भी लागू करने की आवश्यकता है। इसके अलावा, आवेदन अक्सर एक अड़चन बन जाता है।

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

समाधान का उपयोग कर समाधान

यह एक मृत अंत प्रतीत होगा। लेकिन अभी भी समाधान हैं। एक प्रभावी तकनीक है जो आपको कठिनाइयों की पूरी उलझन को उजागर करने, जोखिमों को दूर करने और लक्ष्य प्राप्त करने की गारंटी देती है। इसमें DBREPLICATION डेटा विनिमय तकनीक का उपयोग शामिल है। समाधान पारंपरिक बुनियादी ढाँचे के विकल्प और क्लाउड-आधारित Microsoft Azure दोनों के लिए उपयुक्त है। संक्षेप में, सार इस प्रकार है।

• डेटाबेस का एक क्लोन बनाया जाता है, क्लोन और मुख्य डेटाबेस के बीच एक तरफा डेटा विनिमय DBREPLICATION का उपयोग करके कॉन्फ़िगर किया गया है। यह अनुमति दी जाती है कि मुख्य डेटाबेस और / या इसका क्लोन Microsoft Azure क्लाउड में (दोनों या उनमें से एक) स्थित हैं।
• क्लोन में, उपयोगकर्ता काम नहीं करते हैं, वहां सजा प्रक्रिया शुरू होती है। चूंकि तह प्रक्रिया किसी को परेशान नहीं करती है, इसलिए यह पूरे दिन बिना किसी रुकावट के चल सकती है। इस प्रकार, तकनीकी विंडो की अवधि के लिए लिंक गायब हो जाता है!
• बिना हस्तक्षेप के उपयोगकर्ता मुख्य डेटाबेस में काम करते हैं। और DBREPLICATION तकनीक मुख्य डेटाबेस से सभी परिवर्तनों को स्वचालित रूप से उच्च गति पर ढहने वाले तक स्थानांतरित करती है। इस प्रकार, परिचालन डेटा के संदर्भ में क्लोन अप टू डेट है।
• सजा के पूरा होने के बाद, एक नियम के रूप में, परिणाम का एक विस्तृत सत्यापन ग्राहक के तकनीकी विशेषज्ञों और व्यावसायिक उपयोगकर्ताओं की भागीदारी के साथ किया जाता है। और यह प्रक्रिया काफी लंबे समय (कई घंटे या दिन) तक चल सकती है। विचाराधीन कार्यप्रणाली में, व्यावहारिक रूप से कोई समय सीमा नहीं है, इसलिए, सत्यापन को आवश्यक समय के रूप में आवंटित किया जा सकता है।
• दृढ़ संकल्प और सत्यापन पूरा होने के बाद, सभी उपयोगकर्ता बंद किए गए क्लोन पर स्विच करते हैं, और उसी क्षण से यह मुख्य आधार बन जाता है। और मूल खतनारहित आधार ऐतिहासिक डेटा के संग्रह के रूप में कार्य करता है।
  
  • एक अतिरिक्त लाभ विपरीत दिशा में प्रतिकृति स्विच करने की क्षमता है जब उपयोगकर्ता न्यूनतम डेटाबेस पर स्विच करते हैं। यह अतिरिक्त सुरक्षा प्रदान करता है, क्योंकि यदि "कुछ गलत हो जाता है", तो आप दर्ज किए गए डेटा को खोए बिना उपयोगकर्ताओं को जल्दी से बिना डेटाबेस के वापस स्विच कर सकते हैं।
• यदि संग्रह डेटाबेस को अद्यतित रखने की आवश्यकता है, तो आप विपरीत दिशा में प्रतिकृति स्विच कर सकते हैं और न्यूनतम डेटाबेस से संग्रह एक में परिवर्तन स्थानांतरित कर सकते हैं।

चित्र 1। DBREPLICATION तकनीक का उपयोग करके डेटाबेस ट्रिमिंग का योजनाबद्ध आरेख।

अंजीर। २। एमएस एज़्योर क्लाउड में बंधनेवाला डेटाबेस को होस्ट करने का विकल्प।

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

यह समझा जाना शेष है कि इस योजना में किस विनिमय तकनीक का उपयोग किया जा सकता है? DBReplication क्यों?

DBReplication क्यों?

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

• व्यापार एप्लिकेशन प्लेटफॉर्म के साथ संगतता, जिसका आधार ढह रहा है।

उदाहरण: यदि हम 1 सी डेटाबेस को ध्वस्त करते हैं, तो प्रत्येक विनिमय प्रौद्योगिकी 1 सी आधार संरचना के साथ संगत नहीं है, विशेष रूप से, क्लासिक एमएस लेनदेन प्रतिकृति संगत नहीं है, क्योंकि यह तालिका संरचना में परिवर्तन करता है।

• प्रदर्शन। सजा के दौरान काम करने के आधार में होने वाले परिवर्तनों के प्रवाह से निपटने के लिए एक्सचेंज तकनीक की गारंटी होनी चाहिए।

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

• समस्या की स्थितियों के लिए प्रमुख प्रयोज्यता।

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

इसके अलावा, विनिमय प्रौद्योगिकी अन्य संकेतकों के संदर्भ में प्रभावी होनी चाहिए:

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

इन गुणों के बिना, विनिमय तकनीक कार्यप्रणाली के एक महत्वपूर्ण तत्व को अपने "कमजोर लिंक" में बदलने की धमकी देती है, गंभीर जोखिमों का परिचय देती है और पूरे प्रोजेक्ट को धमकी देती है। और फिर मूल विचार अपना अर्थ खो देता है।

हालांकि, DBReplication तकनीक निश्चित रूप से सभी आवश्यकताओं को पूरा करती है और रोलअप परियोजना की सफलता सुनिश्चित करती है।

इस कार्य में DBReplication सफल होने के कारण मुख्य कारकों पर ध्यान दें:

• बहुत अधिक विनिमय दर। गति प्रदान करने वाली कुछ विशेषताओं पर ध्यान दें:
  
  • DBReplication एक लेन-देन प्रतिकृति है, प्रत्येक परिवर्तन लेन-देन के प्रतिबद्ध होने के तुरंत बाद प्रसारित होना शुरू होता है;
  • परिवहन सबसिस्टम की आंतरिक वास्तुकला ऐसे समाधानों का उपयोग करती है जैसे कतारों के बहु-थ्रेडेड समानांतर प्रसंस्करण, एक पाइपलाइड दृष्टिकोण, स्ट्रीम संपीड़न, बैच लेनदेन प्रसंस्करण, बल्क इंसर्ट और अन्य का उपयोग।
• विंडोज सेवाओं के आधार पर लागू किया गया परिवहन, सुचारू संचालन सुनिश्चित करने के लिए कई सुविधाओं से लैस है। इनमें शामिल हैं: संचार में रुकावट के बाद स्वचालित विनिमय वसूली, कमजोर अस्थिर संचार चैनलों पर काम करना, संस्करण संघर्षों का स्वचालित प्रसंस्करण (दो तरफा विनिमय के लिए), एक व्यावसायिक अनुप्रयोग की तालिकाओं की संरचना में परिवर्तन के मामले में स्वत: अनुकूलन और अन्य।
• डेटा वितरण तंत्र की गारंटी। परिवर्तनों को स्थानांतरित करने के लिए लेन-देन की अखंडता और स्थिरता का सख्त पालन।
• व्यापार एप्लिकेशन की तालिका संरचना को संशोधित नहीं करता है। इसलिए, विशेष रूप से, 1 सी डेटाबेस को तह करते समय इसका सफलतापूर्वक उपयोग किया जा सकता है।
• विकसित उपयोगकर्ता इंटरफ़ेस जो आपको "एक खिड़की से" एक्सचेंज सिस्टम को केंद्रीय रूप से प्रबंधित करने की अनुमति देता है, सभी सेवा जानकारी एकत्र की जाती है और ऑनलाइन प्रदर्शित की जाती है।
• तैनात करने और कॉन्फ़िगर करने में आसान।
• 1 सी प्लेटफॉर्म के लिए अनुकूलित। उपयोगकर्ता तालिकाओं के साथ काम नहीं करता है, लेकिन परिचित 1C मेटाडेटा ऑब्जेक्ट्स के साथ।
• एमएस एसक्यूएल का कोई भी संस्करण, 2005 से शुरू, मानक से उद्यम तक, दोनों स्थानीय रूप से तैनात और एमएस एज़्योर के बादल में स्थित हैं; Azure बिंदु से, वर्चुअल मशीन होस्टिंग और Azure SQL DB होस्टिंग विकल्प दोनों की अनुमति है, जिसमें Azure SQL डेटाबेस ( प्रबंधित इंस्टेंस ) का एक प्रबंधित उदाहरण शामिल है ।
• DBReplication एक तैयार-विश्वसनीय विश्वसनीय समाधान है जिसे कई परियोजनाओं द्वारा विभिन्न स्थितियों और कार्यों में परीक्षण किया गया है।
• यदि एक-तरफ़ा विनिमय मोड में DBREPLICATION का उपयोग किया जाता है, तो विनिमय दिशा बदली जा सकती है।

इसके अलावा, हम एक और महत्वपूर्ण विशेषता पर ध्यान दें:

• DBREPLICATION दो तरह से एक्सचेंज मोड में काम कर सकता है, जब एक्सचेंज में भाग लेने वाले सभी डेटाबेस में एक साथ डेटा दर्ज / बदलना संभव है। एक्सचेंज सर्किट में शामिल किए जा सकने वाले ठिकानों की संख्या सीमित नहीं है।

व्यावहारिक अनुप्रयोग उदाहरण

एक बड़ी रूसी कंपनी के पास 1C 8 + MS SQL सर्वर प्लेटफॉर्म पर आधारित एक एप्लीकेशन अकाउंटिंग सिस्टम है। मुख्य परिचालन आधार ने लंबे समय तक 2 टेराबाइट्स पर कदम रखा है और आगे बढ़ना जारी है। इसी समय, लोड अधिक से अधिक बढ़ रहा है: दोनों लेनदेन और विश्लेषणात्मक। अंत में, आधार की पुष्टि के लिए कई कारणों का गठन किया गया था। 2017 की शुरुआत के लिए ऐतिहासिक डेटा को ट्रिम करने का निर्णय लिया गया था। DBReplication का उपयोग करके यहां वर्णित तकनीक का चयन किया गया था।

अपने आप में, कन्वेंशन एल्गोरिथ्म को मुख्य रूप से टीएसक्यूएल द्वारा लागू करने का निर्णय लिया गया था, जिसमें विशिष्ट 1 सी टूल के छोटे समावेश थे। कार्य इस तथ्य से जटिल था कि सभी लागू वस्तुओं (तालिकाओं) को अपेक्षित तिथि तक नहीं गिराया जा सकता था, क्योंकि व्यावसायिक सुविधाओं की आवश्यकता थी कि सबसे बड़े उप-प्रणालियों की संख्या में ऐतिहासिक डेटा 5-7 साल की गहराई तक पूर्ण रूप से मौजूद हो। इसलिए, डेटाबेस की मात्रा के दृष्टिकोण से, कनवल्शन का प्रभाव उतना बड़ा नहीं था जितना हम चाहेंगे। एक प्रारंभिक विश्लेषण किया गया, जिसमें पता चला कि, उद्देश्य संबंधी प्रतिबंधों को ध्यान में रखते हुए, प्रारंभिक मात्रा का लगभग 33% काटा जाएगा। लेकिन इसका मूल्यांकन ग्राहक द्वारा एक अच्छे परिणाम के रूप में किया गया था, क्योंकि लाभ केवल डेटाबेस की मात्रा में ही नहीं है, बल्कि व्यक्तिगत तालिकाओं की गति में भी है, और ध्वस्त उपप्रणाली की सारणी मात्रा में 33% से घटकर - 46% से 77% (2- में) हो गई है। 3 बार)।

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

परियोजना सारांश:

• लागू तकनीक ने पूरी तरह से भुगतान किया, इसके लिए धन्यवाद स्वयं को पूरा करने के लिए पर्याप्त समय था, साथ ही साथ डेटा को व्यापक रूप से सत्यापित करने के लिए, जिसने मौलिक रूप से कुछ त्रुटियों को छोड़ने और ढह गए डेटाबेस पर स्विच करने के जोखिमों को कम से कम किया।
• वार्तालाप सफलतापूर्वक पूरा हुआ:
  
  • परिचालन डेटाबेस की कुल मात्रा में 33% की कमी हुई। कुछ बड़े उपप्रणालियों के तह पर प्रतिबंध के कारण, उद्देश्य कारणों से डेटाबेस की मात्रा पर अधिक प्रभाव प्राप्त करना संभव नहीं था।
  • ध्वस्त उप-प्रणालियों के सक्रिय रूप से उपयोग की जाने वाली तालिकाओं की मात्रा में 46-77% (2-3 बार) की कमी हुई।
  
  

निष्कर्ष

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

आप किन अन्य कार्यों के लिए DBREPLICATION का उपयोग कर सकते हैं

सुविधाओं और प्रतिस्पर्धी लाभों का एक सेट कई समस्याओं को हल करने के लिए DBReplication का उपयोग करने की अनुमति देता है। संदर्भ के लिए, हम उन्हें सूचीबद्ध करते हैं।

• डेटाबेस अतिरेक और गलती सहिष्णुता।
• भार संतुलन: इसे 2 या अधिक तुल्यकालिक डेटाबेस इंस्टेंस के बीच पुनर्वितरित करना।
• नए सॉफ्टवेयर संस्करणों (MS SQL, 1C) के लिए नियंत्रित संक्रमण, तकनीक कनवल्शन तकनीक के समान है।
• DBReplication के आधार पर उच्च गति विनिमय के साथ एक वितरित सूचना प्रणाली का निर्माण। विशेष रूप से, मौजूदा कंपनी विनिमय प्रौद्योगिकी को अधिक उत्पादक और कुशल - DBREPLICATION के साथ प्रतिस्थापित करना।