Подписки на события (alerts) еще были в версии SCCM 2012 RTM, но только для оповещения состояния клиентов System Center Endpoint Protection, в версии SCCM 2012 SP1 их расширили и добавили новые события. Найти можно в Administration — Alerts: Active Alerts — ваши активные предупреждения, All Alerts — все существующие предупреждения и Subscriptions — подписка о событиях на электронную почту.
В разделе Subscriptions настраивается подключение к почтовому серверу:
Если вы используете Enpoint Protection у себя в инфраструктуре, то вы уже с ними сталкивались, когда настраивали оповещения об обнаружении вирусов и прочего нехорошего стаффа, если нет, то я бы точно рекомендовал включить оповещения о событиях по базе данных, если у вас нет стороннего ПО мониторинга, как например System Center Operations Manager. Это Warning low free space alert for database on site и Critical low free space alert for database on site.
На выходе (в почтовой рассылке) вы увидите что-то подобное:
Оповещение: Предупреждение о низком уровне свободного пространства для базы данных на сайте: КОД_САЙТА
Тип оповещения: Предупреждение о свободном пространстве для базы данных
Серьезность: Предупреждение
Время активности (UTC): 8/9/2015 11:21 PM
Условие: Создавать предупреждающее оповещение, если на диске с файлом базы данных свободно более 5 (но менее 10) ГБ.
Текст оповещения: Предупреждающее оповещение о свободном пространстве для файлов базы данных для сайта ASD. Текущее свободное пространство для файлов базы данных — 9 ГБ, что ниже порога предупреждения (10 ГБ), но выше критического порога (5 ГБ).
А при чем тут собственно размер журнала транзакций базы данных службы SQL Report Services? А при том, что по-умолчанию в SQL включено авторасширение (autogrowth) лог файла и размер файла указан 2 ТБ. И если у вас база данных сервера отчетов находится на одном сервере с базой данных вашего сайта SCCM (и еще веселей, если на одном хранилище), то можно получить примерно такую картинку (52 Гб удовольствия, а то и больше):
Рано или поздно хранилище подойдет к концу. ЗЫЖ в моем случае это и произошло. (да, да, если через VSS пинать резервную копию системы, то транзакшен лог чистится, но бывают ситуации, когда вот так)
Как побороть? Открываем SQL Management Studio, заходим в свойства базы данных сервера отчетов, в моем случае это ReportServer, в Options переключаем Recovery model в Simple.
Далее, в Tasks — Shrink выбираем Files.
В File type — Log и жмем ок.
Та-дам-дам.
Чтобы подобное на повторилось, в свойствах базы данных можно изменить значение авторасширения (autogrowth) и ограничить размер вашего хранилища, на котором лежит база с журналом транзакций.
