Udostępnij za pośrednictwem

Zagadnienia i ograniczenia dotyczące tabeli czasowej

  • Artykuł

Dotyczy: SQL Server 2016 (13.x) i późniejsze wersje Azure SQL DatabaseAzure SQL Managed InstanceSQL Database w usłudze Microsoft Fabric

Istnieją pewne zagadnienia i ograniczenia, które należy wziąć pod uwagę podczas pracy z tabelami czasowymi, ze względu na charakter przechowywania wersji systemu:

  • Tabela czasowa musi mieć zdefiniowany klucz podstawowy, aby skorelować rekordy między bieżącą tabelą a tabelą historii. Tabela historii nie może mieć zdefiniowanego klucza podstawowego.

  • Kolumny okresu SYSTEM_TIME używane do rejestrowania wartości ValidFrom i ValidTo muszą być zdefiniowane przy użyciu typu danych datetime2.

  • Składnia czasowa działa w tabelach lub widokach, które są przechowywane lokalnie w bazie danych. W przypadku obiektów zdalnych, takich jak tabele na serwerze połączonym lub tabelach zewnętrznych, nie można używać klauzuli FOR ani predykatów okresów bezpośrednio w zapytaniu.

  • Jeśli nazwa tabeli historii jest określona podczas tworzenia tabeli historii, musisz określić schemat i nazwę tabeli.

  • Domyślnie tabela historii jest kompresowana w formacie PAGE.

  • Jeśli bieżąca tabela jest partycjonowana, tabela historii jest tworzona w domyślnej grupie plików, ponieważ konfiguracja partycjonowania nie jest replikowana automatycznie z bieżącej tabeli do tabeli historii.

  • Tabele czasowe i historyczne nie mogą używać tabeli FileTable ani FILESTREAM. Funkcja FileTable i FILESTREAM umożliwiają manipulowanie danymi poza programem SQL Server, więc nie można zagwarantować przechowywania wersji systemu.

  • Nie można utworzyć węzła lub tabeli krawędzi ani zmienić jej na tabelę czasową.

  • Tabele czasowe obsługują typy danych obiektów blob, takie jak (n)varchar(max), varbinary(max), (n)texti image, ale generują znaczne koszty przechowywania i wpływają negatywnie na wydajność ze względu na ich rozmiar. W związku z tym podczas projektowania systemu należy zachować ostrożność podczas korzystania z tych typów danych.

  • Tabela historii musi zostać utworzona w tej samej bazie danych co bieżąca tabela. Wykonywanie zapytań czasowych na połączonych serwerach nie jest obsługiwane.

  • Tabela historii nie może mieć ograniczeń (klucz podstawowy, klucz obcy, tabela lub ograniczenia kolumn).

  • Widoki indeksowane nie są obsługiwane w odniesieniu do zapytań czasowych (zapytania korzystające z klauzuli FOR SYSTEM_TIME).

  • Opcja online (WITH (ONLINE = ON) nie ma wpływu na ALTER TABLE ALTER COLUMN w tabeli czasowej w wersji systemowej. ALTER kolumna nie jest wykonywana jako operacja online, niezależnie od tego, która wartość została określona dla opcji ONLINE.

  • instrukcje INSERT i UPDATE nie mogą odwoływać się do kolumn okresu SYSTEM_TIME. Próby wstawienia wartości bezpośrednio do tych kolumn są blokowane.

  • TRUNCATE TABLE nie jest obsługiwany, podczas gdy SYSTEM_VERSIONING jest ON.

  • Bezpośrednia modyfikacja danych w tabeli historii nie jest dozwolona.

  • ON DELETE CASCADE i ON UPDATE CASCADE nie są dozwolone w bieżącej tabeli. Innymi słowy, gdy tabela czasowa odwołuje się do tabeli w relacji klucza obcego (odpowiadająca parent_object_id w sys.foreign_key) opcje CASCADE nie są dozwolone. Aby obejść to ograniczenie, użyj logiki aplikacji lub wyzwalaczy po nich, aby zachować spójność usuwania w tabeli kluczy podstawowych (odpowiadających referenced_object_id w sys.foreign_key). Jeśli tabela klucza podstawowego jest czasowa, a odwołująca się do niej tabela jest nieczasowa, nie ma takiego ograniczenia.

  • INSTEAD OF wyzwalacze na tabeli bieżącej lub historii nie są dozwolone, aby uniknąć unieważnienia logiki DML. AFTER wyzwalacze mogą być stosowane tylko w bieżącej tabeli. Te wyzwalacze są blokowane w tabeli historii, aby uniknąć unieważnienia logiki DML.

  • Użycie technologii replikacji jest ograniczone:

    • grupy dostępności: w pełni obsługiwane

    • Przechwytywanie i śledzenie zmian danych: Obsługiwane tylko w bieżącej tabeli

    • Migawka i replikacja transakcyjna: Są obsługiwane tylko dla pojedynczego wydawcy bez włączenia funkcji czasowych i jednego subskrybenta z włączonymi funkcjami czasowymi. Korzystanie z wielu subskrybentów nie jest obsługiwane z powodu zależności od zegara systemu lokalnego, co może prowadzić do niespójnych danych czasowych. W takim przypadku wydawca jest używany dla obciążenia OLTP, podczas gdy subskrybent służy do odciążania raportowania (w tym AS OF zapytań). Po uruchomieniu agenta dystrybucji zostanie otwarta transakcja, która jest przechowywana do momentu zatrzymania agenta dystrybucji. ValidFrom i ValidTo są wypełniane do godziny rozpoczęcia pierwszej transakcji uruchamianej przez agenta dystrybucji. Może być preferowane uruchamianie agenta dystrybucji zgodnie z harmonogramem, a nie domyślne zachowanie jego ciągłego uruchamiania, jeśli ValidFrom i ValidTo wypełnione czasem zbliżonym do bieżącego czasu systemowego jest ważne dla aplikacji lub organizacji. Aby uzyskać więcej informacji, zobacz scenariusze użycia tabel czasowych .

    • Replikacja scalania : nie jest obsługiwana w przypadku tabel czasowych

  • Regularne zapytania mają wpływ tylko na dane w bieżącej tabeli. Aby wykonywać zapytania dotyczące danych w tabeli historii, należy użyć zapytań czasowych. Aby uzyskać więcej informacji, zobacz Zapytaj o dane w tabeli czasowej z wersjonowaniem systemowym.

  • Optymalna strategia indeksowania obejmuje indeks magazynu kolumn klastrowanych i/lub indeks magazynu wierszy drzewa B w bieżącej tabeli oraz indeks klastrowanego magazynu kolumn w tabeli historii w celu uzyskania optymalnego rozmiaru magazynu i wydajności. Jeśli tworzysz/używasz własnej tabeli historii, zdecydowanie zalecamy utworzenie tego typu indeksu składającego się z kolumn okresowych rozpoczynających się od kolumny końca okresu. Ten indeks przyspiesza wykonywanie zapytań czasowych i przyspiesza zapytania będące częścią sprawdzania spójności danych. Domyślna tabela historii zawiera utworzony dla Ciebie indeks klastrowanego magazynu wierszy na podstawie kolumn okresu (koniec, początek). Zalecane jest co najmniej indeks nieklastrowanego magazynu wierszy.

  • Następujące obiekty/właściwości nie są replikowane z bieżącej tabeli do tabeli historii podczas tworzenia tabeli historii:

    • Definicja okresu
    • Definicja tożsamości
    • Indeksy
    • Statystyka
    • Sprawdzanie ograniczeń
    • Wyzwalaczy
    • Konfiguracja partycjonowania
    • Uprawnienia
    • Predykaty zabezpieczeń na poziomie wiersza

  • Nie można skonfigurować tabeli historii jako bieżącej tabeli w łańcuchu tabel historii.

Notatka

W dokumentacji jest zwykle używany termin B-tree w odniesieniu do indeksów. W indeksach tabelarycznych aparat bazy danych implementuje drzewo B+. Nie dotyczy to indeksów magazynu kolumn ani indeksów w tabelach zoptymalizowanych pod kątem pamięci. Aby uzyskać więcej informacji, zobacz przewodnik dotyczący architektury indeksów i projektowania dla SQL Server i Azure SQL.

Powiązana zawartość