sql база suspect что делать

Устранение неполадок в базах данных доступности 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 RECOVERY_PENDING SUSPECT состоянии:

Кроме того, эта база данных может быть в состоянии Not Synchronizing /Recovery Pending или Suspect в SQL Server Management Studio.

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

Дополнительные сведения

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

Состояние базы данных предотвращает восстановление базы данных

Чтобы восстановить базу данных с параметром, SQL выполнить следующий RECOVERY сценарий.

При запуске этого сценария вы получаете следующее сообщение об ошибке, так как база данных определяется в группе доступности:

Msg 3104, Level 16, State 1, Line 1
RESTORE не может работать на базе данных DatabaseName, так как она настроена для зеркального зеркального доступа к базе данных или присоединилась к группе доступности. Если вы собираетесь восстановить базу данных, используйте ALTER DATABASE, чтобы удалить зеркальное отражение или удалить базу данных из группы доступности.

Msg 3013, Level 16, State 1, Line 1
ВОССТАНОВЛЕНИЕ БАЗЫ данных завершается ненормально.

Состояние базы данных предотвращает удаление базы данных

Вы пытаетесь выполнить следующий сценарий SQL, чтобы отбросить базу данных:

При запуске этого сценария вы получаете следующее сообщение об ошибке, так как база данных определяется в группе доступности:

Msg 3752, Level 16, State 1, Line 1
В настоящее время имя базы данных присоединяется к группе доступности. Прежде чем удалить базу данных, ее необходимо удалить из группы доступности.

Состояние базы данных предотвращает удаление базы данных из группы доступности

Для удаления базы данных из группы доступности SQL следующий сценарий.

При попытке запуска этого скрипта вы получаете следующее сообщение об ошибке, так как база данных доступности принадлежит основной реплике:

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

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

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

Msg 921, Level 16, State 112, Line 1
Имя базы данных базы данных еще не восстановлено. Подождите и попробуйте еще раз.

Разрешение, когда база данных находится в второстепенной роли

Чтобы устранить эту проблему, примите следующие общие действия:

Чтобы выполнить эти действия, подключите новую первичную реплику, а затем запустите сценарий SQL, чтобы удалить реплику, в которой размещена база данных о несостоялась ALTER AVAILABILITY GROUP доступности. Для этого выполните указанные ниже действия.

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

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

Запустите следующий SQL:

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

Устранение любых проблем на сервере, на SQL Server и которые могут привести к сбою базы данных.

Добавьте реплику обратно в группу доступности.

Разрешение, когда основная реплика является единственной репликой в группе доступности

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

Чтобы отказаться от группы доступности, используйте следующий сценарий SQL:

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

Разрешение при падении группы доступности

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

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

Метод 1. Связать слушателя с новой группой доступности (роль) в Failover Cluster Manager

Этот метод позволяет поддерживать слушателя при сбросе и повторном создании группы доступности

На примере SQL Server, к которому подключений руководит существующий слушатель группы доступности, создайте новую, пустую группу доступности. Чтобы упростить этот процесс, используйте команду Transact-SQL для создания группы доступности, у которой нет вторичной реплики или базы данных:

Запустите диспетчер кластера failover и нажмите кнопку Роли в левой области. В области, в которую перечислены роли, выберите исходную группу доступности.

На нижней середине области в вкладке Ресурсы щелкните правой кнопкой мыши ресурс группы доступности и нажмите кнопку Свойства. Щелкните вкладку Зависимостей, удалите зависимость для слушателя и нажмите кнопку ОК.

В соответствии с ресурсами щелкните правой кнопкой мыши слушатель, нажмите кнопку Дополнительные действия, а затем нажмите Кнопку Назначить другую роль.

В диалоговом окне Назначение источника роли выберите новую группу доступности и нажмите кнопку ОК.

