Ошибка 9694 с серьезностью 16 и состоянием 27 появляется в журнале SQL Server и в тексте исключения приложения, когда ядро СУБД прерывает выполнение запроса из-за внутренней проблемы уровня базы данных. Сама по себе цифра 9694 — это номер сообщения из системного каталога sys.messages, а точный текст сообщения зависит от версии сервера и языковой настройки. Поэтому первый практический шаг — не гадать по номеру, а извлечь полный текст ошибки из журнала SQL Server и из контекста, в котором она возникла.
Серьезность (severity) 16 означает, что ошибка относится к категории пользовательских ошибок, которые может исправить администратор или разработчик: сеанс сервера при этом обычно не разрывается, а сам экземпляр SQL Server продолжает работать. Состояние (state) 27 — это внутренний маркер, который указывает, в каком именно месте кода SQL Server было сгенерировано сообщение. Для поддержки Microsoft состояние помогает отличить разные сценарии одной и той же ошибки.
Что означают коды 9694, 16 и 27
Разберем структуру сообщения по частям. Номер ошибки 9694 — идентификатор записи в системном представлении sys.messages. Серьезность 16 — типичный уровень для проблем с синтаксисом, правами доступа, состоянием объектов и настройками базы. Состояние 27 не документируется публично в расшифровке для каждой ошибки: это техническая метка конкретной ветки кода внутри движка.
Практический вывод: искать решение только по связке «9694 / 16 / 27» в интернете малоэффективно. Нужно сопоставить номер с полным текстом сообщения, который сервер выводит вместе с кодом — именно текст содержит имя объекта, базы или операции, вызвавшей сбой.
SELECT message_id, severity, text
FROM sys.messages
WHERE message_id = 9694 AND language_id = 1049;
Если для русского языка запись не найдена, выполните тот же запрос с language_id = 1033 (английский). Текст сообщения подскажет, к какой подсистеме относится сбой.
Типичные сценарии появления ошибки
Ошибки с серьезностью 16, как правило, возникают не из-за аппаратных неисправностей, а из-за состояния данных, настроек или логики запроса. Для ошибок подобного класса характерны следующие ситуации:
- 🔧 Обращение к объекту базы данных, который был удален, переименован или находится в неконсистентном состоянии.
- 🔐 Недостаток прав у учетной записи, от имени которой выполняется запрос или фоновое задание.
- ⚙️ Конфликт настроек базы данных — например, операция требует функцию, отключенную на уровне базы или экземпляра.
- 📦 Повреждение метаданных или отдельных страниц данных, которое проявляется только при обращении к конкретному объекту.
Точную причину нельзя установить по одному номеру — она определяется контекстом: какой запрос выполнялся, какое приложение его инициировало, воспроизводится ли ошибка повторно.
Шаг 1. Соберите диагностическую информацию
Прежде чем что-либо исправлять, зафиксируйте обстоятельства сбоя. Откройте журнал ошибок SQL Server через SQL Server Management Studio: Management → SQL Server Logs, либо прочитайте журнал запросом sp_readerrorlog. Найдите записи с ошибкой 9694 и посмотрите соседние строки — часто рядом находятся связанные сообщения, раскрывающие причину.
Полезно зафиксировать следующее:
- 🕒 Точное время возникновения и периодичность — разовый сбой или повторяющаяся ошибка.
- 👤 Имя входа и приложение, указанные в записи журнала (поле Login / Application Name).
- 🗄️ Базу данных, в контексте которой возникла ошибка.
- 🔁 Запрос или задание, которое выполнялось в момент сбоя.
Расширенные события (Extended Events) позволяют отловить момент ошибки вместе с текстом запроса: создайте сессию на событие error_reported с фильтром по error_number = 9694.
Шаг 2. Проверьте целостность базы данных
Если ошибка повторяется при обращении к одной и той же базе, разумно проверить её целостность. Для этого используется команда DBCC CHECKDB — она проверяет логическую и физическую согласованность объектов без изменения данных.
DBCC CHECKDB (N'ИмяБазы') WITH NO_INFOMSGS, ALL_ERRORMSGS;На больших базах проверка занимает заметное время и создает нагрузку на дисковую подсистему, поэтому планируйте её на период минимальной активности. Если CHECKDB сообщает об ошибках целостности, не запускайте ремонт с потерей данных (REPAIR_ALLOW_DATA_LOSS) без резервной копии — сначала попробуйте восстановление из актуального бэкапа.
⚠️ Внимание: вариант
REPAIR_ALLOW_DATA_LOSSфизически удаляет поврежденные данные и не гарантирует их восстановление. Это крайняя мера, применяемая только после создания копии базы и оценки потерь.
☑️ Базовая диагностика ошибки 9694
Шаг 3. Проверьте права и контекст выполнения
Значительная часть ошибок с серьезностью 16 связана с разрешениями. Проверьте, какая учетная запись указана в записи журнала, и есть ли у неё необходимые права на объект и базу. Особое внимание уделите заданиям SQL Server Agent: задание может выполняться от имени учетной записи службы, права которой отличаются от прав пользователя, запускающего тот же код вручную.
Также проверьте контекст выполнения внутри модулей: если хранимая процедура использует EXECUTE AS, эффективные права определяются указанным контекстом, а не правами вызывающего. Несоответствие прав в цепочке владения (ownership chaining) — частый источник подобных сбоев.
SELECT name, type_desc, execute_as_principal_id
FROM sys.procedures
WHERE execute_as_principal_id IS NOT NULL;
Как посмотреть эффективные права учетной записи
Выполните в контексте нужной базы запрос SELECT * FROM fn_my_permissions(NULL, 'DATABASE') от имени проверяемой учетной записи (или через EXECUTE AS LOGIN). Для прав на конкретный объект используйте fn_my_permissions с указанием объекта.
Шаг 4. Проанализируйте запрос и версию сервера
Если ошибка возникает при выполнении конкретного запроса, проверьте его текст на обращения к удаленным или переименованным объектам, временным таблицам с конфликтующими именами и функциям, зависящим от уровня совместимости базы. Иногда проблема проявляется только после обновления экземпляра или миграции базы с другого сервера.
Часть ошибок внутреннего характера устраняется накопительными обновлениями SQL Server. Сверьте номер сборки экземпляра (SELECT @@VERSION) со списком известных исправлений на сайте Microsoft: если ваша сборка сильно устарела, обновление до актуального накопительного пакета — обоснованный шаг. Перед обновлением сделайте резервные копии системных и пользовательских баз.
Серьезность 16 означает исправимую ошибку уровня пользователя: сервер работает, и проблему почти всегда можно локализовать по полному тексту сообщения и контексту выполнения.
Когда обращаться в поддержку
Самостоятельная диагностика исчерпывается, если ошибка сопровождается дампами в журнале, повреждением данных, которое CHECKDB не может исправить без потерь, или если состояние 27 указывает на внутренний дефект конкретной сборки. В таких случаях соберите пакет данных для поддержки: полный текст ошибки, фрагмент журнала, версию сервера, скрипт воспроизведения и результаты CHECKDB.
⚠️ Внимание: не перезапускайте службу SQL Server и не применяйте недокументированные флаги трассировки «для проверки» — это может скрыть симптомы без устранения причины и усложнить последующую диагностику.
Таблица: расшифровка компонентов ошибки
| Компонент | Значение | Что означает |
|---|---|---|
| Номер ошибки | 9694 | Идентификатор сообщения в sys.messages; смысл раскрывается полным текстом |
| Серьезность | 16 | Ошибка, исправимая пользователем/администратором; сеанс обычно сохраняется |
| Состояние | 27 | Внутренняя метка ветки кода SQL Server, публично не расшифровывается |
| Источник | Журнал SQL Server / приложение | Место, где фиксируется полный текст и контекст ошибки |
| Первичная проверка | sys.messages + журнал | Получение текста сообщения и смежных записей |
Часто задаваемые вопросы
Опасна ли ошибка 9694 для целостности данных?
Сама по себе серьезность 16 не указывает на повреждение данных — это уровень исправимых пользовательских ошибок. Однако если ошибка сопровождается сообщениями о повреждении страниц или сбоях CHECKDB, требуется отдельная проверка целостности базы.
Можно ли найти расшифровку состояния 27?
Нет, значения состояния для большинства ошибок публично не документируются. Это внутренняя метка кода SQL Server, полезная в первую очередь инженерам поддержки Microsoft при анализе конкретного сценария.
Ошибка возникает только в задании SQL Agent, а вручную запрос работает. Почему?
Наиболее вероятная причина — различие контекстов безопасности: задание выполняется от имени другой учетной записи с иными правами. Проверьте владельца задания и учетную запись службы SQL Server Agent.
Поможет ли перезапуск службы SQL Server?
Перезапуск может временно скрыть симптом, если причина связана с временным состоянием сеанса, но не устраняет корневую проблему. Сначала соберите диагностику, иначе после перезапуска ценная информация о контексте будет потеряна.
Нужно ли обновлять SQL Server из-за этой ошибки?
Если экземпляр работает на устаревшей сборке, а ошибка похожа на внутренний дефект движка, установка актуального накопительного обновления — разумный шаг. Перед обновлением обязательно создайте резервные копии всех баз и проверьте совместимость.