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

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

RESTORE DATABASE <database name> WITH RECOVERY

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

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

Через 18 секунд базу данных можно было снова использовать.

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

RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"

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

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

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

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

Drop database *dbname*

Параметр С ВОССТАНОВЛЕНИЕМ используется по умолчанию при выполнении команд 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:

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

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

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

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

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

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

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

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 базы данных: [db name] .mdf и [db name] _log.ldf

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

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

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

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

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

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

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

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

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

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

RESTORE DATABASE [My.DB.Name] WITH RECOVERY

Щелкните правой кнопкой мыши базу данных и выберите Задачи - ›Восстановление -› Журналы транзакций. Если в файлах транзакций вы видите, что файл отмечен, значит, сервер SQL пытается восстановить из этого файла. Снимите флажок с файла и нажмите ОК. База данных вернулась .....

это решило проблему для меня, надеюсь, это кому-то поможет.

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

 drop database <dbname> 

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

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

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

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

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

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

So:

1. если ваша база данных настроена с использованием модели восстановления ПРОСТОЙ, вы можете выполнить восстановление ПОЛНОЕ с параметром NORECOVERY только при наличии резервной копии DIFF. Резервное копирование LOG запрещено в базе данных модели восстановления SIMPLE.
2. В противном случае, если ваша база данных настроена с использованием модели восстановления ПОЛНОЕ или С БОЛЬШИМ РЕГИСТРАТОРОМ, вы можете выполнить восстановление ПОЛНОЕ с последующим 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

Параметр С ЗАМЕНИТЬЮ следует использовать с осторожностью, так как это может привести к потере данных.

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

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

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

Используйте следующую команду, чтобы решить эту проблему

RESTORE DATABASE [DatabaseName] WITH RECOVERY

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

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

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

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

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

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

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

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

Возникла аналогичная проблема при восстановлении базы данных с помощью студии управления SQL-сервером, и она застряла в режиме восстановления. После нескольких часов отслеживания проблем у меня сработал следующий запрос. Следующий запрос восстанавливает базу данных из существующей резервной копии в предыдущее состояние. Я считаю, что загвоздка в том, чтобы файлы .mdf и .log располагались в одном каталоге.

RESTORE DATABASE aqua_lc_availability
FROM DISK = 'path to .bak file'
WITH RECOVERY

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

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

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

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 будет работать ... но он все еще завис при восстановлении?

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

Копирование новых файлов потребовалось НАВСЕГДА, так как я использую виртуальную машину ... поэтому копирование и вставка с использованием буфера обмена заняли около часа, поэтому я бы рекомендовал это только как последнюю попытку.

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

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

Если вы хотите восстановить базу данных SQL Server из файла резервной копии, вы можете использовать следующий сценарий:

RESTORE DATABASE [MyDatabase] -- which database to restore
FROM DISK = N'X:\MyDatabase.bak' -- location of the database backup
WITH 
    FILE = 1, -- restore from a backup file
    -- declare where the file groups should be located (can be more than two)
    MOVE N'MyDatabase_Data' TO N'D:\SSDPATH\MyDatabase.mdf',
    MOVE N'MyDatabase_Log' TO N'E:\HDDPATH\MyDatabase.ldf',
    -- Tape option; only relevant if you backup from magnetic tape
    NOUNLOAD,
    -- brings the database online after the database got restored
    -- use this option when you don't want to restore incremental backups
    -- use NORECOVERY when you want to restore differential and incremental backup files
    RECOVERY,
    -- replace existing database with the backup 
    -- deletes the existing database
    REPLACE, 
    -- print log message for every 1 percent of restore
    STATS = 1;

Это старая проблема, которая постоянно возникает в SQL Server, даже в последней версии 2019 года! Я не знаю, почему Microsoft оставила эту боль так надолго и позволила своему движку MSSQL продолжать вести себя таким образом. Тем не менее, я предлагаю другое возможное решение для тех, кто попробовал ВОССТАНОВИТЬ БАЗУ ДАННЫХ С ВОССТАНОВЛЕНИЕМ, но он все еще не работал.

Войдите на сам сервер и запустите программу SSMS по умолчанию на реальном сервере базы данных. Затем перейдите в базу данных восстановления и УДАЛИТЬ ее. Выполнено. Проблема ушла. Если вам нужно было сохранить его, скопируйте файл MDF, переименуйте его и прикрепите как новую базу данных. У меня работал на SQL Server 2008 R2.