В области Ролей выберите новую группу доступности. На нижней середине области в вкладке Ресурсы теперь необходимо увидеть новую группу доступности и ресурс слушателя. Щелкните правой кнопкой мыши новый ресурс группы доступности и нажмите кнопку Свойства.

Щелкните вкладку Зависимостей, выберите ресурс слушателя из выпадаемого окна и нажмите кнопку ОК.

В SQL Server Management Studio используйте Object Explorer для подключения к экземпляру SQL Server, в котором размещена основная реплика новой группы доступности. Щелкните AlwaysOn с высокой доступностью, щелкните новую группу доступности и нажмите кнопку Слушатели группы доступности. Вы должны найти слушателя.

Щелкните правой кнопкой мыши слушателя, щелкните Свойства, введите соответствующий номер порта для слушателя, а затем нажмите кнопку ОК.

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

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

Метод 2. Связать слушателя с существующим экземпляром SQL Server failover Clustered Instance (SQLFCI)

Если вы размещены в группе доступности в кластерной экземпляре SQL Server failover (SQLFCI), можно связать кластерный ресурс слушателя с кластерной группой ресурсов SQLFCI во время падения и повторного создания группы доступности.

Запустите диспетчер кластера failover и нажмите кнопку Роли в левой области.

В области, в которую перечислены роли, выберите исходную группу доступности.

В нижней средней области на вкладке Ресурсы щелкните правой кнопкой мыши ресурс группы доступности и нажмите кнопку Свойства.

Щелкните вкладку Зависимостей, удалите зависимость для слушателя и нажмите кнопку ОК.

В нижней средней области в вкладке Ресурсы щелкните правой кнопкой мыши слушателя, нажмите кнопку Дополнительные действия и нажмите кнопку Назначить другую роль.

В диалоговом окне Назначение ресурса роли щелкните экземпляр SQL Server FCI и нажмите кнопку ОК.

В области Ролей выберите группу SQLFCI. В нижней средней области, на вкладке Ресурсы, теперь необходимо увидеть новый ресурс слушателя.

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

После повторного создания группы доступности перенанаменуем слушателя на роль группы доступности. Затем установите зависимость между новым ресурсом группы доступности и слушателем и перенастройка порта для слушателя:

Метод 3. Падение группы доступности, а затем повторное создание группы доступности и слушателя с тем же именем слушателя

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

Отбросить группу доступности.

Это также отпадет от слушателя.

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

Например, предположим, что ваш прослушиватель группы доступности является aglisten. В следующем заявлении Transact-SQL создается группа доступности без первичной или вторичной базы данных, но также создается прослушиватель с именем aglisten. Приложения могут использовать этот прослушиватель для подключения.

Восстановление поврежденной базы данных. Затем добавьте его и вторичную реплику обратно в группу доступности.

Источник

alexvyrvich

Alex Vyrvich

Рассмотрим несколько вариантов восстановления БД, в зависимости от того, насколько повреждены файлы БД зависит успешность того или иного метода. Все описанные способы были лично мной проверены на практике и все случаи восстановления, за исключением одного, были успешны. Используйте данное руководство на свой страх и риск, за совершенные вами действия ответственность несете, вы сами.

Итак, во-первых останавливаем службу SQL Server и копируем файлы базы данных (*.mdf и *.ldf) в другую папку, чтобы можно было восстановить их в случае неудачи.

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

Для всех версий SQL Server подойдет следующий вариант: делаем Detach database (отсоединить базу данных), удаляем журнал транзакций (файл с расширением ldf) и делаем Attach database(присоединить базу данных). В мастере выбираем наш mdf файл и жмем ОК.

Если mdf файл не поврежден, то он успешно присоединится и мы увидим нашу базу в диспетчере объектов целую и невредимую.

Радуемся успешному восстановлению. (Этот вариант сработает только если mdf файл не поврежден, поэтому срабатывает не всегда). Если не получилось, то создаем новую базу данных с таким же именем, останавливаем сервер. Подменяем файл mdf файлом от нашей базы, стартуем службу SQL Server и открываем Query analyzer(SQL 2000) или Management studio(SQL 2005/2008) в зависимости от нашей версии сервера.

