Здравствуйте!
Имеется более 30 розничных магазинов с 1С Розница 2.2.
Полные резервные копии базы делаются раз в сутки, журнала транзакций - каждые полчаса в рабочее время. Модель восстановления - полная. И везде файл журнала транзакций сравним по размеру с файла базы, например:
1) База 35 Гб, лог 60 Гб - бэкапы базы 8.5 Гб и первый бэкап журнала транзакций после бэкапа бызы 15,5 Гб (остальные весят несколько мегабайт).
2) База 25 Гб, лог 32 Гб - бэкапы базы 5 Гб и первый бэкап журнала транзакций после бэкапа бызы 9 Гб (остальные весят несколько мегабайт).

Насколько я понимаю, после полной резервной копии базы файл журнала транзакций должен быть фактически пустой и соответственно хорошо ужиматься. Отсюда вопрос - почему резервная копия журнала транзакций такая большая и как ее уменьшить?

SQL Server 2017

Файл лога 60 Гб - это когда? Разве он не должен чиститься после полного бэкапа?

(2) 1. 60 Гб постоянно.
2. Как я понял, должен, поэтому и спрашиваю.

Может поможет http://catalog.mista.ru/public/277252/

(0) потому что индексы заново перестраиваете по всем таблицам, а не где это необходимо.

https://docs.microsoft.com/ru-ru/sql/relational-databases/indexes/reorganize-and-rebuild-indexes?view=sql-server-ver15

(0) сталкивался с этой штукой в 2017.
Проверь следующую ситуацию:
1. Проверь "Свойства базы" => "Файлы" => "Начальный размер" у файла типа "Журнал"
Он выставляется автоматически по максимальному возможному.
(т.е. был 10 Мб на старте, день поработал, лог вырос до 10 Гб, он автоматом ставит на начальный размер  Гб)
2. Выстави 100 мб например начальный размер.
3. Поработай некоторое время (Чтобы лог вырос)
4. Сделай бэкап лога транзакций, и обрати внимание на п.1 (Начальный размер установится - его макс. значение)
5. Если поставить начальный размер 100 мб опять и сделать "Шринк лога" - он сразу уменьшится до нужного размера.

(2) нет.

(0) воткни шринк лога после бэкапа в плане обслуживания через стрелочку.. усё

(8) и что это даст? бэкап лога так и будет висеть 15.5 и 9гб.

Избавит от проблем подобный скрипт: http://catalog.mista.ru/public/256292/
Инфа 100%

(9) не будет

(10) не очень понимаю вашу схему: rebuild -> backup -> shrink?
Между rebuild и backup может сделаться резервная копия журнала транзакций и на диске останутся файлы 15.5 и 9 Гб.

(11) лг за 10 минут не вырастит на 15 гигов, и бэкап лога раз в полчаса будет мааааленьким

(12) 10 минут полный rebuild таблиц у баз на 60Гб? Хмм...

(13) нет
http://pics.rsh.ru/img/backUp_xoryv6cy.jpg

(14) У вас видимо бэкап лога стоит в определенном промежутки времени по часам, в которые не попадает задание по перестроению индексов. В этом случае да, расти не будет.

(15) индексы перестраиваются регламентом, раз в неделю, и да оно в "дырке" заданий..

Спасибо всем за ответы, но пока нет возможности потестировать.

(5) Благодарю, проверил и действительно большой размер бэкапа лога из-за перестроения индекса!