Как проверить mdf файл на ошибки

Обновлено: 06.07.2024

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

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

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

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

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С, которая по листингу директории будет последовательно выполнять скрипты.

Как восстановить файл MDF в SQL Server?

Здесь мы опишем два метода для подключения или восстановления базы данных MDF в SQL Server:

Используя SQL Server Management Studio
Используя T-SQL

Восстановление файла MDF в SQL Server без LDF с помощью SQL Server Managment Studio

Выполните все указанные шаги, чтобы успешно прикрепить файл .mdf в SQL Server.

SQL Server создаст файл LDF при прикреплении файла MDF.

Теперь вам нужно проверить базу данных в папке базы данных.

Прикрепите или восстановите файл MDF в SQL Server с помощью сценария T-SQL

CREATE DATABASE testdatabase ON
(FILENAME = 'C:Program FilesMicrosoft SQL ServerMSSQL12.MSSQLSERVERMSSQLDATAtestdatabase.mdf')
FOR ATTACH_REBUILD_LOG
GO

После восстановления файла MDF с помощью программного обеспечения вы можете подключить MDF в SQL Server. Это программное обеспечение позволяет пользователю восстанавливать удаленные объекты базы данных SQL, а также удаленные записи таблицы SQL. Пользователь может легко восстановить как первичные, так и вторичные файлы с помощью этого программного обеспечения. Кроме того, это программное обеспечение поддерживает Microsoft SQL Server 2019/2017/2016/2014/2012 и более раннюю версию.

Выполните указанные ниже шаги, чтобы восстановить базу данных только из файла MDF.

2. Щелкните на Открыть и просмотреть файл MDF из вашей системы. Далее Выберите Версия SQL Server и Расширенный режим сканирования. (Пользователь также может проверить pпросмотреть удаленный объектs вариант.)

3. Предварительный просмотр объектов базы данных SQL SQL Стол, хранимая процедура, функции, взгляды, индексы и т.д. (Это программное обеспечение показывает удаленные записи таблицы SQL красным цветом.)

4. Щелкните на Кнопка экспорта и заполнить требуемые детали для восстановления базы данных из файла MDF.

Вывод

Файл MDF является основным файлом базы данных в SQL Server. Как все мы знаем, Microsoft SQL Server является наиболее предпочтительной системой реляционных баз данных, хранящей миллионы записей каждый день. В такой ситуации повреждение файла SQL MDF может представлять высокий риск для организаций. Если файл MDF поврежден, SQL Server не сможет получить доступ к файлу данных. Поэтому необходимо восстановить поврежденный файл MDF. Этот блог расскажет вам, как выполнить восстановление MDF файла? Прежде чем перейти к процессу, мы должны сначала знать причины коррупции.

Что является причиной повреждения файла MDF?

Существует несколько возможных причин, по которым файл SQL MDF поврежден. Здесь мы обсудим некоторые из причин:

Повреждение хранилища, на котором хранятся все файлы MDF.
Если пользователь сохранил базу данных SQL в сжатой папке, существует вероятность, что файл MDF будет поврежден.
Любые изменения будут внесены в учетную запись SQL Server.
Пользователь может случайно удалить данные.
Если заголовок файла поврежден, он повредит файл MDF.
Использование базы данных SQL с сетевой ошибкой приведет к повреждению файла MDF.
Сбой жесткого диска, вирусная атака, внезапный сбой питания, внезапное отключение системы

Способ 1: Восстановить поврежденный файл MDF с помощью DBCC CHECKDB

Шаг 1. Сначала запустите DBCC CHECKDB в поврежденной базе данных SQL, используя следующую команду:

DBCC CHECKDB (Name of the corrupt Database)

Шаг 2. Теперь проверьте идентификатор индекса и рассмотрите следующие два случая соответственно

Случай 1: Если ID индекса> 1, удалите его и создайте заново.
Случай 2: Если ID индекса равен 0 или 1, снова запустите DBCC CHECKDB и используйте параметры восстановления, такие как

DBCC CHECK (name_of_corrupt_database, repair_fast)

DBCC CHECK (name_of_corrupt_database, repair_rebuild)

DBCC CHECK (name_of_corrupt_database, repair_allow_data_loss)

Метод 2: Восстановление MDF файла с помощью Инструмент восстановления SQL

В случае сбоя ручного метода вы можете выбрать программное обеспечение Восстановление SQL. Это 100% безопасное и полезное приложение для восстановления и восстановления файла MDF. Это помогает пользователям восстановить все элементы данных, такие как таблицы, правила, триггеры, функции и многое другое. Инструмент прост в использовании и предоставляет различные расширенные функции, которые даже полезны для непрофессиональных пользователей.

Выполните следующие простые шаги для восстановить поврежденный файл MDF в SQL Server 2019, 2017, 2016, 2014, 2012:

Шаг 1. Загрузите и запустите программное обеспечение

Шаг 2. Нажмите «Открыть» и выберите файл MDF для восстановления.

