Приветствую всех.

Перешли на Ms sql server 2017 и 1с сервер. База данных весит после разворачивания из .dt 20гб. + журнал транзакций 14гб. Модель восстановления - полная.
Все вроде работает замечательно за исключением одного момента, после ежедневного плана обслуживания:
- в 2.00 ночи выполняем проверку целостности, реорганизацию индекса, обновление статистик, очистка кеша, резервное копирование базы данных ну и очистки после.
- с 8.00 утра до 18.00 вечера резервное копирование журнала транзакций каждые пол часа

Переключал на простую модель восстановления, уменьшал размер ЖТ до 1гб или 2гб, возвращал на полную, но через день ЖТ снова разрастался до 14гб. Как я понял он так растет после реорганизации индекса, но почему тогда он не усекается после выполнения резервного копирования как об этом пишет Майкрософт?

добавлю, база данных крутится на ссд m2 в рейд 10. Может вообще не имеет смысла делать реорганизацию индекса каждый день на ссд?

(0) "но почему тогда он не усекается после выполнения резервного копирования как об этом пишет Майкрософт"
А вы truncate со shrink не перепутали?

Я это так вижу:
Для моделей полного восстановления и моделей восстановления с неполным протоколированием, если контрольная точка была создана после предыдущего резервного копирования, усечение происходит после резервного копирования журнала. Майкрософт

(3) Усечение журнала не приводит к уменьшению размера файла.

(4) т.е. это пустой файл который будет разрастаться до тех пор пока не заполнит все свободное место на диске и его надо уменьшать руками или написать скрипт по его уменьшению в автоматическом режиме?

(5) Усечение означает что место в файле объявлено свободным для новых записей журнала.

(6) Я это понимаю, не дает покоя, что нужен такой огромный журнал транзакций для одной базы, а когда развернем вторую базу которая в файловом варианте больше чем та которая сейчас на сервере. Как быстро забьет все свободное место на диске журнал транзакций двух баз.

Использовать простую модель восстановления не хочется.

Как тогда поступают с ЖТ на огромных базах?

Ежедневная реорганизация это overkill, одного раза в неделю обычно за глаза. ЖТ можно, конечно, сжимать после этого, но имхо особого смысла в этом нет, если он в размерах стабилизировался то пусть так и живёт

ЖТ нужно не сжимать, а бэкапить

а растет может из-за перепроведения какого

а реорганизация индекса - это не транзаккционное действие, поэтому в ЖТ не пишется

(7) вот ты когда дышишь, у тебя при вдыхании увеличивается объем торса.
через сколько ты и коллега заполните кабинет до предела? может лучше держать вас на улице?

(7) А зачем вам полная модель?

(14) иначе не получится получить ачивку БигДатаИнженер с 10 гиговой базы бухни.

(12) Реорганизация это полностью логируемая операция, просто она кусками выполняется по капотом, поэтому может и не приводить к разрастанию лога. Но поскольку у топикстартера жт только в рабочее время бэкапится, лог без вариантов будет пухнуть

(9) Хорошо, попробую так. Понаблюдаю.

(17) Можете ещё бэкап лога непосредственно перед обслуживанием баз делать, чтоб по максимуму его освободить

(18) спасибо. Обязательно попробую.