ALTER TABLE SET (SYSTEM_VERSIONING = OFF)

Polecenie ALTER TABLE SET (SYSTEM_VERSIONING = OFF) wyłącza automatyczne śledzenie historii zmian danych w tabeli czasowej.

Rola polecenia w tabeli czasowej SQL Server

ALTER TABLE ... SET (SYSTEM_VERSIONING = OFF) jest instrukcją języka Transact-SQL używaną w Microsoft SQL Server do wyłączenia mechanizmu systemowego wersjonowania tabeli czasowej. W typowej konfiguracji tabela składa się z tabeli bieżącej, zawierającej aktualne wiersze, oraz powiązanej z nią tabeli historii. SQL Server zapisuje w tabeli historii wcześniejsze wersje wierszy, gdy dane w tabeli bieżącej są aktualizowane albo usuwane. Polecenie wyłącza automatyczne utrzymywanie tej relacji, ale samo w sobie nie usuwa tabeli historii ani zapisanych w niej danych.

Pełna postać instrukcji może wyglądać następująco: ALTER TABLE dbo.Zamowienia SET (SYSTEM_VERSIONING = OFF);. Nazwa tabeli musi wskazywać tabelę bieżącą, na której skonfigurowano system versioning. Opcja dotyczy konkretnego mechanizmu tabel temporalnych SQL Server, a nie ogólnego archiwizowania danych, dziennika transakcji ani kopii zapasowej. Po wykonaniu polecenia SQL Server przestaje automatycznie przenosić poprzednie wersje rekordów do tabeli historii.

Co zmienia wyłączenie system versioning

Po wyłączeniu wersjonowania tabela bieżąca przestaje działać jako systemowo wersjonowana tabela czasowa. Zapytania wykorzystujące klauzulę FOR SYSTEM_TIME, takie jak AS OF, FROM ... TO, BETWEEN ... AND czy CONTAINED IN, nie mogą być dalej traktowane jako zapytania do aktywnego systemu temporalnego tej tabeli. Dostęp do istniejących danych historycznych nadal może być możliwy przez bezpośrednie odwołanie do tabeli historii, o ile tabela ta nie została usunięta, zmieniona lub pozbawiona uprawnień.

Wyłączenie automatyzacji oznacza również, że późniejsze operacje INSERT, UPDATE i DELETE wykonywane na tabeli bieżącej nie tworzą z tego powodu nowych wersji w tabeli historii. Jeżeli aplikacja lub administrator zmieni dane w tabeli historii, SQL Server nie będzie automatycznie kontrolował takiej zmiany jako elementu aktywnego system versioning. Tabela historii staje się w praktyce odłączonym obiektem przechowującym dotychczasowe rekordy, choć jej struktura i nazwa pozostają bez zmian, dopóki nie zostaną zmodyfikowane osobnymi poleceniami.

Instrukcja nie przywraca wcześniejszego stanu danych i nie wykonuje synchronizacji tabel. Nie należy więc traktować jej jako operacji cofnięcia zmian. Jej działanie dotyczy konfiguracji mechanizmu temporalnego, a nie wartości kolumn, liczby rekordów ani zawartości dziennika transakcji. Wykonanie polecenia może wymagać odpowiednich uprawnień oraz uzyskania blokady schematu, dlatego przy dużej tabeli i aktywnych połączeniach trzeba uwzględnić wpływ operacji na równoległe działania administracyjne i aplikacyjne.

Dlaczego wyłącza się wersjonowanie przed zmianą struktury

Jednym z praktycznych zastosowań SYSTEM_VERSIONING = OFF jest przygotowanie tabeli bieżącej i historii do kontrolowanej zmiany struktury. Aktywne wersjonowanie nakłada ograniczenia na modyfikowanie kolumn, ponieważ tabela bieżąca i tabela historii muszą zachować zgodny układ wymagany przez SQL Server. Po czasowym wyłączeniu mechanizmu administrator może wykonać zaplanowane zmiany, na przykład dostosować definicje kolumn w obu tabelach, zmienić indeksy albo przeprowadzić korektę danych historycznych. Zakres dopuszczalnych operacji nadal zależy od konkretnego schematu, typów danych, więzów i używanych indeksów.

Przed wykonaniem polecenia warto jednoznacznie ustalić nazwę tabeli bieżącej, nazwę tabeli historii, kolumny okresu oraz sposób odtworzenia konfiguracji. Pomocne są katalogi systemowe SQL Server, między innymi widoki opisujące tabele temporalne i ich relacje. Należy również sprawdzić, czy aplikacja nie wykonuje w tym czasie operacji, dla których historia zmian jest wymagana. Wersjonowanie można wyłączyć w ramach kontrolowanego okna administracyjnego, a następnie po zmianach ponownie włączyć, podając właściwą tabelę historii i wymagane ustawienia. Przy ponownym uruchamianiu SQL Server weryfikuje zgodność definicji i danych z zasadami tabel systemowo wersjonowanych.

Ryzyko polega przede wszystkim na powstaniu luki w historii. Wszystkie zmiany wykonane podczas okresu, w którym system versioning pozostaje wyłączony, nie zostaną automatycznie zapisane jako kolejne wersje. Jeżeli modyfikowane są istniejące rekordy historii, można także naruszyć ich wartość dowodową lub chronologię. Dlatego procedura powinna obejmować kopię zapasową zgodną z polityką danego środowiska, zapis stanu konfiguracji, listę wykonanych poleceń, kontrolę liczby rekordów oraz test zapytań temporalnych po ponownym włączeniu mechanizmu. Samo ustawienie opcji na OFF nie zapewnia żadnej z tych kontroli.

Diagnostyka skutków w środowisku SQL Server

Przy problemach związanych z tą instrukcją należy najpierw ustalić, czy polecenie wykonano na właściwej tabeli i w odpowiedniej bazie danych. Błąd może wynikać z niepoprawnej składni, braku uprawnień, aktywnych zależności albo próby odwołania do obiektu, który nie jest tabelą systemowo wersjonowaną. Po operacji trzeba sprawdzić właściwości tabeli bieżącej, obecność tabeli historii, definicję kolumn okresu i stan opcji temporalnych. Warto także porównać schemat obu tabel, zweryfikować indeksy oraz przejrzeć dziennik błędów i historię poleceń administracyjnych.

Jeżeli po wyłączeniu wersjonowania aplikacja zgłasza błędy, przyczyną może być pozostawienie zapytań z FOR SYSTEM_TIME, oczekiwanie automatycznego zapisu historii albo bezpośrednia zmiana tabeli, która wcześniej była chroniona przez mechanizm temporalny. Diagnostyka powinna obejmować kod aplikacji, procedury składowane, wyzwalacze i zadania utrzymaniowe, a także porównanie danych bieżących z zapisami historycznymi. Przywrócenie system versioning wymaga ostrożnej weryfikacji, ponieważ SQL Server może odrzucić konfigurację, gdy tabele nie mają zgodnych kolumn, typów danych lub wymaganych kolumn okresu.

W środowisku produkcyjnym analizę takiej operacji powinien prowadzić administrator znający Microsoft SQL Server i zależności konkretnej bazy. Warszawskie Pogotowie Komputerowe wykonuje diagnostykę oraz naprawę komputerów i podzespołów, natomiast ocena konfiguracji serwerowej tabel temporalnych wymaga pracy w zakresie właściwym dla administracji silnikiem SQL Server.