У нас есть много SQL-серверов в среде разработки, где мы никогда не делаем резервные копии баз данных (для кода достаточно TFS).
Все базы данных (SharePoint) настроены на простую модель восстановления, но файлы журналов, особенно для базы данных конфигурации SharePoint, становятся довольно большими и заполняют наш диск данных на сервере SQL.
Поскольку эти файлы журналов никогда ни для чего не используются, я хотел бы получить совет, как лучше всего минимизировать размер этих файлов журналов - или даже отключить их, если это возможно.
Я не совсем уверен, почему файлы журнала становятся такими большими даже при простом ведении журнала (проверено на наличие длительных транзакций (DBCC OPENTRAN), но не найдено).
Я предполагаю, что причина того, что файлы журнала не усекаются, заключается в том, что мы не делаем никаких резервных копий, и, следовательно, контрольные точки не достигаются.
Автоматическое увеличение для файлов журналов установлено на автоматический рост на 10% с ограничением до 2 ГБ, поэтому я предполагаю, что именно поэтому Checkpoint (70%) здесь также не достигается.
Какова была бы наилучшая стратегия для сохранения небольшого размера файлов журнала (в лучшем случае 0) без ущерба для производительности (например, фрагментация VLF)?
Выполняете ли вы какие-либо работы по техническому обслуживанию, которые могут быть связаны с переиндексацией или другой тяжелой работой? Даже при простом восстановлении журнал должен быть по крайней мере достаточно большим, чтобы содержать самую большую транзакцию, выпущенную для базы данных. Попробуйте запустить DBCC SQLPERF (LOGSPACE) и проверьте, какая часть файла журнала фактически используется. Если он очень низкий, то простое восстановление, вероятно, работает должным образом, а файл журнала, вероятно, только увеличивается, потому что он должен быть настолько большим, чтобы поддерживать транзакцию, превышающую среднюю.
Попробуйте выполнить этот запрос. Это было собрано MS (у меня нет статьи под рукой) и изначально предназначалось для Sharepoint, работающего на SBS2008, но должно работать для любого экземпляра Sharepoint. Убедитесь, что имена и пути БД соответствуют вашему экземпляру.
declare @ConfigDB varchar(255);
declare @ConfigDBLog varchar(255);
declare @ConfigDBCmd varchar(255);
select @ConfigDB = name from sys.databases where name like 'SharePoint_Config_%';
set @ConfigDBCmd = 'BACKUP database [' + RTRIM(@ConfigDB) + '] to disk=''C:\windows\temp\before.bkf''';
execute(@ConfigDBCmd);
set @ConfigDBCmd = 'use [' + RTRIM(@COnfigDB) + ']';
execute(@ConfigDBCmd);
set @ConfigDBCmd = 'BACKUP LOG [' + RTRIM(@ConfigDB) + '] WITH TRUNCATE_ONLY';
execute(@ConfigDBCmd);
set @ConfigDBCmd = 'use [' + RTRIM(@COnfigDB) + ']';
execute(@ConfigDBCmd);
select @ConfigDBLog = name from sys.database_files where name like 'SharePoint_Config%_log';
set @ConfigDBCmd = 'use [' + RTRIM(@ConfigDB) + '] DBCC SHRINKFILE([' + RTRIM(@ConfigDB) + '_log],1)';
execute(@ConfigDBCmd);
set @ConfigDBCmd = 'BACKUP database [' + RTRIM(@ConfigDB) + '] to disk=''C:\windows\temp\after.bkf''';
execute(@ConfigDBCmd);
go
Начните с выполнения следующего запроса, чтобы узнать причину, по которой журнал не усечен:
select log_reuse_wait from sys.databases where name = '<database name>'
Описание причин повторного использования журнала можно найти здесь: http://msdn.microsoft.com/en-us/library/ms178534.aspx
Двойная проверка у вас есть ПРОСТАЯ модель восстановления в ваших базах данных разработки.
select name, recovery_model_desc from sys.databases
Вам нужен файл журнала: его нельзя отключить или обнулить