अपूर्ण पुनर्प्राप्ति के बाद डेटाबेस की जांच कैसे करें संगत है

आप बैकअप से डेटाबेस को पुनर्स्थापित कर सकते हैं और इसे सुसंगत बनाने के लिए बहुत सारे संग्रह लागू कर सकते हैं। अब  आप यह सुनिश्चित करना चाहेंगे कि खुले रीसेट लॉग ठीक हो जाएं।
यहां बताया गया है कि अपूर्ण पुनर्प्राप्ति के बाद डेटाबेस की संगति कैसे जांचें

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

SQL> सत्र सेट बदलें nls_date_format='DD-MON-YYYY HH24:MI:SS';

चेक 1 :

उद्देश्य:सत्यापित करें कि डेटाफ़ाइल्स को इच्छित समय (पीआईटी) तक पुनर्प्राप्त किया गया है और वे सुसंगत हैं (फ़ूज़ज़ी =नहीं)
वर्तमान स्थिति और पीआईटी (पी-ओइंट आई-एन टी-इम, जिस तक डेटाफ़ाइलें की गई हैं) को क्वेरी करें रिकवर किए गए) डेटाफाइल्स को सीधे भौतिक डेटाफाइल्स से डेटाफाइल हेडर्स को पढ़कर:

एसक्यूएल> फ़ज़ी, स्टेटस, एरर, रिकवर, चेकपॉइंट_चेंज #, चेकपॉइंट_टाइम, काउंट (*) v$datafile_header ग्रुप से फ़ज़ी, स्टेटस, एरर, रिकवर, चेकपॉइंट_चेंज #, चेकपॉइंट_टाइम चुनें;

• सत्यापित करें कि checkpoint_time / checkpoint_change# आपके इच्छित समय तक/SCN के अनुरूप है। यदि नहीं, तो डेटाबेस को और अधिक पुनर्प्राप्त करें यदि आपके पास अधिक संग्रहीत लॉग उपलब्ध हैं।
• यदि कुछ डेटा फ़ाइलों के लिए FUZZY=YES, तो इसका अर्थ है कि अधिक पुनर्प्राप्ति की आवश्यकता है। यदि कोई और संग्रहीत लॉग उपलब्ध नहीं हैं, तो ऐसी डेटाफ़ाइलों की पहचान करें और निर्धारित करें कि क्या हम उन्हें ऑफ़लाइन ले जा सकते हैं क्योंकि हम उन डेटाफ़ाइलों में डेटा खो देंगे। यदि डेटाफाइल्स सिस्टम या यूएनडीओ टेबलस्पेस से संबंधित हैं, तो हम उचित विश्लेषण के बिना ऐसी डेटाफाइल को ऑफलाइन नहीं ला सकते हैं। आगे की कार्रवाइयों के लिए कृपया Oracle सहायता से परामर्श लें।

एसक्यूएल> सेलेक्ट फाइल#, सबस्ट्र (नाम, 1, 50), सबस्ट्र (टेबलस्पेस_नाम, 1, 15), undo_opt_current_change# v$datafile_header से जहां fuzzy='YES';

कभी-कभी, यदि टेबलस्पेस नाम इसे UNDO टेबलस्पेस के रूप में इंगित नहीं करता है, यदि हमें UNDO_OPT_CURRENT_CHANGE# कॉलम में गैर-शून्य मान दिखाई देता है, तो यह इंगित करता है कि डेटाफ़ाइल में पूर्ववत खंड हैं।

डेटाफ़ाइल ऑफ़लाइन लाने के लिए:

SQL> डेटाबेस डेटाफाइल को ऑफलाइन बदलें;

चेक 1 को तब पास माना जा सकता है जब :
+ सत्यापित किया गया हो कि सभी डेटाफ़ाइलें इच्छित समय तक पुनर्प्राप्त कर ली गई हैं।
+ सिस्टम, यूएनडीओ और सभी इच्छित डेटाफ़ाइलों के लिए फ़ज़ी=नहीं। Fuzzy=YES वाली डेटा फ़ाइलों के लिए, या तो उन्हें और पुनर्प्राप्त करें या यदि कोई और संग्रहीत लॉग उपलब्ध नहीं हैं तो उन्हें ऑफ़लाइन लाएं।

चेक 2 :

उद्देश्य:सत्यापित करें कि स्थिति के साथ फ़ाइलें=RECOVER अनजाने में ऑफ़लाइन नहीं हैं

एसक्यूएल> स्थिति का चयन करें, सक्षम करें, स्थिति के आधार पर v$datafile समूह से गिनती(*) सक्षम करें;स्थिति सक्षम करें      COUNT(*)------------------------- ------- सिस्टम अक्षम किया गया 

 यदि फ़ाइलें पुनर्प्राप्ति स्थिति में हैं, तो सत्यापित करें कि क्या वे ऑफ़लाइन हैं:
 
