Рассмотрим ситуацию, с которой сталкиваются многие пользователи старых, больших баз 1С:Управление торговлей 10.3. После стандартной, казалось бы, процедуры — выгрузки базы в файл .dt и загрузки обратно для уменьшения физического размера — производительность системы катастрофически падает. Важно понимать, почему .dt — это не бэкап, и какие риски несет логическое восстановление для баз объемом 500+ Гб. Проведение обычного документа «Реализация товаров и услуг» (РТУ) вместо привычных нескольких секунд начинает занимать минуты, что парализует работу нескольких пользователей из-за постоянных блокировок. Проанализируем, почему это происходит и как вернуть системе прежнюю скорость.
Исходные данные проблемы: база УТ 10.3, работающая с 2010 года, размером около 600 Гб на SQL Server. После выгрузки/загрузки через .dt размер уменьшился вдвое, но время проведения РТУ выросло с 2 секунд до 3 минут. Проведенный замер производительности (для углубленного изучения ситуации можно использовать инструменты под анализ документов, автотесты и динамику роста базы) указывает на основное "торможение" в момент записи движений в регистры: СтрокаДвижения.НаборЗаписей.Записать(). При этом серверное оборудование не перегружено, но наблюдается высокая очередь к диску.
Первое, что нужно сделать в такой ситуации, — это исключить очевидные факторы. В нашем случае автор проблемы подтвердил, что:
Это приводит нас к однозначному выводу: проблема кроется в состоянии самих данных в базе после процедуры выгрузки/загрузки.
В УТ 10.3 одним из самых ресурсоемких механизмов является партионный учет. Он включается опцией «Списывать партии при проведении документов». Проведем эксперимент на копии проблемной базы:
Автор темы подтвердил, что отключение партионного учета сократило время проведения вдвое (с 20 секунд до 10 на тестовом сервере). Это прямое указание на то, что основная нагрузка возникает именно при расчете и записи движений по регистрам партий, таким как ПартииТоваровНаСкладах.
Теперь выясним, что именно в данных партионного учета могло так сильно замедлить систему.
Существует несколько "болевых точек" в механизме партий, которые могли обостриться после манипуляций с базой данных.
Партионный учет опирается на механизм последовательностей. Граница последовательности — это дата, до которой все документы считаются проведенными корректно и в правильном порядке. При проведении нового документа система анализирует данные, начиная с этой границы, чтобы правильно подобрать партии для списания.
В обсуждаемом случае выяснилось, что итоги по регистрам были рассчитаны на актуальную дату, а вот граница последовательности партионного учета «застряла» на 2011 году. Это означает, что при проведении каждого нового документа в 2024 году система была вынуждена анализировать данные за 13 лет! Это колоссальный, избыточный объем вычислений, который и является одной из главных причин замедления.
Как проверить: зайдите в меню "Операции" -> "Проведение документов". В форме обработки выберите последовательность, отвечающую за партии (например, "Партионный учет (управленческий учет)"), и посмотрите дату, на которую она установлена.
Наличие отрицательных остатков по партиям (когда товара по документам списали больше, чем оприходовали) — это скрытая причина деградации производительности, приводящая к катастрофическому падению скорости работы. Алгоритмы подбора партий в 1С не оптимизированы для таких ситуаций и начинают выполнять огромное количество лишних итераций, пытаясь найти несуществующую партию, что приводит к "квадратичным" задержкам.
Выгрузка огромной базы в .dt и загрузка обратно — это не то же самое, что резервное копирование и восстановление средствами SQL. Этот процесс может приводить к ряду скрытых проблем:
Явным признаком этой проблемы стало то, что встроенная утилита Тестирование и исправление (ТиИ) начала зависать на проверке логической целостности и пересчете итогов с ошибкой "конфликта блокировки SQL". Это говорит о серьезных нарушениях в структуре данных, которые мешают даже служебным механизмам 1С корректно работать.
Теперь, когда мы понимаем причины, составим пошаговый план действий. Важно: все операции проводите на свежей копии базы данных!
Стандартного плана обслуживания может быть недостаточно. Используйте профессиональное руководство по настройке SQL Server для 1С и выполните следующие команды для ключевых, самых больших таблиц (в первую очередь, таблиц регистров накопления ПартииТоваровНаСкладах, ТоварыНаСкладах, Продажи и т.д.):
UPDATE STATISTICS ИмяТаблицы WITH FULLSCAN;
Это заставит SQL Server пересчитать статистику, проанализировав все строки таблицы, что даст ему более точную информацию для построения планов запросов.ALTER INDEX ALL ON ИмяТаблицы REBUILD;
В отличие от реорганизации (REORGANIZE), перестройка (REBUILD) физически создает индексы заново, полностью устраняя фрагментацию.Сформируйте стандартный отчет "Ведомость по партиям товаров на складах" за весь период. Для более глубокого анализа рекомендуется проверить несоответствие остатка по партиям и остатка по складам, так как рассинхронизация этих регистров часто вызывает скрытые ошибки. Проанализируйте отчет на наличие отрицательных значений в колонке "Конечный остаток".
Каждую проблемную позицию необходимо исправить. Чтобы не тратить часы на ручной ввод документов, можно использовать корректировку партий товаров в несколько кликов, которая автоматизирует исправление пересорта и минусов. Также для точечных исправлений подойдет инструмент, выполняющий корректировку регистра "Партии товаров на складах" документом "Корректировка записей регистров". В ряде случаев может потребоваться исправление остатков регистра "Товары организации" по данным регистра "Товары на складах", чтобы привести все учетные разрезы к единому состоянию.
Это самый важный и потенциально долгий этап. Необходимо запустить алгоритм актуализации границ последовательностей через обработку "Проведение документов", чтобы сдвинуть границу с 2011 года на актуальную дату. На большой базе этот процесс может занять десятки часов или даже несколько дней. Его лучше запускать на выходные. Возможно, потребуется выполнять его поэтапно, сдвигая границу по году или по кварталу.
После того как вы исправили данные и актуализировали последовательность, запустите ТиИ из Конфигуратора еще раз, учитывая рекомендации по выполнению ТиИ на высоконагруженных системах, чтобы избежать конфликтов блокировок. Включите все проверки, особенно:
На этот раз процесс должен завершиться корректно. Успешное завершение ТиИ будет означать, что логическая целостность базы восстановлена.
После выполнения всех этих шагов время проведения документов должно вернуться к приемлемым значениям. Проблема кроется не в магии, а в накопленных за годы ошибках учета и особенностях работы платформы 1С с большими объемами данных, которые обострились после не самой удачной процедуры обслуживания.