Уменьшаем размер базы ЗУП: что удалить, а что — нельзя

База ЗУП растёт в основном не из-за расчётных документов, а из-за служебных данных: журнала регистрации, таблиц регистрации изменений для обмена и кэша. Поэтому обрезать базу данных 1С ЗУП правильнее начинать не с удаления начислений за старые периоды, а с чистки этого «балласта» и последующего физического сжатия файла — часто этого хватает, чтобы база похудела в разы.

Удаление собственно данных ЗУП — кадровых документов и расчётов за прошлые периоды — вещь куда более опасная. В отличие от «Бухгалтерии», здесь нет штатной свёртки в один клик: вычистив старые документы на месте, вы ломаете расчёт среднего заработка, стаж и остатки отпусков. Ниже — что уменьшает базу безопасно, как её сжать физически и как по-настоящему «обрезать» период, не потеряв учёт.

С чего начать: бэкап и диагностика размера

Прежде чем что-то удалять, поймите, чем именно занят объём. Это сэкономит силы: иногда 10 ГБ базы — это 8 ГБ журнала регистрации, который чистится за пять минут.

Порядок подготовки:

1. 📦 Сделайте резервную копию. Для файловой базы — закройте все сеансы и скопируйте файл 1Cv8.1CD. Для серверной — выгрузите .dt через Конфигуратор (Администрирование → Выгрузить информационную базу) или сделайте бэкап средствами СУБД.
2. 🔎 Посмотрите, что весит. У файловой базы объём виден по размеру 1Cv8.1CD и отдельно — журнала (1Cv8.lgd или папка 1Cv8Log). У серверной — размеры файлов данных и лога транзакций в SSMS.
3. 🗂 Решите задачу по-крупному: нужно только ускорить работу (тогда достаточно чистки и сжатия) или реально отрезать исторические периоды (тогда готовьтесь к переносу в новую базу).

Без актуального бэкапа дальше не двигайтесь. Восстановить удалённые расчёты ЗУП «обратно» нельзя.

Что в базе можно почистить без потери учёта

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

Журнал регистрации. Хранит каждое действие пользователей и в активных базах разрастается до гигабайтов. Очистить или сократить его можно в Конфигураторе: Администрирование → Настройка журнала регистрации. Задайте меньший срок хранения записей (например, последние 1–3 месяца) — старое будет удалено. Для файловой базы журнал физически лежит в 1Cv8.lgd, и после сокращения его размер падает сразу.

Кэш клиента и сервера. Не часть базы, но тоже «пухнет». Временные файлы платформы лежат в профиле пользователя; при закрытой 1С их можно удалить, 1С пересоздаст кэш. Серверный кэш — в каталоге рабочих процессов на сервере 1С.

Индекс полнотекстового поиска. Если индекс давно не перестраивался или повреждён, его пересоздание иногда уменьшает размер и ускоряет поиск. Управление индексом находится в режиме предприятия в блоке обслуживания раздела Администрирование; если точный пункт в вашей версии называется иначе, найдите его поиском по форме настроек.

Таблицы регистрации изменений для обмена

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

Что с ними делать:

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

Физическое сжатие базы: файловая и SQL

Важный момент, на котором многие спотыкаются: удаление данных само по себе не уменьшает файл базы. Освободившееся место остаётся «внутри» и переиспользуется под новые записи. Чтобы файл реально похудел, нужно сжатие.

Файловая база (.1CD)

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

Требования:

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

Серверная база (SQL)

Здесь сжатие — на стороне СУБД. Для MS SQL Server это DBCC SHRINKDATABASE или DBCC SHRINKFILE по конкретному файлу данных. Отдельно сжимается журнал транзакций (.ldf) — часто именно он занимает большую часть объёма.

-- Сжать файл данных базы (имя файла смотрите в свойствах БД)
DBCC SHRINKFILE (N'zup_data', 0);

-- Журнал транзакций (предварительно переведя базу в simple или сделав бэкап лога)
DBCC SHRINKFILE (N'zup_log', 0);

