Kolumna is_temporal w sys.tables wskazuje, czy dana tabela jest objęta wersjonowaniem systemowym.
Widok sys.tables (is_temporal) – czym jest kolumna is_temporal
Widok sys.tables należy do katalogu systemowego SQL Server i opisuje tabele dostępne w bieżącej bazie danych. Jedną z jego kolumn jest is_temporal, której wartość wskazuje, czy dana tabela uczestniczy w mechanizmie tabel czasowych, czyli w systemowym wersjonowaniu danych. Kolumna ma charakter logiczny: wartość 1 oznacza tabelę temporalną, a wartość 0 wskazuje tabelę zwykłą, nieobjętą tym mechanizmem.
Informacja ta nie mówi, czy w tabeli znajdują się już historyczne rekordy, ani jak długo historia jest przechowywana. Nie określa również, czy wersjonowanie działa poprawnie w całym modelu danych. Jest to przede wszystkim sygnał opisujący status tabeli w metadanych. Dzięki niemu można szybko filtrować obiekty, wykrywać tabele temporalne podczas analizy schematu i budować skrypty administracyjne reagujące na obecność wersjonowania.
Podstawowe zapytanie może wyglądać następująco:
SELECT
name,
is_temporal
FROM sys.tables
ORDER BY name;
Przy interpretacji wyniku warto pamiętać, że sys.tables zwraca dane dotyczące obiektów widocznych dla bieżącego użytkownika. Uprawnienia mogą więc wpływać na zakres zwracanych informacji. Sama wartość is_temporal nie zastępuje pełnej inspekcji definicji tabeli, ale stanowi wygodny punkt wyjścia do dalszych sprawdzeń.
Widok sys.tables (is_temporal) a tabela temporalna i zwykła
Tabela temporalna przechowuje bieżący stan danych oraz umożliwia odtworzenie wcześniejszych wersji w określonym czasie. W SQL Server realizuje się to przez parę tabel: tabelę bieżącą, nazywaną tabelą systemowo-wersjonowaną, oraz powiązaną z nią tabelę historii. Przy zmianie albo usunięciu rekordu wcześniejsza wersja może zostać przeniesiona do historii, zależnie od konfiguracji mechanizmu. Tabela zwykła nie wykonuje takiej operacji automatycznie.
Wartość is_temporal = 1 odróżnia tabelę objętą systemowym wersjonowaniem od tabeli, która przechowuje wyłącznie aktualne dane. Nie należy jednak utożsamiać tej kolumny z informacją o tabeli historii. Do rozpoznania relacji między tabelą bieżącą i historyczną przydatne są dodatkowe metadane, między innymi kolumny opisujące typ tabeli temporalnej oraz identyfikator obiektu historii. Przykładowe zapytanie kontrolne może rozszerzać wynik o typ wersjonowania i obiekt historii:
SELECT
t.object_id,
t.name AS table_name,
t.is_temporal,
t.temporal_type,
t.history_table_id
FROM sys.tables AS t
WHERE t.is_temporal = 1;
Takie porównanie jest bardziej użyteczne niż samo sprawdzenie nazwy tabeli. Nazwa zawierająca słowo „History” nie jest dowodem, że obiekt jest tabelą historii zarządzaną przez system. Podobnie tabela przechowująca kolumny dat, na przykład ValidFrom i ValidTo, może być obsługiwana wyłącznie przez procedury, wyzwalacze lub kod aplikacji. Wersjonowanie systemowe wyróżnia się tym, że jego konfiguracja jest zapisana w metadanych, a SQL Server zna powiązanie tabeli bieżącej z historią.
W odróżnieniu od ręcznie projektowanego audytu mechanizm temporalny nie wymaga tworzenia osobnej logiki dla każdej instrukcji aktualizującej dane. Z drugiej strony wymaga świadomego planowania miejsca na historię, indeksów, retencji oraz zapytań obejmujących przedziały czasu. Kolumna is_temporal pomaga zidentyfikować obiekty, które trzeba uwzględnić podczas takiego planowania.
Widok sys.tables (is_temporal) – typowe problemy diagnostyczne
Jednym z częstych nieporozumień jest oczekiwanie, że zmiana wartości is_temporal będzie możliwa zwykłym poleceniem aktualizującym widok systemowy. Widoki katalogowe nie służą do bezpośredniej edycji metadanych. Włączenie, wyłączenie albo zmiana konfiguracji wersjonowania wymaga użycia odpowiednich poleceń języka DDL, przeznaczonych do obsługi tabel systemowo-wersjonowanych. Próba traktowania kolumny jak pola użytkowego prowadzi do błędnych założeń.
Drugim problemem jest odczytywanie wartości bez sprawdzenia kontekstu bazy danych. Widok sys.tables działa w obrębie aktualnie wybranej bazy. To samo zapytanie uruchomione w dwóch bazach może zwrócić różne obiekty, a skrypt wykonywany w narzędziu administracyjnym może przypadkowo analizować bazę inną niż zakładana. Przed porównaniem wyników należy jawnie potwierdzić kontekst, na przykład przez odczyt funkcji DB_NAME() oraz nazw schematów.
Trudność może sprawić także ograniczona widoczność obiektów. Użytkownik bez odpowiednich uprawnień może nie zobaczyć pełnej listy tabel albo nie uzyskać wszystkich informacji potrzebnych do dalszej analizy. Brak tabeli w wyniku nie musi oznaczać, że obiekt nie istnieje. Może oznaczać brak uprawnienia do jego metadanych.
W praktyce spotyka się również błędne założenie, że is_temporal = 1 gwarantuje nieograniczony dostęp do pełnej historii. Historia może podlegać retencji, archiwizacji, czyszczeniu albo ograniczeniom wynikającym z konfiguracji. Należy sprawdzić okres przechowywania, stan wersjonowania systemowego, kolumny okresu oraz rozmiar tabeli historii. Warto też analizować plan zapytań, ponieważ filtrowanie po czasie bez odpowiedniego indeksu może być kosztowne.
Widok sys.tables (is_temporal) – praktyczne wskazówki zapytań
Do codziennej inwentaryzacji można użyć zapytania zwracającego wyłącznie tabele temporalne:
SELECT
SCHEMA_NAME(t.schema_id) AS schema_name,
t.name AS table_name,
t.is_temporal,
t.temporal_type_desc,
t.history_table_id
FROM sys.tables AS t
WHERE t.is_temporal = 1
ORDER BY
schema_name,
table_name;
Wynik dobrze zestawić z kolumnami okresu. Informacje o kolumnach tabeli można pobrać z sys.columns, a właściwości związane z okresem z katalogowych widoków dotyczących tabel temporalnych. Przydatne jest również połączenie z sys.objects, aby potwierdzić typ obiektu i datę jego utworzenia. Takie zestawienie ułatwia odróżnienie konfiguracji formalnie zapisanej w bazie od konwencji przyjętej przez zespół.
W skryptach wdrożeniowych warto nie zakładać, że tabela zawsze ma ten sam status. Bezpieczniejszy jest schemat: odczytać is_temporal, sprawdzić typ temporalny, potwierdzić istnienie tabeli historii i dopiero wtedy wykonać operację zgodną z aktualnym stanem. Zapobiega to błędom podczas ponownego uruchamiania migracji oraz ogranicza ryzyko wykonania polecenia przeznaczonego dla tabeli zwykłej na obiekcie wersjonowanym.
Podczas projektowania raportu o schemacie można wyświetlić zarówno tabele temporalne, jak i zwykłe, zachowując kolumnę is_temporal jako prosty znacznik. Warto zapisać datę wykonania raportu, nazwę bazy i wersję środowiska, ponieważ konfiguracja może zmieniać się po migracjach. Sam wynik katalogowy jest aktualnym odczytem metadanych, a nie historycznym rejestrem zmian schematu.
Jeżeli odczyt katalogu systemowego zachowuje się inaczej niż oczekiwano, należy sprawdzić wybraną bazę, schemat, uprawnienia oraz zgodność wersji SQL Server z używanymi kolumnami. Przy analizie środowiska technicznego przydatna bywa kopia konfiguracji i dokumentacja zmian. W razie problemów sprzętowych z komputerem, na którym wykonywane są narzędzia administracyjne, Warszawskie Pogotowie Komputerowe 24/7 może przeprowadzić bezpłatną diagnozę laptopa.
Widok sys.tables (is_temporal) – kiedy zgłosić się do serwisu
Wsparcie serwisowe może być potrzebne wtedy, gdy problem z odczytem sys.tables wynika nie z samego SQL Server, lecz z niestabilnego komputera, uszkodzonego nośnika, błędów pamięci, przegrzewania albo nieprawidłowego działania systemu operacyjnego. Objawami są między innymi samoczynne restarty podczas wykonywania zapytań, zawieszanie narzędzia zarządzającego, znikające połączenie z bazą, uszkodzenia plików projektu lub nieregularne błędy odczytu.
Przed przekazaniem sprzętu warto zanotować komunikat błędu, moment jego występowania i czynności wykonywane bezpośrednio wcześniej. Należy też zabezpieczyć kopie zapasowe baz oraz konfiguracji, jeżeli jest to możliwe. Nie powinno się wielokrotnie uruchamiać komputera z podejrzanym dyskiem ani instalować przypadkowych programów naprawczych, ponieważ może to utrudnić późniejszą diagnostykę.
W przypadku problemu programowego przydatne jest rozdzielenie objawów: czy zapytanie zwraca nieprawidłowy wynik, czy aplikacja nie uruchamia się, czy też cały komputer traci stabilność. Pozwala to ustalić, czy należy analizować metadane bazy, konfigurację połączenia, uprawnienia użytkownika, system plików lub podzespoły komputera. Sama kolumna is_temporal jest tylko jednym elementem diagnozy i nie powinna być traktowana jako pełny test stanu środowiska.
Najważniejsza reguła jest prosta: wartość is_temporal służy do rozpoznania, czy tabela jest objęta systemowym wersjonowaniem, natomiast ocenę historii, konfiguracji, retencji i wydajności trzeba wykonać przy użyciu powiązanych metadanych oraz testów dopasowanych do konkretnej bazy.
