Что делать, если в 1С не пересчитываются итоги и процесс зависает на одной дате

Работа с крупными базами данных (объемом более 1 Тб) на платформе 1С:Предприятие 8.3 требует особого внимания к обслуживанию MS SQL Server. Одной из критических проблем, с которой могут столкнуться администраторы и разработчики, является «замирание» процесса пересчета итогов. В этой статье мы подробно разберем ситуацию, когда дата рассчитанных итогов не двигается вперед, проанализируем причины возникновения этой проблемы и рассмотрим пошаговые методы ее решения на основе реального опыта и технических практик.

Анализ ситуации: почему итоги «застревают»

Рассмотрим типичный сценарий: для проведения регламентных работ была сброшена дата итогов. При попытке вернуть ее на текущий момент процесс доходит до определенной даты (например, конца года) и останавливается. При этом в консоли администрирования серверов 1С наблюдается рост показателя Захвачено СУБД, а в диспетчере задач SQL Server потребляет ресурсы, но прогресса нет в течение многих суток.

Первым делом проанализируем состояние процессов внутри SQL Server. Для этого выполним запрос, который покажет нам активные процессы и типы их ожиданий:

SELECT * FROM master.dbo.sysprocesses 
WHERE spid > 50 AND status = 'runnable';

Если мы обнаружим ожидание типа SOS_SCHEDULER_YIELD, это явный сигнал. Данный тип ожидания означает, что процесс исчерпал свой квант времени на процессоре и добровольно уступил место другим потокам, ожидая повторного включения в очередь планировщика. В контексте пересчета итогов 1С это часто свидетельствует о том, что SQL Server строит крайне неоптимальный план выполнения запроса из-за неактуальной статистики.

Решение №1: Полное обновление статистики (FULLSCAN)

В крупных базах стандартное регламентное задание по обновлению статистики часто выполняется в режиме SAMPLE (выборочно), чтобы сэкономить время. Однако для таблиц итогов регистров бухгалтерии, где количество записей исчисляется сотнями миллионов, выборки в 10-20% может быть недостаточно для корректной работы оптимизатора запросов.

Рассмотрим по шагам, как выполнить полное обновление статистики:

1. Выясним, какие именно таблицы SQL Server отвечают за проблемный регистр. Для этого в 1С используем метод ПолучитьСтруктуруХраненияБазыДанных.
2. Сформируем список таблиц итогов (например, для регистра бухгалтерии это будут таблицы с суффиксами _AccRgAT0, _AccRgAT1, _AccRgOpt и т.д.).
3. Выполним команду обновления статистики с параметром FULLSCAN для этих таблиц.

Пример кода на стороне 1С для получения имен таблиц:

МассивОбъектов = Новый Массив;
МассивОбъектов.Добавить("РегистрБухгалтерии.Хозрасчетный");
ТаблицаСтруктуры = ПолучитьСтруктуруХраненияБазыДанных(МассивОбъектов, Истина);
// Далее перебираем ТаблицаСтруктуры и ищем ИмяТаблицыХранения

После получения имен таблиц (например, _AccRg16395), выполним SQL-скрипт:

UPDATE STATISTICS _AccRg16395 WITH FULLSCAN;
UPDATE STATISTICS _AccRgOpt16447 WITH FULLSCAN;
-- Повторить для всех таблиц итогов данного регистра

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

Решение №2: Настройка параллелизма (MAXDOP)

Часто причиной ожидания SOS_SCHEDULER_YIELD является избыточный параллелизм. Когда SQL Server пытается разбить тяжелый запрос по пересчету итогов на 32 или 64 ядра, накладные расходы на координацию этих потоков становятся выше, чем профит от параллельного выполнения. Для баз 1С крайне рекомендуется ограничить этот параметр.

Как проверить и настроить:

1. В свойствах сервера SQL перейдите на вкладку Advanced.
2. Найдите параметр Max Degree of Parallelism.
3. Установите значение 1 (для полной последовательной обработки) или значение, равное количеству ядер в одном NUMA-узле (обычно 4 или 8).
4. Также проверьте Cost Threshold for Parallelism — для 1С рекомендуется устанавливать значение не менее 50.

Эти настройки заставят SQL Server использовать ресурсы более эффективно, не «распыляясь» на чрезмерное количество потоков при расчете итогов.

Решение №3: Оптимизация инфраструктуры (TempDB и Лог транзакций)

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

Проанализируем следующие моменты:

• Модель восстановления (Recovery Model): На время массового пересчета итогов крайне желательно перевести базу в режим Simple. Это предотвратит бесконечный рост файла лога транзакций (.ldf), который при переполнении диска просто остановит процесс пересчета.
• TempDB: Итоги считаются через временные таблицы в tempdb. Убедитесь, что tempdb вынесена на самые быстрые диски (NVMe/SSD) и имеет достаточное количество файлов (равное количеству ядер процессора, но не более 8).
• Ghost Records: При массовом удалении старых итогов SQL Server помечает записи как «призрачные». Если фоновая очистка (Ghost Cleanup) не успевает, таблицы раздуваются. Иногда помогает простой перезапуск службы SQL Server или (в крайнем случае) Detach/Attach базы, чтобы сбросить часть внутренних кэшей планировщика.

Решение №4: Особенности платформы 1С — «Разделение итогов»

В настройках регистров 1С существует свойство Разделение итогов. Оно позволяет записывать данные в несколько физических таблиц (таблицы с суффиксом _T), чтобы избежать блокировок. Однако при глобальном пересчете итогов на огромных объемах это может замедлить процесс.

Если пересчет не идет, попробуем следующий алгоритм:

1. В конфигураторе временно отключим разделение итогов для проблемного регистра.
2. Запустим пересчет итогов стандартными средствами (через Операции -> Управление итогами).
3. После успешного завершения пересчета вернем настройку разделения итогов обратно.

Решение №5: Физическая целостность данных

Если итоги всегда останавливаются на одной и той же дате (например, 31.12.2016), нельзя исключать повреждение данных на уровне страниц SQL. Проанализируем состояние таблиц командой DBCC CHECKTABLE. Используя имена таблиц, полученные ранее, выполним:

DBCC CHECKTABLE ('_AccRg16395');

Если команда выявит ошибки, потребуется восстановление из бэкапа или использование средств исправления ошибок SQL Server, так как обычное «Тестирование и исправление» в 1С может просто зависнуть на поврежденном участке.

Резюме и рекомендации

Подводя итог, можно сказать, что в 90% случаев проблема зависания пересчета итогов на крупных базах решается именно полным обновлением статистики (FULLSCAN) по конкретным таблицам регистра бухгалтерии. Если база большая, не делайте обновление по всей базе — это может занять сутки. Фокусируйтесь на целевых таблицах.

Ваш чек-лист при зависании итогов:

1. Проверить тип ожидания в SQL (ищем SOS_SCHEDULER_YIELD).
2. Получить список SQL-имен таблиц регистра.
3. Запустить UPDATE STATISTICS ... WITH FULLSCAN для этих таблиц.
4. Проверить MAXDOP (рекомендуется 1 для таких операций).
5. Перевести базу в Simple модель на время расчета.
6. Отключить все фоновые задания 1С на время операции.

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