हाल ही में एक स्टैंडबाय डेटाबेस पर काम करते समय, मैं स्थिति की जांच करने के लिए डीजी ब्रोकर के पास गया और इसे प्राप्त किया:
DGMGRL> show configuration Configuration - resp_ress_config Protection Mode: MaxPerformance Databases: resp - Primary database ress - Physical standby database Error: ORA-16766: Redo Apply is stopped
हम्म...मेरा स्टैंडबाय फिर से लागू नहीं कर रहा है। जब मैंने प्रबंधित पुनर्प्राप्ति प्रारंभ करने का प्रयास किया, तो मुझे स्टैंडबाय अलर्ट लॉग में निम्न मिला:
Tue Dec 31 09:52:10 2013 Managed Standby Recovery starting Real Time Apply Tue Dec 31 09:52:10 2013 MRP0: Background Media Recovery terminated with error 38868 Errors in file /u01/app/oracle/diag/rdbms/ress/ress2/trace/ress2_pr00_13905.trc: ORA-38868: warning: the control file may have incorrect data file structure Managed Standby Recovery not using Real Time Apply Slave exiting with ORA-38868 exception Errors in file /u01/app/oracle/diag/rdbms/ress/ress2/trace/ress2_pr00_13905.trc: ORA-38868: warning: the control file may have incorrect data file structure Recovery Slave PR00 previously exited with exception 38868 MRP0: Background Media Recovery process shutdown (ress2)
तो ORA-38868 मुझे बता रहा है कि मेरे पास एक खराब निर्देशिका संरचना है। मेरा पहला विचार यह था कि यह उस कार्य से संबंधित था जिसके बारे में मैंने कल ब्लॉग किया था। लेकिन वह काम प्राथमिक स्तर पर था। मैंने स्टैंडबाय अलर्ट लॉग को देखा और लगभग 2.5 महीने पहले इस त्रुटि की पहली घटना पाई। यदि यह एक उत्पादन प्रणाली होती, तो मैं इस मुद्दे को उस अवधि के लिए किसी का ध्यान नहीं जाने देने में बड़ी परेशानी में पड़ सकता था। लेकिन अगर मेरा प्रोडक्शन स्टैंडबाय समय की अस्वीकार्य अवधि के लिए प्राथमिक से पीछे रह जाता है, तो मुझे सचेत करने के लिए मेरे पास उपाय हैं। यह सिर्फ एक परीक्षण प्रणाली है जिसे मैं उड़ा सकता हूं और जरूरत पड़ने पर खरोंच से शुरू कर सकता हूं। लेकिन क्या मजा होगा? देखते हैं कि क्या हम समस्या को ठीक कर सकते हैं।
मेरा पहला पड़ाव मेटलिंक था। लेकिन मुझे ORA-38868 त्रुटि के लिए शून्य हिट मिली। वेब खोज करते समय, मुझे एक प्रासंगिक हिट मिली, जिसने उदाहरण को फिर से शुरू करने और फिर से लागू करने के लिए फिर से शुरू करने का एक समाधान पेश किया। मुझे संदेह हुआ, लेकिन आसान सुधार का प्रयास किया। इसमें कोई आश्चर्य की बात नहीं है कि उदाहरण के एक साधारण पुनरारंभ ने समस्या को ठीक नहीं किया। त्रुटि मुझे बता रही है कि मेरी नियंत्रण फ़ाइल में भ्रष्टाचार है। इंस्टेंस को पुनरारंभ करने से नियंत्रण फ़ाइल भ्रष्टाचार ठीक नहीं होगा। चूंकि मेटलिंक और इंटरनेट किसी काम के नहीं हैं, मुझे लगता है कि इसे ठीक करना मेरे ऊपर है। अगर बाकी सब विफल हो जाता है, तो मैं बस स्टैंडबाय छोड़ दूंगा और इसे फिर से बना दूंगा।
मेरा प्रारंभिक समाधान प्राथमिक पर वापस जाना और स्टैंडबाय नियंत्रण फ़ाइल बनाना है। फिर स्टैंडबाय कंट्रोल फाइल के साथ स्टैंडबाय को स्टार्टअप करें। मुझे विश्वास है कि प्राथमिक से एक नई नियंत्रण फ़ाइल समस्या का समाधान करेगी। हालांकि, मुझे 2.5 महीने का फिर से आवेदन करना होगा, जिसमें से अब मेरे पास उपलब्ध नहीं है।
मैं एक वृद्धिशील बैकअप के माध्यम से स्टैंडबाय को आगे बढ़ाने के लिए आरएमएएन का उपयोग करके जांच करने की कोशिश कर रहा हूं। लेकिन ऐसा लगता है कि यह मेरी प्राथमिकताओं की सूची में कम है। मेरे पास एक आगामी परियोजना है जहां मुझे यह जानना होगा कि यह कैसे करना है और वह परियोजना अब एक महीने से भी कम दूर है। तो यह मेरी आगामी परियोजना के लिए इस तकनीक का अभ्यास करने और मेरे वर्तमान मुद्दे को ठीक करने का एक सही समय प्रतीत होता है। ऐसा करने के चरण इस प्रकार हैं:
Metalink Note 836986.1 Steps to Perform for Rolling Forward a Standby Database Using RMAN Incremental Backups
इस दस्तावेज़ के चरणों ने न केवल मेरे स्टैंडबाय को आगे बढ़ाया, बल्कि नियंत्रण फ़ाइलों को भी फिर से बनाया, इस प्रकार मेरी समस्या को ठीक किया।
