В один прекрасный момент в алерт-логе очень большой БД, начали появляться сообщения следующего содержания:
Corrupt block relative dba: 0x0724c078 (file 28, block 2408568)
Fractured block found during backing up datafile
Reread of blocknum=2408568, file=E:ORACLEORADATAXXXXXX_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'ом а недостающие записи были выдернуты из реплики.
Автор: proger89
