Otra solución es usar esquemas múltiples y jugar al cambio. Solo prefiero este método porque solía hacer este truco en un trabajo, y el mensaje de advertencia sobre el cambio de nombre de un objeto (que no se puede suprimir) estaba llenando mis registros de historial. Básicamente, necesita dos esquemas adicionales (uno para almacenar una copia de la tabla temporalmente y otro para almacenar la copia en caché).
CREATE SCHEMA cache AUTHORIZATION dbo;
CREATE SCHEMA hold AUTHORIZATION dbo;
Ahora, cree una mímica de la tabla en el esquema de caché:
SELECT * INTO cache.table FROM dbo.table WHERE 1 = 0;
-- then create any indexes etc.
Ahora, cuando llegue el momento de actualizar los datos:
-- step 1:
TRUNCATE TABLE cache.table;
-- (if you need to maintain FKs you may need to delete)
INSERT INTO cache.table SELECT ...
-- step 2:
-- this transaction will be almost instantaneous,
-- since it is a metadata operation only:
BEGIN TRANSACTION;
ALTER SCHEMA hold TRANSFER dbo.table;
ALTER SCHEMA dbo TRANSFER cache.table;
ALTER SCHEMA cache TRANSFER hold.table;
COMMIT TRANSACTION;
Teóricamente, podría mover la última transferencia fuera de la transacción, porque los usuarios podrían comience a consultar la nueva copia de dbo.table después de la segunda transferencia, pero como dije, esto es casi instantáneo, por lo que me sorprendería si ve alguna diferencia en la concurrencia.
También puede truncar opcionalmente cache.table nuevamente aquí, pero siempre lo mantuve poblado para poder comparar los cambios de datos o solucionar problemas si algo salía mal. Dependiendo de cuánto tiempo tome el paso 1, puede ser más rápido realizar las transferencias a la inversa que volver a llenar desde cero.
Al igual que cambiar el nombre, puede obtener cosas raras de este proceso, como que las estadísticas se pierdan a medida que se mueven con la tabla real, no se quedan con el nombre. Y al igual que cambiar el nombre, querrá probar esto y quizás quiera jugar con los niveles de aislamiento, p. RCSI para acceder a la tabla de informes.
