Почему после переноса базы 1С на другой SQL-сервер расходятся данные в отчетах и документах?

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

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

Шаг 1. Проверка прав доступа и механизма RLS

Первое, на что необходимо обратить внимание при несовпадении данных у пользователей, — работа механизма ограничения доступа на уровне записей (RLS — Record-Level Security). Если отчет строит пользователь с ограниченными правами, платформа на лету добавляет в SQL-запрос условия фильтрации (по организациям, подразделениям, контрагентам или складам). При этом журнал документов может отображать доступные строки иначе, чем сводный отчет, обращающийся к виртуальным таблицам регистра.

Проверим эту гипотезу следующим образом:

1. Запустим сеанс «1С:Предприятие» под учетной записью с полными административными правами (роль ПолныеПрава или АдминистраторСистемы), где RLS полностью отключен.
2. Сформируем проблемный сводный отчет с типовыми настройками (сбросим вариант отчета на значение по умолчанию, чтобы исключить влияние пользовательских отборов).
3. Сравним полученные цифры с суммой по проведенным документам за аналогичный период.

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

Шаг 2. Пересчет итогов и реиндексация в Конфигураторе

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

Для синхронизации выполним процедуру Тестирования и исправления информационной базы:

1. Обязательно создадим резервную копию базы данных средствами СУБД.
2. Завершим все активные пользовательские сеансы и заблокируем регламентные задания.
3. Запустим «Конфигуратор», перейдем в меню Администрирование > Тестирование и исправление....
4. Отметим обязательные пункты проверки:

   — Реиндексация таблиц информационной базы;

   — Пересчет итогов;

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

5. Установим переключатель «При наличии ошибок» в режим Создавать объекты или Не изменять (в зависимости от регламента обслуживания) и нажмем кнопку Выполнить.

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

Шаг 3. Обновление и перестроение агрегатов оборотных регистров

В конфигурациях («Управление торговлей», «ERP», «Комплексная автоматизация») для высоконагруженных регистров продаж применяются агрегаты. Если для регистра включено использование агрегатов, сводные отчеты получают предопределенные сгруппированные данные именно из них. Если после переноса регламентное задание по обновлению агрегатов не выполнялось, данные отчетов за последние периоды будут существенно расходиться с накладными.

Выполним ручную актуализацию агрегатов:

1. В режиме «1С:Предприятие» откроем меню Функции для технического специалиста (или Все функции).
2. Перейдем в раздел Стандартные > Управление итогами и агрегатами.
3. Найдем регистры накопления, отвечающие за продажи и взаиморасчеты (например, регистр ВыручкаИСебестоимостьПродаж или Продажи).
4. Выполним перестроение агрегатов и сдвинем границу рассчитанных итогов на актуальную дату.
5. Проверим в консоли регламентных заданий работоспособность фоновых задач ОбновлениеАгрегатов и ПерестроениеАгрегатов.

Шаг 4. Очистка кэша кластера серверов 1С

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

Для исключения влияния устаревшего кэша произведем его очистку:

1. Остановим службу 1C:Enterprise 8.3 Server Agent через консоль управления службами Windows.
2. Перейдем в рабочий каталог кластера серверов (по умолчанию: C:\Program Files\1cv8\srvinfo\).
3. Внутри папки кластера (вида reg_1541) найдем каталоги сеансов и временных файлов snccntx*. Очистим их содержимое.
4. Важно: не удаляйте конфигурационные файлы кластера (1CV8Clst.lst, 1cv8wsrv.lst), чтобы не потерять список зарегистрированных баз.
5. Запустим службу сервера «1С:Предприятия» повторно.

Шаг 5. Регламентные процедуры на стороне MS SQL Server

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

Выполним первичное обслуживание через SQL Server Management Studio (SSMS). Запустим процедуру полного обновления статистических данных для всех таблиц:

USE [ИмяВашейБазыДанных];
GO
EXEC sp_updatestats;
GO

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

ALTER INDEX ALL ON [dbo].[_AccumRgT_ИмяТаблицы] REBUILD;
GO

Шаг 6. Локализация конкретного расхождения

Если после пересчета итогов и очистки кэша разница сохраняется, применим метод точечной сверки:

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

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