Почему зависает обновление статистики SQL на служебных таблицах 1С и как это исправить

При выполнении ночных регламентных процедур в Microsoft SQL Server администраторы 1С нередко сталкиваются с ситуацией, когда план обслуживания выполняется аномально долго, зависает на этапе сбора статистики по определенным таблицам или прерывается принудительной перезагрузкой операционной системы. В журналах SQL Server при этом можно обнаружить дампы процессов на командах вида UPDATE STATISTICS [dbo].[_AccumRgChngRXXXX] WITH FULLSCAN, а после перезапуска пользователи сталкиваются с зависанием проведения документов и исчезновением незафиксированных данных.

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

Что означает таблица с префиксом _AccumRgChngR

Префикс _AccumRgChngR (Accumulation Register Changes) принадлежит служебным таблицам 1С:Предприятия, которые отвечают за регистрацию изменений регистров накопления для планов обмена (механизмы РИБ или универсального обмена данными). Число в конце имени (например, 7374) — это внутренний идентификатор объекта метаданных в конкретной базе данных.

Для сопоставления имени физической таблицы в СУБД с объектом конфигурации воспользуемся встроенной функцией платформы ПолучитьСтруктуруХраненияБазыДанных(). Выполним программный поиск нужной таблицы:

СтруктураБД = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого Стр Из СтруктураБД Цикл
    Если Стр.ИмяТаблицыХранения = "_AccumRgChngR7374" Тогда
        Сообщить("Имя метаданных: " + Стр.ИмяТаблицы);
    КонецЕсли;
КонецЦикла;

Причины зависания плана обслуживания и формирования дампа SQL

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

1. Колоссальный объем таблицы регистрации изменений. Если в конфигурации настроены планы обмена, но в них присутствуют неактивные, отключенные или давно не синхронизировавшиеся узлы, записи об изменениях в регистрах никогда не удаляются. Таблица разрастается до десятков миллионов строк. Выполнение UPDATE STATISTICS ... WITH FULLSCAN на гигантской таблице требует огромных ресурсов ввода-вывода и оперативной памяти, что приводит к многочасовому зависанию.
2. Повреждение страниц данных или индексов (Data Corruption). Появление мини-дампа в журнале SQL Server при чтении таблицы часто сигнализирует о нарушении логической или физической целостности страниц данных. При сплошном сканировании (FULLSCAN) процесс натыкается на поврежденный сектор, генерируя аварийный дамп.
3. Неэффективная логика стандартных планов обслуживания. Стандартные мастера обслуживания в SQL Server Management Studio запускают полное сканирование статистики для всех объектов без разбора, включая огромные неизменяемые или, наоборот, временные таблицы регистрации.

Почему пропадают документы и зависает проведение

Рассмотрим механизм проведения документов: при записи движений по регистру накопления платформа 1С обязана параллельно внести запись о модификации в соответствующую таблицу _AccumRgChngR для каждого зарегистрированного узла плана обмена. Если эта служебная таблица заблокирована долгим сбором статистики или перегружена, транзакция проведения зависает на блокировках.

Если в этот момент происходит перезагрузка операционной системы или службы SQL Server, запускается процедура Recovery (восстановление базы данных). В процессе восстановления СУБД выполняет две фазы:

1. Redo (накат): фиксируются транзакции, записанные в журнал транзакций до сбоя.
2. Undo (откат): все незавершенные на момент сбоя транзакции принудительно откатываются (Rollback).

Документ, который пользователь начал проводить непосредственно перед перезагрузкой или во время сбойного состояния, не успел зафиксировать транзакцию. При восстановлении СУБД вернула базу к целостному состоянию, поэтому незавершенный документ закономерно «пропал» из информационной базы.

Пошаговый план решения и устранения проблемы

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

1. Проверка физической и логической целостности базы данных

Для исключения повреждения дисковой подсистемы и структуры страниц данных выполним диагностику базы в среде SQL Server:

DBCC CHECKDB ('ИмяВашейБазыДанных') WITH NO_INFOMSGS, ALL_ERRORMSGS;

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

2. Очистка неактуальной регистрации изменений в 1С

Выясним состояние узлов планов обмена:

1. Открываем список всех планов обмена в режиме «1С:Предприятие».
2. Находим неиспользуемые, устаревшие или тестовые узлы, для которых обмен больше не производится, и удаляем их.
3. Для очистки накопившихся «хвостов» используем типовую обработку «Регистрация изменений для обмена данными» либо выполняем очистку программно:

// Очистка регистрации изменений по конкретному регистру накопления
ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена, Метаданные.РегистрыНакопления.ИмяРегистра);

3. Оптимизация регламентного обслуживания SQL Server

Откажемся от сплошного сканирования всей базы методом FULLSCAN в пользу интеллектуального обслуживания:

1. Выборочное обновление статистики: обновляем статистику только тех объектов, где изменился существенный процент данных (отслеживается через системные динамические представления sys.dm_db_stats_properties).
2. Использование сэмплирования: для сверхбольших таблиц используем процентное сканирование (SAMPLE ... PERCENT) вместо 100% сканирования.
3. Разделение технологических окон: разносим по времени регламентные перезагрузки операционной системы Windows Server и окно обслуживания СУБД, оставляя достаточный запас по времени для завершения всех процессов.