Что делать, если в SQL Server 2016 перестали выполняться планы обслуживания и зависают бэкапы

Ситуация, когда годами отлаженные планы обслуживания SQL Server внезапно перестают запускаться или «зависают» в состоянии вечного выполнения, является критической для любой организации. Отсутствие свежих бэкапов и невыполнение регламентных процедур (проверка целостности, обновление статистики) может привести к необратимой потере данных или резкому снижению производительности 1С. Разберем по шагам, почему это происходит и как восстановить работоспособность сервера.

Первичная диагностика: анализируем «Монитор активности заданий»

Первым делом нам необходимо выяснить, на каком этапе «спотыкается» сервер. В среде SQL Server Management Studio (SSMS) за работу по расписанию отвечает SQL Server Agent. Рассмотрим, как получить детальную информацию о текущем состоянии дел:

1. Развернем узел SQL Server Agent в обозревателе объектов.
2. Нажмем правой кнопкой мыши на Job Activity Monitor (Монитор активности заданий) и выберем View Job Activity.
3. Проанализируем колонку Status. Если мы видим, что задание плана обслуживания находится в статусе Executing уже несколько часов или дней, это явный признак блокировки или внутреннего сбоя.

Как показывает практика, часто один из вложенных планов (например, Index Reorganization) может выполняться бесконечно долго из-за возросшего объема данных или конфликтов блокировок. В этом случае остальные шаги плана — включая критически важные бэкапы — просто не могут начаться. Рекомендуется принудительно остановить зависшее задание через контекстное меню (Stop Job) и попробовать запустить следующий шаг (бэкап) вручную, чтобы убедиться в его работоспособности.

Проблема разросшихся системных таблиц в базе msdb

Мало кто задумывается, что SQL Server записывает каждое действие своих агентов в системную базу данных msdb. Если история заданий не очищалась месяцами, таблицы sysjobhistory и sysmaintplan_log могут разрастись до миллионов записей. В определенный момент Агент тратит больше времени на попытку записать лог выполнения, чем на само выполнение задачи.

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

USE msdb;
GO
DECLARE @CleanupDate datetime = DATEADD(dd, -30, GETDATE());
EXEC sp_purge_jobhistory @oldest_date = @CleanupDate;
GO

После очистки истории Агент начнет работать значительно быстрее, и «невидимые» зависания могут исчезнуть сами собой. Рекомендуется включить автоматическую очистку истории в свойствах SQL Server Agent.

Взаимодействие с Integration Services (SSIS) и dtexec

Важно понимать, что планы обслуживания в SQL Server 2016 — это не просто T-SQL скрипты, а полноценные пакеты SSIS (SQL Server Integration Services). Для их запуска Агент вызывает утилиту dtexec.exe. Проанализируем возможные проблемы на этом уровне:

1. Переменные окружения: Если на сервере обновлялось ПО или менялись пути в системной переменной PATH, SQL Server может потерять доступ к нужной версии dtexec.exe.
2. Обновления .NET Framework: Поскольку SSIS тесно завязан на компонентах .NET, некорректная установка обновлений Windows может заблокировать запуск пакетов.
3. Временные файлы: Пакет перед запуском создает временный файл в папке профиля службы SQL Server (обычно C:\Users\Имя_Службы\AppData\Local\Temp). Если эта папка переполнена или у службы нет прав на запись, задание зависнет без вывода ошибок в лог SQL.

Проверить ошибки на уровне ОС можно через Event Viewer (Просмотр событий), раздел Application. Ищите ошибки от источников SQLISPackage или SQLAgent. Если вы видите код исключения 0xc0000005, это явный признак проблем с бинарными файлами или памятью.

Конфликты с антивирусным ПО и правами доступа

Иногда «ни с того ни с сего» планы перестают работать после обновления антивируса. Рассмотрим механизм блокировки: антивирус может начать проверять каждый запускаемый процесс dtexec.exe или блокировать доступ к сетевым папкам, куда должны складываться бэкапы.

Выясним причину через смену учетной записи: Попробуйте временно изменить учетную запись, под которой запущен SQL Server Agent, на Local System через SQL Server Configuration Manager, а затем верните обратно на сервисную учетную запись. Это действие часто исправляет поврежденные «токены безопасности» в сессии Windows и перезаписывает необходимые права в локальных политиках безопасности (например, право на Log on as a service или Replace a process level token).

Ошибки в задаче «Очистка после обслуживания»

Частая причина зависания всего плана — компонент Maintenance Cleanup Task. Если в настройках указано удаление файлов бэкапов с определенным расширением, и в целевой папке накопились десятки тысяч файлов, процесс сканирования может занять часы.

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

Альтернативный подход: уход от визуальных планов к T-SQL скриптам

Если визуальные планы обслуживания в SQL Server 2016 продолжают вести себя нестабильно, профессиональное сообщество рекомендует рассмотреть переход на использование скриптов Олы Халленгрена. Это золотой стандарт в мире администрирования SQL Server.

Почему это лучше:

• Они используют чистый T-SQL и не зависят от SSIS или dtexec.exe.
• Они гораздо подробнее логируют каждый шаг в обычную таблицу или текстовый файл.
• Их легко отлаживать: вы просто копируете код из задания и запускаете его в окне запроса.

Для реализации такого подхода нам потребуется создать обычное задание (Job) в Агенте и прописать в нем вызов хранимой процедуры, например:

EXECUTE [dbo].[DatabaseBackup]
@Databases = 'USER_DATABASES',
@Directory = 'D:\Backups',
@BackupType = 'FULL',
@Verify = 'Y',
@CleanupTime = 168

Этот код выполнит полный бэкап всех пользовательских баз, проверит их целостность и удалит файлы старше 168 часов (7 дней).

Резюме

Если планы обслуживания перестали работать:

1. Проверьте Job Activity Monitor на наличие зависших процессов и убейте их.
2. Очистите историю msdb с помощью sp_purge_jobhistory.
3. Убедитесь, что антивирус не блокирует dtexec.exe.
4. Проверьте наличие свободного места и прав доступа в папке TEMP профиля пользователя SQL.
5. Рассмотрите возможность перехода на скриптовые методы обслуживания, которые более прозрачны в диагностике.

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