SQL Сервер:База данных застряла в состоянии “Восстановления”

Question

Я создал резервную копию базы данных:

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 Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MyDatabase.mdf
MyDatabase_log  C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MyDatabase_log.LDF

Answer 1

Вам нужно использовать WITH RECOVERY опция, с вашей базой данных RESTORE команда, чтобы перевести вашу базу данных в оперативный режим в рамках процесса восстановления.

Это, конечно, только в том случае, если вы не собираетесь восстанавливать какие-либо резервные копии журнала транзакций, т. е.вы только хотите восстановить резервную копию базы данных, а затем получить доступ к ней.

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

RESTORE DATABASE MyDatabase
   FROM DISK = 'MyDatabase.bak'
   WITH REPLACE,RECOVERY

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

Answer 2

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

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

RESTORE DATABASE <database name> WITH RECOVERY

Answer 3

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

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

Answer 4

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

RESTORE DATABASE <database name> WITH RECOVERY

Сообщения базы данных:

ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ успешно обработало 0 страниц за 18.530 секунд (0.000 МБ/ сек).

Через эти 18 секунд база данных снова стала пригодной для использования.

Answer 5

У меня была аналогичная проблема с восстановлением с помощью SQL Management Studio.Я попытался восстановить резервную копию базы данных в новую с другим именем.Сначала это не удалось, и после исправления имен файлов новой базы данных это было успешно выполнено - в любом случае проблема, которую я описываю, повторилась, даже если я сделал это правильно с первого раза.Таким образом, после восстановления исходная база данных осталась с символом (Восстановление...) рядом с ее именем.Учитывая ответы на форуме выше (Bhusan's), я попытался запустить в редакторе запросов сбоку следующее:

RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"

что устранило проблему.Сначала у меня возникли проблемы из-за имени базы данных, которое содержало специальные символы.Я решил эту проблему, добавив двойные кавычки вокруг - одинарные кавычки не будут работать, выдавая ошибку "Неправильный синтаксис рядом с ...".

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

Answer 6

Хорошо, у меня похожая проблема, и точно так же, как это было в случае с Pauk, она была вызвана тем, что на сервере закончилось дисковое пространство во время восстановления, и поэтому вызвала постоянное состояние восстановления.Как завершить это состояние без остановки служб SQL Server?

Я нашел решение :)

Drop database *dbname*

Answer 7

Опция WITH RECOVERY используется по умолчанию при выполнении команд ВОССТАНОВЛЕНИЯ БАЗЫ ДАННЫХ/ журнала ВОССТАНОВЛЕНИЯ.Если вы застряли в процессе "восстановления", вы можете вернуть базу данных в оперативное состояние, выполнив:

RESTORE DATABASE YourDB WITH RECOVERY
GO

Если требуется восстановить несколько файлов, команды командной строки требуют С NORECOVERY и С RECOVERY соответственно - только последний файл в команде должен иметь С RECOVERY, чтобы вернуть базу данных в оперативный режим:

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.Виртуальное восстановление - хорошее решение, если вы имеете дело с большим количеством резервных копий.Процесс восстановления происходит намного быстрее, а также позволяет сэкономить много места на диске.Вы можете взглянуть на инфографика вот для некоторого сравнения.

Answer 8

Это может быть довольно очевидно, но только что это сбило меня с толку:

Если вы создаете резервную копию итогового журнала, эта проблема также может быть вызвана включением этого параметра в мастере восстановления SSMS - "Оставить исходную базу данных в состоянии восстановления (с NORECOVERY)".

Answer 9

Я понял почему.

Если клиент, выдавший RESTORE DATABASE команда отключается во время восстановления, восстановление будет заблокировано.

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

Answer 10

это действительно сработало :

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

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

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

5. Запустил свою MS SQL Management Studio с обычным входом в систему.

6. Щелкните правой кнопкой мыши на базе данных виновника и нажмите УДАЛИТЬ (чтобы удалить базу данных вообще).

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

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

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

10. Затем я скопировал оба файла (с шага 3) обратно в папку DATA (шаг 2).

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

Answer 11

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

RESTORE DATABASE [My.DB.Name] WITH RECOVERY

Answer 12

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

 drop database <dbname> 

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

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

Answer 13

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

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

На самом деле я начал делать это по умолчанию.Сценарий удаления базы данных, воссоздания, а затем восстановления.

Answer 14

