Ужимание журналов SQL Server (.ldf) для баз 1С

Практическая шпаргалка: диагностика → причина → безопасное уменьшение → проверка

Главное правило

Файл .ldf нельзя удалять, переименовывать или переносить вручную при работающем SQL Server. Уменьшение выполняется штатно командой DBCC SHRINKFILE только после проверки причины роста.

 

Краткий порядок действий

  1. Проверить общий размер и процент заполнения журнала.
  2. Узнать логическое имя LOG-файла.
  3. Проверить, что мешает повторному использованию журнала.
  4. Устранить причину: чаще всего дождаться или выполнить backup log (.trn).
  5. Выполнить CHECKPOINT и DBCC SHRINKFILE до разумного размера.
  6. Проверить результат и настройки автоприроста.

Разумная цель

Для небольшой базы 1С обычно начинают с 4096 МБ. До 2048 МБ уменьшают только если журнал действительно не нуждается в большем рабочем объёме. Если SQL Server остановился выше целевого значения — это нормально.

 

Что означают расширения

Файл

Назначение

.mdf / .ndf

Файлы данных базы.

.ldf

Рабочий журнал транзакций SQL Server.

.bak

Полная или дифференциальная резервная копия.

.trn

Резервная копия журнала транзакций.

 

 

1. Диагностика перед ужатием

1.1. Проверить размер и заполнение журналов

Показывает размер каждого журнала и процент занятого места. Найдите нужную базу.

DBCC SQLPERF(LOGSPACE);

Ориентир: если Log Space Used (%) низкий, например 1–10 %, внутри файла много свободного места. Но это ещё не гарантирует, что свободен именно конец файла.

 

1.2. Узнать логическое имя файлов выбранной базы

DBCC SHRINKFILE принимает логическое имя файла, а не имя .ldf в Проводнике и не физический путь.

USE ИмяБазы;
GO

SELECT
    name,
    type_desc,
    size * 8 / 1024 AS SizeMB,
    physical_name
FROM sys.database_files;

Строка type_desc = LOG — это журнал. Например: stolica_ut_log.

 

Быстро:

CHECKPOINT;
GO

DBCC SHRINKFILE (ИМЯ_ИЗ_СТРОКИ_LOG, 4096);
GO

 

1.3. Проверить причину, мешающую очистке журнала

Главный диагностический запрос. Значение log_reuse_wait_desc подсказывает следующее действие.

SELECT
    name,
    recovery_model_desc,
    log_reuse_wait_desc
FROM sys.databases
WHERE name = 'ИмяБазы';

 

 

 

2. Основная процедура ужатия

Перед выполнением

Убедитесь, что есть актуальный резервный backup (.bak), задания backup log (.trn) работают, а на диске нет аварийного дефицита места. Не запускайте SHRINKFILE по расписанию.

 

2.1. Рекомендуемый рабочий шаблон

Замените ИмяБазы, ИмяЛогФайла и целевой размер. Начинайте с 4096 МБ.

USE ИмяБазы;
GO

CHECKPOINT;
GO

DBCC SHRINKFILE (ИмяЛогФайла, 4096);
GO

SELECT
    name,
    type_desc,
    size * 8 / 1024 AS SizeMB
FROM sys.database_files;

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 — виртуальный фрагмент журнала), файл останется больше указанной цели.

 

 

 

3. Что делать по значению log_reuse_wait_desc

3.1. LOG_BACKUP — требуется резервная копия журнала

Типичная ситуация для модели восстановления FULL. Дождитесь штатного задания .trn или выполните backup log вручную.

BACKUP LOG ИмяБазы
TO DISK = 'G:\backup\trn\ИмяБазы_manual.trn'
WITH CHECKSUM, STATS = 10;

Используйте уникальное имя файла. Папка должна существовать, а учётная запись службы SQL Server должна иметь право записи. После успешного backup log повторите CHECKPOINT и DBCC SHRINKFILE.

 

3.2. Проверить историю резервных копий

D = full backup (.bak), I = differential backup, L = log backup (.trn).

SELECT TOP (20)
    database_name,
    backup_start_date,
    backup_finish_date,
    type
FROM msdb.dbo.backupset
WHERE database_name = 'ИмяБазы'
ORDER BY backup_finish_date DESC;

 

3.3. ACTIVE_TRANSACTION — есть незавершённая транзакция

Показывает самую старую открытую транзакцию в выбранной базе.

USE ИмяБазы;
GO

DBCC OPENTRAN;

Не завершайте процесс вслепую. Сначала выясните, какое приложение или пользователь держит транзакцию. После её штатного завершения дождитесь backup log и повторите ужатие.

 

 

 

