КАК ВОССТАНОВИТЬ БАЗУ ИЗ MDF И LOG ФАЙЛОВ? – Технологии – Базы данных
Как восстановить базу данных из MDF в SQL Server 2005?
У меня есть файл MDF и нет файлов LDF для базы данных, созданной в MS SQL Server 2005. Когда я пытаюсь прикрепить файл MDF к другому SQL Server, я получаю следующее сообщение об ошибке.
The log cannot be rebuilt because there were open transactions/users when the database was shutdown, no checkpoint occurred to the database, or the database was read-only. This error could occur if the transaction log file was manually deleted or lost due to a hardware or environment failure.
Я хотел бы выполнить один из следующих вариантов:
- прикрепите базу данных без потери данных (маловероятно, но сэкономит мне некоторое время).
- прикрепите базу данных с потерей данных (независимо от того, какие транзакции были открыты растеряться.)
- восстановить только схему (без данных) из файла MDF.
какие команды SQL я могу попытаться снова запустить свою базу данных?
8 ответов
Я нашел следующий документ о Эксперты Обмен.
patrikt: У вас будет потеря данных, но это можно сделать.
вот детали, которые охватывают части 2) и 3) в случае повторного создания журнала не работает, что может произойти, если файл MDF поврежден.
вы можете восстановить данные и структуру, только прочитав файл MDF с помощью стороннего инструмента, который может декодировать то, что написано как двоичные данные, но даже с такими инструментами вы не всегда можете выполнить эту работу полностью.
в таких случаях можно попробовать Восстановление ApexSQL. Из того, что я знаю, это единственный инструмент, который может выполнять такую работу но это довольно дорого.
гораздо лучше попытаться восстановить их из любых старых резервных копий, если они у вас есть.
из поста на форумах SQL Server прикреплять MDF без LDF:
Если вы хотите прикрепить MDF без LDF, то вы можете следовать шагами ниже Он протестирован и работает нормально
создайте новую базу данных с тем же именем и теми же файлами MDF и LDF
остановите sql server и переименуйте существующий MDF в новый, скопируйте исходный MDF в это место и удалите LDF файлы.
запустить SQL Server
теперь ваша база данных будет помечена как suspect 5. Обновление системной обновить в аварийный режим. Это не будет использовать файлы журнала в start up
перезапустите sql server. теперь база данных будет находиться в аварийном режиме
теперь выполните недокументированный DBCC для создания файла журнала
DBCC REBUILD_LOG(dbname,’c:dbname – . ldf’) — недокументированный шаг к создайте новый файл журнала.
(замените имя dbname и имя файла журнала на основе требования ur)
перезапустите SQL server и посмотрите, что база данных находится в сети.
обновление: DBCC REBUILD_LOG не существует SQL2005 и выше. Это должно сработать:
вы пытались игнорировать ldf и просто прикрепить mdf:
процедура sp_attach_single_file_db [ @значение dbname = ] ‘имя_бд’ , [ @physname = ] ‘параметр physical_name’
Я не знаю точно, что произойдет с вашими открытыми транзакциями (возможно, просто потеряно), но это может вернуть ваши данные в интернет.
просто у меня была эта проблема, но ни один из вышеперечисленных ответов не работал для меня.
но вместо этого я нашел это, которое сработало, и поэтому я подумал, что поделюсь этим для всех остальных:
нашел другой способ, который работает полностью:
- создайте новую базу данных с тем же именем в расположении базы данных по умолчанию.
- остановить SQL server.
- скопируйте старый файл mdf, чтобы перезаписать вновь созданный файл mdf и удалить новый файл ldf
- запустите SQL Server, база данных будет в аварийном режиме
- отсоединить базу данных аварийного режима
- скопируйте исходный файл ldf в расположение базы данных по умолчанию (где новый файл LDF как созданный и удалили в шаге 3 выше.
- прикрепите файл MDF базы данных.
Я получил рабочую базу данных после попытки всего вышеперечисленного, что не удалось для меня.
Я надеюсь, что это легко сделать так,
- открыть SQL Server
- Нажмите Кнопку Создать Запрос
выполните следующий запрос
sp_attach_single_file_db @dbname= ‘dbname’,@physname=’C:Databasedbname – . MDF’
здесь dbname – вы хотите показать в Обозревателе объектов, где @physname – это локальное расположение файла mdf.
надеюсь, это поможет кто-то, я сделал выше, получил как структуру, так и данные.
протестировано в Sql Server 2000 и 2008. В Sql Server 2000 он не работает, но отлично работает в 2008 году.
Программное обеспечение компьютерной базы данных, такое как Microsoft SQL Server, выгодно для всех типов предприятий, поскольку делает ведение записей быстрым, гибким и безопасным. SQL Server позволяет отключить базу данных от программы основного сервера, что позволяет создавать безопасные резервные копии или отправлять данные в филиалы. После отключения базы данных ее необходимо восстановить из ее файла .MDF в процессе, называемом «вложение». SQL Server предлагает два способа присоединения файла .MDF: через графический интерфейс программы Management Studio или с помощью типовых текстовых команд Transact-SQL.,
Запустите SQL Server Management Studio
Нажмите кнопку «Пуск». Переместите курсор мыши в меню «Все программы», затем найдите и нажмите «Microsoft SQL Server», чтобы открыть список программ SQL Server.
Нажмите «SQL Server Management Studio», чтобы открыть диалоговое окно «Подключение к серверу».
Выберите сервер в вашей сети. Установите в раскрывающемся списке «Аутентификация» значение «Аутентификация Windows» и нажмите кнопку «Подключиться».
Восстановить с графическим интерфейсом
Щелкните правой кнопкой мыши «Базы данных» и выберите «Прикрепить», чтобы открыть диалоговое окно «Прикрепить базы данных».
Нажмите кнопку «Добавить», чтобы открыть диалоговое окно «Поиск файлов базы данных».
Введите полное имя файла .MDF, включая полный путь к устройству и каталогу, как показано в следующем примере:
c: data files my_data.mdf
Нажмите кнопку «ОК». SQL Server Management Studio загружает базу данных из файла .MDF.
Восстановить с помощью Transact-SQL
Нажмите «Новый запрос» на главной панели инструментов Management Studio. Это открывает большую текстовую область на правой стороне экрана.
Щелкните в текстовой области и введите инструкцию Create Database, используя в качестве руководства следующий код Transact-SQL:
CREATE DATABASE MyDatabase ON (FILENAME = ‘c: data files my_data.mdf’), (FILENAME = ‘c: data files my_data.ldf’) FOR ATTACH;
Нажмите кнопку «Выполнить» на панели инструментов Transact-SQL, расположенной под основной панелью инструментов Management Studio. Символ кнопки «Выполнить» представляет собой направленный треугольник. SQL Server Management Studio восстанавливает базу данных.
КАК ВОССТАНОВИТЬ БАЗУ ИЗ MDF И LOG ФАЙЛОВ? – Технологии – Базы данных
Вопрос
Ответы
ну тогда молитесь 🙂 т.к. документированного способа нет. но можно попробовать:
1) создать новую БД с именем вашей БД
2) подсунуть копию ldf-файла (именно копию. сам файл не загубите 🙂 )
3) в случаи успешного рестарта, снять бэкап лога
4) поднять ваш старый полный бэкап, попробовать накатить бэкап лога
ЗЫ: Все системные администраторы делятся на две категории: на тех кто не делает бэкапы и тех кто их уже делает
- Помечено в качестве ответа Руслан Абдрахимов 25 февраля 2014 г. 13:33
Все ответы
А файлы mdf(ndf) есть? Есть бэкап лога?
А каким образом у вас остался файл .ldf и при этом нет файла .mdf? Ведь БД может существовать только если есть, как минимум оба этих файла. Вы уверены, что этот файл вообще рабочий и от вашей БД?
ну тогда молитесь 🙂 т.к. документированного способа нет. но можно попробовать:
1) создать новую БД с именем вашей БД
2) подсунуть копию ldf-файла (именно копию. сам файл не загубите 🙂 )
3) в случаи успешного рестарта, снять бэкап лога
4) поднять ваш старый полный бэкап, попробовать накатить бэкап лога
ЗЫ: Все системные администраторы делятся на две категории: на тех кто не делает бэкапы и тех кто их уже делает
- Помечено в качестве ответа Руслан Абдрахимов 25 февраля 2014 г. 13:33
Лог получилось подменить, тока при создание бэкапа лога не удается создать
Восстановление базы MS SQL после удаления файла логов _log.ldf
Мы столкнулись с неприятной ситуацией когда «случайно» был удален файл логов базы данных MS SQL dbname_log.ldf. А работоспособность базы нужно восстанавливать, потому как актуальных резервных копий нет… Конечно не излишне будет повториться, что актуальные резервные копии важных баз, как впрочем и любой другой информации, должны быть всегда и лучше в избытке)
Первое, что было сделано — служба SQL Server была остановлена, и скопирован оставшийся файл данных базы.
После база была удалена и было испробовано приаттачить файл с данными к новой базе dbname без файла логов
На что была получена ошибка
Сообщение 5120, уровень 16, состояние 101, строка 1
Не удалось открыть физический файл «E:SQLLOGdbname_log.ldf». Ошибка операционной системы 32: «32(Процесс не может получить доступ к файлу, так как этот файл занят другим процессом.)».
Сбой при активации файла. Возможно, физическое имя файла «E:SQLLOGdbname_log.ldf» неправильное.
Не удается перестроить журнал, поскольку во время завершения работы базы данных существовали открытые транзакции или подключенные пользователи, для базы данных отсутствуют контрольные точки либо она доступна только для чтения. Эта ошибка может возникать, если журнал транзакций был удален вручную или оказался потерян в результате сбоя оборудования или аварии.
Сообщение 1813, уровень 16, состояние 2, строка 1
Невозможно открыть новую базу данных «dbname». Операция CREATE DATABASE прервана.
Второе, что было сделано. Была создана новая, одноименная с удаленной, база данных dbname. Служба SQL Server была остановлена и вновь созданный с базой файл данных dbname.mdf был заменен на прежний. Служба сервера запущена.
Далее выполняем запрос
Видим длинный лог, который оканчивается
CHECKDB обнаружил 0 ошибок размещения и 0 ошибок согласованности в базе данных «dbname».
Выполнение DBCC завершено. Если DBCC выдает сообщения об ошибках, обратитесь к системному администратору.
То есть мы имеем работоспособную базу MS SQL. Далее было сделано следующее. Поскольку эта база являлась базой программы 1С, из самой 1С был выполнен экспорт «Выгрузить информационную базу…» который прошел успешно. SQL база была удалена, создана одноименная новая, подключена к 1С. В 1С был выполнен импорт через «Загрузить информационную базу…».
Завершающим шагом стала настройка регулярного резервного копирования.
More In DB
Создание дампа базы MySQL из командной строки
Очень часто, перед внесением каких либо изменений, требуется сделать резервную копию базы данных MySQL или просто перенести базу на другой сервер. Самый простой способ сделать…read more →
Установка Apache, php, mysql
Предварительно проверяем обновления # yum update Устанавливаем пакеты # yum install httpd mod_ssl php php-common php-gd php-mysql php-xml mysql mysql-server Конфигурируем на свой вкус /etc/httpd/conf/httpd.conf – настройки…read more →
Как установить, изменить, сбросить пароль root в MySQL
Очень часто, при работе с MySQL, нужно установить, сбросить или изменить пароль root. Для всех этих случаев нужно воспользоваться командой mysqladmin Установка пароля root Чтобы впервые…read more →
КАК ВОССТАНОВИТЬ БАЗУ ИЗ MDF И LOG ФАЙЛОВ? – Технологии – Базы данных
Есть рабочая база данных, есть ее резервная копия в виде bak файла, необходимо данную резервную копию восстановить во временную базу данных, при этом не затрагивая рабочую, проблема в том, что резервную копию не получится восстановить в базу у которой логические имена отличаются от оригинальных, а SQL один и требуется рабочая версия базы и ее временная копия.
Решение
Создание новой временной БД
- Необходимо открыть Microsoft SQL Management Studio – Databases – ПКМ – New Database;
- В поле Database Name указать имя новой базы данных;
- В полях Logical Name указать имена точно такие же, как у оригинальной базы;
- В полях File Name указать другое месторасположение БД и лог файла (отличное от расположения оных оригинальной базы);
Восстановление
- После создания необходимо в контекстном меню базы выбрать – Tasks – Restore – Database.
- Отметить From Device – Выбрать требуемый bak файл;
- В полях Select the backup sets to restore отметить параметры в столбце Restore;
- На вкладке Options отметить параметр – Overwrite the existing database (WITH REPLACE);
- Обязательно в полях Restore As указать месторасположение файла БД и лог файла временной базы данных;
Комментарии
Спасибо за инструкцию, помогла продублировать базу данных.
Есть несколько моментов, которые поставили в тупик. Опишу здесь свои поправки.
Создание новой временной БД
1. – непонятно к чему добавлена аббревиатура ПКМ
3. – В полях Logical Name указать имена точно такие же, как и логические имена у оригинальной базы (смотрите в свойствах оригинальной базы (если имя базы BASE, то логические имена у меня BASE_Data и BASE_Log, хотя могут совершенно не совпадать с именем базы)
4. – В полях File Name задать новые имена для файла базы данных и лог файла. Например, BASE2.mdf и BASE2_1.ldf. В полях Path указать путь где по умолчанию хранятся файлы базы данных, т.е. такой же, как и у оригинальной базы данных.
Восстановление
5. – На вкладке Files обязательно в полях Restore As указать месторасположение файла БД и лог файла временной базы данных;
Восстановление базы 1С под SQL-Server
Иногда приходится столкнуться с ситуацией, когда плоды многолетней работы, находящиеся в 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:DataDemoXMB_Data.MDF’,
c. @filename2 = ‘E:DataDemoXMB_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:mssql7dataDemoXMB_Dat.mdf’
При выполнении этих команд, создастся файл DemoXMB_Log.ldf в том же каталоге где и база, размером 1MB и авторасширением.
Если есть *.MDF и *.LDF-файлы, или данные хранятся более чем в одном физическом файле (общее количество подключаемых физических файлов не должно превышать 16-ти), то следует использовать ХП “sp_attach_db”
Например:
use master
EXEC sp_attach_db @dbname = ‘DemoXMB’,
@filename1 = ‘c:mssql7dataDemoXMB_Dat.mdf’,
@filename1 = ‘c:mssql7dataDemoXMB_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 :).
