Temporal tables a migracja danych

Migracja tabel temporalnych wymaga przeniesienia zarówno bieżącej tabeli, jak i powiązanej z nią tabeli historii.

Budowa tabeli temporalnej w SQL Server

W SQL Server tabela temporalna przechowuje dane w dwóch powiązanych miejscach: w tabeli bieżącej, zwanej tabelą temporalną, oraz w tabeli historii. Tabela bieżąca zawiera aktualny stan rekordów, natomiast tabela historii przechowuje wcześniejsze wersje wierszy zmienionych albo usuniętych. Relację między tymi tabelami definiuje mechanizm SYSTEM_VERSIONING, a nie tylko sama nazwa tabeli historii.

System-versioned temporal table musi mieć dwie kolumny okresu obowiązywania. Są one definiowane jako GENERATED ALWAYS AS ROW START i GENERATED ALWAYS AS ROW END, a następnie łączone klauzulą PERIOD FOR SYSTEM_TIME. Typowym typem tych kolumn jest datetime2. Wartości określają przedział czasu, w którym dana wersja wiersza była aktualna. Podczas aktualizacji SQL Server zapisuje poprzednią wersję w tabeli historii, a podczas usunięcia przenosi do historii ostatni obowiązujący stan rekordu.

Zakres migracji: dane bieżące i wersje historyczne

Migracja tabeli temporalnej nie jest kompletna, jeżeli obejmuje wyłącznie tabelę bieżącą. Przeniesienie aktualnych rekordów bez tabeli historii powoduje utratę informacji potrzebnych do odtworzenia wcześniejszych stanów danych. Po takiej operacji zapytania wykorzystujące FOR SYSTEM_TIME mogą zwracać niepełny obraz zmian, mimo że bieżąca tabela działa poprawnie.

W praktyce trzeba ustalić mapowanie zarówno dla kolumn tabeli bieżącej, jak i dla odpowiadających im kolumn w tabeli historii. Tabela historii powinna zachować zgodność strukturalną wymaganą przez SQL Server, w tym zgodne kolumny danych oraz kolumny okresu systemowego. Należy także sprawdzić klucze, indeksy, ograniczenia i sposób przechowywania wartości ValidFrom oraz ValidTo. Historyczne wiersze muszą zachować oryginalne przedziały czasu, ponieważ ich zmiana może zniekształcić wyniki zapytań as-of i zapytań obejmujących zakres czasu.

Przed rozpoczęciem migracji warto ustalić, czy przenoszona jest cała tabela, czy tylko wybrany zakres danych. Przy migracji częściowej trzeba zdefiniować kryterium wyboru rekordów oraz sprawdzić, czy nie pozostawia ono luk w historii. Szczególnej uwagi wymagają rekordy powiązane relacjami kluczów obcych, ponieważ kolejność ładowania danych może mieć znaczenie dla poprawności całego modelu.

Wyłączenie wersjonowania i kontrolowane ładowanie danych

Najbezpieczniejszy przebieg migracji zależy od tego, czy dane są kopiowane do nowej tabeli, czy odtwarzane w już istniejącym obiekcie. Przy operacjach wymagających bezpośredniego załadowania historycznych wersji można czasowo wyłączyć wersjonowanie instrukcją ALTER TABLE ... SET (SYSTEM_VERSIONING = OFF). Po wyłączeniu mechanizmu tabela bieżąca i tabela historii stają się obiektami, które można obsługiwać oddzielnie, dlatego trzeba pilnować, aby nie pomylić ich przeznaczenia.

Podczas ładowania danych należy zachować wartości kolumn okresu systemowego. Wstawienie bieżącego rekordu z nowym znacznikiem czasu zamiast z jego pierwotnym okresem zmienia znaczenie historii. Należy również kontrolować, czy dla jednego klucza głównego przedziały czasu nie nakładają się oraz czy zachowana jest logiczna kolejność zmian. SQL Server przechowuje wersje, ale nie zastępuje procesu migracji, który musi poprawnie odwzorować dane źródłowe.

Po zakończeniu kopiowania tabelę historii należy ponownie powiązać z tabelą bieżącą przez włączenie SYSTEM_VERSIONING. Warto skorzystać z kontroli spójności historii, między innymi opcji DATA_CONSISTENCY_CHECK, oraz porównać liczbę rekordów, zakresy dat i wyniki przykładowych zapytań temporalnych. Test powinien obejmować zapytania typu FOR SYSTEM_TIME AS OF, FROM ... TO, BETWEEN ... AND i CONTAINED IN, jeżeli aplikacja korzysta z tych wariantów.

Pułapki zgodności po przeniesieniu danych

Jednym z częstych problemów jest niezgodność schematu między środowiskiem źródłowym a docelowym. Dodanie kolumny do tabeli bieżącej wymaga uwzględnienia jej odpowiednika w tabeli historii, jeżeli obie struktury mają pozostać zgodne. Dotyczy to także typów danych, kolejności kolumn w operacjach opartych na pozycji oraz wartości domyślnych. Niewłaściwe mapowanie może doprowadzić do odrzucenia importu albo do cichego przypisania danych do nieodpowiednich pól.

Trzeba również zweryfikować indeksy tabeli historii. Zapytania analizujące przeszłość często filtrują po kluczu rekordu i kolumnach okresu, dlatego brak odpowiednich indeksów może znacząco zwiększyć czas odczytu po migracji. Nie wolno jednak zakładać, że indeksy z tabeli bieżącej automatycznie zapewnią taką samą wydajność w tabeli historii. Obie tabele mają inne wzorce użycia: bieżąca obsługuje operacje aplikacji, a historyczna głównie odczyt wersji.

Końcowa kontrola powinna porównać dane przed i po migracji na kilku poziomach: liczbę wierszy, sumy kontrolne wybranych kolumn, minimalne i maksymalne znaczniki czasu oraz historię reprezentatywnych rekordów. Należy sprawdzić także operację aktualizacji i usunięcia po ponownym włączeniu wersjonowania. Dopiero potwierdzenie, że nowe zmiany trafiają do właściwej tabeli historii, pozwala uznać migrację za zakończoną poprawnie.