В зависимост от промяната, която правите, понякога може да е по-лесно да вземете прозорец за поддръжка. По време на този прозорец (където никой не трябва да може да променя данните в таблицата) можете:
- изхвърлете всички индекси/ограничения, сочещи към старата колона, и деактивирайте задействанията
- добавете нов нулеви колона с новия тип данни (дори ако е предназначена да НЕ е NULL)
- актуализирайте новата колона, като я зададете равна на стойността на старата колона (и можете да направите това на части от отделни транзакции (да речем, засягайки 10 000 реда наведнъж, като използвате
UPDATE TOP (10000) ... SET newcol = oldcol WHERE newcol IS NULL) и с CHECKPOINT, за да избегнете прехвърляне на вашия дневник) - след като всички актуализации са готови, махнете старата колона
- преименувайте новата колона (и добавете ограничение NOT NULL, ако е подходящо)
- изградете отново индекси и актуализирайте статистиката
Ключът тук е, че ви позволява да извършвате актуализацията постепенно в стъпка 3, което не можете да направите с една команда ALTER TABLE.
Това предполага, че колоната не играе основна роля за целостта на данните - ако е замесена в куп връзки с външни ключове, има повече стъпки.
РЕДАКТИРАНЕ
Освен това и просто се чудя на глас, не съм правил никакви тестове за това (но го добавям към списъка). Чудя се дали компресирането на страница + ред ще помогне тук? Ако промените INT на BIGINT, с компресия SQL Server трябва да третира всички стойности така, сякаш все още се вписват в INT. Отново, не съм тествал дали това ще направи промяната по-бърза или по-бавна или колко повече време ще отнеме, за да се добави компресия на първо място. Просто го изхвърлям.
