Инструкция восстановления не обработана база данных должна находиться в однопользовательском режиме

Чтобы обнаруживать ошибки, программист должен иметь ум, которому доставляет удовольствие находить изъяны там, где, казалось, царят красота и совершенство. Фредерик Брукс-младший

После нескольких лет работы с SQL сервером от Майкрософт оказались перед очередной проблемой, после не плановой перезагрузки сервера база SQL оказалась со статусом «подозрительна». Так как раньше с таким не сталкивался пришлось искать информацию в интернете. Не буду описывать как все происходило, скопипастью статью по которой лечили SQL.

Ситуация – после аварийной перезагрузки ноутбука , который не проснулся из hibernate, перестал загружаться Sharepoint. (Я поставил в запись тег sharepoint, но запись больше про sql server).

Как это выглядит – не работает ни одно веб приложение, говорит.
Ферма недоступна.

Центр администрирования выдает

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

ОТкрываем SQL Configuration Manager, видимо что SQL сервер почему то не стартовал.

Стартуем, делаем IISReset и..
Толку нет.
Идем дальше – открываем SQl Management Studio , подключаемся к SQL Server.
На первый взгляд все почти в порядке. Рухнула база WebAnalitics, но я этой службой на DEV машине все равно пока не пользовался.
В чем же дело?

Попробуем открыть базу данных sharepoint_config_чего то там. И видим что не все так хорошо.

Что же делать?

Бекапов на разработческой машине я не делал, а переставлять sharepoint долго и неприятно.

Попробуем починить базу.

У нас есть замечательная команда DBCC CHECKDB, вот ей и восользуемся.
DBCC CHECKDB (‘SharePoint_Config_349c423b-6e3d-48a1-9251-dca12042d8ad’);

Результат

Msg 926, Level 14, State 3, Line 1
Не удалось открыть базу данных «SharePoint_Config_349c423b-6e3d-48a1-9251-dca12042d8ad». Она была отмечена как подозрительная (SUSPECT) операцией восстановления. Дополнительные сведения см. в журнале ошибок SQL Server.

Поиском в интернете нашел правильную ссылку
ALTER DATABASE [SharePoint_Config_349c423b-6e3d-48a1-9251-dca12042d8ad] SET EMERGENCY

сработало!

DBCC CHECKDB (‘SharePoint_Config_349c423b-6e3d-48a1-9251-dca12042d8ad’);
кажется тоже заработало.
теперь начинаем чинить
DBCC CHECKDB (‘SharePoint_Config_349c423b-6e3d-48a1-9251-dca12042d8ad’,REPAIR_REBUILD);

результат

Msg 7919, Level 16, State 3, Line 1
Инструкция восстановления не обработана. База данных должна находиться в однопользовательском режиме.

хм, значит надо ввести базу в однопользовательский режим.
ALTER DATABASE [SharePoint_Config_349c423b-6e3d-48a1-9251-dca12042d8ad] SET SINGLE_USER

а теперь еще раз
DBCC CHECKDB (‘SharePoint_Config_349c423b-6e3d-48a1-9251-dca12042d8ad’,REPAIR_REBUILD);

Msg 7901, Level 16, State 1, Line 1
Инструкция восстановления не была обработана. Данный уровень восстановления не поддерживается, если база данных находится в аварийном режиме.

хм, значит надо другую опцию.
DBCC CHECKDB (‘SharePoint_Config_349c423b-6e3d-48a1-9251-dca12042d8ad’,REPAIR_ALLOW_DATA_LOSS );

заработало! РЕзультаты постить не буду, так как был выдан огромный лог ошибок.

запустим еще раз
DBCC CHECKDB (‘SharePoint_Config_349c423b-6e3d-48a1-9251-dca12042d8ad’);
ошибок не обнаружено.

Остался последний штрих – вернуть базу в нормальный режим.

ALTER DATABASE [SharePoint_Config_349c423b-6e3d-48a1-9251-dca12042d8ad] SET MULTI_USER

ALTER DATABASE [SharePoint_Config_349c423b-6e3d-48a1-9251-dca12042d8ad] SET ONLINE

итого

Правильный скрипт который “лечит” базу таков.

ALTER DATABASE [SharePoint_Config_349c423b-6e3d-48a1-9251-dca12042d8ad] SET ONLINE
—
ALTER DATABASE [SharePoint_Config_349c423b-6e3d-48a1-9251-dca12042d8ad] SET EMERGENCY

DBCC CHECKDB (‘SharePoint_Config_349c423b-6e3d-48a1-9251-dca12042d8ad’);

ALTER DATABASE [SharePoint_Config_349c423b-6e3d-48a1-9251-dca12042d8ad] SET SINGLE_USER

DBCC CHECKDB (‘SharePoint_Config_349c423b-6e3d-48a1-9251-dca12042d8ad’,REPAIR_ALLOW_DATA_LOSS );

DBCC CHECKDB (‘SharePoint_Config_349c423b-6e3d-48a1-9251-dca12042d8ad’);

ALTER DATABASE [SharePoint_Config_349c423b-6e3d-48a1-9251-dca12042d8ad] SET MULTI_USER

ALTER DATABASE [SharePoint_Config_349c423b-6e3d-48a1-9251-dca12042d8ad] SET ONLINE

после чего IISreset и sharepoint поднялся.

Источник http://www.gotdotnet.ru/blogs/mbakirov/8642/

Данный материал является переводом оригинальной статьи «MSSQLTips : Daniel Calbimonte : SQL Server Database Stuck in Restoring State».

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

