स्टैंडबाय डीबी का पुनर्निर्माण करें

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

हम आम तौर पर संग्रहीत फिर से लॉग को 7 दिनों के लिए रखते हैं। दुर्भाग्य से, जब तक मुझे इस स्थिति का पता चला, तब तक 15 दिन बीत चुके थे और संग्रहीत रीडो लॉग "गायब" थे। लागू करने के लिए कोई संग्रहीत फिर से लॉग नहीं होने के कारण, डेटाबेस को खरोंच से पुनर्निर्माण करने का एकमात्र समाधान था। यह डेटाबेस लगभग 7TB आकार का है, इसलिए खरोंच से पुनर्निर्माण करना कोई मामूली मामला नहीं है।

प्राथमिक एक 3-नोड RAC 11.2.0.2 डेटाबेस है जो Linux पर चल रहा है। स्टैंडबाय एक दो-नोड आरएसी डेटाबेस है, जाहिर तौर पर वही ओरेकल और ओएस संस्करण।

यहां बताया गया है कि हमने स्टैंडबाय का पुनर्निर्माण कैसे किया:

हमने प्राथमिक को हॉट बैकअप मोड में रखा और डेटाबेस का डिस्क-आधारित स्नैपशॉट लिया।
स्नैपशॉट को बाहरी मीडिया में कॉपी किया गया था। नोट:WAN से शिपिंग में बहुत समय लगता था।
बाहरी मीडिया को DR साइट पर ले जाया गया।
स्टैंडबाय के लिए LOG_ARCHIVE_DEST_STATE_n को DEFER पर सेट किया गया था।
स्टैंडबाय डेटाबेस को डीजी ब्रोकर कॉन्फ़िगरेशन से हटा दिया गया था: डेटाबेस स्टैंडबाय संरक्षित स्थलों को हटा दें;
स्टैंडबाय डेटाबेस के माउंट पॉइंट मिटा दिए गए थे। आखिरकार, इस बिंदु पर डेटाबेस अनिवार्य रूप से बेकार था।
नए माउंट पॉइंट बनाए गए और स्नैपशॉट को DR साइट पर डिस्क पर लिखा गया।
फ़ाइल स्थानांतरण पूर्ण होने के बाद (लगभग 5 दिन), हमने अपने संग्रहण को DR साइट पर स्नैपशॉट को अधिक वर्तमान स्नैपशॉट के साथ अपडेट करने के लिए कहा। यह WAN पर किया गया था क्योंकि केवल परिवर्तन भेजे गए थे, जो कि डेटाबेस से बहुत छोटा था।
एक स्टैंडबाय कंट्रोलफाइल बनाया गया था: वैकल्पिक डेटाबेस '/dir/path' के रूप में स्टैंडबाय नियंत्रण बनाएं;
चीजों को सरल रखने के लिए, हम एक एकल-आवृत्ति स्टैंडबाय का उपयोग तब तक करना चाहते थे जब तक कि हम इसे उठाकर चालू नहीं कर देते। इसलिए हमने स्टैंडबाय के RAC SPFILE से एक PFILE बनाया और फिर किसी भी RAC-जागरूक पैरामीटर को हटाने के लिए पैरामीटर फ़ाइल को संशोधित करने के लिए एक टेक्स्ट एडिटर का उपयोग किया। हमने CLUSTER_DATABASE को हटा दिया है, एक उदाहरण-विशिष्ट UNDO_TABLESPACE पैरामीटर सेट किया है जिसका उपयोग सभी उदाहरणों "*" के लिए किया जाएगा, THREAD पैरामीटर को हटा दिया जाएगा, आदि। हमारे सामान्य स्टैंडबाय डेटाबेस में दो उदाहरण हैं, STANDBY1 और STANDBY2। नोड 1 में, हम pfile को initstandby1.ora के बजाय $ORACLE_HOME/dbs/initstandby.ora में डालते हैं ताकि एकल-आवृत्ति डेटाबेस इसकी पैरामीटर फ़ाइल ढूंढ सके। पासवर्ड फ़ाइल के लिए हमने कुछ ऐसा ही किया।
हमने डेटाबेस स्नैपशॉट में नियंत्रण फ़ाइलों पर चरण 9 से स्टैंडबाय नियंत्रण फ़ाइल की प्रतिलिपि बनाई।
एक उदाहरण डेटाबेस के लिए pfile और pswd फ़ाइल के साथ, हमने STARTUP MOUNT किया।
हमने कोई भी स्टैंडबाय रीडो लॉग बनाया जिसकी हमें आवश्यकता होगी। हमारे मामले में, प्राथमिक में स्विचओवर संचालन की सुविधा के लिए स्टैंडबाय रीडो लॉग भी हैं और प्राथमिक से स्टैंडबाय रीडो लॉग स्नैपशॉट का हिस्सा नहीं थे। इसलिए हमें उन SRL को हटाना पड़ा जिन्होंने यात्रा नहीं की।
प्राथमिक में, LOG_ARCHIVE_DEST_STATE_n को ENABLE पर सेट करें।
प्राथमिक उदाहरणों में, ALTER SYSTEM SWITCH LOGFILE का प्रदर्शन किया;
प्राथमिक और स्टैंडबाय दोनों के अलर्ट लॉग में सत्यापित किया गया कि स्टैंडबाय लॉग प्राप्त कर रहा था, यानी सत्यापित किया गया कि लॉग ट्रांसपोर्ट काम कर रहा था।
प्रबंधित स्टैंडबाय चालू किया गया:वैकल्पिक डेटाबेस पुनर्प्राप्ति प्रबंधित स्टैंडबाय डेटाबेस सत्र से डिस्कनेक्ट;
स्टैंडबाय के अलर्ट लॉग में सत्यापित किया गया कि लॉग लागू किए जा रहे थे, यानी सत्यापित आवेदन अब काम कर रहा था।

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

srvctl डेटाबेस शुरू करें -d स्टैंडबाय -o माउंट

इस बिंदु पर केवल एक चीज बची थी, वह थी डीजी ब्रोकर कॉन्फ़िगरेशन (डीजीएमजीआरएल में) में स्टैंडबाय को वापस जोड़ना: डेटाबेस स्टैंडबाय जोड़ें

जब यह पहली बार हुआ था, तो मैं घबरा गया था कि यह इतना बड़ा डेटाबेस कैसे होगा। उपरोक्त में से कोई भी ऑपरेशन मीडिया में और से फ़ाइलों की प्रतिलिपि बनाने के अलावा आकार-निर्भर नहीं है। लेकिन सब ठीक हो गया।

यह सुनिश्चित करने के लिए कि हम भविष्य में इस स्थिति में न आएं, हमने अपने Oracle एंटरप्राइज मैनेजर ग्रिड कंट्रोल में अलर्ट जोड़ा। लॉग शिपिंग या लॉग लागू होने के 12 घंटे पीछे होने पर और 24 घंटे पीछे होने पर एक क्रिटिकल अलर्ट होने पर मुझे अब एक चेतावनी अलर्ट प्राप्त होगा। इससे हमें किसी भी समस्या को ठीक करने के लिए पर्याप्त समय देना चाहिए, इससे पहले कि संग्रहीत फिर से लॉग 7 दिनों के बाद स्वचालित रूप से हटा दिए जाएं, या बहुत कम से कम, संग्रहीत रीडो लॉग के अधिक दिनों के लायक रखने के लिए प्रक्रिया को तब तक बदलें जब तक कि हम स्थिति को ठीक नहीं कर लेते।