Архитектура обработки фатальных сбоев (Severity 21) в Microsoft SQL Server

Сообщения об ошибках с уровнем серьезности Severity 21 (Fatal Error in Database Processes) указывают на критический сбой внутри ядра СУБД (SQLOS), при котором изолированный системный процесс (SPID) или поток выполнения встретил невосстановимое повреждение структур данных. Шаблон системной ошибки: «Warning: Fatal error %d occurred at %s. Note the error and time, and contact your system administrator» (MSSQL Error: 21). При возникновении такой ошибки SQL Server немедленно принудительно разрывает клиентскую сессию, откатывает текущую транзакцию и формирует минидамп памяти (Memory Mini-dump / Assert Stack Trace).

Бизнес-риски

Аварийный сброс тяжелых регламентных операций (закрытие месяца, расчет себестоимости в 1С), риск логического и физического повреждения страниц данных на диске (Torn Pages / Bad Checksum), временный переход базы данных в статус In Recovery или Suspect.

Типичные первопричины уровня Severity 21

Регламент локализации и восстановления после ошибки MSSQL Error 21

Сценарий 1: Проверка физической и логической целостности базы через DBCC CHECKDB

Немедленно запустите комплексную проверку целостности поврежденной базы данных:

-- Проверка целостности базы данных с выводом всех детальных сообщений об ошибках:
DBCC CHECKDB ('trade_db') WITH NO_INFOMSGS, ALL_ERRORMSGS;
GO

-- Если DBCC CHECKDB выявил ошибки распределения страниц (Allocation Errors):
-- 1. Переведите базу в Single User Mode:
ALTER DATABASE [trade_db] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
-- 2. Попытка восстановления без потери данных (если возможно):
DBCC CHECKDB ('trade_db', REPAIR_REBUILD);
GO
-- 3. Возврат в Multi User:
ALTER DATABASE [trade_db] SET MULTI_USER;
GO

Сценарий 2: Анализ системного журнала SQL ERRORLOG и дампа памяти

Откройте файл ERRORLOG и найдите секцию ***Stack Dump вокруг времени сбоя:

# Поиск критических дампов в каталоге логов SQL Server через PowerShell:
Get-ChildItem -Path "C:\Program Files\Microsoft SQL Server\MSSQL*.MSSQLSERVER\MSSQL\Log\SQLDump*.mdmp" |
  Sort-Object LastWriteTime -Descending | Select-Object Name, Length, LastWriteTime

Если дамп указывает на стороннюю внешнюю DLL (например, антивирусный перехватчик или некорректный Extended Stored Procedure), удалите или обновите проблемный модуль.

Сценарий 3: Аппаратная диагностика дисковой подсистемы и RAM

1. Выполните проверку оперативной памяти сервера с помощью специализированных тестов (MemTest86 / встроенные аппаратные утилиты HP/Dell iLO/iDRAC).
2. Проверьте журнал системных событий System Event Log на наличие событий с источником disk, ntfs, storahci или megaraid (код события 7, 11, 15, 55).
3. Убедитесь, что для базы данных включен параметр PAGE_VERIFY CHECKSUM: ALTER DATABASE [trade_db] SET PAGE_VERIFY CHECKSUM;.

Типовые ошибки администраторов

• Применение REPAIR_ALLOW_DATA_LOSS без бэкапа: Команда REPAIR_ALLOW_DATA_LOSS физически удаляет поврежденные страницы вместе со всеми данными пользователей. Применяйте ее ТОЛЬКО при отсутствии актуальной резервной копии.
• Игнорирование накопительных обновлений (CU): Многие падения ядра по Severity 21 вызваны известными багами оптимизатора запросов, исправленными в свежих Cumulative Updates (CU) от Microsoft.