Чистим и сжимаем информационную базу 1С на MS SQL Server

Файл базы раздулся до сотен гигабайт, место на диске тает, а отчёты формируются всё медленнее. В клиент-серверном варианте 1С на MS SQL Server это почти всегда не «данные учёта», а накопившийся служебный балласт: журнал регистрации, таблицы изменений планов обмена, разросшийся журнал транзакций и фрагментированные индексы.

Чтобы очистить SQL-базу 1С и уменьшить её размер, работаем в два слоя: сначала средствами самой 1С убираем лишние данные внутри базы, потом средствами SQL Server сжимаем освободившиеся файлы и приводим в порядок индексы. Порядок важен — сжимать файлы имеет смысл только после того, как внутри базы реально стало меньше данных.

Сначала смотрим, что именно занимает место

Пока не видно, какие таблицы распухли, чистить вслепую бессмысленно. Начните с инвентаризации.

Размер самих файлов базы данных смотрят в SQL Server Management Studio: правой кнопкой по базе → Reports → Standard Reports → Disk Usage by Top Tables. Отчёт покажет top-таблицы по объёму — именно по ним и будем работать.

Общий расклад по файлам даёт запрос:

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

Здесь важны два типа строк:

• 📄 ROWS — файл данных (.mdf / .ndf), собственно таблицы.
• 📘 LOG — журнал транзакций (.ldf). Если он сопоставим с файлом данных или больше — проблема не в учёте, а в модели восстановления и бэкапах (разберём ниже).

Детальную картину по таблицам даёт системная процедура. Для одной подозрительной таблицы:

EXEC sp_spaceused N'_ReferenceNNNN';  -- имя таблицы из отчёта по top-таблицам

Она покажет число строк и сколько занято под данные и под индексы отдельно. Бывает, что сама таблица небольшая, а раздут её индекс — тогда проблема решается не чисткой, а переиндексацией.

Какие таблицы 1С чаще всего раздуваются:

• 🗂 таблицы изменений планов обмена — имена вида _<ИмяПланаОбмена>Changes;
• 🔎 данные полнотекстового поиска;
• 🕑 история версий объектов (если включено версионирование);
• 📎 присоединённые файлы, если они хранятся в базе, а не в томах на диске.

Отдельно оцените сам журнал регистрации — он к размеру SQL-базы отношения не имеет, но его часто путают с базой, поэтому с него и начнём.

Чистим журнал регистрации — он лежит не в SQL

Типичное заблуждение: «почистим журнал регистрации и база похудеет». В клиент-серверном варианте журнал регистрации хранится не в базе SQL Server, а в отдельных файлах на сервере — в каталоге информационной базы кластера (1Cv8.lgd, формат SQLite). На размер .mdf он не влияет вообще. Но разрастается до десятков гигабайт и тормозит открытие журнала, поэтому чистить его нужно отдельно.

Самый безопасный путь — ограничить срок хранения, чтобы журнал чистился сам:

1. Запустите базу в режиме Конфигуратор.
2. Меню Администрирование → Настройка журнала регистрации.
3. Задайте период хранения (например, записи старше трёх месяцев удалять) и, при необходимости, сократите журнал на указанную дату.

Тот же результат доступен из 1С:Предприятие для пользователя с правами администратора: раздел Администрирование → Обслуживание → Журнал регистрации → настройки хранения (точное название пункта зависит от конфигурации).

Убираем накопленные изменения планов обмена

Если база участвует в обменах (РИБ, синхронизация с другой конфигурацией, выгрузка в другую систему), для каждого узла программа ведёт таблицу зарегистрированных, но ещё не выгруженных изменений. Когда обмен давно не выполняется или узел заброшен, эти таблицы растут безгранично — это и есть «таблица изменений зарегистрированных данных».

Сначала посмотрите, по каким узлам висят изменения: Администрирование → Синхронизация данных (или НСИ и администрирование → Синхронизация данных в зависимости от конфигурации) → откройте список узлов и состав выгрузки.

Варианты очистки по убыванию безопасности:

• ✅ Довыгрузить обмен. Если узел рабочий — просто выполните синхронизацию: после успешной выгрузки регистрация изменений снимается штатно.
• ⚠️ Снять регистрацию по заброшенному узлу. Если узел больше не используется, удалите по нему регистрацию изменений, а затем сам узел. Делается это через обработку регистрации изменений плана обмена.

Как отличить заброшенный узел от рабочего: откройте карточку узла и посмотрите дату последней успешной выгрузки и число непереданных изменений. Узел, по которому висят сотни тысяч изменений и обмен не шёл месяцами, — первый кандидат на отключение. Узел самой базы (помечен как «этот узел») не трогайте: по нему регистрация не ведётся.

Если удалённых узлов много, разбирать их вручную долго — такую чистку обычно оформляют как разовую обработку, запускаемую администратором. После снятия регистрации место внутри таблиц освободится, но файл базы сам не уменьшится — это сделаем на шаге сжатия.

Сокращаем базу средствами 1С

До того как трогать SQL Server, выжмите лишнее средствами платформы — так сжатие файлов потом даст реальный эффект.