4. Другие причины и действия

log_reuse_wait_desc

Что делать

NOTHING

Явной блокировки нет. Дождитесь очередного .trn, выполните CHECKPOINT и повторите SHRINKFILE.

CHECKPOINT

Чаще встречается в SIMPLE. Выполните CHECKPOINT, затем повторите проверку.

ACTIVE_BACKUP_OR_RESTORE

Дождитесь завершения резервного копирования или восстановления.

REPLICATION

Проверить репликацию и задержку её агентов. Не ужимать до устранения причины.

AVAILABILITY_REPLICA

Проверить состояние Always On и синхронизацию вторичной реплики.

DATABASE_MIRRORING

Проверить зеркалирование и очередь отправки журнала.

LOG_SCAN

Дождаться завершения внутреннего сканирования и повторить проверку.

Если файл уменьшается только частично

  • Это не ошибка: активный VLF может находиться ближе к концу файла.
  • Дождитесь следующего backup log и повторите SHRINKFILE один-два раза.
  • Попробуйте сначала цель 4096 МБ, а не 2048 МБ.
  • Не выполняйте десятки повторов подряд и не переключайте FULL → SIMPLE только ради уменьшения.

FULL → SIMPLE → FULL

Такое переключение разрывает текущую цепочку log backup. После возврата в FULL выполните новый полный или дифференциальный backup, чтобы начать новую цепочку. Не применяйте этот способ, если используете .trn для восстановления на конкретный момент времени.

 

 

 

5. Проверка результата и настройки роста

5.1. Проверить новый размер и процент заполнения

Выполните оба запроса после ужатия.

USE ИмяБазы;
GO

SELECT
    name,
    type_desc,
    size * 8 / 1024 AS SizeMB
FROM sys.database_files;
GO

DBCC SQLPERF(LOGSPACE);

 

5.2. Проверить автоприрост

growth хранится в страницах по 8 КБ, если is_percent_growth = 0.

USE ИмяБазы;
GO

SELECT
    name,
    size * 8 / 1024 AS SizeMB,
    growth,
    is_percent_growth
FROM sys.database_files;

Пример: growth = 8192 и is_percent_growth = 0 означает рост на 64 МБ. Для рабочих баз предпочтителен фиксированный рост в МБ, а не проценты.

 

Контрольный список после работы

  • База открывается, пользователи 1С работают без ошибок.
  • Штатные задания .bak и .trn продолжают выполняться.
  • Лог оставлен с запасом под обычную нагрузку.
  • На диске появился ожидаемый объём свободного места.
  • SHRINKFILE не добавлен в ежедневное или еженедельное расписание.

Что нельзя делать

  • Удалять, переименовывать или перемещать .ldf вручную при работающем SQL Server.
  • Ужимать .mdf ради обычного освобождения места без отдельной причины и плана.
  • Удалять .trn из середины нужной цепочки восстановления.
  • Считать большой .trn следствием SHRINKFILE: обычно он отражает объём изменений с прошлого backup log.
  • Ужимать журнал до нескольких мегабайт — он снова вырастет, создавая лишнюю нагрузку.

Финальный ориентир

Если после устранения причины журнал стабильно работает, backup log выполняется регулярно, а размер .ldf соответствует реальной пиковой нагрузке, повторное ужатие не требуется.

 

 

 

6. Быстрый сценарий — скопировать целиком

Диагностика и ужатие

Замените значения в трёх местах: ИмяБазы, ИмяЛогФайла, целевой размер.

-- 1. Заполнение журналов
DBCC SQLPERF(LOGSPACE);
GO

-- 2. Причина, мешающая очистке
SELECT
    name,
    recovery_model_desc,
    log_reuse_wait_desc
FROM sys.databases
WHERE name = 'ИмяБазы';
GO

-- 3. Логическое имя и текущий размер
USE ИмяБазы;
GO

SELECT
    name,
    type_desc,
    size * 8 / 1024 AS SizeMB,
    physical_name
FROM sys.database_files;
GO

-- 4. После штатного backup log (.trn)
CHECKPOINT;
GO

DBCC SHRINKFILE (ИмяЛогФайла, 4096);
GO

-- 5. Проверка результата
SELECT
    name,
    type_desc,
    size * 8 / 1024 AS SizeMB
FROM sys.database_files;
GO

 

Если результат LOG_BACKUP

Сначала дождитесь штатного .trn или выполните BACKUP LOG. Если ACTIVE_TRANSACTION — выполните DBCC OPENTRAN и найдите причину. Если NOTHING — повторите после очередного .trn и CHECKPOINT.