Как я понял, человеку важно, чтобы база не лочилась, а она так не лочится. В отличии от дроп индекс вис мув ту.

Но будет простой ... на время переименования объектов

Плюс вьюха ... не пробовал инсертить во вьюхи )))

Плюс ограничение праймари ки
Может, у них на жтом логика построена
Гопнег, ау )))

Ну это зависит от доступа к данным, у нас через хранимки нам было проще. А так, селект месяца данных во временную таблицу на партишне новом, тут да, апдейт этого месяца подвисает. Констрейт по полю секционирования, свитч партишна в новую таблицу и ладушки

Не, с малым количеством точек входа никаких проблем, да
У нас так же

Есть вариан платный по месту на диске =)
У нас была таблица с 20кк, но оч тяжелая, было поле max. И таблица весела 1-2 Тб.
Нужно было уникальное поле добавить / сжать.
Основная идея работа порциями.
Какое время простоя у тебя?
В твоем случае я бы сделал таблицу рядом с правильным индексом(я бы еще и секционирование сделал мб) туда бы я переливал данные по чуть-чуть итерационно(в момент вставки я бы и делал преобразования нужные), и проверял бы на каждом шаге, что лог не переполнился.
По завершению процесса, когда не перелитых данных останется мало - делаешь транзакцию с блокировкой основной таблицы и переливаешь остаток в новую. Переименовываешь. Комитишь.
Проблему с логом бы я решал - либо чек поинтами либо бекапированием периодическим.
Те у тебя будет долгий трансфер данных. И нужно место на 440кк.
Но зато простой небольшой. Минимальный.
Если есть вариант простоя, а места мало , то я бы вместо трансфера делал делит порциями (естественно фильтры по кластерному индексу) и из делита сразу вставку новую

Нужно посчитать размер порции, который бы не выжрал бы логи сразу и частоту бекапирования. Это если можно лить в табл рядом.
Если через удаление и простоя не мб , то тогда нужно, чтобы не было эскалации блокировок. Я хз, как-то вроде можно ее отключить. Либо по 5000 строк

Вариант с добавлением поля, апдейтом, дропом индекса и ребилдом тоже можно сделать итерационно, а индексы редилдить с остановкой (если версия новая)
Но тогда все это будет долго. Тк у тебя хер пойми что будет на страницах данных после апдейта. Данные будут разбросаны по диску(это если ты оставил место для доставления поля, если нет, то это перезапись на новые страницы) и построить по ним потом индекс скулю будет не просто.
Лучше сразу лить на новые страница, которые будут алрцироваться под "новые данные" последовательно.

Ты как будто умный, ебана

Я откуда знаю?
Я подготовил решение с дропом пк
Но если им надо, пущай UX сначала сделают

Был бы умным, знал бы че за магия с мув ту происходит, а я хз

Принято

Из того, что пробовал, это самое быстрое получается. Режим восстановления базы в Симпл перевёл?)

Доброго времени. Вопрос есть: Есть 3 таблицы, в одну из них ("Главную") - идёт два внешних ключа (по одному с двух других таблиц). те две таблицы заполнил, а как быть с полями в этой Главной (полями, которые идут как Внешний ключ)

FK использовать обязательно (лаба), заполнять - само собой понятно. Не могу понять пока, каким образом "вытянуть" эти FK данные (с их родных таблиц) в эту на эти поля (то-бишь помимо вытягивания, еще как обозначать остальные поля, для которых Главная таблица - родная)

типа: Р - Родное поле с данными, ВК - втор. ключ. И у меня идёт так (Р, ВК, Р, ВК, Р, Р)

а скока у тебя денег на решение твоей лабы?

кекс, ну с такими вопросами - подход понятен