Почему журнал транзакций продолжает расти в режиме простого восстановления с ночным резервным копированием

Прежде чем сразу пометить как дубликат , я прочитал Майка Уолша « Почему журнал транзакций продолжает расти или не хватает места? , но я не думаю, что это дало ответ на мою ситуацию. Я просмотрел дюжину или около того похожих вопросов, но соответствующие, в основном, просто сказали «дубликат» и указали на вопрос Майка.

Подробно: у меня есть набор баз данных ~ 500 МБ на SQL Server 2008 R2, все в режиме ПРОСТОГО восстановления (не мой выбор), ночные полные резервные копии, файлы данных ~ 200 МБ и файлы журналов ~ 300 МБ. Объем журнала не увеличивается до 300 МБ сразу, а довольно медленно в течение пары месяцев. Ни по одной из них нет открытых транзакций, по крайней мере, согласно sp_who2 и монитору активности. Если я щелкну правой кнопкой мыши по базе данных и выберу свойства, это скажет мне, что есть ~ 50 МБ свободного места. Особенно сразу после резервного копирования, не должен ли весь журнал быть свободным? В режиме SIMPLE журнал не должен быть свободным, если нет открытой транзакции?

log_reuse_wait_descfrom sys.databasesговорит «НИЧЕГО», что, исходя из вышеупомянутых вопросов и ответов, говорит, что не следует ждать чего-либо, чтобы повторно использовать пространство.

Если я сделаю 'DBCC SHRINKFILE', файл журнала сжимается до 1 МБ, поэтому он готов освободить место. Я могу настроить что-то, что еженедельно сжимает журналы и не дает вещам выйти из-под контроля, но я не понимаю, почему SQL Server заставил меня это сделать.

Я могу понять, была ли какая-то сумасшедшая транзакция, которая требовала 300 МБ для ее регистрации, но мы не делаем ничего экстремального, просто базовый OLTP. Из вопроса / ответа Майка:

Модель простого восстановления - Итак, с помощью приведенного выше введения проще всего сначала поговорить о модели простого восстановления. В этой модели вы говорите SQL Server - я в порядке, если вы используете файл журнала транзакций для восстановления после сбоя и перезапуска (у вас действительно нет выбора. Найдите свойства ACID, и это должно иметь смысл быстро), но как только вы не Это больше не нужно для этой цели восстановления после сбоя, продолжайте и снова используйте файл журнала.

SQL Server прослушивает этот запрос в Simple Recovery и сохраняет только ту информацию, которая ему необходима для восстановления после сбоя / перезапуска. Если SQL Server уверен, что он может восстановиться, потому что данные усилены в файл данных (более или менее), то данные, которые были усилены, больше не нужны в журнале и помечены для усечения, что означает, что они используются повторно.

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

Что мне не хватает? Что-то мешает SQL Server распознать данные как «усиленные» и освободить журнал?

(редактировать) Отчет о действиях - AKA немного знаний опасно

Узнав, что это «популярный вопрос», я почувствовал, что должен объяснить, что произошло 7 месяцев назад и чему я научился, чтобы спасти некоторых других от горя.

Прежде всего, доступное пространство, которое вы видите в SSMS при просмотре свойств в базе данных, - это пространство, доступное в файле данных. Вы можете просмотреть это, запустив в базе данных следующее, и вы увидите, что доступное пространство, сообщаемое SSMS, является разницей между FileSizeMB и UsedSpaceMB:

SELECT
    DB.name,
    MF.physical_name,
    MF.type_desc AS FileType,
    MF.size * 8 / 1024 AS FileSizeMB,
    fileproperty(MF.name, 'SpaceUsed') * 8/ 1024 AS UsedSpaceMB,
    mf.name LogicalName
FROM
    sys.master_files MF
    JOIN sys.databases DB ON DB.database_id = MF.database_id
WHERE   DB.name = 'yourdatabasename'

Это подтвердило, что в обычных условиях мы использовали очень мало места для журнала (20 МБ или меньше), но это приводит ко второму пункту ...

