Kręta droga czy prosta dróżka – migracja bazy danych do #Azure

Kilka, a w zasadzie to nawet już kilkanaście dni temu, napisałem krótką wzmiankę o tym jak wykorzystanie bazy danych (SQL Databases) na platformie Azure może zapewnić ciągłość działania. Zdałem sobie jednak sprawę, że dla wielu firm, o wiele poważniejszym wyzwaniem może być przeniesienie swoich baz z formy on-premises (zacisza własnej serwerowni) do bazy danych oferowanej w formie platformy. Pomysł migracji do SQL Databases jeszcze jakiś czas temu mógł się istotnie wydawać sporym wyzwaniem, głównie ze względu na kompatybilność oferowanej platformy i dobrze znanej własnej implementacji SQL Server. Wraz z wprowadzeniem V12 baz danych dość duża cześć funkcjonalności potrzebna w codziennym wykorzystaniu baz danych została dodana, a obecnie może bez większego problemu porównywać SQL Server 2016 z SQL Databases na platformie Azure pod kątem dostępnych funkcjonalności i zgodności. Niezależnie od tego czy planujemy migrację bardzo małej bazy danych wykorzystywanej do zapisywania pojedynczych transakcji np. wystawianych faktur w programie obsługi działalności gospodarczej czy chcemy przenieść bazę danych dużego portalu lub aplikacji biznesowej, niezbędne jest wykonanie kilku standardowych kroków.

  • Weryfikacja kompatybilności: Przed wykonaniem jakichkolwiek kroków, należy dokonać sprawdzenie możliwości przeniesienia bazy danych, poprzez weryfikację zgodności obecnie stosowanego rozwiązania ze środowiskiem docelowym
  • Rozwiązanie problemów kompatybilności (jeśli występują): Rozwiązanie problemów kompatybilności może być procesem dość czasochłonnym, w zależności od zidentyfikowanych niezgodności
  • Przeprowadzenie procesu migracji: Po przygotowaniu bazy danych do migracji należy rozpocząć sam proces przenoszenia bazy i jej zawartości. W tym miejscu przydatne będą sprawdzone rozwiązania i praktyki.

W realizacji powyższych zadań przydatne mogą być narzędzia, które bardzo często w dość zautomatyzowany sposób są w stanie wykonać proces weryfikacji czy samej migracji ( przy założeniu, że wyeliminowane zostały problemy w obszarze zgodności rozwiązań).

Dla przykładu proces weryfikacji kompatybilności można przeprowadzić korzystając z wbudowanej funkcjonalności w ramach Visual Studio. Wystarczy wykonać import bazy danych do projektu Visual Studio, dokonać zmiany docelowej platformy wdrożenia bazy danych, a narzędzie przeprowadzi walidację obiektów w ramach rozwiązania i określi możliwość wdrożenia bazy danych w ramach wskazanej platformy docelowej.

Alternatywnie można skorzystać z zupełnie nowego Upgrade Advisora’a  dla SQL Server, jedną z dostępnych funkcjonalności jest określenie poziomu zgodności z V12 SQL Databases. Dla przykładu –  poniżej analiza bazy DWDiagnostic (baza na potrzeby mechanizmu Polybase w ramach SQL Server 2016)  przeprowadzona z wykorzystaniem Upgrade Advisor;a wskazuje potencjalne problemy przy migracji wynikające z nieobsługiwanych w ramach SQL Databases obiektów.

sqlmigration

Oczywiście nie planowałem przenoszenia tej konkretnej bazy, użyłem jej wyłącznie w celach demonstracyjnych dla Upgrade Advisor’a

Proces usuwania potencjalnych niekompatybilności jest już nieco bardzie manualnym procesem i sprowadza się bardzo często do weryfikacji poszczególnych obiektów i wykorzystywanych w ramach T-SQL elementów języka/funkcjonalności, wskazanych jako niekompatybilne.

Sam proces migracji to również kilka standardowych możliwości – ja ostatnio z sukcesem testowałem opcje opartą o wbudowany w SQL Server mechanizm Data Tier application, którego jednym z elementów funkcjonalnych jest możliwość stworzenia plików .dacpac lub .backpack (w dużym skrócie podstawowa różnica to, że .backpack zawiera pełną kopię danych).  Po wykonaniu zrzutu lokalnej bazy danych do pliku.backpack, wykorzystałem możliwość  stworzenia pełnej bazy danych na platformie Azure, wraz ze wszystkim danymi w oparciu o przygotowany plik.

Uwaga! Ciekawostka – opcja zrzutu bazy do pliku .backpack to również ciekawa forma przenoszenia baz danych pomiędzy różnymi wersjami SQL Server. O ile przeniesienie bazy z wersji 2014 do 2016 jest obsługiwanym natywnie scenariuszem, o tyle już baza działająca na wersji 2016 ( nawet bez zmienionego poziomu kompatybilności) nie będzie chciała się zbyt prosto odtworzyć na wersji 2012 (zakładając nawet, że nie wykorzystano opcji niedostępnych w wersji 2012). Pomocne będzie wykorzystanie opcji plików .bacpack

W nieco uproszczonym schemacie opcje migracji przedstawiają się następująco:

01ssmsdiagram_new
Źródło: https://azure.microsoft.com/pl-pl/documentation/articles/sql-database-cloud-migrate/

Jeśli chcesz wiedzieć więcej o możliwościach, korzyściach z migracji bazy danych do rozwiązaź PaaS (SQL Databases oraz SQL Datawarehouse) w ramach Azure – daj proszę znać. Z chęcią poruszę ten temat szerzej, a może nawet namówię kilka osób na jakieś warsztaty w tym zakresie. Są chętni ?

Póki co zachęcam do odwiedzania stron Microsoft Vistual Academy – na szkolenie poświęcone migracji baz danych do rozwiązań w chmurze