Cambiar el esquema sin romper aplicaciones activas

Una migración puede terminar correctamente mientras la aplicación falla. Durante un despliegue gradual, versiones viejas y nuevas comparten la base. Renombrar una columna o exigir inmediatamente un campo nuevo puede romper procesos todavía activos. La unidad de cambio es el contrato entre código y datos.

Ampliar antes de exigir

Añada estructura compatible, despliegue código que comprenda ambas formas, complete históricos, valide y retire después el contrato anterior. Una columna nullable suele ser un buen inicio, pero requiere bloqueos de esquema. Un cambio pequeño no garantiza ausencia de bloqueos.

El ejercicio utiliza una tabla temporal pequeña. Ejecute bloques en orden. NOT NULL representa una validación y liberación separadas, no una acción automática después de añadir la columna.

CREATE TABLE #Orders(OrderId int PRIMARY KEY, Amount decimal(12,2));
INSERT #Orders VALUES(1,10),(2,20);
ALTER TABLE #Orders ADD CurrencyCode char(3) NULL;

UPDATE #Orders SET CurrencyCode='USD' WHERE CurrencyCode IS NULL;
SELECT OrderId,Amount,CurrencyCode FROM #Orders ORDER BY OrderId;

IF EXISTS(SELECT 1 FROM #Orders WHERE CurrencyCode IS NULL)
    THROW 50000, 'Backfill is incomplete.', 1;
ALTER TABLE #Orders ALTER COLUMN CurrencyCode char(3) NOT NULL;

En producción, defina cómo nuevas escrituras rellenan CurrencyCode antes de completar históricos. USD solo es correcto por el significado declarado del ejemplo. Un default cómodo no descubre la moneda real de órdenes antiguas. Los desconocidos requieren conciliación, no valores inventados.

Coordinar escrituras concurrentes

Cuando coexisten representaciones, indique cuál manda en cada fase. Las escrituras dobles deben ser atómicas o reconciliadas. Un fallo puede actualizar únicamente una. Una lectura alternativa puede mantener disponibilidad mientras oculta divergencia; mida desacuerdos antes de cambiar lectores.

En tablas grandes, use lotes reanudables con rango estable de claves. El predicado no debe sobrescribir valores nuevos de la aplicación. Confirme progreso junto con cambios cuando deba sobrevivir a fallos. Limitar filas modificadas no limita automáticamente lecturas o log generado por índices y desencadenadores.

Los cambios de esquema pueden esperar detrás de transacciones largas. Establezca timeout y reintentos apropiados, revise bloqueadores y no inicie otra migración mientras la anterior sigue esperando. Opciones online dependen de operación, versión y edición; no significan ausencia completa de bloqueos.

Definir hasta dónde se puede volver

Antes de eliminar, confirme que ninguna versión soportada, informe, tarea, exportación o SQL dinámico requiere el campo antiguo. Los catálogos ayudan, pero no descubren todas las cadenas construidas externamente. Combine inventario, ejecución observada y pruebas con versiones mezcladas.

Revertir código es sencillo solo mientras la base conserva su contrato. Si nuevas escrituras contienen valores imposibles de representar anteriormente, retroceder puede perder significado aunque la columna vieja siga presente. Documente el último paso reversible y recuperación sin pérdida para etapas posteriores.

Valide valores transformados, restricciones y operaciones representativas de ambas versiones, no solo cantidades. Interrumpa el relleno y pruebe continuación. Conserve identificadores y estado para distinguir pasos aplicados de fallidos.

La eliminación final merece otra liberación después de demostrar estabilidad. Pruebe también un proceso antiguo que permanezca activo durante toda la transición, porque reiniciar todos los servicios en laboratorio oculta problemas de coexistencia. Cada etapa debe explicar quién lee, quién escribe, cuál dato manda y qué reversión sigue siendo segura.

Incluya tareas nocturnas y exportaciones poco frecuentes en el periodo de observación antes de retirar columnas antiguas.

Referencias técnicas: Microsoft Learn: ALTER TABLE · Microsoft Learn: Dependency metadata.