Восстановление информации при частичном нарушении mdf(или backup)-файлов

Случилось страшное (посыпался винт, был скачок напряжения, и т.п.) – база в состоянии suspect и выходить из него не хочет, что бы мы не предпринимали…

Резервные копии баз мы естественно не делали – авось пронесет. Не пронесло.

Итак, для восстановления данных нам нужно:

1. MSSQL сервер, MS SQL Enterprise Manager (EM), MS SQL Query Analyzer (QA) от Microsoft (входит в поставку MS SQL).

2. 1С:Предприятие 7.7 SQL версия.

3. MSSQLRecovery от http://www.officerecovery.com

4. Копия 1cv7.md-файла от разрушенной базы данных 1С, копия разрушенного файла mdf, приблизительно столько же свободного места на диске, что и занимает файл.

5. Свободного времени исходя из расчета 3 часа на 1 Гб веса файла mdf.

6. Клавиатура, мышь, монитор.

Вкратце опишу, что делает MSSQLRecovery:

1. Разбирает mdf-файл на уровне структуры (MFT), формируют текстовые sql-скрипты, содержащие схему БД и сами данные из нашей разрушенной базы.

2. Создает командный файл commit.bat, который запускает консольную версию MS Query Analyzer, последовательно выполняющий sql-файлы и собственно заполняет нашу новосозданную базу SQL.

Комментарии к работе MSSQLRecovery.

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

Во-первых, программа создает скрипт schema.sql, содержащий описание структуры таблиц, процедур, функций, индексов и пр. Данный скрипт выполняется первым, создает соответственно таблицы, процедуры, функции, индексы и прочее в нашей пустой пока еще базе данных. Очень качественно это делает. За одним «но» -- в файле перепутан порядок следования полей при создании структуры таблиц. Возможно для других программ такое «перепутывание» не страшно, а вот 1С этого не переваривает.

Во-вторых в созданном пакетном файле commit.bat используется консольная версия Query Analyzer (isql.exe), а он почему-то не желает корректно работать с кодовой страницей cp1251 – преобразовывает русские символы в OEM-кодировку. Нам это тоже не подходит.

Собственно процедуры, которые необходимо выполнить, чтоб было счастье:

1. Натравить MSSQLRecovery на частично разрушенный файл mdf, дать ей время на обработку и после указать где мы хотим сохранить получившиеся скрипты со структурой БД и её восстановленными данными.

2. Создать новую пустую базу на SQL-сервере.

3. Создать структуры нашей базы, воспользовавшись копией 1cv7.md от рухнувшей базы с помощью 1С:Конфигуратора.

4. Изменить файл commit.bat, убрав строчку с вызовом выполнения скрипта schema.sql – мы уже создали структуру БД с помощью 1С.

5. Изменить в том же commit.bat вызов isql на вызов isqlw – GUI версию Query Analyzer’а. Это нужно для корректного восприятия русской кодировки. Т.е. строка:
isql –S %1 –d %2 –U %3 –P %4 –E –I data0001.sql
будет иметь вид:
isqlw –S %1 –d %2 –U %3 –P %4 –E –i data0001.sql –o out.txt
Параметр «–о» и файл «out.txt» необходимы для корректного запуска GUI-версии QA, в файл «out.txt» будет записан лог произведенных транзакций. Заменить нужно во всем файле commit.bat, например в файловом менеджере Far Manager.

6. Запустить файл commit.bat на исполнение с четырьмя параметрами: - Имя сервера SQL - Имя новой базы SQL, которую мы создали ранее - Имя пользователя, имеющего роль dbowner для этой базы (обычно это sa) - Пароль этого пользователя Выглядеть будет приблизительно так: commit.bat my_sql_server recovery_1c_db sa gfhjkm

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

После отработки commit.bat можно запустить 1С и посмотреть, на сколько велики потери. Обычно теряются те данные, которые чаще всего использовались или использовались в момент сбоя.

А чтоб потерь не было – делайте backup. И почаще.