Устранение неполадок баз данных доступности AlwaysOn в состоянии ожидания восстановления или подозрительного состояния в SQL Server
В этой статье описываются ошибки и ограничения базы данных доступности в Microsoft SQL Server, которая находится в Recovery Pending состоянии или , Suspect а также способы восстановления базы данных до полной функциональности в группе доступности.
Исходная версия продукта: SQL Server 2012 г.
Исходный номер базы знаний: 2857849
Заключение
Предположим, что база данных доступности, определенная в группе доступности AlwaysOn, переходит Recovery Pending в состояние или Suspect в SQL Server. Если это происходит на первичном реплика группы доступности, это влияет на доступность базы данных. В этом случае вы не сможете получить доступ к базе данных через клиентские приложения. Кроме того, нельзя удалить или удалить базу данных из группы доступности.
Например, предположим, что SQL Server выполняется, а для базы данных доступности задано Recovery Pending состояние или Suspect . При запросе динамических административных представлений (DMV) на первичном реплика с помощью следующего скрипта SQL база данных может быть представлена NOT_HEALTHY SUSPECT в состоянии и RECOVERY_PENDING или в состоянии следующим образом:
SELECT dc.database_name, d.synchronization_health_desc, d.synchronization_state_desc, d.database_state_desc FROM sys.dm_hadr_database_replica_states d JOIN sys.availability_databases_cluster dc ON d.group_database_id = dc.group_database_id AND d.is_local = 1 database_name synchronization_health_desc synchronization_state_desc database_state_desc -------------------- ------------------------------ ------------------------------ --------------------- NOT_HEALTHY NOT SYNCHRONIZING RECOVERY_PENDING (1 row(s) affected) 
Кроме того, эта база данных может находиться в состоянии Не синхронизация/ Ожидание восстановления или Подозрительное в SQL Server Management Studio.
Если база данных определена в группе доступности, ее невозможно удалить или восстановить. Поэтому необходимо выполнить определенные действия, чтобы восстановить базу данных и вернуть ее в рабочую среду.
Дополнительные сведения
В следующем содержимом рассматриваются ошибки и ограничения базы данных доступности, которая находится в состоянии ожидания восстановления в различных ситуациях.
-
Состояние базы данных предотвращает восстановление базы данных Чтобы восстановить базу данных с параметром RECOVERY , попробуйте выполнить следующий скрипт SQL:
RESTORE DATABASE WITH RECOVERY При выполнении этого скрипта появляется следующее сообщение об ошибке, так как база данных определена в группе доступности:
Сообщение 3104, уровень 16, состояние 1, строка 1
Функция RESTORE не может работать с database , так как она настроена для зеркального отображения базы данных или присоединена к группе доступности. Если вы планируете восстановить базу данных, используйте инструкцию ALTER DATABASE, чтобы удалить зеркальное отображение или удалить базу данных из группы доступности. Сообщение 3013, уровень 16, состояние 1, строка 1
Восстановление базы данных происходит аномально.
DROP DATABASE
При выполнении этого скрипта появляется следующее сообщение об ошибке, так как база данных определена в группе доступности:
Сообщение 3752, уровень 16, состояние 1, строка 1
База данных в настоящее время присоединена к группе доступности. Перед удалением базы данных необходимо удалить ее из группы доступности.
ALTER DATABASE SET hadr OFF При попытке запустить этот скрипт появляется следующее сообщение об ошибке, так как база данных доступности принадлежит к основному реплика:
Сообщение 35240, уровень 16, состояние 14, строка 1
База данных не может быть присоединена к группе доступности AvailabilityGroupName> или отсоединена от нее<. Эта операция не поддерживается в основном реплика группы доступности.
Из-за этого сообщения об ошибке может потребоваться выполнить отработку отказа базы данных. После отработки отказа базы данных реплика, которому принадлежит ожидающая восстановления база данных, находится в роли-получателе. В этом случае вы попытаетесь выполнить следующий скрипт SQL еще раз, чтобы удалить базу данных из группы доступности на вторичном реплика:
ALTER DATABASE SET hadr OFF Однако вы по-прежнему не можете удалить базу данных из группы доступности, и вы получите следующее сообщение об ошибке, так как база данных по-прежнему находится в состоянии ожидания восстановления:
Сообщение 921, уровень 16, состояние 112, строка 1
Database еще не восстановлен. Подождите и повторите попытку.
Разрешение, когда база данных находится в роли-получателе
Чтобы устранить эту проблему, выполните следующие общие действия.
- Удалите из группы доступности реплика, в котором размещена поврежденная база данных, когда база данных находится в роли-получателе.
- Устраните все проблемы, влияющие на систему и которые могли привести к сбою базы данных.
- Восстановите реплика в группе доступности.
Чтобы выполнить эти действия, подключитесь к новой первичной реплика, а затем запустите ALTER AVAILABILITY GROUP скрипт SQL, чтобы удалить реплика, в котором размещена база данных доступности, на котором была выполнена сбойная база данных доступности. Для этого выполните указанные ниже действия.
При выполнении этих действий предполагается, что на реплика-источнике сначала размещается поврежденная база данных. Поэтому сначала необходимо выполнить отработку отказа, чтобы перевести реплика, в котором размещена поврежденная база данных, во вторичную роль.
- Подключитесь к серверу, на котором выполняется SQL Server и на котором размещается дополнительный реплика.
- Выполните следующий скрипт SQL:
ALTER AVAILABILITY GROUP FAILOVER ALTER AVAILABILITY GROUP REMOVE REPLICA ON '' Разрешение, когда основной реплика является единственным реплика в группе доступности
Если основная реплика размещает поврежденную базу данных и является единственным рабочим реплика в группе доступности, группа доступности должна быть удалена. После удаления группы доступности базу данных можно восстановить из резервной копии или применить другие усилия по аварийному восстановлению для восстановления баз данных и возобновления рабочей среды.
Чтобы удалить группу доступности, используйте следующий скрипт SQL:
DROP AVAILABILITY GROUP
На этом этапе можно попытаться восстановить проблемную базу данных. Или можно восстановить базу данных из последней известной хорошей резервной копии.
Решение при удалении группы доступности
При удалении группы доступности ресурс прослушивателя также удаляется и прерывает подключение приложения к базам данных доступности.
Чтобы свести к минимуму время простоя приложения, используйте один из следующих методов для поддержки подключения к приложению через прослушиватель и удаления группы доступности:
Метод 1. Связывание прослушивателя с новой группой доступности (ролью) в диспетчере отказоустойчивости кластеров
Этот метод позволяет поддерживать прослушиватель при удалении и повторном создании группы доступности.
-
На экземпляре SQL Server, к которому существующий прослушиватель группы доступности направляет подключения, создайте пустую группу доступности. Чтобы упростить этот процесс, используйте команду Transact-SQL, чтобы создать группу доступности без дополнительных реплика или базы данных:
USE master GO CREATE AVAILABILITY GROUP ag FOR REPLICA ON 'sqlnode1' WITH ( ENDPOINT_URL = 'tcp://sqlnode1:5022', AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL ) 
Это гарантирует, что приложения, использующие прослушиватель, по-прежнему могут использовать его для подключения к экземпляру SQL Server, в котором размещаются рабочие базы данных без прерывания. Исходную группу доступности теперь можно полностью удалить и повторно создать. Кроме того, базы данных и реплики можно добавить в новую группу доступности.
При повторном создании исходной группы доступности следует переназначить прослушиватель обратно роли группы доступности, настроить зависимость между новым ресурсом группы доступности и прослушивателем, а затем переназначить порт прослушивателю. Для этого выполните следующие действия:
- Запустите диспетчер отказоустойчивости кластеров, а затем выберите Роли в области слева. В области со списком ролей щелкните новую группу доступности, в которую размещается прослушиватель.
- В нижней средней области на вкладке Ресурсы щелкните прослушивателя правой кнопкой мыши, выберите Дополнительные действия, а затем выберите Назначить другую роль. В диалоговом окне выберите повторно созданную группу доступности и нажмите кнопку ОК.
- В области Роли щелкните повторно созданную группу доступности. В нижней средней области на вкладке Ресурсы вы увидите повторно созданную группу доступности и ресурс прослушивателя. Щелкните правой кнопкой мыши повторно созданный ресурс группы доступности и выберите Пункт Свойства.
- Перейдите на вкладку Зависимости , выберите ресурс прослушивателя в раскрывающемся списке и нажмите кнопку ОК.
- В SQL Server Management Studio используйте объектную Обозреватель для подключения к экземпляру SQL Server, на котором размещается основной реплика повторно созданной группы доступности. Выберите Высокий уровень доступности AlwaysOn, щелкните новую группу доступности, а затем выберите Прослушиватели группы доступности. Вы должны найти прослушиватель.
- Щелкните прослушиватель правой кнопкой мыши, выберите Свойства, введите соответствующий номер порта для прослушивателя и нажмите кнопку ОК.
Метод 2. Связывание прослушивателя с существующим кластеризованным экземпляром SQL Server отработки отказа (SQLFCI)
Если вы размещаете группу доступности в экземпляре отказоустойчивой кластеризации SQL Server (SQLFCI), вы можете связать кластеризованный ресурс прослушивателя с кластеризованной группой ресурсов SQLFCI во время удаления, а затем повторно создать группу доступности.
- Запустите диспетчер отказоустойчивости кластеров, а затем выберите Роли в области слева.
- В области со списком ролей выберите исходную группу доступности.
- В нижней средней области на вкладке Ресурсы щелкните правой кнопкой мыши ресурс группы доступности и выберите Пункт Свойства.
- Перейдите на вкладку Зависимости , удалите зависимость прослушивателя и нажмите кнопку ОК.
- В нижней средней области на вкладке Ресурсы щелкните прослушивателя правой кнопкой мыши, выберите Дополнительные действия, а затем выберите Назначить другую роль.
- В диалоговом окне Назначение ресурса роли щелкните экземпляр FCI SQL Server и нажмите кнопку ОК.
- В области Роли выберите группу SQLFCI. В нижней средней области на вкладке Ресурсы должен появиться новый ресурс прослушивателя.
Это гарантирует, что приложения, использующие прослушиватель, по-прежнему могут использовать его для подключения к экземпляру SQL Server, на котором размещаются рабочие базы данных без прерывания. Исходную группу доступности теперь можно удалить и повторно создать. Кроме того, базы данных и реплики можно добавить в новую группу доступности.
После повторного создания группы доступности переназначьте прослушиватель обратно роли группы доступности. Затем настройте зависимость между новым ресурсом группы доступности и прослушивателем и переназначьте порт прослушивателю:
- Запустите диспетчер отказоустойчивости кластеров, а затем выберите Роли в области слева.
- В области со списком ролей щелкните исходную роль SQLFCI.
- В нижней средней области на вкладке Ресурсы щелкните прослушивателя правой кнопкой мыши, выберите Дополнительные действия, а затем выберите Назначить другую роль.
- В диалоговом окне щелкните повторно созданную группу доступности и нажмите кнопку ОК.
- В области Роли выберите новую группу доступности.
- На вкладке Ресурсы вы увидите новую группу доступности и ресурс прослушивателя. Щелкните правой кнопкой мыши новый ресурс группы доступности и выберите Пункт Свойства.
- Перейдите на вкладку Зависимости , выберите ресурс прослушивателя в раскрывающемся списке и нажмите кнопку ОК.
- В SQL Server Management Studio используйте объектную Обозреватель для подключения к экземпляру SQL Server, на котором размещается основной реплика новой группы доступности.
- Выберите Высокий уровень доступности AlwaysOn, щелкните новую группу доступности, а затем выберите Прослушиватели группы доступности. Вы должны найти прослушиватель.
- Щелкните прослушиватель правой кнопкой мыши, выберите Свойства, введите соответствующий номер порта для прослушивателя и нажмите кнопку ОК.
Способ 3. Удалите группу доступности, а затем повторно создайте группу доступности и прослушиватель с тем же именем прослушивателя.
Этот метод приведет к небольшому сбою для приложений, которые в настоящее время подключены, так как группа доступности и прослушиватель удаляются, а затем создаются повторно:
-
Удалите группу доступности.
Примечание. Это также приведет к удалению прослушивателя.
USE master GO CREATE AVAILABILITY GROUP ag FOR REPLICA ON 'sqlnode1' WITH ( ENDPOINT_URL = 'tcp://sqlnode1:5022', AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL ) LISTENER 'aglisten' ( WITH IP ((N'11.0.0.25', N'255.0.0.0')), PORT = 1433 ) GO SQL-Ex blog
Как перевести базу данных SQL Server в состояние Recovery Pending
Добавил Sergey Moiseenko on Среда, 2 февраля. 2022
Вы могли бы спросить, зачем кому-то на земле понадобилось переводить базу данных в нежелательное состояние, а конкретно в состояние Recovery Pending (ожидание восстановления). Ну, в моем случае имелась клиентская база данных, которая вошла в это состояние в результате отказа хранилища. К счастью, это не была производственная база данных, поэтому у меня было время найти наилучший способ исправить проблему.
Фраза, которая часто использовалась во время моей службы в пожарной части, была такой: «Попробуй, прежде чем совать нос». Нужно ли выбивать входную дверь? Возможно она не заперта и, сначала попробовав (своим ботинком), я могу предотвратить повреждение двери. В подобных сценариях эта философия верна. Проверка на некритичных базах данных поможет предотвратить любые дальнейшие повреждения.
В данном случае я захотел проверить, прежде чем предпринимать некие действия, которые могли привести к повреждению. Это означало, что я должен был перевести тестовую базу данных в состояние восстановления. Переведя её в требуемое состояние, затем я могу испытать различные методы, чтобы правильно восстановить базу данных. Определившись с успешным решением, я смогу уверенно сунуть нос в поврежденную производственную базу данных, зная, что я использую проверенный метод.
ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: НЕ ДЕЛАЙТЕ ЭТОГО НА ПРОИЗВОДСТВЕННОМ ЭКЗЕМПЛЯРЕ SQL SERVER.
Как перевести базу данные в режим ожидания восстановления?
- Начать новую транзакцию.
- Создать новую таблицу.
- Остановить службу SQL Server.
- Переименовать/удалить файл журнала базы данных.
- Перезапустить службу SQL Server.
Почему база данных находится в режиме ожидания восстановления?
Когда база данных снова пытается перейти в оперативный режим, она будет переведена в состояние ожидания восстановления, поскольку отсутствует файл журнала, и имелась открытая транзакция, когда служба была выключена. При обычном функционировании даже при открытой транзакции SQL Server прошел бы фазу восстановления журнала транзакций. При восстановлении на фазе отката SQL Server попытался бы откатить транзакцию, которая была открыта на момент рестарта, и отменить изменения. Поскольку файл журнала теперь отсутствует, это невозможно сделать.
Следовательно, база данных теперь находится в состоянии ожидания восстановления. Это ожидание восстановления обусловлено открытой транзакцией, но SQL Server не может перевести базу данных в согласованное состояние.
Когда это происходит, вы видите что-то подобное в журнале ошибок:
Если база данных закрыта чисто, и файл журнала транзакций удален/переименован/и т.д., SQL Server просто перестроит для вас файл журнала.
Выводы
Иногда полезно иметь возможность перевести базу данных в конкретное состояние с тем, чтобы вы могли проверить решения прежде, чем выполнять какое-либо действие в условиях производства. Просто не забудьте попробовать, прежде чем сунуть нос. Если вы этого не сделаете, то можете только ухудшить ситуацию, поэтому излишняя осторожность не помешает.
Обратные ссылки
Нет обратных ссылок
Комментарии
Показывать комментарии Как список | Древовидной структурой
Автор не разрешил комментировать эту запись
Восстанавливаем базу данных SQL Server из режима “suspect”
В случае выхода базы данных из строя, может быть повреждена важная информация, потеря которой обернется катастрофическими последствиями как для пользователя, так и для бизнеса.
Автор: Waqas, журналист в сфере информационной безопасности В случае выхода базы данных из строя может быть потеряна важная информация. Последствия потери данных могут быть катастрофическими как для пользователя, так и для бизнеса. Если крупные организации понесут огромные убытки, малые предприятия могут поплатиться своим существованием. По словам разработчиков, ошибка присутствует в каждой программе. Даже самое лучшее программное обеспечение может иногда давать сбой. 
Иногда работа и жизнь людей зависят от функциональности программного обеспечения. Корректная работа ПО влияет на финансовое благополучие или здоровье людей. Поэтому особенно важно, чтобы при сбоях программного обеспечения, имелась возможность быстро его вернуть в нормальное рабочее состояние. Программы работают с базами данных. В случае выхода базы данных из строя, может быть повреждена важная информация, потеря которой обернется катастрофическими последствиями как для пользователя, так и для бизнеса. Большинство баз данных работают на сервере Microsoft SQL. В случае проблем с сервером для восстановления базы потребуется много времени и сил. 
Существует несколько способов восстановить базу данных после инцидента. Во-первых, следует разобраться с таблицей подозрительных(suspect) страниц. Информация в таблице подозрительных страниц доступна любому пользователю, имеющему доступ к базе данных MSDB. Обновлять базу также может любой пользователь, имеющий разрешение на обновление. Владельцы базы, исправив роль базы данных в MSDB, или сисадмин, исправив роль сервера, могут вставлять, обновлять и удалять записи. Способы восстановления базы данных из подозрительного режима: Сброс статуса базы данных + DBCC CHECKDB DBCC CHECKDB Используйте программное обеспечение Recovery Toolbox for SQL Server Таблица подозрительных страниц содержит информацию о потенциально поврежденных страницах и используется при принятии решения о восстановлении страниц. Подозрительная страница из таблицы находится в базе данных MSDB. Страница считается «подозрительной», если при попытке ее чтения ядром СУБД SQL Server обнаруживается одна из следующих ошибок.
- Ошибка 823: возникает во время проверки циклической контрольной суммы (CRC), запущенной операционной системой, например, ошибка диска (возникает при некоторых аппаратных ошибках)
- Ошибка 824: например, разрыв страницы (или любая другая логическая ошибка)
Идентификатор каждой «подозрительной» страницы записывается в таблицу подозрительных страниц. В данную таблицу компонент Database Engine записывает все подозрительные страницы, с которыми сталкивается во время обработки, в частности:
- Когда при обработке запроса необходимо прочитать страницу.
- При выполнении DBCC CHECKDB.
- Во время операции резервного копирования.
Во время операции восстановления, исправления DBCC или удаления базы данных таблица подозрительных страниц также обновляется по мере необходимости.
Ниже приведены несколько способов восстановления базы данных, если она перешла в режим “suspected”.
Во время своей работы я однажды столкнулся с ситуацией, когда рабочая база данных в конце дня перешла в режим “suspected”. Причем в последний раз база была заархивирована много часов назад. К сожалению, вернуться в штатный режим не получилось. DBCC checkdb также отказался запускаться.
Я очень расстроился, пока не нашел решение. Рассмотрим первый способ восстановления базы данных.
Сначала необходимо перевести базу данных в АВАРИЙНЫЙ режим, выполнив следующие действия:
- EXEC sp_resetstatus ‘yourDBname’;
- ALTER DATABASE yourDBname SET EMERGENCY
Затем требуется протестировать базу данных:
- DBCC checkdb (‘yourDBname’)
- ALTER DATABASE yourDBname SET SINGLE_USER WITH ROLLBACK IMMEDIATE
- DBCC CheckDB (‘yourDBname’, REPAIR_ALLOW_DATA_LOSS)
- ALTER DATABASE yourDBname SET MULTI_USER
Если не получилось восстановить базу первым способом
У вас имеется поврежденная база данных сервера (MS SQL 2005) и она неисправна. Такую базу невозможно восстановить путем тестирования-исправления (возникает ошибка контрольной суммы). В таком случае база данных не выгружается в файл – выдается та же ошибка. Вы попробовали несколько раз, и это не помогло. Попробуйте восстановить базу данных, протестировав сам SQL.
Команды для тестирования SQL приведены ниже:
- DBCC CHECKDB (‘database’, REPAIR_FAST)
- DBCC CHECKDB (‘database’, REPAIR_REBUILD)
Если обе команды не работают, можно использовать третью. Рекомендуем использовать данную команду только в крайнем случае в связи с опасностью возможной потери данных.
DBCC CHECKDB (‘database’, REPAIR_ALLOW_DATA_LOSS)
Если команда не выполняется из-за не однопользовательского режима, используйте команду:
Alter database db-name set SINGLE_USER
! Перед тестированием обязательно сделайте бэкап!
Используйте программу Recovery Toolbox for SQL Server — важный инструмент в работе любого системного администратора. Программа позволяет работать с файлами MS SQL Server любой версии.
Программа позволяет комплексно восстанавливать файлы базы данных. Особенности программы Recovery Toolbox for SQL Server приведены ниже:
1. Данные из нечитаемых баз данных можно восстановить в приостановленном состоянии (suspended state);
2. Программа работает со всеми версиями Microsoft SQL Server;
3. Программа позволяет восстановить самое важное и ценное в базе данных;
4. В базе данных несколько элементов — тоже не проблема;
5. Восстановливает таблицы при работе с MDF файлами;
6. SQL MDF Recovery экспортирует данные непосредственно в Microsoft SQL Server;
7. Информация сохраняется в том числе в виде скриптов;
8. Извлеченные данные напрямую экспортируются в новую базу данных;
9. Программа работает с любой версией Windows;
10. Мультиязычный интерфейс;
11. Возможен просмотр данных перед восстановлением;
Сбой базы данных после сбоя сервера является самым страшным сном любого сисадмина. Как в такой ситуации восстановить поврежденную базу?
Для восстановления данных после сбоя обычно используется резервная копия. Однако, если по какой-то причине копия не была сделана, попробуйте использовать Recovery Toolbox for SQL Server. Скорее всего, вам удастся восстановить рабочее состояние базы данных.
Для этого необходимо выполнить следующие действия:
1. Установите Recovery Toolbox for SQL Server на свой компьютер. Нет необходимости использовать полную версию, достаточно демонстрационной версии;
2. Выберите файл;
3. После выполнения действий начнется анализ базы данных;
4. Изучите список всех восстановленных таблиц;
5. Просматривайте данные в таблицах;
6. Изучайте восстановленные объекты;
7. Настройте параметры сохранения;
8. Выберите необходимые данные;
9. Сохраните их (для этого потребуется полная версия)
Восстановление базы данных
Как видим, для быстрого исправления MDF файла потребовалось нажать всего несколько кнопок. Все восстановленные данные копируются в новую базу данных или в виде скриптов на диск. Таким образом, программа никак не влияет на поврежденные файлы.
Как это работает?
1. Выбираем поврежденную базу данных.
2. Смотрим, какие данные можно восстановить.
3. Определяемся с вариантом экспорта.
4. Выбираем данные для восстановления.
5. Просматриваем отчет после сохранения.
Программа условно-бесплатная, стоит 99 долларов. Скачать программу можно здесь.
База данных SQL Server застряла в состоянии восстановления
Данный материал является переводом оригинальной статьи «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, чтобы проверить наличие ошибок.
Заключение
В этой статье мы рассмотрели разные причины, по которым база данных может находиться в состоянии восстановления. Надеемся, это будет полезно, если вам придется устранять эту проблему.