Восстановление информации при частичном нарушении mdf(или backup)-файлов. Как восстановить поврежденную базу данных MS SQL Server Восстановление mdf файла

Восстановить MDF

Если база данных Microsoft SQL Server неработоспособна и в SQL Management Studio база имеет статус “suspend” (отмечена серым цветом), то целостность данных в ней серьезно нарушена. Как восстановить поврежденную базу данных из состояния suspend? Как восстановить информацию, хранящуюся в.mdf файле базы данных?

Пошаговое описание восстановления поврежденного.mdf файла:

Отсоединить (de-attach) базу данных от MS SQL Server в SQL Management Studio
Создать новую пустую базу данных, для последующего импорта в нее восстановленных данных.
Запустить SQL Server Repair Toolbox и выбрать.mdf файл, отключенной базы на первой странице программы

Выполнить все шаги внутри программы и:

или сохранить данные в виде sql скриптов. После сохранения данных как скрипты sql на диске требуется запустить.bat файл с нужными параметрами для импорта данных в новую базу данных
или экспортировать данные непосредственно в новую базу данных.

SQL Server Repair Toolbox не является бесплатной программой с открытым исходным кодом. Пользователи могут попробовать эту программу перед приобретением, используя демонстрационную версию. Программа не обладает такими лицензиями, как GNU General Public License (GPL) или GNU Lesser General Public License (LGPL).

Системные требования: Windows 98 или выше

Случилось страшное (посыпался винт, был скачок напряжения, и т.п.) – база в состоянии 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. И почаще.

Иногда приходится столкнуться с ситуацией, когда плоды многолетней работы, находящиеся в SQL-базе данных оказываются под угрозой. Эта статья о том, как не допустить потерю данных, а в случае, если это всё-таки произошло, как восстановить данные из того, что осталось от некогда нормальной базы.

Итак, приступим. Ситуация следующая: имеется сервер с запущенной на нем 1С+SQL. Во время работы SQL базы рубанули питание. Результат плачевный: база находится в состоянии suspect, и когда 1с пытается к ней зацепиться, выдается ошибка, что мол соединиться невозможно т.к. база помечена suspect for recovery. Этот режим в принципе означает, что MSSQL Server попытается восстановить базу своими средствами. Я не стал ни чего трогать и оставил все на ночь, в надежде, что к утру база восстановится, но и утром было то же самое, и к базе, стало быть, ни как не подобраться. Backup по закону подлости имеется, но он трехдневной давности, плюс имеется куча документов которые проводятся лишь по базе, а по бумажным документам их нет, т.е. возможности вручную восстановить документы нет. Потратив кучу сил, и нервов, (которые, как известно не восстанавливаются:)), я пришел к следующей последовательности действий, необходимых для восстановления базы.

1) Основной принцип поначалу – не навреди. Глушим SQL server и копируем *.mdf и *.ldf файлы от базы в сторону.
2) В принципе, бывает, что состояние suspect возникает из-за того, что поменялись пути к файлам с базой (например, добавился новый диск в системе, который потом убрали, переименовали папку с базой и т.д.). Затем, конечно же, пути восстановили, но база все равно остается помеченной как suspect. Вот что мы делаем:
3) Запускаем SQL Server.
4) Пробуем подключить базу через Enterprise Manager:
Правой кнопкой по Databases, в появившемся меню выбираем All tasks->Attach database, затем в появившемся диалогов окне выбираем файл с базой (*.mdf) и устанавливаем необходимые параметры.
5) или через Query Analyser примерно такой командой:
a. sp_attach_db @dbname = "DemoXMB",
b. @filename1 = "E:\Data\DemoXMB_Data.MDF",
c. @filename2 = "E:\Data\DemoXMB_Log.LDF"
6) Пути к базе, естественно нужно заменить на свои. Если база подключилась, то, можно сказать, отделались легким испугом, если же нет, то продолжим.
7) Если log-файл не поврежден (*.ldf), а поврежден *.mdf (например, при подключении базы sql ругается на ошибки в mdf-файле), и режим сохранения backup"а стоит full, то восстанавливаем базу без восстановления лога транзакций, почти 100%, что все мучения на этом могут закончиться.
8) Если же наоборот, поврежден ldf-файл, но остался *.mdf файл, при подключении база ругается на отсутствие/повреждение лога транзакций. В этом случае можно воспользоваться ХП "sp_attach_single_file_db"

