Сколько ждать, пока 1С пересчитает итоги регистров

Пересчет итогов в 1С занимает от пары минут до нескольких часов. Небольшая файловая база на SSD (1–3 ГБ) обычно укладывается в 5–20 минут. Серверная база на 50–150 ГБ с многолетней историей проводок может пересчитываться 2–8 часов и дольше. Главное, от чего зависит время, — число записей в регистрах, особенно в регистре бухгалтерии, и скорость дисковой подсистемы.

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

От чего зависит длительность пересчета итогов

Итоги — это служебные таблицы, где платформа хранит готовые остатки и обороты регистров. При пересчете она стирает их и заново собирает из всех движений документов. Значит, время растет вместе с объемом движений.

Основные факторы:

• 📊 Количество записей в регистрах. База за 8 лет работы торговой компании с сотнями документов в день пересчитывается в разы дольше, чем база за 1–2 года.
• 🧾 Регистр бухгалтерии . В БП 3.0 это Хозрасчетный. Итоги в нем хранятся по счетам и по каждому сочетанию субконто, поэтому именно он обычно забирает основную долю времени.
• 📅 Период рассчитанных итогов. Если он давно не сдвигался, платформа хранит итоги на каждый месяц вперед до текущей даты и считает их все.
• 💽 Диск. Пересчет — это массовое чтение и запись. Переход с HDD на SSD сокращает время чаще всего заметнее, чем добавление процессоров.
• 🧠 Оперативная память. На сервере СУБД при нехватке памяти данные постоянно подкачиваются с диска.
• 🖥️ Вариант работы базы. Файловая или клиент-серверная, какая СУБД, где лежит файл базы — на локальном диске или в сетевой папке.
• 👥 Активные пользователи. Параллельная работа людей конкурирует за те же таблицы и блокировки.

Почему пересчет итогов идет так долго: технические причины

Когда пересчет растягивается на ночь, причина обычно в одной-двух вещах из этого списка:

1. Огромные таблицы движений. Платформа читает каждую запись каждого регистра. Здесь не сэкономишь, но можно не трогать лишнее (см. пересчет за период ниже).
2. Разросшиеся таблицы итогов. Чем дальше период рассчитанных итогов от реальной даты, тем больше строк платформа пишет заново.
3. Фрагментированные индексы и устаревшая статистика СУБД. Сервер выбирает медленный план запроса и читает таблицу целиком там, где хватило бы индекса.
4. Медленный журнал транзакций. В MS SQL при полной модели восстановления пересчет генерирует большой журнал. Если журнал лежит на том же медленном диске, что и данные, операции ждут друг друга.
5. Сетевая папка для файловой базы. Каждое чтение идет по сети. Пересчет в базе, открытой по \\server\bases\buh, может быть в несколько раз медленнее, чем та же операция на локальном диске сервера.
6. Антивирус. Проверка файла базы и временных файлов при каждом обращении заметно тормозит файловый вариант.
7. Блокировки от других сеансов. Если в базе кто-то работает или висит фоновое задание, пересчет ждет освобождения таблиц.

Где запустить пересчет и какой способ быстрее

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

Тестирование и исправление в Конфигураторе

Путь: Администрирование → Тестирование и исправление. В окне отметьте флажок «Пересчет итогов».

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

Управление итогами в режиме 1С:Предприятие

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

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

• «Пересчитать итоги» — полный пересчет выбранных регистров;
• «Пересчитать текущие итоги» — только актуальные остатки, это быстро;
• «Пересчитать итоги за период» — только указанный диапазон;
• «Установить период рассчитанных итогов» — сдвиг границы хранения итогов.

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

Пакетный запуск по расписанию

Для ночного обслуживания удобен запуск Конфигуратора с параметром /IBCheckAndRepair:

"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe" DESIGNER /F"D:\Bases\Buh" /N"Администратор" /P"пароль" /IBCheckAndRepair -RecalcTotals -TimeLimit:004:00 /Out"D:\Logs\recalc.log"

• -RecalcTotals — только пересчет итогов;
• -TimeLimit:004:00 — остановить операцию через 4 часа, чтобы к утру база гарантированно освободилась;
• -UseStartPoint — при следующем запуске продолжить с места, где остановились.

Версию платформы в пути замените на свою. Для серверной базы вместо /F укажите /S"сервер\имябазы". Полный список ключей — в справке по параметрам командной строки, которая ставится вместе с платформой.

Как подготовить базу, чтобы пересчет прошел быстрее

Подготовка часто дает больше, чем любые настройки во время самого пересчета.

Для серверной базы основная работа идет на стороне СУБД:

