Sqlserver
 sql >> Baza danych >  >> RDS >> Sqlserver

Rozciągnij bazę danych w SQL Server 2016 RTM

W sierpniu 2015 napisałem artykuł przedstawiający nową funkcję bazy danych Stretch w SQL Server 2016. W tym artykule omawiałem, jak rozpocząć pracę z bazą danych Stretch w SQL Server 2016 Community Technology Preview 2 (CTP2). SQL Server 2016 został wydany 1 czerwca 2016 r. i pojawiło się wiele aktualizacji produktu. Metoda konfiguracji bazy danych Stretch uległa niewielkim zmianom, podobnie jak niektóre funkcje.

Począwszy od SQL Server 2016 zyskaliśmy możliwość przechowywania części bazy danych w Azure SQL Database. We wcześniejszych podglądach, gdy włączono funkcję Stretch dla bazy danych, trzeba było migrować całą tabelę, w wersji RTM SQL Server 2016 można teraz wybrać część tabeli. Po włączeniu rozciągania dla tabeli nastąpi dyskretna migracja danych. Jeśli nie znasz usługi Stretch Database, wykorzystuje ona moc obliczeniową platformy Azure do uruchamiania zapytań na zdalnych danych przez przepisanie zapytania. Nie musisz przepisywać żadnych zapytań po swojej stronie. Zobaczysz to jako operator „zdalnego zapytania” w planie zapytania.

Prostym sposobem identyfikacji baz danych i tabel, które kwalifikują się do obsługi funkcji Stretch, jest pobranie i uruchomienie Doradcy uaktualnienia programu SQL Server 2016 i uruchomienie Doradcy bazy danych Stretch. Aaron Bertrand (@AaronBertrand) napisał o tym jakiś czas temu. Doradca uaktualnień zmienił się nieco od czasu posta Aarona, jednak proces jest w większości taki sam:

  • Zidentyfikuj tabele kandydatów dla rozciągniętych baz danych SQL Server 2016
Ograniczenia dla bazy danych Stretch

Nie wszystkie stoły będą kwalifikować się do włączenia funkcji rozciągania. Niektóre właściwości tabel, typy danych i kolumn, ograniczenia i indeksy nie są obsługiwane, na przykład:

  • Tabele zoptymalizowane pod kątem pamięci i replikowane
  • Tabele zawierające dane FILESTREAM, użyj śledzenia zmian lub przechwytywania zmian danych
  • Typy danych, takie jak znacznik czasu, sql_variant, XML lub geografia
  • Sprawdź lub domyślne ograniczenia
  • Ograniczenia kluczy obcych, które odwołują się do tabeli
  • XML, pełnotekstowe, przestrzenne lub klastrowane indeksy magazynu kolumn
  • Zindeksowane widoki odwołujące się do tabeli
  • Nie można uruchomić instrukcji UPDATE lub DELETE ani wykonać operacji CREATE INDEX lub ALTER INDEX na tabeli obsługującej rozciąganie

Pełną listę ograniczeń można znaleźć na stronie:Wymagania i ograniczenia bazy danych Stretch.

Konfigurowanie bazy danych stretch

Rozpoczęcie pracy z wersją RTM jest nieco inne niż wcześniejsze wersje zapoznawcze. Będziesz potrzebować konta platformy Azure, a następnie musisz włączyć bazę danych rozciągania w wystąpieniu lokalnym.

Aby włączyć bazę danych rozciągania na instancji, uruchom:

EXEC sys.sp_configure N'remote data archive', '1';
RECONFIGURE;
GO

Do tego demo użyję utworzonej przeze mnie przykładowej bazy danych o nazwie STRETCH. Zacząłem, klikając prawym przyciskiem myszy bazę danych, wybierając Zadania, Rozciągnij, a następnie wybierając Włącz. To było przy użyciu programu SQL Server 2016 Management Studio.

Następny ekran pokazuje, które tabele chcesz włączyć dla funkcji Stretch:

Wybrałem stół SALES2. Kreator domyślnie wyświetla „Cała tabela”, ale możesz również zmienić tę opcję, aby przeprowadzić migrację podzbioru wierszy.

Jeśli wybierasz według wierszy, musisz wybrać nazwę kryteriów, a następnie możesz wybrać kolumnę, która ma być użyta w instrukcji where, a także warunek i wartość. Na tym zrzucie ekranu wybrałem wiersze sprzed 2016 r. Możliwość wybrania części tabeli to ogromna poprawa w porównaniu z wcześniejszymi podglądami, które pozwalały tylko na rozciągnięcie całej tabeli. Dla uproszczenia w tym demo zamierzam przeprowadzić migrację całej tabeli, więc kliknąłem Anuluj, a następnie Dalej.

Po wybraniu tabel i warunków musisz wybrać subskrypcję platformy Azure, której będziesz używać, region platformy Azure oraz informacje o serwerze.

Po wprowadzeniu wymaganych informacji kliknij Dalej.

Nowe ulepszenie wykorzystuje klucz główny bazy danych do ochrony poświadczeń platformy Azure w celu nawiązania połączenia z platformą Azure. Jeśli nie masz jeszcze klucza głównego, zostaniesz poproszony o jego utworzenie, jeśli już go masz, będziesz musiał podać hasło. Kliknij Dalej.

Będziesz musiał utworzyć regułę zapory dla swojego serwera lub wprowadzić zakres adresów IP podsieci. Dokonaj wyboru i kliknij Dalej.

To jest moment, w którym rzeczy naprawdę się zmieniły i sprawią, że ponownie rozważę korzystanie z tej funkcji. Firma Microsoft stworzyła jednostkę rozciągania bazy danych (DSU), dzięki której można skalować w górę lub w dół poziom wydajności potrzebny do danych rozciągania. Od czerwca 2016 r. aktualne ceny dotyczą zarówno zasobów obliczeniowych, jak i magazynu, co widać na powyższym obrazku. W przypadku mojej tabeli 15 MB, która została zmigrowana, zapłaciłbym 61 USD miesięcznie za pamięć, a także minimalny poziom DSU (100) wynoszący 912,50 USD miesięcznie. Poziomy DSU wahają się od:

Poziom DSU Koszt godzinowy Maksymalny koszt miesięczny
(miesiące z 31 dniami)
100 1,25 USD 930 USD
200 2,50 USD 1860 USD
300 3,75 USD 2790 USD
400 5,00 USD 3720 USD
500 6,25 USD 4,650 USD
600 7,50 USD 5,580 USD
1000 12,50 USD 9300 USD
1200 15,00 USD 11 160 USD
1500 18,75 USD 13 950 USD
2000 25,00 USD 18 600 USD

Dlaczego kreator powiedział mi tylko 912,50 USD, podczas gdy arkusz cen wskazuje, że powinno to być 900 USD w czerwcu (lub proporcjonalnie na podstawie liczby dni pozostałych w czerwcu)? Twoje przypuszczenia są równie dobre jak moje; Próbowałem różnych rzeczy matematycznych i wyszedłem pusty. Możesz dowiedzieć się więcej o modelach cenowych tutaj:

  • Cennik bazy danych SQL Server Stretch

Przed zapoznaniem się z nową metodą rozliczeń dla DSU mógłbym wysunąć argument, że użycie bazy danych Stretch byłoby bardzo opłacalną metodą przechowywania zimnych danych (niewykorzystanych danych) w chmurze. Rozciągając te dane na platformę Azure, możesz przeprowadzić migrację dużej części starszych danych, co zmniejszyłoby rozmiar (a tym samym koszt) lokalnych kopii zapasowych. Gdybyś musiał przywrócić bazę danych, musiałbyś po prostu nawiązać połączenie z Azure dla rozciągniętych danych, eliminując w ten sposób potrzebę ich przywracania. Jednak przy minimalnym koszcie wynoszącym prawie 1000 USD miesięcznie w przypadku niższej skali DSU, wiele organizacji stwierdzi, że znacznie taniej jest przechowywać dane na tańszej warstwie pamięci masowej w ich centrum danych i znaleźć inne metody HA, takie jak dublowanie, wysyłanie dzienników lub grupy dostępności.

Kliknij Zakończ, aby rozpocząć migrację.

Gratulacje, przeprowadziłem migrację tabeli SALES2 do bazy danych Azure SQL

