Как сделать Shrink (сжатие) базы MS SQL для 1С после удаления логов
Механизм транзакций SQL и разрастание файлов
Ситуация, когда файл журнала транзакций (.LDF) Microsoft SQL Server превышает размер файла самих данных (.MDF) базы 1С, является классической проблемой непродуманного плана обслуживания. Разрастание происходит при выполнении массовых операций в 1С: групповое перепроведение документов, удаление помеченных объектов, очистка журнала регистрации (если он хранится в БД), или при сбоях в работе AlwaysOn. Бизнес-риски: диск (LUN) переполняется (Error 9002 The transaction log is full), SQL Server останавливает запись, пользователи 1С получают сообщение об ошибке СУБД и база 'встает'.
Состояния журнала транзакций (Recovery Models)
| Модель восстановления (Recovery Model) | Поведение файла лога (LDF) | Когда применять |
|---|---|---|
| Full (Полная) - По умолчанию | Лог растет бесконечно, пока не будет сделан бэкап журнала (Log Backup). | Промышленные базы 1С, где важна потеря данных = 0. |
| Simple (Простая) | Транзакции затираются после их завершения. Лог не растет. | Тестовые базы 1С, базы РИБ, разработка. |
Алгоритм безопасного сжатия логов (Shrink)
Сценарий 1: Сжатие через переключение модели в Simple (Быстрый метод)
Если вам не нужен point-in-time recovery (восстановление на конкретную секунду) за прошедший период, усекаем лог грубо.
USE [master];
-- 1. Переводим базу 1С в простую модель восстановления (разрывает цепочку логов)
ALTER DATABASE [baza_1c_erp] SET RECOVERY SIMPLE;
GO
-- 2. Выполняем сжатие файла лога до минимального размера (например, 100 МБ)
USE [baza_1c_erp];
DBCC SHRINKFILE (N'baza_1c_erp_log', 100);
GO
-- 3. Возвращаем полную модель для работы бэкапов
ALTER DATABASE [baza_1c_erp] SET RECOVERY FULL;
GOСценарий 2: Правильный метод через Log Backup (Без разрыва цепочки)
Если база критична, необходимо сделать бэкап транзакций, чтобы SQL сам пометил пространство VLF (Virtual Log Files) как свободное, а затем сжать файл.
-- 1. Делаем бэкап лога транзакций в файл или NUL
BACKUP LOG [baza_1c_erp] TO DISK = N'D:\Backups\baza_1c_erp_log_shrink.trn'
-- (или TO DISK = N'NUL' для фиктивного бэкапа)
GO
-- 2. Теперь выполняем Shrink пустого лога
DBCC SHRINKFILE (N'baza_1c_erp_log', 1024); -- Сжать до 1 ГБ
GOТиповые ошибки администраторов (DBA)
- Shrink базы целиком (MDF): Использование
DBCC SHRINKDATABASEубивает производительность 1С. Страницы данных тасуются хаотично, уничтожая всю статистику и индексы. После такого Shrink'а 1С будет тормозить неделями, пока не выполнится полная реиндексация (Index Rebuild). - Отсутствие Maintenance Plan: Если база в модели FULL, а планы обслуживания делают только FULL бэкапы (раз в день) без Transaction Log Backups (каждые 15-30 минут), лог-файл гарантированно сожрет весь диск.
Частые вопросы (FAQ)
Почему DBCC SHRINKFILE не уменьшает размер LDF?
Файл лога содержит активные транзакции (Active VLF). Запустите команду 'DBCC OPENTRAN'. Возможно, какая-то сессия 1С зависла с открытой транзакцией (например, долгое проведение). Пока транзакция не завершится (Commit/Rollback), сжать лог невозможно.
Как узнать логическое имя файла лога для команды SHRINKFILE?
Выполните запрос: USE [ВашаБаза]; SELECT name, physical_name FROM sys.database_files WHERE type = 1; Значение в колонке 'name' — это то, что нужно подставить в команду DBCC SHRINKFILE.
Нужно ли делать Shrink логов регулярно?
Категорически НЕТ. Если лог вырастает до 50 ГБ каждую неделю, значит этот объем необходим базе для текущих операций. Регулярный Shrink и последующий Auto-Grow только нагружают дисковую подсистему и фрагментируют файловую систему NTFS.
Как бороться с фрагментацией после Shrink логов?
Shrink файла LDF не влияет на фрагментацию индексов 1С (в отличие от MDF). Однако частый рост лога создает внутреннюю фрагментацию VLF. Установите правильный размер лога изначально (например, 20-30% от размера MDF) и задайте шаг автоприроста (Auto-Growth) в мегабайтах (например, по 500 МБ), а не в процентах.