Corrupt block relative dba: 0x0724c078 (file 28, block 2408568)
Fractured block found during backing up datafile
Reread of blocknum=2408568, file=E:\ORACLE\ORADATA\XXX\XXX_BLOB16.DBF. found same corrupt data
Ситуация осложнялось тем, что бэкапов под рукой не было.
Далее последуют инструкции по выходу из данной ситуации.
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 — не смог прояснить ситуации, ввиду ограничений на работу с LOB полями.
На просторах сети было найдено решение — суть его заключалась в следующем:
- 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
При помощи нехитрого запроса были получены PRIMARY KEY данных записей и записи были успешно потерты.
Казалось бы, вот оно решение проблемы — но 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’ом а недостающие записи были выдернуты из реплики.
ссылка на оригинал статьи http://habrahabr.ru/post/162319/
Добавить комментарий