A seconda della modifica che stai apportando, a volte può essere più semplice richiedere una finestra di manutenzione. Durante quella finestra (in cui nessuno dovrebbe essere in grado di modificare i dati nella tabella) puoi:
- elimina tutti gli indici/vincoli che puntano alla vecchia colonna e disabilita i trigger
- aggiungi un nuovo annullabile colonna con il nuovo tipo di dati (anche se deve essere NOT NULL)
- aggiorna la nuova colonna impostandola uguale al valore della vecchia colonna (e puoi farlo in blocchi di singole transazioni (ad esempio, interessando 10000 righe alla volta usando
UPDATE TOP (10000) ... SET newcol = oldcol WHERE newcol IS NULL) e con CHECKPOINT per evitare di sovraccaricare il tuo log) - al termine degli aggiornamenti, elimina la vecchia colonna
- rinominare la nuova colonna (e aggiungere un vincolo NOT NULL se appropriato)
- ricostruisci gli indici e aggiorna le statistiche
La chiave qui è che ti consente di eseguire l'aggiornamento in modo incrementale nel passaggio 3, cosa che non puoi eseguire in un singolo comando ALTER TABLE.
Ciò presuppone che la colonna non svolga un ruolo importante nell'integrità dei dati:se è coinvolta in una serie di relazioni di chiavi esterne, sono necessari più passaggi.
MODIFICA
Inoltre, e mi chiedo solo ad alta voce, non ho fatto alcun test per questo (ma l'ho aggiunto all'elenco). Mi chiedo se la compressione pagina + riga possa aiutare qui? Se si modifica un INT in un BIGINT, con la compressione in atto SQL Server dovrebbe comunque trattare tutti i valori come se rientrassero ancora in un INT. Ancora una volta, non ho testato se questo renderebbe un alter più veloce o più lento, o quanto tempo ci vorrebbe per aggiungere la compressione in primo luogo. Basta buttarlo là fuori.
