SQL Server: база данных застряла в состоянии" восстановление"

У меня была эта ситуация восстановление базы данных в экземпляр SQL Server 2005 Standard Edition с помощью Symantec Backup Exec 11d. После завершения задания восстановления база данных осталась в состоянии" восстановление". У меня не было проблем с дисковым пространством-база данных просто не вышла из состояния "восстановление".

Я запустил следующий запрос к экземпляру SQL Server и обнаружил, что база данных сразу стала полезной:

RESTORE DATABASE <database name> WITH RECOVERY

вот как вы это делаете:

1. остановить службу (MSSQLSERVER);
2. переименовать или удалить файлы базы данных и журналов (C:\Program файлы\Microsoft SQL Server\MSSQL.1\MSSQL\данные...) или где у вас есть файлы;
3. запустить службу (MSSQLSERVER);
4. удалить базу данных с проблемы;
5. восстановить базу данных.

удачи!

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

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 команда отключается во время восстановления, Восстановление будет застрять.

странно, что сервер, когда ему говорят восстановить базу данных с помощью клиентского соединения, не завершит восстановление, если клиент не будет подключен все время.

Это сработало:

http://social.msdn.microsoft.com/Forums/en/sqldatabaseengine/thread/8dd1b91d-3e14-4486-abe6-e3a550bfe457

У меня была ситуация, когда моя база данных показывала состояние восстановления, и я не мог запускать какие-либо запросы и не мог подключиться к нашему программному обеспечению.

Что я сделала, чтобы выйти из этой ситуации:

1. остановить все связанные службы SQL из windows сервисы.

2. Я открыл папку данных, где файлы Ldf и Mdf находятся в каталоге SQL, обычно это похоже : "C:\Program файлы***********\MSSQL\DATA

3. затем я скопировал файлы Ldf и Mdf базы данных: [имя БД].mdf и [имя БД]_log.ldf

Я скопировал оба файла в другую папку.

1. затем я запустил все службы, связанные с SQL (на шаге 1) снова из служб windows.

2. запустил мою MS SQL Management studio с обычным логином.

3. Правой Кнопкой Мыши на базе данных виновника и нажмите Удалить (чтобы удалить базу данных на всех).

4. все файлы LDF и MDF, связанные с этой базой данных, ушли из папки данных (упомянутой в шаге 2).

5. создал новую базу данных с тем же именем (то же имя, которое я удалил в шаге 6 - база данных виновника).

6. затем [имя базы данных] - > щелкните правой кнопкой мыши - > задачи - > отключить.

7. затем я скопировал оба файла (с шага 3) обратно в папку данных (Шаг 2).

8. [имя базы данных] - >щелкните правой кнопкой мыши - > задачи - > вывести в интернет.

У меня было . в моем имени базы данных, и запрос не работал из-за этого (говоря неправильный синтаксис рядом '.Затем я понял, что мне нужна скобка для имени:

RESTORE DATABASE [My.DB.Name] WITH RECOVERY

У меня была эта проблема, когда я также получил ошибку TCP в журнале событий...

падение БД с sql или щелкните правой кнопкой мыши на нем в диспетчере " удалить" И восстановить снова.

Я фактически начал делать это по умолчанию. Сценарий падение БД, воссоздать, а затем восстановить.

по умолчанию every RESTORE DATABASE входит RECOVERY настройка. Параметры "NORECOVERY" в основном сообщают SQL Server, что база данных ожидает больше файлов восстановления (может быть DIFF файл и LOG файл и, может включать файл резервной копии хвостового журнала, если это возможно). Параметры "восстановление", завершить все транзакции и пусть база данных готова к выполнению транзакций.

так:

1. если ваша база данных настроена простой модель восстановления, вы можете выполнять только полное восстановить с помощью NORECOVERY вариант, когда у вас есть DIFF резервное копирование. Нет!--12-->LOG резервное копирование разрешается в простой модель восстановления базы данных.
2. в противном случае, если база данных настроена с полное или МАССОВАЯ РЕГИСТРАЦИЯ модель восстановления, вы можете выполнять полное восстановление с последующим NORECOVERYопция, затем выполните DIFF следовал по NORECOVERY и, наконец, выполнить LOG восстановить с помощью .

помните, что ПОСЛЕДНИЙ ЗАПРОС ВОССТАНОВЛЕНИЯ ДОЛЖЕН ИМЕТЬ RECOVERY опции. Это может быть явный способ или нет. В термах T-SQL ситуация:

1. 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

1. 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

надеюсь, что это поможет.

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

1. сначала я следовал Типу Delacablu шаги (прочитайте несколько сообщений вверх)
2. выполнить команду: drop database [ваша база данных], которая даст вам ошибку, сообщающую вам имя базы данных моментальных снимков
3. run command: drop database [база данных моментальных снимков], а затем снова запустите команду на Шаге 2.

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

 drop database <dbname> 

в окне запроса.

затем я щелкнул правой кнопкой мыши на базы данных и выбранными обновить который удалил запись в Management Studio. После этого я сделал новое восстановление, которое работало нормально (обратите внимание, что вывод его в автономном режиме не работал, перезапуск службы SQL не работал, перезагрузка сервера также не работала).

вы пробовали запустить только проверку? Просто чтобы убедиться, что это резервная копия.

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

1. сначала проверьте и запустите службу агента SQL.

2. используя следующий T-SQL:

   выберите имя файла от мастера.системный.sysaltfiles Где dbid = функции db_id('имя_базы_данных');

3. использование 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 например.