La façon dont je l'ai fait dans quelques projets consiste à utiliser deux copies de la table dans différents schémas. Donc quelque chose comme :
CREATE SCHEMA fake WITH AUTHORIZATION dbo;
CREATE SCHEMA standby WITH AUTHORIZATION dbo;
GO
CREATE TABLE dbo.mySummary(<...columns...>);
CREATE TABLE fake.mySummary(<...columns...>);
GO
Créez maintenant une procédure stockée qui tronque et remplit à nouveau la fausse table, puis, dans une transaction, déplacez les objets entre les schémas.
CREATE PROCEDURE dbo.SwapInSummary
AS
BEGIN
SET NOCOUNT ON;
TRUNCATE TABLE fake.mySummary;
INSERT fake.mySummary(<...columns...>)
SELECT <expensive query>;
BEGIN TRANSACTION;
ALTER SCHEMA standby TRANSFER dbo.mySummary;
ALTER SCHEMA dbo TRANSFER fake.mySummary;
ALTER SCHEMA fake TRANSFER standby.mySummary;
COMMIT TRANSACTION;
END
GO
Il s'agit probablement du temps le plus court que vous pouvez faire attendre aux utilisateurs pour que les nouvelles données soient actualisées et sans les interrompre au milieu d'une lecture. (Il existe de nombreux problèmes associés à NOLOCK qui en font une alternative moins souhaitable, même s'il est vrai qu'il est facile à coder.) Pour des raisons de brièveté/clarté, j'ai omis la gestion des erreurs, etc. scripts pour synchroniser vos bases de données, assurez-vous de nommer les contraintes, les index, etc. de la même manière sur les deux tables, sinon vous serez désynchronisé la moitié du temps. À la fin de la procédure, vous pouvez TRUNCATE la nouvelle table fake.MySummary, mais si vous avez de l'espace, j'aime y laisser les données afin de pouvoir toujours comparer à la version précédente.
Avant SQL Server 2005, j'utilisais sp_rename dans la transaction pour accomplir exactement la même chose, mais depuis que je fais cela dans un travail, j'étais content de passer aux schémas, car lorsque je l'ai fait, l'avertissement non supprimable de sp_rename a cessé de se remplir mes journaux d'historique de l'Agent SQL Server.