Во-вторых, мое восприятие роста бревен было медленным с течением времени. Однако в действительности журналы быстро росли по ночам, когда парень, ответственный за применение исправлений для этого стороннего приложения, применял исправления. Патч был выполнен в виде одной транзакции, поэтому в зависимости от патча 200 МБ данных требовалось 300 МБ журнала. Ключ к отслеживанию этого был запрос от Аарона Бертран на https://sqlblog.org/2007/01/11/reviewing-autogrow-events-from-the-default-trace

DECLARE @path NVARCHAR(260);

SELECT 
    @path = REVERSE(SUBSTRING(REVERSE([path]), 
    CHARINDEX('\', REVERSE([path])), 260)) + N'log.trc'
FROM    sys.traces
WHERE   is_default = 1;

SELECT 
   DatabaseName,
   [FileName],
    SPID,
    Duration,
    StartTime,
    EndTime,
    FileType = CASE EventClass 
       WHEN 92 THEN 'Data'
       WHEN 93 THEN 'Log'
    END
FROM sys.fn_trace_gettable(@path, DEFAULT)
WHERE
    EventClass IN (92,93)
ORDER BY
    StartTime DESC;

Это показало, что журнал увеличивался в определенные вечера, когда клиент не использовал базу данных. Это привело к разговору с парнем, применяющим патчи и ответом на загадку.

Еще раз спасибо за людей, которые помогли мне получить ответ.

Мы не можем догадаться, что является причиной этого, но SQL Server не просто увеличивает лог-файл до 300 МБ, а растет до 300 МБ, потому что в какой-то момент с момента последней операции сжатия ему понадобилось много места в журнале (будь то из-за одной большой транзакции или множества меньших параллельных). Вам нужно будет отследить события роста файла журнала (я говорил об этом здесь и здесь ), чтобы попытаться сузить, когда или почему это происходит (также, если вы установили размер файла журнала, равный 300 МБ или около того, он увеличится на 300 МБ). как только потребуется более 1 МБ места для размещения активных транзакций).

В любом случае, почему, по вашему мнению, вам нужно сжать файл журнала, когда он достиг 300 МБ? Вы действительно полностью прочитали все ответы на вопрос Майка ? Файл журнала НЕ собирается сокращаться сам по себе, потому что сжатие файла журнала до 1 МБ - просто так, чтобы он мог снова расти во время ваших крупнейших транзакций - это пустая трата времени. Что вы собираетесь делать со всем этим свободным пространством в это время?

Все ваши текущие тесты ( DBCC SHRINKFILE, log_reuse_wait_desc) просто доказывают, что сейчас вы правильно используете файлы виртуальных журналов транзакций. Но когда в файле журнала транзакций происходят события автоматического роста, это реакция на невозможность повторного использования журнала.

Часто это не постоянное состояние (именно так, как вам сейчас кажется при отсутствии симптомов, которые вы сейчас видите). Есть несколько вещей, которые могут вызвать такое поведение, даже в простой модели восстановления.

Лучше всего было бы настроить задание по сбору данных, чтобы регулярно извлекать данные из log_reuse_wait_descвашей базы данных, и регулярно регистрировать это где-нибудь. Тогда у вас будет возможность перепроектировать то, что вызывает отсутствие повторного использования журнала.

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

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

У вас есть автоматическое сжатие на БД? И / или у вас есть плановые планы обслуживания, выполняющие перестройку индекса?

Автоматическое сжатие с последующим обслуживанием индекса даст значительный объем журнала.

Обслуживание индексов само по себе также приводит к значительному объему журнала, если есть проблемы с дизайном БД, такие как кластерные индексы на GUID.

 create table #dblog (Databasename varchar(100),
                     logsize float,
                     logspace%] float,
                     [Status] int)

 insert into #dblog
 EXEC ('DBCC sqlperf(logspace)') 

 select * from #dblog

 alter table #dblog 
 add [lgspace used GB] float;

 update #dblog 
 set [lgspace used GB ] = (logsize*[logspace%]/1024)

 update #dblog 
 set [logsize] =([logsize]/1024)

 alter table #dblog 
 drop column [Status];

 select * from #dblog

 drop table #dblog