Удаление помеченных объектов. Пометка на удаление не убирает данные физически. Выполните Администрирование → Обслуживание → Удаление помеченных объектов. Программа проверит ссылки и удалит то, что ни с чем не связано.

История версий объектов. Если включено версионирование, таблица версий легко становится самой большой в базе. Проверьте настройки версионирования и срок хранения версий, сократите глубину хранения до разумной.

Полнотекстовый поиск. Данные индекса полнотекстового поиска тоже занимают место. Если поиск не используется — его можно отключить; если используется — индекс периодически обновляют, а не накапливают.

Присоединённые файлы. В типовых конфигурациях сканы договоров, картинки и вложения по умолчанию могут храниться прямо в базе. Именно они часто и дают основной рост .mdf. Решение — перенести хранилище файлов в тома на диске: в разделе Администрирование → Настройки работы с файлами включите хранение в томах и перенесите существующие файлы. База после этого хранит только ссылки, а не сами файлы.

Тестирование и исправление с реструктуризацией. Самый весомый инструмент — в Конфигураторе: Администрирование → Тестирование и исправление. Для задачи «уменьшить размер» включите флаг сжатия таблиц информационной базы (реструктуризация). Платформа пересоберёт таблицы и вернёт пустоты, оставшиеся после удалений.

Сжимаем файлы базы и журнал транзакций на MS SQL

После того как внутри базы освободилось место, файлы .mdf и .ldf всё ещё занимают прежний объём — SQL Server не отдаёт его диску автоматически. Теперь можно сжать.

Разберитесь сначала с журналом транзакций .ldf. Он разрастается, когда база в модели восстановления FULL, а бэкапы журнала не делаются. Правильное лечение — не бесконечное сжатие, а регулярный бэкап журнала:

BACKUP LOG [ИмяБазы] TO DISK = 'D:\Backup\log.trn';

После бэкапа журнал можно однократно сжать до нормального размера:

DBCC SHRINKFILE (N'ИмяБазы_log', 2048);  -- целевой размер в МБ

Файл данных сжимают так же точечно:

DBCC SHRINKFILE (N'ИмяБазы', 50000);  -- до 50 ГБ

Если журнал транзакций вам в принципе не нужен для поминутного восстановления — переведите базу в SIMPLE: журнал перестанет копить незабэкапленные транзакции. Но тогда восстановить базу на произвольный момент времени будет нельзя, только из последнего полного бэкапа.

Переиндексация и обновление статистики после очистки

После удалений, реструктуризации и особенно после SHRINKFILE индексы фрагментированы, а статистика устарела — запросы 1С начинают «тупить». Это обязательный завершающий шаг.

Перестройка или реорганизация индексов:

-- тяжёлая перестройка (нужно окно без пользователей)
ALTER INDEX ALL ON [имя_таблицы] REBUILD;

-- лёгкая реорганизация (можно при небольшой нагрузке)
ALTER INDEX ALL ON [имя_таблицы] REORGANIZE;

Обновление статистики с полным сканированием:

EXEC sp_updatestats;
-- или точечно:
UPDATE STATISTICS [имя_таблицы] WITH FULLSCAN;

Чтобы не перестраивать всё подряд, сначала посмотрите реальную фрагментацию индексов:

SELECT OBJECT_NAME(ips.object_id) AS table_name,
       ips.index_id,
       ips.avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats
     (DB_ID(), NULL, NULL, NULL, 'LIMITED') AS ips
WHERE ips.avg_fragmentation_in_percent > 10
ORDER BY ips.avg_fragmentation_in_percent DESC;

Правило выбора между перестройкой и реорганизацией по колонке avg_fragmentation_in_percent:

• 🟢 фрагментация до 10% — ничего не делаем;
• 🟡 10–30% — REORGANIZE (онлайн, без монополии);
• 🔴 свыше 30% — REBUILD (эффективнее, но тяжелее).

Отдельно по 1С-специфике: перестройка индексов по большим регистрам накопления и таблицам движений даёт самый заметный выигрыш в скорости проведения документов и построения отчётов — на них и стоит сосредоточиться в первую очередь.

Настраиваем регламентное обслуживание, чтобы не чистить вручную

Разовая чистка решает проблему один раз. Чтобы база не распухала снова, обслуживание нужно поставить на расписание. Удобнее разделить: тяжёлое — средствами SQL Server, прикладное — средствами 1С.

На стороне SQL Server (Maintenance Plans или задания SQL Server Agent) по ночам выполняют:

• 💾 резервное копирование базы и журнала транзакций;
• 🧹 реорганизацию/перестройку индексов по фрагментации;
• 📊 обновление статистики;
• 🔍 проверку целостности DBCC CHECKDB.

На стороне 1С в фоне держат прикладные задачи: обновление индекса полнотекстового поиска , удаление устаревших версий объектов, выполнение обменов, чтобы таблицы изменений не копились.

Так разовая чистка превращается в поддерживаемое состояние: место не утекает, индексы не фрагментируются, а полная реструктуризация с остановкой пользователей нужна лишь изредка.

Частые вопросы