В этой статье мы покажем причины, по которым база данных MS SQL Server находится в состоянии восстановления, и как получить доступ к базе данных в состоянии восстановления. Это не очень распространенная проблема, но когда так случается, для администратора баз данных это головная боль. В этой статье мы рассмотрим различные причины и возможные решения этой проблемы. Рассмотренные здесь рекомендации пригодны для любой версии SQL Server.

База данных SQL Server в состоянии RESTORING после восстановления

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

Создадим файл полной резервной копии (файл *.bak) и файл резервной копии журнала транзакций (файл *.bak), запустив вот такой код T-SQL в SQL Server Management Studio (SSMS):

BACKUP DATABASE [earnings] TO DISK = N'c:\sql\earnings.bak' 
WITH NOFORMAT, NOINIT, NAME = N'earnings-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO   BACKUP LOG [earnings] TO DISK = N'C:\sql\earnings_LogBackup_2018-06-02_12-42-07.bak' 
WITH NOFORMAT, NOINIT, NAME = N'earnings_LogBackup_2018-06-02_12-42-07', SKIP, NOREWIND, NOUNLOAD, STATS = 10

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

Чтобы восстановить полную резервную копию с резервной копией журнала, нам нужно использовать параметр NORECOVERY в процессе восстановления. Итак, если мы сперва восстановим полную резервную копию следующим образом:

RESTORE DATABASE [earnings] 
FROM DISK = N'c:\sql\earnings.bak' WITH NORECOVERY, NOUNLOAD, STATS = 10

База данных теперь будет в состоянии восстановления. Если мы забудем восстановить дополнительные резервные копии, база данных застрянет в этом режиме.

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

RESTORE LOG [earnings]
FROM DISK = N'c:\sql\earnings_LogBackup_2018-06-02_12-42-07.bak'

База данных SQL Server в состоянии RESTORING после выполнения резервного копирования журнала с помощью NORECOVERY

Другая причина, по которой ваша база данных может находиться в состоянии восстановления, — это резервное копирование хвоста журнала (Log Tail) с помощью параметра NORECOVERY, как показано ниже.

BACKUP DATABASE [earnings] TO DISK = N'c:\sql\earnings.bak' 
WITH NOFORMAT, NOINIT,  NAME = N'earnings-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO   
BACKUP LOG [earnings] TO DISK = N'C:\sql\earnings_LogBackup_2018-06-02_12-42-07.bak' 
WITH NOFORMAT, NOINIT, NAME = N'earnings_LogBackup_2018-06-02_12-42-07', SKIP, NOREWIND, NOUNLOAD, NORECOVERY, STATS = 10

Это приведет к переходу базы данных в состояние восстановления.

Чтобы исправить это, вы можете восстановить резервные копии базы данных, как показано выше.

Как сделать базу данных SQL Server доступной в состоянии RESTORING без восстановления резервных копий

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

RESTORE DATABASE [earnings] WITH RECOVERY

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

Дополнительные сведения о восстановлении базы данных в состоянии восстановления можно найти в статье «Recovering a SQL Server database that is in the restoring state».

База данных SQL Server в состоянии RESTORING и Database Mirroring

Другая причина, по которой ваша база данных находится в состоянии восстановления, заключается в том, что она является частью зеркального отображения базы данных SQL Server (Database Mirroring). Database Mirroring — это решение, позволяющее обеспечить высокую доступность базы данных. Если в первичной базе данных произошел сбой, база данных вторичной реплики на другом сервере возьмет на себя операции с базой данных. Основная база данных — это основной сервер, вторичная — это зеркальный сервер и, при желании вы можете иметь еще один зеркальный сервер.

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

Дополнительные сведения о зеркальном отображении базы данных можно найти в статье «Configure SQL Server Database Mirroring Using SSMS».

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

Чтобы выполнить автоматическое переключение при отказе, выполните действия описанные в статье: «SQL Docs : Role Switching During a Database Mirroring Session — Manual Failover».

Чтобы «сломать» зеркало, вам нужно будет выбрать базу данных, перейти на страницу зеркального отображения и нажать кнопку удаления зеркального отображения. В следующей статье показано, как это сделать: «SQL Docs : Remove Database Mirroring (SQL Server)». После удаления база данных зеркального отображения вернется в нормальное состояние, и вы сможете создать резервную копию и восстановить базу данных как обычную базу данных.

База данных SQL Server в состоянии RESTORING и Log Shipping

Режим Доставки журналов SQL Server (Log Shipping) позволяет постоянно создавать резервные копии журналов транзакций, а также отправлять и восстанавливать резервные копии на другом сервере, чтобы иметь реплики базы данных в случае отказа основного сервера.

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

Ссылка на статью об изменении состояния, чтобы избежать состояния восстановления: «Change the restore mode of a secondary SQL Server database in Log shipping with SSMS».

База данных SQL Server застряла в состоянии RESTORING после перезапуска компьютера

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

Если у вас возникла эта проблема, попробуйте сначала команду:

RESTORE DATABASE [databasename] WITH RECOVERY

Если вы получаете сообщение об ошибке, что база данных используется, сперва попробуйте установить однопользовательский режим:

USE master;
GO   
ALTER DATABASE Database_name
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;

Затем попробуйте снова выполнить восстановление с помощью предыдущей команды восстановления.

После восстановления вы можете перейти в многопользовательский режим с помощью следующей команды T-SQL:

USE master;
GO   
ALTER DATABASE Database_name
SET MULTI_USER;
GO

Кроме того, убедитесь, что вы используете последний пакет обновления или накопительное обновление SQL Server.

Так же, вам следует просмотреть журнал ошибок и средство просмотра событий Windows, чтобы проверить наличие ошибок.

Заключение

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