Как восстановить ldf файл sql

Как восстановить базу данных из файла MDF только в SQL Server?

Файл MDF — это основной файл хранилища SQL Server, в котором хранятся все физические данные. SQL Server также использует некоторые другие файлы LDF (файл журнала транзакций), NDF (файл вторичного хранилища). Теперь поговорим о том, как восстановить базу данных из файла MDF без файла LDF. Есть некоторые ситуации, когда нам нужно восстановить данные из файла MDF, например, если мы переносим SQL Server, если мы отказываемся использовать старые серверы SQL, и т. Д. В таких ситуациях мы должны прикрепить файл MDF в SQL Server.

Теперь вопрос в том, как прикрепить файл MDF к SQL серверу? — Есть два способа выполнить эту задачу, в этом разделе мы рассмотрим оба метода восстановления базы данных из файла MDF.

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

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

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

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

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

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

Чтобы прикрепить файл MDF в SQL Server с помощью T-SQL, вы выполнили следующий сценарий T-SQL —

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

Используя вышеуказанные решения, вы можете легко прикрепить файл MDF в SQL Server, но иногда из-за некоторых ошибок пользователь не может восстановить MDF в SQL Server. Некоторые ошибки обсуждаются ниже —

Учитывайте запросы пользователя —

Решение — Вы получаете сообщение об ошибке 5123 от SQL Server, потому что есть проблемы с разрешениями в вашем MDF или файле базы данных. Из-за этих проблем вы не можете прикрепить файл MDF в SQL Server или не можете восстановить базу данных из файла MDF в SQL Server. Чтобы решить эту ошибку, вы должны изменить разрешение в качестве владельца файла MDF, а затем прикрепить файл на сервере SQL, следуя приведенным выше решениям.

Решение — Эта ошибка возникает, когда информация заголовка файла MDF повреждена, и база данных становится недоступной, поэтому для решения этих проблем вам необходимо восстановить файл MDF. Чтобы удалить ошибку 5172, вам необходимо использовать Recovery Tool.

После восстановления файла 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.

Вывод

Источник

Как восстановить ldf файл sql

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

Сбой и восстановление базы данных TempDB

TempDB – это системная база для временных таблиц. При запуске службы сервера БД, база данных TempDB создаётся заново. В случае выхода из строя накопителя, на котором размещаются файлы базы TempDB, служба не будет запущена, так как этот накопитель более недоступен и создать базу TempDB SQL Server не сможет. Чтобы это исправить, можно установить новый накопитель и назначить для него в системе ту же букву, что была у потерянного накопителя (при этом полный путь к файлам базы TempDB должен быть восстановлен: нужно создать соответствующие каталоги).
В случае, если путь к файлам базы TempDB восстановить не представляется возможным, нужно указать серверу БД другой путь (существующий) для этой базы. Чтобы это сделать необходимо:

Описание параметры запуска:
-m: запускает SQL Server в однопользовательском режиме, Контрольная точка не срабатывает;
-с: ускоряет запуск из Командной строки. Запускается в отдельном окне как приложение, а не как служба;
-f: запускает SQL Server в минимальной конфигурации;
-T: включает определённый флаг трассировки. 3608: запрещает автоматически запускать и восстанавливать все БД, кроме master (используется для перемещения системных БД).
4022: обход автоматически запускаемых процедур.

2) Подключиться к запущенному серверу БД с помощью программы sqlcmd.exe:

Описание параметров sqlcmd:
-S: имя сервера БД к которому происходит подключение;
-U: Логин (имя входа) под которым происходит подключение к серверу;
-P: пароль.

3) Изменить пути к файлам БД TempDB с помощью T-SQL (указать новые существующие пути):

ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, FILENAME = ‘С:\TempDB\tempdb.mdf’) ;
GO
Ответ сервера на успешный запрос:
Файл «tempdb» был изменен в системном каталоге. Данный новый путь будет использ
ован при следующем запуске этой базы данных.

ALTER DATABASE tempdb MODIFY FILE (NAME = templog, FILENAME = ‘C:\TempDB\templog.ldf’) ;
GO

Ответ сервера на успешный запрос:
Файл «templog» был изменен в системном каталоге. Данный новый путь будет использ
ован при следующем запуске этой базы данных.

Для проверки изменений можно выполнить следующий запрос:
SELECT name, physical_name AS CurrentLocation, state_desc FROM sys.master_files WHERE database_id = DB_ID(N’tempdb’);
GO

4) Закрыть sqlcmd и командное окно сервера SQL Server через нажатие клавиш Ctrl+C;

5) Запустить сервер SQL Server в нормальном режиме (через запуск службы).

Сбой и восстановление баз данных msdb и model