Wyłącz tabelę rozciągania

We wczesnych podglądach bazy danych Stretch, jeśli chcesz wyłączyć tabelę Stretch, musisz utworzyć nową tabelę i wstawić do niej dane dotyczące rozciągania. Po skopiowaniu wszystkich danych należałoby albo ręcznie przełączyć tabele, zmieniając ich nazwy, albo ręcznie scalić rozciągnięte dane z powrotem do tabeli produkcyjnej. W wersji RTM nadal możesz ręcznie obsługiwać migrację, zdecydować się na pozostawienie danych na platformie Azure lub wybrać opcję przywrócenia danych z platformy Azure.

Bez względu na to, której metody używasz do przywrócenia danych, ponosisz opłaty za transfer danych.

Tworzenie kopii zapasowej i przywracanie rozciągniętej bazy danych

Po przeprowadzeniu migracji danych do bazy danych Stretch platforma Azure obsługuje kopię zapasową danych Stretch. Kopie zapasowe są tworzone z migawką wykonywaną co 8 godzin, a migawki są przechowywane przez 7 dni. Daje to do 21 punktów w czasie w ciągu ostatnich 7 dni na przywrócenie.

Nie musisz wprowadzać żadnych zmian w bieżących lokalnych procedurach tworzenia kopii zapasowych. Wszelkie lokalne kopie zapasowe będą zawierać wszystkie dane lokalne i odpowiednie dane, które nie zostały jeszcze przeniesione. Nazywa się to płytką kopią zapasową i nie zawiera żadnych danych już przeniesionych na platformę Azure.

DBCC CHECKDB

Nie możesz również uruchomić CHECKDB z danymi, które zostały zmigrowane na platformę Azure.

Kiedy uruchomiłem DBCC CHECKDB na mojej bazie danych STRETCH przed migracją, otrzymałem następujące wyniki dla tabeli SALES2:

Wyniki DBCC dla „SALES2”.
Istnieje 45860 wierszy na 1901 stronach dla obiektu „SALES2”.

Po migracji otrzymałem następujące dane wyjściowe dla tabeli SALES2 (podkreślenie moje):

Wyniki DBCC dla „SALES2”.
Istnieją 0 wierszy na 1901 stronach dla obiektu "SPRZEDAŻ2".

Możesz uruchomić DBCC CHECKDB w Azure SQL Database, jednak ze względu na brak możliwości bezpośredniego połączenia z rozciągniętą Azure SQL Database, obecnie nie można ręcznie uruchomić DBCC CHECKDB w odniesieniu do rozciągniętych danych. Nie mogę znaleźć żadnej dokumentacji, która stwierdza, że ​​platforma Azure przeprowadza kontrole spójności względem tych baz danych.

Moim zdaniem niesie to ze sobą znaczne ryzyko.

Podsumowanie

Stretch Database to łatwy sposób na migrację danych archiwalnych do Microsoft Azure, jeśli Twoja baza danych to obsługuje. Obecnie w SQL Server 2016 RTM istnieje wiele ograniczeń dotyczących właściwości tabeli, danych i kolumn, typów danych i kolumn, ograniczeń i indeksów. Jeśli nie ograniczają Cię te ograniczenia, funkcja Stretch Database to prosty sposób na migrację danych historycznych do usługi Azure SQL Database w celu zwolnienia magazynu lokalnego i skrócenia czasu przywracania tych baz danych, jeśli jest to opłacalne. Musisz także czuć się komfortowo, przynajmniej na razie, nie mając możliwości uruchomienia DBCC CHECKDB na żadnych migrowanych danych. Zarządzanie przywracaniem będzie nieco trudniejsze, ponieważ trzeba będzie przywrócić połączenie między bazą danych SQL Server a zdalną bazą danych Azure.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Funkcja IndexOf w T-SQL

  2. Wykonaj dynamiczne zapytanie za pomocą go w sql

  3. Jak naprawić „Konwersja nie powiodła się podczas konwersji wartości na typ danych” w SQL Server

  4. Odpytywanie danych poprzez łączenie dwóch tabel w dwie bazy danych na różnych serwerach

  5. Tymczasowe buforowanie obiektów SQL Server