USE master
GO
sp_configure ‘allow updates’, 1
reconfigure WITH override
GO

Если у вас SQL 2000, то далее пишем:

UPDATE sysdatabases SET STATUS= 32768 WHERE name = ‘db_name’
GO

Если SQL 2005 или 2008, то пишем:

ALTER DATABASE db_name SET EMERGENCY, SINGLE_USER
GO

где вместо db_name пишем имя своей БД

Жмем F5. После этого наша БД должна быть видна в статусе EMERGENCY.

В особо тяжелых случаях возникают проблемы с переходом в EMERGENCY, возможны даже проблемы с detach, в таких случаях поврежденная база удаляется, а далее происходит хитрая подмена файлов данных. Для начала создадим новую базу, имена файлов mdf и ldf должны совпадать с именами файлов поврежденной базы. Новую базу переводим в режим EMERGENCY, останавливаем службу MSSQL и подменяем файлы поврежденными. Таким образом мы получим рабочий инстанс в статусе EMERGENCY с поврежденными файлами.

Отлично, приступаем к восстановлению.

Выполним следующие SQL команды.

DBCC REBUILD_LOG(‘db_name’, ‘Полный путь к новому файлу ldf’)
GO

Жмем F5, если все нормально, сервер скажет: Warning: The log for database ‘db_name’ has been rebuilt.

USE master
GO
sp_dboption ‘db_name’, ‘single user’, ‘true’
GO
USE db_name
GO
DBCC CHECKDB(‘db_name’, REPAIR_REBUILD)
GO

Если база не хочет в single mode можно попробовать такую команду

USE db_name
ALTER database db_name set SINGLE_USER with rollback immediate
GO

если DBCC не хочет выполняться, то вместо REPAIR_REBUILD нужно подставить REPAIR_ALLOW_DATA_LOSS

Жмем F5, ждем некоторое время. Сервер вернет кучу сообщений. Если там будут содержаться ошибки, то лучше еще раз выполнить DBCC CHECKDB с параметром REPAIR_REBUILD, пока все ошибки не будут устранены.

Для SQL 2005/2008 действия несколько иные:

DBCC CHECKDB(‘db_name’, REPAIR_ALLOW_DATA_LOSS)
GO

Тут без вариантов. В SQL 2005 и выше нет инструкции REBUILD_LOG, вместо этого выполняется CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS.

После того как сервер закончит выполнять запрос и вернет результат, меняем REPAIR_ALLOW_DATA_LOSS на REPAIR_REBUILD и выполняем запрос еще раз, это должно убрать оставшиеся ошибки в бд.

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

USE master
GO
sp_dboption ‘db_name’, ‘single user’, ‘false’
GO

ALTER DATABASE db_name SET ONLINE, MULTI_USER
GO

Все. База онлайн и готова к работе. Радуемся и не забываем делать бэкапы.

Источник

Восстанавливаем базу данных SQL Server из режима “suspect”

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

Автор: Waqas, журналист в сфере информационной безопасности

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

По словам разработчиков, ошибка присутствует в каждой программе. Даже самое лучшее программное обеспечение может иногда давать сбой.

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

Программы работают с базами данных. В случае выхода базы данных из строя, может быть повреждена важная информация, потеря которой обернется катастрофическими последствиями как для пользователя, так и для бизнеса. Большинство баз данных работают на сервере Microsoft SQL. В случае проблем с сервером для восстановления базы потребуется много времени и сил.

Существует несколько способов восстановить базу данных после инцидента. Во-первых, следует разобраться с таблицей подозрительных(suspect) страниц. Информация в таблице подозрительных страниц доступна любому пользователю, имеющему доступ к базе данных MSDB. Обновлять базу также может любой пользователь, имеющий разрешение на обновление. Владельцы базы, исправив роль базы данных в MSDB, или сисадмин, исправив роль сервера, могут вставлять, обновлять и удалять записи.