Шаг 3. Выберите параметр сканирования, а затем вручную или автоматически выберите версию .mdf файла SQL Server.

Шаг 4. После завершения процесса сканирования вы можете легко увидеть предварительный просмотр восстановленных данных. Удаленные записи базы данных SQL будут показаны красным цветом. Теперь нажмите на опцию экспорта сверху.

Шаг 5. Выберите «Параметры экспорта» из «Экспорт в базу данных SQL Server» и «Совместимые сценарии SQL Server». После заполните необходимые данные.

Шаг 6. Выберите базу данных назначения из «создать новую базу данных» и «экспортировать в существующую базу данных» в соответствии с необходимостью.

Шаг 7. Выберите опцию Экспорт только со схемой и Со схемой и данными. После этого нажмите кнопку «Экспорт».

Дополнительные функции программного обеспечения восстановление MDF файла

Восстановление поврежденный файл базы данных SQL со всеми объектами, такими как таблицы, триггеры, функции, правила и т. Д.
Расширенная опция для предварительного просмотра удаленных записей базы данных SQL в красном цвете.
Нет проблем с размером файла, номером файла и потерей данных при восстановлении поврежденного файла MDF.
Поддерживает SQL Server 2017, 2016, 2014, 2012, 2008 и все другие версии.
Восстановить поврежденный файл MDF и восстановить данные непосредственно в действующей базе данных SQL Server, используя только учетные данные вашей учетной записи SQL Server.
Восстановить файл базы данных SQL в новую базу данных или существующую базу данных без каких-либо изменений.
Работает со всеми последними и более ранними версиями ОС Microsoft Windows, включая Windows 10, 8, 7 и т. Д.

Последние строки

Данные всегда важны для всех нас, и повреждение файла базы данных SQL MDF может вызвать проблемы у пользователей. Чтобы преодолеть и решить проблему повреждения, здесь мы объяснили руководство и автоматизированное решение восстановить поврежденный файл базы данных SQL. Может быть трудно выполнить восстановление MDF файла вручную, потому что это требует сильных технических знаний, а иногда и не устраняет повреждение. По этой причине рекомендуется выбрать автоматическое решение для быстрого и безопасного результата.

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

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

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

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

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

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

Статья Gail Shaw «Help, my database is corrupt. Now what?», перевод которой я запостил на прошлой неделе, вызвала, вроде бы, определенный интерес, но она, увы, не содержала «практики». Да, там написано как можно спасти данные, но нет никаких примеров.
Изначально я хотел сделать еще один перевод все того же автора, но, подумав, решил написать пост «от себя», как бы «по мотивам». Причины, побудившие меня поступить так, я опишу в конце поста, в примечаниях.

Восстановление баз данных в SQL Server

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

SQL Server предоставляет множество возможностей для восстановления баз данных. Во-первых, это восстановление базы данных целиком — оно может занимать довольно много времени (зависит от размера БД и скорости жестких дисков). Во-вторых, восстановление отдельных файловых групп, либо файлов, если ваша БД состоит из нескольких файловых групп (или, соответствено, файлов). В этом случае, есть возможность восстановления только поврежденных частей БД, не затрагивая остальных. Эти два вида восстановления БД используются довольно часто и затрагиваться в дальнейшем не будут.
В-третьих, в SQL Server 2005 появилась возможность восстановления отдельных страниц БД — в этом случае из бэкапа будут восстановлены только указанные страницы. Такое восстановление будет особенно актуально, если DBCC CHECKDB найдет несколько поврежденных страниц в какой-нибудь огромной таблице, «лежащей» в здоровенном файле. За счет того, что восстанавливаться будет не весь файл, и даже не вся таблица, а только несколько страниц — время простоя может быть значительно сокращено.

Требования и ограничения

Модель восстановления и доступность резервных копий журнала транзакций

Самое главное, что нужно помнить — для восстановления отдельных страниц, база данных должна использовать полную (full) модель восстановления, либо модель восстановления с неполным протоколированием (bulk-logged). Если ваши базы находятся в простой (simple) модели восстановления — дальше вы можете уже и не читать.
Второе требование — ваши полные бэкапы и бэкапы журнала транзакций должны образовывать неразрывную цепочку журналов (log chain). Если вы никогда не выполняете команду BACKUP LOG WITH TRUNCATE_ONLY (NO_LOG) и не переключаетесь в простую модель восстановления для того, чтобы уменьшить журнал транзакций, и у вас есть ВСЕ резервные копии журнала транзакций с момента последней полной резервной копии не содержащей поврежденных страниц (включая эту самую полную резервную копию) — за цепочку журналов можно не волноваться.
В модели восстановления с неполным протоколированием, теоретически, восстановление отдельных страниц должно работать нормально в том случае, если соблюдаются условия описанные выше, и восстанавливаемые страницы не изменялись операциями, выполняемыми с минимальным протоколированием.

Редакции SQL Server