По умолчанию каждый RESTORE DATABASE поставляется с RECOVERY настроено.Параметры 'NORECOVERY', в основном, сообщают серверу SQL, что база данных ожидает дополнительных файлов восстановления (может быть РАЗНИЦА файл и ЖУРНАЛ файл и, по возможности, может включать файл резервной копии хвостового журнала).Параметры "ВОССТАНОВЛЕНИЕ" завершают все транзакции и подготавливают базу данных к выполнению транзакций.

Итак:

1. если ваша база данных настроена с ПРОСТОЙ модель восстановления, вы можете выполнить только ПОЛНЫЙ восстановить с помощью NORECOVERY вариант, когда у вас есть РАЗНИЦА резервное копирование.НЕТ ЖУРНАЛ резервное копирование разрешено в ПРОСТОЙ база данных модели восстановления.
2. В противном случае, если ваша база данных настроена с ПОЛНЫЙ или МАССОВО РЕГИСТРИРУЕМЫЙ модель восстановления, вы можете выполнить ПОЛНЫЙ восстановить с последующим NORECOVERYвариант, затем выполните РАЗНИЦА за которым следует NORECOVERY, и, наконец, выполните ЖУРНАЛ восстановить с помощью RECOVERY вариант.

Запомни, ПОСЛЕДНИЙ ЗАПРОС НА ВОССТАНОВЛЕНИЕ ДОЛЖЕН СОДЕРЖАТЬ 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

Опцию WITH REPLACE следует использовать с осторожностью, так как это может привести к потере данных

Или, если вы выполняете ПОЛНОЕ резервное копирование и 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

 2. 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 сообщать о выполнении каждых 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

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

Answer 15

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

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

Answer 16

Вы пробовали запускать ТОЛЬКО ПРОВЕРКУ?Просто чтобы убедиться, что это надежная резервная копия.

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

Answer 17

1. Давайте сначала проверим и запустим службу SQL Agent.

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

   ВЫБЕРИТЕ имя файла ИЗ master.sys.sysaltfiles ГДЕ dbid = DB_ID('db_name');

3. Постоянное использование T-SQL:

   ВОССТАНОВИТЬ БАЗУ ДАННЫХ С ДИСКА = 'DB_path' С ПОМОЩЬЮ ПЕРЕЗАПУСТИТЬ, ЗАМЕНИТЬ;

Надеюсь, это поможет!

Answer 18

Все варианты, основанные на ВОССТАНОВЛЕНИИ, у меня не сработали.

Что было сделано, так это выполнить полное восстановление из 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

Answer 19

У меня была такая же проблема...хотя я не знаю, почему в моей базе данных возникла эта проблема, поскольку мой диск не был заполнен...Как будто он был поврежден или что-то в этом роде.Я перепробовал все вышеперечисленное, ни один из них полностью не сработал, особенно я подумал, что предложение остановить службу и удалить файлы mdf и ldf сработает...но он все еще зависал при восстановлении?

В итоге я решил эту проблему, удалив файлы, как упоминалось, но вместо того, чтобы пытаться восстановить базу данных снова, я скопировал свежие файлы .mdf и .ldf и прикрепил их с помощью мастера интерфейсных вложений.Облегчение, это сработало!!

Копирование новых файлов заняло целую ВЕЧНОСТЬ, поскольку я использую Виртуальную машину...таким образом, копирование и вставка с помощью буфера обмена заняли около часа, поэтому я бы рекомендовал это только как последнюю попытку.

Answer 20

У меня есть MyDbName (Восстановление ...) случай из-за лицензионного ограничения SQL Express.

В файле журнала я нашел это:

СОЗДАТЬ БАЗУ ДАННЫХ или ИЗМЕНИТЬ БАЗУ ДАННЫХ потерпел неудачу, потому что результирующий совокупный размер базы данных будет превысьте свой лицензионный лимит в 10 240 МБ для каждой базы данных.

Итак, если вы пытаетесь восстановить большую базу данных, вам необходимо переключить ваш SQL Express server на версию Developer Edition например.

Answer 21

То, что исправило это для меня, было

1. остановка экземпляра
2. создание резервной копии файлов .mdf и .ldf в папке data
3. Перезапустите экземпляр
4. удалите базу данных, застрявшую при восстановлении
5. поместите файлы .mdf и.ldf обратно в папку data
6. Прикрепите экземпляр к файлам .mdf и .ldf

Answer 22

RESTORE DATABASE {DatabaseName}
   FROM DISK = '{databasename}.bak'
   WITH REPLACE, RECOVERY