Delen via

Overwegingen en beperkingen voor tijdelijke tabellen

  • Artikel

Van toepassing op: SQL Server 2016 (13.x) en latere versies Azure SQL DatabaseAzure SQL Managed InstanceSQL-database in Microsoft Fabric

Er zijn enkele overwegingen en beperkingen waarmee u rekening moet houden bij het werken met tijdelijke tabellen, vanwege de aard van systeemversiebeheer:

  • Een tijdelijke tabel moet een primaire sleutel hebben gedefinieerd om records te correleren tussen de huidige tabel en de geschiedenistabel. In de geschiedenistabel kan geen primaire sleutel zijn gedefinieerd.

  • De kolommen SYSTEM_TIME periode die worden gebruikt om de ValidFrom- en ValidTo-waarden vast te leggen, moeten worden gedefinieerd met een gegevenstype van datum/tijd2-.

  • Temporale syntaxis werkt op tabellen of weergaven die lokaal zijn opgeslagen in de database. Met externe objecten, zoals tabellen op een gekoppelde server of externe tabellen, kunt u de FOR-clause of tijdperiode-predicaten niet rechtstreeks in de query gebruiken.

  • Als de naam van een geschiedenistabel wordt opgegeven tijdens het maken van de geschiedenistabel, moet u de schema- en tabelnaam opgeven.

  • De geschiedenistabel wordt standaard PAGE gecomprimeerd.

  • Als de huidige tabel is gepartitioneerd, wordt de geschiedenistabel gemaakt in de standaardbestandsgroep, omdat de partitioneringsconfiguratie niet automatisch wordt gerepliceerd van de huidige tabel naar de geschiedenistabel.

  • Tijdelijke tabellen en geschiedenistabellen kunnen geen filetable of FILESTREAM gebruiken. FileTable en FILESTREAM maken het bewerken van gegevens buiten SQL Server mogelijk, zodat systeemversiebeheer niet kan worden gegarandeerd.

  • Een knooppunt- of edge-tabel kan niet worden aangemaakt als, of omgezet in, een temporale tabel.

  • Tijdelijke tabellen ondersteunen blobgegevenstypen, zoals (n)varchar(max), varbinary(max), (n)teksten afbeelding, ze hebben aanzienlijke opslagkosten en hebben gevolgen voor de prestaties vanwege hun grootte. Als zodanig moet u bij het ontwerpen van uw systeem voorzichtig zijn bij het gebruik van deze gegevenstypen.

  • De geschiedenistabel moet worden gemaakt in dezelfde database als de huidige tabel. Tijdelijke query's op gekoppelde servers worden niet ondersteund.

  • De geschiedenistabel kan geen beperkingen hebben (primaire sleutel, refererende sleutel, tabel of kolombeperkingen).

  • Geïndexeerde weergaven worden niet ondersteund boven op tijdelijke query's (query's die gebruikmaken van FOR SYSTEM_TIME component).

  • De online-optie (WITH (ONLINE = ON) heeft geen effect op ALTER TABLE ALTER COLUMN in een systeemgeversioneerde temporele tabel. ALTER kolom wordt niet uitgevoerd als een onlinebewerking, ongeacht welke waarde is opgegeven voor de optie ONLINE.

  • INSERT- en UPDATE-instructies kunnen niet verwijzen naar de SYSTEM_TIME-periodieke kolommen. Pogingen om waarden rechtstreeks in deze kolommen in te voegen, worden geblokkeerd.

  • TRUNCATE TABLE wordt niet ondersteund terwijl SYSTEM_VERSIONINGONis.

  • Directe wijziging van de gegevens in een geschiedenistabel is niet toegestaan.

  • ON DELETE CASCADE en ON UPDATE CASCADE zijn niet toegestaan in de huidige tabel. Met andere woorden, wanneer een tijdelijke tabel verwijst naar een tabel in de vreemde-sleutelrelatie (overeenkomend met parent_object_id in sys.foreign_key), zijn CASCADE opties niet toegestaan. Als u deze beperking wilt omzeilen, gebruikt u toepassingslogica of een na-trigger om consistentie bij het verwijderen in de tabel met primaire sleutels te behouden (overeenkomend met referenced_object_id in sys.foreign_key). Als de primaire-sleuteltabel tijdelijk is en de verwijzende tabel niet tijdelijk is, is er geen dergelijke beperking.

  • INSTEAD OF triggers zijn niet toegestaan op de huidige of de geschiedenistabel om te voorkomen dat de DML-logica ongeldig wordt. AFTER triggers zijn alleen toegestaan in de huidige tabel. Deze triggers worden geblokkeerd in de geschiedenistabel om te voorkomen dat de DML-logica ongeldig wordt.

  • Het gebruik van replicatietechnologieën is beperkt:

    • beschikbaarheidsgroepen: volledig ondersteund

    • Gegevens vastleggen en bijhouden van wijzigingen: alleen ondersteund in de huidige tabel

    • Momentopname en transactionele replicatie: alleen ondersteund voor één uitgever zonder temporele inschakeling en één abonnee met temporele functionaliteit. Het gebruik van meerdere abonnees wordt niet ondersteund vanwege een afhankelijkheid van de lokale systeemklok, wat kan leiden tot inconsistente tijdelijke gegevens. In dit geval wordt de uitgever gebruikt voor een OLTP-workload, terwijl abonnee fungeert voor offloadingrapportage (inclusief AS OF query's). Wanneer de distributieagent wordt gestart, wordt er een transactie geopend die open blijft totdat de distributieagent stopt. ValidFrom en ValidTo worden ingevuld tot de begintijd van de eerste transactie die de distributieagent start. Het is misschien beter om de distributieagent volgens een schema uit te voeren in plaats van het standaardgedrag van het continu uitvoeren ervan, als ValidFrom en ValidTo gevuld met een tijd die dicht bij de huidige systeemtijd ligt, belangrijk is voor uw toepassing of organisatie. Zie Tijdelijke tabelgebruiksscenario'svoor meer informatie.

    • Samenvoegreplicatie: niet ondersteund voor tijdtabellen

  • Reguliere query's zijn alleen van invloed op gegevens in de huidige tabel. Als u query's wilt uitvoeren op gegevens in de geschiedenistabel, moet u tijdelijke query's gebruiken. Zie Querygegevens in een tijdelijke tabel met systeemversiesvoor meer informatie.

  • Een optimale indexeringsstrategie omvat een geclusterde columnstore-index en/of een B-tree rowstore-index op de huidige tabel, en een geclusterde columnstore-index op de geschiedenistabel, voor optimale opslaggrootte en prestaties. Als u uw eigen geschiedenistabel maakt of gebruikt, raden wij sterk aan om dit type index te creëren, dat bestaat uit periodekolommen beginnend met de kolom voor het einde van de periode. Deze index versnelt tijdelijke query's en versnelt de query's die deel uitmaken van de gegevensconsistentiecontrole. De standaardgeschiedenistabel heeft een geclusterd rowstore-index die voor u is aangemaakt op basis van de periodekolommen (einde, begin). Minimaal wordt een niet-geclusterde rowstore-index aanbevolen.

  • De volgende objecten/eigenschappen worden niet gerepliceerd van de huidige naar de geschiedenistabel wanneer de geschiedenistabel wordt gemaakt:

    • Periodedefinitie
    • Identiteitsdefinitie
    • Indexen
    • Statistiek
    • Controleer voorwaarden
    • Aanleidingen
    • Partitioneringsconfiguratie
    • Machtigingen
    • Beveiligingspredicaten op rijniveau

  • Een geschiedenistabel kan niet worden geconfigureerd als huidige tabel in een keten van geschiedenistabellen.

Notitie

Documentatie maakt gebruik van de term B-tree in het algemeen in verwijzing naar indexen. In rijstore-indexen implementeert de database-engine een B+-boom. Dit geldt niet voor columnstore-indexen of indexen voor tabellen die zijn geoptimaliseerd voor geheugen. Zie de SQL Server- en Azure SQL-indexarchitectuur en ontwerphandleidingvoor meer informatie.

Verwante inhoud