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

Базы данных являются основой основ многих корпоративных информационных систем. В них может храниться практически любая информация, начиная с оперативной и заканчивая бухгалтерской документацией. Даже временная недоступность этой информации может привести к заметным убыткам. Что уж говорить о полной их утере! Между тем, такая ситуация вполне реальна. Физически базы данных являются самыми обыкновенными файлами, которые легко могут оказаться поврежденными в результате вирусной атаки, сбоев программного обеспечения или файловой системы, выхода из строя жесткого диска, неосторожных действий пользователей и т.д. В любом из этих случаев база перестает открываться и, соответственно, вся информация, размещенная в ней, оказывается недоступной.

Помочь справиться этой проблемой и вернуть казалось бы окончательно утерянные данных может программа SQL Server Recovery Toolbox (). Она предназначена для извлечения и сохранения информации из поврежденных баз MS SQL Server (поддерживаются файлы Microsoft SQL Server 7.0, 2000, 2005, 2005 64-bit, 2008 и 2008 R2). Естественно, SQL Server Recovery Toolbox не может гарантировать полного восстановления всех данных. Необходимо понимать, что в некоторых случаях повреждения могут оказаться настолько сильными, что часть информации извлечь просто-напросто невозможно. Процесс восстановления и сохранения информации из поврежденной базы данных MS SQL Server с помощью программы SQL Server Recovery Toolbox осуществляется с помощью пошагового мастера. На каждом этапе пользователь должен выполнить всего одно действие, что очень удобно и практично.

На первом шаге необходимо выбрать поврежденную базу данных MS SQL Server. Удобнее всего это сделать с помощью Windows Explorer, который запускается при нажатии на кнопку . В качестве фильтра отбора автоматически указаны расширения *.mdf и *.ndf (стандартные расширения баз данных MS SQL Server). Все однажды проанализированные файлы заносятся в специальный список быстрого доступа. В будущем для их выбора пользователю достаточно нажать на значок , переместить в открывшемся списке курсор на нужный документ и нажать на левую кнопку мыши.

Переход к следующему этапу осуществляется с помощью кнопки Next. При этом программа выдаст на экран диалоговое окно с вопросом, нужно или нет проводить анализ исходного файла. В случае утвердительного ответа она извлекает из поврежденной базы служебные данные и отображает ту информацию, которую она может восстановить. Для удобства пользователя окно делится на две части. В левой выводятся все возможные категории информации: пользовательские и системные таблицы (User Tables и System Tables), представления (Views), хранимые процедуры (Stored Procedures), функции (Functions) и определенные пользователем типы (User Defined Data Types). При установке курсора на любой из них в правой части будет показан список доступных объектов и их содержимое. Пользователь должен внимательно просмотреть ее и убедиться в том, что программа SQL Server Recovery Toolbox справится с задачей и действительно сможет восстановить утерянные данные.

На следующем шаге происходит выбор способа сохранения информации. Дело в том, что в рассматриваемой утилите извлеченные из поврежденного файла данные могут быть сохранены на жесткий диск в виде набора скриптов на языке SQL или экспортированы непосредственно в базу MS SQL Server. Первый вариант хорош тем, что позволяет перенести извлеченную информацию на любой сервер. Для этого достаточно скопировать полученный в результате работы пакет скриптов на нужный компьютер и запустить его там. А второй вариант более удобен в тех случаях, когда ПК, на котором осуществляется восстановление, имеет подключение к нужной базе данных. В этом случае экспорт информации в нее происходит без каких-либо дополнительных действий.

Далее пользователю необходимо выбрать информацию, которую нужно восстановить из поврежденного файла и сохранить. Для этого программа SQL Recovery Roolbox опять отображает на экране то, что она может извлечь. А пользователь должен с помощью установки/снятия флажков в чекбоксах отметить нужные ему данные. Выбирать или снимать выбор можно сразу же со всей базы данных, целых категорий информации или отдельных объектов (таблиц, представлений, хранимых процедур и т.д.).

После завершения выбора можно запускать процесс сканирования исходного файла и сохранения извлеченной их него информации. Для этого необходимо нажать на кнопку Start Recovery. Длительность этой работы зависит от двух факторов. Во-первых, от исходного файла, его структуры и размера. А во-вторых, от производительности компьютера, на которой она выполняется. Стоит отметить, что в некоторых случаях базы данных имеют огромные размеры, а поэтому восстановление информации из них может занять несколько дней. Сразу же после окончания процесса программа SQL Server Recovery Toolbox выдаст на экран лог. В нем приводятся данные по всем процессам восстановления информации, реализованным в течение текущей сессии работы.

Таким образом, программа SQL Server Recovery Toolbox является удачным средством для восстановления данных из поврежденных баз MS SQL Server. Она отличается двумя особенностями. Первая из них - эффективность. Рассматриваемая утилита способна восстановить из поврежденного файла возможный максимум информации. Вторая особенность SQL Server Recovery Toolbox - крайняя простота использования. С помощь этой программы извлечь информацию из поврежденной базы данных и сохранить ее без предварительного обучения может любой пользователь, даже только начинающий изучение компьютера.

Иногда приходится столкнуться с ситуацией, когда плоды многолетней работы, находящиеся в 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:).

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

Восстановить 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. И почаще.