msdb – это системная база, где хранится вся информация по заданиям, расписаниям, история резервных копий для всех БД и т.д. Нужна для работы службы SQL Server Agent.
model – это системная база, используется, как шаблон для всех создаваемых пользовательских БД.
В случае сбоя этих системной базы, а также в случае перестроения системной БД master необходимо выполнить восстановления этих баз из резервных копий. Поэтому необходимо постоянно создавать резервные копии этих баз (особенно базы msdb), рекомендуется создавать полные копии после каждого изменения.

Для восстановления системных баз msdb и model необходимо выполнить скрипт T-SQL (через панель объектов в Management Studio не получится), его можно выполнить либо в Management Studio, либо через утилиту sqlcmd.exe.

Скрипт для восстановления БД msdb (аналогичный скрипт будет работать и для БД model):

RESTORE DATABASE [msdb] FROM DISK = N’D:\Backup\SYS\msdb.rez’ WITH FILE = 1,
MOVE N’MSDBData’ TO N’C:\MSDBData.mdf’,
MOVE N’MSDBLog’ TO N’C:\MSDBLog.ldf’,
NOUNLOAD, REPLACE
GO

Дополнительный материал:
Вопросы восстановления БД msdb и model:
http://msdn.microsoft.com /ru-ru/library/ms190749.a spx
Вопросы резервного копирования и восстановления системных баз:
http://msdn.microsoft.com /ru-ru/library/ms190190.a spx

Сбой и восстановление базы данных master

master – это главная системная база SQL Server, в ней хранится вся конфигурация сервера и конфигурация подключенных БД. При сбое этой базы сервер SQL Server не может быть запущен (даже в минимальной конфигурации).
При попытке запустить Сервер БД в журнале событий приложения появятся ошибка:
Во время запуска при открытии файла «C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\ma ster.mdf» для получения данных конфигурации произошла ошибка 2(Не удается найти указанный файл.). Возможно, ошибка вызвана неверным параметром запуска. Проверьте параметры запуска и исправьте или удалите их при необходимости.

Для восстановления работоспособности БД master (и всего сервера БД) нужно выполнить:

1. Перестроение системных БД
Для выполнения этой операции нужен дистрибутив SQL Server 2008. Нужно запустить инсталлятор setup.exe со специальными параметрами:

Выполнять эту команду следует из командной строки(cmd.exe), чтобы отслеживать процесс восстановления (если будут ошибки, то они появятся в виде сообщений в этом же окне). В случае успешного выполнения этой операции в командной строке не будет сообщений.

2. Восстановление системной БД master из резервной копии

Для восстановления БД master необходимо запустить сервер SQL Server в однопользовательском режиме (сначала нужно остановить службу MSSQLSERVER):

Затем нужно подключиться к серверу под sa (можно из Management Studio) и выполнить инструкция T-SQL:

RESTORE DATABASE [master] FROM DISK = N’D:\ Backup\SYS\master.rez’ WITH FILE = 1 WITH REPLACE
GO

3. После восстановления БД master необходимо восстановить системные БД msdb и model (см. выше).

Источник

Утилита для восстановления базы данных MS SQL

Как восстановить базу данных SQL Server

Recovery Toolbox for SQL Server

Recovery Toolbox for SQL Server поможет исправить поврежденные MDF файлы MS SQL Server всех версий.

Как восстановить поврежденное хранилище Microsoft SQL Server

Как исправить нерабочую базу данных MS SQL Server?

Recovery Toolbox for SQL Server это программа для восстановления поврежденных файлов баз данных MS SQL Server.

Возможности ПО для восстановления MDF файлов:

Специальная, оптимизированная утилита восстановления SQL Server способна исправить многие типы повреждений баз данных и *.mdf файлов.

Как вернуть базу данных SQL Server после повреждения

Для возвращения данных из поврежденной базы данных SQL Server можно воспользоваться последней резервной копией или попытаться использовать Recovery Toolbox for SQL Server. С большой вероятностью Recovery Toolbox for SQL Server может вернуть базу данных SQL Server в исходное состояние до повреждения. Для проверки этой гипотезы достаточно:

Как исправить базу данных SQL Server

Требования:

Как импортировать сохраненные SQL скрипты в базу данных?

Существует два способа сохранить данные, которые были получены с помощью программы Recovery Toolbox for SQL Server:

Пожалуйста обратите внимание, что SQL скрипты различаются, несмотря на тот факт, что они основываются на тех же самых файлах базы данных. Это происходит из-за особенностей синтаксиса как в запросах, которые выполняются при прямом соединении с сервером с помощью ADO, так и в SQL запросах, выполняемых в среде Query Analyzer’а, которая поставляется вместе с MS SQL Server (использование «:», команды Go и т.д.). Первый способ более надежен, что же касается второго способа, он более удобен.

Конвертация данных в скрипты и сохранение их на диск