Например:
use master
EXEC sp_attach_single_file_db @dbname = "DemoXMB",
@physname = "c:\mssql7\data\DemoXMB_Dat.mdf"

При выполнении этих команд, создастся файл DemoXMB_Log.ldf в том же каталоге где и база, размером 1MB и авторасширением.
Если есть *.MDF и *.LDF-файлы, или данные хранятся более чем в одном физическом файле (общее количество подключаемых физических файлов не должно превышать 16-ти), то следует использовать ХП "sp_attach_db"

Например:
use master
EXEC sp_attach_db @dbname = "DemoXMB",
@filename1 = "c:\mssql7\data\DemoXMB_Dat.mdf",
@filename1 = "c:\mssql7\data\DemoXMB_Log.ldf"

Для подключения более 16-ти физических файлов к БД следует использовать команду:
CREATE DATABASE FOR ATTACH

Однако если ничего не помогло, оказались поврежденными оба файла и база всё еще в состоянии suspect, то можно попробовать сбросить состояние базы следующей последовательностью: (перед использованием этой ХП необходимо разрешить прямое изменение системных таблиц)
use master
go
Разрешаем прямое изменение системных таблиц:
sp_configure "allow updates",1
go
reconfigure with override
go
Для сброса признака suspect выполняем в БД master ХП sp_resetstatus:
sp_resetstatus "DataBaseName"
go
А теперь запретим прямое изменение системных таблиц:
sp_configure "allow updates",0
go
reconfigure with override
go

В принципе, когда я выполнил все эти шаги, статус suspect сбросился, НО! при попытке выполнить какие-либо действия SQL начинала ругаться, что база все еще в состоянии suspect. И тогда я сделал так:

Из QA выполняем скрипт:
Use master
go
sp_configure "allow updates", 1
reconfigure with override
go

Там же выполняем:
update sysdatabases set status= 32768 where name = ""

Перезапускаем SQL Server. В принципе база должна быть видна (в emergency mode).

Из QA выполняем:
USE ""
GO
sp_dboption "", "single_user", "true"
go
DBCC CHECKDB("", REPAIR_ALLOW_DATA_LOSS)
go

Если все в порядке, то:
sp_dboption "", "single_user", "false"
go
Use master
go
sp_configure "allow updates", 0
go

После этого стало возможно просмотреть таблицы базы из SQL, а вот работать с ней было невозможно. Теперь необходимо при помощи Data Transformation Services экспортировать данные в новую базу. После этого проводим восстановление/тестирование базы средствами 1С. Внимание! Многие не обращают внимания на этот очень важный пункт. В результате, вы можете в один прекрасный момент обнаружить, что база восстановлена, мягко говоря, не совсем корректно. Т.е. в документе вместо номенклатуры будет стоять нечто вроде 10122/<Объект не найден>, это та проблема, которая возникла у меня, вариантов же может быть уйма. Поэтому лучше потерять время, но проверить базу средствами 1С.

Если уж совсем ничего не помогает, а данные страсть как нужно восстановить, есть еще сторонняя утилита под названием MSSQLRecovery . Утилита платная, но есть возможность воспользоваться демонстрационной версией, которую можно взять здесь: http://www.officerecovery.com/mssql/download_demo.htm . Программа очень простая, и восстановление базы сводится к трем шагам: 1) выбираем файл с базой; 2) выбираем путь куда сохранять; 3) Жмем кнопку recovery; Ждем. Программа разбирает SQL-базу по косточкам и складывает ее в отдельный каталог. Туда же она добавляет и.bat файл для восстановления базы из полученных «кусочков». Я ей так и не воспользовался, т.к. сумел восстановить базу предыдущими шагами.

Но! Здесь следует сделать паузу. Статья не была бы полной, если бы я не описал методы для предотвращения подобных проблем. Итак, самый простой и надежный способ: архивация, архивация и еще раз архивация. В Enterprise Manager заходим в меню Tools->Wizards->Management->Backup Wizard и настраиваем все необходимые параметры. В результате, у меня полный сброс SQL базы на диск происходит ночью, а затем каждые 15 минут backup изменений, внесенных в базу. В принципе, если бы у меня был такой backup, я бы за пару минут сделал откат назад, и продолжил бы попивать Coca-Cola:).

В случае возникновения дополнительных вопросов/комментариев писать сюда: