Как «воскресить» базу данных Oracle

Достаточно часто приходится сталкиваться с задачами, когда из-за перебоев в электричестве/оборудовании или просто из-за устаревшего железа портятся данные в базе данных. Конечно, необходимо делать резервные копии, настраивать инкрементальные резервные копии, использовать standby базы данных, но все это требует дополнительных ресурсов, как аппаратных, так и человеческих. Как бы ни была продумана СУБД, как бы хорошо ни работали архивные журналы, дубликаты контрольных файлов, журналов повторных выполнений, всегда есть угроза потери данных, и, к сожалению, не всегда есть возможность использовать все решения, все меры безопасности и все возможные средства.


Восстановление данных
Oracle Database 11g

С аналогичным случаем довелось столкнуться недавно и нам. В компанию DBI обратился Заказчик с поврежденной СУБД Oracle DB 11gR2 на Windows Server 2008 в качестве операционной системы. База данных имела размер 35G. Типичные ошибки первоначальной настройки: все дубликаты контрольных файлов и файлов повторного выполнения располагались в одном месте, а именно вместе с файлами данных. Был отключен архивный режим и ко всему прочему отсутствовали полноценные резервные копии.

Из-за аппаратного сбоя или сбоя в электроснабжении был поврежден жесткий диск, на котором располагались все эти данные. После некоторых восстановительных работ системными инженерами на руках были, на первый взгляд, оригинальные файлы данных, все журналы и контрольные файлы, а вот попытка запустить базу данных приводила к ошибкам:

ORA-01578: ORACLE data block corrupted (file # 1, block # ***)

И блоков таких было порядка 5000 только в SYSTEM табличном пространстве.

Утилита DBVerify показала также повреждения в пользовательском табличном пространстве В итоге, сумма поврежденных блоков была порядка 19.000, а это около 150M информации. Хотя и процентное соотношение к 35G небольшое, но запустить базу данных с повреждениями в SYSTEM табличном пространстве не всегда получается.

Задачу восстановления осложняло отсутствие резервных копий, точнее одна копия  была на руках, но она была сделана уже после повреждений, так что использовать её не было возможности. Ну и как факт, восстановить поврежденные блоки данных в SYSTEM табличном пространстве было неоткуда.

Было несколько вариантов:

  1. Использовать Transportable Tablespaces технологию, но для её применения необходима копия метаданных, которые и находятся в поврежденном SYSTEM.
  2. Утилита BBED — была включена в Oracle 7 – 10G версии. Напоминает редактор блоков данных (интерфейс напоминает RMAN/CELLCLI и аналогичным утилитам). Но беда в том, что под 11G утилиту необходимо компилировать отдельно, более того на Windows Server. Да и сама утилита без поддержки OracleSupport достаточно небезопасна и требует хорошей практики.
  3. RMAN утилита — без имеющихся резервных копий по факту была бессильна.

На этом бы и завершилась работа с официальной поддержкой Oracle, более того, утилиту BBED даже бы и не вспомнили.
В тоже время существует достаточно много сторонних разработок различных производителей, которые позиционируют свое ПО, как способное к восстановлению поврежденных данных в Oracle базе данных. Судя по описанию и возможностям, подобные утилиты были разработаны с поддержкой специалистов, хорошо знакомых со структурой и архитектурой Oracle файлов, расположением данных и системой их хранения.

Эмпирическим путем сотрудники компании DBI выбрали наиболее оптимальный инструмент для своей работы.
Данный программный продукт позволяет увидеть процесс анализа данных. Функционал уникален, так как это полный и подробный отчет по всем пользователям, правам и объектам, которые были найдены в поврежденном SYSTEM, а, более того, и непосредственно сами данные:

Восстановление Oracle DB 11g

Результирующий отчет показывает подробно всю структуру базы данных, все данные, которые возможно восстановить. Более того не было жесткой привязки к кодировке или языку хранимых данных. Согласитесь, достаточно удивительный и приятный результат.

Восстановить потерянные данные в полной мере не удалось, что в итоге подтвердилось окончательным анализом результата, но работоспособность БД была восстановлена, а более того, и были восстановлены сами данные, которые имели важное значение для самого бизнес-процесса.
Время анализа данных составило около 4-х часов. Восстановление порядка 36 часов. Данные наполнялись посредством INSERT операций, так что физическая структура хранения гарантированно не содержала в себе ошибки.

Окончательный анализ результата показал недостаточность данных в одной из пользовательских таблиц, но по сравнению с полной потерей данных, такой результат был оценен как «отличный».

Алексей Светличный
Ведущий администратор баз данных Oracle, DBI


Как «воскресить» базу данных Oracle: 1 комментарий

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*