При обновление бд из конфигуратора процесс длиться очень долго, идет версионирование объектов уже больше часа? Как бороться?

Наверное, реструктуризация таблицы с версиями?
На будущее: не хранить все версии, настроить очистку по периоду.

Если база большая, то смотреть в сторону:
https://wonderland.v8.1c.ru/blog/optimizatsiya-restrukturizatsii-bazy-dannykh/

(1) за обычно проходит реструктуризация таблицы с версиями ? пара часов может это нормально, когда миллионы записе?

(2) у кого то и сутки базы реструктуризятся...

Как бороться с долгой реструктуризацией больших таблиц?

платформа корп помогает ускорить?

При реструктуризации v1 1С создает таблицу - копию с измененными колонками и кидает в нее все строки из старой таблицы. Епстественно, что ваше версионирование содержит не нежные GIUD-ы, а толстые XML тексты всех ваших объектов и будет это работать крайне долго. Ждите или пробуйте (1)

(5) Нет.

А чему там обновляться, версии ведь это простой регистр сведений с блобом внутри?

за какой период храните версии объектов на млн записей в регистре версионирования?

(9) от потребностей очевидно зависит

(2) Так от сервера зависит, на некоторых пара часов это только cf накатить)

(6) >версионирование содержит не нежные GIUD-ы, а толстые XML тексты всех ваших объектов
Там хитро немного сделано, хранятся только измененные версии. Если несколько раз нажать записать без изменения реквизитов, то просто добавляется запись без XML в хранилище.

(11) структура регистра отличается от типового?

(11)
https://youtu.be/7eiIR7ThAW8?si=i2ivXDLV3EDcf9SF

(13) Кста, да.

устаревшие версии это какой признак в рс версии объектов?

(15) срезпоследних наверно?

хочу отобрать устаревшие и почистить sql truncate

(12) Это в типовом так сделано.

Откройте в пользовательском через все функции в пользовательском.
Реквизиты: ЕстьДанныеВерсии, РазмерДанных, КонтрольнаяСумма.
Если размер 18 и есть данные версии = Ложь, то в регистре сведений физически ничего не записано. По контрольным суммам определяется нужно записывать данные или нет.