Aspekty a omezení časových tabulek

Platí na: SQL Server 2016 (13.x) a novější verze Azure SQL DatabaseAzure SQL Managed InstanceSQL database in Microsoft Fabric

Při práci s časovými tabulkami mějte na paměti následující aspekty a omezení vyplývající z povahy systémového verzování:

  • Časová tabulka musí mít definovaný primární klíč, aby se záznamy korelovaly mezi aktuální tabulkou a historickou tabulkou. 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ělena, historická tabulka se vytvoří ve výchozí souborové skupině, protože konfigurace rozdělení se automaticky nereplikuje z aktuální tabulky do historické tabulky.

  • 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 buďte opatrní při používání těchto typů dat.

  • 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á.

  • Aby nedošlo k narušení logiky jazyka pro manipulaci s daty (DML), INSTEAD OF nejsou povoleny triggery ani v aktuální tabulce, ani v tabulce historie. 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ě podporována

    • Zachycování dat a sledování změn: Podporováno pouze v 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ě je vydavatel použit pro pracovní zátěž zpracování online transakcí (OLTP), zatímco odběratel slouží k odlehčování reportování (včetně AS OF dotazování). Když distribuční agent začne, otevírá transakci, která zůstává otevřená, dokud distribuční agent nepřestane. ValidFrom a ValidTo jsou vyplněny do začátku první transakce, kterou distribuční agent zahájí. 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í: Není podporována pro časové tabulky

  • 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 časové tabulce s verzováním podle systému.

  • Optimální strategie indexování zahrnuje clusterovaný sloupcový index nebo řádkový index typu B-tree na aktuální tabulce a clusterovaný sloupcový index na tabulce historie pro optimální velikost úložiště a výkon. Pokud si vytvoříte nebo používáte vlastní tabulku historie, vytvořte tento typ indexu složený z sloupců s obdobím začínajícím sloupcem na konci období. Tento index urychluje časové dotazování a dotazy, které jsou součástí kontroly konzistence dat. Výchozí tabulka historie vytváří shlukovaný index řádků založený na sloupcích období (konec, začátek). Minimálně použijte neclusterovaný index řádků.

  • 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
    • Indexes
    • Statistika
    • Kontrola omezení
    • Spouštěče
    • Konfigurace dělení
    • Permissions
    • Predikáty zabezpečení na úrovni řádků

  • Nemůžete nastavit tabulku historie jako aktuální tabulku v řetězci historických tabulek.

Note

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

  • Last updated on