Zagadnienia i ograniczenia dotyczące tabeli czasowej

Dotyczy do: SQL Server 2016 (13.x) i nowsze wersje Azure SQL DatabaseAzure SQL Managed InstanceSQL database in Microsoft Fabric

Pracując z tabelami czasowymi, miej na uwadze następujące kwestie i ograniczenia wynikające z charakteru wersjonowania systemowego:

  • Tabela temporalna musi mieć zdefiniowany klucz główny, aby korelować 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 historyczna jest tworzona w domyślnej grupie plików, ponieważ konfiguracja partycjonowania nie jest automatycznie przenoszona z bieżącej tabeli do tabeli historycznej.

  • 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. Projektując swój system, bądź ostrożny przy użyciu 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.

  • Aby uniknąć naruszenia logiki DML, wyzwalacze INSTEAD OF nie są dozwolone ani w tabeli bieżącej, ani w tabeli historii. 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 wspierane

    • Przechwytywanie zmian danych i śledzenie zmian: Obsługiwane tylko w obecnej 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 na potrzeby obciążenia OLTP (przetwarzania transakcji online), podczas gdy subskrybent służy do odciążenia obsługi raportowania (w tym wykonywania AS OF zapytań). Po uruchomieniu agenta dystrybucji otwierana jest transakcja, która pozostaje otwarta do momentu zatrzymania agenta dystrybucji. ValidFrom i ValidTo są wypełniane do czasu rozpoczęcia pierwszej transakcji, którą rozpoczyna agent dystrybucyjny. 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 dla 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 klastrowany indeks magazynu kolumnowego lub indeks magazynu wierszy typu B-tree w tabeli bieżącej oraz klastrowany indeks magazynu kolumnowego w tabeli historii, aby zapewnić optymalny rozmiar pamięci masowej i wydajność. Jeśli tworzysz lub używasz własnej tabeli historii, stwórz taki indeks składający się z kolumn okresu zaczynających się od kolumny końcowej okresu. Ten indeks przyspiesza zapytania czasowe oraz zapytania będące częścią sprawdzania spójności danych. Domyślna tabela historii tworzy klastrowany indeks pamięci wierszy na podstawie kolumn okresu (end, start). Co najmniej użyj indeksu nieklastrowanego wierszowego zapisu.

  • 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
    • Indexes
    • Statystyka
    • Sprawdzanie ograniczeń
    • Wyzwalacze
    • Konfiguracja partycjonowania
    • Permissions
    • Predykaty zabezpieczeń na poziomie wiersza

  • Nie możesz skonfigurować tabeli historii jako aktualnej tabeli w łańcuchu tabel historii.

Note

W dokumentacji jest zwykle używany termin B-tree w odniesieniu do indeksów. W indeksach typu rowstore silnik 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 architekturę i przewodnik projektowania indeksu SQL Server i Azure SQL.

Treści powiązane

  • Last updated on