InterBase - статьи

Восстановление данных


И так мы можем приступать к самому ответственному этапу. Для удобства работы можно порезать файл базы данных на множество страниц и вычленить страницы с необходимой нам таблицей. Для начала пусть это будет любая таблица с текстовыми данными, например справочник товаров и т.д. Просмотрев его любым текстовым редактором можно заметить, что в данном файле находятся утерянные текстовые данные. Но возникает другой вопрос, как эти данные вытащить из базы, если заголовок со смещением и размером записи утерян навсегда. Возможно придумать массу алгоритмов с помощью которых можно восстановить утерянные данные, я предлагаю, на мой взгляд, самый простой, да и по вычислительным возможностям современных компьютеров восстановление происходит относительно быстро. В качестве примера данного утверждения могу сказать, что восстановление 2000 записей (не текстовая таблица) на Athlon XP 2000, программой написанной на Delphi , заняло порядка 10 секунд.

Суть алгоритма состоит в том, что нам известно следующее:

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

Возьмем на рассмотрение самый простой метод, варьированием параметров которого можно добиваться увеличения производительности программы восстановления во много раз.

Начиная с конца страницы, берем несколько байт (для каждой таблицы можно отдельно посчитать необходимый минимум) и просто пытаемся раскодировать, если после декодирования у нас не получился размер равный размеру записи, то делаем шаг приращения (советую в один байт, пока не найден кандидат в запись, потом шаг можно пересмотреть), и повторяем процедуру заново.

В случае, если размеры совпали, то мы получили кандидата на правильную запись в первом приближении, однако, она должна удовлетворять многим условиям. Прежде всего, её заголовок не должен содержать ничего криминального, после этого проверяем на правильность данных, которые несет в себе запись.

При проверке стоит учитывать несколько факторов, которые напрямую зависят от предметной области базы данных:

•  Если первичным ключом таблицы является поле с автоинкриментом, то соответственно оно не должно быть более чем значение генератора, так же, если не определено иное оно не может быть отрицательным;

•  Даты, если это, например, простенькая складская программа, не могут быть в далёком прошлом и далёком будущем;

•  Цена на товар не может быть отрицательной либо слишком большой;

Таким образом, кроме вышеперечисленных, можно выдумать ещё массу реальных ограничений, которые можно наложить на данные.

В качестве примера могу сказать, что при восстановлении 2000 записей имеющими дубликаты оказались только 4.

Так как их количество оказалось не сильно велико, то основываясь на знаниях, что именно должно было указано в этих полях, лично я не стал утруждать себя и возится с версиями записей.

В результате проделанной работы мы получаем из базы всё что нужно.

Для простоты восстановления можно просто приостановить работу всех триггеров и с помощью sql запросов добавить недостающие данные.

ГОТОВО!!!!



Содержание раздела