Сворачивание информационной базы 1С — это стандартная, но чрезвычайно ответственная процедура, предназначенная для уменьшения объема базы данных и повышения быстродействия системы. В процессе свертки удаляются устаревшие документы за прошлые периоды, а вместо них создаются документы ввода остатков (как правило, это документы КорректировкаЗаписейРегистров или специализированные документы ввода остатков). Однако иногда после успешно завершенной свертки технические специалисты сталкиваются со странным поведением системы: отчеты выводят некорректные остатки товаров или взаиморасчетов, хотя физические документы-регистраторы содержат абсолютно верные цифры.
В этой статье мы подробно разберем, почему возникает ситуация, когда реальные движения по регистру накопления не соответствуют данным его виртуальной таблицы остатков, проанализируем неочевидные причины этого сбоя и рассмотрим пошаговые сценарии решения проблемы.
Рассмотрим классическую ситуацию, с которой часто сталкиваются разработчики. Вы выполнили свертку базы данных на определенную дату. Для проверки корректности данных вы формируете запрос к виртуальной таблице остатков регистра накопления ТоварыНаСкладах.Остатки на конец текущего дня:
ВЫБРАТЬ
ТоварыНаСкладахОстатки.Номенклатура КАК Номенклатура,
ТоварыНаСкладахОстатки.ХарактеристикаНоменклатуры КАК ХарактеристикаНоменклатуры,
ТоварыНаСкладахОстатки.КоличествоОстаток КАК Остаток
ИЗ
РегистрНакопления.ТоварыНаСкладах.Остатки(
&Дата,
Номенклатура В (&Номенклатура)
И Склад В (&Склад)) КАК ТоварыНаСкладахОстатки
Запрос возвращает некорректное число (например, 97 единиц товара). Чтобы разобраться, откуда взялась эта цифра, мы пишем запрос к таблице физических движений этого же регистра за весь период существования свернутой базы:
ВЫБРАТЬ
ТоварыНаСкладах.Номенклатура КАК Номенклатура,
ТоварыНаСкладах.ХарактеристикаНоменклатуры КАК ХарактеристикаНоменклатуры,
ТоварыНаСкладах.Количество КАК Количество,
ТоварыНаСкладах.Регистратор КАК Регистратор,
ТоварыНаСкладах.ВидДвижения КАК ВидДвижения
ИЗ
РегистрНакопления.ТоварыНаСкладах КАК ТоварыНаСкладах
ГДЕ
ТоварыНаСкладах.Номенклатура = &Номенклатура
И ТоварыНаСкладах.Склад = &Склад
Этот запрос возвращает всего две записи:
КорректировкаЗаписейРегистров (ввод остатков после свертки) — движение Приход на сумму 15 единиц.ЧекККМ (текущие продажи после даты свертки) — движение Расход на сумму 1 единица.Математически очевидно, что итоговый остаток должен составлять 14 единиц. Однако виртуальная таблица упорно возвращает 97. При этом стандартное Тестирование и Исправление (ТиИ) через Конфигуратор с включенными флагами «Реиндексация таблиц» и «Пересчет итогов» на рабочем компьютере не дает никакого результата. Выясним, почему так происходит, и разберем четыре основные причины этой проблемы.
Если тестирование и исправление базы данных не приносит результатов на рабочем компьютере, но при переносе базы на другой ПК и повторном выполнении ТиИ остатки мгновенно приходят в норму — проблема кроется в локальном кэше платформы 1С:Предприятие.
Во время свертки базы происходят колоссальные изменения в структуре метаданных и физических таблицах СУБД: удаляются миллионы строк документов, создаются новые тяжелые записи корректировок. Локальный кэш исходного компьютера (в котором хранятся индексы таблиц, структуры запросов и временные файлы виртуальных таблиц) рассинхронизируется с реальным физическим состоянием базы данных. При выполнении запросов платформа обращается к старым кэшированным данным индексов и возвращает некорректные виртуальные итоги.
Для устранения этой проблемы выполним очистку кэша по шагам:
%userprofile%\AppData\Local\1C\1Cv8%userprofile%\AppData\Roaming\1C\1Cv82c9f56a3-678a-4b9d-b4ef.... В этих папках как раз и содержатся временные кэшированные данные конфигураций и баз данных.Если вы используете устаревшие релизы платформы 1С (например, ветку 8.3.8, в частности релиз 8.3.8.1652), вы можете столкнуться с зарегистрированными технологическими ошибками расчета итогов. В ряде релизов платформы присутствует критическая ошибка: при пересчете итогов регистров, у которых среди измерений присутствуют строковые типы данных или составные типы с неограниченной длиной, либо если индекс по измерениям включает более 16 полей, СУБД рассчитывает итоги неверно.
Для исправления ситуации выполним следующие действия:
8.3.12, 8.3.20 или старше, в которых уязвимости механизмов индексации виртуальных таблиц полностью устранены.ВосстановлениеВспомогательныхДанныхТаблиц.epf (она находится в каталоге установки платформы EXE\Diagnostics838). Запустите её в режиме Предприятия и выполните восстановление структуры итогов.Иногда стандартный механизм «Пересчета итогов» в Конфигураторе не выполняет физическую очистку таблиц итогов, а лишь пытается наложить новые расчеты на уже существующие «фантомные» записи. В этом случае нам поможет принудительный сброс рассчитанных итогов далеко в прошлое с последующим полным расчетом «с нуля».
Проанализируем процедуру ручного сброса через режим Предприятия:
Если ручной метод не помог, разработчики могут применить программный пересчет итогов по конкретному регистру. Посмотрим на пример кода, который полностью перестраивает таблицы итогов регистра накопления:
// Отключаем использование итогов для регистра накопления
РегистрыНакопления.ТоварыНаСкладах.УстановитьИспользованиеИтогов(Ложь);
// Включаем использование итогов обратно - это форсирует полную очистку и пересоздание таблиц
РегистрыНакопления.ТоварыНаСкладах.УстановитьИспользованиеИтогов(Истина);
// Вызываем метод принудительного пересчета за весь период ведения учета
РегистрыНакопления.ТоварыНаСкладах.ПересчитатьИтогиЗаПериод();
Выполнение этого кода гарантирует полное уничтожение любых некорректных архивных записей в таблице остатков и их пересчет на основании только реально существующих документов регистраторов.
Сворачивание базы — транзакционно емкий процесс. При нехватке оперативной памяти сервера СУБД (особенно в файловом варианте или при работе на 32-разрядных серверах приложений) транзакция удаления старых документов может прерваться ошибкой СУБД в самый последний момент. При этом часть документов может быть удалена из таблиц регистраторов, но записи итогов в физической таблице остатков (которая обновляется в СУБД асинхронно или в конце транзакции) сохраняют старые значения.
В такой ситуации в базе возникают «битые» или «сиротские» записи итогов, у которых нет физических документов-регистраторов. Стандартная таблица остатков обращается к ним напрямую, искажая картину.
Для исправления такой проблемы необходимо выполнить полное Тестирование и Исправление (ТиИ) со следующими обязательными настройками:
После прохождения всех этапов тестирования и исправления обязательно запустите повторный расчет итогов, чтобы система окончательно синхронизировала таблицы движений с виртуальными остатками.