Beroende på vilken förändring du gör kan det ibland vara lättare att ta ett underhållsfönster. Under det fönstret (där ingen ska kunna ändra data i tabellen) kan du:
- släpp alla index/begränsningar som pekar på den gamla kolumnen och inaktivera triggers
- lägg till en ny nullbar kolumn med den nya datatypen (även om den är avsedd att INTE vara NULL)
- uppdatera den nya kolumnen genom att ställa in den lika med den gamla kolumnens värde (och du kan göra detta i delar av enskilda transaktioner (säg, påverka 10 000 rader åt gången med
UPDATE TOP (10000) ... SET newcol = oldcol WHERE newcol IS NULL) och med CHECKPOINT för att undvika att din logg överskrids) - när alla uppdateringar är klara, släpp den gamla kolumnen
- byt namn på den nya kolumnen (och lägg till en NOT NULL-begränsning om så är lämpligt)
- bygga om index och uppdatera statistik
Nyckeln här är att den låter dig utföra uppdateringen stegvis i steg 3, vilket du inte kan göra med ett enda ALTER TABLE-kommando.
Detta förutsätter att kolumnen inte spelar någon större roll i dataintegriteten - om den är involverad i ett gäng främmande nyckelrelationer finns det fler steg.
REDIGERA
Dessutom, och bara undrar högt, jag har inte gjort några tester för detta (men lagt till det i listan). Jag undrar om komprimering av sida + rad skulle hjälpa här? Om du ändrar en INT till en BIGINT, med komprimering på plats, bör SQL Server fortfarande behandla alla värden som om de fortfarande passar in i en INT. Återigen, jag har inte testat om detta skulle göra en förändring snabbare eller långsammare, eller hur mycket längre tid det skulle ta att lägga till komprimering i första hand. Det är bara att kasta ut det där.