Способы восстановления базы данных из подозрительного режима:

Сброс статуса базы данных + DBCC CHECKDB

Используйте программное обеспечение Recovery Toolbox for SQL Server

Таблица подозрительных страниц содержит информацию о потенциально поврежденных страницах и используется при принятии решения о восстановлении страниц. Подозрительная страница из таблицы находится в базе данных MSDB.

Страница считается «подозрительной», если при попытке ее чтения ядром СУБД SQL Server обнаруживается одна из следующих ошибок.

Ошибка 823: возникает во время проверки циклической контрольной суммы (CRC), запущенной операционной системой, например, ошибка диска (возникает при некоторых аппаратных ошибках)

Ошибка 824: например, разрыв страницы (или любая другая логическая ошибка)

Идентификатор каждой «подозрительной» страницы записывается в таблицу подозрительных страниц. В данную таблицу компонент Database Engine записывает все подозрительные страницы, с которыми сталкивается во время обработки, в частности:

Когда при обработке запроса необходимо прочитать страницу.

При выполнении DBCC CHECKDB.

Во время операции резервного копирования.

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

Ниже приведены несколько способов восстановления базы данных, если она перешла в режим “suspected”.

Во время своей работы я однажды столкнулся с ситуацией, когда рабочая база данных в конце дня перешла в режим “suspected”. Причем в последний раз база была заархивирована много часов назад. К сожалению, вернуться в штатный режим не получилось. DBCC checkdb также отказался запускаться.

Я очень расстроился, пока не нашел решение. Рассмотрим первый способ восстановления базы данных.

Сначала необходимо перевести базу данных в АВАРИЙНЫЙ режим, выполнив следующие действия:

Затем требуется протестировать базу данных:

Если не получилось восстановить базу первым способом

У вас имеется поврежденная база данных сервера (MS SQL 2005) и она неисправна. Такую базу невозможно восстановить путем тестирования-исправления (возникает ошибка контрольной суммы). В таком случае база данных не выгружается в файл – выдается та же ошибка. Вы попробовали несколько раз, и это не помогло. Попробуйте восстановить базу данных, протестировав сам SQL.

Команды для тестирования SQL приведены ниже:

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

DBCC CHECKDB (‘database’, REPAIR_ALLOW_DATA_LOSS)

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

Alter database db-name set SINGLE_USER

! Перед тестированием обязательно сделайте бэкап!

Программа позволяет комплексно восстанавливать файлы базы данных. Особенности программы Recovery Toolbox for SQL Server приведены ниже:

1. Данные из нечитаемых баз данных можно восстановить в приостановленном состоянии (suspended state);

2. Программа работает со всеми версиями Microsoft SQL Server;

3. Программа позволяет восстановить самое важное и ценное в базе данных;

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 на свой компьютер. Нет необходимости использовать полную версию, достаточно демонстрационной версии;

3. После выполнения действий начнется анализ базы данных;

4. Изучите список всех восстановленных таблиц;

5. Просматривайте данные в таблицах;

6. Изучайте восстановленные объекты;

7. Настройте параметры сохранения;

8. Выберите необходимые данные;

9. Сохраните их (для этого потребуется полная версия)

Восстановление базы данных

Как видим, для быстрого исправления MDF файла потребовалось нажать всего несколько кнопок. Все восстановленные данные копируются в новую базу данных или в виде скриптов на диск. Таким образом, программа никак не влияет на поврежденные файлы.

1. Выбираем поврежденную базу данных.

2. Смотрим, какие данные можно восстановить.

3. Определяемся с вариантом экспорта.

4. Выбираем данные для восстановления.

5. Просматриваем отчет после сохранения.

Программа условно-бесплатная, стоит 99 долларов. Скачать программу можно здесь.

Источник