При администрировании систем 1С:Предприятие на базе Microsoft SQL Server специалисты часто сталкиваются с парадоксальной ситуацией: файл базы данных (MDF) занимает всего 10 Гб, в то время как файл журнала транзакций (LDF) разрастается до 40–100 Гб и более. Это не только неэффективно использует дисковое пространство, но и может привести к полной остановке работы пользователей из-за ошибки переполнения лога. Разберем подробно, почему так происходит, зачем задавать большие начальные размеры файлов и как правильно управлять этим процессом.
Первоочередная причина неуправляемого роста лога заключается в выборе модели восстановления (Recovery Model). Проанализируем, как они работают в контексте 1С:
Если вы столкнулись с переполнением, первым делом проверьте модель восстановления. Для смены модели и очистки лога можно использовать следующий скрипт:
USE [Имя_Вашей_Базы];
ALTER DATABASE [Имя_Вашей_Базы] SET RECOVERY SIMPLE;
DBCC SHRINKFILE (N'Имя_Файла_Лога' , 1024); -- Сжать до 1 Гб
Часто возникает вопрос: зачем при создании базы вручную указывать размер файла лога в 10–20 Гб? Выясним причину, которая кроется во внутренней архитектуре SQL Server — Виртуальных лог-файлах (Virtual Log Files, VLF).
Когда файл журнала транзакций растет небольшими порциями (например, по 1 Мб или по 10%), SQL Server нарезает его на множество мелких фрагментов — VLF. Если их становится слишком много (тысячи), производительность базы резко падает:
Рекомендация: Установка сразу большого начального размера файла лога (например, 4–8 Гб или 20-30% от размера базы) позволяет серверу создать оптимальное количество крупных VLF, что значительно повышает стабильность системы.
Рассмотрим ситуацию, когда мы создаем файл данных mdf объемом 100 Гб. По умолчанию SQL Server будет заполнять это место нулями, что создаст огромную нагрузку на диски и заставит вас ждать. Однако в Windows существует настройка «Выполнение задач по обслуживанию томов» (Perform volume maintenance tasks).
Проанализируем преимущества ее включения для учетной записи, под которой запущен SQL Server:
mdf создаются и расширяются мгновенно, так как система просто выделяет место на диске без «зануления».Важно: На файлы журналов транзакций (ldf) эта настройка не распространяется — они всегда инициализируются нулями, поэтому их чрезмерно частый рост (мелкими шагами) крайне нежелателен.
Выясним причину на примере типовых операций 1С. SQL Server воспринимает многие действия 1С как одну гигантскую транзакцию. Посмотрим на список таких операций:
В модели Simple после завершения этих операций место внутри лога освободится для новых записей, но сам файл ldf на диске не уменьшится. Это нормально. Не нужно пытаться сжимать его (Shrink) после каждой операции.
Разберем, почему постоянное использование DBCC SHRINKDATABASE или DBCC SHRINKFILE — это плохая практика:
Правило: Свободное место внутри файла базы данных — это ваш «буфер безопасности». Не экономьте на дисковом пространстве, оно стоит дешевле, чем время простоя системы.
Посмотрим на настройки авторасширения. Во многих старых конфигурациях шаг роста стоит «1 МБ» или «10%». Проанализируем риски:
Как сделать правильно: Устанавливайте фиксированный шаг роста. Для баз среднего размера (до 100 Гб) оптимальным будет шаг 256 МБ или 512 МБ для данных и 128-256 МБ для лога.
Подводя итог, сформулируем краткий чек-лист для стабильной работы 1С на SQL Server:
Shrink (сжатие) базы без крайней необходимости. Помните, что за сжатием файла данных всегда должна следовать полная переиндексация.Соблюдение этих правил позволит вам забыть об ошибках «Transaction log is full» и обеспечит максимальную отзывчивость системы 1С для конечных пользователей.