Перенос крупной базы данных «1С:Управление торговлей 10.3» (УТ 10.3) на новую СУБД (например, переезд с MS SQL на PostgreSQL) часто сопровождается жесткими временными рамками. Попытка выполнить эту операцию стандартным способом через выгрузку и загрузку файла .dt нередко оборачивается многочасовым ожиданием или зависанием процесса. В этой статье мы подробно разберем, почему база объемом всего 14 Гб может выгружаться часами, как правильно провести ревизию и очистку тяжелых регистров без вреда для учета, и какие современные инструменты миграции стоит использовать для быстрого решения задачи.
Для базы объемом в 14 Гб время выгрузки в файл .dt, превышающее 4 часа, является критической аномалией. В штатном режиме на современном оборудовании этот процесс должен занимать не более 15–30 минут. Давайте проанализируем основные факторы, которые вызывают такое замедление:
Перед тем как приступать к масштабной очистке данных, обязательно выполните базовую подготовку на исходном SQL-сервере. Запустите реорганизацию и перестроение индексов, а также обновление статистик. Дополнительно проведите тестирование и исправление базы данных (ТиС) из конфигуратора с включенными опциями проверки логической и ссылочной целостности.
Часто администраторы в попытках сжать базу начинают удалять все подряд. Важно понимать, что удаление мелких справочников (таких как Банки, который со всеми индексами весит менее 10 МБ) абсолютно не решает проблему производительности и объема. Это «капля в море», которая никак не ускорит миграцию. Сосредоточиться нужно на действительно «тяжелых» объектах.
Распространенная ситуация: организация работает по упрощенной системе налогообложения (УСН) или зарегистрирована как ИП без НДС, но регистры накопления по НДС (например, НДС начисленный, НДС по партиям запасов) раздуты до гигабайтных размеров. Выясним причину этого поведения системы.
В конфигурации УТ 10.3 партионный учет архитектурно тесно связан с регистрами НДС. Даже если в учетной политике отключен общий учет НДС, система при проведении документов поступления и списания товаров продолжает делать движения по регистру НДС по партиям запасов. Если пользователи по привычке заполняют колонку ставки НДС в документах (даже без выделения налога), регистр будет стремительно расти.
Как поступить правильно:
TRUNCATE) крайне опасно. При проведении последующих документов система попытается списать партии по регистру НДС по партиям запасов и, не найдя остатков, выдаст ошибки или нарушит себестоимость.Регистр накопления СписанныеТовары используется в УТ 10.3 как временный буфер при включенном режиме «отложенного проведения». Когда менеджер проводит документ продажи, система быстро делает запись в этот регистр, не рассчитывая себестоимость в реальном времени. Затем регламентная обработка «Проведение по партиям» забирает данные из этого регистра, рассчитывает партии и очищает его.
Если в вашей базе партионный учет актуален и все последовательности восстановлены, этот регистр по окончании расчетов должен быть пуст по остаткам. Его ручная очистка не принесет пользы, так как система управляет им автоматически. Если же в нем висят миллионы записей за прошлые годы — это признак того, что последовательность проведения партий заброшена. В таком случае регистр можно очистить, но это зафиксирует некорректность партионного учета в прошлых периодах.
Это классические оборотные регистры накопления. Они не хранят остатки, а только фиксируют факты хозяйственных операций для построения отчетов. Их прямая очистка существенно уменьшит размер базы данных, но полностью лишит вас возможности строить отченость по продажам и закупкам за прошлые годы непосредственно в рабочей базе.
Если руководство согласовало сценарий, при котором старая отчетность будет анализироваться исключительно в архивной копии базы, то очистка этих регистров вполне допустима. Но выполнять ее нужно не ручным удалением строк, а через стандартную процедуру **свертки информационной базы** на определенную дату.
Проанализируем объекты, которые можно безболезненно удалить из базы прямо перед миграцией, так как они не влияют на оперативный учет и проведение документов:
.lgf или новые форматы базы данных журнала) часто забывают сократить. Выполните процедуру сокращения журнала регистрации через конфигуратор, сохранив старые записи в отдельный файл.Иногда специалисты рекомендуют использовать внешние инструменты разработчика для генерации SQL-скрипта очистки таблиц (например, через команду TRUNCATE TABLE). Разберем, почему этот метод требует предельной осторожности:
Во-первых, происходит нарушение ссылочной целостности. Платформа 1С хранит связи между таблицами документов и их движениями на уровне метаданных. Если вы очистите таблицу движений регистра напрямую в SQL, документ в базе останется в статусе «Проведен», но фактически не будет давать никаких движений. При первой же попытке перепроведения или группового пересчета итогов система столкнется с рассинхронизацией данных.
Во-вторых, разрушаются таблицы итогов. Регистры накопления в 1С состоят из таблицы движений и таблиц итогов (текущих и промежуточных по месяцам). Если очистить только основную таблицу движений через SQL, таблицы итогов останутся заполненными старыми значениями. Отчеты продолжат показывать остатки несуществующих товаров. Чтобы этого избежать, после любых прямых манипуляций с SQL-таблицами необходимо обязательно выполнять пересчет итогов:
// Пример программного пересчета итогов для регистра накопления
РегистрыНакопления.Продажи.УстановитьИспользованиеИтогов(Ложь);
РегистрыНакопления.Продажи.УстановитьИспользованиеИтогов(Истина);
Если вашей главной целью является перенос базы на новую СУБД PostgreSQL в рамках одной ночи, забудьте про классическую схему Выгрузить в DT -> Загрузить из DT. Начиная с версии платформы 8.3.23, разработчики 1С предоставили администраторам мощный инструмент прямой репликации баз данных с помощью утилиты автономного сервера ibcmd.
Этот способ позволяет переносить данные напрямую из одной СУБД в другую минуя создание промежуточных тяжелых файлов на диске. Процесс происходит значительно быстрее и стабильнее.
Рассмотрим пошагово схему миграции с использованием утилиты ibcmd:
ibcmd infobase replicate --src-db-dbms=MSSQLServer --src-db-server=SourceSQLServer --src-db-name=UT103_Prod --src-db-user=sa --src-db-pwd=MySqlPassword --target-db-dbms=PostgreSQL --target-db-server=PostgreServer --target-db-name=UT103_New --target-db-user=postgres --target-db-pwd=PostgrePassword
Проанализируем параметры этой команды подробнее:
--src-db-dbms — тип исходной системы управления базами данных (в нашем случае MSSQLServer).--src-db-server — имя или IP-адрес исходного SQL-сервера.--src-db-name — имя исходной базы данных в MS SQL.--target-db-dbms — тип целевой СУБД (указываем PostgreSQL).--target-db-server — адрес нового сервера PostgreSQL.--target-db-name — имя создаваемой базы данных на новом сервере.Использование утилиты ibcmd позволяет обойти большинство ограничений формата .dt, связанных с выделением памяти на клиенте, и перенести базу объемом 14 Гб в разы быстрее, полностью уложившись в технологическое окно ночной миграции.