Не удалось открыть базу данных msdb она была отмечена как подозрительная suspect операцией

MSSQLSERVER_926 MSSQLSERVER_926

Сведения Details

attribute Attribute Значение Value
Название продукта Product Name SQL Server SQL Server
Идентификатор события Event ID 926 926
Источник события Event Source MSSQLSERVER MSSQLSERVER
Компонент Component SQLEngine SQLEngine
Символическое имя Symbolic Name DB_SUSPECT DB_SUSPECT
Текст сообщения Message Text Невозможно открыть базу данных «%.*ls». Database ‘%.*ls’ cannot be opened. Она была отмечена как подозрительная (SUSPECT) операцией восстановления. It has been marked SUSPECT by recovery. Дополнительные сведения см. в журнале ошибок SQL Server. See the SQL Server errorlog for more information.

Объяснение Explanation

База данных помечается как подозрительная из-за ошибки в процессе восстановления, который должен переводить ее в согласованное транзакционное состояние. The database is marked as suspect because it failed the recovery process that brings a database to a consistent transactional state. Это может происходить во время следующих операций. This can occur during the following operations:

Присоединение базы данных. Attaching a database.

Использование процедур RESTORE и RESTORE LOG. Using the RESTORE database or RESTORE LOG procedures.

Действие пользователя User Action

Проверьте журнал ошибок SQL Server SQL Server и выясните причину ошибки. Inspect the SQL Server SQL Server error log and determine the cause of the error. Если SQL Server SQL Server перезапускалась после неуспешного завершения восстановления, найдите предыдущие журналы ошибок SQL Server SQL Server и попробуйте отыскать причину ошибки восстановления. If SQL Server SQL Server has been restarted since the failed recovery, look at previous SQL Server SQL Server error logs to see the reason why recovery failed.

Если восстановление завершилось неуспешно из-за постоянной ошибки ввода-вывода, обрыва страницы или другой вероятной неполадки оборудования, устраните проблему, связанную с оборудованием, и восстановите базу данных из резервной копии. If the recovery failed because of a persistent I/O error, a torn page, or other possible hardware problem, resolve the underlying hardware problem and restore the database by using a backup. Если резервные копии недоступны, воспользуйтесь параметрами исправления инструкции DBCC CHECKDB. If no backups are available, consider the repair options of DBCC CHECKDB.

Источник

Чиним sql server после сбоя

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

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

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

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

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

Попробуем открыть базу данных 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

Источник

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

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

Источник

База данных MSDB не открывается

У меня есть эта проблема в локальном экземпляре SQL Server 2008 R2 на моей машине. В этом экземпляре имеется несколько баз данных. Но я не вижу ни одного из них из объекта-проводника.

Я могу запросить мои базы данных из нового окна запроса. Но не смог увидеть никого из них.

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

База данных msdb не может быть открыта. Он был отмечен SUSPECT путем восстановления. Дополнительную информацию см. В журнале ошибок SQL Server. (Microsoft SQL Server, ошибка: 926).

Я также пробовал комбинации выше, но ничего не работает.

Версия SQL Server Management Studio версии 10.50.2500.0.

Я нашел ответ в эту ссылку.

EDIT: Включая оба решения из ссылки из-за возможного Linkrot в будущем.

Войдите в систему с помощью учетной записи sa для обоих решений.

Решение 1

Открыть новое окно запроса

ALTER DATABASE DB_Name SET EMERGENCY; (Объяснение: Как только база данных установлена ​​в режим EMERGENCY, она становится READ_ONLY копией, и только члены фиксированных ролей сервера sysadmin имеют права доступа к ней.)

DBCC checkdb(‘DB_Name’); (Объяснение: проверьте целостность всех объектов.)

ALTER DATABASE DB_Name SET SINGLE_USER WITH ROLLBACK IMMEDIATE; (Объяснение: Установите базу данных в однопользовательский режим.)

DBCC CheckDB (‘DB_Name’, REPAIR_ALLOW_DATA_LOSS); (Объяснение: Исправьте ошибки)

ALTER DATABASE DB_Name SET MULTI_USER; (Объяснение: Установите базу данных в многопользовательский режим, чтобы теперь к ней можно было обращаться другими.)

Решение 2

В обозревателе объектов → Открытое соединение → rightclick → Stop

Выберите пункт Sql Server (MSSQLSERVER) из служб → rightclick → Stop

Откройте C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA

Переместите MSDBData.mdf и MSDBlog.ldf в любое другое место

Затем скопируйте эти файлы снова с нового места и поместите их в более старое место

C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA

В открывшемся соединении в объекте Explorer → rightclick → Пуск

Затем обновите базу данных.

Затем вы можете отсоединить файл MSDB

Второе решение сработало для меня.

Примечание. Мне нужно было получить базу данных msdb mdf и ldf файлов с другой рабочей машины, чтобы заставить ее работать.

Источник

Управление таблицей suspect_pages (SQL Server) Manage the suspect_pages Table (SQL Server)

Страница считается «подозрительной», если при попытке ее чтения компонентом Компонент SQL Server Database Engine SQL Server Database Engine обнаруживается одна из следующих ошибок. A page is considered «suspect» when the Компонент SQL Server Database Engine SQL Server Database Engine encounters one of the following errors when it tries to read a data page:

Ошибка 823, возникающая при проверке циклической контрольной суммы (CRC), запущенной операционной системой, например, ошибка диска (происходит при некоторых ошибках оборудования) An 823 error that was caused by a cyclic redundancy check (CRC) issued by the operating system, such as a disk error (certain hardware errors)

Ошибка 824, например разрыв страницы (или любая другая логическая ошибка) An 824 error, such as a torn page (any logical error)