Отдельная частая причина раздутого объёма серверной базы — разросшийся журнал транзакций при модели восстановления Full без регулярного бэкапа лога. Если бэкапы лога не настроены, а точка восстановления «на любой момент» вам не нужна, переведите базу в простую модель восстановления (Simple) — тогда лог перестанет копить неусечённые транзакции. Если же модель Full нужна, настройте регулярный бэкап журнала транзакций: именно он освобождает лог, а не SHRINK.

Сжатие SQL-базы не отменяет бэкап средствами 1С или СУБД — сделайте его до.

Удаление помеченных объектов и почему нельзя «вырезать» расчёты

Если вы всё же удаляете конкретные документы (например, ошибочно задвоенные или заведомо ненужные), штатный путь — пометить на удаление, а затем выполнить Администрирование → Обслуживание → Удаление помеченных объектов. Обработка проверит ссылочную целостность и не даст удалить объект, на который кто-то ссылается.

А вот массово «обрезать» расчёты ЗУП за прошлые годы удалением на месте — нельзя, и вот почему:

• 🧮 Средний заработок. Отпускные, больничные, командировки считаются по доходам и дням за 12–24 месяца назад. Удалив старые начисления, вы обнулите расчётную базу.
• 📅 Остатки отпусков. Они накапливаются от приёма сотрудника. Без истории кадровых документов остаток «поплывёт».
• 🎖 Стаж. Страховой и трудовой стаж для пособий собирается из кадровой истории.
• 🔁 Взаиморасчёты и НДФЛ. Регистры накопления по зарплате и НДФЛ не живут без своих документов-движений.

Поэтому «удаление периодов» в ЗУП — не кнопка, а продуманный перенос. Об этом — дальше.

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

Когда действительно нужно отрезать историю (база стала неподъёмной, или вы хотите «начать с чистого листа» с определённой даты), рабочий способ — создать новую чистую базу ЗУП и перенести в неё только необходимое, а не кромсать старую.

Что переносится:

1. Справочная информация — организации, подразделения, должности, сотрудники, графики, начисления и удержания, настройки учётной политики.
2. Кадровая история и начальная расстановка — чтобы сохранились стаж и позиции сотрудников на дату старта.
3. Остатки, нужные для расчётов — остатки отпусков, данные для среднего заработка, незакрытые взаиморасчёты, накопленный доход и удержанный НДФЛ с начала года.

Технически это делают либо типовыми механизмами переноса (выгрузка-загрузка справочных данных между базами ЗУП), либо специализированной обработкой переноса от 1С/партнёра. Ключевой момент — начальные остатки и данные для среднего заработка: без них новая база будет считать отпускные и пособия неверно. Поэтому дату «обрезки» выбирайте по границе года (проще собрать данные по НДФЛ и доходу).

Порядок при переносе обычно такой:

1. Создайте пустую базу из того же релиза ЗУП, что и рабочая, — иначе структуры данных не совпадут.
2. Перенесите справочники и настройки (организации, сотрудники, виды начислений, учётная политика).
3. Введите кадровую расстановку и начальные остатки на выбранную дату: остатки отпусков, данные для среднего, незакрытые взаиморасчёты, доход и НДФЛ с начала года.
4. Прогоните контрольный расчёт за первый период в новой базе и сверьте с рабочей.

Старую базу при этом не удаляйте — храните её как архив для сверок, запросов за прошлые периоды и ответов на требования по старым начислениям. Место под архив несопоставимо дешевле риска потерять историю расчётов.

Проверка базы после обрезки и сжатия

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

Что проверить:

• 🔧 Целостность. В Конфигураторе прогоните Тестирование и исправление с проверкой логической и ссылочной целостности (без сжатия, если уже сжимали).
• 🧾 Контрольные отчёты. Сформируйте расчётный листок и свод за закрытый месяц до и после — суммы должны совпасть. Проверьте отчёт по НДФЛ и взносам за текущий период.
• 🏖 Остатки отпусков по нескольким сотрудникам — сравните с тем, что было.
• 🔁 Обмен. Если оставляли синхронизацию, сделайте тестовый обмен и убедитесь, что он проходит.
• 👥 Вход пользователей. Пустите в базу одного-двух человек, проверьте скорость и открытие типовых документов.

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

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