SQL Server: база данных застряла в состоянии «Восстановление» - PullRequest
532 голосов
/ 06 февраля 2009

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

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

Ответы [ 23 ]

6 голосов
/ 28 июля 2016

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

RESTORE DATABASE [My.DB.Name] WITH RECOVERY
5 голосов
/ 18 июля 2018

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

 drop database <dbname> 

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

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

3 голосов
/ 11 апреля 2017

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

Итак:

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

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

3 голосов
/ 13 марта 2010

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

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

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

2 голосов
/ 28 августа 2009

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

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

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

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

0 голосов
/ 09 мая 2019
RESTORE DATABASE {DatabaseName}
   FROM DISK = '{databasename}.bak'
   WITH REPLACE, RECOVERY
0 голосов
/ 10 декабря 2018

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

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

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

0 голосов
/ 01 ноября 2018

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

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

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

В лог-файле я нашел это:

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

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

...