Пять аварий MS SQL Server: что делать и чего не делать

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

Сохраните в закладки сейчас. Когда понадобится - будет не до поиска.

Одно общее правило до начала. В любой аварии СУБД самые непоправимые потери приносит не сама авария, а торопливые действия в первые полчаса: команды из первой найденной статьи, перезапуски «а вдруг поможет», удаление файлов, которые «мешают». Прежде чем что-то делать - сделайте файловую копию каталогов с данными и логами, если они доступны. Это единственный шаг, о котором ещё никто не пожалел.

Авария 1. «Журнал транзакций переполнен» - ошибка 9002

Как выглядит. Приложение перестаёт писать в базу. В логах - ошибка 9002: «Журнал транзакций для базы данных переполнен», в англоязычной версии «The transaction log for the database is full». Пользователи 1С видят её как «Ошибка СУБД: журнал транзакций для базы данных переполнен». Чтение при этом обычно работает, поэтому первые минуты авария выглядит загадочно: отчёты строятся, документы не проводятся.

Что произошло. SQL Server обязан хранить журнал транзакций до тех пор, пока записанное в нём не станет ненужным. Если журнал не освобождается - он растёт, пока не съест диск или собственный лимит. Причину сервер называет сам, спросите его:

SELECT name, log_reuse_wait_desc FROM sys.databases;

Дальше по значению. LOG_BACKUP - база в модели восстановления full, а бэкапы журнала не делаются: самая частая причина, девять случаев из десяти, классика инсталляций «поставили и забыли». ACTIVE_TRANSACTION - какая-то транзакция открыта часами и держит журнал: ищите её через DBCC OPENTRAN. REPLICATION - репликация не успевает или сломана, журнал её заложник. AVAILABILITY_REPLICA - реплика AlwaysOn отстала или недоступна, журнал копится для неё.

Чего не делать. Не удаляйте файл журнала - база после этого не откроется, и простая авария превратится в тяжёлую. Не переключайте базу в simple по совету с форума: это рвёт цепочку восстановления на момент времени, а в группе доступности вообще невозможно. Не делайте shrink журнала ритуалом «после каждого бэкапа» - файл снова вырастет, но уже с фрагментированной структурой.

Как чинить. При LOG_BACKUP - сделать бэкап журнала, при нехватке места добавить второй файл журнала на свободном диске как временную меру, после стабилизации - один осознанный shrink до рабочего размера. При ACTIVE_TRANSACTION - найти транзакцию, понять её происхождение и корректно завершить; чаще всего это забытая сессия или зависший джоб. При репликации и AG - чинить их, журнал освободится сам.

Как не повторить. Модель full - это обещание восстановить базу на любую минуту, и оно требует бэкапов журнала каждые 10-15 минут. Не нужна точка восстановления - выбирайте simple осознанно. Нужна - настройте бэкапы журнала и алерт на его заполнение. Третьего варианта нет, все «третьи варианты» заканчиваются этой главой.

Авария 2. Служба SQL Server не запускается - ошибка 3417

Как выглядит. После перезагрузки, переноса, обновления или сбоя питания служба MSSQLSERVER не стартует. В журнале событий Windows - ошибка 3417, рядом могут быть 1814 и 1067.

Что произошло. Ошибка 3417 означает одно: сервер не смог поднять системные базы, и почти всегда речь про master. Причины по убыванию частоты: файлы системных баз недоступны - переехали, сменились права, каталог зашифрован или заблокирован антивирусом; повреждение master после сбоя диска; нехватка места там, где живёт tempdb.

Чего не делать. Не переустанавливайте SQL Server поверх - это главная ошибка этой аварии: переустановка не чинит данные, зато уничтожает конфигурацию и усложняет восстановление. Не раздавайте права Everyone/Full Control на каталоги наугад. Не удаляйте «подозрительные» файлы из каталога DATA.

Как чинить. Первым делом - файл ERRORLOG в каталоге Log: там написана точная причина, обычно вплоть до имени файла, который не открылся. Если дело в правах или путях - вернуть как было. Если повреждён master - восстановить его из бэкапа, запустив сервер в однопользовательском режиме. Крайний случай - пересборка системных баз с последующим восстановлением конфигурации, и вот здесь без бэкапа master становится по-настоящему больно.

Как не повторить. Бэкапьте системные базы. Про master и msdb забывают практически все - а в msdb живут все ваши джобы, расписания и история бэкапов.

Авария 3. База «ожидает восстановления» - recovery pending и suspect

