Добавили регистр накопления в конфигурацию; база огромная; реструктуризация займет недели. Что можно сделать? Как компании проводят обновления в таких случаях?
---
Добавление нового регистра не должно проходить долго. При изменении существующего, который содержит много записей тут да, реструктуризация занимает много времени.
---
попробуйте на копии базы , если есть возможность.

вы же не будете делать это на боевой (рабочей) .

даже если и есть желание.
---
Ну конечно на копии делали. На копии оттестировано, теперь залить надо в боевую. Проблема в том, что копия весит 200 ГБ, а продакшн - 1 ТБ+. И суть даже не в реструктуризации, а в том, что когда определяешь для регистра, какие документы движения будут в нем использоваться, запускается переиндексация этих документов с добавлением движений по этим регистрам (даже если их пока нет). Соответственно новый регистр + добавленные регистраторы в этот регистр = с*кс с обновлением из-за индексации.

Тестируем сейчас updatedbcfg v2, прирост виден на базе в 200 ГБ, будем пробовать на боевой.
---
успехов вам !
---
Добавление нового регистра не должно проходить долго. При изменении существующего, который содержит много записей тут да, реструктуризация занимает много времени.
---
фото выложите.
нет названия конфигурации - база огромная - это же база
конфигуратор - это же не база

вы что делали реструктуризацию , что решили о неделе ?
---
при чем тут конфигуратор? Изменение структуры ведет к реструктуризации вне зависимости от конфигурации.
---
при добавлении нового регистра нечего реструктурировать
---
регистр внесен в конфигурацию или в платформу ?
5минут и вся реструктуризация.
вопрос причем здесь неделя ?
---
в платформу? Что, простите?
Неделя имелась ввиду у автора, что большие таблицы в десятки и сотни гигабайт реструктуризироваться могут неделю.
---
еще раз: при ДОБАВЛЕНИИ нового объекта реструктуризации не будет от слова совсем.
Реструктуризация будет, если ИЗМЕНИЛИ существующий регистр, в котором есть записи.

Если записей действительно много, то быстрее будет создать новый регистр, начать работать с ним и в фоне переносить в него данные из "старого" регистра, либо использовать данные "старого" регистра как исторические.
---
действительно. Сомневался, не возникнет ли реструктуризации на регистраторе, смоделировал, не возникло. Вы правы
---
Последнее время работаю в основном с большими базами (пол терабайта). Самая долгая реструктуризация которую видел занимала 6-8 часов, если резать прямо по тяжелому регистру. Это укладывалось в ночь или выходной день.
---
полтерабайта еще не предел. 200Гб может занимать одна только таблица этой базы. И ее реструктуризация уходит в небеса. К тому же чаще всего у нагруженных систем режим работы 24/7 и для бизнеса критичны даже 3-4 часа, не то, что целый день
---
Возможно вы и правы, но фактически я на своей практике с такой реструктуризацией не встречался. Не представляю просто, что можно хранить в таком здоровом регистре.
---
данные о товарообороте, например. Данные о продажах
---
а вы попробуйте после вашего моделирования нажать F5

что произойдет ?

человек переживает . что это будет долго.
---
тут и нажимать нечего, если обновление прошло полностью, то при нажатии на Ф5 запустится отладка. Это даже без нажатия очевидно
---
а клинт запустится ?

думать может вам и не надо.
возьмите 10гб базу, внесите регистр в конфигурацию.сделайте изменения и запустите платформу.

и ждите.сколько это будет времени ?
---
Автору могу посоветовать только проверить, какая таблица реструктуризируется. Если это документы, в которых есть табличные части, то можно откинуть ТЧ на СУБД, создав их пустые копии, после реструктуризации вернуть на место, дропнув пустые
---
не данных , кто делал

У регистра накопления есть
Измерения, Ресурсы, Реквизиты и Стандартные реквизиты.
вид регистра накопления — обороты и остатки.

никаких данных , что можно думать.

а вопрос мой к вам был в том , что изменения вносятся через конфигуратор. а платформа - чтобы было понятно , что вносятся изменения через конфигурацию.
---
у меня копия равна продакшену
иначе как тестировать ?
что вам мешает сделать копию с боевой базы ?
---
Есть копия. Но как это относится к сути вопроса?
---
1.Подозреваю, что вы заливаете в базу картинки, что в принципе не приемлемо для больших баз SQL.
2. Если все же 1 терабайт - это реальные данные, которые нельзя подрезать - то перенестите табличные части в другую базу. SQL скрипт это делает примерно за 12 часов. Далее наказываете свои регистры. 1 час
И вернете назад свои табличные части еще 12 часов
---
Да, изображения так же хранятся в базе. Спасибо за совет.