मैं मौजूदा 3-नोड आरएसी क्लस्टर के लिए हार्डवेयर को बदलने की प्रक्रिया में हूं। यह सिस्टम 2-नोड RAC स्टैंडबाय डेटाबेस के लिए भी प्राथमिक है। हार्डवेयर को बदलने के लिए, मेरी योजना अस्थायी रूप से क्लस्टर को 6-नोड कॉन्फ़िगरेशन, 3 पुराने सर्वर और 3 नए सर्वर में विस्तारित करने की है। एक बार जब मेरे पास नए हार्डवेयर पर इंस्टेंस चल रहे हैं और मेरे एप्लिकेशन नए इंस्टेंस से कनेक्ट हो रहे हैं, तो मैं पुराने इंस्टेंस को हटा दूंगा और पुराने सर्वर को रिटायर कर दूंगा, 3-नोड कॉन्फ़िगरेशन पर वापस आऊंगा।
क्लस्टर को सभी छह नोड्स में विस्तारित करने के बाद, पिछले सप्ताहांत में मैंने नए नोड्स पर नए उदाहरण शुरू किए। अपने जीवन को आसान बनाने के लिए, मैंने इस काम के लिए DBCA का लाभ उठाया। DBCA शुरू करने के बाद, मैंने RAC डेटाबेस पर काम करना चुना, और फिर इंस्टेंस मैनेजमेंट और फिर Add New Instance को चुना। विज़ार्ड के माध्यम से चलते हुए मैंने डीबीसीए को मेरे लिए सभी विवरणों का ध्यान रखने दिया। आसान लगता है।
आज सुबह, मुझे मेरी सामान्य संग्रह अंतराल रिपोर्ट मिली। यह निम्न के जैसा दिखता है:
INSTANCE_NAME APPLY_LAG CURR_TIME
---------------- -------------------- -------------------
orcs1 +01 21:40:47 2012-12-03 08:00:01
मैं इसे दिन में दो बार अपने इनबॉक्स में भेजता हूं। एक त्वरित नज़र मुझे यह निर्धारित करने में मदद करती है कि क्या मेरा स्टैंडबाय प्राथमिक से लेनदेन प्राप्त कर रहा है और लागू कर रहा है। मैंने अपने सभी स्टैंडबाय डेटाबेस को चार घंटे की देरी से लागू करने के लिए सेट कर दिया है। और मेरे प्राथमिक में ARCHIVE_LAG_TARGET एक घंटे पर सेट है। इसका मतलब है कि आवेदन में देरी कम से कम 4 घंटे होगी लेकिन 5 घंटे से अधिक नहीं होनी चाहिए। जैसा कि हम ऊपर देख सकते हैं, हमारे पास दो स्टैंडबाय डेटाबेस हैं जो 5 घंटे के अधिकतम लागू अंतराल से बहुत अधिक हो गए हैं। ऊपर, मेरे पास 1 दिन 21 घंटे के लागू अंतराल के साथ स्टैंडबाय है! तो मुझे तुरंत पता चल गया कि कुछ गड़बड़ है। और एक रॉकेट वैज्ञानिक को यह जानने की ज़रूरत नहीं पड़ी कि प्राथमिक में नए उदाहरण को जोड़ने से शायद समस्या में योगदान हुआ है।
जैसा कि मैंने इस पोस्ट की शुरुआत में कहा था, मेरे पास 2-नोड RAC स्टैंडबाय सिस्टम है। एक उदाहरण "उदाहरण लागू करें" है और दूसरा उदाहरण वहां अपेक्षाकृत निष्क्रिय है। मेरे लागू इंस्टेंस अलर्ट लॉग में, मैंने निम्न त्रुटि संदेश देखे:
Sat Dec 01 14:25:40 2012
Recovery created file /u01/app/oracle/oradata/orcl/data04/undotbs04.dbf
Successfully added datafile 342 to media recovery
Datafile #342: '/u01/app/oracle/oradata/orcl/data04/undotbs04.dbf'
No OMF destination specified, unable to create logs
Errors with log /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
MRP0: Background Media Recovery terminated with error 1264
Errors in file /u01/app/oracle/diag/rdbms/orcs/orcs2/trace/orcs2_pr00_29759.trc:
ORA-01264: Unable to create logfile file name
Recovery interrupted!
Sat Dec 01 14:25:51 2012
Recovered data files to a consistent state at change 192271576009
Sat Dec 01 14:25:51 2012
MRP0: Background Media Recovery process shutdown (orcs2)
चूंकि मेरा स्टैंडबाय डेटाबेस STANDBY_FILE_MANAGEMENT=AUTO पर सेट है, इसलिए संदेशों का पहला भाग समझ में आता है। जब आप आरएसी डेटाबेस में एक नया इंस्टेंस जोड़ते हैं, तो आपको उस इंस्टेंस के लिए पूर्ववत टेबलस्पेस प्रदान करना होगा और आपको उस इंस्टेंस के थ्रेड को समर्पित ऑनलाइन रीडो लॉग समूह भी प्रदान करना होगा। DBCA ने विशेष रूप से मुझसे फ़ाइल संरचना को पूर्ववत करने और फिर से करने से संबंधित प्रश्न पूछे। उपरोक्त अलर्ट लॉग सामग्री में, हम देख सकते हैं कि स्टैंडबाय ने सफलतापूर्वक डेटाफाइल 342 जोड़ा, जो कि मेरा पूर्ववत टेबलस्पेस है। लेकिन स्टैंडबाय ऑनलाइन रीडो लॉग्स को जोड़ने में असमर्थ था। यदि आप चाहते हैं कि स्टैंडबाय स्वचालित रूप से ऑनलाइन फिर से लॉग को जोड़ने में सक्षम हो, तो आपको ओएमएफ पैरामीटर निर्दिष्ट करने की आवश्यकता है, जो मैं करने के लिए अनिच्छुक हूं। चूंकि ऑनलाइन पुन:लॉग फ़ाइल जोड़ने के परिणामस्वरूप त्रुटि हुई, स्टैंडबाय ने मीडिया पुनर्प्राप्ति को रोक दिया। स्टैंडबाय को अभी भी लॉग मिल रहे हैं।
मुझे मेटलिंक पर या इस मुद्दे को हल करने के लिए Google खोजों पर बहुत कुछ नहीं मिला, लेकिन यहां वे कदम हैं जो मैंने मीडिया रिकवरी को वापस लाने और चलाने के लिए उठाए। स्टैंडबाय डेटाबेस पर (मैंने इसे लागू उदाहरण पर किया था लेकिन यह आरएसी स्टैंडबाय डेटाबेस में किसी भी उदाहरण पर व्यवहार्य होना चाहिए):
1. alter database recover managed standby database cancel;
alter database recover managed standby database cancel
*
ERROR at line 1:
ORA-16136: Managed Standby Recovery not active
यह एक सदमा नहीं होना चाहिए क्योंकि हम जानते हैं कि प्रबंधित पुनर्प्राप्ति निरस्त हो गई है। लेकिन पूर्णता के लिए, मैंने इस चरण को शामिल किया। यदि आपको एक स्टैंडबाय में फिर से लॉग जोड़ना है जो वर्तमान में लेनदेन लागू कर रहा है, तो आपको इस चरण की आवश्यकता होगी।
2. alter system set standby_file_management='MANUAL' scope=memory;
System altered.
3. alter database add logfile thread 4 group 40 '/u01/app/oracle/oradata/orcl/redo01/redo40.log' size 536871424;
Database altered.
उपरोक्त वही है जो प्राथमिक पर चलाया गया था। स्टैंडबाय पर रीडो लॉग को ठीक वैसे ही जोड़ने की जरूरत है जैसे प्राथमिक पर किया गया था। प्राथमिक पर जोड़े गए प्रत्येक पुन:लॉग समूह के लिए दोहराएं। चूंकि मैंने अपने प्राथमिक आरएसी डेटाबेस में 3 उदाहरण जोड़े हैं, इसलिए मुझे यहां तीन सूत्र जोड़ने होंगे।
4. alter system set standby_file_management='AUTO' scope=memory;
System altered.
5. alter database recover managed standby database disconnect from session;
Database altered.
प्रबंधित पुनर्प्राप्ति प्रारंभ करें। अब सब कुछ अच्छा होना चाहिए और हम लागू इंस्टेंस के अलर्ट लॉग में सत्यापित कर सकते हैं:
alter database recover managed standby database disconnect from session
Attempt to start background Managed Standby Recovery process (orcs2)
Mon Dec 03 13:32:38 2012
MRP0 started with pid=47, OS id=13232. से हुई
MRP0: Background Managed Standby Recovery process started (orcs2)
started logmerger process
Mon Dec 03 13:32:44 2012
Managed Standby Recovery not using Real Time Apply
Mon Dec 03 13:32:49 2012
Parallel Media Recovery started with 4 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Mon Dec 03 13:32:49 2012
Completed: alter database recover managed standby database disconnect from session
Mon Dec 03 13:32:50 2012
Media Recovery Log /u01/app/oracle/admin/orcs/arch/1_87840_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/2_88542_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/4_1_677462342.dbf
हम यह भी सत्यापित कर सकते हैं कि आवेदन में देरी कम हो रही है। स्टैंडबाय में, निम्नलिखित जारी करें:
select i.instance_name,d.value as apply_lag,
to_char(sysdate,'YYYY-MM-DD HH24:MI:SS') as curr_time
from v$instance i,v$dataguard_stats d. से
where d.name='apply lag';
अपने भौतिक स्टैंडबाय डेटाबेस के लिए ऑनलाइन फिर से लॉग को प्रबंधित करने के तरीके के बारे में पृष्ठभूमि की जानकारी के लिए, मेटलिंक नोट 740675.1 स्टैंडबाय में ऑनलाइन फिर से लॉग देखें।