Как выглядит. База в Management Studio помечена как «Recovery Pending», «Suspect» или «Ожидает восстановления» и не открывается. Обычно обнаруживается утром после ночного сбоя.

Что произошло. Recovery pending - сервер не смог начать восстановление базы: файл недоступен или не хватает ресурсов. Suspect - восстановление началось и упало: как правило, повреждён журнал или страницы данных, на середине отката база осталась в неопределённом состоянии.

Чего не делать. Здесь живёт самый разрушительный совет интернета: перевести базу в EMERGENCY и запустить CHECKDB с REPAIR_ALLOW_DATA_LOSS. Вчитайтесь в название параметра: «разрешить потерю данных». Эту команду запускают первой, не сняв копию файлов, - и теряют данные там, где восстановление из бэкапа вернуло бы всё. REPAIR_ALLOW_DATA_LOSS - последний инструмент, но не первый. Вторая по разрушительности идея - отсоединить проблемную базу: detach для suspect-базы проходит, а attach обратно уже нет, и вы остаётесь с файлами, которые никуда не подключаются.

Как чинить. Порядок такой. Файловая копия данных и журнала - до любых действий. Затем ERRORLOG: причина всегда названа там. Если есть рабочая цепочка бэкапов - восстановление из неё почти всегда быстрее и всегда чище любого ремонта. Ремонт через EMERGENCY - только когда бэкапов нет, только после копии файлов и желательно не в одиночку: цена ошибки здесь измеряется содержимым базы.

Как не повторить. Ответ скучный и оттого редкий: рабочие, проверенные восстановлением бэкапы. Про это - пятая глава.

Авария 4. Ошибки 823 и 824 - повреждение страниц

Как выглядит. В логе SQL Server - ошибка 823 или 824: сбой ввода-вывода или несовпадение контрольной суммы страницы. Иногда падает конкретный запрос, который «просто читал таблицу». Иногда ошибку находит регулярный CHECKDB.

Что произошло. База получила с диска не то, что туда записывала. Виновник ниже СУБД: диск, контроллер, кэш записи, файловая система, виртуализация. SQL Server здесь гонец с плохой вестью, но не причина.

Чего не делать. Не игнорируйте единичную 824 - «один раз не считается» здесь не работает: повреждения от деградирующего диска копятся, ничем себя не выдавая, и чем позже вы отреагируете, тем меньше останется целых бэкапов. Не запускайте REPAIR_ALLOW_DATA_LOSS рефлекторно - см. предыдущую главу.

Как чинить. Список пострадавших страниц ведёт сам сервер - msdb.dbo.suspect_pages. Дальше у MS SQL есть инструмент, который на больших базах меняет масштаб аварии: восстановление отдельных страниц из бэкапа. Не всей базы - конкретных повреждённых страниц: они достаются из полного бэкапа, доводятся разностным, затем цепочкой журналов и хвостом журнала до текущего момента. На базе в терабайты это минуты вместо часов. В Enterprise база при этом продолжает работать, в Standard потребуется короткий офлайн - всё равно несопоставимый с полным восстановлением.

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

Как не повторить. Проверьте, что у баз включена контрольная сумма страниц (PAGE_VERIFY CHECKSUM - у старых баз, переживших много миграций, встречается NONE). Регулярный CHECKDB - по расписанию; запуски по настроению за регулярность не считаются. Алерты на ошибки 823-825 - настраиваются за десять минут, экономят недели.

Авария 5. Бэкапы есть - восстановления нет

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

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

Чего не делать. Не верить зелёному статусу джоба. Успешный бэкап и пригодный бэкап - разные события, между ними лежит проверка восстановлением.

Как чинить. Эта глава чинится только до аварии. RESTORE VERIFYONLY - минимум, который проверяет читаемость файла. Настоящая проверка - регулярное тестовое восстановление на отдельном сервере, по расписанию, с CHECKDB поверх восстановленной базы. Звучит избыточно ровно до того дня, когда пригодится.

Вместо заключения - про первые полчаса

Перечитайте четыре раздела «чего не делать» - они складываются в одно правило: авария прощает бездействие и не прощает суеты. Файловая копия, ERRORLOG, диагноз - и только потом действия. Если диагноз не складывается или цена ошибки слишком высока - позовите того, кто разбирал такое десятки раз: мы подключаемся в день обращения.

А если хочется, чтобы этот текст никогда вам не пригодился, - это тоже делается: мониторинг, бэкапы с проверкой восстановлением, регламентное обслуживание. Называется абонентское сопровождение баз данных, и все пять аварий из этой статьи в нём предусмотрены до того, как случатся.