W zależności od tego, jakie zmiany wprowadzasz, czasami łatwiej jest zrobić okres konserwacji. W tym oknie (w którym nikt nie powinien mieć możliwości zmiany danych w tabeli) możesz:
- upuść wszystkie indeksy/ograniczenia wskazujące na starą kolumnę i wyłącz wyzwalacze
- dodaj nowy nullable kolumna z nowym typem danych (nawet jeśli nie ma być NULL)
- zaktualizuj nową kolumnę ustawiając ją na równą wartości starej kolumny (możesz to zrobić w kawałkach pojedynczych transakcji (powiedzmy, wpływając na 10000 wierszy na raz za pomocą
UPDATE TOP (10000) ... SET newcol = oldcol WHERE newcol IS NULL) i z CHECKPOINT, aby uniknąć przekroczenia dziennika) - po zakończeniu aktualizacji usuń starą kolumnę
- zmień nazwę nowej kolumny (i dodaj ograniczenie NOT NULL, jeśli to konieczne)
- odbuduj indeksy i aktualizuj statystyki
Kluczem jest tutaj to, że umożliwia on wykonywanie aktualizacji przyrostowo w kroku 3, czego nie można zrobić w jednym poleceniu ALTER TABLE.
Zakłada to, że kolumna nie odgrywa głównej roli w integralności danych - jeśli jest zaangażowana w szereg relacji kluczy obcych, jest więcej kroków.
EDYTUJ
Poza tym, głośno się zastanawiam, nie przeprowadziłem żadnych testów tego (ale dodałem to do listy). Zastanawiam się, czy pomogłaby tutaj kompresja strona + wiersz? Jeśli zmienisz INT na BIGINT, przy włączonej kompresji SQL Server powinien nadal traktować wszystkie wartości tak, jakby nadal mieściły się w INT. Ponownie, nie testowałem, czy to sprawiłoby, że zmiana byłaby szybsza czy wolniejsza, ani też ile czasu zajęłoby dodanie kompresji w pierwszej kolejności. Po prostu wyrzuć to.
