дядьки. если бы вам пришлось поменять int на bigint у колонки в таблице с 400кк строками как бы вы поступили? как обычно надо быстро и бесплатно для лога.
я добавляю новую колонку, заполняю ее, дропаю ключи, переименовываю колонки, удаляю старую, возвращаю ключи. но все работает ппц как долго) есть варианты исчо?)

Да, в следующий раз юзай гуиды

нет уж спасибо

Ну ты могешь сделать простой create table без пк и кластерного индекса.
И глянуть в sys.indexes. там какой-то отдельный тип индекса для кучи говна - 0 что ли.
А потом создай на этой таблице кластерный индекс. Если память не изменяет, то 0й индекс пропадет и появится индекс с типом 1 - клатерный

кстати, если дропать типа нельзя, то возможно имелось ввиду использовать вот это :)
CREATE UNIQUE CLUSTERED INDEX ptc ON dbo.pt(pc, Id) WITH(DROP_EXISTING = ON)ON ps1(pc) ;

Низя так сделать, т.к. от этого кластерного индекса зависит пк

Т.е. сначала констрэинт

И в условии (мне так аажется) неспроста написано про то, что перестроение в лоб занимает больше суток. Я думаю, это как раз про это и говлрится

ну я ж условия не видел - видел только дроп контсрайт виз мув ту

Переливка варчаров максов

We have a large table (containing a large number of records and occupying a large amount of data) that stores transactions.
CREATE TABLE [Transactions] (
 [TransactionID] UNIQUEIDENTIFIER NOT NULL PRIMARY KEY,
 [TimeStamp] DATETIME2 NOT NULL,
 [ClientID] INT NOT NULL,
 [ClientTransactionID] NVARCHAR (20),
 [Sum] MONEY,
 [SomeOtherData] NVARCHAR (MAX)
 );

It is necessary to break down this table into partitions by the [TimeStamp] field, broken down by months. The [TransactionID] field should remain as Primary Key.
Data older than 1.5 years can be stored in one partition (access to them will be very rare).

The operation should go "seamlessly" - with minimal database downtime.
Direct rebuild of the table will take more than a day and not acceptable.

The result of the task should be a plan for the transition to partitioned storage, a list of the necessary technologies / services, as well as the necessary code to complete this plan.

но да, как-то у меня сутки табличка партиционировалсь :)

у нас было как:
большая таблица
мало процедур, которые селектят оттуда данные.
1) созали новую таблицу, сделали партишн функцию с одной точкой начиная со следующего месяца. Сделали схему с двумя группами по этой функции
2) перенаправили инсёрт сразу в новую таблицу
3) заапендили селект/апдейт/делит хранимки апдейтом делитом селектом из двух таблиц. Т.к. это транзакции, то вряд ли там что-то апдейтится в старых данных
4)  ну и потом из старой таблицу выбирали помесячно данные в темповую таблицу и шарашили в новую таблицу через слайсинг виндоу

3. Апдейтится, я уточнял(

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

всегда можно ебануть вьюшку и триггеры

Нинжи! Поделитесь скриптами обслуживания колумнсторов

а что с integration services нельзя работать через sql login, нужна виндовая учётка?https://docs.microsoft.com/en-us/sql/integration-services/grant-permissions-to-integration-services-service?view=sql-server-2014