Если вы выбрали сохранение данных на диск, Recovery Toolbox for SQL Server создаст подкаталог, включающий название исходного MDF файла, этот подкаталог создается в каталоге, указанном пользователем, все скрипты будут помещены туда. Все скрипты создаются в соответствии с правилом, названия состоят из слова и цифры. Слово означает роль скрипта, цифра указывает на его номер. Существует множество типов скриптов, например:

Порядковый номер скрипта не содержит никаких полезных данных, а также не указывает на последовательность выполнения скриптов или какую-либо другую информацию. Эти номера используются только для того, чтобы разделять данные и сохранять их во множество небольших документов, вместо одного большого файла. Пользователи могут определить максимальный размер файла с SQL скриптом. Кроме того, пользователям стоит обратить внимание на нумерацию Data файлов. Необходимо отметить, что каждый файл Data типа может включать данные только одной таблицы. Файлы с последовательными номерами содержат все данные для каждой из таблиц.

Внимание: Если в некоторых файлах отсутствуют номера, это означает, что некоторые таблицы не содержат никаких данных.

На этом рисунке вы можете видеть рекомендуемую последовательность исполнения:

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

Источник

Восстановление базы 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:\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

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

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

ВНИМАНИЕ!

Завтра на «Клерке» стартует обучение на онлайн-курсе повышения квалификации для получения удостоверения, которое попадет в госреестр. Тема курса: управленческий учет.

Повысьте свою ценность как специалиста в глазах директора. Смотреть полную программу

Источник

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

В этом разделе описано, как восстановить базу данных SQL Server в новую папку и при необходимости переименовать ее в SQL Server с помощью SQL Server Management Studio (SSMS) или Transact-SQL. Эта процедура позволяет переместить базу данных по новому пути каталога или создать копию базы данных на том же или другом экземпляре сервера.

Перед началом работы

Ограничения

Предварительные требования

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

Чтобы восстановить зашифрованную базу данных, требуется доступ к сертификату или асимметричному ключу, использовавшемуся для шифрования этой базы данных. Без сертификата или асимметричного ключа восстановить базу данных невозможно. Необходимо сохранять сертификат, используемый для шифрования ключа шифрования базы данных, пока существует потребность в резервной копии. Дополнительные сведения см. в статье SQL Server Certificates and Asymmetric Keys.

Рекомендации

безопасность

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

Permissions

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

Восстановление базы данных в новую папку и при необходимости ее переименование с помощью SSMS

После подключения к соответствующему экземпляру компонента Компонент SQL Server Database Engineв обозревателе объектов разверните дерево сервера, щелкнув имя сервера.

База данных

Устройство

В списке Источник: Устройство: База данных выберите имя базы данных, из которой нужно восстановить резервные копии.

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

Дополнительные сведения о столбцах сетки Резервные наборы данных для восстановления см. в статье Восстановление базы данных (страница «Общие»).

На странице Параметры настройте параметры, если в этом есть необходимость. Дополнительные сведения об этих параметрах см. в статье Восстановление базы данных (страница «Параметры»).

Восстановление базы данных в новую папку и при необходимости ее переименование с помощью T-SQL

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

RESTORE FILELISTONLY FROM WITH FILE = номер_файла_резервного_набора

Эта инструкция также поддерживает некоторые параметры WITH. Дополнительные сведения см. в разделе Инструкция RESTORE FILELISTONLY (Transact-SQL).

Используйте инструкцию RESTORE DATABASE для восстановления полной резервной копии базы данных. По умолчанию файлы данных и журналов восстанавливаются в исходных местоположениях. При перемещении базы данных используйте параметр MOVE, чтобы переместить каждый файл базы данных и избежать конфликтов с существующими файлами.

Базовый синтаксис Transact-SQL для восстановления базы данных в новом месте и с новым именем:

В следующей таблице аргументы инструкции RESTORE описаны применительно к восстановлению базы данных в новом месте. Дополнительные сведения об этих аргументах см. в разделе RESTORE (Transact-SQL).

новое_имя_базы_данных
Новое имя базы данных.

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

< DISK | TAPE >= имя_физического_устройства_резервного_копирования

< RECOVERY | NORECOVERY >
Если в базе данных используется модель полного восстановления, может возникнуть необходимость применить резервные копии журналов транзакций после восстановления базы данных. В этом случае укажите параметр NORECOVERY.

В противном случае используйте параметр RECOVERY, который применяется по умолчанию.

Если этот параметр не указан, по умолчанию используется первый резервный набор на устройстве резервного копирования.

Дополнительные сведения см. в подразделе «Указание резервного набора данных» раздела Аргументы инструкции RESTORE (Transact-SQL).

Примеры (Transact-SQL)

Пример создания полной резервной копии базы данных AdventureWorks2012 см. в разделе Создание полной резервной копии базы данных (SQL Server).

Источник