Dela via

Överväganden och begränsningar för tidstabeller

  • Artikel

gäller för: SQL Server 2016 (13.x) och senare versioner Azure SQL DatabaseAzure SQL Managed InstanceSQL-databas i Microsoft Fabric

Det finns vissa överväganden och begränsningar att tänka på när du arbetar med temporala tabeller på grund av systemversionshantering:

  • En temporal tabell måste ha en primärnyckel definierad för att korrelera poster mellan den aktuella tabellen och historiktabellen. Det går inte att definiera en primärnyckel i historiktabellen.

  • De SYSTEM_TIME periodkolumner som används för att registrera värdena ValidFrom och ValidTo måste definieras med en datatyp av datetime2.

  • Temporal syntax fungerar på tabeller eller vyer som lagras lokalt i databasen. Med fjärrobjekt som tabeller på en länkad server eller externa tabeller kan du inte använda FOR-satsen eller periodpredikat direkt i frågan.

  • Om namnet på en historiktabell anges när historiktabellen skapas måste du ange schemat och tabellnamnet.

  • Som standard komprimeras historiktabellen PAGE.

  • Om den aktuella tabellen partitioneras skapas historiktabellen i standardfilgruppen eftersom partitioneringskonfigurationen inte replikeras automatiskt från den aktuella tabellen till historiktabellen.

  • Tabeller för tids- och historik kan inte använda FileTable eller FILESTREAM. FileTable och FILESTREAM tillåter datamanipulering utanför SQL Server, så systemversioner kan inte garanteras.

  • En nod- eller kanttabell kan inte skapas som eller ändras till en temporal tabell.

  • Även om temporala tabeller stöder blobdatatyper, till exempel (n)varchar(max), varbinary(max), (n)textoch bild, medför de betydande lagringskostnader och får prestandakonsekvenser på grund av deras storlek. När du utformar systemet bör du därför vara försiktig när du använder dessa datatyper.

  • Historiktabellen måste skapas i samma databas som den aktuella tabellen. Temporala frågekörningar över länkade servrar stöds inte.

  • Historiktabellen kan inte ha begränsningar (primärnyckel, sekundärnyckel, tabell eller kolumnbegränsningar).

  • Indexerade vyer stöds inte ovanpå temporala frågor (frågor som använder FOR SYSTEM_TIME-satsen).

  • Onlinealternativet (WITH (ONLINE = ON) har ingen effekt på ALTER TABLE ALTER COLUMN i en systemversionsbaserad temporaltabell. ALTER kolumn utförs inte som en onlineåtgärd, oavsett vilket värde som angavs för alternativet ONLINE.

  • INSERT- och UPDATE-instruktioner kan inte referera till SYSTEM_TIME-periodens kolumner. Försök att infoga värden direkt i dessa kolumner blockeras.

  • TRUNCATE TABLE stöds inte när SYSTEM_VERSIONING är ON.

  • Direkt ändring av data i en historiktabell tillåts inte.

  • ON DELETE CASCADE och ON UPDATE CASCADE tillåts inte i den aktuella tabellen. Med andra ord, när en temporal tabell refererar till en tabell i en främmande nyckelrelation (motsvarande parent_object_id i sys.foreign_key) är CASCADE-alternativ inte tillåtna. Om du vill kringgå den här begränsningen använder du programlogik eller efter utlösare för att upprätthålla konsekvens vid borttagning i primärnyckeltabellen (motsvarande referenced_object_id i sys.foreign_key). Om primärnyckeltabellen är temporal och referenstabellen inte är temporal finns det ingen sådan begränsning.

  • INSTEAD OF utlösare tillåts inte för den aktuella tabellen eller historiktabellen för att undvika att DML-logiken ogiltigförklaras. AFTER utlösare tillåts endast på den aktuella tabellen. Dessa utlösare blockeras i historiktabellen för att undvika att DML-logiken ogiltigförklaras.

  • Användningen av replikeringstekniker är begränsad:

    • tillgänglighetsgrupper: stöds fullt ut

    • Ändra datainsamling och ändringsspårning: Stöds endast i den aktuella tabellen

    • Ögonblicksbild och transaktionsreplikering: Stöds endast för en enskild utgivare utan att temporal är aktiverat, och en prenumerant med temporal aktiverat. Användning av flera prenumeranter stöds inte på grund av ett beroende av den lokala systemklockan, vilket kan leda till inkonsekventa tidsdata. I det här fallet används publiceraren för att hantera en OLTP-arbetsbelastning, medan abonnenten hanterar avlastning av rapporteringen (inklusive AS OF-frågeställningar). När distributionsagenten startar öppnas en transaktion som hålls öppen tills distributionsagenten stoppas. ValidFrom och ValidTo fylls i till starttiden för den första transaktionen som distributionsagenten startar. Det kan vara bättre att köra distributionsagenten enligt ett schema i stället för standardbeteendet att köra den kontinuerligt, om det är viktigt för ditt program eller din organisation att ha ValidFrom och ValidTo fyllt med en tid som ligger nära den aktuella systemtiden. Mer information finns i användningsscenarier för tidstabeller.

    • Sammanfoga replikering: Stöds inte för temporala tabeller

  • Vanliga frågor påverkar endast data i den aktuella tabellen. Om du vill köra frågor mot data i historiktabellen måste du använda temporala frågor. Mer information finns i Fråga data i en systemversionerad temporär tabell.

  • En optimal indexeringsstrategi innehåller ett grupperat kolumnlagerindex och/eller ett B-trädradarkivindex i den aktuella tabellen och ett grupperat kolumnlagringsindex i historiktabellen för optimal lagringsstorlek och prestanda. Om du skapar/använder en egen historiktabell rekommenderar vi starkt att du skapar den här typen av index som består av periodkolumner som börjar med slutet av periodkolumnen. Det här indexet påskyndar temporal frågekörning och påskyndar de frågor som ingår i datakonsekvenskontrollen. Standardhistoriktabellen har ett grupperat radlagringsindex som skapats för dig baserat på periodkolumnerna (slut, start). Ett icke-grupperat radlagringsindex rekommenderas som minst.

  • Följande objekt/egenskaper replikeras inte från den aktuella till historiktabellen när historiktabellen skapas:

    • Period definition
    • Identitetsdefinition
    • Indexer
    • Statistik
    • Kontrollera begränsningar
    • Utlösare
    • Partitioneringskonfiguration
    • Behörigheter
    • Säkerhetspredikat på radnivå

  • Det går inte att konfigurera en historiktabell som aktuell tabell i en kedja med historiktabeller.

Obs

I dokumentationen används termen B-träd vanligtvis som referens till index. I radlagringsindex implementerar databasmotorn ett B+-träd. Detta gäller inte för kolumnlagringsindex eller index i minnesoptimerade tabeller. Mer information finns i arkitekturen och designguiden för SQL Server och Azure SQL-index.

Relaterat innehåll