Den måde, jeg har gjort dette på i nogle få projekter, er at bruge to kopier af tabellen i forskellige skemaer. Så noget i stil med:
CREATE SCHEMA fake WITH AUTHORIZATION dbo;
CREATE SCHEMA standby WITH AUTHORIZATION dbo;
GO
CREATE TABLE dbo.mySummary(<...columns...>);
CREATE TABLE fake.mySummary(<...columns...>);
GO
Opret nu en lagret procedure, der afkorter og genudfylder den falske tabel, og flyt derefter objekterne mellem skemaer i en transaktion.
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
Dette er sandsynligvis den korteste tid, du kan få brugere til at vente på, at de nye data bliver opdateret og uden at forstyrre dem midt i en læsning. (Der er mange problemer forbundet med NOLOCK, der gør det til et mindre ønskværdigt alternativ, men det er ganske vist nemt at kode.) For kortheds skyld/klarheds skyld har jeg udeladt fejlhåndtering osv., og jeg skal også påpege, at hvis du bruger scripts til at synkronisere dine databaser, sørg for at navngive begrænsninger, indekser osv. det samme på begge tabeller, ellers vil du være ude af sync halvdelen af tiden. I slutningen af proceduren kan du TRUNCATE den nye falske.MySummary-tabel, men hvis du har plads, vil jeg gerne efterlade dataene der, så jeg altid kan sammenligne med den tidligere version.
Før SQL Server 2005 brugte jeg sp_rename inde i transaktionen for at opnå nøjagtig det samme, men da jeg gør dette i et job, var jeg glad for at skifte til skemaer, for da jeg gjorde det, holdt advarslen fra sp_rename op med at fylde. op mine SQL Server Agent-historiklogfiler.