Ответы:
Он будет усекаться автоматически, но это сильно отличается от сжатия. Усечение освобождает пространство журнала для повторного использования, физическое сжатие уменьшает размер файла, чтобы освободить пространство для ОС. Если ваш журнал увеличился до его текущего размера, вполне вероятно, что он снова вырастет, если вы уменьшите его.
Я бы посоветовал узнать, какое типичное и максимальное использование журналов для вашей системы. Приведенный ниже запрос (не мой, усиленный из сценариев Glen Berrys DMV) может быть выполнен вручную или вы можете записать вывод в таблицу с помощью задания агента. Если вы зарегистрируете его в таблице в течение недели или около того, вы получите представление о типичном использовании и, что более важно, когда процесс приводит к тому, что журнал выходит за рамки ожидаемого.
SELECT
db.[name] AS [Database Name]
, db.recovery_model_desc AS [Recovery Model]
, db.log_reuse_wait_desc AS [Log Reuse Wait Description]
, ls.cntr_value AS [Log Size (KB)]
, lu.cntr_value AS [Log Used (KB)]
, CAST(
CAST(lu.cntr_value AS FLOAT) / CAST(ls.cntr_value AS FLOAT)
AS DECIMAL(18,2)
) * 100 AS [Log Used %]
, db.[compatibility_level] AS [DB Compatibility Level]
, db.page_verify_option_desc AS [Page Verify Option]
, db.is_auto_create_stats_on, db.is_auto_update_stats_on
, db.is_auto_update_stats_async_on, db.is_parameterization_forced
, db.snapshot_isolation_state_desc, db.is_read_committed_snapshot_on
FROM sys.databases AS db
INNER JOIN sys.dm_os_performance_counters AS lu
ON db.name = lu.instance_name
INNER JOIN sys.dm_os_performance_counters AS ls
ON db.name = ls.instance_name
WHERE lu.counter_name LIKE N'Log File(s) Used Size (KB)%'
AND ls.counter_name LIKE N'Log File(s) Size (KB)%'
AND ls.cntr_value > 0
OPTION (RECOMPILE);
Усечение журнала транзакций описывает как и когда происходит усечение журнала.
Если записи журнала никогда не удалялись из журнала транзакций, он в конечном итоге занимал бы все дисковое пространство, доступное для физических файлов журнала. Усечение журнала автоматически освобождает пространство в логическом журнале для повторного использования журналом транзакций.
Факторы, которые могут задержать усечение журнала, являются полезным справочным материалом для понимания, почему ваш журнал может не усечь и, следовательно, вырасти больше, чем ожидалось.
Как упоминалось ранее, нет, он не будет автоматически сокращаться. Это уберет немного мусора как бы то ни было.
Причина в том, что в модели полного восстановления вы говорите SQL, что вы хотите делать резервные копии журнала для восстановления на определенный момент времени, таким образом, он ведет учет всех транзакций, выполненных с базой данных.
Поскольку вы говорите, что хотите восстановить на определенный момент времени, вам необходимо сделать полное резервное копирование и создать резервные копии. Когда вы завершите резервное копирование tlog, оно очистит содержимое журнала (кроме хвостовой части) и начнет заново.
Это может помочь, если вы считаете эти файлы контейнерами.
Мое предложение состоит в том, что, если tlogs стали большими и неуправляемыми, сокращают полную резервную копию. Переключение в SIMPLE восстановления модели и SHRINK файл TLOG. Вернитесь к модели полного восстановления и выполните обслуживание фрагментации *. Как и другие опубликовали, это не лучшая практика и приведет к высокой степени фрагментации.
Спланируйте и начните режим резервного копирования после этого.
* Индекс перестроить / реорганизовать операции и дефрагментацию на уровне диска . Это не часть обслуживания журналов: вы ведете свои журналы T, создавая их резервные копии. Это контейнеры, которые растут, когда приближаются к емкости. Перестройка / реорганизация может помочь в восстановлении после неправильного управления журналами, что приводит к большому использованию диска.