Восстановление страниц возможно в любой редакции SQL Server, но для редакций Enterprise Edition и Developer Edition возможно восстановление поврежденных страниц on-line, т.е. к базе данных, во время восстановления, можно обращаться (и более того, обращаться можно даже к той таблице, к которой относятся восстанавливаемые в данный момент страницы, если сами эти страницы не будут «затрагиваться» — в противном случае, запрос завершится ошибкой). Для редакций «ниже» Enterprise Edition, восстановление страниц проходит в режиме off-line и база данных, на время восстановления, становится недоступной.

Тип поврежденной страницы

Собственно, восстановление

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

Портим БД

Для экспериментов я буду использовать базу данных AdventureWorks, которая поставляется вместе с SQL Server. Если вы не устанавливали ее, при желании, можно скачать здесь. Перевожу ее в модель восстановления full:
убеждаюсь, что ошибок в ней еще нет:
и создаю полный бэкап:

В этой базе данных я создаю таблицу crash.
Поле типа varchar мы и будем портить, для того, чтобы проверить что произойдет, если вдруг SQL Server обнаружит в нем не те данные, которые он сам туда записал.
Прежде чем что-то испортить, надо это чем-то заполнить. Я забиваю в созданную таблицу левые данные.
Теперь делаю резервную копию журнала транзакций:

Теперь немного изменим данные:

Итак, все готово. Отсоединяем БД и открываем mdf-файл FAR'ом (или чем вам удобнее), ищем в нем строку «zzzzzzz» и заменяем несколько 'z' на произвольные символы:

Теперь, когда БД испорчена, подсоединяем ее. И, да, я помню, что в предыдущей статье было четко сказано, что отсоединять/присоединять БД не стоит. Но в нашем случае это абсолютно «безопасно» — база данных в «suspect» не упадет.

Ищем ошибки

Итак, испорченная БД успешно вернулась в строй. Снова запустим проверку целостности:
В результате то, чего мы ждали (обязательно запоминайте номера поврежденных страниц!):

Смириться с потерей данных и выполнить DBCC CHECKDB('AdventureWorks', REPAIR_ALLOW_DATA_LOSS)
Сделать бэкап активной части журнала транзакций и восстановить БД целиком — в результате потери данных не будет, но это займет продолжительное время
Сделать бэкап активной части журнала транзакций и восстановить только одну(!), поврежденную, страницу

Восстанавливаем поврежденную страницу

В первую очередь нам надо сделать бэкап заключительного фрагмента журнала транзакций (tail backup). При этом, если у вас Enterprise Edition, вы можете не добавлять параметр NORECOVERY, который переведет БД в состояние «restoring», поскольку эта редакция поддерживает on-line восстановление страниц. Более того, если у вас резервные копии журнала транзакций выполняются на регулярной основе, чтобы не нарушать цепочку журналов, в редакции Enterprise Edition, вы можете сделать COPY_ONLY бэкап.
Я же иду по пути off-line восстановления и выполняю:

Теперь, можно восстанавливать поврежденную страницу. В первую очередь, используем полный бэкап (aw_full_ok1.bak):

В итоге, имеем:

Обратите внимание на то, что необходимо использовать опцию NORECOVERY, поскольку нам предстоит еще накатывать на нее бэкапы журнала транзакций.
и

Вроде бы все прошло успешно, запускаем DBCC CHECKDB и…

Восстановление прошло успешно.
Обратите внимание, что время простоя сокращается за счет того, что из полного бэкапа мы восстанавливаем не всю БД, а только поврежденные страницы (если бы я восстанавливал бэкап целиком — бэкап восстановился бы за 8,5 секунд, но, чем больше размер БД — тем больше будет разница во времени). Счастливчики с SQL Server Enterprise Edition, использующие on-line восстановление, так же сэкономят время на восстановлении из бэкапов лога, а при off-line восстановлении, увы, журналы будут обрабатываться целиком.
Стоит так же добавить, что в SQL Server 2005, 2008, 2008 R2 восстановление отдельной страницы возможно только с помощью T-SQL, в Denali появилась возможность делать это через GUI.

А если все-таки DBCC CHECKDB?

На всякий случай я решил проверить что сделает SQL Server, если я запущу DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS. Все та же ошибка:

Сначала переводим БД в режим SINGLE_USER:
А затем, запускаем восстановление:
В итоге:
Repair: The page (1:20455) has been deallocated from object ID 1883153754, index ID 0, partition ID 72057594054246400, alloc unit ID 72057594061651968 (type In-row data).
Ага, SQL Server удалил «испорченную» страницу. Переводим БД в режим MULTI_USER, чтобы она стала доступной для всех и проверяем что пропало:

Учитывая, что размер страницы в SQL Server 8КБ, а для пользовательских данных доступно чуть меньше — то все закономерно, таблица «похудела» на 7 записей (в начале их было 99999). Поскольку на этой таблице не было кластерного индекса, данные могли храниться в произвольном порядке, т.е. мы даже не могли узнать какие данные будут потеряны.

Читайте также: