Проверка наличия базы данных в состоянии восстановления

Я запускаю T-SQL script, который удаляет базу данных, а затем восстанавливает ее. script работает с базой данных SQL Server 2008. Иногда возникает проблема с файлом резервной копии, и база данных застревает в состоянии восстановления.

IF EXISTS (SELECT 1 FROM master.dbo.sysdatabases WHERE name = 'dbname')
BEGIN
    ALTER DATABASE [dbname]
    SET SINGLE_USER WITH 
    ROLLBACK IMMEDIATE
END

IF EXISTS (SELECT 1 FROM master.dbo.sysdatabases WHERE name = 'dbname')
BEGIN
    DROP DATABASE [dbname]
END

RESTORE DATABASE [dbname]
FROM  DISK = N'C:\dbname.bak'
WITH  FILE = 1,
NOUNLOAD,
STATS = 10

В следующий раз, когда script запускает script, генерируется сообщение об ошибке

ALTER DATABASE is not permitted while a database is in the Restoring state.

Каков наилучший способ проверить, находится ли база данных в состоянии восстановления, прежде чем пытаться запустить команду ALTER DATABASE?

EDIT: команда RESTORE DATABASE, которую я запускаю, не использует параметр NO RECOVERY.

Ответ 1

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

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

Чтобы ответить на ваш вопрос:

Метод 1

SELECT DATABASEPROPERTYEX ('DatabaseName', 'Status')

См. электронную документацию по SQL Server: DATABASEPROPERTYEX (Transact-SQL)

Метод 2

Просмотрите представление системы sys.databases, чтобы определить текущее состояние базы данных. Например:

SELECT
    state,
    state_desc
    FROM sys.databases
WHERE [name] = 'DatabaseName'

Состояние 1 = ВОССТАНОВЛЕНИЕ

См. Sys.Databases для документации относительно этого системного представления.

Ответ 3

У других была аналогичная проблема, выполняющая RESTORE с pyodbc. Мое изменение проблемы (с похожими симптомами) оказалось неправильным файлом bak. Это можно обнаружить с помощью следующего T-SQL, ищущего неправильные имена файлов .mdf или .ldf или имена баз данных:

RESTORE FILELISTONLY FROM DISK = N'C:\dbname.bak'

Ответ 4

Способ 2:

SELECT
    state,
    state_desc
     FROM sys.databases
WHERE [name] = 'Databasename'

Это дает мне точный результат.