W miarę upływu czasu coraz więcej firm migruje do bazy danych Azure SQL lub przynajmniej ją ocenia jako alternatywę dla wysokich kosztów lokalnego uruchamiania SQL Server.
Sprawdzanie zgodności
Jednym z pierwszych aspektów przenoszenia bazy danych do Azure SQL Database jest sprawdzenie zgodności, a firma Microsoft oferuje wiele sposoby wykonania tej czynności w przypadku Azure SQL Database V12 (zwanej dalej po prostu „V12”). Jedną z tych metod jest użycie narzędzi SQL Server Data Tools dla programu Visual Studio (SSDT), które wykorzystują najnowsze reguły zgodności do wykrywania niezgodności V12. W SSDT można zaimportować schemat bazy danych i zbudować projekt dla wdrożenia V12, a jeśli zostaną znalezione jakiekolwiek niezgodności, można je poprawić w SSDT, a następnie zsynchronizować z powrotem do źródłowej bazy danych.
Możesz także użyć narzędzia wiersza polecenia o nazwie SqlPackage, które może wygenerować raport o problemach ze zgodnością (i zawsze upewnij się, że masz najnowszą wersję). SQL Server Management Studio to inny sposób na zrobienie tego, korzystając z funkcji eksportowania aplikacji warstwy danych, która może wykrywać i zgłaszać błędy na ekranie. Jeśli nie zostaną wykryte żadne błędy, możesz przeprowadzić migrację bazy danych do wersji V12. W przypadku wykrycia niezgodności można je naprawić za pomocą programu SSMS przed migracją.
Asystent migracji danych to samodzielne narzędzie (które można łatwo pomylić z Asystentem migracji programu SQL Server), które może pomóc w zmniejszeniu nakładu pracy związanej z aktualizacją i zastępuje program SQL Server 2016 Upgrade Advisor Preview. DMA może również zalecić poprawę wydajności i niezawodności. Inne narzędzie, Kreator migracji SQL Azure (SAMW), to narzędzie Codeplex, które używa reguł zgodności Azure SQL Database V11 do wykrywania niezgodności V12. SAMW może również zakończyć migrację do V12 i naprawić niektóre problemy ze zgodnością. Podczas korzystania z SAMW należy pamiętać, że może wykryć niezgodności, których nie trzeba naprawiać.
Migracja danych
Gdy baza danych przejdzie kontrolę zgodności, musisz określić najlepszą metodę migracji. Niektóre z bardziej powszechnych metod obejmują korzystanie z Kreatora migracji SSMS, eksportowanie do BACPAC, korzystanie z replikacji transakcyjnej lub ręczne tworzenie skryptów baz danych i wstawianie danych.
Korzystanie z Kreatora migracji SSMS doskonale nadaje się do SQL Server 2005 i nowszych baz danych, które są małe lub średnie. Możesz aktywować tego kreatora w programie SSMS 2016, klikając prawym przyciskiem myszy bazę danych, wybierz Zadania, a następnie Wdróż bazę danych w Microsoft Azure SQL Database. W SSMS 2014 nazywa się to wdrażaniem bazy danych w bazie danych SQL Azure w systemie Windows. Korzystanie z tego kreatora umożliwia określenie bazy danych do migracji, nawiązanie połączenia z subskrypcją platformy Azure, wybranie lokalizacji pliku bacpac, nowej nazwy bazy danych i warstwy do migracji. Po kliknięciu przycisku Zakończ kreator wyodrębni i zweryfikuje schemat, a następnie wyeksportuje dane. Po wyeksportowaniu danych utworzy plan wdrożenia i rozpocznie importowanie danych do nowej bazy danych V12.
Bardzo podobna do Kreatora migracji SSMS jest aplikacja warstwy eksportu danych. Aby wybrać tę opcję, kliknij prawym przyciskiem myszy bazę danych, wybierz Zadania, a następnie Eksportuj aplikację warstwy danych. W ustawieniach eksportu określasz, gdzie chcesz utworzyć plik .bacpac. Możesz zapisać to lokalnie lub bezpośrednio na koncie magazynu platformy Azure. Dostępna jest również zakładka zaawansowana, w której możesz wybrać, które tabele chcesz uwzględnić. Jest to przydatne, jeśli lokalna baza danych zawiera kopie tabel, których nie chcesz migrować do wersji 12. Gdy wybierzesz Zakończ, wyeksportuje Twoje dane. Następnie możesz połączyć się z serwerem Azure za pomocą programu SSMS i wybrać opcję Importuj aplikację warstwy danych. Określisz lokalizację pliku, nazwę bazy danych i warstwę Azure SQL Database. Po wybraniu opcji Zakończ, baza danych rozpocznie import. Ta metoda zapewnia nieco większą kontrolę nad procesem, ponieważ oddziela eksport od importu. Daje również możliwość przechowywania pliku .bacpac na koncie magazynu Azure, dzięki czemu bardziej wrażliwy proces importowania nie będzie zależał od połączenia internetowego.
Opcją w przypadku korzystania z Kreatora migracji SSMS lub aplikacji warstwy eksportu danych jest utworzenie maszyny wirtualnej platformy Azure z programem SQL Server i skonfigurowanie wysyłania dzienników. Spowoduje to wstępne przygotowanie bazy danych w chmurze platformy Azure, aby zminimalizować czas importowania bazy danych. Kiedy przychodzi czas na migrację, wystarczy przywrócić końcowe kopie zapasowe dziennika na serwerze pomocniczym, a następnie usunąć wysyłanie dziennika. Aby przełączyć bazę danych w tryb online, wykonaj przywracanie z odzyskiwaniem. Zasadniczo wyeliminuje to czas potrzebny na skopiowanie bazy danych z centrum danych do centrum danych platformy Azure.
Replikacja transakcyjna to kolejna metoda pomagająca skrócić przestoje związane z migracją do wersji 12. Jest to najlepsza opcja, jeśli masz bardzo małe okno konserwacji, aby przełączyć się na wersję 12, jeśli baza danych może obsługiwać replikację transakcyjną. Konfiguracja replikacji transakcyjnej wymaga kluczy podstawowych dla każdej opublikowanej tabeli, co może być problematyczne w przypadku wielu baz danych. Konfiguracja replikacji transakcyjnej może być również skomplikowana, ponieważ musisz skonfigurować bazę danych dystrybucji, skonfigurować wydawcę i subskrybenta oraz monitorować zadania.
Możesz również przeprowadzić migrację ręcznie za pomocą kreatora Generuj skrypty i tworząc skrypty na schemacie i/lub danych bazy danych. Następnie możesz utworzyć pustą bazę danych na platformie Azure i zaimportować schemat i/lub dane, wykonując skrypt. Słyszałem, że niektórzy ludzie używają tej metody do tworzenia pustej bazy danych, a następnie ręcznego wstawiania swoich danych po jednej tabeli na raz za pomocą SSMS i połączonego serwera. Ta metoda może działać dla Ciebie, ale może być również bardzo skomplikowana, jeśli masz wiele konstrukcji schematów, takich jak relacje kluczy obcych i kolumny tożsamości, w którym to przypadku inne powyższe metody byłyby bardziej niezawodne i wydajne.
Inne kwestie związane z migracją
Planując migrację lokalnych baz danych do wersji 12, rozmiar bazy danych ma ogromny wpływ na czas trwania migracji. Eksport bazy danych, transfer danych i import będą wzrastać proporcjonalnie do rozmiaru bazy danych.
Innym ważnym czynnikiem wpływającym na czas przywracania/importowania podczas przenoszenia baz danych do wersji 12 jest również przywracana warstwa wydajności. Proces przywracania/importowania wymaga dużej mocy, więc aby przyspieszyć migrację, należy rozważyć przywrócenie do wyższego poziomu wydajności. Gdy baza danych jest w trybie online, możesz łatwo i szybko przejść do niższej warstwy, która spełnia Twoje codzienne potrzeby w zakresie wydajności. Możliwość zmiany warstw wydajności za pomocą kilku kliknięć myszą to jedna z największych zalet usługi Azure SQL Database.
Monitorowanie
Ważną częścią administrowania każdą bazą danych jest monitorowanie. Jeśli czegoś nie monitorujesz, nie możesz tego zmierzyć. Jeśli nie wiesz, jakie są Twoje wskaźniki, gdy wszystko działa normalnie, skąd będziesz wiedzieć, które rzeczy są gorsze, gdy wydajność jest obniżona? Dzięki lokalnym bazom danych dysponujemy narzędziami, z którymi jesteśmy zaznajomieni:SQL Server Management Studio, Performance Monitor, Task Manager, DMV i tak dalej. Kiedy przenosimy nasze bazy danych do wersji 12, tracimy możliwość monitorowania z perspektywy systemu operacyjnego, a inne koncepcje też się nieco zmieniają. Mamy teraz do pracy tę metrykę o nazwie DTU, która oznacza jednostki transakcji bazy danych. Pomyśl o tym jako o kombinacji procesora, danych i logów transakcji we/wy oraz pamięci. Portal Azure zawiera wykres monitorowania, w którym domyślnie sprawdzana jest wartość procentowa jednostek DTU. Możesz edytować ten wykres, aby uwzględnić dodatkowe metryki, takie jak:
- Zablokowane przez zaporę sieciową
- Procent procesora
- Limit DTU
- Używane DTU
- % danych we/wy
- Rozmiar bazy danych %
- Zakleszczenia
- Nieudane połączenia
- W pamięci OLTP %
(wersja zapoznawcza)
- Prot. we/wy dziennika
- Sesje %
- Pomyślne połączenia
- Całkowity rozmiar bazy danych
- Pracownicy %
Jako minimum dodałbym procent procesora, procent we/wy danych, zakleszczenia i procent rozmiaru bazy danych. Obecnie ten wykres przedstawia poprzednią godzinę wykorzystania zasobów.
Monitorowanie przez DMV niewiele się zmieniło, poza wprowadzeniem kilku nowych DMV związanych z indywidualnymi metrykami bazy danych i sposobem obliczania rozmiaru bazy danych. Jeden z moich poprzednich artykułów tutaj, Wprowadzenie do dostrajania wydajności w Azure SQL Database, obejmuje niektóre różnice w typowych skryptach używanych do zbierania opóźnień dysku i statystyk oczekiwania w odniesieniu do Azure SQL Database.
Narzędzia innych firm również zaczęły dołączać zaczepy do Azure SQL Database, takie jak SentryOne z DB Sentry. DB Sentry daje możliwość monitorowania wydajności i zarządzania zdarzeniami występującymi w systemie. Jedną z fajnych funkcji jest funkcja Top SQL, która pozwala zobaczyć zapytania, które mają największy wpływ na ogólną wydajność, dzięki czemu można dostroić/naprawić wszelkie problemy z tym zapytaniem. Innym jest tworzenie wykresów DTU w czasie i wizualizowanie tego na pulpicie nawigacyjnym wraz z innymi ważnymi metrykami.
 Najlepszy SQL w kliencie SentryOne |  Użycie jednostek DTU w panelu DB Sentry |
Te metryki są przechowywane w dedykowanej bazie danych, co zapewnia możliwość tworzenia linii bazowych i zmiany trendów wydajności w czasie, co jest znacznie lepsze niż ograniczone wykresy, które obecnie otrzymujesz w Azure Portal.
Podsumowanie
Migracja do Azure SQL Database V12 ma wiele zalet, jeśli Twoja baza danych jest zgodna, więc skorzystaj z jednego z dostępnych narzędzi, aby sprawdzić zgodność z V12. Jeśli Twoja baza danych jest zgodna lub można ją łatwo zmodyfikować, aby stała się zgodna, możesz łatwo przeprowadzić migrację do Azure SQL Database V12 i rozpocząć testowanie oraz testowanie aplikacji i obciążeń.
