V závislosti na tom, jakou změnu provádíte, může být někdy jednodušší provést údržbu. Během tohoto okna (kde by nikdo neměl mít možnost změnit data v tabulce) můžete:
- zrušte všechny indexy/omezení ukazující na starý sloupec a deaktivujte spouštěče
- přidat novou možnost null sloupec s novým datovým typem (i když má být NOT NULL)
- aktualizujte nový sloupec tak, aby se rovnal hodnotě starého sloupce (a můžete to udělat po částech jednotlivých transakcí (řekněme, ovlivnění 10 000 řádků najednou pomocí
UPDATE TOP (10000) ... SET newcol = oldcol WHERE newcol IS NULL) a pomocí CHECKPOINT, aby nedošlo k překročení vašeho protokolu) - Po dokončení všech aktualizací starý sloupec vypusťte
- přejmenujte nový sloupec (a případně přidejte omezení NOT NULL)
- obnovit indexy a aktualizovat statistiky
Klíčem je zde to, že vám umožňuje provádět aktualizaci postupně v kroku 3, což nelze provést jediným příkazem ALTER TABLE.
To předpokládá, že sloupec nehraje hlavní roli v integritě dat – pokud je zapojen do hromady vztahů s cizím klíčem, existuje více kroků.
UPRAVIT
Také, a jen se nahlas divím, jsem pro to neprovedl žádné testování (ale přidal jsem to do seznamu). Zajímalo by mě, jestli by zde pomohla komprese stránky + řádků? Pokud změníte INT na BIGINT, s kompresí by měl SQL Server stále zacházet se všemi hodnotami, jako by se stále vešly do INT. Opět jsem netestoval, zda by to zrychlilo nebo zpomalilo změnu nebo jak dlouho by trvalo přidání komprese na prvním místě. Prostě to tam hodím.