Wat is de beste manier om een ​​rollup-tabel onder belasting te vernieuwen?

De manier waarop ik dit in een paar projecten heb gedaan, is door twee exemplaren van de tabel in verschillende schema's te gebruiken. Dus zoiets als:

CREATE SCHEMA fake WITH AUTHORIZATION dbo;
CREATE SCHEMA standby WITH AUTHORIZATION dbo;
GO

CREATE TABLE dbo.mySummary(<...columns...>);

CREATE TABLE fake.mySummary(<...columns...>);
GO

Maak nu een opgeslagen procedure die de neptabel afkapt en opnieuw vult, en verplaats vervolgens in een transactie de objecten tussen schema's.

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

Dit is waarschijnlijk ongeveer de kortste tijd die u gebruikers kunt laten wachten tot de nieuwe gegevens zijn vernieuwd en zonder ze tijdens het lezen te verstoren. (Er zijn veel problemen met NOLOCK die het een minder wenselijk alternatief maken, hoewel het weliswaar gemakkelijk te coderen is.) Voor de duidelijkheid heb ik foutafhandeling enz. weggelaten, en ik moet er ook op wijzen dat als u scripts om uw databases te synchroniseren, zorg ervoor dat u constraints, indexen etc. dezelfde naam geeft aan beide tabellen, anders loopt u de helft van de tijd niet synchroon. Aan het einde van de procedure kun je de nieuwe nep.MySummary-tabel TRUNCATE, maar als je de ruimte hebt, laat ik de gegevens daar graag achter, zodat ik altijd kan vergelijken met de vorige versie.

Vóór SQL Server 2005 gebruikte ik sp_rename in de transactie om precies hetzelfde te bereiken, maar aangezien ik dit in een baan doe, was ik blij dat ik overschakelde naar schema's, want toen ik dat deed, stopte de niet-onderdrukbare waarschuwing van sp_rename met vullen mijn geschiedenislogboeken van SQL Server Agent op.