Главная › Восстановление файлов

Как восстановить mdf файл базы данных Microsoft SQL Server из состояния suspend

Восстановление и предотвращение утери файлов Microsoft SQL Server

Читайте, как восстановить удалённую базу MSSQL используя встроенные в приложение инструменты или сторонние программы
. Рассмотрим причины, по которым база может быть утеряна, а также способы восстановления для каждого из них. SQL Server – это система управления реляционными базами данных (СУБД) от Microsoft, которая изначально разрабатывалась компанией как конкурент набиравшим популярность Oracle Database и MySQL.

Основным инструментом интерфейса SQL Server является Microsoft SQL Server Management Studio (SSMS).

Как и большинство СУБД Microsoft SQL Server поддерживает стандарт ANSI SQL. Но, СУБД от Microsoft также использует собственную реализацию стандарта – T-SQL.

Содержание:

Файлы системы Microsoft SQL Server

Файлы базы SQL Server по умолчанию сохраняются на диске С компьютера:

C:Program FilesMicrosoft SQL Server

Причём под каждую базу создаётся отдельная папка с её названием. Например, в нашем случае создано две базы данных Microsoft SQL Server: MSSQL13.SQLEXPRESS, MSSQL13.MSSQLHETMAN.

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

  • *.mdf
    – это первичный файл данных базы. В таком файле содержатся сведения, которые необходимы для запуска базы, ссылки на другие файлы базы, данные и объекты пользователя. В .mdf файле физически хранятся данные базы.
  • *.ndf
    – вторичные файлы данных базы, которые также используются системой для хранения данных базы.
  • *.ldf
    – файлы журнала транзакций (лог файлы).

Каждый из указанных файлов имеет название базы данных и хранится в папке DATA:

C:Program FilesMicrosoft SQL ServerНазвание_Базы_ДанныхMSSQLDATA

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

Причины утери данных MSSQL

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

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

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

Человеческий фактор
. Утеря данных в результате неумышленных действий пользователя или администратора системы.

Способы восстановления базы данных

Есть несколько способов резервирования и восстановления данных базы SQL Server. Использование каждого из них зависит от преследуемой цели: плановое создание бэкапа базы данных или восстановление из него при переносе базы данных на другую машину, или необходимость восстановления данных базы MSSQL в результате её утери или удаления.

Создать копию базы данных для дальнейшего восстановления можно как с помощью встроенных в Microsoft SQL Server Management Studio инструментов, так и вручную. Создание и восстановление базы данных из созданной вручную копии, это более быстрый процесс чем создание и разворачивание резервной копии, но не такой надёжный.

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

Для этого:

  • Запустите Диспетчер конфигурации SQL Server (Sql Server Configuration Manager)

  • Выберите Службы SQL Server

  • В правом окне диспетчера кликните правой кнопкой мыши на базе данных которую необходимо остановить и выберите «Остановить»
    .

  • Запустить базу данных можно аналогичным образом, выбрав пункт меню «Запустить»
    .

Также базу данных можно остановить и запустить с помощью команд:

  • В Transact-SQL: SHUTDOWN;
  • Из окна командной строки: Net stop MSSQLHETMAN
    Net start MSSQLHETMAN
    Где, MSSQLHETMAN
    – название базы данных

Восстановление удалённой базы с Hetman Partition Recovery

В случае утери или удаления базы данных SQL Server из компьютера, её можно восстановить при условии, что его диск сохранил свою работоспособность. Это можно сделать с помощью программы для восстановления данных жесткого диска Hetman Partition Recovery.

Чтобы восстановить утерянные файлы данных базы MS SQL Server:

  • Запустите Hetman Partition Recovery
    и просканируйте с её помощью диск на котором были сохранены файлы данных SQL Server

  • Перейдите с помощью проводника программы в папку с файлами данных базы

    • Восстановите необходимые *.mdf, *.ndf, *.ldf файлы данных

  • Присоедините восстановленные файлы данных к базе SQL Server используя функцию «Присоединить…»

    Для этого, войдите в базу данных и кликните правой кнопкой мыши на папке «Базы данных». Выберите меню «Присоединить…»
    / кнопка «Добавить»
    , после укажите *.mdf файл данных восстановленной базы и нажмите OK.

Однако стоит отметить, что в случае если база данных была удалена или утеряна в результате сбоя в работе компьютера (который мог послужить причиной форматирования диска или переустановки ОС), и на момент утери / удаления её работа остановлена не была, то дальнейший запуск такой базы может быть сопряжен с возникновением ошибок. Если восстановить необходимо вручную созданную раннее копию файлов базы данных, то проблем с её восстановлением и запуском не будет.

Как создать копию базы SQL Server для дальнейшего восстановления, импорта или переноса

Чтобы избежать утери данных базы MSSQL в случае возникновения непредвиденных обстоятельств, в случае необходимости импорта базы или её переноса из одной машины на другую, в Microsoft SQL Server Management Studio (SSMS) предусмотрен целый ряд инструментов на разные случаи, часть из которых мы уже упоминали в данной статье.

Создать резервную копию… / Восстановить

Чтобы создать резервную копию базы данных, кликните на папке с её названием правой кнопкой мыши и выберите Задачи
/ Создать резервную копию…

В результате, в папке Backup

C:Program FilesMicrosoft SQL ServerMSSQL13.MSSQLHETMANMSSQLBackup

будет создан *.bak
файл с резервной копией базы данных.

Чтобы восстановить резервную копию базы данных, кликните на папке с её названием правой кнопкой мыши и выберите Задачи
/ Восстановить
, и укажите путь к файлу резервной копии.

Импорт данных… / Экспортировать данные…

C помощью функции Импорта
/ Экспорта
данных Microsoft SQL Server можно скопировать данные из источника в файл назначения или сервер. Данная функция поддерживает такие источники данных:

  • SQL Server
  • Microsoft Access
  • Microsoft Excel
  • Неструктурированные файлы

Другими словами, из SQL Server базы данные можно экспортировать на другой SQL Server или в файл Access, Excel, неструктурированный файл. Из этих же источников можно импортировать данные в SQL Server.

Чтобы экспортировать данные базы, кликните на папке с её названием правой кнопкой мыши и выберите Задачи
/ «Экспортировать данные…»
.

После чего укажите с помощью открывшегося Мастера импорта и экспорта SQL Server, Источник и Куда копировать данные.

Импортировать данные в базу можно аналогичным образом, с помощью меню Задачи
/ «Импорт данных…»
.

Отсоединить… / Присоединить…

Самым подходящим способом создания копии базы данных для переноса её на другую машину, есть функция Отсоединить…
/ Присоединить…

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

Такие файлы данных можно перенести в другое удобное пользователю место без риска утери данных из соответствующей базы и подсоединить их к SQL Server другого компьютера (с версией не ниже отсоединённой).

Чтобы отсоединить базу данных, кликните на папке с её названием правой кнопкой мыши и выберите Задачи
/ «Отсоединить…»
/ Ok
.

Чтобы присоединить базу данных, кликните на папке «Базы данных»
правой кнопкой мыши и выберите «Присоединить…»
/ Добавить
, после чего укажите путь к *.mdf файлу базы данных которую необходимо присоединить.

Примечание
. В случае необходимости, с помощью Hetman Partition Recovery
можно восстановить файл резервной копии базы данных (*.bak), Иморта/Экспорта базы данных или файлы отсоединённой базы (*.mdf, *.ndf ,*.ldf) с дальнейшим их присоединением или восстановлением в Microsoft SQL Server.

Восстановление базы 1С под SQL-Server

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

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

Например:
use master EXEC sp_attach_single_file_db @dbname = ‘DemoXMB’, @physname = ‘c:mssql7dataDemoXMB_Dat.mdf’

Например:
use master EXEC sp_attach_db @dbname = ‘DemoXMB’, @filename1 = ‘c:mssql7dataDemoXMB_Dat.mdf’, @filename1 = ‘c:mssql7dataDemoXMB_Log.ldf’

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

Там же выполняем : 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

После этого стало возможно просмотреть таблицы базы из 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 :).

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

Автор: Коноплин Артем http://www.sysad.ru/

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

Задайте вопрос
Быстрый доступ
Системы управления базами данных Microsoft

 > 

SQL Server для администраторов

  • Вопрос

  • Упал виртуальный сервер, вчера подняли новый и накатили бекап за 12.02.14 число бекап, можно ли восстановить базу имея лог ldf за 24.12.14 число 
    25 февраля 2014 г. 3:12
    Ответить
    |
    Цитировать

Ответы

  • ну тогда молитесь 🙂 т.к. документированного способа нет…но можно попробовать:

    1) создать новую БД с именем вашей БД

    2) подсунуть копию ldf-файла (именно копию…сам файл не загубите 🙂 )

    3) в случаи успешного рестарта, снять бэкап лога

    4) поднять ваш старый полный бэкап, попробовать накатить бэкап лога

    ЗЫ: Все системные администраторы делятся на две категории
    : на тех кто не делает бэкапы и тех кто их уже делает

    http://www.t-sql.ru

    • Помечено в качестве ответа
      25 февраля 2014 г. 13:33
    25 февраля 2014 г. 5:50
    Ответить
    |
    Цитировать

Все ответы

  • А файлы mdf(ndf) есть? Есть бэкап лога?

    http://www.t-sql.ru

    25 февраля 2014 г. 4:01
    Ответить
    |
    Цитировать
  • Есть тока .ldf хотелось бы накатить этот лог на базу 
    25 февраля 2014 г. 4:43
    Ответить
    |
    Цитировать

  • А каким образом у вас остался файл .ldf и при этом нет файла .mdf? Ведь БД может существовать только если есть, как минимум оба этих файла. Вы уверены, что этот файл вообще рабочий и от вашей БД?

    http://www.t-sql.ru

    25 февраля 2014 г. 4:57
    Ответить
    |
    Цитировать
  • Все хранилось на разных дисках и по этому смогли тока вытащить 

    .ldf за 24.02.14 и остался бекап .
    bak за 12.02.14 а .mdf хранился на другом системном диске который упал и уже не восстановить все крутилось на hyper-v
    25 февраля 2014 г. 5:03
    Ответить
    |
    Цитировать

  • ну тогда молитесь 🙂 т.к. документированного способа нет…но можно попробовать:

    1) создать новую БД с именем вашей БД

    2) подсунуть копию ldf-файла (именно копию…сам файл не загубите 🙂 )

    3) в случаи успешного рестарта, снять бэкап лога

    4) поднять ваш старый полный бэкап, попробовать накатить бэкап лога

    ЗЫ: Все системные администраторы делятся на две категории
    : на тех кто не делает бэкапы и тех кто их уже делает

    http://www.t-sql.ru

    • Помечено в качестве ответа
      25 февраля 2014 г. 13:33
    25 февраля 2014 г. 5:50
    Ответить
    |
    Цитировать
  • Ну мы так и пытаемся сделать создаем новую бд восстанавливаем с бэкапа последнего и сейчас хотим подменить ему лог этот который остался, позже отпишусь что будет =(
    25 февраля 2014 г. 6:21
    Ответить
    |
    Цитировать

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

    нет, вы не читаете то, что я написал…лог нужно подменять НОВОЙ ПУСТОЙ БД…делать БЭКАП…и уже через накатывание ПОЛНЫЙ БЭКАП + БЭКАП ЛОГА восстанавливать вашу БД

    http://www.t-sql.ru

    25 февраля 2014 г. 6:33
    Ответить
    |
    Цитировать

  • Лог получилось подменить, тока при создание бэкапа лога не удается создать

    =================================== Действие Резервное копирование завершилось неудачно для объекта «Сервер» «SERV-ACKOH4».  (Microsoft.SqlServer.SmoExtended) —————————— Чтобы получить справку, щелкните: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=10.50.4000.0+((KJ_PCU_Main).120628-0827+)&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&EvtID=Резервное+копирование+Server&LinkId=20476 —————————— Расположение программы:    в Microsoft.SqlServer.Management.Smo.Backup.SqlBackup(Server srv)    в Microsoft.SqlServer.Management.SqlManagerUI.BackupPropOptions.OnRunNow(Object sender) =================================== System.Data.SqlClient.SqlError: Не удалось открыть базу данных «base_test» вследствие недоступности файлов, нехватки памяти или места на диске. Подробности см. в журнале ошибок SQL Server. (Microsoft.SqlServer.Smo) —————————— Чтобы получить справку, щелкните: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=10.50.4000.0+((KJ_PCU_Main).120628-0827+)&LinkId=20476 —————————— Расположение программы:    в Microsoft.SqlServer.Management.Smo.ExecutionManager.ExecuteNonQueryWithMessage(StringCollection queries, ServerMessageEventHandler dbccMessageHandler, Boolean errorsAsMessages)    в Microsoft.SqlServer.Management.Smo.BackupRestoreBase.ExecuteSql(Server server, StringCollection queries)    в Microsoft.SqlServer.Management.Smo.Backup.SqlBackup(Server srv)

    25 февраля 2014 г. 7:28
    Ответить
    |
    Цитировать

  • http://msdn.microsoft.com/en-us/library/ms179314.aspx

    ну и не спросил сразу, а какая модель восстановления вообще у вашей БД?

    http://www.t-sql.ru

    25 февраля 2014 г. 8:06
    Ответить
    |
    Цитировать
  • Полная
    25 февраля 2014 г. 8:20
    Ответить
    |
    Цитировать
  • Игра с бубном вообщем идет 
    25 февраля 2014 г. 10:56
    Ответить
    |
    Цитировать

  • ну вот если бы во время делали бэкапы, то проблем бы не было 🙂

    бэкап лога получилось сделать?

    http://www.t-sql.ru

    25 февраля 2014 г. 11:08
    Ответить
    |
    Цитировать

  • Упал виртуальный сервер, вчера подняли новый и накатили бекап за 12.02.14 число бекап, можно ли восстановить базу имея лог ldf за 24.12.14 число 

    Насколько я помню, даже при неработающей БД (из-за поврежденного/отсутсвующего файла данных) можно сделать реззервную копию журнала транзакций, если его файл цел (фича появилась в SQL 2000, и если ее не выпилили — должно сработать).

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

    PS Способ, кстати — вполне документированный.

    Слава России!

    • Изменено
      25 февраля 2014 г. 14:40
    25 февраля 2014 г. 14:39
    Ответить
    |
    Цитировать
  • Время вышло так ка пользователей нужно пускать в работу, пришлось восстановиться на 12 число, создали задание бэкапа и сегодня будем писать скрип что-бы бэкап копировался на хранилку воть, как то так серв просто раньше админил другой пользователей, теперь он в наших руках =)))
    26 февраля 2014 г. 10:37
    Ответить
    |
    Цитировать
Оценка статьи:
1 звезда2 звезды3 звезды4 звезды5 звезд (пока оценок нет)
Загрузка...
Поделиться с друзьями:
Поделиться
Отправить
Класснуть
Ссылка на основную публикацию
Похожие публикации
vosstanovim.website © 2023 Политика конфиденциальности Пользовательское соглашениеКарта сайта