Восстановление битых блоков в Oracle — LOB сегмент из песочницы

В один прекрасный момент в алерт-логе очень большой БД, начали появляться сообщения следующего содержания:

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'ом а недостающие записи были выдернуты из реплики.

UPDATE

Данная проблема возникла после того как начали рассыпаться диски на сервере.
Копию раздела сняли сторонней утилитой и развернули на новый свежесобранный массив.
Все операции проводились на базе весом 1,5 Тб.
Вес таблицы 70 Гб.
Версия Oracle 11g R2 — думаю данный способ применим и для 10g.
ALTER TABLE… SHRINK SPACE CASCADE имеет ряд ограничений предварительно рекомендую ознакомится сдокументацией перед его использованием.