Afhængigt af hvilken ændring du laver, kan det nogle gange være nemmere at tage et vedligeholdelsesvindue. I det vindue (hvor ingen skal kunne ændre dataene i tabellen) kan du:
- slip alle indekser/begrænsninger, der peger på den gamle kolonne, og deaktiver triggere
- tilføj en ny nullbar kolonne med den nye datatype (selvom det er meningen, at den IKKE skal være NULL)
- opdater den nye kolonne ved at sætte den lig med den gamle kolonnes værdi (og du kan gøre dette i bidder af individuelle transaktioner (f.eks. påvirke 10000 rækker ad gangen ved at bruge
UPDATE TOP (10000) ... SET newcol = oldcol WHERE newcol IS NULL) og med CHECKPOINT for at undgå at overskride din log) - når alle opdateringerne er færdige, skal du slippe den gamle kolonne
- omdøb den nye kolonne (og tilføj en NOT NULL-begrænsning, hvis det er relevant)
- genopbyg indekser og opdater statistik
Nøglen her er, at den giver dig mulighed for at udføre opdateringen trinvist i trin 3, hvilket du ikke kan gøre i en enkelt ALTER TABLE-kommando.
Dette forudsætter, at kolonnen ikke spiller en større rolle i dataintegritet - hvis den er involveret i en flok udenlandske nøglerelationer, er der flere trin.
REDIGER
Også, og bare undrende højt, har jeg ikke lavet nogen test for dette (men tilføjet det til listen). Jeg spekulerer på, om side + række komprimering ville hjælpe her? Hvis du ændrer en INT til en BIGINT, med komprimering på plads bør SQL Server stadig behandle alle værdier, som om de stadig passer ind i en INT. Igen, jeg har ikke testet, om dette ville gøre en ændring hurtigere eller langsommere, eller hvor meget længere tid det ville tage at tilføje komprimering i første omgang. Bare smider det derud.