SQL Server: база данных застряла в состоянии" восстановление"
Я создал резервную копию базы данных:
BACKUP DATABASE MyDatabase
TO DISK = 'MyDatabase.bak'
WITH INIT --overwrite existing
а затем попытался восстановить его:
RESTORE DATABASE MyDatabase
FROM DISK = 'MyDatabase.bak'
WITH REPLACE --force restore over specified database
и теперь база данных застряла в состоянии восстановления.
некоторые люди предположили, что это потому, что в резервной копии не было файла журнала, и его нужно было свернуть с помощью:
RESTORE DATABASE MyDatabase
WITH RECOVERY
кроме того, что, конечно, не удается:
Msg 4333, Level 16, State 1, Line 1
The database cannot be recovered because the log was not restored.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.
и именно то, что вы хотите в катастрофической ситуации, - это восстановление, которое не будет работа.
резервная копия содержит как данные, так и файл журнала:
RESTORE FILELISTONLY
FROM DISK = 'MyDatabase.bak'
Logical Name PhysicalName
============= ===============
MyDatabase C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDATAMyDatabase.mdf
MyDatabase_log C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDATAMyDatabase_log.LDF
20 ответов
вам нужно использовать WITH RECOVERY
опция, с вашей базой данных RESTORE
команда, чтобы привести вашу базу данных в режиме онлайн в рамках процесса восстановления.
Это, конечно, только если вы не собираетесь восстанавливать резервные копии журналов транзакций, т. е. вы хотите восстановить резервную копию базы данных, а затем иметь доступ к базе данных.
ваша команда должна выглядеть так,
RESTORE DATABASE MyDatabase
FROM DISK = 'MyDatabase.bak'
WITH REPLACE,RECOVERY
вы можете иметь больше успеха с помощью мастера восстановления базы данных в SQL Server Студия Управления. Таким образом, можно выбрать определенные расположения файлов, параметр перезаписи и параметр с восстановлением. Иногда процесс восстановления застревает только из-за размера файла базы данных. смотрите здесь: https://madhivanan.wordpress.com/2016/09/06/issue-in-recovering-a-database-that-is-in-the-restoring-state-reference/
У меня была эта ситуация восстановление базы данных в экземпляр SQL Server 2005 Standard Edition с помощью Symantec Backup Exec 11d. После завершения задания восстановления база данных осталась в состоянии" восстановление". У меня не было проблем с дисковым пространством-база данных просто не вышла из состояния "восстановление".
Я запустил следующий запрос к экземпляру SQL Server и обнаружил, что база данных сразу стала полезной:
RESTORE DATABASE <database name> WITH RECOVERY
вот как вы это делаете:
- остановить службу (MSSQLSERVER);
- переименовать или удалить файлы базы данных и журналов (C:\Program файлы\Microsoft SQL Server\MSSQL.1\MSSQL\данные...) или где у вас есть файлы;
- запустить службу (MSSQLSERVER);
- удалить базу данных с проблемы;
- восстановить базу данных.
удачи!
У меня был аналогичный инцидент с остановкой сервера-получателя доставки журналов. После команды удалить сервер из доставки журналов и остановить доставку журналов с первичного сервера база данных на вторичном сервере застряла в восстановлении состояния после команды
RESTORE DATABASE <database name> WITH RECOVERY
сообщения базы данных:
восстановление базы данных успешно обработано 0 страниц за 18.530 секунд (0.000 MB / sec).
база данных была использована снова после тех 18 секунд.
У меня была аналогичная проблема с восстановлением с помощью SQL Management Studio. Я попытался восстановить резервную копию базы данных на новую с другим именем. Сначала это не удалось, и после исправления имен файлов новой базы данных это было успешно выполнено - в любом случае проблема, которую я описываю, произошла снова, даже если я получил это право с первого раза. Таким образом, после восстановления исходная база данных осталась с A (Restoring... рядом с названием. Рассмотрение ответов форума выше (Bhusan) я попытался запустить в Редакторе запросов на стороне следующее:
RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"
который исправил проблему. Сначала у меня возникли проблемы из-за имени базы данных, содержащей специальные символы. Я решил это, добавив двойные кавычки вокруг-одиночные кавычки не будут работать, давая " неправильный синтаксис рядом ..." ошибка.
Это было минимальное решение, которое я пытался решить эту проблему (застрявшая база данных в состоянии восстановления), и я надеюсь, что его можно применить к более случаи.
OK, у меня есть аналогичная проблема, и точно так же, как это было в случае Pauk, это было вызвано тем, что сервер исчерпал дисковое пространство при восстановлении и поэтому вызвал постоянное состояние восстановления. Как завершить это состояние без остановки служб SQL Server?
Я нашел решение :)
Drop database *dbname*
с опцией восстановления используется по умолчанию при выполнении команд RESTORE DATABASE/RESTORE LOG. Если вы застряли в процессе "восстановления", вы можете вернуть базу данных в онлайн-состояние, выполнив:
RESTORE DATABASE YourDB WITH RECOVERY
GO
Если есть необходимость в восстановлении нескольких файлов, команды CLI требуют с NORECOVERY и с восстановлением соответственно-только последний файл в команде должен иметь с восстановлением, чтобы вернуть базу данных онлайн:
RESTORE DATABASE YourDB FROM DISK = 'Z:\YourDB.bak'
WITH NORECOVERY
GO
RESTORE LOG YourDB FROM DISK = 'Z:\YourDB.trn'
WITH RECOVERY
GO
можно использовать SQL Server Мастер Management Studio также:
существует также виртуальный процесс восстановления, но вам придется использовать сторонние решения. Как правило, вы можете использовать резервную копию базы данных в онлайн базе. ApexSQL и Idera имеют свои собственные решения. Обзор по SQL Hammer о восстановлении ApexSQL. Виртуальный восстанавливая хорошее решение, если вы имеете дело с большим количеством резервных копий. Процесс восстановления намного быстрее, а также может сэкономить много места на диске. Вы можете взгляните на инфографики здесь для некоторого сравнения.
Это может быть довольно очевидно, но это меня только что споткнулось:
Если вы берете резервную копию хвостового журнала, эта проблема также может быть вызвана тем, что эта опция включена в Мастере восстановления SSMS - " оставить исходную базу данных в состоянии восстановления (с NORECOVERY)"
Я понял, почему.
если клиент, который выдал RESTORE DATABASE
команда отключается во время восстановления, Восстановление будет застрять.
странно, что сервер, когда ему говорят восстановить базу данных с помощью клиентского соединения, не завершит восстановление, если клиент не будет подключен все время.
Это сработало:
У меня была ситуация, когда моя база данных показывала состояние восстановления, и я не мог запускать какие-либо запросы и не мог подключиться к нашему программному обеспечению.
Что я сделала, чтобы выйти из этой ситуации:
остановить все связанные службы SQL из windows сервисы.
Я открыл папку данных, где файлы Ldf и Mdf находятся в каталоге SQL, обычно это похоже : "C:\Program файлы***********\MSSQL\DATA
затем я скопировал файлы Ldf и Mdf базы данных: [имя БД].mdf и [имя БД]_log.ldf
Я скопировал оба файла в другую папку.
затем я запустил все службы, связанные с SQL (на шаге 1) снова из служб windows.
запустил мою MS SQL Management studio с обычным логином.
Правой Кнопкой Мыши на базе данных виновника и нажмите Удалить (чтобы удалить базу данных на всех).
все файлы LDF и MDF, связанные с этой базой данных, ушли из папки данных (упомянутой в шаге 2).
создал новую базу данных с тем же именем (то же имя, которое я удалил в шаге 6 - база данных виновника).
затем [имя базы данных] - > щелкните правой кнопкой мыши - > задачи - > отключить.
затем я скопировал оба файла (с шага 3) обратно в папку данных (Шаг 2).
[имя базы данных] - >щелкните правой кнопкой мыши - > задачи - > вывести в интернет.
У меня было . в моем имени базы данных, и запрос не работал из-за этого (говоря неправильный синтаксис рядом '.Затем я понял, что мне нужна скобка для имени:
RESTORE DATABASE [My.DB.Name] WITH RECOVERY
У меня была эта проблема, когда я также получил ошибку TCP в журнале событий...
падение БД с sql или щелкните правой кнопкой мыши на нем в диспетчере " удалить" И восстановить снова.
Я фактически начал делать это по умолчанию. Сценарий падение БД, воссоздать, а затем восстановить.
по умолчанию every RESTORE DATABASE
входит RECOVERY
настройка.
Параметры "NORECOVERY" в основном сообщают SQL Server, что база данных ожидает больше файлов восстановления (может быть DIFF файл и LOG файл и, может включать файл резервной копии хвостового журнала, если это возможно).
Параметры "восстановление", завершить все транзакции и пусть база данных готова к выполнению транзакций.
так:
- если ваша база данных настроена простой модель восстановления, вы можете выполнять только полное восстановить с помощью
NORECOVERY
вариант, когда у вас есть DIFF резервное копирование. Нет!--12-->LOG резервное копирование разрешается в простой модель восстановления базы данных. - в противном случае, если база данных настроена с полное или МАССОВАЯ РЕГИСТРАЦИЯ модель восстановления, вы можете выполнять полное восстановление с последующим
NORECOVERY
опция, затем выполните DIFF следовал поNORECOVERY
и, наконец, выполнить LOG восстановить с помощью .
помните, что ПОСЛЕДНИЙ ЗАПРОС ВОССТАНОВЛЕНИЯ ДОЛЖЕН ИМЕТЬ RECOVERY
опции. Это может быть явный способ или нет. В термах T-SQL ситуация:
-
USE [master] GO RESTORE DATABASE Database_name FROM DISK = N'\path_of_backup_file.bak WITH FILE = 1, [REPLACE],NOUNLOAD, RECOVERY -- This option could be omitted. GO
С заменой опция должна использоваться с осторожностью, так как это может привести к потере данных
или, если вы выполняете Полное и DIFF резервное копирование, вы можете использовать это
USE [master]
GO
RESTORE DATABASE Database_name
FROM DISK = N'\path_of_backup_file.bak' WITH FILE = 1,
NOUNLOAD,NORECOVERY
GO
RESTORE DATABASE Database_name
FROM DISK =N'\path_of_**diff**backup_file.bak' WITH FILE = 1,
NOUNLOAD, RECOVERY
GO
USE [master] GO -- Perform a Tail-Log backup, if possible. BACKUP LOG Database_name GO -- Restoring a FULL backup RESTORE DATABASE Database_name FROM DISK = N'\path_of_backup_file.bak' WITH FILE = 1, NOUNLOAD,NORECOVERY GO -- Restore the last DIFF backup RESTORE DATABASE Database_name FROM DISK = N'\path_of_DIFF_backup_file.bak' WITH FILE = 1, NORECOVERY,NOUNLOAD GO -- Restore a Log backup RESTORE LOG Database_name FROM DISK = N'path_of_LOG_backup_file.trn' WITH FILE = 2, RECOVERY, NOUNLOAD GO
конечно, вы можете выполнить восстановление с параметром статистика = 10 это говорит SQL Server сообщать о каждом 10% завершено.
если вы предпочитаете, вы можете наблюдать процесс или восстановление в режиме реального времени на основе запроса. Как следует:
USE[master]
GO
SELECT session_id AS SPID, command, a.text AS Query, start_time, percent_complete, dateadd(second,estimated_completion_time/1000, getdate()) as estimated_completion_time
FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a
WHERE r.command in ('BACKUP DATABASE','RESTORE DATABASE')
GO
надеюсь, что это поможет.
также может возникнуть проблема с удалением застрявшей базы данных, если включен снимок. Для меня это сработало:
- сначала я следовал Типу Delacablu шаги (прочитайте несколько сообщений вверх)
- выполнить команду: drop database [ваша база данных], которая даст вам ошибку, сообщающую вам имя базы данных моментальных снимков
- run command: drop database [база данных моментальных снимков], а затем снова запустите команду на Шаге 2.
в моем случае этого было достаточно, чтобы удалить базу данных, который висел в состоянии "восстановление..." С помощью команды SQL
drop database <dbname>
в окне запроса.
затем я щелкнул правой кнопкой мыши на базы данных и выбранными обновить который удалил запись в Management Studio. После этого я сделал новое восстановление, которое работало нормально (обратите внимание, что вывод его в автономном режиме не работал, перезапуск службы SQL не работал, перезагрузка сервера также не работала).
- сначала проверьте и запустите службу агента SQL.
-
используя следующий T-SQL:
выберите имя файла от мастера.системный.sysaltfiles Где dbid = функции db_id('имя_базы_данных');
-
использование T-SQL непрерывно:
восстановить базу данных с диска = 'DB_path' С ПЕРЕЗАПУСТИТЬ, ЗАМЕНИТЬ;
надеюсь, что это поможет!
все опции на основе восстановления не работали для меня.
что было сделано, так это полное восстановление из Management Studio.
USE [master]
RESTORE DATABASE Sales_SSD
FROM DISK = N'D:\databaseBackups02\Daily_Sales_20150309_0941.bak'
WITH FILE = 1,
MOVE N'Sales_Data' TO N'C:\Data\SSD\Sales.mdf',
MOVE N'Sales_Log' TO N'C:\Data\SSD\Sales_1.ldf',
NOUNLOAD, REPLACE, STATS = 5
У меня была та же проблема... хотя я не знаю, почему моя база данных испытала эту проблему, поскольку мой диск не был заполнен... Как будто что-то испортилось. Я попробовал все вышеперечисленное, ни один из них не работал полностью, я особенно думал, что предложение остановить службу и удалить файлы mdf и ldf будет работать... но он все равно застыл на restore?
в конечном итоге я решил это, удалив файлы, как упоминалось, но вместо того, чтобы пытаться восстановить БД снова, я скопировал свежий.MDF и. ldf-файлы и прикрепленные к ним с помощью мастера вложений переднего плана. Облегчение, сработало!!
потребовалась вечность, чтобы скопировать новые файлы, поскольку я использую виртуальную машину... поэтому копирование и вставка с помощью буфера обмена заняли около часа, поэтому я бы рекомендовал это только как последнюю попытку.
У меня есть MyDbName (Восстановление...) дело из-за лицензионного ограничения SQL Express.
в файле журнала, я нашел это:
создать базу данных или изменить базу данных не удалось, потому что в результате общий размер базы данных превысьте лицензионный лимит 10240 МБ по базе данных.
Итак, если вы пытаетесь восстановить большую базу данных,вам нужно переключить SQL Express server to Developer edition например.