Widok sys.periods

sys.periods zawiera definicje okresów ważności wykorzystywanych przez tabele temporalne.

Widok sys.periods jako opis okresu temporalnego

sys.periods jest systemowym widokiem katalogowym SQL Server, który przechowuje powiązanie między tabelą temporalną a dwiema kolumnami wyznaczającymi okres obowiązywania każdego wiersza. Jedna z tych kolumn wskazuje początek okresu, a druga jego koniec. Dzięki temu można ustalić, które pola tabeli są używane przez mechanizm tabel systemowo wersjonowanych do zapisywania przedziału czasu, w którym dany rekord pozostawał aktualny.

Widok nie zawiera historii biznesowej jako takiej i nie służy do odczytywania kolejnych wersji danych. Jest częścią metadanych bazy danych. Jego zadaniem jest opis konstrukcji tabeli: wskazanie identyfikatora obiektu oraz identyfikatorów kolumn pełniących funkcję początku i końca okresu. Faktyczne wartości dat i czasu znajdują się w tabeli głównej oraz, w przypadku tabeli systemowo wersjonowanej, w tabeli historii. Rozdzielenie metadanych od danych pozwala najpierw rozpoznać strukturę, a dopiero później budować zapytania zwracające konkretne wersje rekordów.

W praktyce sys.periods jest używany podczas analizy schematu, sprawdzania poprawności konfiguracji tabel temporalnych, przygotowywania skryptów administracyjnych oraz automatycznego generowania zapytań. Sam fakt obecności wpisu w tym widoku wskazuje, że dla danego obiektu zdefiniowano okres, lecz pełna ocena działania tabeli wymaga także sprawdzenia ustawień temporalnych w katalogu tabel oraz właściwości samych kolumn.

sys.periods, kolumny czasu i kontekst techniczny

Najważniejszą wartością w sys.periods jest object_id. Identyfikuje on obiekt, którego dotyczy definicja okresu. Dwa pozostałe identyfikatory, start_column_id i end_column_id, wskazują kolumny początku i końca okresu w obrębie tego samego obiektu. Są to identyfikatory kolumn, a nie ich nazwy, dlatego do czytelnego raportu trzeba połączyć widok z sys.columns. Nazwę tabeli można odczytać z sys.tables, natomiast schemat z sys.schemas.

Przykładowy sposób interpretacji metadanych polega na wykonaniu połączenia według identyfikatora obiektu, a następnie dwukrotnym połączeniu z sys.columns: raz dla kolumny początku i drugi raz dla kolumny końca. W zapytaniu należy rozróżnić aliasy, ponieważ oba odwołania dotyczą tego samego widoku. Wynik może zawierać nazwę schematu, nazwę tabeli, nazwę kolumny początkowej oraz nazwę kolumny końcowej. Tak przygotowany raport jest znacznie bardziej użyteczny niż surowe identyfikatory katalogowe.

Kolumny okresu są zazwyczaj kolumnami typu daty i czasu, a ich wartości są obsługiwane przez silnik w sposób charakterystyczny dla tabel temporalnych. Koniec okresu jest zwykle traktowany jako granica wyłączna, co ma znaczenie przy filtrowaniu wersji obowiązujących w określonym momencie. Właściwe zapytania temporalne uwzględniają tę semantykę automatycznie, natomiast ręczne warunki na kolumnach okresu powinny być budowane ze świadomością różnicy między granicą włączną a wyłączną.

W porównaniu z sys.columns widok sys.periods odpowiada na inne pytanie. sys.columns opisuje wszystkie kolumny obiektu, a sys.periods wskazuje, które dwie z nich tworzą parę okresu. Z kolei sys.tables dostarcza informacji o tabeli jako obiekcie, lecz nie zastępuje informacji o przypisaniu konkretnych kolumn do początku i końca okresu. Dopiero zestawienie tych widoków daje pełny obraz konfiguracji.

Typowe problemy przy odczycie sys.periods

Jednym z częstych problemów jest traktowanie identyfikatorów kolumn jako nazw. Wartość start_column_id nie jest tekstem przeznaczonym do wyświetlenia użytkownikowi. Bez połączenia z sys.columns można jedynie stwierdzić, która kolumna została wskazana numerycznie. Podobnie samo object_id nie informuje wprost, w jakim schemacie znajduje się tabela ani jaką ma nazwę.