• MS SQL Server: перед пересчетом выполните перестроение индексов и обновление статистики через план обслуживания. Можно временно перевести базу в простую модель восстановления, чтобы журнал не разрастался, — но только если вы понимаете, как это повлияет на вашу схему резервного копирования.
• PostgreSQL: выполните VACUUM ANALYZE для базы. Проверьте, что параметры памяти (shared_buffers, work_mem) не остались по умолчанию из пакета дистрибутива.

Чтобы понять, какие регистры самые тяжелые, посмотрите размеры таблиц в СУБД. Для PostgreSQL:

SELECT relname,
       pg_size_pretty(pg_total_relation_size(relid)) AS size
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 20;

Для MS SQL — число строк по таблицам:

SELECT TOP 20 t.name, SUM(p.rows) AS rows_count
FROM sys.tables t
JOIN sys.partitions p ON p.object_id = t.object_id AND p.index_id IN (0, 1)
GROUP BY t.name
ORDER BY rows_count DESC;

Таблицы движений регистров накопления называются _AccumRg…, их итоги — _AccumRgT…. Таблицы регистра бухгалтерии начинаются с _AccRg. Если в верхней строке списка таблица на сотни миллионов строк — она и задает время пересчета.

Файловая или клиент-серверная база: что меняется

Архитектура определяет, кто выполняет работу и где узкое место.

Файловый вариант. Всю работу делает один процесс 1С на компьютере, где открыт Конфигуратор. Данные читаются из одного файла. Узкие места — диск и сеть, если база в общей папке. Многоядерность почти не помогает.

Клиент-серверный вариант. Запросы выполняет СУБД, у нее свой кэш, параллельное чтение и оптимизатор. На больших объемах это быстрее файлового варианта. Но если сервер СУБД слабый, перегружен другими базами или живет на виртуальной машине с общим диском, пересчет может оказаться медленнее ожидаемого.

Конфигурация влияет через набор регистров:

• БП 3.0 — основное время уходит на регистр бухгалтерии Хозрасчетный и регистры накопления по взаиморасчетам и товарам.
• УТ 11, КА 2, ERP — много регистров накопления по товарам, резервам, взаиморасчетам; общий объем движений обычно больше, чем в бухгалтерии той же компании.
• ЗУП 3.1 — регистров много, но строк в них меньше; пересчет обычно идет быстрее, чем в учетных конфигурациях того же возраста.

Сравнение: сколько длится пересчет в разных условиях

Ориентиры для полного пересчета итогов всех регистров при отключенных пользователях. Реальное время может отличаться в 2–3 раза в обе стороны.

Последняя строка показывает главный резерв: чаще всего полный пересчет не нужен вовсе. Если расхождение в остатках обнаружено по одному счету или складу, пересчитайте конкретный регистр за конкретный период.

Как ускорить пересчет и реже к нему прибегать

Сдвигайте период рассчитанных итогов

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

Отключайте итоги на время массовой загрузки

Классический прием при переносе данных или перепроведении за год:

1. В «Управлении итогами» выключите использование итогов для нужных регистров.
2. Выполните загрузку или групповое перепроведение — документы проведутся быстрее, потому что итоги не обновляются при каждой записи.
3. Включите использование итогов обратно. Платформа сама пересчитает их одним проходом.

Пока итоги выключены, отчеты по остаткам строятся очень медленно или некорректно — делайте это вне рабочего времени.

Включите разделение итогов

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

Свертка базы

Если база хранит 10 лет истории, а реальная работа идет с последними тремя, поможет свертка или переход в новую базу с вводом остатков. Это радикальная мера с отдельным планом, но она сокращает время любых сервисных операций кратно.

Пересчитывайте только при необходимости

Полный пересчет нужен, если отчеты не сходятся с движениями документов, после сбоя питания во время записи или после аварийного обновления. Регулярный еженедельный полный пересчет «на всякий случай» на исправной базе ничего не дает.

Пересчет итогов завис: что делать

Отличить долгую работу от реального зависания можно по активности. Откройте диспетчер задач на компьютере, где выполняется операция (для серверной базы — на сервере СУБД), и посмотрите нагрузку на диск и процессор.

Если решили прервать операцию:

• ⏹️ Прерывание пересчета итогов само по себе не портит документы: движения на месте, а итоги можно пересчитать повторно. Отчеты до этого момента будут показывать неверные остатки.
• 🛑 Прерывание реструктуризации или сжатия в том же запуске опасно — база может не открыться. Поэтому не совмещайте пересчет с этими операциями на больших базах.
• ⚠️ Завершение процесса 1С или сеанса в консоли оборвет работу всех, кто в этот момент подключен к базе. Делайте это только после предупреждения пользователей.

Если база после прерывания не открывается, восстановите ее из резервной копии, сделанной перед запуском.

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