Dependiendo del cambio que esté realizando, a veces puede ser más fácil tomar una ventana de mantenimiento. Durante esa ventana (donde nadie debería poder cambiar los datos en la tabla) puede:
- elimine cualquier índice/restricción que apunte a la columna anterior y deshabilite los disparadores
- añadir un nuevo anulable columna con el nuevo tipo de datos (incluso si se supone que NO es NULO)
- actualice la nueva columna configurándola igual al valor de la columna anterior (y puede hacer esto en fragmentos de transacciones individuales (digamos, afectando 10000 filas a la vez usando
UPDATE TOP (10000) ... SET newcol = oldcol WHERE newcol IS NULL) y con CHECKPOINT para evitar sobrecargar su registro) - una vez que se hayan realizado todas las actualizaciones, suelte la columna anterior
- cambie el nombre de la nueva columna (y agregue una restricción NOT NULL si corresponde)
- reconstruir índices y actualizar estadísticas
La clave aquí es que le permite realizar la actualización de forma incremental en el paso 3, lo que no puede hacer con un solo comando ALTER TABLE.
Esto supone que la columna no juega un papel importante en la integridad de los datos; si está involucrada en un montón de relaciones de clave externa, hay más pasos.
EDITAR
Además, y solo me preguntaba en voz alta, no he hecho ninguna prueba para esto (pero lo agregué a la lista). Me pregunto si la compresión de página + fila ayudaría aquí. Si cambia un INT a BIGINT, con la compresión en su lugar, SQL Server aún debe tratar todos los valores como si todavía encajaran en un INT. Una vez más, no he probado si esto haría que una modificación fuera más rápida o más lenta, o cuánto tiempo llevaría agregar compresión en primer lugar. Solo tíralo por ahí.
