Практическая шпаргалка: диагностика → причина → безопасное уменьшение → проверка
Главное правило Файл .ldf нельзя удалять, переименовывать или переносить вручную при работающем SQL Server. Уменьшение выполняется штатно командой DBCC SHRINKFILE только после проверки причины роста. |
Разумная цель Для небольшой базы 1С обычно начинают с 4096 МБ. До 2048 МБ уменьшают только если журнал действительно не нуждается в большем рабочем объёме. Если SQL Server остановился выше целевого значения — это нормально. |
Файл | Назначение |
.mdf / .ndf | Файлы данных базы. |
.ldf | Рабочий журнал транзакций SQL Server. |
.bak | Полная или дифференциальная резервная копия. |
.trn | Резервная копия журнала транзакций. |
Показывает размер каждого журнала и процент занятого места. Найдите нужную базу.
DBCC SQLPERF(LOGSPACE); |
Ориентир: если Log Space Used (%) низкий, например 1–10 %, внутри файла много свободного места. Но это ещё не гарантирует, что свободен именно конец файла.
DBCC SHRINKFILE принимает логическое имя файла, а не имя .ldf в Проводнике и не физический путь.
USE ИмяБазы; |
Строка type_desc = LOG — это журнал. Например: stolica_ut_log.
Быстро:
CHECKPOINT;
GO
DBCC SHRINKFILE (ИМЯ_ИЗ_СТРОКИ_LOG, 4096);
GO
Главный диагностический запрос. Значение log_reuse_wait_desc подсказывает следующее действие.
SELECT |
Перед выполнением Убедитесь, что есть актуальный резервный backup (.bak), задания backup log (.trn) работают, а на диске нет аварийного дефицита места. Не запускайте SHRINKFILE по расписанию. |
Замените ИмяБазы, ИмяЛогФайла и целевой размер. Начинайте с 4096 МБ.
USE ИмяБазы; |
4096 = 4 ГБ; 2048 = 2 ГБ; 8192 = 8 ГБ. Цель — разумный рабочий размер, а не минимально возможный.
USE ИмяБазы — переключает текущий контекст на нужную базу.
GO — разделяет команды на пакеты в SSMS; это не команда самого SQL Server.
CHECKPOINT — записывает изменённые страницы из памяти на диск. В модели FULL сам по себе не заменяет backup log.
DBCC SHRINKFILE — пытается удалить свободные виртуальные фрагменты журнала (VLF) с конца файла.
SELECT ... sys.database_files — показывает фактический размер файлов после операции.
Почему SQL может не достичь указанного размера SHRINKFILE может отрезать только свободный конец .ldf. Если в конце находится активный VLF (virtual log file — виртуальный фрагмент журнала), файл останется больше указанной цели. |
Типичная ситуация для модели восстановления FULL. Дождитесь штатного задания .trn или выполните backup log вручную.
BACKUP LOG ИмяБазы |
Используйте уникальное имя файла. Папка должна существовать, а учётная запись службы SQL Server должна иметь право записи. После успешного backup log повторите CHECKPOINT и DBCC SHRINKFILE.
D = full backup (.bak), I = differential backup, L = log backup (.trn).
SELECT TOP (20) |
Показывает самую старую открытую транзакцию в выбранной базе.
USE ИмяБазы; |
Не завершайте процесс вслепую. Сначала выясните, какое приложение или пользователь держит транзакцию. После её штатного завершения дождитесь backup log и повторите ужатие.
log_reuse_wait_desc | Что делать |
NOTHING | Явной блокировки нет. Дождитесь очередного .trn, выполните CHECKPOINT и повторите SHRINKFILE. |
CHECKPOINT | Чаще встречается в SIMPLE. Выполните CHECKPOINT, затем повторите проверку. |
ACTIVE_BACKUP_OR_RESTORE | Дождитесь завершения резервного копирования или восстановления. |
REPLICATION | Проверить репликацию и задержку её агентов. Не ужимать до устранения причины. |
AVAILABILITY_REPLICA | Проверить состояние Always On и синхронизацию вторичной реплики. |
DATABASE_MIRRORING | Проверить зеркалирование и очередь отправки журнала. |
LOG_SCAN | Дождаться завершения внутреннего сканирования и повторить проверку. |
FULL → SIMPLE → FULL Такое переключение разрывает текущую цепочку log backup. После возврата в FULL выполните новый полный или дифференциальный backup, чтобы начать новую цепочку. Не применяйте этот способ, если используете .trn для восстановления на конкретный момент времени. |
Выполните оба запроса после ужатия.
USE ИмяБазы; |
growth хранится в страницах по 8 КБ, если is_percent_growth = 0.
USE ИмяБазы; |
Пример: growth = 8192 и is_percent_growth = 0 означает рост на 64 МБ. Для рабочих баз предпочтителен фиксированный рост в МБ, а не проценты.
Финальный ориентир Если после устранения причины журнал стабильно работает, backup log выполняется регулярно, а размер .ldf соответствует реальной пиковой нагрузке, повторное ужатие не требуется. |
Замените значения в трёх местах: ИмяБазы, ИмяЛогФайла, целевой размер.
-- 1. Заполнение журналов |
Если результат LOG_BACKUP Сначала дождитесь штатного .trn или выполните BACKUP LOG. Если ACTIVE_TRANSACTION — выполните DBCC OPENTRAN и найдите причину. Если NOTHING — повторите после очередного .trn и CHECKPOINT. |