- Tabela odpowiada na jedno pytanie: które skrypty zmieniające schemat zostały już wykonane w tej bazie.
- Przed uruchomieniem migracji narzędzie porównuje listę plików z zawartością tabeli i wykonuje wyłącznie brakujące pozycje.
- Dzięki temu ten sam zestaw skryptów można bezpiecznie uruchomić na bazie testowej, wzorcowej i produkcyjnej.
- Ręczna modyfikacja wierszy jest operacją wysokiego ryzyka — rozjeżdża stan faktyczny bazy z jej zapisaną historią.
Do czego służy tabela [dbo].[_dbup]
Baza danych rozwija się razem z aplikacją: dochodzą kolumny, zmieniają się typy, powstają nowe indeksy. Przy jednym wdrożeniu da się to prowadzić ręcznie, przy kilkudziesięciu — nie. Tabela [dbo].[_dbup] jest miejscem, w którym narzędzie migracyjne zapisuje, co już zrobiło.
Mechanizm jest prosty i właśnie dlatego niezawodny. Skrypty leżą w katalogu i mają ustaloną kolejność wynikającą z nazwy. Przy uruchomieniu narzędzie odczytuje listę nazw zapisanych w tabeli, porównuje ją z zawartością katalogu i wykonuje wyłącznie te pliki, których na liście nie ma. Po udanym wykonaniu dopisuje nazwę i datę.
Praktyczna konsekwencja: proces jest powtarzalny i bezpieczny przy ponownym uruchomieniu. Wywołanie migracji na bazie, która jest już aktualna, nie zmienia niczego. To pozwala włączyć aktualizację schematu do standardowej procedury wdrożenia, zamiast traktować ją jako osobną, ręczną czynność wymagającą uwagi administratora.
Odczyt kataloguNarzędzie zbiera listę dostępnych skryptów w ustalonej kolejności
PorównanieNazwy z katalogu zestawiane są z zawartością tabeli _dbup
WykonanieUruchamiane są wyłącznie skrypty, których jeszcze nie odnotowano
Zapis historiiNazwa i data trafiają do tabeli dopiero po udanym wykonaniu
Zapis następuje po wykonaniu skryptu, nie przed nim. Skrypt przerwany błędem nie zostanie odnotowany i przy kolejnej próbie wykona się ponownie.
Budowa tabeli — wykaz kolumn
Struktura jest celowo minimalna — do odtworzenia stanu migracji potrzeba wyłącznie nazwy skryptu i momentu jego wykonania.
| Kolumna | Typ | Wymagana | Znaczenie |
|---|---|---|---|
Applied | datetime data i godzina | tak | Data i godzina pomyślnego wykonania skryptu na tej bazie |
Id | int liczba całkowita | tak | Kolejny numer wpisu nadawany automatycznie, klucz główny tabeli |
ScriptName | nvarchar(127) tekst do 127 znaków | tak | Pełna nazwa pliku skryptu wraz z przedrostkiem porządkowym — jedyny identyfikator rozpoznający skrypt jako wykonany |
Kolumna ScriptName przechowuje pełną nazwę pliku wraz z przedrostkiem porządkowym. To ona, a nie identyfikator liczbowy, decyduje o rozpoznaniu skryptu jako wykonanego.
Indeksy i wydajność zapytań
Tabela jest odczytywana raz na uruchomienie migracji i zawiera zwykle od kilkudziesięciu do kilkuset wierszy, dlatego nie wymaga rozbudowanego indeksowania.
| Indeks | Kolumny | Rodzaj |
|---|---|---|
PK__dbup_Id | Id | klucz główny |
Klucz główny na kolumnie Id zapewnia jednoznaczność wiersza. Przy bardzo długiej historii migracji warto rozważyć indeks unikalny na ScriptName — wymusza on brak duplikatów i przyspiesza porównanie listy.
Typowe kłopoty i sposób ich rozwiązania
Awarie mechanizmu migracji niemal zawsze sprowadzają się do rozbieżności między tym, co zapisano w tabeli, a tym, co faktycznie znajduje się w schemacie. Poniżej najczęstsze przypadki spotykane przy utrzymaniu instalacji StudioSystem.
| Objaw | Prawdopodobna przyczyna | Postępowanie |
|---|---|---|
| Skrypt wykonuje się przy każdym uruchomieniu | Nazwa pliku została zmieniona po jego wykonaniu | Przywrócić pierwotną nazwę albo dopisać nową do tabeli, jeśli zmiana jest już w bazie |
| Migracja przerywa się błędem „obiekt już istnieje” | Zmianę wprowadzono ręcznie, z pominięciem skryptu | Dopisać nazwę skryptu do tabeli po sprawdzeniu, że schemat odpowiada jego treści |
| Nowa kolumna nie pojawiła się mimo udanej migracji | Skrypt trafił do katalogu po zakończeniu wdrożenia | Uruchomić migrację ponownie — brakujący plik zostanie wykonany |
| Ta sama nazwa skryptu występuje dwa razy | Ręczna edycja tabeli lub scalenie dwóch gałęzi zmian | Usunąć duplikat i rozważyć indeks unikalny na kolumnie ScriptName |
Wspólny mianownik wszystkich przypadków: nazwa pliku jest jedynym identyfikatorem skryptu, więc jej zmiana zawsze ma konsekwencje.
Zasada nadrzędna brzmi: skryptu, który został już wykonany na jakiejkolwiek bazie, nie modyfikuje się. Poprawkę wprowadza się nowym plikiem. Odstępstwo od tej reguły powoduje, że środowiska przestają być porównywalne, a odtworzenie bazy od zera daje inny wynik niż jej aktualizacja.
Jak korzystać z tabeli w praktyce
Przy pracy z historią migracji warto pamiętać o kilku rzeczach:
- Wykonuj migrację najpierw na kopii bazy produkcyjnej — na środowisku testowym o innej historii wynik może być mylący.
- Rób kopię zapasową przed uruchomieniem skryptów zmieniających typy kolumn lub usuwających obiekty; migracja nie ma funkcji cofnięcia.
- Nie zmieniaj nazw plików już odnotowanych w tabeli — to najczęstsza przyczyna ponownego wykonania skryptu.
- Poprawki wprowadzaj nowym skryptem zamiast edycji istniejącego, nawet gdy chodzi o drobiazg.
- Traktuj ręczne dopisanie wiersza jako operację wyjątkową i odnotowuj jej powód poza bazą — po pół roku nikt nie odtworzy motywu z samej tabeli.
- Sprawdzaj datę ostatniej migracji przy diagnozie różnic między środowiskami; rozbieżność zwykle tłumaczy odmienne zachowanie aplikacji.
Zapytanie pokazujące ostatnio wykonane skrypty wraz z czasem, jaki upłynął od ich wprowadzenia:
SELECT TOP (20)
Id,
ScriptName,
Applied,
DATEDIFF(DAY, Applied, GETDATE()) AS DNI_TEMU
FROM dbo._dbup
ORDER BY Applied DESC, Id DESC;Porównanie wyniku tego zapytania na dwóch środowiskach jest najszybszym sposobem ustalenia, czym różnią się ich schematy.
Osobną sprawą, o której łatwo zapomnieć, jest nazewnictwo plików. Kolejność wykonania wynika z nazwy, więc przedrostek musi ją jednoznacznie ustalać — najczęściej stosuje się datę w formacie rocznym z numerem porządkowym. Nazwy typu poprawka.sql albo fix2.sql działają dopóty, dopóki nad bazą pracuje jedna osoba; przy dwóch równoległych gałęziach zmian kolejność przestaje być przewidywalna, a skutek migracji zależy od tego, kto wdrażał jako pierwszy.
Tabela migracji bywa pomijana w dokumentacji, bo nie zawiera danych biznesowych. W praktyce to jednak pierwsze miejsce, do którego zagląda się przy pytaniu „dlaczego na tym środowisku działa inaczej”. Zestawienie jej zawartości z dwóch instalacji odpowiada na nie szybciej niż porównywanie samych schematów.
Powiązane tabele i dokumentacja
Historia migracji łączy się z pozostałymi mechanizmami wersjonowania i konfiguracji systemu: