Sdílet prostřednictvím

Aspekty a omezení časových tabulek

  • Článek

platí pro: SQL Server 2016 (13.x) a novější verze Azure SQL DatabaseAzure SQL Managed InstanceSQL Database v Microsoft Fabric

Při práci s dočasnými tabulkami je potřeba vzít v úvahu některé aspekty a omezení, a to z důvodu povahy správy systémových verzí:

  • Dočasná tabulka musí mít definovaný primární klíč, aby bylo možné korelovat záznamy mezi aktuální tabulkou a tabulkou historie. Tabulka historie nemůže mít definovaný primární klíč.

  • Sloupce SYSTEM_TIME období použité k zaznamenávání hodnot ValidFrom a ValidTo musí být definovány datovým typem datetime2.

  • Dočasná syntaxe funguje u tabulek nebo zobrazení, která jsou uložená místně v databázi. U vzdálených objektů, jako jsou tabulky na propojeném serveru nebo externích tabulkách, nemůžete přímo v dotazu použít klauzuli FOR ani predikáty období.

  • Pokud je název tabulky historie zadán během vytváření tabulky historie, je nutné zadat schéma a název tabulky.

  • Ve výchozím nastavení je tabulka historie PAGE komprimována.

  • Pokud je aktuální tabulka rozdělená na oddíly, vytvoří se ve výchozí skupině souborů tabulka historie, protože konfigurace dělení se automaticky nereplikuje z aktuální tabulky do tabulky historie.

  • Dočasné tabulky a tabulky historie nemůžou používat FileTable ani FILESTREAM. FileTable a FILESTREAM umožňují manipulaci s daty mimo SQL Server, takže správu verzí systému není možné zaručit.

  • Uzel nebo hraniční tabulka nelze vytvořit jako dočasnou tabulku ani ji změnit.

  • Dočasné tabulky podporují datové typy objektů blob, například (n)varchar(max), varbinary(max), (n)texta image, nesou významné náklady na úložiště a mají vliv na výkon kvůli jejich velikosti. Při návrhu systému je třeba věnovat pozornost používání těchto datových typů.

  • Tabulka historie musí být vytvořena ve stejné databázi jako aktuální tabulka. Dočasné dotazování na odkazované servery se nepodporuje.

  • Tabulka historie nemůže mít omezení (omezení primárního klíče, cizího klíče, tabulky nebo sloupce).

  • Indexovaná zobrazení nejsou podporována nad dočasnými dotazy (dotazy, které používají klauzuli FOR SYSTEM_TIME).

  • Možnost Online (WITH (ONLINE = ON) nemá žádný vliv na ALTER TABLE ALTER COLUMN v časové tabulce verzované systémem. ALTER sloupec se neprovádí jako online operace bez ohledu na to, jakou hodnotu byla zadána pro ONLINE možnost.

  • INSERT a výroky UPDATE nemohou odkazovat na sloupce období SYSTEM_TIME. Pokusy o vložení hodnot přímo do těchto sloupců jsou blokované.

  • TRUNCATE TABLE se nepodporuje, zatímco SYSTEM_VERSIONING je ON.

  • Přímá úprava dat v tabulce historie není povolená.

  • ON DELETE CASCADE a ON UPDATE CASCADE nejsou v aktuální tabulce povolené. Jinými slovy, pokud časová tabulka odkazuje na tabulku v relaci cizího klíče (odpovídající parent_object_id v sys.foreign_key), možnosti CASCADE nejsou povoleny. Pokud chcete toto omezení obejít, použijte logiku aplikace nebo po triggerech, abyste zachovali konzistenci při odstranění v tabulce primárního klíče (odpovídající referenced_object_id v sys.foreign_key). Pokud je tabulka primárního klíče dočasná a odkazování na tabulku není dočasné, neexistuje žádné takové omezení.

  • INSTEAD OF triggery nejsou povolené v aktuální tabulce nebo v tabulce historie, aby se zabránilo zneplatnění logiky DML. AFTER triggery jsou povoleny pouze v aktuální tabulce. Tyto triggery jsou v tabulce historie blokované, aby se zabránilo zneplatnění logiky DML.

  • Použití replikačních technologií je omezené:

    • skupiny dostupnosti : plně podporovaná

    • Change data capture a Change tracking: Podporováno pouze na aktuální tabulce

    • Snímek a transakční replikace: Podporuje se pouze pro jednoho vydavatele bez povolení časových funkcí a jednoho odběratele s povolenými časovými funkcemi. Použití více odběratelů není podporováno kvůli závislosti na místních systémových hodinách, což může vést k nekonzistentním dočasným datům. V tomto případě se vydavatel používá pro úlohu OLTP, zatímco odběratel slouží k odlehčení zpracování výkazů (včetně dotazování AS OF). Při spuštění distribučního agenta se otevře transakce, která zůstane otevřená, dokud se distribuční agent nezastaví. ValidFrom a ValidTo se nastaví na čas zahájení první transakce, kterou zahájí distribuční agent. Pokud je pro vaši aplikaci nebo organizaci důležité mít ValidFrom a ValidTo naplněné časem, který je blízko aktuálního systémového času, může být vhodnější spustit distribučního agenta podle plánu, než ho spouštět nepřetržitě podle výchozího chování. Další informace najdete v tématu scénáře použití dočasných tabulek.

    • replikace sloučení : Pro dočasné tabulky se nepodporuje

  • Běžné dotazy mají vliv jenom na data v aktuální tabulce. Pokud chcete dotazovat data v tabulce historie, musíte použít dočasné dotazy. Další informace najdete v tématu Dotazování dat v dočasné tabulce s systémovou verzí.

  • Optimální strategie indexování zahrnuje index úložiště clusterovaných sloupců nebo index úložiště řádků stromu B v aktuální tabulce a clusterovaný index columnstore v tabulce historie pro optimální velikost a výkon úložiště. Pokud vytváříte nebo používáte vlastní tabulku historie, důrazně doporučujeme vytvořit tento typ indexu skládajícího se ze sloupců období začínajících sloupcem konce období. Tento index zrychluje dočasné dotazování a zrychluje dotazy, které jsou součástí kontroly konzistence dat. Výchozí tabulka historie obsahuje clusterovaný index rowstore vytvořený za vás na základě sloupců období (konec, začátek). Minimálně se doporučuje neclusterovaný index rowstore.

  • Následující objekty nebo vlastnosti se při vytváření tabulky historie nereplikují z aktuální tabulky do tabulky historie:

    • Definice období
    • Definice identity
    • Indexy
    • Statistika
    • Kontrola omezení
    • Spouště
    • Konfigurace dělení
    • Dovolení
    • Predikáty zabezpečení na úrovni řádků

  • Tabulku historie nejde nakonfigurovat jako aktuální tabulku v řetězu tabulek historie.

Poznámka

Dokumentace používá termín B-tree obecně v odkazu na indexy. V indexech rowstore databázový stroj implementuje strom B+. To neplatí pro indexy columnstore ani indexy v tabulkách optimalizovaných pro paměť. Další informace najdete v SQL Serveru a architektuře indexu Azure SQL a průvodci návrhem.

Související obsah