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

Ответ 1

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

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

Ваша команда должна выглядеть так,

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

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

Ответ 2

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

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

RESTORE DATABASE <database name> WITH RECOVERY

Ответ 3

Вот как ты это делаешь:

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

Ответ 4

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

RESTORE DATABASE <database name> WITH RECOVERY

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

RESTORE DATABASE успешно обработала 0 страниц за 18.530 секунд (0,000 МБ/с).

База данных снова использовалась после этих 18 секунд.

Ответ 5

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

RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"

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

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

Ответ 6

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

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

Drop database *dbname*

Ответ 7

Параметр

WITH RECOVERY используется по умолчанию, когда выполняются команды RESTORE DATABASE/RESTORE LOG. Если вы застряли в процессе "восстановления", вы можете вернуть базу данных в онлайн-состояние, выполнив:

RESTORE DATABASE YourDB WITH RECOVERY
GO

Если требуется восстановление нескольких файлов, команды CLI требуют WITH NORECOVERY и WITH RECOVERY соответственно - только последний файл в команде должен иметь WITH 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:

enter image description here

Существует также процесс виртуального восстановления, но вам придется использовать сторонние решения. Обычно вы можете использовать резервное копирование базы данных в виде онлайн-базы данных. ApexSQL и Idera имеют собственные решения. Обзор SQL Hammer об ApexSQL Restore. Виртуальное восстановление - хорошее решение, если вы имеете дело с большим количеством резервных копий. Процесс восстановления намного быстрее, а также может сэкономить много места на диске. Вы можете посмотреть infographic здесь для некоторого сравнения.

Ответ 8

Это может быть довольно очевидным, но сейчас это сработало:

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

enter image description here

Ответ 9

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

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

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

Ответ 10

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

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

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

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

  1. Остановите все службы, связанные с SQL, из служб Windows.

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

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

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

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

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

  3. Щелкните правой кнопкой мыши на базе данных виновника и нажмите DELETE (чтобы удалить базу данных вообще).

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

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

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

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

  8. [имя базы данных] → правой кнопкой мыши → задачи → Подключить к сети.

Ответ 11

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

RESTORE DATABASE [My.DB.Name] WITH RECOVERY

Ответ 12

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

 drop database <dbname> 

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

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

Ответ 13

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

Отбросьте БД с помощью sql или щелкните правой кнопкой мыши на нем в менеджере "delete" И снова восстановите.

Я действительно начал делать это по умолчанию. Script Отбрасывание, восстановление и восстановление базы данных.

Ответ 14

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

Так:

  1. если ваша база данных настроена с использованием модели восстановления SIMPLE, вы можете выполнить только полное восстановление с параметром NORECOVERY, если у вас есть резервная копия DIFF. В базе данных модели восстановления SIMPLE не допускается резервное копирование LOG.
  2. В противном случае, если ваша база данных настроена с использованием модели восстановления FULL или BULK-LOGGED, вы можете выполнить полное восстановление с параметром NORECOVERY, затем выполнить DIFF с последующим NORECOVERY и, наконец, выполнить восстановление LOG с параметром 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 следует использовать с осторожностью, так как это может привести к потере данных

Или, если вы выполняете полное и резервное копирование, вы можете использовать это

   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

Конечно, вы можете выполнить восстановление с параметром STATS = 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

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

Ответ 15

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

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

Ответ 17

  • Сначала проверьте и запустите службу SQL Agent.
  • Использование следующего T-SQL:

    SELECT имя файла   FROM master.sys.sysaltfiles   WHERE dbid = DB_ID ('db_name');

  • Использование T-SQL непрерывно:

    ВОССТАНОВИТЬ БАЗА ДАННЫХ ОТ ДИСКА = 'DB_path' С RESTART, REPLACE;

Надеюсь на эту помощь!

Ответ 18

Все параметры, основанные на WITH RECOVERY, не работали для меня.

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

Ответ 19

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

Я решил это решить, удалив файлы, как упоминалось, но вместо того, чтобы пытаться восстановить БД, я скопировал свежие файлы .mdf и .ldf и присоединил их с помощью мастера Front End Attachment. Рельеф, это сработало!

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

Ответ 20

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

В файле журнала я нашел следующее:

CREATE DATABASE или ALTER DATABASE не удалось, потому что результат кумулятивный размер базы данных будет превышать ваш лицензионный лимит в размере 10240 МБдля каждой базы данных.

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

Ответ 21

Что исправило это для меня

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

Ответ 22

Отличная дискуссия. Наиболее распространенная ошибка, которую совершают максимум пользователей, - это восстановление базы данных с возможностью восстановления, имеющей несколько резервных копий. Это переводит базу данных в состояние RESTORING.

Если вы выполняете восстановление на определенный момент времени, сначала перейдите к Восстановлению с NoRecovery. С последней опцией резервного копирования вам нужно использовать Restore with Recovery.

Прочтите reference1 и reference2 о резервном копировании и восстановлении.

Ответ 23

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