Migracje zmian w TSQL cz. 1 – schematy

Jednym z koszmarów związanych z pracą administratora bazy danych są migracje zmian z przestrzeni deweloperskiej do produkcyjnej. Jeśli mamy dobrze prowadzoną dokumentację lub otrzymaliśmy skrypty aktualizacyjne to problem praktycznie nie istnieje. Co jednak zrobić kiedy dostajemy bardzo zwięzłe w treści zadanie w stylu „skończone – możesz to już zmigrować na produkcję”? Tutaj niestety zaczynają się mniej lub bardziej irytujące schody. Ponieważ problemów jakie w takiej sytuacji się pojawiają jest wiele, dlatego też nie będę się starał opisywać tego wszystkiego na raz a rozbiję to na serię wpisów.

Pytania na jakie warto sobie odpowiedzieć podczas takiej migracji brzmią:

  • czy trzeba coś robić ze schematami? 
  • czy trzeba coś robić z tabelami?
  • czy trzeba coś robić z indeksami, kluczami, itp?
  • czy trzeba coś robić z rolami użytkowników?
  • czy trzeba coś robić z modułami programowalnymi (funkcje, procedury, triggery)?
  • czy trzeba coś robić z uprawnieniami użytkowników?

Oczywiście lista ta nie jest wyczerpana i w niektórych przypadkach powinna być rozbudowana (i to nawet solidnie). Niemniej uważam jednak, że większość przypadków została tutaj zawarta a przygotowanie dla nich gotowych rozwiązań bardzo ułatwi nam pracę.

W tym wpisie będziemy zajmować się wyszukiwaniem różnic w schematach pomiędzy dwiema bazami.

Zanim zaczniemy chciałbym powiedzieć kilka słów o przygotowaniu środowiska. Otóż utworzyłem sobie dwie bazy o nazwach poligon oraz poligon_dev (chyba wiadomo, która jest która 😉 ). Po czym w bazie produkcyjnej dodałem schemat o nazwie test a w bazie produkcyjnej o nazwie raporty. Efektem naszego działania będzie wyłapanie tych różnic. Co ważne – naszym celem nie będzie automatyczne przerobienie bazy produkcyjnej na obraz i podobieństwo deweloperskiej. Jedyne co chcemy osiągnąć to dowiedzieć się to czy są jakieś różnice. Można też ewentualnie zasugerować zapytania „korygujące”, z których będziemy mogli skorzystać bądź nie, ale osobiście preferuję wykonywać takie działania osobiście i nie zawierzać tego „przydatnym skryptom” 😉 Sama informacja o różnicach to i tak już, moim zdaniem, ogromna pomoc.

Podstawowym zapytaniem do pobierania informacji o schematach w bazie jest skorzystanie z INFORMATION_SCHEMA.SCHEMATA co może wyglądać tak

select *
from poligon.INFORMATION_SCHEMA.SCHEMATA

W efekcie działania powyższego skryptu otrzymamy następujący rezultat

W przypadku bazy deweloperskiej wynikiem działania byłby natomiast następujący widok

Jak najłatwiej będzie nam wyłapać różnice? Moglibyśmy posłużyć się np. takim zapytaniem

select prod.SCHEMA_NAME as prod_schema, dev.SCHEMA_NAME as dev_schema
from poligon.INFORMATION_SCHEMA.SCHEMATA as prod
full outer join poligon_dev.INFORMATION_SCHEMA.SCHEMATA as dev on dev.SCHEMA_NAME = prod.SCHEMA_NAME
where prod.SCHEMA_NAME is null 
or dev.SCHEMA_NAME is null

Którego wykonanie podałoby nam następujący efekt

Czy taki wynik można uznać za satysfakcjonujący? Trudno ukryć, że odpowiada on na nasze podstawowe pytanie. Chciałbym jednak zaproponować drobną modyfikację tego zapytania

select coalesce(prod.CATALOG_NAME, dev.CATALOG_NAME) as CATALOG_NAME,
coalesce(prod.SCHEMA_NAME, dev.SCHEMA_NAME) as SCHEMA_NAME
from poligon.INFORMATION_SCHEMA.SCHEMATA as prod
full outer join poligon_dev.INFORMATION_SCHEMA.SCHEMATA as dev on dev.SCHEMA_NAME = prod.SCHEMA_NAME
where prod.SCHEMA_NAME is null 
or dev.SCHEMA_NAME is null

Wynik działania poda nam zarówno informacje o tym, w której bazie znajduje się schemat nieistniejący w drugiej oraz jak ten schemat się nazywa.

Na koniec pozostaje nam jeszcze odpowiedzieć sobie na pytanie, czy odpowiada nam każdorazowe przywoływanie tego skryptu i zmienianie nazw baz w razie potrzeby? Jeśli wolelibyśmy sparametryzować sobie to zapytanie i wywoływać je w bardziej przyjazny sposób, wtedy możemy zapisać sobie to jako procedurę w bazie master. Skrypt tworzący taką procedurę, którą nazwałem dbo.migracje_sprawdzSchematy, wraz z objaśnieniami, zamieściłem w repozytorium na GitHubie. Wywołanie takiej procedury jest bardzo proste – w naszym przypadku byłoby to

-- Należy uważać na kolejność podawania nazw baz danych
exec master.dbo.migracje_sprawdzSchematy 'poligon', 'poligon_dev';

Mogą zainteresować Ciebie również poniższe wpisy

Comments are closed.