Администрирование · 9 мин
Как обрезать базу 1С на SQL Server: практическая инструкция
Как обрезать базу 1С на SQL Server: свёртка итогов, удаление старых документов, shrink, бэкап и проверка результата. Практическая инструкция для администраторов.
База 1С на SQL Server со временем разрастается: накапливаются документы за прошлые годы, движения регистров, версии объектов и журналы регистрации. Разросшаяся база замедляет проведение документов, удлиняет резервное копирование и усложняет обновления. «Обрезка» базы — это комплекс мер: свёртка остатков на дату, удаление устаревших данных и сжатие файлов БД на уровне SQL Server.
Важно понимать: обрезка — необратимая операция. Удалённые документы и движения восстановить можно только из резервной копии, поэтому любые действия начинаются с полного бэкапа и тестового прогона на копии базы. Ниже разобран рабочий порядок действий, который применим для типовых конфигураций (БП, УТ, ERP, ЗУП) на платформе 8.3 с MS SQL Server.
Подготовка: бэкап, копия и оценка объёма
Первый шаг — полная резервная копия средствами SQL Server (полная модель восстановления позволит откатиться на любой момент времени). Бэкап через dt-файл из конфигуратора для больших баз неудобен и медленен, поэтому используйте BACKUP DATABASE в SQL Server Management Studio.
Далее оцените, что именно занимает место. В типовых базах основной объём обычно дают таблицы движений регистров накопления и сведений, журнал регистрации (_EventLog) и таблица версий объектов. Определить самые тяжёлые таблицы поможет отчёт по размеру таблиц в SSMS (правый клик по базе → Reports → Disk Usage by Table).
Проверьте размер _EventLog и настройки версионирования
Проверьте дату запрета и актуальность итогов
Нужна свёртка на дату и последующий shrink
Определите дату обрезки. Обычно это начало текущего или прошлого года, но учтите требования к хранению первичных документов: бухгалтерские и налоговые документы должны храниться установленные сроки, поэтому физическое удаление данных, подпадающих под обязательное хранение, согласуйте с бухгалтерией и руководством. Часто старые периоды выносят в отдельную архивную базу, а не удаляют безвозвратно.
Свёртка остатков на дату
Основной инструмент обрезки — типовая обработка «Свёртка информационной базы» (входит в состав конфигурации или доступна на ИТС). Она формирует документы ввода остатков на выбранную дату и помечает на удаление все документы раньше этой даты.
- 1Сделайте полный бэкап SQL-базы и поднимите копию для теста
- 2Установите дату запрета редактирования на дату свёртки
- 3Запустите обработку «Свёртка информационной базы» в монопольном режиме
- 4Выберите дату свёртки и регистры, по которым формируются остатки
- 5Дождитесь формирования документов ввода остатков и проверьте их
- 6Выполните удаление помеченных объектов
- 7Сверьте остатки по отчётам до и после свёртки на копии
- 8Повторите процедуру на рабочей базе в нерабочее время
Свёртка выполняется в монопольном режиме и на большой базе может занять часы. На это время пользователи должны быть отключены, регламентные задания — остановлены. После свёртки обязательно сформируйте контрольные отчёты (ОСВ, остатки склада, взаиморасчёты) на дату свёртки и сравните с данными до обрезки — расхождений быть не должно.
Удаление устаревших данных без свёртки
Не всегда нужна полная свёртка. Часто значительную часть объёма дают служебные данные, которые можно сократить отдельно и без риска для учёта.
Журнал регистрации
Журнал регистрации в клиент-серверном варианте хранится в SQL-таблице и может занимать гигабайты. Сократите его через конфигуратор: Администрирование → Настройка журнала регистрации → Сократить, указав дату, до которой события удаляются. Предварительно выгрузите журнал в файл, если история действий пользователей может понадобиться для разборов.
Версии объектов и история данных
Если включено версионирование объектов или история данных, старые версии накапливаются в базе. Проверьте настройки хранения версий (срок хранения, список версионируемых объектов) и выполните очистку устаревших версий штатными средствами конфигурации.
Помеченные объекты и неактуальные данные обмена
Удаление помеченных объектов (Администрирование → Удаление помеченных объектов) часто освобождает заметный объём, особенно если пометки копились годами. Дополнительно проверьте регистрацию изменений для узлов обмена: после успешных обменов зарегистрированные изменения должны удаляться, а зависшие регистрации по неиспользуемым узлам можно очистить.
Сжатие файлов базы на уровне SQL Server
После удаления данных внутри БД файлы .mdf и .ldf сохраняют прежний размер — освобождённое пространство остаётся внутри файла как пустое. Чтобы вернуть его операционной системе, используется операция shrink.
Порядок безопасного сжатия: сначала перестройте индексы (rebuild), затем выполните DBCC SHRINKFILE с указанием целевого размера. Shrink сильно фрагментирует индексы, поэтому после него рекомендуется повторная реиндексация либо обновление статистики. На больших базах операция длительная и нагружает дисковую подсистему — планируйте её на нерабочее время.
DBCC SHRINKFILE (N'MyBase1C', 51200); -- целевой размер в МБ
ALTER INDEX ALL ON _AccumRg12345 REBUILD; -- пример реиндексации после shrinkФайл журнала транзакций (.ldf) сжимается отдельно: при полной модели восстановления сначала сделайте бэкап журнала, затем shrink лог-файла. Если база не требует восстановления на произвольный момент времени, рассмотрите перевод в простую модель восстановления — это ограничит рост ldf в будущем.
Частые ошибки при обрезке базы
Главная ошибка — работа без тестового прогона. Свёртка на копии показывает реальную длительность операции, выявляет проблемные данные и позволяет проверить остатки до того, как рисковать рабочей базой.
Отдельно предостережение: никогда не удаляйте данные из таблиц 1С прямыми SQL-запросами DELETE. Структура таблиц 1С включает служебные итоги, регистрацию изменений и связи, которые платформа ведёт сама; прямое вмешательство почти гарантированно приводит к ошибкам ссылочной целостности и некорректным итогам. Все удаления — только штатными средствами платформы.
Проверка результата и профилактика роста
После обрезки проверьте три вещи: сходимость остатков по контрольным отчётам, размер файлов базы на диске и скорость ключевых операций (проведение документов, закрытие месяца, формирование отчётов). Также выполните тестирование и исправление информационной базы в конфигураторе для проверки логической целостности.
Как проверить результат
Полностью совпадают с отчётами до обрезки
Есть расхождения — искать причину до открытия работы пользователям
Уменьшились после shrink, свободное место внутри файла невелико
Размер прежний — shrink не выполнен или не было удаления данных
После rebuild фрагментация низкая
Высокая фрагментация после shrink — нужна повторная реиндексация
Чтобы база не разрасталась снова, настройте профилактику: регулярное сокращение журнала регистрации, ограничение сроков хранения версий объектов, регламентную реиндексацию и обновление статистики, контроль регистрации изменений в обменах. Периодическую свёртку (например, раз в год-два) планируйте заранее, а не когда место на диске уже заканчивается.
Что важно запомнить
Обрезка базы 1С на SQL — это бэкап, тестовая свёртка типовой обработкой, очистка журнала регистрации и версий, затем shrink файлов и реиндексация. Прямые удаления в SQL запрещены, а контроль остатков после свёртки обязателен.
FAQ
Можно ли обрезать базу 1С без свёртки документов?
Да, если цель — освободить место без изменения учётных данных. Сократите журнал регистрации, очистите версии объектов, удалите помеченные объекты и зависшую регистрацию изменений, затем выполните shrink. Это безопасно для учёта, но объём движений по регистрам не уменьшится.
Что делать со старыми периодами, которые нельзя удалять по срокам хранения?
Выгрузите старые периоды в отдельную архивную базу (копия рабочей базы до свёртки). Архивная база открывается только для просмотра, а рабочая сворачивается на нужную дату. Так соблюдаются требования хранения и не раздувается рабочая база.
Сколько времени занимает свёртка большой базы?
Зависит от объёма данных и мощности сервера: на базах в десятки гигабайт операция может идти несколько часов. Точное время покажет только тестовый прогон на копии — поэтому его нельзя пропускать при планировании окна обслуживания.
Опасен ли DBCC SHRINKFILE для базы 1С?
Сама операция безопасна для данных, но сильно фрагментирует индексы и нагружает диски. Правильная последовательность: удаление данных → shrink → реиндексация. Не делайте shrink регулярно «для профилактики» — только после реального массового удаления данных.
Можно ли ускорить базу, просто удалив журнал регистрации?
Удаление журнала освобождает место, но на скорость проведения документов влияет слабо. На производительность сильнее влияют объём таблиц движений и итогов, фрагментация индексов и актуальность статистики — поэтому комплексная обрезка с реиндексацией эффективнее.
Нужен ли монопольный режим для всех операций обрезки?
Для свёртки и удаления помеченных объектов — да, обязательно. Сокращение журнала регистрации и shrink на уровне SQL технически возможны без монопольного режима, но выполнять их лучше в нерабочее время из-за нагрузки и блокировок.