Добрый день. Вчера уже задавал вопрос, но решение по существу

так и не получил. Поэтому продублирую снова, вдруг кто ещё увидит.
Имеется SQL Server 2014 и 2019.
На обоих созданы мастером через Studio планы обслуживания по бэкапу баз и логов. Они идентичны.
Во вложенном плане после шага по бэкапу логов идёт задача по сжатию бд с параметром по возврату места операционной системе. Вывод T-SQL такой: DBCC SHRINKDATABASE(N'DB', 10, TRUNCATEONLY)
На сервере 2014, после выполнения данного вложенного плана, файл лога физически ужимается до минимального размера.
На сервере 2019, после выполнения данного вложенного плана, файл лога физически не ужимается вообще.
Свободное место в логах присутствует в избытке, транзакций нет, в свойствах баз автосжатие выключено, DBCC SHRINKFILE нигде не указано, планы выполняются без ошибок, у учетной записи агента права есть.
Если через Studio на сервере 2019 выбрать сжатие файла лога, выставить сжатие до минимально возможного размера, то в этом случае лог физически сжимается.
Почему происходит физическое сжатие на 2014 и почему не происходит физическое сжатие на 2019?
Заранее спасибо.

Под учеткой агента скриптом пробовал ужимать?

Как решение - использовать командлет Invoke-DbaDbShrink из dbatools.io с параметрами уменьшения файла по 100МБайт, это поможет вам уменьшить размер файла. Но "рекомендации лучших собаководов" - не урезать файл лога, т.к. рост файла влияет на производительность. Еще интересно как настроен в свойствах БД размер и увеличение файла лога.

По-моему говорили ,что возможно последний vlf используется. dbcc loginfo поможет понять так ли это.

+ Truncateonly обрезает свободное место с конца файла. Если текущий vlf в конце, то эффекта не будет.

У меня корень вопроса - почему. Т.е. в чем причина.

Какой смысл? Все учетки и права идентичны.

Чекал. Всё норм

Активная транзакция.

Не проверь не узнаешь

БД не зеркалируется?

Может у тебя модель восстановление на 2019 Full стоит?

Запусти профилер и в студии запусти команду, которая правильно отрабатывает сжатие. В трассировке увидишь запрос, который студия выполняет на 2019. Сравни его со своим в 2014

Конечно

ALTER DATABASE DBNAME SET RECOVERY SIMPLE; GO DBCC SHRINKDATABASE (DBNAME,1,TRUNCATEONLY); ALTER DATABASE DBNAME SET RECOVERY FULL;

Ломается цепочка бекапов, разваривается ao и прочее

Говорю ж, на 2014 всё норм

тебе надо в момент попытки сжатия лога посмотреть что там за запрос генерится, на чем он мб висит и тд

Это и так ясно. Вопрос в другом - почему.

SELECT log_reuse_wait_desc FROM sys.databases

Nothing