ओरेकल - एलओबी खंड में पीटा ब्लॉकों की वसूली

एक बहुत बड़े डेटाबेस के अलर्ट लॉग में एक बिंदु पर, निम्न सामग्री के संदेश दिखाई देने लगे:

भ्रष्ट ब्लॉक सापेक्ष dba: 0x0724c078 (फ़ाइल 28, ब्लॉक 2408568)
डेटाफ़ाइल का बैकअप लेने के दौरान खंडित खंड पाया गया
ब्लॉकनम = 2408568, फ़ाइल = E: \ ORACLE \ ORADATA \ XXX \ XXX_BLOB16.DBF। एक ही भ्रष्ट डेटा पाया

स्थिति इस तथ्य से जटिल थी कि हाथ में कोई बैकअप नहीं था।
अगला, इस स्थिति से बाहर निकलने के लिए निर्देशों का पालन करें।


RMAN ने इस ब्लॉक पर आराम किया और डेटाबेस का बैकअप बिल्कुल नहीं लेना चाहता था।
एक विस्तृत डीब्रीफिंग शुरू हो गई है, और यह पता लगाना है कि यह इकाई क्या संदर्भित करती है:

SELECT owner, segment_name, segment_type FROM dba_extents WHERE file_id = 28 AND 2408568 BETWEEN block_id AND block_id + blocks - 1; OWNER ---------------------------- SEGMENT_NAME ---------------------------- SEGMENT_TYPE ------------------ DOC_USER SYS_LOB0000075021C00003$$ LOBSEGMENT 

तब पता चला कि LOB खंड किस तालिका से संबंधित है:

 SELECT table_name, column_name FROM dba_lobs WHERE owner='DOC_USER' AND segment_name='SYS_LOB0000075021C00003$$'; TABLE_NAME ------------------- COLUMN_NAME ------------------- DOC_LARGE_PIC BINARY_DATA 

DBMS_REPAIR - स्थिति को स्पष्ट नहीं कर सका, एलओबी क्षेत्रों के साथ काम करने पर प्रतिबंध के कारण।

नेटवर्क के खुले स्थानों पर, एक समाधान पाया गया - इसका सार इस प्रकार था:

• 1. तालिका से प्रविष्टियों के माध्यम से वैकल्पिक रूप से सॉर्ट करें।
• 2. यदि आप पीटा ब्लॉक से संबंधित रिकॉर्ड में आते हैं, तो उसके ROWID को बाहर निकालें।

 set serverout on exec dbms_output.enable(100000); declare error_1578 exception; pragma exception_init(error_1578,-1578); n number; cnt number:=0; badcnt number:=0; begin for cursor_lob in (select rowid r, BINARY_DATA L from DOC_USER.DOC_LARGE_PIC) loop begin n:=dbms_lob.instr(cursor_lob.L,hextoraw('AA25889911'),1,999999) ; exception when error_1578 then dbms_output.put_line('Got ORA-1578 reading LOB at '||cursor_lob.R); badcnt:=badcnt+1; end; cnt:=cnt+1; end loop; dbms_output.put_line('Scanned '||cnt||' rows - saw '||badcnt||' errors'); end; / 

स्क्रिप्ट ने दो प्रविष्टियों को सफलतापूर्वक लौटाया:

 Got ORA-1578 reading LOB at AAASUNAAQAAPf7hAAY Got ORA-1578 reading LOB at AAASUNAAQAAPf7hAAp 

एक सरल क्वेरी का उपयोग करते हुए, प्राथमिक कुंजी डेटा रिकॉर्ड प्राप्त किए गए थे और रिकॉर्ड सफलतापूर्वक मिटा दिए गए थे।

ऐसा लगता है कि यह समस्या का समाधान है - लेकिन RMAN सख्ती से इन ब्लॉकों पर आराम करने वाले डेटाबेस को आरक्षित नहीं करना चाहता था।
V $ DATABASE_BLOCK_CORRUPTION और RMAN VALIDATE DATAFILE में क्वेरी ने पुष्टि की कि ब्लॉक एक ही स्थिति में बने हुए हैं।

मैं वास्तव में एक तालिका नहीं बनाना चाहता था और इसे पूरे टेबल स्पेस के नेत्रगोलकों को सौंपना चाहता था, इसलिए यह ALTER TABLE XXX SHRINK SPACE का उपयोग करने का निर्णय लिया गया।

 ALTER TABLE DOC_USER.DOC_LARGE_PIC ENABLE ROW MOVEMENT; ALTER TABLE DOC_USER.DOC_LARGE_PIC SHRINK SPACE CASCADE; 

फिर हम RMAN के साथ समस्या फ़ाइल की जाँच करना शुरू करते हैं:

 RMAN VALIDATE DATAFILE 28; 

इस ऑपरेशन के बाद, V $ DATABASE_BLOCK_CORRUPTION व्यू क्रिस्टल क्लियर हुआ।
इसके अलावा, डेटाबेस को RMAN द्वारा सफलतापूर्वक आरक्षित कर दिया गया था, और लापता रिकॉर्ड्स को प्रतिकृति से बाहर निकाला गया था।

अद्यतन

सर्वर पर डिस्क उखड़ने के बाद यह समस्या उत्पन्न हुई।
अनुभाग की एक प्रति को एक तृतीय-पक्ष उपयोगिता के साथ हटा दिया गया था और नए सिरे से इकट्ठे सरणी में तैनात किया गया था।
सभी ऑपरेशन 1.5 टीबी के वजन के आधार पर किए गए थे।
टेबल का वजन 70 जीबी है।
Oracle 11g R2 का संस्करण - मुझे लगता है कि यह विधि 10g के लिए लागू है।
पहले से बताएं ... SHRINK SPACE CASCADE की कई सीमाएँ हैं, मेरा सुझाव है कि आप इसे इस्तेमाल करने से पहले खुद को डॉक्यूमेंटेशन से परिचित करा लें।