При проведении регламентных операций по обслуживанию базы данных (ТиИ — Тестирование и исправление) администраторы часто сталкиваются с аномальным поведением системы. Одной из самых загадочных ситуаций является проверка логической целостности регистров накопления, когда шкала прогресса переваливает за 100% и процесс уходит в «бесконечный цикл». Особенно часто это проявляется в связке платформы 1С:Предприятие 8.3 и СУБД PostgreSQL. Разберем причины этого явления и пошагово рассмотрим методы решения проблемы.
Прежде чем переходить к активным действиям, выясним, почему платформа ведет себя подобным образом. Проблема редко заключается в самой 1С, чаще это результат конфликта между логикой платформы и физическим хранением данных в СУБД. Проанализируем основные факторы:
Collation (сортировки) в PostgreSQL могут возникнуть записи, которые платформа считает одинаковыми, а СУБД — разными. При попытке исправить логическую целостность ТиИ входит в рекурсию, пытаясь пересчитать итоги по конфликтующим записям._AccumRegTotals) могут содержать некорректные даты (например, 0001-01-01 или значения из далекого будущего).MVCC оставляет старые версии строк. Если Autovacuum настроен агрессивно или, наоборот, не справляется, объем таблицы итогов может вырасти в десятки раз, что замедляет сканирование до критических значений.Первым делом проанализируем версию вашей СУБД. Если используется PostgreSQL 9.x, это основной кандидат на роль виновника. Платформа 8.3.19 и выше ожидает от СУБД поддержки современных механизмов оптимизации запросов. Рассмотрим алгоритм миграции на новую версию:
.dt. Если база слишком велика и выгрузка не проходит, этот метод придется пропустить и использовать миграцию на уровне SQL.Russian_Russia.1251)..dt или выполним переливку таблиц.Важно: При переходе на 13-ю версию PostgreSQL учитывайте, что формат B-tree индексов изменился. После загрузки данных обязательно выполните команду REINDEX DATABASE.
Если ТиИ зависает на логической проверке, попробуем подготовить базу на уровне СУБД. Выполним «жесткую» очистку и переиндексацию, чтобы исключить влияние физических повреждений таблиц. Рассмотрим последовательность команд в консоли pgAdmin или psql:
Сначала выполним полную очистку базы от «фантомных» записей и обновим статистику планировщика:
VACUUM FULL ANALYZE;
REINDEX DATABASE имя_вашей_базы;
После этого попробуем запустить в 1С только «Пересчет итогов». Часто именно этот этап позволяет системе «прожевать» проблемные записи в регистрах накопления без полной проверки логической целостности.
Если база настолько повреждена, что стандартное ТиИ не справляется, а выгрузка в .dt падает с ошибкой, воспользуемся советом экспертов и создадим «чистый» клон базы через механизм Распределенных Информационных Баз (РИБ). Это позволит перенести данные в новую структуру, отсекая системный мусор. Рассмотрим процесс по шагам:
Этот метод хорош тем, что при записи данных в новую базу 1С автоматически пересчитывает итоги «с нуля», не опираясь на старые (возможно, битые) таблицы итогов _AccumRegTotals.
Если мы точно знаем, какой регистр вызывает проблему (например, ТоварыВНТТ), проанализируем возможность его очистки через XML. Рассмотрим этот вариант подробнее:
Воспользуемся стандартной обработкой ВыгрузкаЗагрузкаДанныхXML.epf. Она работает на уровне объектов и игнорирует многие ошибки физического уровня таблиц. Порядок действий следующий:
Набор = РегистрыНакопления.ИмяПроблемногоРегистра.СоздатьНаборЗаписей();
Набор.Записать(); // Записываем пустой набор, что фактически очищает данные
Ситуация, когда ТиИ показывает более 100%, — это явный сигнал о несоответствии метаданных 1С и физических таблиц PostgreSQL. Мы рассмотрели несколько путей: от простого обслуживания СУБД командами VACUUM и REINDEX до радикальной миграции данных через РИБ или XML. Помните, что перед любыми манипуляциями с таблицами итогов или версиями СУБД создание резервной копии на уровне файловой системы или снимка виртуальной машины является обязательным условием безопасности ваших данных.