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

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

När du arbetar med temporala tabeller, var medveten om följande överväganden och begränsningar på grund av systemversioneringens natur:

  • En temporär 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 är partitionerad skapas historiktabellen på 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 designar ditt system, var 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.

  • För att undvika att data manipulation language (DML)-logiken ogiltigförklaras är INSTEAD OF triggers inte tillåtna vare sig i den aktuella eller historiktabellen. 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: Fullt stödd

    • Insamling och spårning av förändringsdata: 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 detta fall används utgivaren för en arbetsbelastning för onlinetransaktionshantering (OLTP) medan abonnenten arbetar för att avlasta rapportering (inklusive AS OF förfrågningar). När distributionsagenten startar öppnar den en transaktion som hålls öppen tills distributionsagenten slutar. ValidFrom och ValidTo anges till starttiden för den första transaktion 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.

    • Merge replication: 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 inkluderar ett klustrat kolumnlagringsindex eller ett B-träd radlagringsindex i den aktuella tabellen, samt ett klustrat kolumnlagringsindex i historiktabellen, för optimal lagringsstorlek och prestanda. Om du skapar eller använder din egen historiktabell, skapa denna typ av index bestående av periodkolumner som börjar med kolumnen för periodens slut. Detta index snabbar upp temporala frågor och de frågor som ingår i datakonsistenskontrollen. Standardhistoriktabellen skapar ett klustrat radbutiksindex baserat på periodkolumnerna (slut, start). Använd som minimum ett icke-klustrat radlagringsindex.

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

    • Definitionen av perioden
    • Identitetsdefinition
    • Indexen
    • Statistics
    • Kontrollera begränsningar
    • Utlösare
    • Partitioneringskonfiguration
    • Permissions
    • Säkerhetspredikat på radnivå

  • Du kan inte konfigurera en historiktabell som den aktuella tabellen i en kedja av historiktabeller.

Note

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

  • Last updated on