Innym źródłem pomyłek jest niewłaściwe filtrowanie po nazwie tabeli. Ta sama nazwa może wystąpić w różnych schematach, dlatego bezpieczniej uwzględnić zarówno nazwę schematu, jak i nazwę obiektu. Przy automatycznym przetwarzaniu metadanych należy także pamiętać, że uprawnienia użytkownika mogą ograniczać widoczność obiektów katalogowych. Brak oczekiwanego wiersza nie zawsze oznacza, że tabela nie ma okresu; może wskazywać na brak dostępu do odpowiednich metadanych.

Problemy pojawiają się również wtedy, gdy analiza miesza tabelę bieżącą z tabelą historii. sys.periods opisuje definicję okresu powiązaną z tabelą temporalną, natomiast dane historyczne są przechowywane zgodnie z konfiguracją wersjonowania. Do ustalenia, gdzie znajduje się historia, potrzebne jest dodatkowe sprawdzenie właściwości tabeli. Sam widok okresów nie jest katalogiem wszystkich historycznych rekordów i nie pokazuje zmian wartości w czasie.

Podczas migracji schematu należy zweryfikować zgodność nazw i typów kolumn, a także kolejność operacji wykonywanych w skrypcie. Zmiana kolumny używanej jako początek lub koniec okresu może wpływać na działanie wersjonowania oraz na zapytania raportowe. Warto najpierw odczytać metadane, zapisać stan wyjściowy, a po zmianie ponownie sprawdzić sys.periods razem z sys.columns i sys.tables.

Praktyczne wskazówki dotyczące sys.periods

Najwygodniej rozpocząć diagnostykę od zapytania zwracającego identyfikator obiektu oraz oba identyfikatory kolumn. Następnie należy dodać nazwy obiektu i schematu, a na końcu nazwy kolumn. Takie podejście ułatwia wykrycie sytuacji, w której raport wskazuje inną tabelę o podobnej nazwie albo gdy kolumna początku i kolumna końca zostały pomylone w logice aplikacji.

• Do każdego raportu metadanych dodawany jest schemat, aby uniknąć niejednoznaczności nazw.
• Identyfikatory z sys.periods są łączone z sys.columns po object_id oraz column_id.
• Przy kontroli konfiguracji sprawdzane są także typy danych i właściwości kolumn okresu.
• Zapytania odczytujące wersje rekordów są oddzielane od zapytań opisujących strukturę katalogową.
• Po zmianach struktury wykonywana jest ponowna kontrola metadanych i test odczytu danych w ujęciu czasowym.

Warto zachować gotowe zapytanie diagnostyczne w dokumentacji projektu. Powinno ono zwracać nazwę schematu, nazwę tabeli, nazwę kolumny początku oraz nazwę kolumny końca. Przy większej liczbie tabel temporalnych taki raport pozwala szybko porównać konfigurację i znaleźć obiekt odstający od przyjętego wzorca. Dodatkową korzyścią jest możliwość użycia raportu przed wdrożeniem zmian oraz po ich wykonaniu.

Kiedy zgłosić problem z sys.periods do serwisu

Do serwisu warto zgłosić się wtedy, gdy zapytania temporalne zwracają nieoczekiwane wersje, tabela historii nie jest prawidłowo wykorzystywana, po migracji nie można odczytać metadanych albo aplikacja zgłasza błąd przy operacjach na tabeli systemowo wersjonowanej. Szczególnie pomocne jest przekazanie informacji o nazwie bazy, schemacie, tabeli, treści komunikatu błędu oraz wyniku odczytu z sys.periods, sys.columns i sys.tables. Nie należy usuwać tabeli historii ani wyłączać wersjonowania bez kopii danych i planu odtworzenia.

Warszawskie Pogotowie Komputerowe 24/7 może pomóc w uporządkowaniu diagnostyki komputera, analizie konfiguracji SQL Server oraz przygotowaniu bezpiecznego planu dalszych działań. Przed przekazaniem sprzętu lub nośnika warto zabezpieczyć kopie zapasowe i zanotować, od kiedy występuje problem. W przypadku środowiska testowego można przygotować uproszczony przykład tabeli, aby rozdzielić błąd definicji okresu od problemu z konkretną aplikacją lub zapytaniem.