एसक्यूएल> फ़ाइल #, सबस्ट्र (नाम, 1, 50), स्थिति, त्रुटि का चयन करें, v$datafile_header से पुनर्प्राप्त करें;
 

 यदि आप चाहते हैं कि इन फ़ाइलों का डेटा सुलभ हो, तो उन्हें ऑनलाइन लाएं:
 
SQL> डेटाबेस डेटाफाइल को ऑनलाइन बदलें;
 

 यदि कोई फ़ाइल OPEN RESETLOGS के समय ऑफ़लाइन रहती है, तो डेटाफ़ाइल को उसी खुले डेटाबेस में फिर से ऑनलाइन वापस नहीं लाया जा सकता है।
चेक 2 को पास माना जा सकता है जब:
a) सभी इच्छित डेटाफ़ाइलें हैं ऑफ़लाइन नहीं
 

 चेक 3 : 
 

 उद्देश्य:अतिरिक्त फ़ज़ी जाँच (पूर्ण फ़ज़ी जाँच)
 

 कभी-कभी, सभी इच्छित डेटाफ़ाइलों के लिए फ़ज़ी=नहीं और समान checkpoint_change# देखना संभव है; अभी भी कुछ डेटाफ़ाइलें फ़ज़ी हो सकती हैं और OPEN RESETLOGS त्रुटि लौटाएगा, उदा.
 
एसक्यूएल> फजी, स्टेटस, एरर, रिकवर, चेकपॉइंट_चेंज #, चेकपॉइंट_टाइम, काउंट (*) v$datafile_header ग्रुप से फजी, स्टेटस, एरर, रिकवर, चेकपॉइंट_चेंज #, चेकपॉइंट_टाइम; फूज स्टेटस  एरर             आरईसी चेकप्वाइंट_चेंज चेक पीओ का चयन करें। (*)------ ------------------- ---------- नहीं  ऑनलाइन                                              5375858580 31-अक्टूबर-2011 23:10:14          7एसक्यूएल> वैकल्पिक डेटाबेस खुला रीसेट;ओआरए -01194:फ़ाइल 14 को सुसंगत होने के लिए अधिक पुनर्प्राप्ति की आवश्यकता हैORA-01110:डेटा फ़ाइल 3:'/u01/app/oracle/oradata/TEST/undotbs02.dbf'इसलिए, हमें अतिरिक्त फ़ज़ी जाँच करनी चाहिए जिसे निरपेक्ष फ़ज़ी जाँच के रूप में जाना जाता है:
 
SQL> hxfil file#, substr(hxfnm, 1, 50) नाम, fhscn checkpoint_change#, fhafs Absolute_Fuzzy_SCN, max(fhafs) over () Min_PIT_SCN x$kcvfh से चुनें जहां fhafs!=0;
 

 नोट:कॉलम Min_PIT_SCN कई पंक्तियों के लिए भी वही मान लौटाएगा जैसा कि हमने उस पर ANALYTICAL "MAX() OVER ()" फ़ंक्शन लागू किया है।
 

 उपरोक्त क्वेरी इंगित करती है कि डेटाफ़ाइलों को सुसंगत और खुले के लिए तैयार करने के लिए पुनर्प्राप्ति कम से कम SCN 5311524 तक की जानी चाहिए। चूंकि checkpoint_change# Min_PIT_SCN से छोटा है, इसलिए डेटाफ़ाइलें अधिक पुनर्प्राप्ति के लिए कहेंगी।
 

 चेक 3 को तब पास माना जा सकता है, जब,
a) उपरोक्त क्वेरी से कोई पंक्ति नहीं चुनी गई हो (यानी सभी डेटाफ़ाइलों के लिए Min_PIT_SCN 0 (शून्य) है)
b) Min_PIT_SCN, Checkpoint_Change#
 से कम लौटाया जाता है 

 चेक 4 :लॉग को संग्रहित करना आवश्यक है 
 

 पुनर्प्राप्ति के लिए आवश्यक नवीनतम संग्रह को खोजने के लिए कंट्रोलफाइल को क्वेरी करें। मान लें कि बैकअप 31-AUG-2011 23:20:14 पर पूरा हुआ:
 
SQL> वैकल्पिक सत्र सेट करें NLS_DATE_FORMAT='DD-MON-RR HH24:MI:SS';
SQL> THREAD#, SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG
WHERE '31 चुनें -अगस्त-11 23:20:14' FIRST_TIME और NEXT_TIME के ​​बीच;
 

 यदि उपरोक्त क्वेरी कोई पंक्ति नहीं लौटाती है, तो हो सकता है कि जानकारी नियंत्रण फ़ाइल से बाहर हो गई हो - v$log_history के विरुद्ध निम्न क्वेरी चलाएँ।
 
SQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-RR HH24:MI:SS';
SQL> a.THREAD#, a.SEQUENCE#, a.FIRST_TIME
V$ से चुनें LOG_HISTORY a
जहां FIRST_TIME =
( MAX(b.FIRST_TIME) चुनें
V$LOG_HISTORY b से
जहां b.FIRST_TIME 
उपरोक्त क्वेरी द्वारा दिया गया अनुक्रम# बैकअप समाप्त होने के समय वर्तमान लॉग अनुक्रम है - मान लें कि 530 थ्रेड 1 है।
 

 न्यूनतम पुनर्प्राप्ति उपयोग के लिए:(क्रमांक# जैसा कि +1 लौटाया गया)
 
RMAN> रन करें
{
SEQUENCE 531 THREAD 1 तक सेट करें;
डेटाबेस पुनर्प्राप्त करें;
}
 

 यदि यह एक RAC कार्यान्वयन है तो इसके बजाय इस SQL ​​​​का उपयोग कंट्रोलफाइल को क्वेरी करने के लिए करें:
 
एसक्यूएल> चुनें थ्रेड#, अनुक्रम#, FIRST_CHANGE#, NEXT_CHANGE# V$ARCHIVED_LOG से जहां '31-अगस्त-11 23:20:14' FIRST_TIME और NEXT_TIME के ​​बीच;
 

 न्यूनतम पुनर्प्राप्ति के लिए उपरोक्त क्वेरी द्वारा लौटाए गए लॉग अनुक्रम और थ्रेड का उपयोग करें जिसमें निम्नतम NEXT_CHANGE# है।
 

 चेक 4 को पास माना जा सकता है जब:
 

 बैकअप के समय से लेकर बैकअप के अंत तक के सभी संग्रह पुनर्प्राप्ति के दौरान उपयोग के लिए उपलब्ध हैं
 

 चेक 5 (सफल ओपन रीसेट के बाद): 
 

 OPEN RESETLOGS गतिविधियों के समय के लिए अलर्ट.लॉग की निगरानी करें। शब्दकोश जाँच के दौरान आपको नीचे कुछ संदेश दिखाई दे सकते हैं:
 

 नियंत्रण फ़ाइल में ऑफ़लाइन फ़ाइल 'MISSING00004' बनाना
 

 अगर आपको फ़ाइल मिलती है, तो उनका नाम बदलने का प्रयास करें। यदि नहीं, तो हम डेटाफ़ाइल को ऑफ़लाइन कर सकते हैं या संबद्ध तालिका स्थान को छोड़ सकते हैं:
 
SQL> v$datafile से फ़ाइल#, स्थिति, सक्षम, सबस्ट्र (नाम, 1, 50) चुनें, जहां नाम '%MISSING%';FILE#    STATUS  सक्षम किया गया है    SUBSTR(NAME,1,50) ---- -------------------------------------------------------- ---------------------        4 ऑफ़लाइन अक्षम   /<पथ>/MISSING000       7 ऑफ़लाइन अक्षम   /<पथ>/MISSING000SQL> डेटाबेस डेटाफ़ाइल 4 को ऑनलाइन बदलें;डेटाबेस डेटाफ़ाइल 4 बदलें ऑनलाइन*त्रुटि 1:ORA-01157:डेटा फ़ाइल को पहचान/लॉक नहीं कर सकता 4 - DBWR ट्रेस फ़ाइल देखेंORA-01111:डेटा फ़ाइल 4 का नाम अज्ञात है - फ़ाइल को सही करने के लिए नाम बदलेंORA-01110:डेटा फ़ाइल 4:'//dbs/MISSING00004'SQL> डेटाबेस का नाम बदलें फ़ाइल 'MISSING00004' को '//users01.dbf' में बदलें; डेटाबेस बदल गया। SQL> डेटाबेस का नाम बदलें फ़ाइल 'MISSING00007' को '//users02.dbf' में बदलें;डेटाबेस बदल दिया गया। SQL> dba_tablespaces से tablespace_name, स्थिति का चयन करें जहां tablespace_name (dba_data_files से tablespace_name चुनें जहां file_id (4, 7) में);TABLESPACE_NAME                स्थिति ------------- ---------- ------------उपयोगकर्ता                         ऑफ़लाइन SQL> तालिका स्थान उपयोगकर्ताओं को ऑनलाइन बदलें; तालिका स्थान बदल दिया गया है।
 

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

 यह भी पढ़ता है 
ओरेकल में संग्रह लॉग अनुक्रम संख्या कैसे खोजें
RMAN बैकअप आदेश
RMAN सूची बैकअप आदेश
RMAN का उपयोग करके डेटाबेस को कैसे पुनर्प्राप्त करें