Пересчет итогов в 1С: сколько времени занимает и от чего зависит скорость

Пересчет итогов в 1С — стандартная операция обслуживания базы, которая восстанавливает актуальные остатки и обороты по регистрам накопления и бухгалтерии. Чаще всего её запускают через «Тестирование и исправление» в конфигураторе, когда отчеты показывают неверные остатки, проведение документов замедлилось или после сбоя сервера итоги «разъехались» с движениями документов.

Главный вопрос, который возникает у администратора перед запуском — сколько времени это займет и можно ли работать в базе во время пересчета. Однозначного ответа нет: на небольшой файловой базе в несколько гигабайт процедура может завершиться за 10–30 минут, а на крупной клиент-серверной базе с сотнями гигабайт данных — занять несколько часов и даже рабочую ночь.

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

Что такое пересчет итогов и когда он нужен

Итоги в 1С — это предварительно рассчитанные остатки и обороты, которые платформа хранит отдельно от движений документов, чтобы отчеты строились быстро. По регистрам накопления итоги хранятся помесячно, по регистрам бухгалтерии — по счетам и периодам. Когда документ проводится, платформа обновляет итоги автоматически.

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

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

Сколько времени занимает пересчет итогов: от чего зависит

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

• Объем базы. Главный фактор. Файловая база до 5 ГБ обычно пересчитывается за десятки минут; база в 50–100 ГБ — уже часы.
• Тип развертывания. Файловая база работает медленнее клиент-серверной на нормальном сервере СУБД, особенно при больших объемах.
• Количество и «тяжесть» регистров. Регистры с сотнями миллионов записей движений пересчитываются дольше всего.
• Скорость дисков. Разница между HDD и SSD на этой операции кратная — операция интенсивно читает и пишет данные.
• Глубина пересчета. Полный пересчет всех периодов дольше, чем пересчет с определенной даты.
• Загрузка сервера. Параллельные процессы, антивирус, фоновые задания увеличивают время.

Ориентировочный ориентир для планирования окна обслуживания: на файловой базе закладывайте 1–3 часа на каждые 10–15 ГБ данных при среднем железе, на клиент-серверной с SSD и настроенной СУБД — заметно меньше. Первый запуск на конкретной базе лучше делать с запасом времени и засечь фактическую длительность — она станет базой для планирования в будущем.

Как запустить пересчет итогов: пошагово

Стандартный способ — обработка «Тестирование и исправление» в конфигураторе. Порядок действий одинаков для большинства конфигураций.

1. 1
   Сделайте резервную копию базы (выгрузку в dt или backup средствами СУБД)
2. 2
   Попросите всех пользователей выйти и завершите фоновые сеансы
3. 3
   Откройте конфигуратор в монопольном режиме
4. 4
   Выберите Администрирование → Тестирование и исправление
5. 5
   Отметьте пункт «Пересчет итогов» (при необходимости вместе с реиндексацией)
6. 6
   Выберите режим «Тестирование и исправление» и нажмите «Выполнить»
7. 7
   Дождитесь завершения и проверьте протокол на ошибки
8. 8
   Проверьте ключевые отчеты: оборотно-сальдовую ведомость, остатки складов

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

Для клиент-серверных баз существует альтернатива: пересчет итогов отдельных регистров средствами СУБД или через код на встроенном языке (методы УстановитьПериодРассчитанныхИтогов и ПересчитатьИтоги у менеджеров регистров). Это позволяет пересчитывать не всё сразу, а только проблемный регистр, что сокращает время простоя.

Как ускорить пересчет итогов

Если окно обслуживания ограничено, есть несколько легальных способов сократить время:

• Пересчитывать выборочно. Если проблема затрагивает один-два регистра, пересчитайте только их через код, а не всю базу через тестирование и исправление.
• Ограничить период. Для регистров накопления можно пересчитать итоги начиная с даты, где возникла проблема, а не за всю историю.
• Перенести базу на SSD. Если база на файловом ресурсе или HDD, перенос на быстрый диск часто дает самый большой выигрыш.
• Отключить антивирус на каталоге базы или добавить его в исключения — проверка каждого блока файла сильно тормозит операцию.
• На клиент-серверной базе убедиться, что СУБД имеет достаточно памяти и tempdb расположен на быстром диске.

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

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

Можно ли работать в базе во время пересчета

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

Частичное исключение — программный пересчет итогов конкретного регистра на клиент-серверной базе. Технически он может выполняться при работающих пользователях, но создает тяжелую нагрузку на СУБД и блокировки на уровне регистра. На практике даже такой вариант лучше запускать в период минимальной активности, а пользователей предупредить о возможных «тормозах».

Маршрут решения

Как выбрать действие

База файловая, объем до 5–10 ГБЗапустите полное тестирование и исправление вечером — обычно укладывается в пару часов

База клиент-серверная, проблема в одном регистреПересчитайте итоги только этого регистра программно, без полного тестирования

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

Итоги разъезжаются регулярноИщите причину: проверьте диски, стабильность сервера, код обработок с прямой записью в регистры

Типичные ошибки и риски

Отдельная распространенная ситуация: пересчет итогов запускают, когда реальная проблема — не в итогах, а в ошибках ссылочной целостности или битых данных. В этом случае пересчет не поможет. Поэтому при серьезных сбоях имеет смысл запускать тестирование и исправление с несколькими проверками сразу (реиндексация, проверка ссылочной целостности, пересчет итогов), но с пониманием, что общее время вырастет.

Если пересчет итогов приходится делать регулярно — это тревожный симптом. Итоги не должны «разъезжаться» сами по себе. Проверяйте дисковую подсистему на ошибки, стабильность электропитания и сети, корректность завершения работы сервера 1С и СУБД, а также обработки, которые пишут в регистры нестандартными способами.

Как проверить результат после пересчета

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

Контрольные точки

Как проверить результат

Протокол тестирования

Норма

Нет ошибок и предупреждений по итогам

Тревожный признак

Есть сообщения об ошибках пересчета по регистрам

Оборотно-сальдовая ведомость

Норма

Сальдо совпадает с данными до сбоя или ожидаемыми значениями

Тревожный признак

Суммы изменились необъяснимо

Отчеты по остаткам складов

Норма

Остатки соответствуют движениям документов

Тревожный признак

Отрицательные или завышенные остатки без причины

Проведение документов

Норма

Документы проводятся без ошибок контроля остатков

Тревожный признак

Контроль остатков по-прежнему выдает ложные ошибки

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

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

Сколько ждать, прежде чем считать, что пересчет завис?

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

Можно ли запустить пересчет итогов без конфигуратора?

Да, программно: у менеджеров регистров накопления и бухгалтерии есть методы пересчета итогов, которые можно вызвать из внешней обработки или регламентного задания. Это удобно для точечного пересчета одного регистра и для автоматизации обслуживания на клиент-серверных базах.

Нужно ли делать реиндексацию вместе с пересчетом итогов?

Не обязательно, но часто разумно: реиндексация перестраивает индексы таблиц и ускоряет запросы. Если вы всё равно выделили окно обслуживания, запуск обеих операций за один раз экономит время по сравнению с двумя отдельными окнами. Учтите только, что суммарная длительность вырастет.

Ускорит ли пересчет переход с файловой базы на клиент-серверную?

Как правило, да, и заметно: серверная СУБД эффективнее работает с большими таблицами, использует память сервера и параллелизм. Но выигрыш зависит от настройки СУБД и железа — неправильно сконфигурированный сервер может работать не быстрее файлового варианта.

Что делать, если пересчет итогов не помог и остатки всё равно неверные?

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