При обработке запроса необходимо считать страницу. A query has to read a page.

При выполнении инструкции DBCC CHECKDB. During a DBCC CHECKDB operation.

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

В этом разделе In This Topic

Перед началом работы Before you begin:

Управление таблицей suspect_pages с помощью: To manage the suspect_pages table, using:

Перед началом Before You Begin

Рекомендации Recommendations

Ошибки, заносящиеся в таблицу suspect_pages Errors Recorded in suspect_pages Table

Описание ошибки Error description Значение event_type event_type value
Ошибка 823, вызванная ошибкой CRC операционной системы, или ошибка 824, не относящаяся к неверной контрольной сумме или обрыву страницы (например, неверный идентификатор страницы). 823 error caused by an operating system CRC error or 824 error other than a bad checksum or a torn page (for example, a bad page ID) 1 1
Неверная контрольная сумма Bad checksum 2 2
Разрыв страницы Torn page 3 3
Восстановлена (страница была восстановлена после того, как была помечена поврежденной) Restored (The page was restored after it was marked bad) 4 4
Исправлена (в ходе проверки базы данных DBCC) Repaired (DBCC repaired the page) 5 5
Удалена при выполнении DBCC Deallocated by DBCC 7 7

В таблицу suspect_pages записываются также нерегулярные ошибки. The suspect_pages table also records transient errors. Их причиной могут быть ошибки ввода-вывода (например отсоединение кабеля) или временно возникшая ошибка проверки контрольной суммы страницы. Sources of transient errors include an I/O error (for example, a cable was disconnected) or a page that temporarily fails a repeated checksum test.

Как компонент Database Engine обновляет таблицу suspect_pages How the Database Engine Updates the suspect_pages Table

Компонент Компонент Database Engine Database Engine выполняет с таблицей suspect_pages следующие действия. The Компонент Database Engine Database Engine takes the following actions on the suspect_pages table:

В ходе проверки базы данных (DBCC) все страницы, не содержащие ошибок, помечаются как исправленные (event_type = 5) или освобожденные (event_type = 7). If a DBCC check is run, the check marks any error-free pages as repaired (event_type = 5) or deallocated (event_type = 7).

Автоматические обновления таблицы suspect_pages Automatic Updates to the suspect_pages Table

Ошибка 823, вызываемая ошибкой CRC операционной системы. An 823 error that is caused by an operating system CRC error.

Ошибка 824 (логическая ошибка, например разрыв страницы). An 824 error (logical corruption such as a torn page).

Операции полного восстановления, восстановления файла или страницы помечают записи для страниц как восстановленные. A full, file, or page RESTORE marks the page entries as restored.

ALTER DATABASE REMOVE FILE ALTER DATABASE REMOVE FILE

DROP DATABASE DROP DATABASE

Задачи обслуживания, выполняемые администратором базы данных Maintenance Role of the Database Administrator

За обслуживание таблицы, преимущественно за удаление старых строк, отвечают администраторы базы данных. Database administrators are responsible for managing the table, primarily by deleting old rows. Размер таблицы suspect_pages ограничен, поэтому после того, как она заполнена, новые ошибки в нее не заносятся. The suspect_pages table is limited in size, and if it fills, new errors are not logged. Чтобы не допустить переполнения таблицы, администратор базы данных или системный администратор должен вручную удалить из нее старые строки. To prevent this table from filling up, the database administrator or system administrator must manually clear out old entries from this table by deleting rows. Поэтому рекомендуется периодически удалять или архивировать строки, у которых event_type указывает на восстановление, или строки, значение last_update у которых устарело. Therefore, we recommend that you periodically delete or archive rows that have an event_type of restored or repaired, or rows that have an old last_update value.

Для наблюдения за ситуацией в таблице «suspect_pages» можно использовать класс событий Database Suspect Data Page. To monitor the activity on the suspect_pages table, you can use the Database Suspect Data Page Event Class. Строки иногда добавляются в таблицу suspect_pages из-за временных ошибок. Rows are sometimes added to the suspect_pages table because of transient errors. Однако если в таблицу добавляется множество строк, то, скорее всего, проблема существует в подсистеме ввода-вывода. If many rows are being added to the table, however, a problem probably exists with the I/O subsystem. Если было замечено резко возросшее количество строк, добавляемых в систему, то рекомендуется провести диагностику подсистемы ввода-вывода на предмет возможных проблем. If you notice a sudden increase in the number of rows being added to the table, we recommend that you investigate possible problems in your I/O subsystem.

Администратор базы данных может также вставлять или обновлять записи. A database administrator can also insert or update records. Например, обновление строк может оказаться полезным, если администратор базы данных знает, что какая-нибудь из сомнительных страниц на самом деле исправна, но хочет на время сохранить соответствующую запись. For example, updating a row might useful when the database administrator knows that a particular suspect page is actually intact, but wants to preserve the record for a while.

безопасность Security

Permissions Permissions

Использование среды SQL Server Management Studio Using SQL Server Management Studio

Управление таблицей suspect_pages To manage the suspect_pages table

Разверните последовательно узлы Системные базы данных, msdb, Таблицы и Системные таблицы. Expand System Databases, expand msdb, expand Tables, and then expand System Tables.

Разверните узел dbo.suspect_pages и щелкните правой кнопкой мыши Изменить 200 верхних строк. Expand dbo.suspect_pages and right-click Edit Top 200 Rows.

В окне запроса измените, обновите или удалите необходимые строки. In the query window, edit, update, or delete the rows that you want.

Использование Transact-SQL Using Transact-SQL

Управление таблицей suspect_pages To manage the suspect_pages table

На панели «Стандартная» нажмите Создать запрос. From the Standard bar, click New Query.

Источник

Читайте также:  Как понять не тут то было