Sättet jag har gjort detta i några projekt är att använda två kopior av tabellen i olika scheman. Så något 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
Skapa nu en lagrad procedur som trunkerar och fyller på den falska tabellen, och flytta sedan objekten mellan scheman 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
Detta är förmodligen den kortaste tid du kan få användare att vänta på att de nya uppgifterna ska uppdateras och utan att störa dem mitt under en läsning. (Det finns många problem förknippade med NOLOCK som gör det till ett mindre önskvärt alternativ, men det är visserligen lätt att koda.) För korthetens skull/tydlighetens skull har jag utelämnat felhantering etc., och jag bör också påpeka att om du använder skript för att synkronisera dina databaser, se till att du namnger begränsningar, index etc. samma på båda tabellerna, annars kommer du att vara osynkroniserad hälften av tiden. I slutet av proceduren kan du TRUNKERA den nya falska tabellen. MySummary-tabellen, men om du har utrymme vill jag lämna data där så att jag alltid kan jämföra med den tidigare versionen.
Innan SQL Server 2005 använde jag sp_rename inuti transaktionen för att åstadkomma exakt samma sak, men eftersom jag gör detta i ett jobb, var jag glad över att byta till scheman, för när jag gjorde det slutade varningen från sp_rename att inte kunna undertryckas fyllas upp mina SQL Server Agent-historikloggar.