Прежде чем сразу пометить как дубликат , я прочитал Майка Уолша « Почему журнал транзакций продолжает расти или не хватает места? , но я не думаю, что это дало ответ на мою ситуацию. Я просмотрел дюжину или около того похожих вопросов, но соответствующие, в основном, просто сказали «дубликат» и указали на вопрос Майка.
Подробно: у меня есть набор баз данных ~ 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;
Это показало, что журнал увеличивался в определенные вечера, когда клиент не использовал базу данных. Это привело к разговору с парнем, применяющим патчи и ответом на загадку.
Еще раз спасибо за людей, которые помогли мне получить ответ.