Korzystanie z portalu zarządzania SQL Database . Projektowanie tabel i relacji . Wstawianie danych . Odpytywanie bazy danych . Poznawanie dodatkowych możliwości portalu .
2 Konfiguracja i ceny. .................................................................................................... 33 Korzystanie z portalu zarządzania platformą Microsoft Azure . . . . . . . . . . . . . . . Tworzenie nowej bazy danych . Ustawianie reguł zapory . Uzyskiwanie łańcucha połączenia . Usuwanie bazy danych . Korzystanie z SQL Server Management Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . Łączenie się z SQL Database. Tworzenie nowej bazy danych . Zmienianie wydania i maksymalnego rozmiaru bazy danych . Usuwanie bazy danych .
33 33 37 41 42 43 44 46 47 47
Korzystanie z PowerShell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Instalowanie poleceń cmdlet dla Microsoft Azure . Korzystanie z PowerShell ISE . Konfigurowanie PowerShell dla konta Microsoft . Tworzenie nowego serwera . Tworzenie nowej bazy danych . Usuwanie bazy danych .
47 49 50 51 52 53 iii
iv
Spis treści
Planowanie budżetu dla SQL Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Magazyn SQL . Pasmo klienckie . Magazyn dla kopii zapasowych . Pasmo magazynu kopii zapasowych . Wsparcie . Optymalizacja kosztów . Konfigurowanie wydania i rozmiaru bazy danych .
icrosoft Azure SQL Database to działająca w chmurze wersja Microsoft SQL Server, czyli doskonale znanej platformy relacyjnej bazy danych. Niezależnie od pewnych wartych odnotowania różnic, SQL Database (krótsza nazwa Microsoft Azure SQL Database) jest w większości kompatybilna z SQL Server, zatem doświadczenie już zdobyte przy pracy z SQL Server może być w znacznym stopniu bezpośrednio zastosowane w SQL Database. Jeśli jesteś profesjonalistą od oprogramowania, rozważającego wykorzystanie chmury jako platformy dla bazy danych w swojej kolejnej aplikacji, SQL Database może być właśnie tym narzędziem, którego potrzebujesz. A jeśli chcesz szybko dołączyć do tej rozwijającej się platformy, bez względu na to, czy masz już jakieś doświadczenia z SQL Server, czy nie, ta książka na pewno w tym pomoże. Microsoft Azure SQL Database krok po kroku proponuje uporządkowaną wycieczkę po platformie SQL Database. Naszym celem było pokazanie SQL Database od początku do końca z zachowaniem rozsądnej równowagi pomiędzy zakresem tematyki i zagłębianiem się w szczegóły. W pierwszym rozdziale szybko utworzymy pierwszą bazę danych w Microsoft Azure. Do końca ostatniego rozdziału zbudujemy pełne, wielowarstwowe rozwiązanie bazodanowe w chmurze – obejmujące witrynę Web i aplikację dla Windows Phone 8 – w pełni oparte na SQL Database. W każdym z rozdziałów będziemy poznawali inne oblicze SQL Database i wiele z towarzyszących jej technologii. SQL Database to rozległy temat, ale staraliśmy się tak skonstruować każdy rozdział, aby zajmować się tylko jedną rzeczą na raz i pokazywać łatwe do naśladowania procedury, które pozwalają przenieść wyrafinowane koncepcje na bezpośrednie zastosowania praktyczne. Nasza wiedza będzie rosła w każdym rozdziale w miarę poznawania zagadnień konfigurowania, migracji, zabezpieczeń, kopii zapasowych i wielu innych. Wielka różnica pomiędzy oprogramowaniem działającym lokalnie (w siedzibie firmy – on-premises) a usługami w chmurze polega na tym, że tę drugą można aktualizować i rozbudowywać znacznie częściej i prościej, niż pierwszą, jako że w przypadku chmury nie jest wymagana żadna instalacja czy tworzenie infrastruktury klienckiej. Z drugiej strony usługi w chmurze podlegają również częstym zmianom, jeśli chodzi o ich cenę. Z tych względów funkcje, ograniczenia, koszty, interfejs użytkownika, a nawet sama nazwa Microsoft Azure SQL Database, opisane w tej książce, mogą zmienić się do czasu, gdy książka trafi do rąk Czytelnika. Na przykład, krótko przed skierowaniem książki do druku platforma nazywana wcześniej Windows Azure została przemianowana na Microsoft Azure. (Choć tytuł książki i tekstowe odsyłacze zostały odpowiednio zaktualizowane, wiele zrzutów ekranowych nadal pokazuje starszą ix
x
Wprowadzenie
nazwę Windows Azure). Jednak niezależnie od potencjalnych zmian tego rodzaju zasady i techniki omawiane w książce pozwolą osiągnąć poziom sprawnego posługiwania się Microsoft Azure SQL Database. Uwaga W miarę ewolucji platformy Azure zmieniamy się wraz z nią. Choć pierwsze wydanie dopiero zostało wysłane do druku, pracujemy intensywnie nad następnym wydaniem z rozszerzonym omówieniem nowo przedstawionych (zapowiedzianych) wydań Basic, Standard i Premium. Te nowe warstwy usługi (których dostępność była jeszcze ograniczona do wersji testowej w chwili pisania tych słów) pozwalają obsłużyć większe i bardziej skalowalne bazy danych, niż oferowane przez obecne wydania Web i Business. Kolejne wydanie zostanie również uzupełnione o nowy portal zarządzania, który jest obecnie opracowywany przez firmę Microsoft.
Kto powinien przeczytać tę książkę Książka ta ma pomóc deweloperom oprogramowania i profesjonalistom bazodanowym zrozumieć podstawowe koncepcje Microsoft Azure SQL Database i powiązane z nią technologie. Czytelnicy mogą nie mieć żadnego lub tylko niewielkie doświadczenie w pracy z SQL Server i nie stanowi to żadnego problemu. Naszą wycieczkę rozpoczynamy od samego początku i zapewniamy dobry punkt startowy, nawet jeśli Czytelnik nie dysponuje żadną wiedzą o SQL Server lub koncepcjach relacyjnych baz danych. Książka będzie też użyteczna dla osób, które dobrze znają lokalne instalacje SQL Server i są zainteresowane tworzeniem nowych aplikacji wykorzystujących SQL Database lub tych, którzy chcą przenieść istniejące rozwiązania działające lokalnie do chmury.
Założenia Nie zakładamy ani nie wymagamy żadnego wcześniejszego doświadczenia ani wiedzy dotyczącej Microsoft Azure (i w ogólności – przetwarzania w chmurze). Co więcej, choć znajomość Microsoft SQL Server na pewno jest przydatna, również nie jest wymagana. Kilka rozdziałów odwołuje się do programowania na platformie .NET. Także w tym przypadku wcześniejsze doświadczenia w pracy z Microsoft Visual Studio i językiem C# będzie pomocne, ale niekonieczne. Procedury zawarte w tych rozdziałach zawierają cały potrzebny kod wraz z jasnym wyjaśnieniem jego działania.
Ta książka może nie być odpowiednia, jeśli…
Ta książka może nie być odpowiednia, jeśli… Książka ta nie jest przeznaczona dla osób, które już mają rozległą wiedzę i doświadczenie w pracy z SQL Database i szukają pogłębionych informacji o wewnętrznych mechanizmach lub innych specjalistycznych zagadnieniach, które nie zostały przedstawione w tej książce. Tym niemniej książka nadal zawiera informacje, które mogą się okazać użyteczne także dla doświadczonych użytkowników. Z tego względu sugerujemy przejrzeć omówienia poszczególnych rozdziałów w kolejnym podrozdziale.
Organizacja książki Książka zawiera dziesięć rozdziałów, z których każdy skupia się na innym aspekcie Microsoft Azure SQL Database. Większość Czytelników powinna rozpocząć od rozdziału 1 i posuwać się dalej konsekwentnie, ale można też sobie wyobrazić czytanie w dowolnie wybranej kolejności. W każdym przypadku Czytelnik znajdzie praktyczne wskazówki i sposoby postępowania, które pomogą wykonać pracę z SQL Database. ■
■
■
Rozdział 1 – Poznajemy Microsoft Azure SQL Database
Otwierający rozdział zawiera ogólny przegląd platformy SQL Database. Po krótkim omówieniu przetwarzania w chmurze utworzymy konto Microsoft (o ile Czytelnik jeszcze go nie ma) i próbną (bezpłatną) subskrypcję Microsoft Azure. Następnie nauczymy się, jak posługiwać się portalem zarządzania Microsoft Azure do tworzenia serwerów i baz danych. Później przejdziemy do korzystania z portalu zarządzania SQL Database, w którym będziemy projektować tabele, widoki i procedury składowane, a następnie wypełniać tabele przykładowymi danymi i wykonywać zapytania. Żadne narzędzia lokalne nie są wymagane, aby przejść wszystkie procedury zawarte w tym rozdziale; wszystko, czego potrzebujemy, to przeglądarka sieci Web i dostęp do Internetu. Rozdział 2 – Konfiguracja i ceny Po przedstawieniu podstaw ten rozdział wyjaśnia dodatkowe opcje konfigurowania SQL Database, wykraczające poza stosowanie przeglądarki i portali, omówione w rozdziale 1. Nauczymy się, jak połączyć się z SQL Database przy użyciu standardowych narzędzi lokalnych, takich jak SQL Server Management Studio (SSMS) oraz SQL Server Data Tools (SSDT), stanowiące część Visual Studio. Dowiemy się też, jak konfigurować i zarządzać SQL Database przy użyciu powłoki PowerShell, wykorzystując moduł poleceń cmdlet Microsoft Azure dla PowerShell. Rozdział kończy omówienie struktury kosztów dotyczących SQL Database i wskazówki pomagające w zaplanowaniu budżetu dla rozwiązania SQL Database. Rozdział 3 – Różnice pomiędzy SQL Server a Microsoft Azure SQL Database Czytelnicy dysponujący doświadczeniem w pracy z SQL Server będą chcieli poznać ważne różnice pomiędzy silnikiem relacyjnej bazy danych działającym w siedzibie firmy a implementacją SQL Database w chmurze Microsoft Azure. Ten
xi
xii Wprowadzenie
■
■
■
■
krótki rozdział zawiera wyliczenie tych różnic i wyjaśnia ich przyczyny. Tam, gdzie to możliwe, zasugerowaliśmy również obejścia dla funkcji SQL Server, które nie są wspierane w SQL Database. Rozdział 4 – Migrowanie baz danych Przy budowaniu systemu mającego działać w chmurze Microsoft Azure często zachodzi potrzeba przeniesienia baz danych z istniejących serwerów SQL Server do SQL Database. Istnieje wiele technik i narzędzi, których można użyć w celu przemigrowania baz danych SQL Database. W tym rozdziale pokażemy wykorzystanie do tego celu skryptów Transact-SQL, mechanizmu SQL Data-Tier Applications, kopiowania masowego oraz kreatora SQL Database Migration Wizard. Rozdział 5 – Bezpieczeństwo i kopie zapasowe Bezpieczeństwo, dostępność i możliwość przywrócenia po awarii to czołowe pozycje na liście rzeczy, które klienci rozważają zastanawiając się nad korzystaniem z usług publicznej chmury. W tym rozdziale poznamy mechanizmy zabezpieczeń dostępne w Microsoft Azure. Pokażemy, jak zabezpieczyć bazę danych SQL Database przy użyciu reguł zapory, a także jak tworzyć użytkowników i przypisywać uprawnienia. Na koniec omówimy sposoby przywracania po awariach przy użyciu technik kopii zapasowych udostępnianych przez SQL Database. Rozdział 6 – Raportowanie w chmurze Jeśli mamy już bazę danych zawierającą jakieś informacje, jest tylko kwestią czasu, gdy pojawi się wymóg tworzenia raportów dotyczących tych danych. Gdy baza ta jest hostowana w chmurze Microsoft Azure, naturalne jest rozważenie umieszczenia w tej chmurze również rozwiązania raportującego. W tym rozdziale dowiemy się, jak utworzyć maszynę wirtualną (VM) w Azure, hostującą SQL Server Reporting Services (SSRS) w chmurze (nie jest wymagane wcześniejsze doświadczenie w pracy z SSRS). Po skonfigurowaniu VM pokażemy, jak budować raporty SSRS przy użyciu dwóch narzędzi autorskich: Report Builder oraz SSDT Business Intelligence dla Visual Studio. Po zbudowaniu i przejrzeniu raportów lokalnie nauczymy się, jak wdrożyć je na maszynie wirtualnej, aby zbudować pełne rozwiązanie działające w chmurze. Rozdział 7 – Microsoft Azure SQL Data Sync W tym rozdziale nauczymy się, jak wykorzystać usługę SQL Data Sync dostępną w Microsoft Azure do replikowania danych pomiędzy wieloma bazami danych. Poznamy architekturę gwiazdy, na której oparta jest usługa, a następnie pokażemy, jak wykorzystać usługę SQL Data Sync do implementowania rozwiązań w rozmaitych scenariuszach, w tym jedno- i dwukierunkowe replikacje w zbiorze baz danych rozmieszczonych w różnych lokalizacjach. Procedury w tym rozdziale poprowadzą Czytelnika poprzez proces konfigurowania usługi SQL Data Sync i tworzenia grup synchronizacji obejmujących zarówno bazy danych hostowane w chmurze (w Microsoft Azure SQL Database), jak i w siedzibie (używające SQL Server). Nauczymy się też, jak konfigurować strategię rozwiązywania konfliktów i włączyć harmonogram automatycznej synchronizacji.
Konwencje stosowane w książce
■
■
■
Rozdział 8 – Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności Aplikacje i systemy przeznaczone do rzeczywistych zastosowań pro-
dukcyjnych muszą zapewniać dobrą wydajność i niezawodność działania. W tym rozdziale zajmiemy się optymalizacją i dostrajaniem wydajności bazy danych w SQL Database. Następnie poprawimy stabilność aplikacji poprzez zarządzanie połączeniami bazy danych i obsługą błędów połączeń, wykorzystując zarówno ADO.NET, jak i platformę Entity Framework. Na koniec pokażemy, jak wykonać skalowanie bazy danych w SQL Database przy użyciu specjalnej techniki partycjonowania znanej jako sharding. Rozdział 9 – Monitorowanie i zarządzanie SQL Database Usługi używane w aplikacjach produkcyjnych muszą zapewniać możliwości monitorowania i zarządzania. W tym rozdziale dowiemy się, jak monitorować kondycję SQL Database przy użyciu portalu zarządzania, tablicy kontrolnej Microsoft Azure i dynamicznych widoków i funkcji zarządzania. Nauczymy się też, jak programowo zautomatyzować operacje w SQL Database przy użyciu opartego na standardzie REST komponentu Service Management API. Rozdział 10 – Budowanie rozwiązania w chmurze W końcowym rozdziale książki pokażemy budowanie kompletnego rozwiązania w chmurze, opartego na Microsoft Azure SQL Database. Mówiąc konkretnie, zbudujemy rozwiązanie Visual Studio, zawierające projekt bazodanowy SQL Server Database, warstwę dostępu do danych Entity Framework, witrynę ASP.NET MVC oraz usługę Web API. Rozwiązanie to będzie tworzyło witrynę do składania zamówień oraz usługi Web i aplikację Windows Phone 8 pozwalającą na odczytywanie, dodawanie i modyfikowanie danych przechowywanych w SQL Database.
Konwencje stosowane w książce Treści zawarte w książce wykorzystują kilka konwencji, które mają na celu zapewnić większą czytelność: ■
■
■
■
Każda procedura składa się z serii zadań przedstawianych jako numerowane kroki (1, 2 i tak dalej) wyliczające wszystkie akcje, które trzeba podjąć, aby ukończyć ćwiczenie. Elementy w ramkach, takie jak „Uwaga” lub „Wskazówka”, zawierają dodatkowe informacje lub alternatywne metody realizacji danego zadania. Tekst, który ma zostać wpisany przez Czytelnika (poza blokami kodu), jest wytłuszczony. Nazwy poleceń, elementów menu i opcji, które należy kliknąć lub które po prostu identyfikują elementy interfejsu, są wyróżnione czcionką bezszeryfową. Przy pierwszym użyciu jakiegoś terminu w nawiasie podawane jest jego tłumaczenie na język polski.
xiii
xiv Wprowadzenie
■
■
■
Nazwy elementów programowych, adresy internetowe oraz nowe lub ważne pojęcia prezentowane są kursywą. Znak plus (+) pomiędzy nazwami klawiszy oznacza, że klawisze te należy nacisnąć jednocześnie. Na przykład „Naciśnij Alt+Tab” oznacza, że klawisz Alt musi być przytrzymany, gdy naciskamy klawisz Tab. Pionowa kreska pomiędzy elementami menu (na przykład File | Close) oznacza, że należy wybrać pierwszy element menu, a następnie drugi z menu podrzędnego (i tak dalej, jeśli elementów jest więcej).
Wymagania systemowe Zasadniczo nie istnieją specjalne wymagania systemowe do pracy z SQL Database. Portal Microsoft Azure wymaga jedynie kompatybilnej przeglądarki Web oraz dostępu do Internetu. Korzystanie z portalu zarządzania SQL Database wymaga przeglądarki z zainstalowaną wtyczką Silverlight. Niektóre rozdziały zawierają procedury wykorzystujące narzędzia zainstalowane lokalnie – zazwyczaj SQL Server Management Studio (SSMS) oraz Visual Studio 2013. Aby wykonać te procedury, konieczne jest zainstalowanie tych programów, co oznacza spełnienie następujących wymagań: ■
■
■
System operacyjny Windows 7, Windows 8.*, Windows Server 2008 SP2, Windows Server 2008 R2 albo Windows Server 2012 (R2). Dowolne wydanie Visual Studio 2013 (przy korzystaniu z wydania Express konieczne może być pobranie wielu dodatkowych elementów). SQL Server 2012 Express Edition lub wyższa wersja, z komponentem SQL Server Management Studio 2012 Express lub wyższym. (SSMS jest zawarte w Visual Studio, ale wydanie Express wymaga oddzielnego pobierania).
Zależnie od konfiguracji systemu Windows, instalacja i konfiguracja Visual Studio 2013 i SQL Server 2012 mogą wymagać lokalnych uprawnień administratora. Rozdział 4, „Migrowanie baz danych " oraz 7, „Microsoft Azure SQL Data Sync”, zawierają procedury, które wymagają lokalnej instancji SQL Server, w której Czytelnik ma uprawnienia do tworzenia baz danych. Jeśli nie dysponuje się takim dostępem, można zainstalować oprogramowanie SQL Server Express Edition (darmową wersję SQL Server), wykonując instrukcje zawarte w kolejnym podrozdziale. Na koniec poszczególne rozdziały wykorzystują dodatkowe oprogramowanie, które trzeba zainstalować lokalnie. Rozdziały te zawierają szczegółowe procedury pobierania i instalowania tych programów, dzięki czemu możliwe jest wykonanie wszystkich zadań danego rozdziału.
Pobieranie: SQL Server Express Edition
Pobieranie: SQL Server Express Edition Istnieje wiele wersji SQL Server Express Edition dostępnych do pobrania z witryny firmy Microsoft, przy czym są one udostępnione zarówno jako wersje 32-, jak i 64-bitowe. Można wybrać instalację jedynie silnika bazy danych SQL Server Express (i niczego więcej) albo wybrać jeden z dwóch pozostałych (większych) pakietów: Express With Tools (zawierający SQL Server Management Studio [SSMS]) albo Express With Advanced Services (zawierający SSMS, Full Text Search i Reporting Services). Istnieją również oddzielne pakiety dla SSMS i LocalDB, ale nie zawierają one silnika bazy danych SQL Server Express, niezbędnego do hostowania lokalnych baz danych. Aby zainstalować silnik bazy danych SQL Server Express Edition, wykonaj poniższe kroki: 1 . Otwórz przeglądarkę Internet Explorer i przejdź do adresu http://www.microsoft.
com/en-us/download/details.aspx?id=29062. 2 . Kliknij wielki, pomarańczowy przycisk Download (pobierz). 3 . Zaznacz odpowiedni pakiet dla swojego systemu, jak na rysunku W-1: a . Dla systemu 64-bitowego wybierz ENU\x64\SQLEXPR_x64_ENU.exe. b . W przypadku systemu 32-bitowego (lub 64-bitowego, jeśli wolisz uruchamiać
aplikację jako WoW) wybierz ENU\x86\SQLEXPR32_x86_ENU.exe.
Uwaga Jeśli potrzebujesz pobrać również komponent SQL Server Management Studio (SSMS), wybierz plik Express With Tools, czyli taki, który w nazwie zawiera WT.
4 . Kliknij Next (dalej). 5 . Jeśli pojawi się monit ostrzeżenia, kliknij Allow Once (Zezwalaj raz), jak na rysun-
ku W-2.
Rysunek W-2 Tymczasowe zezwalanie na okno wyskakujące w celu umożliwienia pobierania w razie potrzeby
6 . W monicie z zapytaniem, czy uruchomić, czy zapisać plik, wybierz Run (Uruchom).
Spowoduje to rozpoczęcie pobierania. 7 . Jeśli pojawi się okno kontroli konta użytkownika po rozpakowaniu pobranych
plików, kliknij Yes (Tak). 8 . W oknie SQL Server Installation Center (Centrum instalacji SQL Server) kliknij opcję New SQL Server Stand-Alone Installation (Nowa samodzielna instalacja SQL Server),
jak na rysunku W-3.
Rysunek W-3 Wybieranie nowej instalacji SQL Server
Pobieranie: Przykłady kodu z książki
9 . W kreatorze instalacji SQL Server 2012 Setup wykonaj poniższe działania: a . Na stronie License Terms zaznacz pole wyboru I Accept The License Terms (akcep-
tuję warunki licencji) i kliknij Next. b . Na stronie Product Updates (aktualizacje produktu) zezwól kreatorowi na wyko-
nanie skanowania w poszukiwaniu aktualizacji, po czym kliknij Next. c . Na stronie Install Setup Files (instalowanie plików) zaczekaj, aż instalacja się
zakończy. d . Na stronie Feature Selection zaakceptuj domyślne ustawienia, klikając Next. e . Kontynuuj zatwierdzanie domyślnych ustawień na kolejnych stronach,
aż do strony Installation Progress (postęp instalacji) i zaczekaj na zakończenie procesu. f . Na stronie Complete wskazującej udaną instalację (rysunek W-4) kliknij Close.
Rysunek W-4 Zakończona instalacja SQL Server Express
Pobieranie: Przykłady kodu z książki Wiele rozdziałów zawiera procedury, w których konieczne będzie wpisanie jakiegoś kodu. W większości przypadków są to tylko krótkie fragmenty, ale nadal wygodne będzie pobranie pełnych listingów z witryny powiązanej z książką. W ten sposób łatwiejsze będzie wykonanie procedur, szczególnie tych, w których występuje nieco
xvii
xviii Wprowadzenie
więcej kodu do wpisania. Wszystkie fragmenty kodu występujące w książce można pobrać z poniższej strony: http://aka.ms/AzureSQLDB_SBS
Instalowanie i używanie przykładów kodu Jeśli na pokazanej wyżej stronie nie jest widoczne łącze Companion Content (powiązana zawartość), należy kliknąć przycisk other format (inne formaty) a następnie Companion Content. Pobrany plik zip należy rozpakować. Znajdziemy w nim po jednym folderze dla każdego rozdziału, choć można zauważyć, że nie istnieją żadne przykłady kodu dla rozdziałów 2 i 3. Foldery zawierają pliki .txt odpowiadające numerom listingów w poszczególnych rozdziałach oraz pliki .sql dla procedur składowanych. Dodatkowo foldery dla rozdziałów 6, 8 i 10 zawierają również gotowe (skończone) rozwiązania Visual Studio dla ćwiczeń zawartych w tych rozdziałach.
Podziękowania Po raz pierwszy poproszono mnie o napisanie książki o SQL Azure – wówczas jeszcze ciągle nazywało się to SQL Azure – blisko dwa lata temu. Od tego momentu przebyliśmy długą drogę i pomimo trzęsień ziemi zarówno po stronie platformy produktu Azure, jak i ekosystemu wydawniczego (nie wspominając o innych niespodziankach) szczęśliwie udało nam się dotrzeć do celu! Jest to moja trzecia książka techniczna i choć każde doświadczenie było unikatowe, z każdej z nich nauczyłem się tego samego: nie można nawet zastanawiać się nad wyzwaniem, jakim jest napisanie książki, bez wsparcia i pomocy licznych, starannych i utalentowanych osób. Są to ci ludzie, którzy zasługują na szczególne wyróżnienie – ci, którzy pomagali mi na tak wiele sposobów, że nie jestem w stanie ustawić ich nazwisk w żadnym sensownym porządku. Zacznę od Andrew Brusta. Gdyby nie on (a sam jest niekwestionowanym liderem w branży oprogramowania), w ogóle nie zabrałbym się za pisanie książek. Jestem wdzięczny za osobistą przyjaźń, jak i za wspólną pracę przy pisaniu i prezentowaniu warsztatów. Te doświadczenia pomogły mi się rozwinąć i urosnąć. Miałem też szczęście pracować wspólnie z moim kolegą i współautorem, Erikiem Boydem, który napisał cztery rozdziały poświęcone bardzo zaawansowanej tematyce. Eric jest niezwykle utalentowanym programistą, którego doświadczenie i pasja są jawnie widoczne w pisanych przez niego słowach. Nie można zapomnieć o tych, których wysiłek pozwolił przekształcić surowy tekst w gotową książkę. Russell Jones, mój kumpel z O’Reilly Media, zajmuje specjalną pozycję, gdyż to on namówił mnie do napisania tej książki. Muszę mu podziękować nie tylko za tę okazję, ale również za wskazówki i pomoc podczas przechodzenia
Errata, poprawki i wsparcie dla książki
do Microsoft Press. Jeszcze więcej podziękowań otrzymuje Roger LeBlanc za redakcję tekstu i Scott Klein za recenzję techniczną. Nie mogę też pominąć Devona Musgrave i Rosemary Caperton z Microsoft Press oraz Steve’a Sagmana z Waypoint Press. Ich wskazówki były kluczowe dla udanego ukończenia tej książki. Książka ta nie mogłaby powstać bez wsparcia i miłości mojej rodziny. Dziękuję za to, że byliście tak cierpliwi i tolerancyjni dla mnie, gdy pracowałem nad tym projektem. Leonard Lobel Od blisko dwudziestu lat pracuję przy projektowaniu oprogramowania i jestem wdzięczny za to, że miałem możliwość tworzenia, uczenia się i poznawania niekiedy bardzo złożonych, ale fascynujących zagadnień. Pisanie książki takiej jak ta było kolejnym wyzwaniem i nie podołałbym mu bez pomocy i wsparcia wielu ludzi. Praca nad tym projektem sprawiła mi wiele radości, ale pochłonęła też wiele czasu. Podziękować muszę przede wszystkim mojej żonie Shelly za wszystko, co robi dla naszej rodziny. Chcę też podziękować przyjaciołom i współpracownikom za ich wsparcie podczas tej pracy. Oczywiście, ważne miejsce zajmuje Lenni Lobel, który zaprosił mnie do dołączenia do tego projektu. Lenni jest fantastycznym współautorem i wykonał świetną robotę, prowadząc ten projekt aż do ukończenia. Jego wskazówki i pomoc w znajdowaniu właściwego formułowania myśli były niezwykle cenne zarówno dla mnie samego, jak i dla całego projektu. Na koniec, ale na pewno nie najmniej ważne, są wszystkie osoby w firmie Microsoft i Microsoft Press, które pomagały w realizacji tego projektu. Lista ta (niewątpliwie niekompletna) obejmuje Scotta Kleina, Dorę Chan, Marka Browna, Devona Musgrave, Rosemary Caperton, Steve’a Sagman, Conora Cunninghama i cały zespół Azure CAT. Eric Boyd
Errata, poprawki i wsparcie dla książki Dołożyliśmy wszelkich starań, aby zagwarantować poprawność tej książki i powiązanej z nią zawartości. Aktualizacje do tej książki w formie erraty zawierającej zgłoszone usterki i ich poprawki są dostępne na karcie Errata & Updates strony internetowej dotyczącej książki pod adresem: http://aka.ms/AzureSQLDB_SBS W razie zauważenia błędu, który nie jest jeszcze wymieniony, można go zgłosić za pośrednictwem tej samej strony. Dodatkową pomoc można uzyskać z działu Microsoft Press Book Support pod adresem [email protected].
xix
xx Wprowadzenie
Prosimy zauważyć, że wsparcie dotyczące oprogramowania i sprzętu firmy Microsoft nie jest oferowane pod powyższymi adresami. Pomoc dotyczącą produktów firmy Microsoft można uzyskać pod adresem http://support.microsoft.com.
Czekamy na uwagi Najwyższym priorytetem wydawnictwa Microsoft Press jest zadowolenie Czytelników, a ich opinie są dla nas niezwykle cenne. Prosimy o przekazywanie uwag w witrynie: http://aka.ms/tellpress Ankieta jest krótka, a my czytamy wszystkie przysłane do nas spostrzeżenia i pomysły. Z góry dziękujemy za wszystkie wpisy!
Pozostańmy w kontakcie Niech dyskusja trwa! Jesteśmy na Twitterze: http://twitter.com/MicrosoftPress.
ROZDZI AŁ 1
Poznajemy Microsoft Azure SQL Database Leonard Lobel
W
tym rozdziale wspólnie z Czytelnikiem utworzymy pierwszą bazę danych na platformie Microsoft Azure SQL Database – całkowicie od zera. Należy przez to rozumieć, że wszystko, co będzie potrzebne, aby wykonać opisane tu zadania, to przeglądarka sieci Web (w tym rozdziale użyty został Internet Explorer) oraz dostęp do Internetu. Czytelnik uzyska konto Microsoft (jeśli go jeszcze nie ma) i posłuży się nim w celu utworzenia i uzyskania dostępu do darmowej próbnej subskrypcji usługi Microsoft Azure. Następnie poznamy portal zarządzający Microsoft Azure, a następnie zapewnimy, aby serwer i baza danych rozpoczęły działanie w chmurze. Na koniec posłużymy się portalem zarządzania SQL Database do zaprojektowania, wypełnienia i odpytywania bazy danych. Uwaga W tej książce będziemy się zazwyczaj odwoływać do Microsoft Azure SQL Database jako do SQL Database. Termin SQL Server będzie zawsze oznaczał instancje bazy danych zainstalowane w siedzibie firmy (on-premises), podczas gdy SQL Database oznacza zawsze bazę danych opartą na chmurze Microsoft Azure.
Choć książka ta koncentruje się głównie na Microsoft Azure SQL Database, powinna być pomocna w poznawaniu szerszego kontekstu platformy Microsoft Azure i w ogólności przetwarzania w chmurze. Wiedza taka pozwoli lepiej zrozumieć wartość SQL Database. Tak więc, zanim zajmiemy się tworzeniem konta Microsoft, pozwolę sobie na skrótowe omówienie przetwarzania w chmurze ze szczególnym uwzględnieniem usługi Microsoft Azure.
1
2
Rozdział 1: Poznajemy Microsoft Azure SQL Database
Przetwarzanie w chmurze: przedstawienie pojęcia Microsoft Azure to należąca do firmy Microsoft platforma przetwarzania w chmurze (cloud-computing). Jednak czym właściwie jest przetwarzanie w chmurze? Problem w tym, że nie istnieje precyzyjna definicja. W rzeczywistości termin ten jest niejednoznaczny. Istnieje dziś wiele różnych typów usług, które działają „w chmurze”. Zasadniczo termin przetwarzanie w chmurze odnosi się do ewolucji, jaką przeszły internetowe usługi hostingowe, prowadząc do sytuacji, w której dostawcy (tacy jak Microsoft, Google, Amazon i wielu innych) oferują indywidualnym konsumentom i firmom usługi realizowane na sprzęcie zapewniającym niezbędną nadmiarowość, przy czym obsługa tych systemów jest częściowo lub w pełni zautomatyzowana (z punktu widzenia klienta). Ten poziom usług znacznie wykracza poza tradycyjny hosting internetowy, który pojawił się wraz z „bąblem dot-comów” w latach dziewięćdziesiątych XX wieku. W przypadku przetwarzania w chmurze Internet nie jest już jedynie używany jako medium dla udostępniania informacji. W istocie chmura wykorzystuje Internet jako sposób łączenia klientów z różnymi usługami infrastruktury, platformy lub aplikacji na znacznie większym poziomie elastyczności i abstrakcji, niż możliwy do zaoferowania przez wcześniej stosowane schematy hostingu. Jedną z najwcześniejszych platform przetwarzania w chmurze były Amazon Web Services (AWS), wprowadzone w 2002 roku przez Amazon.com. Także dziś AWS jest jednym z głównych graczy w branży przetwarzania w chmurze. Począwszy od połowy pierwszej dekady XXI wieku przetwarzanie w chmurze zaczęło szybko zdobywać popularność i w roku 2009 firma Microsoft zaprezentowała swoje rozwiązanie Windows Azure, które w kwietniu 2014 zostało przemianowane na Microsoft Azure. Od samego powstania Azure firma Microsoft stale rozszerza swoją platformę o nowsze i bogatsze możliwości.
Natychmiastowe, dynamiczne wdrażanie Zacznijmy od tego, że wdrażanie i konfigurowanie własnych (zainstalowanych w siedzibie firmy) serwerów jest trudne. Po pierwsze, musimy zakupić i fizycznie rozmieścić odpowiedni sprzęt. Następnie trzeba uzyskać niezbędne licencje na oprogramowanie, zainstalować system operacyjny, po czym wdrożyć i skonfigurować potrzebne oprogramowanie. Konieczne jest też zapewnienie akceptowalnego poziomu wydajności i ciągłość działania na wypadek nieoczekiwanej awarii sprzętu, oprogramowania i sieci. Oznacza to konfigurowanie równoważenia obciążeń i nadmiarowości poprzez technologie duplikowania i klastrowania. Trzeba też zdefiniować strategię tworzenia kopii zapasowych i stosować ją ściśle jako część ogólnego planu przywracania po awarii – który również trzeba będzie opracować. A gdy już wszystko zostanie skonfigurowane
Przetwarzanie w chmurze: przedstawienie pojęcia
i uruchomione, nadal trzeba będzie o to dbać, aby zapewnić sprawne działanie systemu przez cały czas życia naszej aplikacji. Bez zbędnej przesady, przejście do chmury eliminuje wszystkie te obciążenia. W skrócie, idea aplikacji i usług uruchamianych w „chmurze” oznacza, że mamy do czynienia z „niedotykalnymi” zasobami sprzętowymi, co z kolei przekłada się na środowisko robocze pozbawione konieczności jego konserwowania. Rejestrujemy się w firmie hostującej chmurę (Microsoft w przypadku Azure), płacimy jej za tyle mocy (w znaczeniu zasobów), ile potrzebuje nasza aplikacja (RAM, CPU, pojemność magazynu, pasmo przenoszenia, skalowalne równoważenie obciążenia i tak dalej) i to ta firma martwi się o całą resztę. W porównaniu z ilością pracy i potencjalnymi błędami, które mogą pojawić się przy samodzielnym robieniu tego wszystkiego, rozwiązanie takie jest wolne zarówno od mordęgi, jak i ryzyka.
Chmura Microsoft Azure W przypadku Azure nasze aplikacje, usługi i dane rezydują w chmurze. Chmura Azure oparta jest na wielkich, geograficznie rozproszonych centrach danych należących do firmy Microsoft, wyposażonych w wydajne serwery, ogromne pojemności magazynu danych i bardzo wysoki poziom nadmiarowości, zapewniający ciągłość działania. Jednak środowisko Microsoft Azure to znacznie więcej, niż zbiór konwencjonalnych serwerów hostingowych „na sterydach”. W istocie nasze chmurowe aplikacje i usługi nie są uruchamiane bezpośrednio na tych serwerach. Zamiast tego na tym całym sprzęcie działa zaawansowana technologia wirtualizacji – hyperwizor. Nasz „kod w chmurze” z kolei działa na tej warstwie wirtualizacji. Dzięki temu przeskalowanie w czasie szczytowego obciążenia sprowadza się do zmiany ustawień konfiguracyjnych, które zwiększają liczbę uruchomionych instancji w celu obsługi rosnących potrzeb. Gdy gorący sezon się skończy, analogiczna prosta zmiana pozwala zredukować liczbę instancji i przeskalowanie rozwiązania w dół. Microsoft Azure obsługuje skalowalność poprzez dynamiczne przyznawanie większej lub mniejszej mocy obliczeniowej zwirtualizowanemu środowisku. Proces ten, często nazywany elastycznym skalowaniem, jest praktycznie natychmiastowy. A teraz spróbujmy rozważyć ten sam scenariusz przy konwencjonalnej infrastrukturze. Musimy kupić i zainstalować dodatkowe serwery, włączyć je i dodać jako członków farmy równoważenia obciążenia. A gdy dodatkowa moc nie będzie już potrzebna, trzeba je odłączyć do trybu offline, aby czekały na kolejny szczyt obciążenia. Wymaga to wiele pracy i czasu – naszej własnej lub firmy hostingowej – zbyt wiele, gdy porównamy to z dostosowywaniem konfiguracji poprzez kilka kliknięć myszą. Ponieważ rozwiązania chmurowe mogą być dostarczane na wiele różnych sposobów, w słowniku pojawiło się wiele nowych słów i sloganów. Wyróżniają się wśród nich najrozmaitsze akronimy pochodne od zwrotu „as a service” (jako usługa), takie jak IaaS (Infrastructure as a Service – infrastruktura jako usługa), PaaS (Platform
3
4
Rozdział 1: Poznajemy Microsoft Azure SQL Database
as a Service – platforma jako usługa) oraz SaaS (Software as a Service – oprogramowanie jako usługa). Wszystkie te terminy jednoznacznie odwołują się do usług (service); różnica leży w poziomie tej usługi. Zazwyczaj pomocne jest myślenie o tych terminach jako o różnych stopniach abstrakcji, poczynając od najniższego poziomu infrastruktury sprzętowej. W przypadku instalacji w siedzibie nie ma żadnej abstrakcji i jesteśmy odpowiedzialni za wszystkie poziomy, od sprzętu w górę. Po przejściu do chmury możemy wybrać wariant IaaS, Paas lub SaaS, zgodnie z potrzebami, przy czym każde z tych podejść zapewnia większy poziom abstrakcji.
Infrastruktura jako usługa W wariancie IaaS Microsoft Azure w praktyce oznacza udostępnienie maszyn wirtualnych (VM), które są w całości pod naszą kontrolą. Podobnie jak w środowisku tradycyjnym, jesteśmy odpowiedzialni za instalację systemu operacyjnego i skonfigurowanie maszyny. Łatwo można zbudować maszynę wirtualną od zera – albo dostosować istniejące maszyny wirtualne z biblioteki wstępnie skonfigurowanych VM – po czym je wdrożyć do działania w chmurze z pełnymi możliwościami sieciowymi (włącznie z połączeniami Virtual Private Network [VPN]). Jednak w odróżnieniu od pracy z serwerami w siedzibie, nigdy nie będą nam potrzebne śrubokręty, dyski, kable, szafy rackowe, zasilacze, płyty główne, pamięć ani nic podobnego. Na tym właśnie polega IaaS – jest abstrakcją sprzętu (sieć, magazyn, serwery, wirtualizacja) i niczym więcej. Mając takie możliwości, możemy oczywiście utworzyć VM w Microsoft Azure, na której będzie działać Microsoft SQL Server; właśnie tak, maszynę wirtualną w chmurze, na której uruchomimy pełną, „on-premises” wersję SQL Server. Mogą istnieć sytuacje, gdy takie działanie będzie w pełni usprawiedliwione i poprawne – na przykład gdy wymagana będzie pełna kompatybilność z istniejącą już w siedzibie firmy instalacją SQL Server, czego nie zapewnia SQL Database. (Różnice pomiędzy tymi dwiema platformami omówimy szczegółowo w rozdziale 3, „Różnice pomiędzy SQL Server a Microsoft Azure SQL Database”). Typowym przykładem takiego scenariusza jest potrzeba dostarczenia usługi raportowania z SQL Server Reporting Services (SSRS) uruchomioną na maszynie wirtualnej Microsoft Azure (jak to zrobić, nauczymy się w rozdziale 6, „Raportowanie w chmurze”). Trzeba jednak pamiętać, że uruchomienie SQL Server na maszynie wirtualnej Azure jest czymś zupełnie odmiennym od korzystania z Microsoft Azure SQL Database. Wybranie IaaS i SQL Server oznacza, że nadal jesteśmy w pełni odpowiedzialni za obsługę naszej maszyny wirtualnej (lub maszyn) w chmurze. Obejmuje to instalację systemu operacyjnego od zera (chyba że wybierzemy załadowanie wstępnie skonfigurowanej VM z galerii), instalację SQL Server, skonfigurowanie instancji, zapewnienie aktualności oprogramowania, ochronę maszyn wirtualnych przed awariami programowymi i tworzenie kopii zapasowych. Jeśli nasza maszyna wirtualna ulegnie awarii, wówczas to my mamy problem. SQL Database jest czymś zupełnie odmiennym, i to właśnie czyni ją rozwiązaniem typu PaaS.
Przetwarzanie w chmurze: przedstawienie pojęcia
Platforma jako usługa W przypadku PaaS poziom abstrakcji został podniesiony znacznie wyżej w porównaniu do IaaS, przez co jesteśmy odgraniczeni od warstw systemu operacyjnego, warstwy pośredniej (middleware) i czasu wykonania (runtime). Oznacza to, że Microsoft Azure zapewnia platformę dla naszych aplikacji i usług, na której możemy je uruchomić. Nie mamy żadnej kontroli nad samą platformą; musimy zarządzać tylko aplikacjami i danymi, podczas gdy dostawca chmury zarządza resztą infrastruktury. Nadal musimy samodzielnie utworzyć i przetestować nasze aplikacje, po czym załadować je do Microsoft Azure. (Zagadnienie to omówimy w rozdziale 10, „Budowanie rozwiązania w chmurze”). Zapewnia to naszej aplikacji niewiarygodną skalowalność bez konieczności inwestowania w kosztowny sprzęt, co byłoby wymagane w dowolnym scenariuszu instalacji w siedzibie. SQL Database jest rozwiązaniem typu PaaS. To nadal jest SQL Server, ale w celu dostarczenia platformy dla relacyjnej bazy danych (w przeciwieństwie do infrastruktury) określone funkcjonalności, które są dostępne w rozwiązaniach w siedzibie, nie są obsługiwane. W przypadku SQL Database można skonfigurować serwery i bazy danych „w locie”, bez żadnej interakcji z systemem operacyjnym czy innymi elementami podrzędnej infrastruktury. Nie musimy nawet wiedzieć ani zastanawiać się nad tym, czy dane i pliki dzienników są przechowywane na dysku C, czy D, gdyż SQL Database obsługuje za nas wszystkie szczegóły fizycznego przechowywania danych. I jak zobaczymy w rozdziale 3, korzyści z praktycznie natychmiastowego wdrażania oraz bezwysiłkowa i pozbawiona ryzyka obsługa oznacza też pewną utratę kontroli, którą mamy przy wykorzystywaniu instalacji SQL Server w siedzibie.
Oprogramowanie jako usługa SaaS (Software as a Service) to najwyższy poziom abstrakcji, w którym wszystko – od poziomu sprzętu, aż po aplikacje końcowych użytkowników – jest obsługiwane przez usługę. Obecnie istnieje już wiele chmur typu SaaS, w tym Office 365, CRM oraz Salesforce.com. Możemy utworzyć nasze własne rozwiązanie SaaS oparte na SQL Database, wspierając usługę lub witrynę Web – również hostowaną w Azure – na tej bazie danych. (Zrobimy to w rozdziale 10). Następnie będziemy mogli zaoferować kompletne rozwiązanie naszym klientom, którzy będą wchodzić w interakcję z aplikacją korzystając jedynie z przeglądarki lub urządzenia mobilnego. Klienci ci nie muszą (i nie potrzebują) znać żadnych aspektów infrastruktury ani platformy – po prostu łączą się z aplikacją. Tak więc, z ich perspektywy, dostarczamy im prawdziwe rozwiązanie SaaS.
5
6
Rozdział 1: Poznajemy Microsoft Azure SQL Database
Rejestrowanie się dla SQL Database Aby móc zacząć korzystać z SQL Database, potrzebujemy dwóch rzeczy: konta Microsoft oraz subskrypcji Microsoft Azure. Jest całkiem możliwe, że Czytelnik już ma konto Microsoft, znane wcześniej jako Windows Live ID. Jest to to samo konto, którego używamy dziś do logowania się w różnych witrynach i usługach firmy Microsoft, takich jak Outlook.com, Hotmail, Xbox LIVE, Windows Phone, OneDrive (dawniej SkyDrive) i wielu innych.
Tworzenie konta Microsoft Pierwszym krokiem, który trzeba wykonać, zanim będzie można użyć dowolnej z usług Microsoft Azure, jest uzyskanie konta Microsoft, o ile jeszcze go nie mamy. Zasadniczo jest to kombinacja adresu email i hasła, którego użyjemy do utworzenia subskrypcji Microsoft Azure, a później do uzyskiwania dostępu do Azure. Jeśli Czytelnik ma już konto Microsoft, może użyć go do utworzenia nowej subksrypcji Azure. Nie ma potrzeby tworzenia konta, zatem w takiej sytuacji można przejść od razu do następnego podrozdziału, „Tworzenie subskrypcji Microsoft Azure”. W przeciwnym razie konieczne będzie utworzenie konta. wskazówka Jeśli Czytelnik ma już konto Microsoft, ale chce z dowolnego powodu użyć innego adresu email, nadal nie ma potrzeby tworzenia nowego konta. Można bowiem albo przemianować istniejące konto, albo utworzyć alias. Więcej informacji zawiera strona http://windows.microsoft.com/en-US/hotmail/get-new-outlook-address.
Przy tworzeniu nowego konta Microsoft nazwą użytkownika może być adres email, który już mamy. Alternatywnie można utworzyć nowy adres email dla nowego konta, który będzie się kończył albo na @outlook.com, albo @hotmail.com. W rzeczywistości nie ma znaczenia, co wybierzemy, o ile wybrana nazwa nie jest już zajęta przez kogoś innego w jednej z domen @outlook.com lub @hotmail.com. Jeśli zdecydujemy się na utworzenie nowego adresu, dostaniemy również skrzynkę pocztową pod tym adresem i firma Microsoft będzie się z nami komunikowała poprzez ten adres za każdym razem, gdy pojawi się potrzeba przekazania jakiejś ważnej informacji dotyczącej konta. Bez względu na to, czy wybierzemy istniejący adres email, czy utworzymy nowy, musimy również przypisać do tworzonego konta silne hasło. Wymagane są również pewne dodatkowe informacje osobiste, takie jak nazwisko i imię, płeć, jedną z dwóch form potwierdzenia tożsamości, kraj oraz kod pocztowy.
Rejestrowanie się dla SQL Database
Aby utworzyć nowe konto Microsoft, wykonaj poniższe czynności: 1 . Korzystając z przeglądarki Internet Explorer przejdź do adresu http://signup.live.
com. Pojawi się strona Create An Account (utwórz konto), pokazana na rysunku 1-1.
Rysunek 1-1 Rejestrowanie nowego konta Microsoft
2 . Wpisz swoje imię i nazwisko. 3 . Jako nazwę użytkownika konta Microsoft (tego konta będziemy używać do logo-
wania się w portalu Microsoft Azure) podaj istniejący adres email albo kliknij łącze Or get a new email address (albo uzyskaj nowy adres email), by utworzyć nowy adres w domenie @outlook.com lub @hotmail.com. 4 . Wpisz hasło, a następnie wpisz je ponownie w celu potwierdzenia. Hasło dla kon-
ta musi być silne, o długości co najmniej ośmiu znaków i zawierać kombinację małych i wielkich liter, cyfr i symboli. 5 . Wybierz z odpowiednich list nazwę kraju i kod pocztowy, datę urodzenia oraz
płeć. 6 . Podaj numer telefonu lub alternatywny adres email. Konieczne jest wskazanie
przynajmniej jednej spośród tych metod potwierdzania tożsamości. 7 . Wpisz pokazane niżej przypadkowe znaki (CAPTCHA) w celu sprawdzenia,
że jesteś rzeczywistą osobą, a nie botem. 8 . Kliknij przycisk Create Account (utwórz konto).
7
8
Rozdział 1: Poznajemy Microsoft Azure SQL Database
Jeśli w kroku 3 został utworzony nowy adres email, nastąpi natychmiastowe przekierowanie do strony Account Summary (podsumowanie konta). W przypadku podania istniejącego konta po chwili zostanie nań wysłana wiadomość od nadawcy „Microsoft account team”. Wiadomość ta ma na celu weryfikację, że w istocie jesteśmy właścicielami podanego adresu pocztowego. Nowe konto Microsoft nie zostanie uaktywnione, dopóki nie klikniemy weryfikacyjnego łącza zawartego w tej wiadomości.
Tworzenie subskrypcji Microsoft Azure Teraz, gdy już mamy konto Microsoft, możemy przejść do tworzenia subskrypcji Azure. Subskrypcja ta jest zasadniczo kontem rozliczeniowym Microsoft Azure i otwiera drzwi do pełnego zakresu usług dostępnych w Microsoft Azure – w tym oczywiście SQL Database. W pokazanej dalej procedurze utworzymy darmową próbną subskrypcję w Microsoft Azure. W momencie pisania tych słów darmowa próbna subskrypcja obejmowała kredyt w wysokości 200 dolarów (150 euro) na 30-dniowy dostęp do wszystkich usług. Proces ten wymaga podania danych karty kredytowej, która zostanie użyta do opłacenia subskrypcji po wygaśnięciu okresu próbnego1. ważne Ceny usług Microsoft Azure i oferty specjalne podlegają ciągłym zmianom. Zdecydowanie polecamy odwiedzenie strony http://www.windowsazure.com/pl-pl/pricing/purchase-options/ w celu sprawdzenia aktualnych cen. Dodatkowo subskrybenci MSDN mają do dyspozycji specjalne oferty. Więcej informacji można znaleźć pod adresem http://www. windowsazure.com/pl-pl/pricing/member-offers/msdn-benefits/.
Wykonaj poniższe czynności, aby utworzyć nową subskrypcję Microsoft Azure: 1 . Przy użyciu przeglądarki Internet Explorer przejdź do adresu http://www.windo-
wsazure.com. 2 . Kliknij zielony przycisk Try For Free (Wypróbuj bezpłatnie). 3 . Na kolejnej stronie kliknij zielony przycisk Try It Now (Wypróbuj teraz). 4 . Jeśli nie byłeś jeszcze zalogowany na konto Microsoft, zaloguj się teraz. 5 . Zostaniesz przekierowany do strony Sign up (Utwórz konto), pokazanej na rysun-
ku 1-2. 1 Witryna rejestracji Microsoft Azure jest dostępna również w języku polskim i w przypadku komputera zlokalizowanego na terenie Polski może nastąpić automatyczne przekierowanie do tej wersji. Zasadniczy portal Azure i inne strony pochodne są dostępne w kilku językach (do wyboru podczas rejestracji), ale nie ma wśród nich wersji polskiej. (Wszystkie przypisy pochodzą od tłumacza).
Rejestrowanie się dla SQL Database
Rysunek 1-2 Rejestrowanie nowej bezpłatnej wersji próbnej subskrypcji Microsoft Azure
6 . Wybierz metodę odebrania kodu weryfikacyjnego – jako wiadomość SMS lub
rozmowę telefoniczną. 7 . Wpisz kod otrzymany w wiadomości tekstowej lub w rozmowie i kliknij Verify Code (Zweryfikuj kod).
8 . Podaj dane karty kredytowej, która zostanie użyta do realizacji płatności po wygaś-
nięciu okresu próbnego. ważne Podanie danych karty kredytowej nie oznacza, że zostaniemy obciążeni jakąkolwiek opłatą, o ile nie odblokujemy subskrypcji. Dane te mają na celu przede wszystkim weryfikację tożsamości użytkownika.
9 . Zaznacz pole wyboru, aby potwierdzić zgodę na warunki umowy. 10 . Kliknij przycisk Sign Up (Utwórz konto).
Konfigurowanie nowej subskrypcji Azure zajmuje tylko kilka sekund i już po chwili możemy zacząć pracę z SQL Database i dowolnymi innymi usługami Microsoft Azure.
9
10
Rozdział 1: Poznajemy Microsoft Azure SQL Database
Tworzenie serwera Tworzenie serwera jest proste. Serwer jest podobny do instancji SQL Server w tym sensie, że może hostować wiele baz danych. Wszystko, co trzeba zrobić, to utworzenie konta administratora z silnym hasłem i wskazanie regionu geograficznego, w którym serwer powinien zostać fizycznie zlokalizowany. W celu osiągnięcia najlepszej wydajności należy wybrać region możliwie bliski naszym klientom. Jak pokażemy w rozdziale 2, „Konfiguracja i ceny”, będziemy również chcieli się upewnić, że dowolne witryny i usługi chmury Microsoft Azure (takie jak te, które utworzymy w rozdziale 10) będą hostowane w tym samym regionie, co serwery SQL Database, z którymi będą się łączyć. Dzięki umieszczeniu obydwu części rozwiązania w tym samym regionie unikniemy opłat opartych na paśmie przesyłowym, które pojawiają się, gdy poszczególne elementy muszą się komunikować poprzez granice regionów Azure. Co również ważne, w ten sposób redukujemy opóźnienia, co zapewnia znacząco lepszą wydajność. SQL Database używa również specjalnych reguł zapory, które można ustawić w celu kontrolowania, który komputer lub komputery mogą uzyskiwać dostęp do naszego serwera bazy danych w chmurze. Jako minimum trzeba dodać regułę przyznającą dostęp z adresu IP własnego komputera, aby móc uzyskiwać dostęp do serwera z komputera lokalnego. W rozwiązaniu produkcyjnym konieczne może być dodanie reguł przyznających dostęp dla jednego lub kilku bloków adresów IP. Więcej informacji na temat reguł zapory przedstawimy w rozdziałach 2 i 5. Aby utworzyć nowy serwer, wykonaj poniższe kroki: 1 . Zaloguj się do portalu Microsoft Azure pod adresem https://manage.windowsa-
zure.com. Zostaniesz przekierowany do głównej strony portalu prezentującej all items (wszystkie elementy), pokazanej na rysunku 1-3.
Rysunek 1-3 Portal zarządzania Microsoft Azure bez żadnych skonfigurowanych usług
Tworzenie serwera
Uwaga Przy pierwszym logowaniu w portalu pojawi się zaproszenie do przejrzenia oferowanych usług. Możesz przyjąć to zaproszenie albo zamknąć komunikat, by przejść do głównej strony portalu.
2 . Kliknij SQL DATABASES w pionowym panelu nawigacyjnym po lewej (rysunek
1-4), później SERVERS w górnej części głównego panelu i następnie CREATE A SQL DATABASE SERVER (utwórz serwer SQL Database).
2
3 1
Rysunek 1-4 Łącze CREATE A SQL DATABASE SERVER na stronie SQL DATABASES
3 . Wpisz nazwę logowania dla nowego serwera – na przykład saz. 4 . Wpisz hasło dla nowego serwera i powtórz je w drugim polu dla potwierdzenia.
Hasło musi stosować się do typowych reguł silnego hasła, czyli zawierać kombinację małych i wielkich liter, cyfr i symboli. 5 . Wybierz odpowiedni region z listy rozwijanej – na przykład West Europe (zachod-
nia Europa). Aby zapewnić najlepszą wydajność, należy wybrać region, w którym się znajdujesz lub możliwie najbliższy. 6 . Upewnij się, że pole wyboru ALLOW WINDOWS AZURE SERVICES TO ACCESS THE SERVER (zezwalaj usługom Windows Azure na dostęp do serwera) jest zaznaczone.
Spowoduje to, że serwer będzie dostępny dla usług chmury Microsoft Azure, które będziemy tworzyć lub z nich korzystać w innych rozdziałach (przypomnijmy, że Microsoft Azure było wcześniej nazywane Windows Azure). Strona powinna wyglądać podobnie do pokazanej na rysunku 1-5.
11
12
Rozdział 1: Poznajemy Microsoft Azure SQL Database
Rysunek 1-5 Okno dialogowe CREATE SERVER
7 . Kliknij ikonę zatwierdzenia (z „ptaszkiem”) w prawym dolnym rogu okna dia-
logowego, aby zatwierdzić ustawienia. Po kilku chwilach nowy serwer zostanie skonfigurowany i udostępniony do użycia, jak na rysunku 1-6.
Rysunek 1-6 Nowy serwer SQL Database
Tworzenie serwera
Ktoś, kto choć raz samodzielnie przygotowywał nowy serwer w siedzibie firmy, zdecydowanie doceni zaoszczędzony właśnie czas i wysiłek. Serwer jest już dostępny i gotowy do przechowywania bazy danych, zaś mechanizm SQL Database automatycznie przypisał mu losową i unikatową (choć względnie krótką) nazwę, po której można uzyskiwać do niego dostęp. Jednak zanim dostęp zostanie przyznany, musi zostać skonfigurowana zapora serwera. Zatem następnym krokiem będzie dodanie reguł zapory, abyśmy mogli połączyć się z serwerem z naszego komputera lokalnego. Pole wyboru wspomniane w punkcie 6 poprzedniej procedury powoduje dodanie do reguł zapory specjalnego adresu IP 0.0.0.0, który pozwala na dostęp do naszego serwera usługom chmury działającym w Microsoft Azure. Nadal jednak musimy dołączyć adres IP naszego lokalnego komputera, aby móc uzyskać dostęp do serwera z portalu zarządzania SQL Database i innych narzędzi (takich jak SQL Server Management Studio lub SQL Server Data Tools, zawarte w Microsoft Visual Studio, o których dowiemy się więcej w późniejszych rozdziałach). Aby dodać regułę zapory dla adresu IP maszyny lokalnej, wykonaj następujące działania: 1 . Kliknij nazwę serwera, a następnie łącze CONFIGURE (konfiguruj) u góry strony. 2 . Kliknij łącze ADD TO THE ALLOWED IP ADDRESSES (dodaj do dozwolonych adresów
IP) obok wykrytego bieżącego adresu komputera, jak na rysunku 1-7. Zostanie utworzona nowa reguła zapory dla adresu IP twojego komputera.
Rysunek 1-7 Dodawanie adresu IP maszyny lokalnej do listy dozwolonych adresów w regułach zapory
3 . Kliknij SAVE (zapisz) w dolnej części strony. 4 . Kliknij ikonę powrotu (wielką strzałkę skierowaną w lewo), aby powrócić do stro-
ny SQL DATABASES dla nowego serwera. Może być konieczne odczekanie kilku chwil, aby nowa reguła zapory zaczęła działać, ale zazwyczaj odbywa się to bardzo szybko (w granicach od pięciu do dziesięciu sekund). Jeśli jednak nie zaczekamy dostatecznie długo i reguła jeszcze nie zaczęła być
13
14
Rozdział 1: Poznajemy Microsoft Azure SQL Database
używana, możemy być pewni, że nie uda się nam połączyć z serwerem z komputera lokalnego, dopóki nowa reguła nie zadziała.
Tworzenie instancji SQL Database Tworzenie bazy danych jest niemal tak proste, jak tworzenie serwera. Trzeba po prostu wybrać nazwę dla nowej bazy, jej wydanie, maksymalną wielkość, domyślne ustawienia językowe dla sortowania (collation) i, oczywiście, serwer, na którym baza ma być hostowana. W rozdziale 2 poznamy więcej różnych opcji dotyczących wydania bazy danych i maksymalnego rozmiaru. Na razie ważne jest, aby wiedzieć, że wszystkie te ustawienia (z wyjątkiem sortowania domyślnego) można łatwo zmienić w późniejszym terminie. W ramach elastycznego skalowania zapewnianego przez SQL Database można swobodnie przełączać się pomiędzy wydaniami Web i Business – w dowolnym kierunku. Można również przełączać zakresy rozmiarów (1 GB albo 5 GB dla wydania Web, oraz od 10 GB do 150 GB dla wydania Business) w miarę zmieniających się potrzeb. A jeśli 150 GB okaże się nadal zbyt mało, można spartycjonować bazę danych używając specjalnych technik nazywanych fragmentowaniem (sharding), co wyjaśnimy w rozdziale 8, „Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności”. Aby utworzyć nową bazę danych SQL Database, wykonaj poniższe kroki: 1 . Jeśli kontynuujesz poprzednią procedurę, kliknij łącze DATABASES (bazy danych)
u góry strony i przejdź do kroku 4. W przeciwnym razie, jeśli wylogowałeś się poprzednio i zaczynasz od początku, przejdź do kroku 2. 2 . Zaloguj się w portalu Microsoft Azure pod adresem https://manage.windowsa-
zure.com. Zostaniesz przekierowany do głównej strony portalu prezentującej all items, jak na pokazanym wcześniej rysunku 1-3. 3 . Kliknij SQL DATABASES w pionowym panelu nawigacyjnym po lewej. 4 . Kliknij łącze CREATE A SQL DATABASE (utwórz bazę danych), pokazane na rysunku
1-8. Pojawi się okno dialogowe NEW SQL DATABASE. 5 . Wpisz nazwę dla nowej bazy: WineCloudDb (tak, będziemy zajmować się han-
dlem winami!). 6 . Pozostaw ustawienia domyślne, aby utworzyć bazę danych w wyda-
niu Web o wielkości do 1 GB, używającą ustawień sortowania (collation) SQL_Lating1_GeneralCP1_CI_AS. Uwaga W rozdziale 2 omówimy różnice pomiędzy wydaniami Web i Business, ustawienia maksymalnej wielkości bazy danych i znaczenie ustawień sortowania SQL Database.
Tworzenie instancji SQL Database
2
3
1
Rysunek 1-8 Łącze CREATE A SQL DATABASE na stronie SQL DATABASES portalu
7 . Wybierz z listy rozwijanej serwer utworzony w poprzedniej procedurze. Strona
portalu powinna wyglądać podobnie do pokazanej na rysunku 1-9.
Rysunek 1-9 Okno dialogowe NEW SQL DATABASE
8 . Kliknij ikonę zatwierdzenia w prawym dolnym rogu, aby dokończyć procedurę.
15
16
Rozdział 1: Poznajemy Microsoft Azure SQL Database
Po kilku chwilach nowa baza danych WineCloudDb zostanie utworzona i udostępniona do użycia, co prezentuje rysunek 1-10.
Rysunek 1-10 Nowa baza danych WineCloudDb
Korzystanie z portalu zarządzania SQL Database Jak dotąd, posługiwaliśmy się portalem zarządzania Microsoft Azure, aby utworzyć serwer SQL Database i bazę danych. Portal ten jest interfejsem opartym na HTML, który – nawiasem mówiąc – zastąpił wcześniejszą wersję opartą na Silverlight w połowie 2012 roku. Jednak samo projektowanie bazy danych jest wykonywane poprzez inną stronę: portal zarządzania SQL Database, który nadal jest oparty na Silverlight (przynajmniej w czasie pisania tych słów). W tym podrozdziale pokażemy, jak dostać się do portalu zarządzania SQL Database z portalu Microsoft Azure. Aby przejść do portalu zarządzania SQL Database, wykonaj następujące działania: 1 . Jeśli kontynuujesz poprzednią procedurę, przejdź do kroku 4. W przeciwnym
razie, jeśli się wylogowałeś, kontynuuj od kroku 2. 2 . Zaloguj się w portalu Microsoft Azure pod adresem https://manage.windowsa-
zure.com. Zostaniesz przekierowany do głównej strony portalu prezentującej all items, jak na pokazanym wcześniej rysunku 1-3. 3 . Kliknij SQL DATABASES w pionowym panelu nawigacyjnym po lewej. 4 . Kliknij bazę danych WineCloudDb. 5 . Kliknij łącze DASHBOARD w górnej części strony. 6 . Przewiń stronę w dół, aby odnaleźć łącze MANAGE URL (adres URL zarządzania)
w sekcji quick glance (szybkie spojrzenie) po prawej stronie, jak na rysunku 1-11. 7 . Kliknij łącze MANAGE URL. Zostanie otwarta nowa karta przeglądarki ze stroną
logowania do portalu SQL Database.
Tworzenie instancji SQL Database
Rysunek 1-11 Wyszukiwanie łącza do portalu zarządzania SQL Database dla bazy danych WineCloudDb Uwaga Portal SQL Database wykorzystuje technologię Silverlight. Jeśli na komputerze nie jest zainstalowane oprogramowanie Silverlight, pojawi się monit o jego pobranie i instalację, zanim będzie możliwe korzystanie z portalu.
8 . Wpisz nazwę użytkownika (w naszym przykładzie saz) oraz hasło podane przy
tworzeniu serwera, jak na rysunku 1-12.
Rysunek 1-12 Strona logowania do portalu zarządzania SQL Database
17
18
Rozdział 1: Poznajemy Microsoft Azure SQL Database
9 . Kliknij Log On. Po uwierzytelnieniu zostaniesz przekierowany do widoku Summary (podsumowanie) karty Administration dla bazy danych, pokazanego
na rysunku 1-13.
Rysunek 1-13 Widok Summary prezentuje właściwości bazy danych WineCloudDb
Projektowanie tabel i relacji Możemy teraz rozpocząć tworzenie tabel. Na początek utworzymy dwie tabele, choć w dalszych rozdziałach znacznie rozszerzymy ten projekt. Tworzenie tabeli jest bardzo łatwe, co zobaczymy w kolejnej procedurze. Wystarczy po prostu kliknąć zakładkę Design (Projekt) po lewej stronie, a następnie New Table (nowa tabela), jak na rysunku 1-14. Działanie to otworzy projektanta tabel, którego wykorzystamy do utworzenia tabeli przechowującej produkty, co pokazuje rysunek 1-15.
Tworzenie instancji SQL Database
2
1
Rysunek 1-14 Tworzenie nowej tabeli
Rysunek 1-15 Definiowanie tabeli Wine przy użyciu projektanta tabel w portalu
19
20
Rozdział 1: Poznajemy Microsoft Azure SQL Database
Tworzenie tabeli Wine Zaczniemy od tworzenia tabeli Wine (wino). Każdy wiersz tej tabeli będzie zawierał inny gatunek wina, które nasza firma sprzedaje swoim klientom. Tabela ta będzie zawierała kolumny WineId (klucz główny unikatowo identyfikujący każdy produkt), Name, Category oraz Year. Aby utworzyć tabelę Wine, wykonaj następujące działania: 1 . Zaloguj się do portalu zarządzania SQL Database dla bazy danych WineCloudDb,
zgodnie z opisem w poprzedniej procedurze. 2 . Kliknij zakładkę Design po lewej stronie. 3 . Kliknij New Table. Zostanie otwarty projektant tabeli z domyślną nazwą Table1,
całkowitoliczbową kolumną ID oraz dwiema kolumnami tekstowymi o nazwach Column1 i Column2. 4 . Zmień nazwę tabeli w polu Table Name na Wine. 5 . Zmień nazwę kolumny ID na WineId, pozostawiając jej ustawienie jako wymaga-
ny klucz główny (primary key). 6 . Zaznacz pole wyboru Is Identity? (czy identycznościowa) dla kolumny WineId.
Spowoduje to automatyczne przypisywanie kolejnych liczb całkowitych dla tej kolumny przez SQL Database podczas wstawiania nowych danych produktów. 7 . Zmień nazwę kolumny Column1 na Name, pozostawiając jej ustawienie jako
wymaganej (required) i typ łańcucha tekstowego nvarchar(50). 8 . Zmień nazwę kolumny Column2 na Category, pozostawiając jej ustawienie jako
wymaganej i typ nvarchar(15). 9 . Kliknij Add Column (dodaj kolumnę). Spowoduje to dodanie nowej kolumny typu
całkowitego (int) o nazwie Column1 do projektu tabeli. 10 . Zmień nazwę nowej kolumny na Year i pozostaw jej ustawienie jako opcjonalnej
(czyli bez zaznaczenia pola wyboru Is Required?). 11 . Kliknij Save w pasku narzędzi u góry okna projektanta.
Utworzyliśmy tabelę Wine, która powinna wyglądać analogicznie do pokazanej wcześniej na rysunku 1-15.
Tworzenie tabeli Customer Wykonamy teraz podobną procedurę w celu utworzenia tabeli Customer (klient), zawierającej kolumny CustomerId (klucz główny), FirstName, LastName oraz FavoriteWineId. Kolumna FavoriteWineId będzie powiązana z kolumną klucza głównego WineId w tabeli Wine, zatem będzie to klucz obcy (foreign key) w tabeli Customer. Po utworzeniu tabeli Customer ustanowimy relację pomiędzy kolumną klucza obcego FavoriteWineId a kolumną klucza głównego WineId w tabeli Wine.
Tworzenie instancji SQL Database
Aby utworzyć tabelę Customer, wykonaj następujące działania: 1 . Kliknij zakładkę [WineCloudDb] u góry w lewym panelu strony. 2 . Kliknij zakładkę Design u dołu po lewej. Pojawi się ta sama strona, której użyliśmy
wcześniej przy tworzeniu tabeli Wine (rysunek 1-14). 3 . Kliknij New Table. 4 . Zmień nazwę tabeli Customer. 5 . Zmień nazwę kolumny ID na CustomerId, pozostawiając wybór jako wymaganej
i klucz główny. 6 . Zaznacz pole wyboru Is Identity? dla kolumny CustomerId. 7 . Zmień nazwę kolumny Column1 na FirstName (imię), pozostawiając ją jako
wymaganą typu nvarchar(50). 8 . Zmień nazwę kolumny Column2 na LastName (nazwisko), pozostawiając ją jako
wymaganą typu nvarchar(15). 9 . Kliknij Add Column. 10 . Zmień nazwę nowej kolumny na FavoriteWineId, pozostawiając ją jako opcjonal-
ną typu int (czyli nie zaznaczając pola wyboru Is Required?). 11 . Kliknij Save.
Teraz baza danych zawiera tabele Wine oraz Customer. Tabele te będą przechowywać (co oczywiste) nasze produkty (gatunki win) oraz dane klientów, choć (co również oczywiste) obydwie są na razie puste.
Definiowanie relacji pomiędzy tabelami Zanim przystąpimy do wypełniania tabel danymi, utworzymy relację obcego klucza pomiędzy kolumną FavoriteWineId w tabeli Customer a kolumną WineId w tabeli Wine. Warto zauważyć, że nie jest to niezbędnie wymagane w tym momencie. Tym niemniej jest zalecaną praktyką, aby poinformować SQL Database o relacjach pomiędzy tabelami, aby silnik bazy danych mógł wymusić integralność referencyjną w naszych danych. (Na przykład SQL Database będzie w stanie zagwarantować, że wartość całkowita w kolumnie FavoriteWineId dla każdego klienta odwołuje się do istniejącego wiersza w tabeli Wine, który będzie można zlokalizować poprzez WineId). Pozwoli to też silnikowi SQL Database na tworzenie bardziej efektywnych planów wykonywania zapytań, gdy użyjemy złączenia tabel według relacji. Portal zarządzania SQL Database udostępnia mechanizm zarządzania kluczami obcymi, który ułatwia definiowanie relacji, pokazany na rysunku 1-16.
21
22
Rozdział 1: Poznajemy Microsoft Azure SQL Database
Rysunek 1-16 Definiowanie relacji pomiędzy tabelami przy użyciu projektanta klucza obcego
Aby zdefiniować relację pomiędzy tabelami, wykonaj następujące działania: 1 . Nadal na stronie projektowania tabeli Customer kliknij łącze Indexes And Keys
(indeksy i klucze) w górnej części strony. 2 . Kliknij Add A Foreign Key Relationship (dodaj relację klucza obcego) na prawo
od tabeli. Pojawi się projektant klucza obcego pokazany na rysunku 1-16. 3 . Zaznacz pole wyboru przy kolumnie FavoriteWineId w tabeli Customer. Oznaczy
to kolumnę jako klucz obcy. 4 . Zmień
nazwę relacji na FK_Customer_Wine.
klucza
obcego
(domyślnie
FK_Customer_0)
5 . Kliknij Select A Reference Table (wybierz tabelę referencyjną) i wybierz Wine. 6 . Kliknij Select A Reference Column (wybierz kolumnę referencyjną) i wybierz WineId. 7 . Kliknij Save.
Relacja zostanie utworzona i kreator powinien teraz wyglądać podobnie do pokazanego na rysunku 1-17.
Rysunek 1-17 Gotowa relacja między tabelami widoczna w projektancie klucza obcego
Wstawianie danych Najbardziej prawdopodobne scenariusze obejmują bądź migrację z istniejących baz danych SQL Server w siedzibie (co omówimy w rozdziale 4, „Migrowanie baz danych”), albo zbudowanie aplikacji, które ładują dane do bazy (czym zajmiemy się
Tworzenie instancji SQL Database
w rozdziale 10). Jednak dla szybkiego i prostego wstawienia danych portal zarządzania SQL Database udostępnia wygodną metodę interaktywnego wprowadzania wierszy danych do tabel (co widać na rysunku 1-18), bez konieczności kodowania wyrażeń INSERT języka Transact-SQL (T-SQL).
Rysunek 1-18 Wypełnianie tabeli danymi
Aby wprowadzić do tabeli Wine kilka przykładowych produktów, wykonaj następujące działania: 1 . Zaloguj się do portalu zarządzania SQL Database dla bazy danych WineCloudDb
i przejdź do strony projektowania tabeli Wine, jak w poprzednich procedurach. 2 . Kliknij łącze Data (dane) u góry strony. 3 . Kliknij Add Row (dodaj wiersz). 4 . Wpisz nowe wartości dla kolumn Name, Category oraz Year: Chateau Penin,
Bordeaux i 2008, odpowiednio. Uwaga Ponieważ zaznaczyliśmy pole wyboru Is Identity? dla kolumny WineId podczas projektowania tabeli, projektant wyświetla w niej wpis w celu zasygnalizowania, że SQL Database automatycznie wstawi tam wartość, gdy utworzone wiersze zostaną zapisane w bazie danych.
5 . Powtórz kroki 3 i 4, aby wprowadzić trzy inne wina do tabeli: a . McLaren Valley, Cabernet, 2005. b . Mendoza, Merlot, 2010. c . Valle Central, Merlot, 2009.
23
24
Rozdział 1: Poznajemy Microsoft Azure SQL Database
6 . Kliknij Save w pasku narzędzi u góry strony.
Żadne dane wpisane na tej stronie nie są zapisywane w bazie, dopóki nie klikniemy przycisku Save (krok 6). Dopiero wtedy wiersze zostają wstawione i widok zostanie odświeżony, pokazując automatycznie dodane wartości klucza głównego WineId. Ponieważ są to pierwsze cztery wiersze dodane to tej tabeli, klucze te mają wartości od 1 do 4, co widać na rysunku 1-19.
Rysunek 1-19 Tabela Wine z wstawionymi wierszami danych z automatycznie przypisanymi wartościami klucza głównego
Teraz dodamy nieco danych do tabeli Customer. Posłużymy się taką samą procedurą, którą wykonaliśmy przed chwilą dla tabeli Wine. Jedynym dodatkowym uwarunkowaniem, o którym trzeba pamiętać, jest to, że dla każdego klienta istnieje (opcjonalna) wartość klucza obcego, identyfikująca ulubione wino tego klienta. Ponieważ poinformowaliśmy SQL Database o tej relacji w poprzedniej procedurze, będziemy mogli wpisać tylko wartości od 1 do 4 w kolumnie FavoriteWineId (albo inne liczby całkowite, o ile kiedyś w przyszłości dodamy nowe wiersze do tabeli Wine). Jedyną alternatywą jest wstawienie NULL, gdyż FavoriteWineId jest wartością opcjonalną (przez co należy rozumieć, że możemy nie znać ulubionego wina klienta). Jak pokażemy, SQL Database nie pozwoli dodać wiersza klienta z wartością nie-NULL w kolumnie FavoriteWineId, dla której nie istnieje powiązany wiersz w tabeli Wine. Aby wypełnić tabelę Customer, wykonaj następujące czynności: 1 . Przejdź do strony projektowania tabeli Customer. 2 . Kliknij Data w górnej części strony. 3 . Kliknij Add Row.
Tworzenie instancji SQL Database
4 . Wpisz nowy wiersz z wartościami dla pól FirstName, LastName i FavoriteWineId:
Jeff, Hay, i 4 odpowiednio. 5 . Kliknij Add Row ponownie, aby wpisać kolejny wiersz: Mark, Hanson, 3. 6 . Kliknij Save, aby zapisać wiersze w bazie danych. Dwa wiersze automatycznie
otrzymają wartości klucza głównego (1 oraz 2) w kolumnie CustomerId. 7 . Ponownie kliknij Add Row i wpisz nowy wiersz: Jeff, Phillips, ale tym razem wpisz
6 w kolumnie FavoriteWineId. 8 . Kliknij Save. Tym razem SQL Database zgłosi błąd. 9 . Rozwiń sekcję Error Details (szczegóły błędu), jak na rysunku 1-20. Pojawi się
komunikat błędu wyjaśniający, że wystąpił konflikt klucza obcego, gdyż żaden wiersz w tabeli Wine nie ma w kolumnie WineId wartości równej 6.
Rysunek 1-20 Komunikat błędu wyświetlany przy próbie naruszenia relacji klucza obcego
10 . Skoryguj problem zmieniając wartość 6 na 2. 11 . Kliknij Save. Tym razem dane klienta zostaną zapisane w tabeli Customer (rysunek
1-21).
Rysunek 1-21 Tabela Customer z kilkoma wierszami danych
25
26
Rozdział 1: Poznajemy Microsoft Azure SQL Database
Co interesujące, wiersz „Jeff Phillips” otrzymał wartość klucza obcego wynoszącą 4, pomijając kolejną dostępną wartość (którą powinno być 3). Wynika to z faktu, że liczba 3 otrzymała status „użyta” podczas nieudanej próby wstawienia wiersza, przy której wystąpił konflikt klucza obcego.
Odpytywanie bazy danych Mamy teraz bazę danych z dwiema powiązanymi relacyjnie, wypełnionymi danymi tabelami. Kolejnym logicznym krokiem jest wykonanie zapytania do tych danych. Ponieważ SQL Database jest zasadniczo zaadaptowaną wersją oprogramowania SQL Server, dostosowaną do wymogów działania w chmurze Microsoft Azure, większość typowych zapytań można formułować używając takiej samej składni T-SQL, jakiej użylibyśmy wobec SQL Server w siedzibie. Tak więc tabele Customer i Wine można łatwo złączyć, aby pokazać nazwy ulubionych win poszczególnych klientów. Co więcej, można je przefiltrować, aby ograniczyć zwracane wyniki według określonych kryteriów. Portal zarządzania SQL Database udostępnia okno zapytania ad-hoc, w którym można wykonywać zapytania T-SQL i przeglądać ich rezultaty. Aby wykonać zapytanie zwracające listę klientów i ich ulubione wina, wykonaj poniższe działania: 1 . Zaloguj się w portalu zarządzania SQL Database dla bazy danych WineCloudDb. 2 . Kliknij New Query (Nowe zapytanie) w górnej części strony, aby otworzyć okno
nowego zapytania. 3 . Wpisz poniższy kod T-SQL w oknie zapytania: SELECT c.FirstName, c.LastName, w.Category, w.Name FROM Customer AS c LEFT OUTER JOIN Wine AS w ON c.FavoriteWineId = w.WineId ORDER BY c.LastName, c.FirstName;
4 . Kliknij Run (Uruchom) w górnej części strony. Silnik SQL Database wykona zapy-
tanie i wyświetli wyniki w dolnej części okna zapytań, jak na rysunku 1-22. 5 . Zmodyfikuj zapytanie, dodając klauzulę WHERE. Bezpośrednio przed klauzulą
ORDER BY wpisz WHERE w.Category = ‘Merlot’
Tworzenie instancji SQL Database
Rysunek 1-22 Tworzenie i wykonywanie zapytania złączającego dane z tabeli klientów i win
6 . Ponownie kliknij Run. Zapytanie zostanie wykonane ponownie, tym razem zwra-
cając tylko tych klientów, których ulubionym winem jest Merlot, jak na rysunku 1-23.
Rysunek 1-23 Stosowanie w zapytaniu filtru przy użyciu klauzuli WHERE
27
28
Rozdział 1: Poznajemy Microsoft Azure SQL Database
7 . Zmień zawartość klauzuli WHERE zapytania z w.Category = ‘Merlot’ na w.Year <
2010. 8 . Kliknij Run jeszcze raz. Tym razem zapytanie zostanie przefiltrowane według roku
produkcji wina, jak na rysunku 1-24.
Rysunek 1-24 Filtrowanie na podstawie roku produkcji wina
W kroku 3 można zauważyć, że wykonaliśmy złączenie tabel Customer i Wine w klauzuli FROM zapytania. Złączenie typu LEFT OUTER JOIN gwarantuje, że zwracane są wszystkie wiersze danych klientów, nawet jeśli zawierają one NULL w kolumnie FavoriteWineId – czyli również tych, dla których nie jest określone ich ulubione wino. Użycie INNER JOIN w tym miejscu automatycznie wykluczyłoby klientów bez wskazanego ulubionego wina. Wstępna wersja tego zapytania nie zawierała klauzuli WHERE, a ze względu na użycie LEFT OUTER JOIN nie wystąpiło żadne filtrowanie. Tak więc zwrócone zostały dane wszystkich klientów wraz z nazwą i kategorią ulubionego wina (można zauważyć wartość NULL dla nazwy i kategorii wina tych klientów, którzy nie mają przypisanego ulubionego wina). Poprzez dodanie klauzuli WHERE w kroku 5 zażądaliśmy, aby SQL Database przefiltrował wyniki i zwrócił tylko tych klientów, których ulubione wino to Merlot. Warto zauważyć, że tabeli Wine został przypisany alias w w klauzuli FROM, zatem w.Category w kategorii WHERE odnosi się do wartości kolumny Category w wierszu złączonym z tabeli Wine. Wykonanie tego zapytania zwraca jedynie dwa wiersze klientów. W kroku 7 zmieniliśmy klauzulę WHERE, aby wykonać filtrowanie według w.Year, która zawiera rok produkcji wina. Zwróćmy uwagę, że kolumna ta nie należy do zbioru wynikowego zwracanego przez wyrażenie SELECT, ale mimo to w pełni uprawnione
Tworzenie instancji SQL Database
jest użycie go do filtrowania. Ta wersja zapytania zwraca dane dwóch klientów, których ulubione wina (z dowolnej kategorii) są starsze niż z roku 2010.
Poznawanie dodatkowych możliwości portalu W tym pierwszym rozdziale już zrobiliśmy sporo w SQL Database. Utworzyliśmy serwer i bazę danych, zdefiniowaliśmy tabele z relacją pomiędzy nimi, wprowadziliśmy do nich pewne dane i wykonaliśmy proste zapytania. A wszystko to zrealizowaliśmy korzystając jedynie z przeglądarki, wykorzystując portal zarządzania Microsoft Azure oraz portal SQL Database. Na razie jednak ledwie musnęliśmy powierzchnię tego, co jest możliwe. Portal zarządzania SQL Database został bardzo rozbudowany od wczesnych dni istnienia Azure (wówczas nosił nazwę portalu zarządzania SQL Azure). Jak można się spodziewać, ta ewolucja będzie postępowała nadal – być może jakieś zmiany pojawią się, zanim gotowa książka trafi do rąk Czytelnika. Przed zakończeniem tego rozdziału proponujemy więc poświęcenie nieco czasu na poznanie dodatkowych możliwości, które były dostępne w portalu SQL Database w chwili pisania tych słów i zorientować się, czy i jakie nowe funkcjonalności są dostępne.
Tworzenie widoków Widoki (view) zasadniczo stanowią „opakowane” zapytania przechowywane w bazie danych. Pod wieloma względami nasze zapytania mogą traktować widoki tak samo jak zwykłe tabele. Dla przykładu moglibyśmy utworzyć trzy widoki, kapsułkujące trzy wersje zapytania z poprzedniego podrozdziału, „Odpytywanie bazy danych”. Widoki te moglibyśmy nazwać następująco: ■ ■ ■
Mając widoki do dyspozycji, zapytania do bazy danych stają się znacznie łatwiejsze. Możemy na przykład po prostu wybrać wszystko z CustomersWithFavoriteMerlotView, zamiast pisać długą wersję zapytania złączającego tabele Customer i Wine.
Tworzenie procedur składowanych Podobnie jak widoki, procedury składowane (stored procedure) również mogą kapsułkować zapytania, ale mogą też robić znacznie więcej. Oprócz zwracania danych z zapytań procedury składowania mogą zawierać dowolną logikę wyrażoną w języku T-SQL. Mogą również przyjmować parametry, aktualizować lub dodawać dane oraz wywoływać inne procedury składowane.
29
30
Rozdział 1: Poznajemy Microsoft Azure SQL Database
Stosowanie procedur składowanych jest typowe w profesjonalnych relacyjnych bazach danych. Często służą do ochrony leżących w tle tabel przed niewłaściwym wykorzystaniem. Mogą one również tworzyć widoki, implementować logikę biznesową lub maskować szczegóły leżącej w tle struktury bazodanowej – ukrywając to, jak nazywają się poszczególne tabele, widoki i kolumny, jak definiowane są relacje pomiędzy tabelami i tak dalej. Zasadniczo, a w szczególności z punktu widzenia projektowania wielowarstwowej architektury, procedury składowane można skutecznie wykorzystać do zbudowania warstwy usługi dla naszych danych wewnątrz bazy danych. Poniższy przykład pokazuje procedurę składowaną, która złącza tabele Customer i Wine w celu zwrócenia klientów wraz z ich ulubionym winem, jak w poprzednim podrozdziale. Jednak ta procedura będzie miała dodaną pewną elastyczność; będzie przyjmowała parametr @FavoriteWineId, dzięki czemu wyniki zostaną ograniczone tylko do tych klientów, których ulubione wino pasuje do wartości przekazanej przez parametr. W przypadku wskazania NULL jako wartości parametru @FavoriteWineId, procedura zwróci dane wszystkich klientów. Tak jak poprzednio, użyjemy w niej złączenia zewnętrznego (OUTER JOIN), zatem w razie nie przesłania wartości parametru zostaną zwróceni również ci klienci, dla których nie zdefiniowano ulubionego wina (jako nazwa wina dla tych klientów pojawi się wartość NULL). Procedurę tę nazwaliśmy GetCustomers. Aby utworzyć procedurę składowaną GetCustomers, wykonaj poniższe działania: 1 . 2 . 3 . 4 . 5 . 6 . 7 . 8 . 9 .
Zaloguj się do portalu Microsoft Azure SQL Database. Kliknij zakładkę Design w lewym panelu strony. Kliknij Stored Procedures w górnej części strony. Kliknij New Stored Procedure (nowa procedura składowana). Zostanie otwarty projektant procedur z domyślną nazwą Stored Procedure1. Zmień nazwę procedury na GetCustomers. Kliknij Add Parameter (dodaj parametr), aby utworzyć nowy paramter. Domyślnie otrzyma on nazwę @Parameter1 i typ danych nvarchar(50). Zmień nazwę parametru na @FavoriteWineId. Kliknij listę rozwijaną poniżej tytułu Select Type (wybierz typ), aby zmienić typ danych parametru na int. Wpisz następujący kod w oknie poniżej: SELECT c.FirstName, c.LastName, w.Category, w.Name FROM Customer AS c LEFT OUTER JOIN Wine AS w ON c.FavoriteWineId = w.WineId WHERE (@FavoriteWineId IS NULL) OR (c.FavoriteWineId = @FavoriteWineId) ORDER BY c.LastName, c.FirstName;
Tworzenie instancji SQL Database
10 . Kliknij Save w pasku narzędzi u góry strony.
Ekran powinien wyglądać podobnie do pokazanego na rysunku 1-25. Jak wyjaśniliśmy wcześniej, procedura ta przyjmuje parametr całkowitoliczbowy o wartości @FavoriteWineId. W procedurze zawarta jest ta sama logika złączenia tabel Customer i Wine w klauzuli FROM, której używaliśmy już wcześniej, ale dodana została logika w klauzuli WHERE w celu sprawdzenia, czy zażądano uwzględnienia ulubionej marki wina (czyli czy przekazana wartość parametru @FavoriteWineId nie wynosi NULL). Następnie albo zwracani są wszyscy klienci (jeśli parametr ma wartość NULL), albo tylko ci, których ulubione wino pasuje do wartości parametru @FavoriteWineId.
Aby przetestować procedurę składowaną, wykonaj następujące działania: 1 . Kliknij New Query u góry strony, aby otworzyć okno nowego zapytania. 2 . W oknie zapytania wpisz EXEC GetCustomers @FavoriteWineId = NULL. 3 . Kliknij Run w górnej części strony, aby wykonać procedurę z przekazaniem NULL
jako wartości parametru @FavoriteWineId. SQL Database zwróci wszystkie trzy wiersze klientów i nazwy ich ulubionych win. 4 . Zmodyfikuj wyrażenie EXEC z kroku 2, zastępując NULL liczbą 3, czyli WineId
dla marki „2010 Mendoza Merlot”.
31
32
Rozdział 1: Poznajemy Microsoft Azure SQL Database
5 . Ponownie kliknij Run. Tym razem zostanie zwrócony tylko wiersz dla Marka
Hansona, gdyż (jak dotąd) jest to jedyny klient, który ma wybrane 2010 Mendoza Merlot jako jego ulubione wino.
Funkcje administracyjne bazy danych Portal zarządzania SQL Database udostępnia również wiele funkcji administrowania bazami danych, które warto poznać, takie jak wsparcie DACPAC i BACPAC (dla celów migracji i kopii zapasowych) oraz śledzenie zdarzeń. Portal zapewnia wsparcie dla formatu plików Data-tier Application Component Package, częściej określanego poprzez akronim DACPAC. Plik DACPAC zawiera pełną definicję bazy danych i może zostać wykorzystany do płynnego, stopniowego wdrażania projektu bazy. Pliki BACPAC są podobne, z tą różnicą, że oprócz definicji bazy danych zawierają również faktyczne dane. Z poziomu portalu zarządzania zapewnione jest pełne wsparcie dla importu i eksportu plików DACPAC oraz BACPAC. Możemy zatem użyć (lokalnie, czyli na własnym komputerze) narzędzi SQL Server Data Tools (SSDT) z Visual Studio do utworzenia plików DACPAC i następnie wdrożyć je w Microsoft Azure SQL Database. Więcej informacji na temat plików DACPAC oraz BACPAC poznamy w kolejnych rozdziałach. Możemy również śledzić zdarzenia występujące w bazie danych, posługując się portalem zarządzania SQL Database. W ten sposób można kontrolować takie zdarzenia, jak połączenia z bazą danych (włącznie z tym, czy były udane, czy nie), zakleszczenia lub wąskie gardła.
Podsumowanie W tym rozdziale przedstawiliśmy podstawowe cechy Microsoft Azure SQL Database. Zaczęliśmy od omówienia Azure i przetwarzania w chmurze, a następnie pokazalismy, jak łatwo można zarejestrować się dla konta Microsoft i subskrypcji Azure. Następnie wykorzystaliśmy portal zarządzania Microsoft Azure do szybkiego utworzenia nowego serwera, a później nowej bazy danych na tym serwerze. W dalszej części pokazaliśmy korzystanie z portalu SQL Database (który uruchamia się z portalu Microsoft Azure za pośrednictwem specjalnego adresu URL) do projektowania bazy danych. Utworzyliśmy i wypełniliśmy przykładowymi danymi dwie powiązane relacyjnie tabele, po czym wykonaliśmy kilka zapytań SELECT do tych tabel. Na koniec pokazaliśmy tworzenie widoków i procedur składowanych oraz wskazaliśmy istnienie innych funkcji administrowania bazą danych w portalu SQL Database. Teraz, gdy Czytelnik ma już pojęcie, czym jest platforma SQL Database, możemy przejść do rozdziału 2, w którym zagłębimy się w szczegóły dotyczące instalacji wstępnej i konfiguracji.
ROZDZI AŁ 2
Konfiguracja i ceny Leonard Lobel
T
eraz, gdy nasza pierwsza baza danych jest już skonfigurowana i uruchomiona, możemy zająć się poznawaniem dodatkowych opcji zarządzania SQL Database. Pokażemy więcej możliwości portalu zarządzania Microsoft Azure, w którym zaczęliśmy pracować w rozdziale 1, „Poznajemy Microsoft Azure SQL Database”, a także narzędzia Microsoft SQL Server Management Studio (SSMS) oraz Windows PowerShell, których obydwu można użyć do administrowania bazami danych w SQL Database. W tym rozdziale pokażemy, jak użyć wspomnianych narzędzi do tworzenia i odrzucania (drop) baz danych. W wielu innych rozdziałach tej książki również będziemy posługiwać się SSMS do wykonywania bardziej szczegółowych akcji i specyficznych zadań. Po zapoznaniu się z tymi narzędziami przedstawimy omówienie planów cenowych i kilka pomocnych wskazówek dotyczących obniżania kosztów korzystania z SQL Database.
Korzystanie z portalu zarządzania platformą Microsoft Azure Jak widzieliśmy w rozdziale 1, portal zarządzania Microsoft Azure zapewnia dobry podstawowy interfejs dla tworzenia i konfigurowania nowych serwerów SQL Database i baz danych. W tym podrozdziale nauczymy się więcej, jak można używać tego portalu do tworzenia baz danych poprzez opcje Quick Create oraz Custom Create, zezwalać na dostęp kliencki poprzez reguły zapory, znajdować łańcuchy połączenia lub usuwać bazy danych.
Tworzenie nowej bazy danych Portal zarządzania udostępnia trzy opcje tworzenia nowej bazy danych: Quick Create (szybkie tworzenie), Custom Create (niestandardowe tworzenie) oraz Import. Quick Create jest najszybszą i najłatwiejszą metodą utworzenia bazy danych. Jeśli odpowiada nam wariant wydania Web o rozmiarze do 1 gigabajta (GB) oraz domyślne 33
34
Rozdział 2: Konfiguracja i ceny
ustawienie sortowania (collation) dla Ameryki Północnej i języków Europy Zachodniej, możemy użyć opcji Quick Create (inne wydania są omówione w dalszej części tego rozdziału w podrozdziale „Konfigurowanie wydania i rozmiaru bazy danych”). Jeśli konieczne jest dostosowanie ustawień sortowania, aby zapewnić wsparcie dla danych w innych językach lub gdy chcemy zadeklarować rozmiar bazy danych większy niż 1 GB, należy użyć opcji Custom Create. Na koniec, jeśli mamy już istniejącą bazę danych (albo Microsoft Azure SQL Database na innym serwerze, albo bazę działającą na instalacji SQL Server w siedzibie), którą chcemy umieścić na określonym serwerze Microsoft Azure SQL Database, należy użyć opcji Import. Ostrzeżenie Wydanie oraz rozmiar bazy danych można zmienić w późniejszym czasie, ale nie ustawienia językowe. Zatem jeśli większość użytkowników tej bazy danych znajduje się poza Stanami Zjednoczonymi i Europą Zachodnią, trzeba się upewnić, że wybrana została właściwa wersja językowa (collation), zapewniająca wsparcie dla wymaganych języków.
Quick Create W przypadku opcji Quick Create musimy dostarczyć tylko dwie informacje, aby utworzyć nową bazę danych: nazwę tej bazy oraz nazwę istniejącego serwera, który ma ją hostować (choć w rzeczywistości Quick Create pozwala nawet na utworzenie nowego serwera dla bazy danych, w tym samym czasie, gdy tworzona jest baza). Aby utworzyć nową bazę danych SQL Database przy użyciu opcji Quick Create, wykonaj następujące działania: 1 . Zaloguj się do portalu Microsoft Azure pod adresem https://manage.windowsa-
zure.com. Zostaniesz przekierowany do głównej strony portalu prezentującej ALL ITEMS. 2 . Kliknij SQL DATABASES w pionowym panelu nawigacyjnym po lewej. 3 . Kliknij przycisk NEW w lewym dolnym rogu strony. 4 . Kliknij opcję QUICK CREATE, pokazaną na rysunku 2-1. 5 . W polu DATABASE NAME (nazwa bazy danych) wpisz MyQuickCreateDb. 6 . W polu SERVER wybierz dostępny serwer z listy rozwijanej (albo wybierz New SQL Database Server, aby utworzyć nowy serwer w locie).
Po krótkiej chwili baza danych MyQuickCreateDb zostanie utworzona i będzie gotowa do użycia. Jest to baza w wydaniu Web o wielkości do 1 GB i z domyślnym ustawieniem językowym.
Korzystanie z portalu zarządzania platformą Microsoft Azure
Rysunek 2-1 Korzystanie z opcji Quick Create do utworzenia nowej bazy danych
Custom Create Przy użyciu opcji Custom Create uzyskujemy kontrolę nad opcjami nowej bazy danych, które nie są dostępne w przypadku Quick Create. Należą do nich wydanie bazy danych (Web lub Business), wielkość oraz ustawienia językowe. W istocie użyliśmy opcji Custom Create w rozdziale 1 do utworzenia bazy danych WineCloudDb, jedynie wywołaliśmy ją w inny sposób, klikając łącze CREATE A SQL DATABASE (patrz rysunek 1-9 w rozdziale 1). Wydania baz danych oraz rozmiary zostaną omówione w podrozdziale „Konfigurowanie wydania i rozmiaru bazy danych”, ale ważną rzeczą, którą trzeba wiedzieć już teraz, jest to, że można zawsze zmienić te ustawienia w późniejszym terminie, gdy baza zostanie już utworzona. Ustawienia sortowania (collation) natomiast nie mogą być zmienione, gdy baza zostanie już utworzona. Ustawienie to jest ważne, jeśli zachodzi potrzeba stosowania danych w innych językach, niż zachodnioeuropejskie. Na przykład, jeśli nasza publiczność wymaga przechowywania swoich danych w języku mandaryńskim, arabskim lub rosyjskim, konieczne jest wybranie odpowiedniego ustawienia collation. Aby utworzyć nową bazę danych SQL Database przy użyciu opcji Custom Create, wykonaj poniższe działania: 1 . Zaloguj się do portalu Microsoft Azure pod adresem https://manage.windowsa-
zure.com.
35
36
Rozdział 2: Konfiguracja i ceny
2 . Kliknij SQL DATABASES w panelu nawigacyjnym po lewej. 3 . Kliknij przycisk NEW w lewym dolnym rogu strony. 4 . Kliknij CUSTOM CREATE. Pojawi się okno dialogowe NEW SQL DATABASE, pokazane
na rysunku 2-2.
Rysunek 2-2 Okno dialogowe NEW SQL DATABASE dla opcji niestandardowej
5 . W polu DATABASE NAME (nazwa bazy danych) wpisz MyCustomCreateDb. 6 . Wybierz wydanie bazy danych (Web dla rozmiaru od 1 do 5 GB lub Business dla
rozmiaru od 10 do 150 GB). 7 . Wybierz collation (ustawienie sortowania) odpowiednio do oczekiwanych danych. 8 . W polu SERVER wybierz dostępny serwer z listy rozwijanej (lub wybierz New SQL Database Server, aby utworzyć nowy serwer w locie).
9 . Kliknij przycisk ze znakiem wyboru („ptaszkiem”), aby zatwierdzić ustawienia.
Po krótkiej chwili baza danych MyCustomCreateDb zostanie utworzona, używając wybranych opcji wydania, wielkości i sortowania.
Korzystanie z portalu zarządzania platformą Microsoft Azure
Importowanie bazy danych Trzecią metodą utworzenia bazy danych z poziomu portalu jest zaimportowanie istniejącej bazy z pliku BACPAC. Plik BACPAC jest zasadniczo kopią zapasową całej bazy danych (schematu i danych), zapisaną jako wielki obiekt binarny (BLOB). Plik BACPAC można utworzyć z bazy danych hostowanej w lokalnej instancji SQL Server (w siedzibie) lub w SQL Database na platformie Azure. Gdy już mamy plik BACPAC, możemy go zaimportować do SQL Database. Zapewnia to łatwy sposób wykonania migracji baz danych pomiędzy wieloma instancjami SQL Server i serwerami Microsoft Azure SQL Database, zlokalizowanymi na różnych serwerach, centrach danych lub subskrypcjach. Importowanie (i eksportowanie) baz danych w Azure jest realizowane poprzez zapisanie plików BACPAC w Azure Blob Storage (magazyn binarny Azure). To z kolei wymaga utworzenia konta Microsoft Azure Storage Account, które jest po prostu kontem dostępowym do magazynu w chmurze. Cały ten proces zostanie omówiony w rozdziale 4, w podrozdziale „Aplikacje warstwy danych SQL”.
Ustawianie reguł zapory W większości przypadków będziemy chcieli, aby nasze produkcyjne bazy danych były dostępne tylko dla naszych usług zlokalizowane w chmurze. W takiej sytuacji wystarczające są domyślne ustawienia zapory, które ograniczają dostęp tylko dla wnętrza centrów danych Microsoft Azure. Jednak od czasu do czasu niezbędny jest dostęp do baz danych bezpośrednio z narzędzi (takich jak SSMS lub Microsoft Visual Studio) uruchomionych na naszych własnych, lokalnych komputerach. W tym celu konieczne jest utworzenie listy adresów IP użytkowników, którzy mają mieć możliwość dostępu do bazy poprzez Internet. Ważne jest, aby zapamiętać, że adres IP, który należy wyspecyfikować, nie jest adresem komputera wewnątrz sieci lokalnej, ale adresem IP, który centrum danych Microsoft Azure widzi, gdy próbujemy uzyskać dostęp do jego zasobów. Zatem jeśli odwołujemy się do bazy z biura, będzie to publiczny, statyczny adres routera wyjściowego. Na przykład, jeśli mamy adresy IP pokazane na rysunku 2-3, adresem, który należy wstawić do konfiguracji zapory, będzie publiczny adres statyczny 123.456.789.012.
37
38
Rozdział 2: Konfiguracja i ceny
Biuro
Centrum danych Azure
Komputer
Router
Adres lokalny: 192.168.1.x
Adres publiczny: 123.456.789.012
Azure SQL Database
Rysunek 2-3 Publiczny IP adres routera internetowego zapewniający dostęp do SQL Database w centrum danych Microsoft Azure
Metoda znajdowania odpowiednich adresów IP będzie się różnić w zależności od tego, czy wszystkie uprawnione maszyny znajdują się za tym samym routerem publicznym, czy nie. Kolejne dwa podrozdziały opisują tworzenie reguł zapory dla obydwu scenariuszy.
Włączanie dostępu z sieci lokalnej W rozdziale 1 dodaliśmy już publiczny adres IP naszego komputera lokalnego (patrz rysunek 1-7 w rozdziale 1). W tym podrozdziale pokażemy, jak dołączyć dodatkowe adresy IP; na przykład w sytuacji, gdy pracę w rozdziale 1 wykonywaliśmy z domu, a teraz chcemy pracować nad rozdziałem 2 z biura. Aby zaktualizować reguły zapory o dodatkowy adres IP, należy wykonać poniższe działania: 1 . Zaloguj się w portalu Microsoft Azure pod adresem https://manage.windowsazu-
re.com. Zostaniesz przekierowany do głównej strony portalu, prezentującej ALL ITEMS. 2 . Kliknij SQL DATABASES w pionowym panelu nawigacyjnym po lewej. Pojawi się
lista dostępnych baz danych, która powinna zawierać bazę WineCloudDb utworzoną w rozdziale 1. 3 . Kliknij nazwę bazy WineCloudDb. Zostanie wyświetlona strona z szybkimi łączami
początkowymi dla tej bazy danych. 4 . Kliknij łącze Set Up Windows Azure Firewall Rules For This IP Address (ustaw reguły
zapory Windows Azure dla tego adresu IP), jak na rysunku 2-4 (Microsoft Azure było wcześniej nazywane Windows Azure). Jeśli ten adres został już dodany w rozdziale 1, otrzymamy komunikat błędu informujący, że ten adres już jest na liście reguł zapory (co oczywiście było oczekiwane).
Korzystanie z portalu zarządzania platformą Microsoft Azure
Rysunek 2-4 Szybkie łącze do tworzenia reguły zapory dla aktualnego adresu sieci
5 . Jeśli pojawi się monit o aktualizację reguł zapory, taki jak pokazany na rysunku
2-5, kliknij YES (tak).
Rysunek 2-5 Automatyczne tworzenie reguły zapory dla wykrytego adresu
Włączanie dostępu dla zdalnego adresu IP Poprzedni scenariusz działa doskonale, jeśli nasz komputer znajduje się w sieci używającej tego samego publicznego adresu IP, co inne maszyny, dla których powinno być dozwolone logowane w bazie danych. Co jednak, jeśli zachodzi potrzeba autoryzowania jakiś komputerów zlokalizowanych w innych miejscach w Internecie? W takim przypadku trzeba ustalić publiczne adresy tych maszyn i dodać je do reguł zapory. Aby otworzyć zaporę dla użytkowników zdalnych, którzy powinni mieć dostęp do bazy danych, zazwyczaj powinniśmy skontaktować się z ich administratorem sieci, aby poznać adres lub adresy IP. Jeśli jednak nie możemy (lub nie chcemy) kontaktować się z administratorem, możemy utworzyć reguły zapory dla tych użytkowników, działając wspólnie z nimi i wykorzystując witrynę whatismyipaddress.com.
39
40
Rozdział 2: Konfiguracja i ceny
Aby to osiągnąć, wykonaj następujące działania: 1 . Poproś użytkownika zdalnego, aby zalogował się do swojego komputera w swojej
sieci. 2 . Niech użytkownik ten otworzy przeglądarkę i przejdzie do witryny http://whatis-
myipaddress.com. 3 . Witryna ta poda użytkownikowi jego adres IP, który powinien nam przekazać. 4 . Zaloguj się do portalu Microsoft Azure. 5 . Kliknij SQL DATABASES w panelu nawigacyjnym po lewej. 6 . Kliknij nazwę serwera dla bazy danych, do której chcesz zapewnić zdalny dostęp. 7 . Kliknij łącze CONFIGURE (konfiguruj) u góry strony. Wyświetlona strona pokazuje
listę wszystkich dozwolonych adresów IP (allowed IP adresses), która powinna zawierać już wpis dla komputera lokalnego, dodany automatycznie wcześniej. 8 . W polu RULE NAME (nazwa reguły) wpisz zrozumiałą nazwę (ale bez używania
spacji) wskazującą zdalnego użytkownika lub grupę, której chcesz przyznać dostęp do bazy danych – na przykład RemoteDevOffice. 9 . Wpisz adres IP uzyskany w kroku 3 (czyli ten, który użytkownik zdalny odczytał
z witryny whatismyipaddress.com) zarówno w polu START IP ADDRESS, jak i END IP ADDRESS. (W tym scenariuszu tworzymy regułę dla pojedynczego adresu, ale te pola tekstowe pozwalają wyspecyfikować zakres adresów IP, jeśli to będzie potrzebne). Strona powinna wyglądać podobnie do pokazanej na rysunku 2-6.
Rysunek 2-6 Dodawanie nowego adresu IP do reguł zapory na serwerze.
10 . Kliknij przycisk SAVE w dolnej części strony.
Korzystanie z portalu zarządzania platformą Microsoft Azure
Od tej chwili komputery ze wskazanego adresu IP będą mogły uzyskiwać dostęp do bazy danych.
Uzyskiwanie łańcucha połączenia W trakcie budowania aplikacji klienckiej, która będzie łączyć się z naszą bazą SQL Database, konieczne będzie umieszczenie w niej łańcucha połączenia dla tej bazy danych. Łańcuch połączenia może występować w wielu różnych formatach, zgodnie z wymaganiami wybranego oprogramowania klienckiego. Dostępne standardy obejmują ADO.NET, ODBC, PHP oraz JDBC. Aby uzyskać łańcuch połączenia dla bazy danych WineCloudDb dla różnych typów klientów bazodanowych, wykonaj poniższe działania: 1 . Zaloguj się w portalu Microsoft Azure. 2 . Kliknij SQL DATABASES w pionowym panelu nawigacyjnym po lewej. Pojawi się
lista dostępnych baz danych, na której powinna znajdować się baza WineCloudDb utworzona w rozdziale 1. 3 . Kliknij nazwę bazy danych WineCloudDb. Zostanie wyświetlona strona szybkich
łączy początkowych dla tej bazy danych. 4 . Kliknij łącze View SQL Database Connection Strings For ADO Net, ODBC, HPP, And JDBC
(Wyświetl łańcuchy połączenia dla…), wyróżnione na rysunku 2-7. Warto też zanotować nazwę serwera pokazaną pod tym łączem, która zawsze zawiera sufiks .database.windows.net. Nazwa ta będzie potrzebna do połączenia z SQL Database przy użyciu SSMS, co wykonamy nieco później w tym rozdziale.
Rysunek 2-7 Łącze pokazujące łańcuchy połączenia dla wybranej bazy danych
41
42
Rozdział 2: Konfiguracja i ceny
5 . Zostaną wyświetlone łańcuchy połączeń w poszczególnych formatach, jak
na rysunku 2-8. Każdy łańcuch umieszczony jest w oddzielnym polu tekstowym (które przewija się w razie potrzeby), skąd można go łatwo skopiować i wkleić do aplikacji klienckiej.
Rysunek 2-8 Wyświetlanie łańcuchów połączenia do bazy danych dla standardów ADO.NET, ODBC, PHP i JDBC
Usuwanie bazy danych Jeśli baza danych (lub serwer) nie jest już więcej potrzebna, możemy użyć portalu zarządzania do jej usunięcia. W tym podrozdziale usuniemy bazy danych MyQuickCreateDb oraz MyCustomCreateDb, utworzone w ramach ćwiczeń wykonywanych wcześniej w tym rozdziale. Aby usunąć niepotrzebne bazy danych, wykonaj poniższe działania: 1 . Zaloguj się w portalu Microsoft pod adresem https://manage.windowsazure.com. 2 . Kliknij SQL DATABASES w panelu nawigacyjnym po lewej. Pojawi się lista
dostępnych baz danych, która powinna zawierać wpisy baz MyQuickCreateDb i MyCustomCreateDb, utworzonych wcześniej w tym rozdziale. 3 . Kliknij, aby zaznaczyć wiersz dla MyQuickCreateDb (nie klikaj kolumn NAME ani SERVER).
4 . Kliknij przycisk DELETE (usuń) w dolnej części strony. 5 . Kliknij YES, DELETE w monicie ostrzegającym, że baza danych zostanie trwale
usunięta.
Korzystanie z SQL Server Management Studio
6 . Powtórz kroki 3−5, aby usunąć bazę danych MyCustomCreateDb.
Portal zarządzania jest doskonałym narzędziem, pozwalającym na pracę z SQL Database z dowolnego komputera wyposażonego w przeglądarkę sieci Web, bez konieczności stosowania żadnego specjalistycznego oprogramowania ani narzędzi. Istnieje jednak wiele programów narzędziowych, które (zainstalowane na lokalnym komputerze) również pozwalają łączyć się i pracować z bazami danych SQL Database. Należą do nich między innymi SSMS oraz PowerShell, którymi zajmiemy się w dalszej części tego rozdziału, a także SQL Server Data Tools (SSDT), które omówimy w rozdziale 10.
Korzystanie z SQL Server Management Studio Administrowanie serwerami i bazami danych SQL Database można wykonywać również przy użyciu SQL Server Management Studio (SSMS), który (a przynajmniej wersja SSMS 2008 R2) dysponuje wbudowanym (choć częściowym) wsparciem dla Microsoft Azure SQL Database. W tym rozdziale pokażemy, jak wykorzystać SSMS do połączenia się z serwerem SQL Database. Następnie nauczymy się, jak tworzyć, modyfikować i usuwać bazy SQL Databases z wnętrza SSMS. Do wykonania ćwiczeń w tym podrozdziale konieczne jest dysponowanie zainstalowanym programem SSMS. W przeciwnym przypadku należy pobrać go z witryny firmy Microsoft (bezpłatnie, albo sam, albo wraz z SQL Server Express). Instrukcje pobierania SSMS zawiera Wprowadzenie do tej książki. Po połączeniu się z SQL Database przy użyciu SSMS można użyć narzędzia Object Explorer do nawigacji pomiędzy obiektami zawartymi w SQL Database, tak samo jak w przypadku lokalnie zainstalowanych instancji SQL Server. Tym niemniej większość innych graficznych narzędzi projektanckich i okien dialogowych nie jest dostępna. Na przykład, jeśli spróbujemy zaprojektować tabelę lub utworzyć nową bazę danych, SSMS otworzy nowe okno zapytania z szablonem skryptu Transact-SQL (T-SQL), który należy przeedytować, zamiast okna projektanta tabel czy okna dialogowego New Database, czego moglibyśmy oczekiwać. Wynika to z faktu, że funkcje te opierają się na SQL Server Management Objects (SMO), dla których SQL Database oferuje tylko ograniczone wsparcie. Tym samym niemal wszystkie działania muszą być wykonane poprzez skrypty T-SQL, gdy chcemy wykorzystać SSMS do konfigurowania SQL Database. Uwaga Narzędzie SQL Server Data Tools (SSDT), stanowiące część Visual Studio, również umożliwia połączenie z SQL Database i działa bardzo podobnie do SSMS. Jednak w odróżnieniu od SSMS narzędzie SSDT nie polega na SMO, zatem zawarty w nim graficzny projektant danych i inne okna dialogowe są obsługiwane w przypadku SQL Database tak samo jak dla lokalnej instancji SQL Server. Narzędzie to poznamy bliżej w rozdziale 10.
43
44
Rozdział 2: Konfiguracja i ceny
Łączenie się z SQL Database Aby połączyć się z SQL Database z programu SSMS, wykonaj następujące czynności: 1 . Uruchom SQL Server Management Studio, wyszukując odpowiedni kafelek
na ekranie startowym systemu Windows (w kategorii Microsoft SQL Server 2012) albo po prostu wpisując sql server management studio w celu wyszukania, po czym klikając znaleziony element, jak na rysunku 2-9. Po chwili powinno pojawić się okno dialogowe Connect To Server (Łączenie z serwerem).
Rysunek 2-9 Uruchamianie SQL Server Management Studio z ekranu startowego Windows
2 . W polu Server Name (nazwa serwera) wpisz .database.windows.net,
zastępując nazwą przypisaną do twojego serwera w Microsoft Azure. wskazówka Nazwę serwera można łatwo odnaleźć w dolnej części strony szybkich łączy, pokazanej wcześniej na rysunku 2-7. Adres ten można również znaleźć w oknie dialogowym Connection Strings, pokazanym na rysunku 2-8.
3 . W polu Authentication (uwierzytelnienie) wybierz SQL Server Authentication z listy
rozwijanej (SQL Database nie wspiera uwierzytelniania Windows). 4 . W polach Login i Password wpisz nazwę użytkownika i hasło przypisane do serwe-
ra, które utworzyłeś w rozdziale 1. Okno dialogowe powinno wyglądać podobnie do pokazanego na rysunku 2-10. 5 . Kliknij przycisk Connect (połącz).
Po krótkiej chwili połączenie zostanie ustanowione i od tej chwili można używać SSMS do zarządzania SQL Database. Jeśli SSMS nie zdoła się połączyć, najbardziej prawdopodobną przyczyną jest to, że publiczny adres IP naszego komputera nie został dodany do reguł zapory zgodnie z opisem zawartym we wcześniejszej części rozdziału. Wyświetlony komunikat błędu powinien jasno wskazywać, czy na tym polega problem. Jeśli połączenie zostanie odrzucone z bardziej ogólnikowym komunikatem
Korzystanie z SQL Server Management Studio
błędu, należy sprawdzić, czy port TCP 1433 jest otwarty w naszej lokalnej zaporze (SQL Database, podobnie jak SQL Server, używa do komunikacji portu 1433).
Rysunek 2-10 Łączenie się z SQL Database z okna dialogowego Connect To Server w SSMS
Po połączeniu można użyć panelu Object Explorer (eksplorator obiektów) narzędzia SSMS do przeglądania komponentów bazy danych WineCloudDb, jak na rysunku 2-11.
Rysunek 2-11 Przeglądanie zawartości bazy danych w panelu Object Explorer
45
46
Rozdział 2: Konfiguracja i ceny
Tworzenie nowej bazy danych Jak wspomnieliśmy wcześniej, zwykle używane okno dialogowe New Database (nowa baza danych) w SSMS nie jest dostępne przy połączeniu z SQL Database. Zamiast tego SSMS jedynie otworzy okno zapytania T-SQL z szablonem wyrażenia CREATE DATABASE, co może być dość zaskakujące. Tak więc prostszą metodą utworzenia nowej bazy danych w SQL Database jest bezpośrednie przejście do pustego okna zapytania i wysłanie podstawowego wyrażenia CREATE DATABASE. Aby utworzyć nową bazę danych przy użyciu okna zapytania SSMS, wykonaj poniższe działania: 1 . Połącz się z serwerem SQL Database zgodnie z opisem w poprzedniej procedurze. 2 . Kliknij prawym klawiszem myszy nazwę serwera w panelu Object Explorer i wybierz
polecenie New Query (nowe zapytanie). 3 . W oknie zapytania wpisz CREATE DATABASE MyDb. Okno SSMS powinno
wyglądać podobnie do pokazanego na rysunku 2-12.
Rysunek 2-12 Tworzenie nowej bazy danych poprzez wykonanie skryptu T-SQL w oknie zapytania SSMS
4 . Naciśnij F5 (lub kliknij ikonę Execute w pasku narzędzi), aby wykonać wyrażenie.
Jego realizacja powinna zająć tylko kilka sekund.
Korzystanie z PowerShell
Zmienianie wydania i maksymalnego rozmiaru bazy danych Baza MyDb utworzona w poprzedniej procedurze otrzymała domyślną konfigurację, czyli wydanie Web i rozmiar do 1 GB, podobnie jak bazy tworzone opcją Quick Create. Jeśli zachodzi potrzeba zmiany wydania i rozmiaru, można to zrealizować, wysyłając wyrażenie ALTER DATABASE. Na przykład w celu zmiany z wydania Web na Business i ustalenia rozmiaru maksymalnego na 10 GB, należy wykonać następujące polecenie T-SQL w oknie zapytania: ALTER DATABASE MyDb MODIFY (EDITION='business', MAXSIZE=10GB)
Usuwanie bazy danych Odrzucenie bazy w SQL Database odbywa się tak samo, jak każdej innej bazy w SQL Server. Należy w tym celu albo kliknąć bazę prawym klawiszem myszy w panelu Object Explorer i wybrać Delete, albo wykonać poniższe wyrażenie T-SQL w oknie zapytania: DROP DATABASE MyDb
Korzystanie z PowerShell PowerShell jest nowoczesną powłoką i językiem skryptowym opracowanym przez Microsoft, który wspiera szeroki zakres zadań administracji systemami. Zadania te są realizowane poprzez wykonywanie poleceń (nazywanych cmdlet, co stanowi skrót od command-let) w oknie wiersza poleceń PowerShell. Firma Microsoft opracowała również polecenia cmdlet do zarządzania Microsoft Azure, w tym wiele przydatnych poleceń dotyczących Database. Nawet jeśli mamy już zainstalowaną powłokę PowerShell, specjalne polecenia cmdlet dla Microsoft Azure muszą zostać zainstalowane oddzielnie. Kolejny podrozdział prezentuje pobieranie i instalowanie tych poleceń.
Instalowanie poleceń cmdlet dla Microsoft Azure W celu zainstalowania modułu Microsoft Azure dla PowerShell, wykonaj następujące działania: 1 . W przeglądarce sieci Web przejdź do witryny https://www.windowsazure.com/
en-us/downloads.
47
48
Rozdział 2: Konfiguracja i ceny
2 . Przewiń stronę aż do zlokalizowania tytułu Command-Line Tools (Narzędzia wiersza
polecenia), po czym kliknij łącze Install (Instaluj) poniżej Windows PowerShell, jak na rysunku 2-13.
Rysunek 2-13 Pobieranie poleceń cmdlet dla Microsoft Azure
3 . W monicie z zapytaniem, czy uruchomić, czy też zapisać plik, kliknij Run
(Uruchom). 4 . Jeśli pojawi się okno kontroli konta użytkownika (UAC), kliknij Yes. 5 . W oknie dialogowym Web Platform Installer (pokazanym na rysunku 2-14) kliknij Install.
Rysunek 2-14 Instalowanie poleceń cmdlet dla Azure
Korzystanie z PowerShell
6 . Kliknij I Accept (akceptuję), aby rozpocząć instalację. 7 . Po ukończeniu instalacji kliknij Finish. 8 . Kliknij Exit (wyjdź), aby zamknąć okno dialogowe Web Platform Installer.
Korzystanie z PowerShell ISE Choć do pisania skryptów PowerShell można użyć dowolnego prostego edytora tekstowego (choćby Notatnika), zintegrowane środowisko skryptowe (Integrated Scripting Environment – ISE) jest znacznie bardziej produktywnym środowiskiem. Jak zobaczymy, udostępnia ono kilka przydatnych funkcjonalności, takich jak wyróżnianie składni i automatyczne dopełnianie w stylu IntelliSense. PowerShell ISE nie ma swojego kafelka na ekranie startowym Windows, zatem musi zostać uruchomione z wiersza polecenia. Aby uruchomić narzędzie PowerShell ISE i wyświetlić informacje pomocy dla poleceń cmdlet Azure SQL Database, wykonaj poniższe działania: 1 . Otwórz okno wiersza poleceń (kafelek dla niego można znaleźć na ekranie star-
towym w kategorii Windows System, ale można po prostu wpisać cmd, aby je wyszukać). 2 . Po znaku zachęty wpisz powershell_ise. 3 . Po uruchomieniu PowerShell ISE zacznij wpisywać get-help get-azuresql i prze-
rwij na chwilę. Po chwili pojawi się wyskakujące okno ukazujące nazwy wszystkich poleceń cmdlet zaczynających się od get-azuresql, jak na rysunku 2-15.
Rysunek 2-15 Uzyskiwanie pomocy na temat poleceń cmdlet dotyczących Microsoft Azure SQL Database
49
50
Rozdział 2: Konfiguracja i ceny
4 . Podwójnie kliknij dowolną z nazw, aby dokończyć polecenie, po czym naciśnij
Enter, by wyświetlić informacje dotyczące wybranego cmdlet.
Konfigurowanie PowerShell dla konta Microsoft Zanim będziemy mogli zacząć korzystać z PowerShell do zarządzania usługami Azure, konieczne jest skonfigurowanie go do korzystania z naszego konta. Sprowadza się to do zalogowania w portalu i następnie wykonania kilku poleceń PowerShell, aby odczytać informacje o naszym koncie z Azure i zaimportować je do środowiska PowerShell. W tym podrozdziale pokażemy ten proces. Aby skonfigurować PowerShell do używania swojego konta Microsoft, wykonaj następujące czynności: 1 . Zaloguj się do portalu Microsoft Azure pod adresem https://manage.windo-
wsazure.com. Krok ten jest nieodzowny, aby PowerShell mógł zidentyfikować konto. Jeśli nie zalogujesz się wcześniej, przy próbie odczytania ustawień konta w PowerShell pojawi się monit o zalogowanie. 2 . Uruchom PowerShell ISE, zgodnie z opisem w poprzedniej procedurze. 3 . Wpisz Get-AzurePublishSettingsFile, aby odczytać swoje ustawienia konta.
Internet Explorer otworzy się automatycznie i pobierze plik .publishsettings zawierający informacje o koncie. 4 . Kliknij Save, aby zapisać plik .publishsettings w domyślnym folderze pobierania. ważne Plik .publishsettings powinien być przechowywany w bezpiecznym i poufnym miejscu, gdyż zapewnia on dostęp do subskrypcji Azure związanych z kontem Microsoft.
5 . Wróć do PowerShell ISE i wpisz Import-AzurePublishSettingsFile
lishsettings>, zastępując pełną nazwą (wraz ze ścieżką) pliku ustawień konta, który właśnie został zapisany w folderze pobierania (typowo będzie to C:\Users\\Downloads\.publishsettings). Uwaga Nazwa pliku może być bardzo długa, ale funkcja automatycznego dopełniania PowerShell ISE jest pomocna, wyświetlając listy możliwości IntelliSense w trakcie pisania. Naciśnięcie klawisza Tab dopełnia kolejne fragmenty ścieżki i nazwy pliku .publishsettings.
PowerShell ISE nie wyświetla niestety żadnego komunikatu o udanym zaimportowaniu ustawień. Jedynie w razie niepowodzenia pojawi się komunikat o błędzie. Innymi słowy, jeśli bez żadnej informacji zwrotnej zostaniemy przekierowani ponownie do wiersza polecenia PowerShell, oznacza to, że wszystko poszło dobrze.
Korzystanie z PowerShell
Jak już wiemy z rozdziału 1, każda baza danych SQL Database jest hostowana przez serwer Azure. Przypomnijmy, że najpierw wykorzystaliśmy portal zarządzania Microsoft Azure do utworzenia serwera, a dopiero potem utworzyliśmy bazę danych na tym serwerze. Posłużyliśmy się też funkcjami portalu do ustawienia reguł zapory, zapewniających dostęp do bazy danych ze wskazanych adresów IP. Teraz wykonamy te same zadania, używając kilku poleceń PowerShell.
Tworzenie nowego serwera Na początek utworzymy nowy serwer i dodamy do niego regułę zapory dla naszego publicznego adresu IP, aby móc uzyskiwać do niego dostęp poprzez PowerShell. W tym celu wykonaj następujące działania w oknie PowerShell ISE: 1 . Wpisz polecenie New-AzureSqlDatabaseServer -Location "East US"
-AdministratorLogin "" -AdministratorLoginPassword "", zastępując oraz poświadczeniami, które mają być przypisane do nowego serwera. Serwer zostanie utworzony, a PowerShell potwierdzi to, wyświetlając nazwę nowego serwera, jak na rysunku 2-16.
Rysunek 2-16 Tworzenie nowego serwera w PowerShell
-RuleName -StartIpAddress -EndIpAddress , gdzie jest nazwą serwera utworzonego w pierwszym kroku, odczytaną z komunikatu zwrotnego, jest arbitralnie wybraną nazwą nowej reguły (nie zawierającą spacji), zaś jest publicznym adresem IP twojego komputera. Polecenie to tworzy nową regułę zapory, która będzie zezwalać na dostęp do serwera z adresu IP komputera lokalnego. Także ono jest potwierdzane komunikatem, podobnym do pokazanego na rysunku 2-17.
Rysunek 2-17 Tworzenie nowej reguły zapory przy użyciu PowerShell Uwaga Do ustalenia publicznego adresu swojego komputera (a ściślej – adresu publicznego routera, używanego do uzyskiwania dostępu do Internetu), można wykorzystać witrynę whatismyipaddress.com, zgodnie z opisem zawartym w podpunkcie „Włączanie dostępu dla zdalnego adresu IP” wcześniej w tym rozdziale.
51
52
Rozdział 2: Konfiguracja i ceny
Tworzenie nowej bazy danych Polecenie cmdlet New-AzureSqlDatabase tworzy nową bazę danych. Jednak zanim będzie można użyć tego polecenia, trzeba najpierw utworzyć obiekt poświadczeń, aby móc użyć swoich poświadczeń do utworzenia kontekstu zabezpieczeń powiązanego z serwerem, na którym chcemy utworzyć bazę danych. Kontekst serwera zapiszemy w zmiennej, po czym odwołamy się do tej zmiennej w poleceniu New-AzureSqlDatabase, aby utworzyć bazę danych (analogiczne działanie trzeba będzie wykonać również dla wszystkich innych poleceń cmdlet wykonywanych wobec określonego serwera). Aby utworzyć nową bazę danych, w oknie PowerShell ISE wykonaj poniższe działania: 1 . Wpisz $creds = new-object System.Management.Automation.PSCredential
("", ("" | ConvertTo-SecureString -asPlainText -Force)), gdzie oraz to nazwa logowania administratora i hasło przypisane podczas tworzenia serwera w poprzedniej procedurze. Polecenie to zapisze poświadczenia administratora w bezpiecznym (zaszyfrowanym) ciągu znaków w zmiennej $creds. 2 . Wpisz $context = New-AzureSqlDatabaseServerContext -ServerName
-serwera> -Credential $creds, gdzie jest nazwą serwera utworzonego w poprzedniej procedurze (nazwa ta jest wyświetlana przez PowerShell po utworzeniu serwera, co było widać wcześniej na rysunku 2-16). Polecenie to tworzy kontekst powiązany z poświadczeniami wygenerowanymi w kroku 1 i serwerem utworzonym wcześniej i zapisuje go w zmiennej (obiekcie) o nazwie $context. 3 . Wpisz New-AzureSqlDatabase -Context $context -DatabaseName MyNewDb.
Polecenie to tworzy nową bazę danych o nazwie MyNewDb. Baza ta jest tworzona na serwerze wskazywanym przez obiekt $context przy użyciu poświadczeń określonych w zmiennej $creds. Po utworzeniu bazy danych PowerShell wyświetla informacje o niej, jak na rysunku 2-18.
Rysunek 2-18 Tworzenie nowej bazy danych przy użyciu PowerShell
4 . Często przydatna jest możliwość zobaczenia wszystkich baz danych, które ist-
nieją na wybranym serwerze. Aby to uzyskać, można użyć polecenia GetAzureSqlDatabase -Context $context. Jak widać na wyjściu tego polecenia pokazanym na rysunku 2-19, serwer zawiera między innymi bazę master, tak samo jak każda standardowa instancja SQL Server.
Korzystanie z PowerShell
Rysunek 2-19 Wyświetlanie listy wszystkich baz danych istniejących na serwerze
Baza danych utworzona poleceniem New-AzureSqlDatabase jest domyślnie bazą wydania Web z maksymalnym rozmiarem wynoszącym 1 GB i domyślnym ustawieniem sortowania. Jest to ten sam typ, jaki jest tworzony poprzez opcję Quick Create w portalu zarządzania Microsoft Azure. Aby zmienić te domyślne paramtery, trzeba użyć przełączników –Edition, –MaxSizeGb oraz –Collation, podając odpowiednie wartości wydania, rozmiaru i sortowania. Na przykład poniższe wyrażenie tworzy bazę wydania Business o wielkości do 150 GB (maksymalnej dostępnej): New AzureSqlDatabase MaxSizeGB 150
Context $context
DatabaseName MyBigDb
Edition Business
Wydanie i maksymalny rozmiar (ale nie sortowanie) można zmienić dla każdej istniejącej bazy danych, używając polecenia cmdlet Set-AzureSqlDatabase z przełącznikami –Edition oraz –MaxSizeGb. Na przykład poniższe polecenie rekonfiguruje dopiero co utworzoną bazę danych MyNewDb na wydanie Business o rozmiarze maksymalnym wynoszącym 20 GB: Set AzureSqlDatabase MaxSizeGB 20
Context $context
DatabaseName MyNewDb
Edition Business
Usuwanie bazy danych Polecenie cmdlet Remove-AzureSqlDatabase powoduje usunięcie bazy SQL Database z serwera, przy czym zarówno serwer, jak i poświadczenia administracyjne trzeba przekazać jako obiekt kontekstu. Aby usunąć utworzoną w poprzedniej procedurze bazę MyNewDb, wykonaj poniższe czynności: 1 . Wpisz Remove-AzureSqlDatabase -Context $context -DatabaseName MyNewDb. 2 . W monicie potwierdzenia kliknij Yes.
Jeśli polecenie Remove-AzureSqlDatabase ma zostać użyte w skrypcie, który będzie wykonywany bez interwencji użytkownika, można dołączyć do niego przełącznik –Force. Powoduje on natychmiastowe usunięcie bazy danych bez monitowania o potwierdzenie.
53
54
Rozdział 2: Konfiguracja i ceny
Planowanie budżetu dla SQL Database Końcowa część tego rozdziału obejmuje różne zagadnienia związane z wydatkami, które trzeba rozważyć przy decydowaniu się na korzystanie z SQL Database. W szczególności omówimy ceny dotyczące magazynowania SQL Database i zużywanego pasma. Jak można się domyślić, w tym podrozdziale nie będzie żadnych procedur „krok po kroku”. Ostrzeżenie Jak wspomnieliśmy już we Wprowadzeniu, cenniki Microsoft Azure ulegają ciągłym zmianom. Przedstawione informacje oparte są na danych cen, które były aktualne w chwili pisania książki. Zdecydowanie należy sprawdzić aktualne wartości w witrynie firmy Microsoft. Cenniki dla SQL Database można znaleźć pod adresem http://www.windowsazure.com/en-us/pricing/details/sql-database.
Informacje zawarte w tym podrozdziale powinny pomóc w ustaleniu właściwej konfiguracji, a także dać kilka wskazówek pozwalających oszczędzić nieco pieniędzy przy wdrożeniach SQL Database. Warto także zajrzeć do kalkulatora online, który szybko wylicza koszty na podstawie podanych parametrów. Kalkulator ten jest dostępny pod adresem http://www.windowsazure.com/en-us/pricing/calculator.
Magazyn SQL Największym składnikiem kosztów korzystania z SQL Database jest cena za rzeczywistą przestrzeń dyskową potrzebną do przechowania danych w Microsoft Azure. Tabela 2-1 prezentuje bieżące ceny za magazynowanie SQL Database2. Tabela 2-1 Cennik magazynu SQL Database Wielkość bazy danych
Cena za jeden miesiąc
Do 100 MB
stała 4.995 USD
100 MB do 1 GB
stała 9,99 USD
1 GB do 10 GB
9,99 za pierwszy GB + 3,996 za każdy dodatkowy GB
10 GB do 50 GB
45,954 USD za pierwszych 10 GB + 1,996 za każdy dodatkowy GB
50 GB do 150 GB
Zobacz http://www.windowsazure.com/en-us/pricing/details/ sql-database/
2 W przypadku łączenia się z pokazanymi wyżej cennikami z komputera zlokalizowanego w Polsce ceny są prezentowane domyślnie w euro, a nie dolarach, ale można zmienić walutę w dowolnym momencie.
Planowanie budżetu dla SQL Database
Jeśli nasza firma ma już bazę danych SQL Server zainstalowaną w siedzibie i chcemy obliczyć jej wielkość, aby móc oszacować koszt migracji do SQL Database, można odpytać wartość w kolumnie reserved_page_count dynamicznego widoku zarządzania sys.dm_db_partition_stats. Wartość w tej kolumnie podaje liczbę stron danych, zatem uzyskany wynik trzeba przemnożyć przez 8192 (liczba bajtów na stronie), a następnie podzielić dwukrotnie przez 1024, aby przetworzyć wynik na megabajty (pierwsze podzielenie przekształci bajty na kilobajty, a drugie kilobajty na megabajty): SELECT (SUM(reserved_page_count) * 8192) / 1024 / 1024 AS DbSizeInMB FROM sys.dm_db_partition_stats
Pasmo klienckie Jeśli łączymy się z bazą danych z tego samego centrum danych, nie ponosimy żadnych kosztów związanych z pasmem przesyłowym dla danych przekazywanych zarówno do, jak i z bazy. Gdy łączymy się z bazą danych spoza centrum, zostaniemy obciążeni opłatami tylko za „ruch wychodzący”, co oznacza, że koszty dotyczą tylko danych wysyłanych z bazy danych do klientów, podczas gdy przepływ wchodzący (dane przesyłane do bazy danych) jest bezpłatny. Trzeba zauważyć, że opłaty te są różne dla różnych regionów świata. Ceny pasma klienckiego są zależne od lokalizacji centrum danych Microsoft Azure, niezależnie od tego, gdzie zlokalizowani są sami klienci uzyskujący dostęp do bazy. Ponownie trzeba zaznaczyć, że szczegółowe dane dotyczące cen mogą ulegać zmianom. Ceny za transfer danych obowiązujące w chwili pisania tych słów zostały zebrane w tabeli 2-2. Tabela 2-2 Ceny pasma klienckiego dla SQL Database Transfer danych (tylko wychodzący)
Magazyn dla kopii zapasowych Jeśli zdecydujemy się na wykorzystanie Azure Storage do zarządzania plikami BACPAC kopii zapasowych, przestrzeń magazynowa dla tych plików pociąga za sobą opłaty za użytkowanie. Ceny zależne są od wielkości danych, ale użycie Azure Storage do przechowania kopii zapasowych jest w ogólności znacznie tańsze, niż wykorzystanie w tym celu magazynu SQL Database (patrz tabela 2-3). Dla bardzo małej bazy danych (do 100 MB) koszt jej utrzymania w Azure wynosi 4,95 dolara miesięcznie, podczas gdy koszt przestrzeni magazynowej na kopie zapasowe to zaledwie 0,035 dolara, zakładając pięć pełnych kopii zapasowych (to mniej niż jedna setna kosztów bazy). W miarę wzrostu wielkości ceny przestrzeni magazynowej stają się względnie większe, ale nadal są znacznie niższe, niż koszt utrzymania bazy danych. Przy 100 GB koszt miesięczny SQL Database wynosi 175 dolarów miesięcznie, zaś cena Azure Storage to tylko 7 dolarów za jedną kopię (1/20 kosztu). Trzeba jednak zachować ostrożność, gdyż opłaty mogą bardzo szybko wzrosnąć, jeśli zastosujemy strategię kopii zapasowych wymagającą przechowywania wielu kopii. Jeśli jednak będziemy stosować prostą strategię kopii przyrostowych, w której utrzymywana jest tylko jedna kopia dla ostatniej godziny, dnia, tygodnia, miesiąca oraz roku, wówczas dla 100-megabajtowej bazy będzie trzeba zapłacić tylko 0,175 miesięcznie za przechowywanie tych kopii, a w przypadku bazy o wielkości 100 GB cena wyniesie jedynie 35 dolarów – to niewielka cena za gwarancję bezpieczeństwa naszych danych. Dodatkowo możemy wybrać replikację geograficzną dla naszego magazynu. Jest to atrakcyjna opcja w przypadku kopii zapasowych, gdyż zapewnia geograficzne rozproszenie danych i ułatwia odtwarzanie po awariach, a dodatkowo wychodzi taniej, niż opłaty za magazynowanie danych w oddzielnych centrach danych i (dodatkowo) za przesyłanie danych pomiędzy tymi centrami. Tabela 2-3 Ceny przestrzeni magazynowej dla kopii zapasowych (w USD) Magazyn
Pasmo magazynu kopii zapasowych Główna różnica pomiędzy kosztami kopii zapasowych przechowywanych zewnętrznie (offsite) i wewnętrznie w centrum danych (onsite) to cena pasma zużywanego na wysyłanie kopii do innego centrum danych. Opłaty za zużycie pasma są takie same, jak te dotyczące działania bazy danych, zatem można wrócić do tabeli 2-2, aby je poznać. Podobnie jak w przypadku dostępu do bazy danych, opłaty za przesyłanie danych pomiędzy centrami są naliczane tylko w jedną stronę; nie zostaniemy obciążeni podwójnie za pasmo zużyte na przesył wychodzący z jednego centrum i przychodzący do drugiego. Zatem jeśli mamy bazę o wielkości 100 MB i kopie wykonywane codziennie, opłaty za zużycie pasma będą następujące: 0,1 GB X 0,12 USD/GB X 30 dni
0,36 USD/miesiąc
Jeśli zdecydujemy się wykonywać kopię zapasową co godzinę, opłaty będą następujące: 0,1 GB X 0,12 USD/GB X 24 godziny X 30 dni
8,64USD/miesiąc
Jeśli zdecydujemy się wykonywać te kopie zapasowe w obrębie tego samego centrum danych, żadne opłaty za pasmo przenoszenia nie zostaną naliczone. Warto rozważyć też inną opcję, a mianowicie geograficznie replikowany magazyn, wspomniany w poprzednim podrozdziale, który również zapewnia ochronę polegającą na przechowywaniu kopii zapasowych w różnych centrach danych. W tym scenariuszu konto magazynowe utworzone dla kopii zapasowych bazy danych ma włączoną replikację geograficzną, co oznacza, że dane są automatycznie replikowane (powielane) w różnych centrach danych w obrębie tego samego regionu. Dla przykładu, jeśli nasze konto magazynowe jest utworzone w centrum North Central, jego replika może być umieszczona w centrum South Central, przy czym obydwa centra danych są zlokalizowane w Stanach Zjednoczonych; nie będą kopiowane do jakiegoś centrum danych w Europie lub Azji. Głównym powodem, dla którego magazyn replikowany geograficznie jest atrakcyjny, są koszty. Załóżmy, że mamy 100-megabajtową bazę danych i wykonujemy kopie zapasowe co godzinę do zdalnego konta magazynowego. Jeśli będziemy utrzymywać godzinne, codzienne, tygodniowe, miesięczne i roczne kopie zapasowe (łącznie pięć zestawów), będziemy musieli zapłacić: 0,1 GB X 0,070 USD/GB/miesiąc X 5 plików kopii 0,035 USD/miesiąc za przestrzeń magazynową oraz 8,64 USD na miesiąc opłat za pasmo, czyli łącznie 8,69 USD
Jeśli zdecydujemy się na wyższą opłatę za geograficznie replikowany magazyn, w rzeczywistości oszczędzimy pieniądze. Koszt magazynowania kopii dla tej samej bazy danych wyniesie bowiem: 0,1 GB X 0,095 USD/GB/miesiąc X 5 plików kopii
0,0475 USD/miesiąc
57
58
Rozdział 2: Konfiguracja i ceny
Jednak w tym przypadku nie musimy ponosić dodatkowego kosztu za replikację danych. Całkowita opłata za przechowanie kopii zapasowych (i to w dwóch egzemplarzach) w tym przypadku wynosi tylko 0,0475 USD, a nie 8,69, jak w scenariuszu ręcznej replikacji.
Wsparcie Przy omawianiu kosztów często pomijanym elementem jest cena pakietu pomocy technicznej. Firma Microsoft oferuje kilka poziomów wsparcia, które można przejrzeć na stronie http://www.windowsazure.com/en-us/support/plans, pokazanej na rysunku 2-20.
Rysunek 2-20 Przeglądanie dostępnych planów pomocy technicznej Azure
Jeśli dopiero zaczynamy i potrzebujemy jakiejś pomocy, łatwo można ją uzyskać, korzystając z forum użytkowników i innych zasobów online. Jednak gdy nasze aplikacje zaczną stawać się bardziej złożone i musimy obsłużyć wielu użytkowników, warto mieć pod ręką plan pomocy technicznej. Przekonaliśmy się niejednokrotnie, że we wstępnych fazach prób zdiagnozowania problemów przydaje się pomoc personelu firmy Microsoft. Z tego względu zalecane jest, aby po zakończeniu okresu próbnego wdrożyć przynajmniej plan pomocy technicznej Developer.
Nie należy przechowywać w bazie danych obiektów BLOB. Zamiast tego należy posłużyć się opcją Azure Blob Storage dla obrazów, wideo lub innych plików, które inaczej musiałyby być przechowywane jako kolumny varbinary(max) lub image w bazie danych. Koszty Blob Storage są znacznie niższe, niż opłaty za przestrzeń magazynową SQL Database. Baza danych SQL Database o wielkości 100 GB kosztuje 175 dolarów miesięcznie, podczas gdy ta sama przestrzeń w Blob Storage ma cenę tylko 7 dolarów. Aby zredukować koszty i poprawić wydajność, takie wielkie elementy należy umieścić w Blob Storage, a w bazie zapisać tylko klucze rekordów Blob Storage, odwołujące się do tych obiektów. Taka strategia będzie miała wielki wpływ na ceny, jeśli baza danych ma przechowywać pliki. Oznaczanie (cycle out) starych (nieużywanych) rekordów i tabel zawartych w bazie danych. W ten sposób oszczędzimy pieniądze, a wiedza, co można, a czego nie można usunąć, jest szczególnie potrzebna, gdy zbliżymy się do zadeklarowanej wielkości maksymalnej i musimy szybko usunąć jakieś rekordy, aby zrobić miejsce na nowe dane. Naszą bazę SQL Database należy umieścić w tym samym centrum danych, w którym zlokalizowane są witryny, usługi mobilne czy inne komponenty Azure, które będą klientami dla tej bazy danych. Wspólna lokalizacja aplikacji i bazy danych nie tylko chroni przed naliczaniem opłat za pasmo przesyłowe dla danych przekazywanych pomiędzy różnymi centrami danych, ale również zapewni lepszą wydajność aplikacji. Użycie strategii usuwania starych kopii zapasowych, tak by móc zapewnić przywrócenie danych historycznych, ale zredukować potrzeby magazynowania. Jeśli będziemy przechowywać przyrostowe kopie zapasowe z ostatniej godziny, dnia, tygodnia, miesiąca i roku, zachowamy dobre pokrycie, jednocześnie nie przekraczając 25 procent kosztów bazy danych na te kopie. Na przykład dla bazy o wielkości 1 GB koszt samej bazy wyniesie 9,99 USD miesięcznie, ale tylko 0,10 USD za przestrzeń magazynową dla kopii zapasowych. Zamiast zdalnego konta magazynowego dla kopii zapasowych typu offsite, należy użyć magazynu replikowanego geograficznie, aby uchronić się przed naliczaniem opłat za pasmo przesyłowe. Jeśli planowane jest wykorzystanie znacznych zasobów Azure w naszej aplikacji, można wybrać jeden z planów czasowych. Wprawdzie oznaczają one poniesienie pewnych wydatków z góry, ale pozwalają oszczędzić od 20 do 30 procent kosztów w przypadku większych aplikacji.
59
60
Rozdział 2: Konfiguracja i ceny
Konfigurowanie wydania i rozmiaru bazy danych Jak pokazaliśmy już, przy tworzeniu SQL Database należy wyspecyfikować również wydanie bazy danych i jej maksymalny rozmiar (lub zgodzić się na domyślne ustawienie wydania Web o rozmiarze 1 GB). W tym podrozdziale wyjaśnimy znaczenie wydania bazy danych i ustawień rozmiaru. W przeszłości firma Microsoft zapowiadała możliwość dodania większej liczby funkcji w wydaniu Business, niż dostępne w wydaniu Web. Jednak w chwili pisania tych słów funkcjonalność obu wydań jest taka sama. Tak więc, jaki jest (jeśli w ogóle) powód istnienia tych ustawień? Zasadniczo sprowadza się on do kontrolowania kosztów. Wydanie bazy określa maksymalny jej rozmiar, zaś ten bezpośrednio wpływa na ponoszone koszty. Dostępne wielkości maksymalnego rozmiaru zebrane są w tabeli 2-4. Tabela 2-4 Wydania SQL Database i rozmiary Wydanie
Dostępne rozmiary maksymalne
Web
1 GB, 5 GB
Business
10 GB, 20 GB, 30 GB, 40 GB, 50 GB, 100 GB, 150 GB
Uwaga W chwili kierowania tej książki do druku firma Microsoft udostępniła wersję zapoznawczą (preview) wydania SQL Database Premium. Jest bardziej kosztowny wariant, niż standardowe wydania Web i Business, obsługujący rozmiar bazy do 500 GB. Jak pokażemy w rozdziale 8, wydanie Premium pozwala również na skalowalność wydajności poprzez użycie dedykowanych procesorów i pamięci. Jednocześnie zapowiedziano wprowadzenie dwóch nowych wydań (Basic i Standard). Począwszy od połowy roku 2015, wydania Web i Business będą wycofywane i docelowo zostaną zastąpione trzema wydaniami Basic, Standard i Premium na sześciu poziomach wydajnościowych.
Miesięczne opłaty za SQL Database są zależne od danych rzeczywiście przechowywanych w bazie, a nie zadeklarowanej wielkości maksymalnej (z wyjątkiem wydań Web). Jeśli zatem użyjemy 2 GB przestrzeni w bazie z zadeklarowaną wielkością maksymalną 150 GB, zostaniemy obciążeni opłatą za te 2 GB. Oznacza to, że możemy bezpiecznie ustawić wielkość maksymalną, która wygodnie pomieści wszystkie dane aplikacji i pozostawi jeszcze trochę miejsca na wzrost. Ustawienie maksymalnego pułapu danych chroni przed sytuacją, w której jakiś błąd programowy spowoduje dodanie zbyt wielu rekordów i nieoczekiwanie wysoki rachunek. Gdy baza danych osiągnie rozmiar maksymalny, nie będzie pozwalać na dalsze dodawanie danych, choć nadal możliwe będzie ich aktualizowanie i usuwanie. Warto zaplanować zawczasu działania w takim scenariuszu. Jednym z możliwych wyjść jest
Podsumowanie
zwolnienie miejsca poprzez usunięcie niepotrzebnych rekordów. Trzeba jednak pamiętać, że zwolnienie miejsca po usunięciu rekordów może zająć nieco czasu, zatem nie należy oczekiwać, że będziemy mogli przywrócić normalne działanie bezpośrednio po wyczyszczeniu bazy. Inną opcją jest zwiększenie wielkości limitu dla bazy danych, albo na stałe (na przykład w celu dostosowania się do rozrostu biznesu) lub chwilowo (aby móc przyjmować nowe rekordy i uzyskać nieco czasu na stworzenie strategii zredukowania wielkości bazy danych). Jako środek prewencyjny, warto pouczyć użytkowników o zasadach wycofywania określonych typów rekordów, dzięki czemu można będzie usuwać stare i nieużywane rekordy z systemu. Takie szkolenie zdecydowanie powinno odbyć się dużo wcześniej, niż osiągnięty zostanie limit rozmiaru bazy. Trzeba też obserwować wielkość bazy i jej wzrost z upływem czasu, aby móc przewidzieć, kiedy nadmiernie zbliżymy się do granicy. W rozdziale 9 przedstawimy więcej informacji na temat monitorowania naszego systemu. Jak pokazaliśmy wcześniej w tym rozdziale, zmianę wydania i maksymalnego rozmiaru SQL Database można wykonać w dowolnej chwili zarówno poprzez T-SQL, jak i PowerShell. Alternatywnie można wykorzystać portal zarządzania Microsoft Azure do konfigurowania wydania i rozmiaru bazy poprzez przeglądarkę.
Podsumowanie W tym rozdziale pokazaliśmy, jak tworzyć i konfigurować bazy danych SQL Database, wykorzystując portal zarządzania Microsoft Azure, SQL Server Management Studio oraz środowisko PowerShell. Poznaliśmy techniki łączenia się każdym z tych narzędzi z Azure oraz ich wykorzystanie do tworzenia i zarządzania serwerami, regułami zapory i bazami danych. Następnie omówiliśmy zagadnienia kosztów, cen i budżetowania. Pokazaliśmy przykłady szacowania i optymalizowania kosztów i przedstawiliśmy wszystkie elementy związane z kosztami, które trzeba rozważyć, w tym przestrzeń magazynową i pasmo transferu danych, a także wydanie bazy danych i ustawienie maksymalnego rozmiaru.
61
ROZDZI AŁ 3
Różnice pomiędzy SQL Server a Microsoft Azure SQL Database Leonard Lobel
J
ednym z najbardziej atrakcyjnych aspektów Microsoft Azure SQL Database jest fakt, że rozwiązanie to wykorzystuje praktycznie ten sam kod bazowy i udostępnia taki sam strumień danych tabelarycznych (tabular data stream – TDS), jak zwykły, zlokalizowany w siedzibie firmy Microsoft SQL Server. Tym samym narzędzia i aplikacje, które działają z SQL Server, w znacznym stopniu zachowują się tak samo z SQL Database. Warto jednak podkreślić użyty zwrot w znacznym stopniu, gdyż pomimo podobieństw istnieje kilka funkcji SQL Server, których SQL Database nie obsługuje. W tym krótkim rozdziale omówimy, jak i dlaczego te dwie platformy różnią się od siebie i wyjaśnimy ograniczenia SQL Database, o których trzeba wiedzieć, jeśli mamy już wcześniejsze doświadczenia w pracy z SQL Server. SQL Server i SQL Database różnią się pod wieloma względami – najbardziej istotne to ograniczenia rozmiaru, wsparcie dla szczególnych funkcjonalności i kompatybilność kodu T-SQL. W wielu przypadkach ograniczenia te są po prostu ceną, którą trzeba zapłacić za wygodę korzystania z „samozarządzalnej” i „samonaprawiającej się” bazy danych w chmurze. Innymi słowy, Microsoft nie jest w stanie odpowiedzialnie wspierać funkcji, które wpływałyby na zdolność do szybkiej replikacji, relokacji i skalowania instancji SQL Database. Z tego właśnie powodu SQL Database narzuca ograniczenia na rozmiary bazy danych i nie wspiera szczególnych specjalizowanych funkcjonalności, takich jak FILESTREAM. Innym typowym powodem, dla którego określona funkcja lub składnia T-SQL nie jest obsługiwana w SQL Database, jest to, że po prostu nie ma zastosowania. W przypadku SQL Database odpowiedzialność administracyjna jest podzielona pomiędzy firmę Microsoft i nas (administratorów naszego biznesu). Microsoft zajmuje się całą stroną fizyczną (takimi elementami, jak dyski i fizyczne serwery), a po naszej stronie leży tylko zarządzanie logiczną strukturą (na przykład projektowanie bazy danych i zabezpieczenia). Z tego powodu dowolne konstrukcje T-SQL, które odnoszą się do zasobów fizycznych (jak nazwy ścieżek), nie są obsługiwane w SQL Database. Na przykład nie 63
64
Rozdział 3: Różnice pomiędzy SQL Server a Microsoft Azure SQL Database
mamy kontroli nad lokalizacją grup plików samych baz i dzienników. Z tego powodu nie można dołączyć klauzuli ON PRIMARY w wyrażeniu CREATE DATABASE, a w istocie SQL Database nie pozwoli na użycie odsyłacza do grupy plików w żadnym wyrażeniu T-SQL. Mówiąc krótko, cokolwiek odnosi się do zasobów fizycznych (czyli infrastruktury), jest poza naszym zainteresowaniem, gdy chodzi o SQL Database. Tym niemniej istnieją także inne sytuacje, gdy pewne funkcjonalności lub zachowania SQL Server nie są wspierane, zasadniczo dlatego, że firma Microsoft nie zdołała dotąd ich wystarczająco przetestować i dołączyć do SQL Database. Platforma Azure ciągle ewoluuje, zatem trzeba uważnie śledzić aktualizacje i informacje o nowościach. Ten rozdział jest dobrym punktem wyjścia, ale najlepszą metodą, aby być na bieżąco, jest przeglądanie sekcji „Guidelines and Limitations” w dokumentacji SQL Database w witrynie MSDN (http://msdn.microsoft.com/en-us/library/ff394102.aspx).
Ograniczenia rozmiaru Z wyjątkiem darmowego, uproszczonego wydania Express oprogramowania SQL Server, nie istnieją praktyczne limity wielkości bazy danych w dowolnym wydaniu SQL Server, jeśli nie liczyć fizycznej wielkości dostępnych dysków. Baza danych SQL Server może urosnąć aż do wielkości 524 272 terabajtów (w przypadku SQL Server Express limit wynosi 10 gigabajtów). W przeliczeniu na „czysty tekst”, jest to mniej więcej milion razy więcej, niż zawartość wszystkich książek, które znajdują się w Bibliotece Kongresu! Dla kontrastu, SQL Database ma bardzo ściśle określone ograniczenia rozmiarów. Jak pokazaliśmy w rozdziale 2, „Konfiguracja i ceny”, konieczne jest określenie maksymalnego rozmiaru poprzez wybór pomiędzy wydaniem Web a Business. W przypadku wydania Web, maksymalny rozmiar bazy danych może zostać ustalony na 1 lub 5 gigabajtów (GB). W przypadku wydania Business rozmiar maksymalny może mieć wielkość od 10 do 150 GB. Największy obsługiwany rozmiar bazy danych to 150 GB, choć wykorzystując strategie partycjonowania można pokusić się o obsługę scenariuszy wymagających większych baz (co wyjaśnimy w rozdziale 8, „Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności”). Uwaga W chwili kierowania tej książki do druku firma Microsoft udostępniła wersję zapoznawczą (preview) wydania SQL Database Premium. Jest bardziej kosztowny wariant, niż standardowe wydania Web i Business, obsługujący rozmiar bazy do 500 GB. Jak pokażemy w rozdziale 8, wydanie Premium pozwala również na skalowalność wydajności poprzez użycie dedykowanych procesorów i pamięci. Jednocześnie zapowiedziano wprowadzenie dwóch nowych wydań (Basic i Standard). Począwszy od połowy roku 2015, wydania Web i Business będą wycofywane i docelowo zostaną zastąpione trzema wydaniami Basic, Standard i Premium na sześciu poziomach wydajnościowych.
Ograniczenia połączeń
Ograniczenia połączeń SQL Database jest znacznie mniej elastyczna, niż SQL Server, jeśli chodzi o ustanawianie i obsługiwanie połączeń. Przy łączeniu się z SQL Database trzeba mieć na uwadze następujące ograniczenia: ■
■
■
■
■
■
SQL Server wspiera wiele protokołów klienckich, takich jak TCP/IP, współdzielona pamięć (Shared Memory) i nazwane potoki (Named Pipes). Tymczasem SQL Database pozwala na połączenia wyłącznie poprzez TCP/IP. SQL Database nie wspiera uwierzytelniania Windows. Każdy łańcuch połączenia przesyłany do SQL Database musi zawsze zawierać nazwę logowania użytkownika (login) oraz hasło. SQL Database często wymaga dołączenia sufiksu @ do loginu w łańcuchu połączenia. SQL Server nie narzuca takiego wymagania. SQL Database może komunikować się tylko przez port 1433 i nie wspiera ani statycznej, ani dynamicznej alokacji portów, co umożliwia SQL Server. SQL Database w pełni obsługuje standard Multiple Active Result Sets (MARS), który zezwala na kolejkowanie wielu żądań w pojedynczym połączeniu. Ze względu na nieprzewidywalną naturę sieci Internet, połączenia SQL Database mogą zostać nieoczekiwanie przerwane i trzeba uwzględniać tą możliwość w projekcie aplikacji. Na szczęście istnieje kilka opcji, które pozwalają sobie poradzić z tym problemem: ❐ Najnowsza wersja Entity Framework (EF6, będącej zalecanym przez Microsoft API dostępu do danych dla .NET) zawiera funkcjonalność Connection Resiliency (elastyczność połączeń), która automatycznie obsługuje wznawianie zerwanych połączeń. ❐ Funkcjonalność Microsoft Enterprise Library Transient Fault Handling Application Block, omówiona w rozdziale 4, pozwala zdefiniować i zaimplementować strategie wznawiania połączeń. ❐ Klasa ADO.NET SqlConnection zawiera rozszerzoną metodę OpenWithRetry, która obsługuje logikę wznawiania połączeń opartą na domyślnych zasadach wznawiania (które muszą być zdefiniowane przy użyciu Microsoft Enterprise Library Transient Fault Handling Application Block).
Nieobsługiwane funkcjonalności W tym podrozdziale zawarliśmy wiele możliwości SQL Server, które nie są obsługiwane w SQL Database, a także sugerowane sposoby ich obejścia, gdy jest to możliwe. Przypomnijmy jednak, że informacje te mogą stracić aktualność w miarę rozwoju
65
66
Rozdział 3: Różnice pomiędzy SQL Server a Microsoft Azure SQL Database
platformy Azure. Z tego względu zdecydowanie polecamy sprawdzenie najnowszych informacji w witrynie MSDN (http://msdn.microsoft.com/en-us/library/ff394102.aspx). ■
■
■
■
■
■
■
■
Agent
Nie można wykorzystać usługi SQL Server Agent do zaplanowania i wykonywania zadań w SQL Database. Inspekcja Funkcje inspekcji SQL Server rejestrują zdarzenia dotyczące serwera i bazy danych w dzienniku systemu Windows lub w systemie plików i nie są wspierane w bazach danych SQL Database. Kopie zapasowe i przywracanie Konwencjonalne kopie zapasowe wykorzystujące polecenia BACKUP i RESTORE nie są obsługiwane w SQL Database. W zamian jednak SQL Database wspiera automatyczny harmonogram kopii zapasowych, który tworzy transakcyjnie spójne kopie w formie plików BACPAC umieszczanych w magazynie Azure. Można również tworzyć pliki BACPAC ręcznie, jednak to nie zapewnia spójności transakcyjnej dla zmian, które nastąpią w trakcie operacji eksportu. Aby zapewnić spójność transakcyjną dla ręcznie wykonywanej kopii zapasowej, trzeba przestawić bazę danych w tryb tylko do odczytu przed wykonaniem eksportu, użyć funkcjonalności Database Copy (kopia bazy danych) do utworzenia kopii bazy spójnej transakcyjnie, po czym wyeksportować tę kopię do pliku BACPAC. Więcej informacji na ten temat zawiera rozdział 5, „Bezpieczeństwo i kopie zapasowe”. Usługa Browser SQL Database nasłuchuje tylko na porcie 1433. Tym samym usługa SQL Server Browser, która umożliwia nasłuchiwanie na różnych (innych) portach, nie jest obsługiwana. Change Data Capture (CDC) Ta funkcjonalność SQL Server monitoruje zmiany występujące w bazie danych i przechwytuje całą powiązaną z tym aktywność w tabelach zmian. CDC jednak opiera się na zadaniach SQL Server Agent, zatem nie jest obsługiwana w SQL Database. Common Language Runtime (CLR) Funkcjonalność SQL Server CLR (często skracana po prostu do SQL CLR) pozwala na pisanie procedur składowanych, wyzwalaczy, funkcji i typów zdefiniowanych przez użytkownika w dowolnym języku .NET (takim jak Microsoft C# lub Visual Basic) jako alternatywę dla stosowania tradycyjnego kodu T-SQL. W SQL Database można używać tylko T-SQL; stosowanie SQL CLR nie jest wspierane. Trzeba jednak zauważyć, że ograniczenie to nie dotyczy typów danych SQL Server implementowanych wewnętrznie przy użyciu CLR, takich jak xml, geography czy geometry – wszystkie one są obsługiwane przez SQL Database. Kompresja SQL Database nie wspiera funkcji kompresji danych znanych z SQL Server, których można użyć do zmniejszenia wielkości tabel i indeksów. Konwencja nazewnicza obiektów bazodanowych W SQL Server można używać wieloczęściowych nazw do odwoływania się do obiektów w innym schemacie
Nieobsługiwane funkcjonalności
■
■
■
■
■
(przy użyciu składni schema.object), w innej bazie danych (trzyczęściowa składnia database.schema.object), a nawet (o ile skonfigurujemy połączony serwer) na innym serwerze (przy użyciu czteroczęściowej składni server.database.schema. object). W SQL Database można używać nazw dwuczęściowych, aby odwołać się do obiektów w innych schematach. Nazwy trzyczęściowe mogą być stosowane tylko w odniesieniu do obiektów tymczasowych w tempdb (czyli tych, dla których nazwa bazy danych to tempdb i nazwa obiektu zaczyna się od symbolu #); nie istnieje możliwość dostępu do innych baz danych na serwerze. Nie ma też możliwości odwoływania się do innych serwerów, zatem nazwy czteroczęściowe nigdy nie będą w użyciu. Przedłużone rejestrowanie zdarzeń W SQL Server można tworzyć sesje rozszerzonego śledzenia zdarzeń, które pomagają w rozwiązywaniu rozmaitych problemów, takich jak nadmierne zużycie mocy obliczeniowej, presja na pamięć lub zakleszczenia. Funkcja ta nie jest obsługiwana w SQL Database. Rozszerzone procedury składowane Nie można wywoływać własnych, rozszerzonych procedur składowanych (które typowo są niestandardowymi procedurami napisanymi w języku C lub C++) w SQL Database. Obsługiwane są tylko konwencjonalne procedury składowane w języku T-SQL. Strumieniowe typy danych Własne funkcje strumieniowe SQL Server, w tym FILESTREAM oraz FileTable, nie są obsługiwane przez SQL Database. Zamiast tego można wykorzystać kontenery Azure Blob Storage dla niestrukturalnych plików danych, ale konieczne będzie utworzenie i obsługa odsyłaczy pomiędzy SQL Database i magazynem binarnym na poziomie aplikacji. Trzeba też zauważyć, że takie podejście nie umożliwia zapewnienia integralności transakcyjnej pomiędzy tymi komponentami. Wyszukiwanie pełnotekstowe Usługa Full-Text Searching (FTS) dostępna w SQL Server, umożliwiająca wyszukiwanie przybliżonych dopasowań i odpytywanie niestrukturalnych dokumentów, nie jest obsługiwana w SQL Database. Istnieje jednak biblioteka przeszukiwania tekstu dostępna od firmy Lucene, której można użyć w SQL Database. Więcej informacji można znaleźć w witrynie http:// www.lucene.net. Dublowanie baz danych SQL Database nie obsługuje dublowania baz danych, co – generalnie mówiąc – nie jest problemem, gdyż firma Microsoft gwarantuje nadmiarowość baz danych SQL Database, zatem nie musimy zajmować się takimi zabezpieczeniami na wypadek awarii. Oznacza to też, że nie można użyć SQL Database jako lokalizacji dublowania dla głównej bazy danych SQL Server działającej w siedzibie firmy. Tym niemniej, jeśli chcielibyśmy wykorzystać chmurę do tego celu, można rozważyć hostowanie SQL Server wewnątrz maszyny wirtualnej Azure i na niej umieścić kopię głównej bazy. Takie rozwiązanie wymaga również implementacji połączenia wirtualnej sieci prywatnej (VPN) pomiędzy siecią
67
68
Rozdział 3: Różnice pomiędzy SQL Server a Microsoft Azure SQL Database
■
■
■
■
■
■
■
■
lokalną a maszyną wirtualną w Azure, choć mogłoby to działać nawet bez VPN, o ile użyjemy certyfikatów serwerów. Partycjonowanie W SQL Server można partycjonować tabele i indeksy horyzontalnie (według grup wierszy) pomiędzy wiele grup plików wewnątrz bazy danych, co znacząco poprawia wydajność bardzo wielkich baz. SQL Database ma jednak limit 150 GB (lub 500 GB w przypadku nowego wydania Premium) i nie zapewnia żadnej kontroli nad grupami plików, a tym samym nie obsługuje partycjonowania tabel i indeksów. Replikacja SQL Server udostępnia rozbudowane funkcje replikacji dla celów dystrybucji i synchronizowania danych, takich jak replikacja scalająca, migawkowa i transakcyjna. Żadna z tych funkcji nie jest wspierana przez SQL Database; tym niemniej można wykorzystać mechanizm SQL Data Sync do implementacji replikacji scalającej pomiędzy różnymi bazami SQL Database (w dowolnej liczbie) w Microsoft Azure lub bazą zlokalizowaną na SQL Server w siedzibie firmy. Więcej informacji na ten temat zawiera rozdział 7, „Microsoft Azure SQL Data Sync”. Zarządca zasobów Funkcjonalność Resource Governor (Zarządca zasobów) w SQL Server pozwala zarządzać obciążeniem i zasobami poprzez określenie limitów użycia procesora i pamięci wykorzystywanych przez żądania klienckie. Jak łatwo zauważyć, koncepcja ta odnosi się bezpośrednio do sprzętu i nie ma zastosowania w SQL Database. Service Broker Komponent SQL Server Service Broker udostępnia funkcje komunikatów i kolejkowania, które nie są wspierane w SQL Database. Systemowe procedury składowane SQL Database udostępnia tylko nieliczne z systemowych procedur składowanych, które można znaleźć w SQL Server. Te nieobsługiwane zazwyczaj dotyczą funkcji i zachowań SQL Server, które nie są wspierane w SQL Database. Jednocześnie SQL Database udostępnia kilka nowych systemowych procedur składowanych niewystępujących w SQL Server, które są specyficzne dla SQL Database (na przykład sp_set_firewall_rule). Tabele bez indeksu klastrowanego Każda tabela w SQL Database musi definiować indeks klastrowany. Domyślnie SQL Database utworzy indeks klastrowany na podstawie kolumny klucza głównego tabeli, ale nie zrobi tego, jeśli nie zdefiniujemy klucza. Co interesujące, mechanizm SQL Database w rzeczywistości pozwoli utworzyć tabelę, bez indeksu klastrowanego, ale nie umożliwi dodania do niej żadnego wiersza, dopóki nie zdefiniujemy indeksu klastrowanego. Ograniczenie takie nie istnieje w SQL Server. Szyfrowanie danych Nie można użyć mechanizmu Transparent Data Encryption (TDE) do szyfrowania zawartości SQL Database, co można zrobić w SQL Server. USE W SQL Database wyrażenie USE może odwoływać się tylko do bieżącej bazy danych; nie można użyć go do przełączania się pomiędzy bazami danych, jak w SQL Server. Każde połączenie SQL Database jest przypisane do pojedynczej
Podsumowanie
■
bazy danych, zatem w celu zmiany bazy musimy połączyć się z nową bazą bezpośrednio. Indeksowanie XSD i XML SQL Database w pełni obsługuje typ danych xml, podobnie jak większość rozbudowanych funkcji XML udostępnianych przez SQL Server, w tym XML Query (XQuery), XML Path (XPath) oraz klauzulę FOR XML. Jednak definicje schematu XML (XSD) oraz indeksy XML nie są obsługiwane w SQL Database.
Podsumowanie W tym krótkim rozdziale pokazaliśmy ważne różnice pomiędzy zwykłą instalacją SQL Server w siedzibie a bazami danych SQL Database w chmurze Microsoft Azure. Wyjaśniliśmy ograniczenia dotyczące rozmiaru, połączeń i istotne uwarunkowania, które trzeba mieć na uwadze, takie jak zrywanie połączeń, co może stosunkowo często pojawiać się w przypadku SQL Database. Rozdział zakończyliśmy wyliczeniem tych funkcjonalności SQL Server, które albo nie są w ogóle obsługiwane, albo mają tylko ograniczone wsparcie SQL Database, wraz z możliwościami obejścia problemu, o ile są możliwe. Informacje zawarte w tym rozdziale powinny być pomocne przy podejmowaniu decyzji, czy wybór SQL Database jest odpowiedni, czy też nie w konkretnym scenariuszu. Oczywiście, jeśli okaże się, że tak nie jest, zawsze pozostaje jeszcze możliwość uruchamiania standardowego oprogramowania SQL Server na maszynie wirtualnej Azure (jak to zrobić, pokażemy w rozdziale 6). Takie podejście typu IaaS (infrastruktura jako usługa) zapewnia pełną funkcjonalność SQL Server w chmurze, w odróżnieniu od podejścia PaaS (platforma jako usługa), którym jest SQL Database.
69
ROZDZI AŁ 4
Migrowanie baz danych Eric Boyd
Z
naszych doświadczeń zdobytych podczas pomagania klientom w projektowaniu i przenoszeniu aplikacji na platformę Microsoft Azure wynika, że zawsze pojawia się potrzeba migrowania danych wraz z tymi aplikacjami, nawet w przypadku „zupełnie nowych” projektów. Tak więc niezbędna jest znajomość technik i rozwiązań umożliwiających migrację danych do SQL Database i zrozumienie zarówno ich zalet, jak i słabości. W tym rozdziale zajmiemy się wieloma narzędziami i technikami umożliwiającymi migrację danych do baz SQL Database, takimi jak skrypty TransactSQL (T-SQL), aplikacje poziomu danych SQL (BACPAC), kopiowanie masowe (bcp) oraz SQL Database Migration Wizard. Uwaga Jak wspomnieliśmy w rozdziale 1, „Poznajemy Microsoft Azure SQL Database” (i co stosujemy w całej książce), termin SQL Database odnosi się do bazy danych w chmurze Microsoft Azure SQL Database, podczas gdy terminu SQL Server używamy, gdy chodzi o lokalnie zainstalowany (w siedzibie firmy) SQL Server.
Oprócz narzędzi i technik omówionych w tym rozdziale istnieje jeszcze wiele innych rozwiązań, oferowanych zarówno przez firmę Microsoft, jak i innych dostawców, które mogą lepiej pasować do konkretnego scenariusza i wymagań. Na przykład SQL Server Integration Services (SSIS) jest świetnym rozwiązaniem, jeśli zachodzi potrzeba importowania danych ze źródeł innych niż bazy danych SQL Server, takich jak arkusze programu Excel, albo z innych platform bazodanowych, jak Oracle. Jeśli zaś mamy już istniejącą bazę danych w SQL Database i chcemy stosować w niej stopniowe zmiany i aktualizacje, narzędzia innych dostawców, takie jak SQL Compare oraz Data Compare firmy Red-Gate, mogą okazać się nieodzowne. Warto przeanalizować te (i inne również) dostępne rozwiązania, które mogą pomóc w migracji danych z dotychczasowych magazynów danych i serwerów do SQL Database. Trzeba dobrze zrozumieć oferowane możliwości i ograniczenia każdej z tych opcji, aby móc dokonać wyboru najlepiej pasującego do rzeczywistych potrzeb.
71
72
Rozdział 4: Migrowanie baz danych
Przygotowania wstępne do migracji danych Procentowy udział budżetu IT, który trzeba przeznaczyć na bieżące utrzymanie w stosunku do kosztów nowego projektu, jest popularną miarą, którą menedżerowie techniczni i biznesowi lubią monitorować i sprawdzać. W zasadzie zawsze celem jest minimalizacja kosztów utrzymania, aby móc zainwestować więcej w innowacyjne, nowe projekty. Zespoły programistyczne i techniczne zwykle wolą pracować nad nowymi projektami (często nazywanymi projektami typu greenfield – dziewiczy teren), niż zajmować się utrzymaniem i ulepszaniem istniejących rozwiązań (co bywa nazywane „rekultywacją” – brownfield). Tym niemniej, jeśli ktoś pracuje w branży IT od jakiegoś czasu, doskonale wie, jak wiele czasu trzeba zainwestować w konserwację i zarządzanie istniejących kodów i rozwiązań. Istniejący kod i dane, którymi musimy zarządzać (często określane mianem dziedzictwa, nawet jeśli powstały ledwo rok wcześniej), skłania do konieczności rozważenia strategii migracji, gdy zastanawiamy się nad wykorzystaniem chmury publicznej, takiej jak Microsoft Azure. W tym rozdziale pokażemy różne sposoby przenoszenia danych do SQL Database z istniejących systemów i własnych serwerów SQL Server, a także omówimy kilka innych spraw, które trzeba rozważyć podczas migrowania danych do SQL Database.
Migrowanie danych za pomocą skryptów Transact-SQL SQL Database wykorzystuje niemal tę samą składnię języka Transact-SQL (T-SQL), jak „zwykły” SQL Server, co jest zdecydowaną zaletą, jeśli już mamy doświadczenia w pracy z SQL Server. Stąd pierwszą, najprostszą opcją wypełnienia bazy danych SQL Database jest użycie skryptów T-SQL. W tym podrozdziale wykorzystamy narzędzie SQL Server Management Studio (SSMS) do napisania skryptów T-SQL tworzących i wypełniających lokalną bazę danych SQL Server. Warto zauważyć, że do tego celu można również wykorzystać narzędzie SQL Server Data Tools (SSDT) wewnątrz Microsoft Visual Studio (więcej informacji na temat SSDT zawiera rozdział 10, „Budowanie rozwiązania w chmurze”). Wszystkie skrypty pokazane w tym rozdziale można pobrać ze strony internetowej powiązanej z książką, zgodnie z instrukcjami zawartymi we Wprowadzeniu.
Konfigurowanie lokalnej bazy danych SQL Server Aby móc zacząć, musimy skonfigurować bazę danych WineDb opisaną w poprzednich rozdziałach w lokalnym środowisku. Jak łatwo zauważyć, wymaga to lokalnej instancji SQL Server.
Migrowanie danych za pomocą skryptów Transact-SQL
Jeśli Czytelnik ma dostęp do instancji SQL Server, w której będzie mógł utworzyć nową bazę danych, może wykorzystać tę instancję. W innym razie konieczne będzie zainstalowanie bezpłatnego wydania SQL Server Express, aby hostować bazę danych na swoim lokalnym komputerze. Procedura instalacyjna została opisana we Wprowadzeniu, w podrozdziale „Instalowanie oprogramowania SQL Server Express”. Uwaga W tym rozdziale przyjmujemy założenie, że jako lokalnej bazy danych używamy wydania SQL Server Express, której nazwa instancji brzmi .\sqlexpress. Jeśli Czytelnik używa innego wydania lub inaczej nazwanej instancji, musi zastąpić nazwę .\sqlexpress we wszystkich instrukcjach nazwą używanej instancji. Na przykład przy korzystaniu z domyślnej (głównej) instancji SQL Server na komputerze lokalnym, można wyspecyfikować po prostu symbol kropki (). albo nazwę localhost. W przypadku używania instancji nazwanej na komputerze lokalnym należy uzupełnić te odwołania o odwrotny ukośnik i nazwę instancji, na przykład .\myinstance lub localhost\myinstance.
Kod T-SQL tworzący lokalną bazę WineDb pokazany jest w Listingu 4-1. Skrypt ten tworzy bazę danych WineDb, a następnie tworzy w niej tabele Customer, Order i Wine. Ponadto ustanawia wszystkie potrzebne relacje klucza obcego pomiędzy tabelami. lisTing 4-1 Tworzenie lokalnej bazy danych WineDb CREATE DATABASE WineDb GO USE WineDb GO CREATE TABLE Wine( WineId int IDENTITY PRIMARY KEY, Name nvarchar(50) NOT NULL, Category nvarchar(15) NOT NULL, Year int, Price MONEY DEFAULT 0 NOT NULL, AddedOn datetime2 DEFAULT SYSDATETIME() NOT NULL, UpdatedOn datetime2) CREATE TABLE Customer( CustomerId int IDENTITY PRIMARY KEY, FirstName nvarchar(50) NOT NULL, LastName nvarchar(50) NOT NULL, FavoriteWineId int, CONSTRAINT FK_Customer_Wine FOREIGN KEY (FavoriteWineId) REFERENCES Wine(WineId)) CREATE TABLE [Order]( OrderId int IDENTITY PRIMARY KEY, OrderedOn datetime2 DEFAULT SYSDATETIME() NOT NULL, CustomerId int NOT NULL, WineId int NOT NULL, Quantity int NOT NULL, Price MONEY NOT NULL, CONSTRAINT FK_Order_Customer FOREIGN KEY (CustomerId) REFERENCES
Aby utworzyć bazę danych WineDb przy użyciu tego skryptu T-SQL, wykonaj następujące działania: 1 . Uruchom narzędzie SSMS. W tym celu naciśnij klawisz Windows, wpisz sql server
management studio na ekranie Start i naciśnij Enter. 2 . W oknie dialogowym Connect To Server wybierz połączenie z lokalną instancją
SQL Server, używając odpowiednich poświadczeń, podobnie jak na rysunku 4-1.
Rysunek 4-1 Łączenie się z SQL Server w oknie dialogowym Connect To Server
3 . Po połączeniu zawartość instancji SQL Server zostanie pokazana w panelu Object Explorer. Prawym klawiszem myszy kliknij instancję SQL Server i wybierz polecenie New Query (nowe zapytanie), jak na rysunku 4-2. Zostanie otwarte nowe okno
zapytania.
Rysunek 4-2 Polecenie New Query w menu kontekstowym panelu Object Explorer
4 . Wpisz kod pokazany na rysunku 4-1 do okna zapytania (lub skopiuj go tam
z pliku pobranego z witryny powiązanej z książką). 5 . Naciśnij F5 lub kliknij przycisk Execute w pasku narzędzi, aby uruchomić skrypt.
Migrowanie danych za pomocą skryptów Transact-SQL
6 . Rozwiń węzeł Databases poniżej nazwy instancji SQL Server w panelu Object Explorer (lub, jeśli jest on już rozwinięty, kliknij go prawym klawiszem myszy i wybierz polecenie Refresh). Na liście powinna znajdować się baza danych WineDb.
7 . Rozwiń węzeł bazy danych WineDb, a następnie węzeł Tables, aby sprawdzić,
że zawiera on tabele Customer, Order oraz Wine. Mamy już bazę danych WineDb uruchomioną w lokalnej instancji SQL Server. Jest to źródłowa baza danych, której migrację do Microsoft Azure będziemy wykonywać przy użyciu różnych technik i narzędzi w dalszej części tego rozdziału.
Wypełnianie bazy danych przy użyciu T-SQL Możemy teraz przystąpić do wypełnienia tabel w lokalnej bazie WineDb jakimiś danymi przykładowymi. W tym podrozdziale utworzymy proste skrypty T-SQL, które umieszczą w tabelach Customer i Wine kilka rekordów. Jedną z wielkich zalet SQL Database jest to, że możemy użyć tej samej składni T-SQL, którą wykorzystujemy przy pracy z SQL Server. Tak więc tych samych skryptów można użyć do wstawienia danych zarówno do bazy SQL Server, jak i do SQL Database. Listing 4-2 pokazuje skrypt T-SQL, który wywołamy w kolejnej procedurze. Skrypt ten tworzy w tabeli Wine piętnaście rekordów (wierszy) danych, zaś w tabeli Customer trzy wiersze. Warto zwrócić uwagę na ustawienie IDENTITY_INSERT, które jest włączane przed wstawieniem wierszy do tabeli, po czym ponownie wyłączane. Dzięki temu skrypt może dostarczyć jawnie wartości dla klucza głównego każdego nowego rekordu, które normalnie zostałyby przypisane automatycznie przez SQL Server, gdyż klucze główne zostały oznaczone atrybutem IDENTITY (patrz Listing 4-1 wcześniej w tym rozdziale). lisTing 4-2 Wypełnianie lokalnej bazy danych WineDb SET IDENTITY_INSERT Wine ON INSERT Wine (WineId, Name, Category, 2008) INSERT Wine (WineId, Name, Category, 2005) INSERT Wine (WineId, Name, Category, INSERT Wine (WineId, Name, Category, 2009) INSERT Wine (WineId, Name, Category, INSERT Wine (WineId, Name, Category, INSERT Wine (WineId, Name, Category, Noir', 2009) INSERT Wine (WineId, Name, Category, INSERT Wine (WineId, Name, Category, 2010) INSERT Wine (WineId, Name, Category, INSERT Wine (WineId, Name, Category,
Aby wypełnić tabele bazy danych przy użyciu tego skryptu, wykonaj następujące działania: 1 . Otwórz nowe okno zapytania w SSMS (albo usuń cały kod w dotychczas otwartym
oknie, o ile nie zostało zamknięte po poprzedniej procedurze). 2 . Wpisz kod pokazany w Listingu 4-2 w oknie zapytania (lub skopiuj go tam z pliku
pobranego z witryny powiązanej z książką). 3 . Naciśnij F5 lub kliknij przycisk Execute w pasku narzędzi, aby wykonać skrypt.
Generowanie skryptów T-SQL Do tej pory skonfigurowaliśmy bazę danych WineDb w lokalnej instancji SQL Server i wypełniliśmy ją pewnymi danymi przykładowymi. Oczywiście moglibyśmy wykonać te same skrypty w instancji SQL Database, aby utworzyć bazę, tabele i wypełnić je wartościami. Jednak tworzenie tego typu skryptów T-SQL dla znacznych ilości danych jest żmudne i czasochłonne. Można by pomyśleć, że musi istnieć jakaś lepsza metoda, i oczywiście tak jest. SSMS może przeanalizować zawartość bazy danych i wygenerować skrypt T-SQL zawierający wyrażenia INSERT dla wszystkich danych zawartych w tabelach. W tej procedurze wykorzystamy SSMS do automatycznego utworzenia skryptu T-SQL na podstawie lokalnej bazy danych WineDb w SQL Server, którego będzie można następnie użyć do odtworzenia jej zawartości w bazie WineCloudDb, w praktyce realizując migrację danych z SQL Server do SQL Database. 1 . Jeśli narzędzie SSMS zostało zamknięte po poprzedniej procedurze, uruchom
je ponownie i połącz się z lokalną instancją SQL Server, zawierającą bazę danych WineDb. 2 . W panelu Object Explorer rozwiń węzeł z nazwą instancji SQL Server. 3 . Rozwiń węzeł Databases, aby wyświetlić listę baz danych.
Migrowanie danych za pomocą skryptów Transact-SQL
4 . Jeśli baza danych WineDb nie jest widoczna, kliknij węzeł Databases prawym kla-
wiszem myszy i wybierz polecenie Refresh (odśwież). 5 . Kliknij prawym klawiszem myszy nazwę WineDb, po czym wybierz Tasks | Generate Scripts (zadania | generuj skrypty). Zostanie uruchomiony kreator Generate And Publish Scripts (generowanie i publikowanie skryptów).
6 . Na stronie powitalnej kliknij Next (dalej), aby wyświetlić stronę Choose Objects
(wybieranie obiektów). 7 . Strona Choose Objects pozwala na wybór pomiędzy skryptowaniem całej bazy
danych a wyborem określonych obiektów. Warto zauważyć, że wybór ten nie jest ograniczony do samych tabel; można tu również dołączyć inne obiekty bazodanowe, takie jak widoki, procedury składowane, wyzwalacze i tak dalej. Pozostaw domyślny wybór skryptowania całej bazy danych i kliknij Next, aby wyświetlić stronę Set Scripting Options (ustawianie opcji skryptu). 8 . Kliknij przycisk Advanced (zaawansowane), aby wyświetlić okno dialogowe Advanced Scripting Options.
9 . Przewiń zawartość okna aż do właściwości Script For The Database Engine Type
(skrypt dla typu mechanizmu bazy danych) – znajduje się ona pod koniec kategorii General. Domyślnie opcja ta jest ustawiona na Stand-alone instance (samodzielna instancja). Można tu również wybrać SQL Azure Database, aby wygenerować skrypty kompatybilne z SQL Database, co właśnie chcemy zrobić w tym przypadku, zatem należy zmienić to ustawienie. 10 . Przewiń dalej do właściwości Types Of Data To Script (typy danych do skrypto-
wania) – jest to ostatnia właściwość w kategorii General. Domyślnie opcja ta jest ustawiona na skryptowanie tylko schematu bazy danych. Wśród dostępnych opcji jest również oskryptowanie samych tylko danych oraz schematu i danych jednocześnie. W naszym scenariuszu chcemy jedynie przenieść dane, zatem należy wybrać opcję Data Only (tylko dane), jak na rysunku 4-3. 11 . Kliknij OK, aby powrócić do strony Set Scripting Options. 12 . Wybierz opcję Save To New Query Window (zapisz w nowym oknie zapytania). 13 . Kliknij Next, aby przejść do strony Summary (podsumowanie). 14 . Kliknij Next, aby przejść do strony Save or Publish Scripts.
77
78
Rozdział 4: Migrowanie baz danych
Rysunek 4-3 Okno dialogowe Advanced Scripting Options w kreatorze Generate and Publish Scripts
15 . Kliknij Finish, aby wygenerować skrypt, który zostanie wyświetlony w nowym
oknie zapytania, jak na rysunku 4-4.
Rysunek 4-4 Wyświetlanie wygenerowanego kodu T-SQL w SSMS
Czytelnik mógłby zauważyć, że moglibyśmy po prostu wykonać w naszej bazie danych w chmurze te same skrypty, których użyliśmy do utworzenia i wypełnienia lokalnej bazy WineDb. Celem tego podrozdziału było jednak zaprezentowanie techniki
Aplikacje warstwy danych SQL
generowania skryptów definiujących bazę (lub tylko jej dane), gdyż w rzeczywistych scenariuszach lokalna baza będzie już istniała od dawna. Wygenerowany skrypt można wykonać w instancji SQL Database łącząc się z nią z narzędzia SSMS. Alternatywnie skrypty T-SQL można wykonywać w SQL Database poprzez portal zarządzania omówiony w rozdziale 1.
Aplikacje warstwy danych SQL Aplikacje warstwy danych (Data-Tier Applications – DAC) zapewniają prostą, ale skuteczną metodę projektowania, wdrażania i zarządzania bazami danych i obiektami instancji. DAC pozwala projektantom spakować obiekty SQL Server lub SQL Database w pojedynczy pakiet (plik .dacpac), umożliwiając wygodne wdrażanie ich w środowiskach projektowych, testowych i produkcyjnych. Przy migrowaniu bazy danych z SQL Server w siedzibie do SQL Database często będziemy chcieli przenieść również faktyczne dane wraz z obiektami bazy i w takim przypadku użyteczne są pakiety BACPAC (pliki .bacpac). Pakiet BACPAC jest analogiczny do DACPAC, ale oprócz obiektów bazy danych (schematu) zawiera też rzeczywiste dane znajdujące się w tabelach. Aby przemigrować dane do instancji SQL Database przy użyciu pakietu BACPAC, trzeba najpierw utworzyć plik .bacpac w lokalnej instalacji SQL Server i załadować go do kontenera blob3 w Microsoft Azure Storage. Następnie można zaimportować ten plik do bazy SQL Database. W tym podrozdziale pokażemy wszystkie kroki potrzebne do realizacji tego zadania.
Tworzenie konta w Microsoft Azure Storage Na początek musimy mieć miejsce w Microsoft Azure, w którym będzie można przechować nasz plik .bacpac, i tym miejscem jest kontener blob Microsoft Azure Storage. Rozpoczniemy zatem od utworzenia kontenera blob przy użyciu usługi Storage, co z kolei wymaga najpierw utworzenia konta w tej usłudze. Konta Microsoft Azure Storage uwierzytelniają dostęp poprzez użycie jednego z dwóch 512-bitowych kluczy dostępowych (głównego i pomocniczego). Klucze te są generowane automatycznie podczas tworzenia konta w usłudze. Klucze te można odtworzyć w dowolnym czasie poprzez portal zarządzania Microsoft Azure (albo przy użyciu API Microsoft Azure Service Management). Aby zapewnić bezpieczeństwo konta magazynowego, zalecane jest okresowe regenerowanie kluczy dostępowych. Zmienianie poświadczeń uwierzytelniających dla usługi, od której zależą inne usługi 3 BLOB jest akronimem od „Binary Large OBject”, czyli wielki obiekt binarny – w istocie może to być dowolny plik, niekoniecznie kopia zapasowa bazy danych. Istotne jest to, że dzięki traktowaniu pliku jako obiektu blob zabezpieczamy się przed jakąkolwiek ingerencją w jego zawartość.
79
80
Rozdział 4: Migrowanie baz danych
i aplikacji, może być trudnym wyzwaniem, jeśli nie chcemy dopuścić do ich wyłączenia na jakiś czas. Microsoft Azure upraszcza to zadanie dzięki udostępnieniu dwóch kluczy dostępowych, co pozwala na ich zmienianie bez powodowania wyłączenia. Aby utworzyć konto Microsoft Azure Storage, którego będzie można użyć do załadowania i przechowania pliku .bacpac, wykonaj następujące działania: 1 . Zaloguj się w portalu Microsoft Azure pod adresem https://manage.windowsazu-
re.com. Zostaniesz przekierowany do głównej strony portalu, prezentującej ALL ITEMS (wszystkie elementy).
2 . Kliknij STORAGE (magazyn) w pionowym panelu nawigacyjnym po lewej. 3 . Kliknij przycisk NEW w lewym dolnym rogu strony. 4 . Kliknij łącze QUICK CREATE (szybkie tworzenie). 5 . W obszarze wprowadzania danych po prawej stronie od łącza QUICK CREATE wyko-
naj następujące czynności: a . W polu URL wpisz nazwę konta magazynowego (dowolny ciąg małych liter
i cyfr o długości od 3 do 24 znaków). Nazwa ta musi być globalnie unikatowa, zatem konieczne będzie wybranie czegoś innego, niż mywinestorage pokazane na zrzucie ekranowym, gdyż ta nazwa zapewne zostanie rozpoznana przez portal jako już używana. b . W polu LOCATION/AFFINITY GROUP (lokalizacja/grupa koligacji) wybierz z listy rozwijanej centrum danych Microsoft Azure, w którym chcesz utworzyć konto magazynowe. Powinno być to to samo centrum danych, które hostuje serwer SQL Database (w rozdziale 2, „Konfiguracja i ceny”, wyjaśniliśmy implikacje cenowe wyboru centrum danych). c . W polu REPLICATION pozostaw domyślne ustawienie Geo-Redundant, które włącza replikację geograficzną. Dzięki temu kopia naszych danych będzie przechowywana również w innym centrum danych Microsoft Azure, zapewniając możliwość odtworzenia ich w razie awarii tego centrum (więcej informacji na ten temat zawiera rozdział 2). Strona portalu powinna wyglądać podobnie do pokazanej na rysunku 4-5. 6 . Kliknij CREATE STORAGE ACCOUNT (utwórz konto magazynowe), aby rozpocząć
tworzenie nowego konta. Po kilku chwilach powinno się ono pojawić w portalu ze statusem Online, jak na rysunku 4-6. 7 . Kliknij nazwę konta magazynowego.
Aplikacje warstwy danych SQL
Rysunek 4-5 Tworzenie nowego konta usługi Microsoft Azure Storage w portalu zarządzania
Rysunek 4-6 Nowe konto magazynowe wyświetlone w portalu zarządzania
nej części strony, aby wyświetlić okno dialogowe Manage Access Keys. Pokazuje on Primary Access Key (główny klucz dostępowy) oraz Secondary Access Key (pomocniczy klucz dostępowy), co widać na rysunku 4-7. Klucze te będą używane do uwierzytelniania konta magazynowego i będziemy niedługo potrzebować klucza głównego, aby załadować do Azure plik .bacpac.
81
82
Rozdział 4: Migrowanie baz danych
Rysunek 4-7 Wyświetlanie kluczy wygenerowanych dla nowego konta magazynowego
9 . Kliknij ikonę kopiowania na prawo od pola tekstowego PRIMARY ACCESS KEY (iko-
na ta wygląda jak dwie kartki dokumentu), aby skopiować klucz do Schowka Windows. Klucz ten trzeba będzie później wkleić, zatem trzeba pamiętać, aby nie używać schowka do innych celów do tego momentu. Alternatywnie możesz otworzyć Notatnik i wkleić klucz do niego. 10 . Jeśli pojawi się monit, czy zezwolić przeglądarce na dostęp do Schowka, kliknij Allow Access (Zezwalaj na dostęp).
11 . Kliknij ikonę „ptaszka” w prawym dolnym rogu okna dialogowego, aby powrócić
do ekranu głównego Storage Account. Teraz, gdy już utworzyliśmy konto magazynowe, kolejnym krokiem będzie przygotowanie w nim kontenera blob. Dopiero wówczas będziemy mogli załadować plik .bacpac do kontenera wewnątrz konta magazynowego, a następnie zaimportować ten plik do bazy SQL Database. Aby utworzyć kontener blob, wykonaj poniższe czynności: 1 . Kliknij łącze CONTAINERS (kontenery) w górnej części strony, pokazane na rysun-
ku 4-8. 2 . Kliknij przycisk ADD (dodaj) w dolnej części strony, aby wyświetlić okno dialogo-
we New Container. 3 . W polu NAME (nazwa) wpisz dbimport.
Aplikacje warstwy danych SQL
Rysunek 4-8 Tworzenie nowego kontenera wewnątrz konta magazynowego
4 . W polu ACCESS (dostęp) pozostaw domyślne ustawienie Private, które gwaran-
tuje, że tylko właściciel konta (czyli ty) będzie mógł uzyskiwać dostęp do tego kontenera. 5 . Kliknij ikonę zatwierdzenia w prawym dolnym rogu okna dialogowego, aby utwo-
rzyć kontener. Gdy proces ten się zakończy, w dolnej części strony portalu pojawi się komunikat potwierdzający. 6 . Kliknij OK, aby zamknąć komunikat potwierdzenia.
Eksportowanie BACPAC do Microsoft Azure Storage Możemy teraz przystąpić do tworzenia pliku .bacpac z lokalnej bazy danych WineDb. W kolejnych krokach wyeksportujemy plik .bacpac i załadujemy go do kontenera blob wewnątrz konta Microsoft Azure Storage, które właśnie utworzyliśmy: 1 . Jeśli narzędzie SSMS nie jest nadal uruchomione po wcześniejszej procedurze,
uruchom je i połącz się z lokalną instancją SQL Server, która zawiera bazę danych WineDb. 2 . W panelu Object Explorer rozwiń węzeł z nazwą instancji SQL Server. 3 . Rozwiń węzeł Database, aby wyświetlić listę baz danych. 4 . Prawym klawiszem myszy kliknij bazę WineDb i wybierz polecenie Tasks | Export Data-Tier Application (zadania | eksportuj aplikację warstwy danych), jak na rysunku 4-9. Zostanie uruchomiony kreator Export Data-Tier Application.
5 . Na stronie powitalnej kreatora kliknij Next, aby przejść do strony Export Settings
(ustawieniai eksportu). 6 . Na zakładce Settings (ustawienia) strony Export Settings kliknij przycisk radiowy Save To Microsoft Azure (zapisz w Microsoft Azure).
83
84
Rozdział 4: Migrowanie baz danych
Rysunek 4-9 Element menu Export Data-Tier Application w SSMS wskazówka Jeśli nie chcesz umieszczać całej bazy danych w pliku .bacpac, możesz wybrać te obiekty bazy, które mają być eksportowane, używając zakładki Advanced strony Export Settings.
7 . Kliknij przycisk Connect (połącz), aby wywołać okno dialogowe Connect To Microsoft Azure Storage.
8 . W polu Storage Account wpisz wybraną wcześniej nazwę konta magazynowego.
Zwróć uwagę, że pole wyboru HTTPS zostało automatycznie wybrane po wpisaniu nazwy konta. To zachowanie jest oczekiwane i należy pozostawić zaznaczoną tę opcję. 9 . W polu Account Key kliknij prawym klawiszem myszy i wybierz Paste (albo naciśnij
CTRL+V), aby wstawić główny klucz dostępowy skopiowany wcześniej do schowka. (Jeśli klucz nie jest już dostępny w schowku, wróć do okna dialogowego Manage Access Keys w portalu, aby skopiować go ponownie, jak na rysunku 4-7). Okno dialogowe Connect To Windows Azure Storage powinno wyglądać podobnie do pokazanego na rysunku 4-10.
Aplikacje warstwy danych SQL
Rysunek 4-10 Okno dialogowe Connect To Microsoft Azure Storage
10 . Kliknij przycisk Connect. Kreator połączy się z kontem magazynowym i powróci
do strony Export Settings, na której lista rozwijana Container będzie teraz dostępna. 11 . Z listy Container wybierz dbimport (jest to kontener, który utworzyliśmy w poprzed-
niej procedurze). Kreator powinien teraz wyglądać tak, jak na rysunku 4-11.
Rysunek 4-11 Eksportowanie pliku .bacpac do Microsoft Azure Storage
12 . Kliknij Next, aby przejść do strony Summary.
85
86
Rozdział 4: Migrowanie baz danych
13 . Przejrzyj stronę podsumowania. Jeśli wszystko wydaje się w porządku, kliknij Finish, aby rozpocząć eksport.
Po zakończeniu eksportowania danych (co powinno nastąpić bardzo szybko, gdyż nasza przykładowa baza danych jest niewielka) kreator wyświetli stronę Results z listą wykonanych zadań. Plik .bacpac został utworzony i załadowany na konto Microsoft Azure Storage. Można już zamknąć kreatora, klikając Close.
Importowanie pliku BACPAC do Microsoft Azure SQL Database Jak dotąd, utworzyliśmy konto magazynowe z kontenerem blob, do którego załadowaliśmy plik .bacpac wyeksportowany z istniejącej bazy danych SQL Server w siedzibie firmy. Został jeszcze ostatni krok – zaimportowanie tego pliku do nowej instancji SQL Database. W celu zaimportowania pliku .bacpac wykonaj następujące działania: 1 . Zaloguj się do portalu Microsoft Azure pod adresem https://manage.windowsa-
zure.com. Zostaniesz przekierowany do głównej strony prezentującej ALL ITEMS. 2 . Kliknij SQL DATABASES w pionowym panelu nawigacyjnym po lewej. 3 . Jeśli na liście baz danych istnieje baza WineCloudDb utworzona w pierwszym roz-
dziale, usuń ją teraz: a . Kliknij w dowolnej kolumnie na prawo od kolumny Name, aby zaznaczyć b . c . d .
e .
bazę WineCloudDb (nie klikaj samej nazwy bazy danych). Kliknij przycisk DELETE (usuń) w dolnej części strony. Kliknij YES, DELETE (tak, usuń) w monicie potwierdzenia. Jeśli była to jedyna baza danych na serwerze SQL Database, pojawi się pytanie, czy chcesz usunąć również serwer. Ponieważ zamierzamy zaimportować plik .bacpac do nowej bazy na tym serwerze, kliknij NO. Kliknij OK, aby zamknąć komunikat potwierdzający, że baza danych została usunięta.
4 . Kliknij przycisk NEW w dolnej części strony. 5 . W środkowej części ekranu kliknij polecenie IMPORT wyróżnione na rysunku
4-12. Pojawi się okno dialogowe IMPORT DATABASE (importowanie bazy danych). 6 . Kliknij ikonę folderu na lewo od pola tekstowego BACPAC URL. W rezultacie pojawi
się okno BROWSE CLOUD STORAGE (przeglądanie magazynu w chmurze). 7 . Po lewej stronie okna pojawi się drzewo eksploratora, ukazujące twoje konta
Microsoft Azure Storage. Kliknij strzałkę na lewo od nazwy konta magazynowego, aby ją rozwinąć i pokazać kontener dbimport wewnątrz.
Aplikacje warstwy danych SQL
Rysunek 4-12 Tworzenie nowej bazy przy użyciu opcji Import w portalu zarządzania
8 . Kliknij kontener dbimport, by wyświetlić jego zawartość. W głównej części okna
powinien pojawić się plik WineDb.bacpac załadowany wcześniej do kontenera, jak na rysunku 4-13.
10 . Kliknij przycisk Open. Ponownie pojawi się okno dialogowe IMPORT DATABASE
z adresem URL pliku .bacpac wpisanym już w polu tekstowym BACPAC URL. 11 . Zmień nazwę bazy danych w polu NAME z WineDb (nazwy bazy na lokalnym
SQL Server, odczytaną z pliku .bacpac) na WineCloudDb, aby odróżnić wersję bazy umieszczoną w instancji SQL Database. 12 . W polu SERVER wybierz dostępny serwer z listy rozwijanej (możesz też wybrać New SQL Database Server, aby utworzyć nowy serwer w trakcie procedury importu danych). Po wybraniu serwera pojawią się dodatkowe pola SERVER LOGIN NAME oraz SERVER LOGIN PASSWORD. Pole nazwy logowania jest automatycznie wypełnione nazwą administratora wybraną przy tworzeniu serwera. ważne Jeśli utworzymy konto magazynowe i serwer SQL Database w różnych regionach, zostaniemy obciążeni dodatkowymi opłatami Microsoft Azure za pasmo sieci wykorzystane na transfer pomiędzy regionami. W takim przypadku portal zarządzania Microsoft Azure wyświetli komunikat ostrzegawczy. Więcej informacji na temat zasad naliczania opłat i cen w Microsoft Azure zawiera rozdział 2.
13 . W polu SERVER LOGIN PASSWORD wpisz hasło do konta administracyjnego.
Okno dialogowe IMPORT DATABASE powinno wyglądać podobnie do pokazanego na rysunku 4-14. Uwaga Domyślnie baza danych importowana z pliku .bacpac jest tworzona jako wydanie Web o rozmiarze 1 GB. Jeśli potrzebny jest większy rozmiar, należy zaznaczyć pole wyboru CONFIGURE ADVANCED DATABASE SETTINGS (konfiguruj zaawansowane ustawienia bazy danych). Przekształci to proste okno dialogowe IMPORT DATABASE w dwustronicowego kreatora, w którym będzie można dodatkowo ustawić opcje wydania i rozmiaru bazy danych. Więcej informacji na ten temat zawiera podrozdział „Konfigurowanie wydania i rozmiaru bazy danych” w rozdziale 2.
14 . Kliknij ikonę zatwierdzenia w prawym dolnym rogu okna dialogoweg, aby roz-
począć import. Po zakończeniu tego procesu pojawi się komunikat o sukcesie w dolnej części ekranu i nowa baza WineCloudDb pojawi się na liście (niekiedy konieczne jest odświeżenie strony naciśnięciem klawisza F5, aby nowa baza została wyświetlona).
Aplikacje warstwy danych SQL
Rysunek 4-14 Importowanie pliku .bacpac z Microsoft Azure Storage do nowej bazy danych SQL Database
Wykorzystanie pliku BACPAC to jedna z najprostszych metod migrowania zarówno schematu bazy danych, jak i danych do instancji SQL Database. Można również użyć pliku DACPAC do przeniesienia samego schematu bazy (definicji tabel i innych obiektów, ale bez danych), jeśli odpowiada to wymaganiom migracji. Tym, co sprawia, że korzystanie z mechanizmu SQL Data-Tier Applications jest łatwe, jest fakt, że wykorzystujemy do tego dobrze znane narzędzia, takie jak SQL Server Management Studio (SSMS). Jak pokazaliśmy, migrację można wykonać używając tylko jednego narzędzia SQL Server oraz portalu zarządzania Microsoft Azure. Trzeba jednak mieć świadomość pewnego ograniczenia tej techniki: nie można zaimportować pliku .bacpac do projektu bazy danych tworzonego w SQL Server Data Tools (SSDT) (omówieniem takich projektów zajmiemy się w rozdziale 10). Jeśli konieczne jest wykonanie dowolnej modyfikacji schematu pomiędzy wyeksportowaniem bazy danych a zaimportowaniem jej do SQL Database, nie można tego osiągnąć przy użyciu pliku .bacpac. Zamiast tego można zaimportować pliki .dacpac (zawierające tylko informacje schematu) do projektu bazodanowego SSDT, ale pakiet taki nie będzie zawierał żadnych danych. Ze względu na ograniczenia funkcjonalności i różnice
89
90
Rozdział 4: Migrowanie baz danych
składniowe pomiędzy SQL Server a SQL Database często konieczne jest wykonanie zmian w schemacie przed wdrożeniem bazy danych w SQL Database. W rezultacie trzeba albo posłużyć się plikami .dacpac bez danych, albo wykonać niezbędne zmiany w schemacie na lokalnym serwerze SQL Server przed wyeksportowaniem plików .bacpac.
SQL Server Bulk Copy (bcp) SQL Server Bulk Copy (bcp) to narzędzie wiersza polecenia, przeznaczone do stosowania w wysoko wydajnych, masowych migracjach danych pomiędzy różnymi instancjami SQL Server – także do i z SQL Database. Migrowanie danych przy użyciu bcp jest zawsze procesem dwuetapowym; najpierw eksportujemy dane z tabeli źródłowej do pliku danych bcp, a następnie importujemy dane do tabeli docelowej z tego pliku. W tym podrozdziale pokażemy, jak wykorzystać narzędzie bcp do wyeksportowania plików danych ze źródłowej bazy SQL Server i zaimportować je do docelowej instancji SQL Database.
Migrowanie schematu Aby móc użyć SQL Server Bulk Copy (bcp) do migracji bazy danych do Microsoft Azure, musimy najpierw wdrożyć w docelowej instancji schemat bazy danych. Wynika to z faktu, że narzędzie bcp przenosi tylko same dane – nie kopiuje żadnych obiektów bazy danych, takich jak definicje tabel, relacje czy inne elementy. Aby utworzyć te obiekty, można zbudować i uruchomić skrypty T-SQL, zaprojektować i opublikować projekt bazy danych za pomocą SSDT (co pokażemy w rozdziale 10), albo nawet ręcznie zaprojektować docelowe tabele, używając portalu zarządzania SQL Database (co pokazaliśmy w rozdziale 1). Dla celów tego ćwiczenia usuniemy i odtworzymy tabele w bazie danych WineCloudDb, wypełnione w procesie migracji BACPAC wykonanym w poprzednim podrozdziale. Do tego celu wykorzystamy portal zarządzania SQL Database oraz skrypt T-SQL przedstawiony na Listingu 4-3. (Warto pamiętać, że uruchomienie skryptów T-SQL w instancji SQL Database można również wykonać jednym z lokalnie zainstalowanych narzędzi, takich jak SSMS lub SSDT). Można zauważyć, że użyty skrypt jest niemal identyczny jak zawarty w Listingu 4-1, tworzącym nową bazę na lokalnej instancji SQL Server. Jedyną różnicą jest to, że ten skrypt zaczyna się od trzech wyrażeń DROP TABLE, które usuwają istniejące tabele z bazy, po czym odtwarza je jako puste. Ostateczny efekt jest identyczny, jak wykonanie migracji samego schematu bazy, bez żadnych danych.
SQL Server Bulk Copy (bcp)
lisTing 4-3 Skrypt T-SQL usuwający i odtwarzający tabele w bazie WineCloudDb DROP TABLE [Order] DROP TABLE [Customer] DROP TABLE [Wine] CREATE TABLE Wine( WineId int IDENTITY PRIMARY KEY, Name nvarchar(50) NOT NULL, Category nvarchar(15) NOT NULL, Year int, Price MONEY DEFAULT 0 NOT NULL, AddedOn datetime2 DEFAULT SYSDATETIME() NOT NULL, UpdatedOn datetime2) CREATE TABLE Customer( CustomerId int IDENTITY PRIMARY KEY, FirstName nvarchar(50) NOT NULL, LastName nvarchar(50) NOT NULL, FavoriteWineId int, CONSTRAINT FK_Customer_Wine FOREIGN KEY (FavoriteWineId) REFERENCES Wine(WineId)) CREATE TABLE [Order]( OrderId int IDENTITY PRIMARY KEY, OrderedOn datetime2 DEFAULT SYSDATETIME() NOT NULL, CustomerId int NOT NULL, WineId int NOT NULL, Quantity int NOT NULL, Price MONEY NOT NULL, CONSTRAINT FK_Order_Customer FOREIGN KEY (CustomerId) REFERENCES Customer(CustomerId), CONSTRAINT FK_Order_Wine FOREIGN KEY (WineId) REFERENCES Wine(WineId))
Aby uruchomić ten skrypt, wykonaj następujące działania: 1 . Zaloguj się do portalu Microsoft Azure pod adresem https://manage.windowsa-
zure.com. Zostaniesz przekierowany do głównej strony prezentującej ALL ITEMS. 2 . Kliknij SQL DATABASES w pionowym panelu nawigacyjnym po lewej. 3 . Kliknij bazę danych WineCloudDb. 4 . Kliknij łącze DASHBOARD (tablica informacyjna) w górnej części strony. 5 . Przewiń stronę w dół i znajdź łącze MANAGE URL w sekcji „Quick Glance” (szybki
przegląd) po prawej stronie, po czym kliknij to łącze. Zostanie otwarta nowa karta przeglądarki ze stroną logowania do portalu SQL Database. Uwaga Portal SQL Database wykorzystuje technologię Silverlight. Jeśli na komputerze Czytelnika nie jest zainstalowany komponent Silverlight, pojawi się monit o jego pobranie i zainstalowanie, zanim możliwe będzie korzystanie z portalu.
6 . Wpisz nazwę logowania administratora i hasło w polach USERNAME oraz PASSWORD
odpowiednio, po czym kliknij Log On.
91
92
Rozdział 4: Migrowanie baz danych
7 . Kliknij przycisk New Query (nowe zapytanie) w pasku narzędzi u góry strony
portalu, aby otworzyć puste okno zapytania. 8 . Wpisz kod pokazany w Listingu 4-3 do okna zapytania (lub skopiuj go z plików
pobranych z witryny powiązanej z książką). 9 . Kliknij przycisk Run (uruchom), aby wykonać skrypt.
Baza danych WineCloudDb zawiera teraz puste tabele Wine, Customer oraz Order i jest gotowa do wykonania migracji danych przy użyciu bcp. Jednak przed pierwszym użyciem narzędzia bcp warto zapoznać się z jego składnią. Tabela 4-1 pokazuje typowe parametry polecenia bcp, które trzeba wyspecyfikować w typowej operacji importu lub eksportu. Tabela 4-1 Często używane parametry narzędzia SQL Server Bulk Copy (bcp) Parametr
Opis
źródło | cel
Obiekt bazy danych W przypadku eksportu wskazuje tabelę, widok lub zapytanie T-SQL, które ma zostać użyte jako źródło danych do wyeksportowania. W przypadku importu specyfikuje tabelę, do której kopiowane są dane.
in | out | queryout
Operacja BCP W celu zaimportowania danych do tabeli należy użyć in. Do wyeksportowania danych z tabeli lub widoku należy wyspecyfikować out. Parametr queryout oznacza, że wykonywany jest eksport z zapytania T-SQL przekazanego jako poprzedni parametr.
plik danych
Plik danych W przypadku eksportu określa nazwę pliku, który zostanie utworzony do przechowania danych eksportowanych z tabeli, widoku lub zapytania. W przypadku importu wskazuje nazwę pliku danych, z którego mają zostać odczytane dane. Parametr ten musi zawierać pełną ścieżkę do pliku danych.
–S serwer
Nazwa serwera Wskazuje nazwę serwera SQL Server lub Microsoft Azure SQL Database, z którym ma się połączyć narzędzie bcp.
–T
Uwierzytelnianie Windows Użycie zaufanego połączenia, w którym nie jest wymagane podanie nazwy użytkownika i hasła. Parametr ten nie może być użyty łącznie z przełącznikami –U ani –P. Zaufane połączenia są wspierane tylko przez SQL Server. Przy łączeniu się z SQL Database konieczne jest użycie przełączników –U oraz –P, wymaganych przez uwierzytelnianie SQL Server.
–U login
Login SQL Server W połączeniu z przełącznikiem –P umożliwia połączenie przy użyciu uwierzytelniania SQL Server z instancją lokalną lub SQL Database. Nie może być łączony z –T.
–P password
Hasło do loginu SQL Server W połączeniu z przełącznikiem –U umożliwia połączenie przy użyciu uwierzytelniania SQL Server z instancją lokalną lub SQL Database. Nie może być łączony z –T.
SQL Server Bulk Copy (bcp)
Tabela 4-1 Często używane parametry narzędzia SQL Server Bulk Copy (bcp) Parametr
Opis
–n
Użycie natywnych typów danych Zalecany przy wykonywaniu migracji pomiędzy instancjami SQL Server, SQL Database lub obydwoma typami. W przypadku baz danych innych firm niż Microsoft przełącznik ten nie jest obsługiwany i bcp wyświetli monit o wskazanie typu danych dla każdej kolumny (można też zdefiniować typy danych w odrębnym pliku formatu).
–q
Obsługa identyfikatorów złożonych Pozwala użyć nazw bazy danych, właściciela, tabeli lub widoków, które zawierają spacje lub pojedyncze znaki cudzysłowów (wykonuje polecenie SET QUOTED IDENTIFIERS ON).
Trzeba zwrócić uwagę, że bcp wymaga właściwej kolejności trzech pierwszych parametrów. Nazwa obiektu bazodanowego, operacji oraz pliku danych muszą zawsze zostać wymienione w tym porządku. Pozostałe przełączniki mogą pojawić się w dowolnej kolejności w wierszu polecenia.
Eksportowanie danych Jak można wywnioskować z przedstawionej składni, narzędzie bcp wykonuje migrację danych z lub do indywidualnej tabeli, a nie całej bazy danych. Lokalna baza WineDb zawiera trzy tabele: Wine, Customer oraz Order. Tabele Wine i Customer zawierają pewną liczbę wierszy danych, zaś tabela Order jest pusta, zatem w celu wyeksportowania danych trzeba będzie dwukrotnie wywołać narzędzie bcp: raz dla tabeli Wine, a następnie dla tabeli Customer. Aby wyeksportować dane z lokalnej bazy WineDb do pliku danych bcp, wykonaj poniższe działania: 1 . Wywołaj okno wiersza polecenia. Najłatwiejszym sposobem jest naciśnięcie kla-
wisza Windows, wpisanie cmd na ekranie startowym i naciśnięcie Enter. 2 . Wpisz polecenie bcp WineDb.dbo.Wine out Wine.dat -S .\sqlexpress -T -n -q
i naciśnij Enter. 3 . Wpisz bcp WineDb.dbo.Customer out Customer.dat -S .\sqlexpress -T -n -q
i naciśnij Enter. Uwaga Powyższe instrukcje zakładają, że używana jest lokalna instancja wydania SQL Server Express, w której nazwa serwera ma postać .\sqlexpress. Przy używaniu innego wydania lub inaczej nazwanej instancji należy zastąpić nazwę serwera .\sqlexpress w poleceniu nazwą używanego serwera i instancji. Co więcej, jeśli serwer nie obsługuje uwierzytelniania Windows, nie można użyć przełącznika –T; w takim przypadku trzeba użyć przełączników –U oraz –P dla uwierzytelniania SQL Server.
93
94
Rozdział 4: Migrowanie baz danych
Po uruchomieniu bcp wyświetlana jest informacja o statusie, wskazująca liczbę wyeksportowanych wierszy, rozmiar pakietu, czas trwania operacji i średnią przepływność, co prezentuje rysunek 4-15.
Rysunek 4-15 Eksportowanie tabel SQL Server do plików danych przy użyciu bcp
Importowanie danych Możemy teraz ponownie użyć bcp, aby zaimportować uzyskane pliki danych do bazy WineCloudDb w instancji SQL Database, ale tym razem trzeba będzie posłużyć się parametrem in, aby wykonać operację importu. Podczas importowania danych przy użyciu bcp trzeba zwrócić uwagę na wielkość pliku danych. Jeśli zbiór danych jest bardzo duży, najprawdopodobniej konieczne będzie podzielenie go na wiele fragmentów. Można to osiągnąć, używając przełącznika –b i specyfikując liczbę wierszy, które mają zostać załadowane w jednym wsadzie. Każdy wsad jest ładowany i rejestrowany jako oddzielna transakcja bazodanowa, zatem w razie wystąpienia błędów tylko wiersze wstawione przez bieżący wsad są odwoływane. Domyślnie bcp ładuje wszystkie wiersze z pliku danych jako jeden wsad, ale przy imporcie bardzo dużych zbiorów pojawia się realne niebezpieczeństwo przerwania połączenia lub zdławienia wydajności SQL Database, jeśli nie użyjemy mniejszego rozmiaru. Być może konieczne będzie poeksperymentowanie z danymi, aby ustalić odpowiednią wielkość wsadu. Składnia bcp udostępnia specjalne przełączniki do obsługi wsadowych operacji importu i pozwala określić wskazówki (hints) włączające inne opcje. Te dodatkowe przełączniki zostały zebrane w tabeli 4-2.
Wielkość wsadu Określa liczbę wierszy, które mają być przetwarzane w pojedynczym wsadzie (transakcji) podczas operacji importu.
–F pierwszy wiersz
Pierwszy wiersz Przy przetwarzaniu wsadowym z użyciem parametru –b określa wiersz w pliku danych, który ma zostać użyty jako punkt początkowy operacji importu.
–L ostatni wiersz
Ostatni wiersz Przy przetwarzaniu wsadowym z użyciem parametru –b określa wiersz w pliku danych, który ma zostać użyty jako punkt stopu (zakończenia) operacji importu.
–h hints
Wskazówki Włącza inne opcje. Na przykład można posortować dane w trakcie operacji importu, używając wskazówki ORDER, wymusić sprawdzanie ograniczeń w trakcie importu przy użyciu CHECK CONSTRAINTS albo zablokować dostęp do tabeli na czas importu, używając wskazówki TABLOCK.
Zalecaną praktyką jest wyłączenie nieklastrowanych indeksów, wyzwalaczy i ograniczeń w docelowej bazie danych na czas importu, po czym ich ponowne włączenie po zakończeniu operacji. W ten sposób można znacząco zwiększyć wydajność i szybkość importu. Biorąc pod uwagę prostotę i wielkość bazy danych WineDb, nic nie musimy tu wyłączać ani nie ma potrzeby dzielenia operacji na poszczególne wsady (choć zamierzamy zademonstrować takie działanie dla 15-wierszowej tabeli Wine, po prostu po to, aby pokazać, jak to robić w przypadku znacznie większych tabel). Aby zaimportować pliki danych wyeksportowane z lokalnej bazy danych WineDb na SQL Server do bazy WineCloudDb w instancji SQL Database, wykonaj poniższe czynności: 1 . Otwórz okno wiersza polecenia, jeśli nie jest nadal otwarte po poprzedniej
procedurze. 2 . Wpisz polecenie bcp WineCloudDb.dbo.Customer in Customer.dat -S
tcp:.database.windows.net -U @ -P -n i naciśnij Enter. To polecenie ładuje cały plik Customer.dat do tabeli Customer w bazie danych. Po ukończeniu działania bcp wyświetli informacje statusu, podobne do pokazanych na rysunku 4-16. Uwaga Zastępcze wpisy , oraz pokazane w powyższym poleceniu (i kolejnych) należy zastąpić nazwą własnego serwera, loginem administratora i hasłem do tego loginu serwera SQL Database, na którym znajduje się baza danych WineCloudDb.
95
96
Rozdział 4: Migrowanie baz danych
Rysunek 4-16 Importowanie pliku danych do tabeli w SQL Database przy użyciu bcp
3 . Wpisz bcp WineCloudDb.dbo.Wine in Wine.dat -S tcp:.database.win-
dows.net -U @ -P -n -b 5 -F 1 -L 5 -h "TABLOCK" i naciśnij Enter. Spowoduje to zaimportowanie pierwszego wsadu wierszy (od 1 do 5) z pliku Wine.dat do tabeli Wine. Przełącznik –h określa wskazówkę TABLOCK, która nakazuje bcp zablokowanie tabeli Wine na czas importu. 4 . Wpisz bcp WineCloudDb.dbo.Wine in Wine.dat -S tcp:.databa-
se.windows.net -U @ -P -n -b 5 -F 6 -L 10 -h "TABLOCK" i naciśnij Enter. Polecenie to zaimportuje drugą porcję danych (wiersze od 6 do 10) z pliku Wine.dat do tabeli Wine, która zostanie zablokowana na czas trwania tego procesu. 5 . Wpisz bcp WineCloudDb.dbo.Wine in Wine.dat -S tcp:.database.
windows.net -U @ -P -n -b 5 -F 11 -L 15 -h "TABLOCK" i naciśnij Enter. Zaimportuje to trzecią (i ostatnią) porcję danych (wiersze od 11 do 15). W ten sposób zaimportowaliśmy zarówno tabelę Wine, jak i Customer z lokalnej bazy WineDb do bazy WineCloudDb w instancji SQL Database, używając narzędzia bcp. W naszym przykładzie migracji podlegał bardzo mały zbiór danych, zatem w rzeczywistości nie było potrzeby dzielenia tabeli Wine na trzy wsady po 5 wierszy w każdym (ale pokazaliśmy, jak to się robi). W istocie narzędzie bcp zostało zaprojektowane do skutecznego przesyłania wielkich ilości danych z i do SQL Server. Jeśli zatem mamy wielkie tabele danych, które chcemy przemigrować do SQL Database (lub pomiędzy różnymi instalacjami SQL Server), ćwiczenie to pokazało, jak można podzielić całą operację na „rozsądnych rozmiarów” wsady (porcje danych).
SQL Database Migration Wizard
SQL Database Migration Wizard SQL Database zawiera szereg wartych odnotowania różnic i ograniczeń, jeśli porównać ją z SQL Server (zostały one omówione w rozdziale 3, „Różnice pomiędzy SQL Server a Microsoft Azure SQL Database”). Różnice te muszą być uwzględnione przy projektowaniu migracji baz danych. Schematy baz danych i używane skrypty T-SQL muszą być zgodne z obsługiwaną funkcjonalnością i składnią w SQL Database, ale przeglądanie schematu i poszczególnych kodów może być bardzo czasochłonne i męczące, a w dodatku podatne na błędy. Dobra wiadomość brzmi tak, że zadanie to znacznie upraszcza narzędzie Microsoft Azure SQL Database Migration Wizard (kreator migracji baz danych Microsoft Azure). Wszystkie narzędzia migracji i rozwiązania, które analizowaliśmy do tej pory, są wbudowane w narzędzia dołączone do Microsoft SQL Server lub w Visual Studio. Tym niemniej istnieją również inne przydatne i użyteczne narzędzia, wykraczające poza podstawowy zestaw oferowany przez firmę Microsoft, i Microsoft Azure SQL Database Migration Wizard jest jednym z nich. Jest to bezpłatne narzędzie typu open source, które interaktywnie pomaga przejść przez proces migracji bazy danych do SQL Database. Autorem tego kreatora jest George Huey, zajmujący stanowisko Principal Architect w firmie Microsoft, jeszcze we wczesnym okresie działania Microsoft Azure SQL Database, gdy wykorzystywana była jeszcze nazwa SQL Azure. Został on później przetestowany praktycznie przez tysiące użytkowników i często jest aktualizowany w celu poprawy błędów i ulepszenia funkcjonalności, często jako wynik licznych wiadomości pochodzących ze społeczności użytkowników. Uwaga Mimo że narzędzie to zostało napisane przez pracownika firmy Microsoft, nie jest to oficjalny produkt firmy i nie jest wspierane przez Microsoft.
Jeśli mamy istniejącą bazę danych SQL Server i nie mamy pewności, czy spełnia ona wszystkie wymagania i ograniczenia SQL Database, kreator Microsoft Azure SQL Database Migration Wizard jest doskonałym punktem wyjścia. Pozwala on nie tylko na wdrożenie schematu i danych przenoszonych z SQL Server do SQL Database, ale również zidentyfikować problemy ze zgodnością, a nawet automatycznie rozwiązać niektóre z tych problemów. Microsoft Azure SQL Database Migration Wizard upraszcza migrację baz danych, wykonując (bardzo dobrze) trzy fundamentalne zadania: ■
■ ■
Analizuje bazę danych SQL Server, ślady SQL Profiler lub skrypty T-SQL w poszukiwaniu niekompatybilności z SQL Database. Generuje skrypty T-SQL do utworzenia schematu bazy danych w SQL Database. Migruje dane do SQL Database przy użyciu narzędzia bcp.
97
98
Rozdział 4: Migrowanie baz danych
Korzystanie ze skryptów T-SQL oraz migrowanie danych do SQL Database przy użyciu BACPAC i bcp omówiliśmy już wcześniej w tym rozdziale. Do tej pory jednak nie próbowaliśmy analizować potencjalnej niekompatybilności bazy danych, a właśnie ta funkcjonalność jest jedną z największych zalet Microsoft Azure SQL Database Migration Wizard.
Pobieranie narzędzia Aby móc zacząć korzystać z SQL Database Migration Wizard, należy pobrać je z witryny Codeplex i następnie zainstalować. SQL Database Migration Wizard jest zależny od dostępności bibliotek i asemblacji SQL Server, co oznacza wymóg wcześniejszego zainstalowania SQL Server na docelowej maszynie. W chwili pisania tych słów dostępne były dwie wersje SQL Database Migration Wizard. Wersja 3.X wspiera SQL Server 2008 R2, zaś wersja 4.X obsługuje SQL Server 2012. W tej książce zakładamy, że Czytelnik używa SQL Server 2012, zatem zainstalujemy wersję 4.X. Należy oczekiwać, że wraz z nowymi, przyszłymi wersjami SQL Server pojawią się również nowe wersje tego narzędzia, zatem trzeba zwrócić uwagę, którą wersję narzędzia pobieramy. Aby pobrać i zainstalować narzędzie SQL Database Migration Wizard, wykonaj poniższe działania: 1 . W przeglądarce Web przejdź do strony http://sqlazuremw.codeplex.com. Jest
to strona witryny Codeplex dedykowana dla tego narzędzia (warto zwrócić uwagę, że URL odwołuje się do „SQL Azure”, gdyż narzędzie powstało w czasie, gdy SQL Database nazywało się SQL Azure). 2 . Kliknij przycisk DOWNLOADS w górnej części strony. Zostanie wyświetlona strona
ze wszystkimi plikami do pobrania dla SQL Database Migration Wizard. 3 . Odszukaj i kliknij łącze pobierania SQLAzureMW v4.0.18 Release Binary for
SQL Server 2012 (albo odszukaj i kliknij łącze Release Binary dla wersji pasującej do używanej wersji SQL Server). 4 . W monicie Open or Save (Otwórz lub zapisz) kliknij Save, aby rozpocząć pobieranie. 5 . W Eksploratorze plików przejdź do folderu pobierania, w którym został zapisany
pobrany plik .zip. 6 . Prawym klawiszem myszy kliknij pobrany plik .zip i wybierz Properties
(Właściwości). 7 . W oknie dialogowym Properties kliknij przycisk Unblock (Odblokuj), jak na rysun-
ku 4-17. Jeśli nie odblokujesz pliku, nadal będzie można go rozpakować, ale nie będzie możliwe uruchomienie programu z lokalizacji rozpakowania.
SQL Database Migration Wizard
Rysunek 4-17 Odblokowywanie pobranego pliku .zip przy użyciu okna dialogowego Properties
8 . Kliknij OK, aby zamknąć okno dialogowe. 9 . Prawym klawiszem myszy kliknij plik .zip i wybierz polecenie Extract All
(Wyodrębnij wszystkie). 10 . Kliknij Extract (Wyodrębnij), aby wypakować zawartość pliku do nowego folderu
w tej samej lokalizacji o tej samej nazwie, co plik .zip. Po wypakowaniu pliku folder z zawartymi w nim plikami otwiera się automatycznie w nowym oknie Eksploratora plików i możemy zacząć korzystać z narzędzia.
Migrowanie bazy danych Aby posłużyć się narzędziem SQL Database Migration Wizard do migracji bazy danych WineDb, wykonaj następujące działania: 1 . W oknie Eksploratora otwartym dla otwartych plików podwójnie kliknij plik
SQLAzureMW.exe, aby uruchomić narzędzie. Zostanie wyświetlona strona Select Process (Wybierz projekt), pokazana na rysunku 4-18.
99
100
Rozdział 4: Migrowanie baz danych
Rysunek 4-18 Strona Select Process narzędzia SQL Database Migration Wizard
2 . Na liście opcji po prawej zaznacz przycisk radiowy Database (baza danych) poniżej
wpisu Analyze / Migrate (analizuj /migruj), po czym kliknij Next. Zostanie wyświetlone okno dialogowe Connect To Server. Uwaga Przycisk TSQL File może być użyteczny, jeśli już wcześniej oskryptowaliśmy obiekty naszej bazy w pliku T-SQL; w tym przypadku narzędzie potrafi również wykonać analizę i migrację przy użyciu tego pliku T-SQL.
3 . W polu Server Name wpisz .\sqlexpress (albo nazwę instancji SQL Server, która
zawiera bazę danych WineDb). 4 . Jeśli lokalny serwer wymaga uwierzytelniania SQL Server, zaznacz przycisk Use A Specific User ID And Password (użyj określonego identyfikatora i hasła), po czym wpisz nazwę logowania i hasło.
5 . Pozostaw inne opcje w wartościach domyślnych, po czym kliknij przycisk Connect
w dolnej części okna. 6 . Pojawi się strona Select Source (wybierz źródło) z listą baz danych zlokalizowanych
w instancji SQL Server, z którą właśnie się połączyliśmy. Zaznacz bazę WineDb i kliknij Next.
SQL Database Migration Wizard
7 . Pojawi się strona Choose Objects (wybierz obiekty). Domyślnie strona ta jest usta-
wiona na skryptowanie wszystkich obiektów bazy danych, ale można tu wybrać określone obiekty (tabele, widoki, procedury składowane i tak dalej), które mają być przetwarzane. Pozostaw włączoną opcję domyślną, aby oskryptować całą bazę danych, po czym kliknij Next. 8 . Pojawi się strona Script Wizard Summary (podsumowanie kreatora skryptu). Warto
poświęcić nieco czasu, aby rozwinąć poszczególne węzły i przejrzeć planowane działania. Po upewnieniu się, że wszystko jest w porządku, kliknij Next. 9 . W monicie, czy tworzyć skrypt SQL, kliknij Yes. W rezultacie utworzony zostanie
skrypt generujący schemat bazy danych i wywołujący bcp w celu wyeksportowania poszczególnych tabel z lokalnej bazy WineDb. 10 . Po ukończeniu przetwarzania kreator wyświetli stronę Results Summary (podsu-
mowanie wyników), pokazaną na rysunku 4-19. W przypadku bazy WineDb nie powinny się pojawić żadne błędy. Jeśliby jednak jakieś błędy wystąpiły, właśnie tu będziemy mogli je zauważyć, gdyż kreator odmówi migrowania bazy danych, dopóki błędy nie zostaną naprawione.
Rysunek 4-19 Strona Results Summary wyświetlana po udanym wygenerowaniu i wykonaniu skryptu
101
102
Rozdział 4: Migrowanie baz danych
Uwaga Strona Results Summary wykorzystuje kodowanie kolorami, aby ułatwić dostrzeżenie problemów. Zielony i niebieski wskazują sukces, ale jeśli pojawią się problemy kompatybilności, zostaną one wyświetlone w kolorze czerwonym lub ciemnoczerwonym. Czerwień sygnalizuje błąd, który uniemożliwia migrację i który trzeba rozwiązać, zaś ciemnoczerwony tekst oznacza wykrycie niezgodności, ale SQL Database Migration Wizard wie, jak rozwiązać taki problem automatycznie.
nerowany przez SQL Database Migration Wizard, pokazany na rysunku 4-20.
Rysunek 4-20 Zakładka SQL Script zawiera wygenerowany skrypt tworzenia schematu
12 . Jeśli chcesz zapisać skrypt do pliku w celu późniejszego użycia lub przejrzenia,
kliknij Save i wybierz lokalizację do zapisania pliku. 13 . Kliknij Next, aby zacząć konfigurowanie wdrożenia w SQL Database. Ponownie
pojawi się okno dialogowe Connect To Server.
SQL Database Migration Wizard
14 . W oknie Connect To Server wykonaj następujące czynności: a . W polu Server Name wpisz .database.windows.net (zastępując
ver> nazwą swojego serwera SQL Database). b . W polu User Name wpisz @ (zastępując nazwą
konta administratora i nazwą serwera SQL Database). c . W polu Password wpisz hasło przypisane do loginu administratora. Okno Connect To Server powinno wyglądać podobnie do pokazanego na rysunku 4-21. d . Kliknij Connect, aby połączyć się z serwerem SQL Database. Okno Connect To Server zostanie zamknięte.
Rysunek 4-21 Łączenie się z SQL Database w celu wdrożenia bazy przy użyciu SQL Database Migration Wizard
15 . W kreatorze pojawi się strona Setup Target Server Connection (konfigurowanie połą-
czenia docelowego serwera), zawierająca listę wszystkich baz danych na serwerze. Jeśli wykonałeś poprzednie procedury, powinieneś zobaczyć bazę WineCloudDb na liście. Ponieważ jednak chcemy zacząć od nowej, pustej bazy, należy usunąć istniejącą: a . Kliknij bazę danych WineCloudDb. b . Kliknij przycisk Delete Database w dolnej części okna. c . W monicie o potwierdzenie kliknij Yes¸ aby powrócić do kreatora.
103
104
Rozdział 4: Migrowanie baz danych
16 . Kliknij przycisk Create Database (utwórz bazę danych) w dolnej części okna dia-
logowego. Pojawi się okno Create Database. 17 . W polu Enter Database Name wpisz WineCloudDb. Okno dialogowe powinno
wyglądać podobnie do pokazanego na rysunku 4-22.
Rysunek 4-22 Tworzenie docelowej bazy danych dla migracji w SQL Database Migration Wizard
18 . Kliknij przycisk Create Database . Spowoduje to utworzenie pustej bazy
w SQL Database o nazwie WineCloudDb, zamknięcie okna Create Database i powrót do kreatora. 19 . Zaznacz nowo utworzoną bazę WineCloudDb na liście i kliknij Next. 20 . W monicie z zapytaniem, czy wykonać skrypt, kliknij Yes. 21 . W miarę postępów na stronie Target Server Response (odpowiedzi serwera docelo-
wego) będą pojawiać się zaktualizowane statusy. Po zakończeniu wdrażania bazy strona ta powinna wyglądać podobnie do pokazanej na rysunku 4-23. Uwaga Strona Target Server Response również używa kodowania kolorami do oznaczania sukcesów (zielone i niebieskie) oraz porażek (czerwone).
22 . Kliknij Exit, aby zamknąć kreatora.
Jak widać, udało nam się przenieść zarówno schemat, jak i dane do bazy danych WineCloudDb w instancji SQL Database, posługując się intuicyjnym narzędziem Azure SQL Database Migration Wizard. Oprócz przenoszenia schematu i danych narzędzie to również wykonuje analizę struktur danych i wykrywa problemy z kompatybilnością.
SQL Database Migration Wizard
Rysunek 4-23 Strona Target Server Response po udanym wdrożeniu bazy danych
Podsumowując, narzędzie to wykonuje następujące działania: 1 . Generuje skrypty T-SQL pozwalające odtworzyć wszystkie obiekty bazodanowe
(schemat) w lokalnej bazie SQL Server. 2 . Eksportuje dane do plików przy użyciu bcp. 3 . Analizuje wygenerowane skrypty T-SQL przy użyciu reguł, które pozwalają wykryć
znane problemy ze zgodnością i ograniczeniami. 4 . Wdraża schemat w SQL Database, wykonując wcześniej utworzone (i potencjalnie
automatycznie naprawione) skrypty T-SQL. 5 . Importuje dane do bazy SQL Database przy użyciu bcp.
Wszystkie te kroki (za wyjątkiem kroku analizy) można również wykonać niezależnie, co pokazaliśmy we wcześniejszych częściach tego rozdziału. SQL Database Migration
105
106
Rozdział 4: Migrowanie baz danych
Wizard po prostu łączy wszystkie te działania w jednym narzędziu, bez konieczności odwoływania się do wielu różnych narzędzi i poleceń. Jednak analiza, którą SQL Database Migration Wizard wykonuje wobec schematu lokalnej bazy danych, nie jest czymś, co moglibyśmy zrobić jakimś innym narzędziem. Ta funkcjonalność jest unikatową i szczególnie atrakcyjną możliwością oferowaną przez kreatora. Microsoft Azure SQL Database Migration Wizard jest oprogramowaniem typu open source i można przejrzeć jego kod źródłowy. Jeśli ktoś wykryje niekompatybilność pomiędzy SQL Server a SQL Database, której narzędzie nie przechwytuje, albo po prostu jest zainteresowany wstępnie zdefiniowanymi regułami, można je łatwo obejrzeć. Są one zdefiniowane w pliku XML o nazwie NotSupportedByAzureFile.Config, który znajduje się w tym samym katalogu, co plik SQLAzureMW.exe. Ktoś, kto zna zasady posługiwania się wyrażeniami regularnymi, może nawet dodać własne reguły do SQL Server Migration Wizard, modyfikując ten plik XML przy użyciu edytora tekstowego.
Podsumowanie Bardzo rzadko zdarzają się projekty, które startują od zera i są całkowicie nowe. Znacznie bardziej prawdopodobna będzie sytuacja, że projekt wdrożenia bazy danych w chmurze Microsoft Azure będzie wymagał przeniesienia (migracji) istniejących baz danych. Istnieje wiele sposobów migracji z SQL Server do SQL Database, przy czym każdy z nich ma swoje zalety i wady i pasuje do różnych scenariuszy. W tym rozdziale pokazaliśmy kilka narzędzi i technik przenoszenia istniejącej bazy danych SQL Server do SQL Database, w tym skrypty T-SQL, pliki .bacpac, bcp oraz SQL Database Migration Wizard. W przypadku niewielkich baz danych można wykorzystać skrypty T-SQL, generowane z bazy danych SQL Server i następnie wykonywane w instancji SQL Database. Pliki .bacpac SQL Data-Tier Application pozwalają w prosty sposób spakować całą bazę danych, włącznie ze schematem i danymi, w pojedynczym pliku i zaimportować go do SQL Database, jednak działanie takie odbywa się na poziomie bazy danych i nie umożliwia migrowania indywidualnych obiektów bazodanowych. Co więcej, w przypadku większych baz danych rozmiar pliku .bacpac może stanowić znaczne utrudnienie. Masowe kopiowanie przy użyciu bcp jest wydajnym i skutecznym sposobem przenoszenia wielkich ilości danych do SQL Database, ale nie pomaga w żaden sposób przy przenoszeniu obiektów bazodanowych (schematu). Na koniec zademonstrowaliśmy Microsoft Azure SQL Database Migration Wizard, bezpłatne oprogramowanie open source dostępne w witrynie Codeplex, które łączy proces generowania skryptów i migrowania schematu z procesem kopiowania danych przy użyciu bcp.
ROZDZI AŁ 5
Bezpieczeństwo i kopie zapasowe Eric Boyd
Z
agadnienia związane z bezpieczeństwem, dostępnością i przywracaniem po awariach zajmują czołowe pozycje na liście wątpliwości podnoszonych przez klientów, gdy przychodzi do rozważania chmury prywatnej. Te obawy zdecydowanie nie są nowe i nie pojawiły się wraz z chmurą; klienci od dawna musieli projektować rozwiązania, które pozwolą sobie poradzić z tymi samymi obawami, długo przed pojawieniem się koncepcji chmury. Ta ostatnia jest po prostu mało znanym terenem, przez co te podstawowe wątpliwości muszą zostać rozpatrzone od nowa. Tak więc klienci muszą poznać sensowne rozwiązania tych zagadnień, zanim uznają chmurę publiczną za akceptowalną opcję. Firma Microsoft wykonała wielką pracę w kierunku rozwiązania tych problemów i ułatwienia działań dzięki mechanizmom zabezpieczeń i certyfikacji działającym w chmurze Microsoft Azure, wraz z funkcjami platformy dostarczającymi niezbędnego poziomu kontroli i widoczności. W tym rozdziale omówimy zagadnienia dotyczące zabezpieczeń i kopii zapasowych w kontekście chmury. Zaczniemy od omówienia ogólnej odpowiedzialności za bezpieczeństwo, jaka spoczywa na dowolnym dostawcy chmury publicznej, po czym przejdziemy do bardziej szczegółowego omówienia tej tematyki w Microsoft Azure i Microsoft Azure SQL Database. Pokażemy, jak zabezpieczyć SQL Database poprzez konfigurację zapory, jak tworzyć niestandardowe reguły dostępowe i definiować użytkowników i uprawnienia. Bezpieczeństwo i kopie zapasowe zazwyczaj występują w parze. Niezależnie od wszelkich innych zagadnień zabezpieczeń, jak „bezpieczny” byłby nasz biznes, gdybyśmy nie dysponowali żadną kopią zapasową na wypadek nieprzewidzianej awarii? Tak więc pod koniec rozdziału nauczymy się, jak wykonać kopię zapasową bazy danych w SQL Database i jak zaplanować automatyczne wykonywanie tych kopii zapasowych.
107
108
Rozdział 5: Bezpieczeństwo i kopie zapasowe
Główne obawy dotyczące chmury Dwie najczęściej wymieniane obawy podnoszone przez użytkowników przy rozważaniu chmury publicznej to bezpieczeństwo i zapewnienie ciągłości biznesu, niekiedy określane terminem przywracania po awarii. Bezpieczeństwo jest bardzo rozległym zagadnieniem i może oznaczać bardzo różne rzeczy, zależnie od oceniającej je osoby i kontekstu. Dlatego wygodniej będzie zastanawiać się nad zagadnieniami zabezpieczeń, gdy podzielimy je na dwie główne kategorie: problemy zabezpieczeń, za które odpowiedzialność spoczywa na dostawcy chmury (firmie Microsoft w przypadku Azure), oraz te, które leżą w gestii klienta lub które są rozwiązywane wspólnie przez klienta i dostawcę chmury.
Odpowiedzialność dostawcy chmury publicznej za bezpieczeństwo Niektóre zagadnienia dotyczące zabezpieczeń mogą być zarządzane i rozwiązywane tylko przez dostawcę chmury, gdyż dostęp kliencki jest ograniczony do wyższego poziomu abstrakcji, ponad surową infrastrukturą przetwarzania, zasobami i usługami. Klient zazwyczaj nie może uzyskać bezpośredniego dostępu do takich rzeczy, jak routery, switche czy zapory. To samo dotyczy fizycznych serwerów lub hiperwizora, będącego warstwą programową wirtualizującą sprzęt w celu umożliwienia działania wielu systemów operacyjnych na pojedynczym fizycznym serwerze. Oznacza to, że bardzo istotny jest wybór renomowanego dostawcy chmury o udokumentowanej historii, na którego będzie można liczyć i mu ufać. Jednak nie można polegać tylko na wierze w dostawcę. Potrzebujemy również transparentności i wglądu w zasoby i praktyki dostawcy chmury, włącznie z praktykami i procedurami dotyczącymi zabezpieczeń, co opiszemy w kolejnych podrozdziałach.
Fizyczne centrum danych Dostęp do fizycznego centrum danych – w tym możliwość wejścia za zewnętrzne ogrodzenie, do budynku i do samej serwerowni zawierającej infrastrukturę fizyczną – musi być zarządzany przy użyciu zasad bezpieczeństwa, które są spójne i stale stosowane. Chcielibyśmy, aby uzyskanie dostępu przez nieautoryzowaną osobę do naszych serwerów było skrajnie trudne, a w wersji idealnej – niemożliwe.
Niezależność od personelu dostawcy Osoby, które są uprawnione do uzyskiwania dostępu do infrastruktury przetwarzania i zasobów nie powinny nadal mieć możliwości dostępu do naszych danych, o ile jawnie nie przyznamy im takiego uprawnienia. Ponieważ nie zarządzamy podstawową infrastrukturą, dostawca musi zagwarantować, że jest ona zabezpieczona
Główne obawy dotyczące chmury
odpowiednimi środkami, które powstrzymają jego pracowników przed uzyskiwaniem dostępu do naszych danych bez zezwolenia.
Izolacja od innych najemców Podobnie jak w przypadku personelu dostawcy, nie chcemy, aby inni użytkownicy chmury mogli uzyskiwać dostęp do naszych danych i aplikacji. W przypadku chmury publicznej często mamy do czynienia ze współnajemcami (multitenant) – to architektura, w której pojedynczy element infrastruktury obsługuje wielu klientów. Gdy korzystamy ze współużytkowanych usług, ten problem musi być zarządzany przez dostawcę.
Ochrona przed cyberatakami Złośliwy atak, taki jak odmowa usługi (denial-of-service), może zostać wymierzony przeciwko naszym aplikacjom i usługom, ale również na szerszym poziomie, przeciwko usługom chmury. Jeśli taki atak nastąpi, chcielibyśmy, aby dostawca chmury go wykrył i powstrzymał, nie dopuszczając do wyłączenia usług.
Wspólna odpowiedzialność za zabezpieczenia Odpowiedzialność za inne zagadnienia zabezpieczeń leżą albo po stronie klienta, albo są współdzielone przez klienta i dostawcę chmury. Ilekroć problem zabezpieczeń wynika z konfiguracji klienta, implementacji lub oprogramowania, odpowiedzialność za niego nie może spoczywać wyłącznie na dostawcy. Klient musi zabezpieczyć te aspekty aplikacji, które leżą w jego zasięgu, aby rozwiązać tego typu problem.
Osiąganie zgodności z wymaganiami Wiele przedsiębiorstw i organizacji musi spełniać wymagania prawne ze względu na naturę prowadzonej działalności i przechowywane dane. Wymagania te często obejmują fizyczne centrum danych, aplikacje uruchomione w tych centrach i procesy zarządzania dotyczące obydwu obszarów. W rezultacie musimy wiedzieć, jakie certyfikacje zgodności uzyskał rozważany dostawca chmury. Musimy jednak rozumieć, że to na nas spoczywa odpowiedzialność za spełnienie tych wymogów, które wykraczają poza kontrolę dostawcy chmury – na przykład dotyczących samej aplikacji i specyficznych dla konkretnej implementacji.
Rejestrowanie aktywności Podobnie jak w przypadku zgodności, zapewnienie tego, że będzie wiadomo, kto co zrobił i kiedy, leży po części po stronie dostawcy chmury, a częściowo po stronie klienta. Tylko dostawca może rejestrować i udostępniać dzienniki inspekcji dotyczące działań, które występują w usługach platformy. Jednak po stronie klienta leży
109
110
Rozdział 5: Bezpieczeństwo i kopie zapasowe
odpowiedzialność za śledzenie aktywności na poziomie aplikacji. Ponieważ dokładna i szczegółowa inspekcja jest typowym wymogiem większości certyfikacji zgodności, jest to ważna zdolność, którą zarówno dostawca chmury, jak i nasze aplikacje muszą zapewnić. Kluczowym wymogiem skutecznej inspekcji jest zapewnienie unikatowych poświadczeń dla każdego użytkownika i zagwarantowanie, że użytkownicy ci nie będą udostępniać sobie tych poświadczeń. Jeśli wielu użytkowników korzysta z jednego konta, nie można będzie określić, kto wykonał określone działanie zarejestrowane dla tego konta.
Ochrona przed elektronicznymi włamywaczami Nie można zapominać o hackerach, którzy próbują zarobić na kradzieży danych, ani o tych, którzy po prostu chcą być złośliwi i próbują stworzyć chaos. Musimy trzymać obydwa typy z daleka. Dostawca chmury musi zabezpieczyć swoją infrastrukturę i podstawowe usługi i ochronić ją przed włamaniem na tym poziomie. Do nas należy odpowiedzialność za ochronę naszej aplikacji przed nadużyciami, a jeśli korzystamy z maszyn wirtualnych w modelu „infrastruktura jako usługa” (IaaS), konieczne jest bieżące aplikowanie poprawek i zabezpieczanie systemu operacyjnego.
Bezpieczeństwo w Microsoft Azure Firma Microsoft zainwestowała wiele wysiłku i talentów w zapewnienie, że Azure jest bezpieczną i niezawodną chmurą publiczną. Microsoft wykonuje też dobrą pracę, zapewniając wzgląd w praktyki zabezpieczeń i poufności stosowane w Microsoft Azure. Jednym z elementów tych działań jest witryna Microsoft Azure Trust Center (Centrum zaufania systemu Microsoft Azure), dostępna pod adresem http://azure.microsoft.com/pl-pl/support/trust-center/. Witryna ta udostępnia szczegółowe informacje o praktykach zapewniających bezpieczeństwo, poufność i zgodność z wymaganiami prawnymi w Microsoft Azure. Jest to doskonałe źródło informacji, pozwalające uzyskać lepsze zrozumienie zagadnień bezpieczeństwa i znaleźć odpowiedzi na pytania dotyczące zabezpieczeń Microsoft Azure. Choć firma Microsoft włożyła wiele wysiłku, aby sprawić, że SQL Database będzie bezpieczną i niezawodną usługą, nadal będziemy musieli zrobić kilka rzeczy, aby stworzyć bezpieczne środowisko. W kolejnych podrozdziałach przejdziemy kilka procedur krok po kroku, które pomogą zabezpieczyć naszą bazę danych. Zaczniemy od zabezpieczenia dostępu i łączności z SQL Database. Następnie przejdziemy do zagadnień zabezpieczeń poziomu aplikacji, takich jak ataki iniekcji SQL i szyfrowanie danych.
Zabezpieczanie SQL Database
Zabezpieczanie SQL Database SQL Database udostępnia funkcje zabezpieczeń dla uwierzytelniania i autoryzacji, analogiczne do tych, które znajdziemy w SQL Server. Niezależnie od tych funkcji SQL Database zapewnia możliwość zabezpieczenia dostępu na podstawie adresu IP klienta oraz szyfrowanie całej komunikacji pomiędzy klientem a bazą danych. W kolejnych procedurach zademonstrujemy wprowadzanie zabezpieczeń w usłudze SQL Database.
Tworzenie bazy danych SQL Database Aby móc zademonstrować różne techniki zabezpieczeń i tworzenia kopii zapasowych, w procedurach zawartych w tym rozdziale wykorzystamy bazę danych WineCloudDb, utworzoną we wcześniejszych rozdziałach. Jeśli ta baza jeszcze nie jest utworzona (albo została usunięta), należy utworzyć ją teraz, aby móc wykonać ćwiczenia z tego rozdziału. Jeśli Czytelnik ma już bazę danych WineCloudDb na swoim serwerze SQL Database, może przejść do kolejnej procedury „Konfigurowanie zapory SQL Database”. Do utworzenia bazy danych wykorzystamy narzędzie SSMS. Następnie wykonamy w niej skrypt pokazany w Listingu 5-1, tworzący kilka tabel i wypełniający je pewną ilością danych. lisTing 5-1 Skrypt tworzący bazę danych WineCloudDb CREATE TABLE Wine( WineId int IDENTITY PRIMARY KEY, Name nvarchar(50) NOT NULL, Category nvarchar(15) NOT NULL, Year int); CREATE TABLE Customer( CustomerId int IDENTITY PRIMARY KEY, FirstName nvarchar(50) NOT NULL, LastName nvarchar(50) NOT NULL, FavoriteWineId int, CONSTRAINT FK_Customer_Wine FOREIGN KEY (FavoriteWineId) REFERENCES Wine(WineId)); SET IDENTITY_INSERT Wine ON; INSERT Wine (WineId, Name, Category, Year) VALUES (1, 'Chateau Penin', 'Bordeaux', 2008), (2, 'McLaren Valley', 'Cabernet', 2005), (3, 'Mendoza', 'Merlot', 2010), (4, 'Valle Central', 'Merlot', 2009); SET IDENTITY_INSERT Wine OFF; SET IDENTITY_INSERT Customer ON; INSERT Customer (CustomerId, FirstName, LastName, FavoriteWineId) VALUES (1, 'Jeff', 'Hay', 4), (2, 'Mark', 'Hanson', 3), (3, 'Jeff', 'Phillips', 2); SET IDENTITY_INSERT Customer OFF;
111
112
Rozdział 5: Bezpieczeństwo i kopie zapasowe
Aby utworzyć bazę WineCloudDb, wykonaj następujące działania: 1 . Uruchom SSMS. Najprostszy sposób, aby to zrobić, to naciśnięcie klawisza
Windows, wpisanie sql server management studio na ekranie startowym i naciśnięcie Enter. 2 . W oknie dialogowym Connect To Server wykonaj następujące czynności: a . W polu Server Name wpisz .database.windows.net. Jest to w peł-
ni kwalifikowana nazwa serwera SQL Database, w której tekst zastępczy należy zastąpić nazwą przypisaną do własnego serwera. b . W polu Authentication wybierz SQL Server Authentication z listy rozwijanej (SQL Database nie wspiera uwierzytelniania Windows). c . W polach Login i Password wpisz nazwę logowania (w naszych przykładach użyliśmy loginu saz) oraz hasło przypisane podczas tworzenia serwera. d . Kliknij przycisk Connect. Serwer pojawi się jako węzeł w panelu Object Explorer. 3 . Prawym klawiszem myszy kliknij węzeł serwera w panelu Object Explorer i wybierz New Query, aby otworzyć nowe okno zapytania połączone z bazą danych master.
4 . W oknie zapytania wpisz CREATE DATABASE WineCloudDb i naciśnij F5, aby
wykonać skrypt. Na serwerze zostanie utworzona nowa baza danych WineCloudDb. 5 . Rozwiń węzeł Databases w panelu Object Explorer. Jeśli nowa baza danych nie jest
widoczna, kliknij węzeł Databases prawym klawiszem myszy i wybierz Refresh. 6 . Prawym klawiszem myszy kliknij bazę WineCloudDb i wybierz New Query, aby
otworzyć okno zapytania połączone z tą bazą danych. 7 . Wpisz kod pokazany w Listingu 5-1 (albo wklej go z pliku pobranego ze strony
powiązanej z książką). 8 . Naciśnij F5, aby wykonać skrypt. 9 . Zamknij okno zapytania (nie trzeba zapisywać zmian, chyba że chcesz zachować
treść skryptu).
Konfigurowanie zapory SQL Database W typowym wdrożeniu SQL Server serwer jest umieszczany wewnątrz zapory przedsiębiorstwa. Nie umieszczamy go w sieci brzegowej, będącą podsiecią udostępniającą usługi na zewnątrz, do większej i niezaufanej sieci. W ten sposób bazy danych SQL Server nie są dostępne spoza wewnętrznej sieci przedsiębiorstwa. Natomiast w przypadku chmury usługi mają być dostępne, zatem nie można ich ograniczać tylko do sieci wewnętrznej. Te wymagania powodują, że redukowanie potencjalnego pola ataku w chmurze jest trudniejsze, niż w przypadku standardowego SQL Server stojącego w naszej własnej serwerowni. Microsoft Azure zamyka tę dziurę, używając
Zabezpieczanie SQL Database
funkcji unikatowej dla SQL Database, nazywanej SQL Database Firewall (zaporą SQL Database). SQL Database Firewall ogranicza dostęp do baz danych SQL Database na podstawie źródłowego adresu IP połączenia. Jest to model typu opt-in, co oznacza, że domyślnie blokowane są wszystkie połączenia z SQL Database z wyjątkiem tych adresów IP, które zostały jawnie dodane jako dozwolone. Reguły można definiować dla indywidualnych adresów lub zakresów adresów IP. Reguły SQL Database Firewall pozwalają na tworzenie połączeń z serwerem SQL Database, ale nie oznacza to jeszcze autoryzacji na dostęp do obiektów wewnątrz instancji SQL Database. Po dopuszczeniu i ustanowieniu połączenia SQL Database wykonuje uwierzytelnienie użytkownika i dopiero wówczas autoryzuje dostęp do żądanych obiektów. wskazówka Oprócz reguł zapory na poziomie serwera, tworzonych przy użyciu portalu zarządzania Microsoft Azure, można skonfigurować reguły na poziomie bazy danych, używając procedury systemowej sp set database firewall rule. Więcej informacji na temat konfigurowania reguł zapory na poziomie bazy danych zawiera artykuł http://msdn.microsoft.com/en-us/library/jj553530.aspx.
Reguły zapory poziomu serwera SQL Database są przechowywane w bazie danych master i pozwalają klientom na dostęp do każdej bazy danych na tym serwerze. Reguły te można edytować bezpośrednio w bazie master albo wykorzystać do tego celu portal zarządzania Microsoft Azure. Reguła zapory składa się z nazwy, początkowego adresu IP i końcowego adresu IP. W ten sposób można utworzyć pojedynczą regułę dla wielu kolejnych adresów, na przykład całej podsieci IP. Reguła dotyczy pojedynczego adresu IP, gdy adres początkowy i końcowy są takie same.
Tworzenie niestandardowych reguł zapory Jak wspomnieliśmy, SQL Database Firewall powstrzymuje wszystkie połączenia do SQL Database, o ile nie są jawnie dozwolone przez regułę zapory. Obejmuje to wszelkie próby dostępu, również za pośrednictwem portalu zarządzania SQL Database. Oznacza to, że adres IP, którego używamy, musi zostać dołączony do reguł. Adres użyty do utworzenia serwera jest dodawany do tych reguł automatycznie, ale jeśli spróbujemy połączyć się z bazą z innego adresu IP, musimy wcześniej dodać odpowiednią regułę zapory. Wykonaj poniższe działania, aby dodać swój adres IP do reguł zapory na poziomie serwera: 1 . Zaloguj się w portalu zarządzania Microsoft Azure pod adresem https://manage.
windowsazure.com. 2 . Kliknij SQL DATABASES w pionowym panelu nawigacyjnym po lewej.
113
114
Rozdział 5: Bezpieczeństwo i kopie zapasowe
3 . Kliknij łącze SERVERS w górnej części strony. Zostanie wyświetlona lista utworzo-
nych już serwerów Microsoft Azure SQL Database, jak na rysunku 5-1.
Rysunek 5-1 Lista serwerów SQL Database w portalu zarządzania Microsoft Azure
4 . W kolumnie NAME kliknij nazwę serwera zawierającego bazę danych WineCloudDb.
Zostanie wyświetlona strona z łączami dotyczącymi wybranego serwera. 5 . Kliknij łącze CONFIGURE w górnej części strony. Pojawi się strona konfiguracji
6 . Jeśli wykonałeś już analogiczną procedurę w rozdziale 1, „Poznajemy Microsoft
Azure SQL Database” i w rozdziale 2, „Konfiguracja i ceny”, powinna być widoczna reguła nazwana ClientIPAddress_yyyy-mm-dd_hh:mm:ss, zawierająca adres IP użyty w tym czasie. Jeśli poprzednie procedury wykonałeś z innej lokalizacji, usuń regułę klikając symbol X na prawo od jej nazwy (symbol X pojawia się tylko po umieszczeniu kursora myszy nad nazwą reguły). 7 . W sekcji Allowed IP Addresses (dozwolone adresy IP) powinien pojawić się aktual-
nie używany adres IP obok wpisu CURRENT CLIENT IP ADDRESS. Kliknij łącze ADD TO THE ALLOWED IP ADDRESSES (dodaj dozwolone adresy IP) po prawej stronie, aby utworzyć nową regułę. Po tej zmianie będziemy mogli połączyć się z serwerem SQL Database z aktualnego adresu IP. Oczywiście, jeśli używany adres IP jest tym samym, którym posługiwaliśmy się w rozdziałach 1 i 2, nowa reguła będzie identyczna z usuniętą w poprzednim kroku. W takiej sytuacji ćwiczenie to ma na celu tylko zademonstrowanie, jak usunąć regułę. Nowe reguły zapory nie są aktywne, dopóki nie klikniemy przycisku SAVE w dolnej części strony. Zanim to zrobimy, dodamy inną regułę, pozwalającą na dostęp z alternatywnej lokalizacji (na przykład z domu). Aby utworzyć taką regułę, wykonaj poniższe działania: 1 . W polu RULE NAME (nazwa reguły) poniżej listy istniejących reguł wpisz opiso-
wą nazwę reguły, na przykład Home Office (biuro domowe). Trzeba zauważyć, że nazwa ta nie może zawierać znaków ukośnika (/) ani odwrotnego ukośnika (\) i nie może kończyć się kropką (.). 2 . W polach START IP ADDRESS i END IP ADDRESS wpisz zakres adresów IP dla biura
domowego (aby wprowadzić pojedynczy adres IP, wpisz ten sam adres w obydwu polach). Strona powinna wyglądać podobnie, jak na rysunku 5-3. 3 . Kliknij przycisk SAVE w dolnej części strony.
Reguły zapory zostały zaktualizowane. Przed wykonaniem tej procedury próba połączenia z serwerem SQL Database z domowego adresu (lub adresów) IP zostałaby zablokowana bez względu na użyte narzędzie, takie jak SQL Server Management Studio (SSMS), SQL Server Data Tools (SSDT), własna aplikacja wykorzystująca ADO.NET lub Entity Framework, a nawet sam portal zarządzania SQL Database.
115
116
Rozdział 5: Bezpieczeństwo i kopie zapasowe
Rysunek 5-3 Nowe reguły zapory dla bieżącej lokalizacji i biura domowego
Zezwalanie na dostęp usług Microsoft Azure Jeśli zechcemy, usługi Microsoft Azure również mogą mieć zablokowany dostęp do naszego serwera SQL Database. Ustalanie adresów IP, z których mogą pochodzić żądania generowane przez usługi Microsoft Azure, mogłoby być trudne i niewygodne, zatem SQL Database udostępnia funkcjonalność włączania (lub wyłączania) blokowania żądań z innych usług Azure bez potrzeby znajomości adresów IP powiązanych z tymi żądaniami. Jeśli zezwolimy usługom Azure na dostęp do serwera SQL Database poprzez tę funkcję, wszystkie usługi Azure będą mogły łączyć się z serwerem poprzez zaporę. Nadal jednak będą musiały się uwierzytelnić i uzyskać autoryzację w naszym serwerze, zanim będą mogły zrobić cokolwiek w bazie danych. Podczas tworzenia serwera można zauważyć pole wyboru, którego zaznaczenie pozwala usługom Microsoft Azure na dostęp do nowego serwera SQL Database (użyliśmy tego pola wyboru w rozdziale 1; patrz rysunek 1-5). Pole to jest domyślnie zaznaczone. Po utworzeniu serwera można łatwo przełączyć to ustawienie i zezwolić lub zablokować dostęp usług Azure przez zaporę, klikając odpowiednio opcję YES lub NO obok wpisu WINDOWS AZURE SERVICES poniżej tytułu Allowed Services (dozwolone usługi) w dolnej części strony reguł zapory (patrz rysunek 5-3). Zezwolenie na dostęp usług Microsoft Azure powoduje utworzenie nowej reguły zapory z zakresem adresów IP od 0.0.0.0 do 0.0.0.0. Ten „specjalny” zakres zezwala
Zabezpieczanie SQL Database
na dostęp wszystkich usług Microsoft Azure. Jednak reguła ta nie jest wyświetlana na stronie konfiguracji zapory, choć można sprawdzić jej istnienie w bazie danych master. W interfejsie użytkownika portalu zarządzania Microsoft Azure obecność (lub nieobecność) tej reguły jest sygnalizowana poprzez zaznaczenie opcji YES lub NO dla WINDOWS AZURE SERVICES. Jako uzupełnienie zarządzania regułami zapory na poziomie serwera poprzez portal zarządzania Microsoft Azure, jak to właśnie pokazaliśmy, można wykorzystać mechanizm SQL Database Management REST API do modyfikowania ustawień zapory z poziomu aplikacji lub skryptu (REST API omówimy w rozdziale 8, „Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności”).
Uwierzytelnianie i autoryzowanie użytkowników Gdy połączenie klienckie zostanie dopuszczone przez zaporę serwera, SQL Database musi wykonać sprawdzenie poświadczeń i zalogować użytkownika. SQL Database zarządza i uwierzytelnia użytkowników przy użyciu mechanizmu uwierzytelniania SQL Server, podobnie jak zwykły SQL Server. Jednak w przeciwieństwie do SQL Server nie jest obsługiwany mechanizm uwierzytelniania Windows. (Więcej informacji na temat różnic pomiędzy Microsoft Azure SQL Database a SQL Server zawiera rozdział 3). Gdy Microsoft Azure tworzy serwer SQL Database, jest w nim tworzona (między innymi) baza danych master. Jedną z funkcjonalności, za którą odpowiedzialna jest baza master, jest zarządzanie loginami SQL Database. Wstępny login tworzony jest dla nazwy użytkownika i hasła podanego podczas tworzenia serwera SQL Database (w naszych przykładach używaliśmy nazwy saz). Ten użytkownik staje się podmiotem administracyjnym na poziomie serwera, analogicznym do użytkownika sa w SQL Server. Można użyć tego loginu do łączenia się z serwerem SQL Database z naszych aplikacji, ale takie działanie zdecydowanie nie jest dobrą praktyką, gdyż login ten ma pełne uprawnienia dla każdej bazy danych i nie moglibyśmy wprowadzić kontroli dostępu. Aby móc ograniczyć dostęp i osiągnąć bardziej szczegółową kontrolę, musimy utworzyć nowych użytkowników SQL Database i odpowiadające im loginy.
Tworzenie loginów SQL Database Aby utworzyć nowy login i użytkownika w SQL Server, można wykorzystać graficzny interfejs udostępniany przez SQL Server Management Studio. Niestety, te okna dialogowe i formularze nie są dostępne, gdy SSMS jest połączony z serwerem SQL Database. W rezultacie konieczne jest bezpośrednie wywołanie poleceń T-SQL wewnątrz okna zapytania.
117
118
Rozdział 5: Bezpieczeństwo i kopie zapasowe
Wykonaj poniższe działania, aby utworzyć nowy login na serwerze SQL Database: 1 . Uruchom SSMS. W tym celu naciśnij klawisz Windows, wpisz sql server mana-
gement studio na ekranie startowym i naciśnij Enter. 2 . W oknie dialogowym Connect To Server wpisz odpowiednie poświadczenia,
jak na rysunku 5-4. Upewnij się, że wybrałeś serwer zawierający bazę danych WineCloudDb. Przypomnijmy, że nazwa serwera musi być uzupełniona sufiksem .database.windows.net i trzeba podać login wybrany podczas tworzenia serwera (w naszym przykładzie jest to nazwa saz).
Rysunek 5-4 Okno dialogowe Connect To Server w SQL Server Management Studio
3 . Kliknij przycisk Connect. 4 . Po ustanowieniu połączenia serwer SQL Database pojawi się w panelu Object Explorer. Kliknij nazwę serwera prawym klawiszem myszy i wybierz polecenie New Query, jak na rysunku 5-5. Zostanie otwarte nowe okno zapytania połączone
z bazą master.
Rysunek 5-5 Otwieranie okna zapytania dla bazy danych master
Uwaga Tekst zastępczy należy zastąpić silnym hasłem dla nowego loginu. Hasło to musi spełniać wymagania określone przez zasady haseł. Więcej informacji na temat zasad silnych haseł zawiera artykuł http://msdn.microsoft.com/en-us/library/ ms161962.aspx.
6 . Naciśnij F5 (lub kliknij przycisk Execute w pasku narzędzi), aby wykonać
polecenie. Utworzyliśmy już nowy login serwera SQL Database; jednak na razie login ten nie jest autoryzowany do realizowania jakichkolwiek działań na serwerze. Kolejnym krokiem będzie utworzenie użytkownika dla tego loginu i przyznanie mu uprawnień na poziomie serwera lub bazy danych.
Przyznawanie uprawnień na poziomie serwera SQL Database zawiera dwie role zabezpieczeń poziomu serwera, loginmanager oraz dbmanager, opisane w tabeli 5-1. Role te pozwalają użytkownikom innym niż administrator serwera zarządzać zabezpieczeniami i bazami danych. Użytkownik musi zostać utworzony dla istniejącego loginu w bazie danych master, aby możliwe było przypisanie mu jednej z ról poziomu serwera. Tabela 5-1 Role poziomu serwerowego w SQL Database Rola
Opis
loginmanager
Rola ta ma uprawnienia do tworzenia loginów na serwerze SQL Database i jest analogiczna do roli securityadmin w SQL Server.
dbmanager
Rola ta ma uprawnienia do tworzenia baz danych na serwerze SQL Database, analogicznie do roli dbcreator w SQL Server.
Podobnie jak w przypadku tworzenia i modyfikowania loginów, zarządzanie użytkownikami i przypisywanie do ról trzeba wykonywać poprzez skrypty T-SQL, gdyż graficzny interfejs użytkownika w SQL Server Management Studio nie jest dostępny przy łączeniu się z serwerem SQL Database. Wykorzystując to samo okno zapytania, którego użyliśmy w poprzedniej procedurze, wykonaj poniższe działania, aby utworzyć nowego użytkownika z uprawnieniami na poziomie serwera: 1 . Usuń z okna zapytania kod T-SQL pozostały po poprzedniej procedurze. 2 . Wpisz poniższe wyrażenia T-SQL w oknie zapytania:
119
120
Rozdział 5: Bezpieczeństwo i kopie zapasowe
CREATE USER WineCloudDbUser FROM LOGIN WineCloudDbLogin GO EXEC sp_addrolemember 'loginmanager', 'WineCloudDbUser' EXEC sp_addrolemember 'dbmanager', 'WineCloudDbUser'
3 . Naciśnij F5 (lub kliknij przycisk Execute w pasku narzędzi), aby wykonać skrypt.
Kod ten tworzy nowego użytkownika o nazwie WineCloudDbUser, powiązanego z loginem WineCloudDbLogin utworzonym w poprzedniej procedurze i dodaje nowego użytkownika do ról loginmanager oraz dbmanager. Utworzyliśmy nowego użytkownika o nazwie WineCloudDbUser w bazie danych master i przyznaliśmy temu użytkownikowi uprawnienia do zarządzania loginami i bazami danych na poziomie całego serwera SQL Database. W ten sposób będziemy mogli delegować innym osobom uprawnienia do zarządzania serwerem bez konieczności przekazywania im poświadczeń administracyjnych.
Przyznawanie uprawnień na poziomie bazy danych Jednym z głównych celów, dla których trzeba zajmować się zabezpieczeniami, jest zminimalizowanie obszaru potencjalnie narażonego na zewnętrzne ataki. Jedną z podstawowych zasad związanych z tym problemem jest zasada najmniejszych przywilejów, co oznacza w praktyce przyznawanie takiego poziomu dostępu, który wystarcza na wykonywanie ich zadań, ale ani odrobiny więcej. W ten sposób zminimalizowany jest dostęp użytkowników, co z kolei zmniejsza ogólny obszar systemu podatny na atak. Przy korzystaniu z SQL Database nie będziemy chcieli przyznawać wszystkim użytkownikom uprawnień na poziomie serwera; zamiast tego należy dać im jedynie takie uprawnienia, które pozwolą im wykonać swoją pracę. Na przykład, jeśli mamy aplikację, która musi jedynie odczytywać dane z bazy, nie powinniśmy dawać użytkownikowi wykorzystywanemu przez tę aplikację uprawnienia do zapisu danych. W takiej sytuacji należy utworzyć nowego użytkownika, który będzie miał tylko uprawnienia odczytu z bazy danych. Oznacza to utworzenie nowego loginu w bazie master i następnie nowego użytkownika powiązanego z tym loginem w bazie WineCloudDb. W celu utworzenia nowego użytkownika z prawami tylko do odczytu należy wykonać poniższą procedurę: 1 . Usuń kod T-SQL, który pozostał w oknie zapytania z poprzedniej procedury
(przypomnijmy, że to okno jest cały czas połączone z bazą danych master). 2 . Wpisz poniższe wyrażenie T-SQL w oknie zapytania: CREATE LOGIN WineCloudDbReadonlyLogin WITH PASSWORD=''
Uwaga Ponownie należy zastąpić zwrot silnym hasłem dla nowego loginu.
Zabezpieczanie SQL Database
3 . Naciśnij F5 (lub kliknij przycisk Execute w pasku narzędzi), aby wykonać pole-
cenie. Kod ten utworzy nowy login o nazwie WineCloudDbReadonlyLogin w bazie master. 4 . W panelu Object Explorer rozwiń węzeł Databases, aby ujawnić listę baz danych
na serwerze (powinna ona zawierać bazę danych WineCloudDb). 5 . Prawym klawiszem myszy kliknij bazę WineCloudDb i wybierz New Query, jak
na rysunku 5-6. Spowoduje to otwarcie nowego okna zapytania, połączonego z bazą WineCloudDb.
Rysunek 5-6 Otwieranie okna zapytania dla bazy danych WineCloudDb
6 . Wpisz poniższe wyrażenia T-SQL w nowym oknie zapytania połączonym z bazą
WineCloudDb, a następnie wykonaj skrypt: CREATE USER WineCloudDbReadonlyUser FROM LOGIN WineCloudDbReadonlyLogin GO EXEC sp_addrolemember 'db_datareader', 'WineCloudDbReadonlyUser'
Wyrażenia te utworzą nowego użytkownika dla wcześniej przygotowanego loginu w bazie danych WineCloudDb i przyznają temu użytkownikowi uprawnienia do odczytywania danych. Przypisywanie uprawnień na poziomie bazy danych pozwala wybrać najmniejsze niezbędne uprawnienia użytkowników.
Łączenie się z serwerem SQL Database przy użyciu uprawnień na poziomie bazy danych W poprzedniej procedurze utworzyliśmy w SQL Database login o nazwie WineCloudDbReadonlyLogin i powiązanego z nim użytkownika WineCloudDbReadonlyUser, który ma przyznane tylko uprawnienia do odczytu w bazie WineCloudDb. Loginu tego można użyć w niestandardowej aplikacji łączącej się z bazą danych, ale można sobie też wyobrazić sytuację, gdy chcemy przyznać programiście dostęp do bazy danych tylko do odczytu, aby mógł zdiagnozować jakiś problem. W tym drugim scenariuszu
121
122
Rozdział 5: Bezpieczeństwo i kopie zapasowe
jest bardzo prawdopodobne, że programista ten będzie chciał użyć SSMS. Jednak jeśli spróbuje połączyć się z bazą danych przy użyciu WineCloudDbReadonlyLogin, SSMS wyświetli komunikat o błędzie pokazany na rysunku 5-7.
Rysunek 5-7 Komunikat błędu informujący, że użyty login nie ma dostępu do bazy master.
Błąd ten wynika z faktu, że domyślnie SSMS próbuje uzyskać dostęp do bazy master podczas łączenia, ale użyty login nie ma żadnych uprawnień w tej bazie – ma jedynie prawo do odczytu w bazie WineCloudDb. Rozwiązaniem jest użycie zaawansowanej wersji okna dialogowego Connect To Server, które pozwala wyspecyfikować konkretną bazę danych, z którą chcemy się połączyć – inną niż master, którą w naszym przypadku będzie WineCloudDb. Aby użyć zaawansowanego okna dialogowego Connect To Server w SSMS, wykonaj następujące działania: 1 . Jeśli zamknąłeś narzędzie SSMS po poprzedniej procedurze, uruchom je ponow-
nie, aby wyświetlić okno dialogowe Connect To Server. Jeśli SSMS jest nadal uruchomione, kliknij Connect | Database Engine (połącz | silnik bazy danych) w menu paska narzędzi panelu Object Explorer (rysunek 5-8), aby wywołać okno dialogowe Connect To Server.
Rysunek 5-8 Łączenie się z komponentem Database Engine w panelu Object Explorer
Zabezpieczanie SQL Database
2 . W polu Server name wpisz nazwę serwera SQL Database, który zawiera bazę
danych WineCloudDb (pamiętaj, aby dodać sufiks .database.windows.net). 3 . W polu Authentication wybierz SQL Server Authentication. 4 . W polu Login wpisz WineCloudDbReadonlyLogin. 5 . W polu Password wpisz hasło przypisane do tego loginu w poprzedniej procedurze. 6 . Kliknij przycisk Options w prawym dolnym rogu okna. Zmieni to okno dialogowe Connect To Server w jego rozbudowaną wersję, zawierającą również pole tekstowe Connect To Database (połącz z bazą danych), w której można wprowadzić nazwę
bazy inną niż master. 7 . W polu Connect To Database wpisz WineCloudDb, jak na rysunku 5-9.
Rysunek 5-9 Zaawansowana wersja okna dialogowego Connect To Server pozwala wskazać wybraną bazę danych dla połączenia.
8 . Kliknij przycisk Connect. Tym razem nie pojawi się komunikat błędu, ale SSMS
połączy się z powodzeniem z bazą danych. Połączyliśmy się z bazą danych WineCloudDb w narzędziu SSMS, używając ograniczonego konta, które ma jedynie uprawnienie db_datareader. Jak wyjaśniliśmy, może to być przydatne, jeśli na przykład chcemy dać członkowi zespołu dostęp tylko do odczytu do produkcyjnej bazy danych w celu zdiagnozowania problemów lub wykonania jakiś analiz danych.
123
124
Rozdział 5: Bezpieczeństwo i kopie zapasowe
Microsoft Azure SQL Database udostępnia funkcje zabezpieczeń, które obejmują zaporę oraz role na poziomie serwera. Można również zabezpieczać obiekty SQL przy użyciu ról poziomu bazy danych i uprawnień – tak samo jak w SQL Server. Pozwala to na stosowanie się do zasady najniższych przywilejów i przyznawania użytkownikom tylko tych uprawnień, których faktycznie potrzebują – nie większych, ale i nie mniejszych. Pozwala to zredukować potencjalną powierzchnię ataku i pomaga w zarządzaniu zabezpieczeniami. Dobrą praktyką jest stosowanie się do tej zasady już na etapie projektowania aplikacji, które będą łączyć się z bazą SQL Database, a następnie udostępnić innym członkom zespołu poświadczenia dla SQL Database, których będą mogli użyć w celu budowania rozwiązań, rozwiązywania problemów i analiz.
Tworzenie kopii zapasowej SQL Database Niewygodna prawda brzmi, że awarie i inne katastrofy się zdarzają i przychodzą w różnych postaciach i rozmiarach. Taka katastrofa może być wynikiem złośliwego ataku, wyłączenia usługi lub czegoś tak prostego, jak błędny kod, który usunął lub uszkodził dane. Gdy awaria już nastąpi, musimy być w stanie ją naprawić i przywrócić działanie naszego biznesu. Zapewnienie dobrej ciągłości działania i plan przywracania po awarii jest kluczem do udanego poradzenia sobie z katastrofą, gdy już nastąpi. Jednym z podstawowym elementów planu przywracania po awarii są kopie zapasowe. Poza przywracaniem po awariach, kopie zapasowe są powszechnie wykorzystywane do tworzenia nowych środowisk i rozwiązywania problemów, które mogą wystąpić tylko w określonym środowisku. Gdy projektanci po raz pierwszy stykają się z Microsoft Azure SQL Database, często mylnie sądzą, że kopie zapasowe nie są już potrzebne, gdyż SQL Database udostępnia domyślnie funkcjonalność wysokiej dostępności. Potrzeba kopii zapasowych jest zbliżona, ale różni się od wymagania wysokiej dostępności. Możliwości wysokiej dostępności pomagają zagwarantować, że nasza baza danych będzie dostępna, gdy wystąpi niewielka przerwa w działaniu infrastruktury – na przykład gdy występuje nadmierne obciążenie serwera lub gdy serwer ten wymaga restartu ze względu na rutynową procedurę konserwacyjną. Wysoka dostępność nie pomoże jednak, jeśli coś nieoczekiwanego spowoduje usunięcie lub uszkodzenie bazy danych, gdyż zmiany te zostaną zreplikowane w innych węzłach klastra wysokiej dostępności. Tak więc, potrzebujemy strategii tworzenia kopii zapasowych i przywracania pomimo wbudowanych funkcji wysokiej dostępności, zapewnianych przez SQL Database. Proces tworzenia i przywracania kopii zapasowych w Microsoft Azure SQL Database różni się od tego, który znamy z SQL Server, gdyż tradycyjne wyrażenia T-SQL BACKUP oraz RESTORE nie są tu obsługiwane. Zamiast tradycyjnych kopii zapasowych znanych z SQL Server, w tej roli wykorzystywane są pliki BACPAC.
Tworzenie kopii zapasowej SQL Database
Kopiowanie bazy danych Przy tworzeniu kopii zapasowych transakcyjnego systemu bazodanowego, takiego jak SQL Database lub SQL Server, istotne jest zachowanie spójności transakcyjnej. Pliki BACPAC nie zapewniają jej, gdyż mechanizm ten kopiuje tabele indywidualnie i w czasie pomiędzy skopiowaniem pierwszej i ostatniej tabeli mogą powstać jakieś modyfikacje. Tak więc pierwszą rzeczą, którą trzeba zrobić, gdy przystępujemy do tworzenia kopii zapasowych serwera SQL Database, jest utworzenie statycznego (nieaktywnego) duplikatu bazy danych przy użyciu funkcji Database Copy (kopia bazy danych). Funkcja Database Copy tworzy nową bazę danych na podstawie istniejącej bazy SQL Database. Kopia ta jest spójna transakcyjnie po zakończeniu kopiowania, gdyż wszystkie zmiany, jakie nastąpiły w źródłowej bazie w czasie trwania kopiowania, są replikowane do bazy docelowej na końcu procesu. Kopie bazy danych można tworzyć na tym samym serwerze SQL Database bądź na innym serwerze zlokalizowanym w tym samym regionie. W celu skopiowania bazy danych WineCloudDb wykonaj poniższe działania: 1 . W narzędziu SSMS połącz się z serwerem SQL Database zawierającym bazę danych
WineCloudDb, używając loginu administracyjnego zadeklarowanego podczas tworzenia serwera (w naszych przykładach login ten nosi nazwę saz). Po nawiązeniu połączenia serwer pojawi się w panelu Object Explorer po lewej. 2 . Prawym klawiszem myszy kliknij nazwę serwera i wybierz polecenie New Query.
Pojawi się nowe okno zapytania połączone z bazą danych master. 3 . Wpisz poniższe wyrażenie T-SQL w oknie kodu: CREATE DATABASE WineCloudDbCopy AS COPY OF WineCloudDb
4 . Naciśnij F5 (lub kliknij przycisk Execute w pasku narzędzi), aby wykonać pole-
cenie. Powoduje ono rozpoczęcie kopiowania bazy WineCloudDb do nowej bazy o nazwie WineCloudDbCopy. W ten sposób rozpoczęliśmy wykonywanie kopii zapasowej naszej bazy danych. W tej procedurze utworzyliśmy kopię bazy źródłowej na tym samym serwerze SQL Database, ale moglibyśmy wybrać inny serwer, o ile tylko będzie on zlokalizowany w tym samym regionie Microsoft Azure, co źródłowy. W tym celu należy wywołać polecenie CREATE DATABASE w oknie zapytania połączonym z bazą master na serwerze docelowym, dodając prefiks nazwy serwera do nazwy źródłowej bazy w wyrażeniu CREATE DATABASE…AS COPY OF – jak w poniższym przykładzie: CREATE DATABASE WineCloudDbCopy AS COPY OF muea4g022x.WineCloudDb
125
126
Rozdział 5: Bezpieczeństwo i kopie zapasowe
Monitorowanie postępów operacji kopiowania bazy danych Gdy wywołamy polecenie CREATE DATABASE…AS COPY OF, bardzo szybko zwracany jest komunikat o sukcesie lub niepowodzeniu. Jednak kopiowanie bazy danych jest procesem asynchronicznym i zwracany rezultat polecenia nie jest w rzeczywistości wynikiem kopiowania bazy danych – jest to po prostu wynik rozpoczęcia operacji asynchronicznego kopiowania. Faktyczny status operacji kopiowania przebiegającej w tle można ustalić, odpytując widoki systemowe sys.databases oraz sys.dm_database_copies. W czasie, gdy baza jest kopiowana, kolumna state_desc widoku sys.databases będzie zawierała wartość COPYING (kopiowanie). Jeśli proces kopiowania zostanie przerwany z powodu błędu, kolumna state_desc zwróci SUSPECT (podejrzana). W przypadku kopiowania zakończonego sukcesem wartością tej kolumny będzie ONLINE. Nowa baza docelowa jest tworzona we wczesnej fazie procesu kopiowania. Jeśli wystąpi jakiś błąd w dowolnym momencie podczas kopiowania, baza ta będzie w niekompletnym stanie i trzeba będzie ją usunąć przy użyciu polecenia DROP DATABASE. W ten sam sposób (wykonując polecenie DROP DATABASE wobec nowej bazy docelowej) można anulować wcześniej wywołaną operację kopiowania. Wykonaj poniższe działania, aby monitorować postęp kopiowania bazy danych: 1 . W narzędziu SSMS połącz się z serwerem SQL Database, zawierającym bazę
WineCloudDbCopy utworzoną w poprzedniej procedurze, używając loginu administracyjnego. 2 . Prawym klawiszem myszy kliknij nazwę serwera i wybierz polecenie New Query.
Pojawi się nowe okno zapytania połączone z bazą master. 3 . Wpisz poniższe wyrażenie T-SQL w oknie kodu: SELECT name, state_desc FROM sys.databases WHERE name = 'WineCloudDbCopy'
4 . Naciśnij F5 (lub kliknij przycisk Execute w pasku narzędzi), aby wykonać zapy-
tanie. Wynikiem będzie status nowej bazy odczytany z widoku sys.databases, co pokazuje rysunek 5-10. Oczywiście, jeśli odczekamy dostatecznie dużo czasu, aby operacja kopiowania wywołana w poprzedniej procedurze zdążyła się zakończyć, kolumna state_desc będzie zgłaszać status ONLINE, a nie COPYING. Dodatkowe szczegóły operacji kopiowania (data i godzina rozpoczęcia, procentowe wykonanie, informacje o błędach i tak dalej) można uzyskać, złączając widok sys.databases z widokiem sys.dm_database_copies na podstawie kolumny database_id, jak w poniższym przykładzie: SELECT * FROM sys.dm_database_copies AS c INNER JOIN sys.databases AS d
Tworzenie kopii zapasowej SQL Database
ON c.database_id = d.database_id WHERE d.name = 'WineCloudDbCopy'
Rysunek 5-10 Wyniki zapytania do widoku sys.databases wykonanego w czasie operacji kopiowania bazy danych
Uwaga Widok sys.dm database copies zwróci jakikolwiek rezultat jedynie wtedy, gdy operacja kopiowania jeszcze trwa. Po zakończeniu kopiowania widok ten nie zwróci żadnych wyników.
Możliwości monitorowania operacji kopiowania bazy danych udostępnia również portal zarządzania Microsoft Azure, co pokazuje rysunek 5-11.
Rysunek 5-11 Portal zarządzania Microsoft Azure pokazuje status bazy danych w trakcie operacji kopiowania.
127
128
Rozdział 5: Bezpieczeństwo i kopie zapasowe
Po zakończeniu operacji kopiowania uzyskamy transakcyjnie spójny duplikat naszej bazy danych i będziemy mogli wyeksportować go jako plik BACPAC.
Eksportowanie pliku BACPAC Jak pokazywaliśmy już w rozdziale 4, „Migrowanie baz danych”, SQL Database udostępnia funkcjonalność importu i eksportu plików BACPAC, co umożliwia łatwą migrację bazy danych pomiędzy SQL Server a SQL Database. Te same możliwości zapewniają prostą i niezawodną metodę tworzenia kopii zapasowych i przywracania baz danych w SQL Database (przy założeniu, że najpierw utworzymy transakcyjnie spójną kopię). Usługą magazynową Microsoft Azure, którą wykorzystamy do przechowania plików BACPAC, jest Microsoft Azure Blob Storage. Jest to usługa zaprojektowana do przechowywania plików binarnych o bardzo wielkich rozmiarach. Usługa obsługuje dwa typy plików blob: blokowe (block blobs) oraz stronicowe (page blobs), przy czym każdego z nich można użyć do przechowywania plików BACPAC. W chwili pisania tych słów maksymalny rozmiar blokowego obiektu wynosił 200 gigabajtów (GB), zaś obiektu stronicowego jeden terabajt (TB). Blob Storage jest idealną usługą dla przechowywania plików BACPAC. Aby móc użyć funkcjonalności eksportu w SQL Database, potrzebne jest konto magazynowe Microsoft Azure Storage. Jeśli Czytelnik nie utworzył jeszcze konta magazynowego, należy powrócić do rozdziału 4 i wykonać procedurę opisaną w podrozdziale „Tworzenie konta w Microsoft Azure Storage”. Wykonaj poniższe kroki, aby wyeksportować plik BACPAC do swojego konta magazynowego (w naszych przykładach jest to konto mywinestorage): 1 . Zaloguj się w portalu Microsoft Azure pod adresem https://manage.windowsazu-
re.com. Zostaniesz przekierowany do strony głównej prezentującej ALL ITEMS. 2 . Kliknij SQL DATABASES w pionowym panelu nawigacyjnym po lewej. 3 . Kliknij bazę danych WineCloudDbCopy (spójną transakcyjnie kopię bazy
WineCloudDb utworzoną w poprzedniej procedurze). 4 . Kliknij przycisk EXPORT w dolnej części strony, aby wyświetlić okno dialogowe Export Database Settings (ustawienia eksportu bazy danych).
5 . W polu FILENAME można pozostawić domyślną nazwę przypisaną przez portal
(WineCloudDbCopy uzupełnioną o bieżącą datę i czas), ale można też wpisać własną, wybraną nazwę dla pliku BACPAC. 6 . W polu BLOB STORAGE ACCOUNT wybierz swoje konto magazynowe z listy rozwi-
janej albo wybierz polecenie Create A New Storage Account (utwórz nowe konto magazynowe), aby utworzyć nowe konto w locie. Po wybraniu konta pojawi się lista rozwijana CONTAINER (kontener).
Tworzenie kopii zapasowej SQL Database
wskazówka Zalecaną praktyką jest umieszczanie konta magazynowego w tym samym regionie Microsoft Azure, w którym zlokalizowany jest serwer SQL Database. W ten sposób unikamy dodatkowych kosztów związanych z transferem danych pomiędzy regionami i poprawia się wydajność kopiowania. Więcej informacji na temat cen SQL Database i zalecanych praktyk zawiera rozdział 2.
7 . Na liście CONTAINER można wybrać z listy rozwijanej istniejący już kontener
(na przykład kontener dbimport utworzony w rozdziale 4) albo utworzyć nowy. W tym ćwiczeniu wybierz Create A New Container (utwórz nowy kontener) z listy rozwijanej. 8 . W polu NEW CONTAINER NAME wpisz dbbackups. 9 . Pole SERVER LOGIN NAME powinno być automatycznie wypełnione nazwą użyt-
kownika administracyjnego na serwerze (saz w naszych przykładach). 10 . W polu SERVER LOGIN PASSWORD wpisz hasło dla loginu administracyjnego. Okno
dialogowe Export Database Settings powinno wyglądać podobnie do pokazanego na rysunku 5-12.
Rysunek 5-12 Okno Export Database Settings w portalu zarządzania Microsoft Azure
129
130
Rozdział 5: Bezpieczeństwo i kopie zapasowe
11 . Kliknij ikonę zatwierdzenia w prawym dolnym rogu okna dialogowego, aby roz-
począć eksport bazy danych. Po zakończeniu tego procesu w dolnej części pojawi się komunikat potwierdzający sukces. Wyeksportowaliśmy właśnie bazę danych WineCloudDbCopy do pliku BACPAC zlokalizowanego w usłudze Blob Storage. Plik ten stanowi przenośną kopię zapasową naszej bazy danych, którą można zarchiwizować lub odtworzyć w innej instancji SQL Database w Microsoft Azure albo w lokalnej instalacji SQL Server we własnej serwerowni. Wyeksportowany plik można pobrać za pośrednictwem portalu Microsoft Azure lub przy użyciu odrębnego (innej firmy) oprogramowania klienckiego.
Importowanie pliku BACPAC Tworzenie kopii zapasowej nie jest zbyt cenne, jeśli nie będziemy umieli wykonać przywracania tej kopii. W SQL Database przywracanie bazy danych z pliku BACPAC jest łatwe dzięki funkcji Import Database. Aby zaimportować utworzony plik BACPAC, wykonaj poniższe działania: 1 . Jeśli zamknąłeś portal zarządzania Microsoft Azure po poprzedniej procedurze,
zaloguj się ponownie pod adresem https://manage.windowsazure.com. Pojawi się główna strona portalu. 2 . Kliknij SQL DATABASES w panelu nawigacyjnym po lewej. 3 . Kliknij przycisk NEW w dolnej części strony. 4 . Kliknij IMPORT, jak na rysunku 5-13. Zostanie wyświetlone okno dialogowe IMPORT DATABASE.
Rysunek 5-13 Odtwarzanie bazy danych przy użyciu opcji importu w portalu zarządzania
Tworzenie kopii zapasowej SQL Database
5 . Kliknij ikonę folderu na lewo od pola tekstowego BACPAC URL. Pojawi się okno
dialogowe BROWSE CLOUD STORAGE (przeglądanie magazynu w chmurze). 6 . W lewej części okna wyświetlane jest drzewo eksploratora, ukazujące konta
Microsoft Azure Storage i zawarte w nich kontenery. Rozwiń węzeł konta użytego w poprzedniej procedurze eksportu (mywinestorage w naszym przykładzie), aby wyświetlić zawarte w nim kontenery. 7 . Kliknij kontener dbbackups użyty w procedurze eksportu, aby pokazać jego zawar-
tość. Powinieneś zobaczyć plik BACPAC, jak na rysunku 5-14.
8 . Kliknij plik BACPAC, aby go zaznaczyć. 9 . Kliknij przycisk Open. Ponownie pojawi się okno dialogowe IMPORT DATABASE
z wypełnionym już polem adresu BACPAC URL. 10 . W polu NAME zmień nazwę bazy danych na WineCloudDbRestored. 11 . W polu SERVER wybierz z listy rozwijanej dowolny dostępny serwer, który
ma przechować odtworzoną bazę danych (należy pamiętać, że serwer ten powinien znajdować się w tym samym regionie, co konto magazynowe, aby uniknąć ponoszenia kosztów transferu danych pomiędzy regionami). W tym ćwiczeniu po prostu odtworzymy plik BACPAC na tym samym serwerze, z którego wyeksportowaliśmy bazę WineCloudDbCopy, ale można wybrać inny już istniejący serwer z listy. Alternatywnie można wybrać opcję New SQL Database Server i utworzyć
131
132
Rozdział 5: Bezpieczeństwo i kopie zapasowe
nowy serwer w trakcie operacji. Po wybraniu serwera pojawią się pola tekstowe SERVER LOGIN NAME oraz SERVER LOGIN PASSWORD, przy czym pole SERVER LOGIN NAME jest automatycznie wypełniane nazwą logowania konta administracyjnego. 12 . W polu SERVER LOGIN PASSWORD wpisz hasło dla tego loginu. Okno dialogowe IMPORT DATABASE powinno wyglądać podobnie do pokazanego na rysunku 5-15.
Rysunek 5-15 Importowanie pliku BACPAC z magazynu Microsoft Azure Storage do nowej bazy danych na serwerze SQL Database Uwaga Domyślnie baza danych zaimportowana z pliku .bacpac tworzona jest jako wydanie Web o wielkości do 1 GB. Jeśli wymagana jest większa baza danych, należy zaznaczyć pole wyboru CONFIGURE ADVANCED DATABASE SETTINGS w dolnej części okna dialogowego. Konwertuje ono proste okno IMPORT DATABASE na dwustronicowy kreator, w którym można dokonać wyboru wydania i rozmiaru bazy danych SQL Database. Więcej informacji zawiera podrozdział „Konfigurowanie wydania i rozmiaru bazy danych” w rozdziale 2.
13 . Kliknij ikonę zatwierdzenia w prawym dolnym rogu okna dialogowego, aby rozpo-
cząć import. Po zakończeniu operacji w dolnej części strony pojawi się komunikat o sukcesie, a na liście baz danych pojawi się nowa pozycja WineCloudDbRestored.
Tworzenie kopii zapasowej SQL Database
Utworzyliśmy nową bazę danych, importując wcześniej wyeksportowany plik BACPAC. Zwróćmy uwagę, że można odtworzyć plik kopii zapasowej na dowolnym serwerze SQL Database, w tym na serwerze należącym do innej subskrypcji, przesyłając ten plik do konta magazynowego tej subskrypcji.
Tworzenie harmonogramu eksportowania BACPAC Przedstawione dotąd techniki pozwalają na ręczne eksportowanie i importowanie plików BACPAC. W ten sposób można łatwo utworzyć migawkę bazy danych przed wykonaniem jakiś modyfikacji lub odtworzeniem jej w innym środowisku. Zazwyczaj jednak będziemy chcieli, aby kopie zapasowe były tworzone w regularnych odstępach czasu, według spójnego harmonogramu. Możemy to zrealizować, tworząc harmonogram automatycznych kopii zapasowych przy użyciu funkcjonalności Automated Export (automatycznego eksportu). Funkcja ta jest obecnie dostępna jako Preview (wersja wstępna) i nie ma jeszcze statusu ogólnie dostępnej (Generally Available – GA), co oznacza, że nie zapewnia tego samego poziomu gwarancji i wsparcia, jak funkcje sklasyfikowane jako GA. Jest także bezpłatna, co również może się zmienić, gdy status zmieni się z Preview na GA. Jak wyjaśniliśmy, pliki BACPAC tworzone ręcznie nie zapewniają spójności transakcyjnej i dlatego konieczne było utworzenie najpierw kopii bazy danych, a następnie pliku BACPAC z tej kopii. Na szczęście jednak, jeśli utworzymy harmonogram eksportu plików BACPAC do automatycznego tworzenia kopii zapasowych, generowane pliki BACPAC są spójne transakcyjnie. Tym samym automatyczne eksportowanie plików BACPAC zapewnia skuteczną i wygodną strategię kopii zapasowych dla baz danych SQL Database. Aby skonfigurować harmonogram automatycznego eksportowania plików BACPAC, wykonaj następujące działania: 1 . Jeśli zamknąłeś portal zarządzania Microsoft Azure po poprzedniej procedurze,
zaloguj się ponownie, przechodząc do adresu https://manage.windowsazure.com. 2 . Kliknij SQL DATABASES w panelu nawigacyjnym po lewej. 3 . Kliknij WineCloudDb w kolumnie NAME na liście baz danych. 4 . Kliknij łącze CONFIGURE w górnej części strony. 5 . W sekcji EXPORT STATUS (status eksportu) poniżej wpisu Automated Export kliknij
przycisk AUTOMATIC, aby wyświetlić opcje konfiguracji automatycznego eksportu. 6 . W polu STORAGE ACCOUNT wybierz swoje konto magazynowe z listy rozwijanej
(w naszym przykładzie jest to konto mywinestorage). 7 . W sekcji FREQUENCY (częstotliwość) określ, jak często baza danych ma być eks-
portowana, podając interwał wyrażony w dniach (domyślnie co siedem dni) oraz datę i godzinę początkową (domyślnie bieżącego dnia o północy).
133
134
Rozdział 5: Bezpieczeństwo i kopie zapasowe
8 . W polu RETENTION (przechowywanie) wpisz liczbę dni, przez które mają być
przechowywane poszczególne kopie (domyślnie 30 dni). Pozostaw zaznaczoną opcję Always Keep At Least One Export File (zawsze przechowuj przynajmniej jeden plik eksportu), aby zagwarantować, że przynajmniej jeden plik kopii zapasowej będzie dostępny nawet po wygaśnięciu okresu przechowywania dla wszystkich eksportów. 9 . W polu SERVER LOGIN NAME wpisz login użyty przy tworzeniu serwera (saz
w naszym przykładzie). 10 . W polu SERVER LOGIN PASSWORD wpisz hasło dla tego loginu i odczekaj chwilę,
aż hasło zostanie zweryfikowane. Strona CONFIGURE dla bazy danych powinna wyglądać podobnie do pokazanej na rysunku 5-16.
Rysunek 5-16 Konfigurowanie automatycznego eksportu dla bazy danych SQL Database
Podsumowanie
11 . Kliknij przycisk SAVE w dolnej części strony, aby zapisać zmiany.
Od tego momentu kopie zapasowe bazy danych WineCloudDbCopy będą wykonywane automatycznie zgodnie z wybranymi ustawieniami.
Podsumowanie Bezpieczeństwo, dostępność i zdolność do przywracania po awariach należą do najważniejszych zagadnień, które są podnoszone przy rozważaniu użycia chmury publicznej. Firma Microsoft odnosi się do tych wątpliwości, zapewniając bezpieczną, niezawodną i wysoko dostępną platformę w postaci Microsoft Azure. Jest rzeczą bardzo ważną, aby usługi danych w chmurze były zabezpieczone i oferowały dobre rozwiązania przywracania po awarii. SQL Database udostępnia wielopoziomowe funkcje zabezpieczeń oraz mechanizm przywracania po awarii. W tym rozdziale pokazaliśmy, jak tworzyć zabezpieczenia na wielu poziomach, poczynając od reguł dostępowych opartych na adresach IP w zaporze SQL Database, aż po uwierzytelnianie i autoryzację przy użyciu loginów SQL Database, kont użytkowników i ról, tak serwerowych, jak i na poziomie bazy danych. Pokazaliśmy też technikę tworzenia ręcznej kopii zapasowej i przywracania jej w nowej bazie danych. Na koniec pokazaliśmy konfigurowanie automatycznych, transakcyjnie spójnych kopii BACPAC. Dzięki tym funkcjonalnościom SQL Database można zbudować bezpieczne, niezawodne i wysoko dostępne rozwiązanie bazy danych w chmurze Microsoft Azure.
135
ROZDZI AŁ 6
Raportowanie w chmurze Leonard Lobel
W
świecie baz danych umieszczanie informacji w bazie to tylko jedna strona medalu. Inną ważną częścią jest wydobywanie ze zgromadzonych danych znaczących informacji i strategiczne analizowanie tych danych, aby uzyskać wartościowe spostrzeżenia. Do realizacji tych celów powstała rozbudowana rodzina usług i komponentów analizy biznesowej (Business Intelligence – BI), które są zintegrowane jako część produktu Microsoft SQL Server. Jednym z głównych elementów tej rodziny jest narzędzie SQL Server Reporting Services (SSRS). Ten składnik stosu SQL Server udostępnia bogaty język raportowania znany jako Report Definition Language (RDL), usługę renderującą raporty oparte na RDL, a także narzędzia klienckie i projektanckie, ułatwiające tworzenie i rozpowszechnianie plików RDL. W tym rozdziale skonfigurujemy maszynę wirtualną (VM) w Microsoft Azure z zainstalowanym oprogramowaniem SSRS i zbudujemy kilka prostych raportów RDL. Wykorzystamy w tym celu dwa narzędzia klienckie: Report Builder oraz Microsoft Visual Studio (a mówić ściślej, dodatek SSDT Business Intelligence dla Visual Studio) do lokalnego projektowania raportów, po czym wdrożymy je w instancji SSRS na maszynie wirtualnej w Microsoft Azure.
Co z Microsoft Azure SQL Reporting? Firma Microsoft do niedawna oferowała rozwiązanie SQL Reporting jako opartą na chmurze wersję SSRS, ale ostatnio zakończyła oferowanie tej usługi. W chwili pisania tych słów nie można już utworzyć nowego serwera Microsoft Azure SQL Reporting, zaś istniejące i nadal działające serwery zostaną wyłączone 31 października 2014. SQL Reporting był zasadniczo wersją typu Platform-as-a-Service (PaaS) komponentu SSRS, działającą w Microsoft Azure. Można porównać Microsoft Azure SQL Reporting z wersją SSRS w siedzibie w analogiczny sposób, jak możemy zestawić Microsoft Azure SQL Database z lokalną instalacją SQL Server; ta pierwsza
137
138
Rozdział 6: Raportowanie w chmurze
jest implementacją PaaS tej drugiej, dostosowaną do działania w chmurze, nie obsługującą pełnego zestawu funkcji dostępnego w produkcie lokalnym. Nieszczęśliwie pojawiło się wiele problemów związanych z SQL Reporting, które skłoniły firmę Microsoft do zakończenia oferowania tej usługi i zalecenia w to miejsce instalowania składnika SSRS na maszynach wirtualnych w Microsoft Azure. Najpoważniejszym problemem było to, że SQL Reporting obsługiwał jako źródło danych tylko bazy danych SQL Database. Dla kontrastu, SSRS wspiera liczne źródła danych, w tym wielowymiarowe zbiory danych przechowywane w kostkach Microsoft SQL Server Analysis Services, a także platformy danych innych firm, takie jak Oracle lub DB/2. Oznaczało to, że jedynym źródłem danych, które można było uwzględnić w raportach SQL Reporting, była relacyjna baza danych hostowana w SQL Database. Dodatkowo SSRS pozwala na osadzenie własnego, niestandardowego kodu w raportach, a także zaplanować automatyczne wykonywanie i dostarczanie raportów, podczas gdy SQL Reporting nie wspierał żadnej z tych funkcji. Na koniec występowały problemy dotyczące wydajności samej usługi SQL Reporting. Działała wolniej niż SSRS i nie można było jej wyłączyć, gdy nie była potrzebna, przez co opłaty narastały stale, nawet jeśli nie powstawały żadne raporty. W rezultacie firma Microsoft zdecydowała, że najlepszym wyjściem będzie rezygnacja z SQL Reporting i zalecenie zamiast tej usługi rozwiązania SSRS w VM, które omówimy w tym rozdziale. Wynika stąd, że wszystkie funkcjonalności znane z wersji w siedzibie są nadal dostępne w chmurze. Na przykład można zbudować raporty wykonywane w chmurze, które odwołują się do rozmaitych źródeł danych, a nie tylko do SQL Database. Możemy również osadzić własny kod (nawet taki, który wywołuje niestandardowe asemblacje .NET) w swoich raportach, utworzyć harmonogramy wykonywania i dostarczania tych raportów i – generalnie – zrobić wszystko, na co pozwala SSRS. Ponieważ katalog raportów serwera znajduje się na lokalnym dysku maszyny wirtualnej, wydajność jest podobna do tej, której możemy oczekiwać od instancji SSRS w siedzibie. A jeśli nie ma potrzeby tworzenia raportów, można po prostu wyłączyć VM, aby opłaty za obliczenia przestały obciążać naszą subskrypcję Microsoft Azure. Rozdział ten zawiera wiele procedur, które łącznie pozwolą przejść cały proces konfigurowania maszyny wirtualnej (VM) zawierającej SSRS w chmurze Microsoft Azure, zaprojektowanie raportów lokalnie przy użyciu narzędzi autorskich i wdrożenie tych raportów na tej VM. Na początek utworzymy prosty raport w narzędziu Report Builder, używając bazy danych WineCloudDb, po czym wdrożymy go na maszynie wirtualnej. Następnie przejdziemy do tworzenia raportu przy użyciu narzędzi SSDT BI w Visual Studio. Prosta
Tworzenie maszyny wirtualnej dla SQL Server Reporting Services
baza WineCloudDb nie zawiera dostatecznie złożonego schematu (tabel i kolumn w tych tabelach) ani danych (wierszy), aby skutecznie zademonstrować bardziej zaawansowane raporty, zatem pobierzemy i zainstalujemy w SQL Database przykładową bazę AdventureWorks2012. Baza danych AdventureWorks (dostępna w Codeplex) od wielu lat służy jako standardowa przykładowa baza SQL Server i istnieje również specjalna wersja tej bazy, zaprojektowana dla Microsoft Azure SQL Database. Uwaga Wiele z pokazanych procedur to jednorazowe instalacje. Gdy VM, narzędzia i bazy danych są już na swoich miejscach, tworzenie raportu i jego wdrożenie jest zadziwiająco szybkie. Jednak ze względu na konieczność wykonania tych wszystkich instalacji (a niektóre mogą być czasochłonne), warto nastawić się na konieczność wielu przerw na kawę, gdy będziemy czekać na zakończenie różnych operacji (chyba że ktoś woli kieliszek wina).
RDL stanowi ośrodek SSRS. Format RDL w pełni opisuje raport, który zasadniczo składa się z trzech części: jak raport łączy się z bazą danych (źródło danych), jak odpytuje ją o dane (zbiór danych) i jak rzeczywiście wygląda (układ). Wszystkie te informacje są zawarte w pojedynczym pliku RDL, który w istocie jest po prostu zwykłym plikiem XML, który można otworzyć w dowolnym edytorze tekstowym, na przykład Notatniku. Jednak, choć to może być pouczające i ciekawe, Notatnik zdecydowanie nie jest idealnym narzędziem do tworzenia RDL. Aby zapewnić sprawną pracę, powstały dwa główne narzędzia autorskie, które umożliwiają zarówno projektowanie, jak i wdrażanie raportów: ■ ■
Report Builder Projekty typu Report Server w Visual Studio z zainstalowanym dodatkiem (add-in) SSDT Business Intelligence
W miarę posuwania się przez ten rozdział nauczymy się, jak używać obu tych narzędzi do tworzenia i wdrażania zarówno prostych, jak i nieco bardziej złożonych raportów. Oczywiście istnieje wiele funkcji i znacznie bardziej złożonych scenariuszy, które można realizować w RDL, które wykraczają poza zakres tego rozdziału. Jednak wiedza, którą Czytelnik pozna w tym rozdziale, będzie stanowić dobry fundament dla rozwijania umiejętności raportowania.
Tworzenie maszyny wirtualnej dla SQL Server Reporting Services Rozpoczniemy od utworzenia VM, która będzie hostowała SSRS, choć z technicznego punktu widzenia nie potrzebujemy instancji SSRS, aby móc zacząć budować raporty. Wynika to z faktu, że zarówno Report Builder, jak i projekt Report Server w Visual Studio udostępniają funkcje podglądu, która umożliwia uruchomienie i przejrzenie
139
140
Rozdział 6: Raportowanie w chmurze
raportu lokalnie, w trakcie projektowania. Gdy już będziemy zadowoleni z projektu raportu, będziemy mogli wdrożyć go w instancji SSRS na maszynie wirtualnej i następnie udostępnić go użytkownikom w chmurze. W tej procedurze szybko utworzymy i uruchomimy VM, wybierając jeden z wstępnie zdefiniowanych obrazów w galerii maszyn wirtualnych Microsoft Azure. Obraz ten zawiera już SQL Server z zainstalowanym składnikiem SSRS, co pozwala pominąć najbardziej czasochłonną część procesu instalacji. Jednak SSRS w tej VM nie jest jeszcze skonfigurowany, podobnie jak nie ma tam reguły zapory niezbędnej do uzyskiwania dostępu do SSRS przez port 80 TCP. Co więcej, punkt końcowy VM musi zostać skonfigurowany, aby pasował do reguły zapory. Zatem w kilku następnych procedurach zrealizujemy następujące zadania: 1 . Utworzymy VM. 2 . Skonfigurujemy SSRS w tej maszynie wirtualnej. 3 . Utworzymy regułę zapory w VM, pozwalającą na dostęp do usługi raportowania. 4 . Utworzymy odpowiadający tej maszynie wirtualnej punkt końcowy w portalu
zarządzania Microsoft Azure, pozwalający na dostęp do usługi raportowania. Uwaga Zależnie od tego, jakie funkcje SQL Server są wymagane, może się okazać, że bardziej efektywne z punktu widzenia kosztów będzie korzystanie z licencjonowanej kopii SQL Server, zakupionej i zainstalowanej oddzielnie w maszynie wirtualnej. Jeśli wszystko, czego potrzebujemy w VM, to samo SSRS, można również rozważyć zastosowanie bezpłatnej wersji Reporting Services, dostępnej w wydaniu SQL Server Express With Advanced Services. Instrukcje pobierania SQL Server Express przedstawione we Wprowadzeniu można (po nieznacznej modyfikacji) wykorzystać wewnątrz „gołej” maszyny wirtualnej Microsoft Azure. Należy jedynie wybrać do pobrania plik ENU\x64\SQLEXPRADV x64 ENU.exe (wersję Express With Advanced Services, zawierającą SSRS) zamiast ENU\x64\SQLEXPR x64 ENU.exe (zawierający tylko silnik relacyjnej bazy danych), aby zainstalować darmową wersję SSRS w maszynie wirtualnej.
Tworzenie maszyny wirtualnej z galerii obrazów Aby utworzyć nową maszynę wirtualną (VM), wykonaj poniższe działania: 1 . Zaloguj się w portalu Microsoft Azure. Pojawi się strona ALL ITEMS. 2 . Kliknij VIRTUAL MACHINES w lewej części strony. 3 . Kliknij przycisk NEW w dolnej części strony. 4 . Kliknij QUICK CREATE (szybkie tworzenie). 5 . W obszarze wprowadzania danych po prawej wpisz następujące informacje:
Tworzenie maszyny wirtualnej dla SQL Server Reporting Services
a . W polu DNS NAME (nazwa DNS) wpisz krótką, ale zrozumiałą (czytelną), unika-
tową globalnie nazwę, którą ma otrzymać maszyna wirtualna. W naszym przykładzie użyliśmy nazwy WineCloudVM (Czytelnik będzie musiał wybrać inną, gdyż ta nazwa najprawdopodobniej będzie niedostępna). b . Z listy rozwijanej IMAGE wybierz najnowszą dostępną wersję SQL Server w wydaniu Standard, uruchamianą na najnowszej dostępnej wersji Windows Server (w chwili pisania tych słów była to wersja SQL Server 2012 SP1 Standard w systemie Windows Server 2012). Uwaga Aby zlokalizować pożądaną kombinację oprogramowania SQL Server i Windows Server, konieczne może być użycie opcji More images (więcej obrazów), która powoduje wyświetlenie bardziej rozbudowanego kreatora, który pozwala również na wybranie rozmiaru maszyny wirtualnej (liczby rdzeni procesora i przydzielonej pamięci). Parametry te można zmienić również w późniejszej fazie, po utworzeniu maszyny wirtualnej.
c . W polu USER NAME wpisz nazwę konta administratora dla maszyny wirtualnej.
W naszym przykładzie użyliśmy nazwy WineAdmin. d . W polach NEW PASSWORD oraz CONFIRM wpisz (dwukrotnie) silne hasło dla konta administratora VM. Hasło to musi mieć długość co najmniej ośmiu znaków i zawierać kombinację małych i wielkich liter, cyfr oraz symboli. e . Z listy rozwijanej REGION/AFFINITY GROUP (region/grupa powinowactwa) wybierz region, w którym ma być hostowana VM. Aby uniknąć opłat za pasmo przesyłowe (patrz rozdział 2, „Konfiguracja i ceny”), wybierz ten sam region, w którym zlokalizowany jest serwer SQL Database z bazą danych, dla której chcemy skonfigurować raportowanie. Ekran powinien w tym momencie wyglądać podobnie do pokazanego na rysunku 6-1. f . Kliknij łącze CREATE A VIRTUAL MACHINE (utwórz maszynę wirtualną). Tworzenie VM może zająć kilka minut, po czym portal wyświetli informację, że została ona uruchomiona, jak na rysunku 6-2. ważne Gdy tylko VM rozpocznie działanie, rozpoczyna się naliczanie opłat w subskrypcji Microsoft Azure. Z tego względu należy zamknąć (wyłączyć) VM, gdy nie pracuje się nad procedurami opisanymi w tym rozdziale, klikając przycisk SHUT DOWN w dolnej części strony.
141
142
Rozdział 6: Raportowanie w chmurze
Rysunek 6-1 Tworzenie nowej maszyny wirtualnej Microsoft Azure z SQL Server 2012 SP1 przy użyciu wstępnie zdefiniowanego obrazu systemu
Rysunek 6-2 Portal Microsoft Azure pokazujący uruchomioną maszynę wirtualną
Tworzenie maszyny wirtualnej dla SQL Server Reporting Services
Konfigurowanie SSRS na maszynie wirtualnej Dopiero co utworzona VM zawiera już zainstalowane komponenty SSRS, ale nie są one skonfigurowane. Na szczęście konfigurowanie SRSS jest bardzo proste i szybkie. W tym celu należy połączyć się z maszyną wirtualną za pomocą pulpitu zdalnego (Remote Desktop) i uruchomić narzędzie SQL Server Reporting Services Configuration Manager, aby zdefiniować adres URL bazy danych SSRS i powiązanych usług. Jeśli kontynuujemy pracę z poprzedniej procedury, wiersz nowej VM w portalu Microsoft Azure powinien być zaznaczony. Aby skonfigurować SSRS w tej maszynie wirtualnej, wykonaj poniższe działania: 1 . Zaloguj się w VM: a . Kliknij przycisk CONNECT (połącz) w dolnej części strony. Spowoduje to wyge-
nerowanie pliku .rdp zawierającego dane dla sesji pulpitu zdalnego i przesłanie go do przeglądarki. b . W monicie z zapytaniem, czy otworzyć, czy zapisać plik .rdp, kliknij Open, jak na rysunku 6-3.
Rysunek 6-3 Pobieranie pliku .rdp w celu uruchomienia sesji pulpitu zdalnego do maszyny wirtualnej
c . W monicie ostrzeżenia, że wydawca zdalnego połączenia nie może zostać zwe-
ryfikowany, kliknij Connect. d . W oknie dialogowym Windows Security wpisz nazwę użytkownika (WineAdmin w naszym przykładzie) oraz hasło przypisane do konta administratora VM w poprzedniej procedurze. Warto zauważyć, że nazwa użytkownika może być już wprowadzona i trzeba jedynie wpisać hasło. e . Kliknij OK. f . W monicie ostrzeżenia, że tożsamość komputera zdalnego nie może być zweryfikowana, kliknij Yes (Tak). Spowoduje to otwarcie sesji pulpitu zdalnego i zalogowanie w maszynie wirtualnej. 2 . Uruchom narzędzie SQL Server Reporting Services Configuration Manager w VM. a . Na ekranie startowym VM przewiń kafelki w celu odszukania narzędzia, albo
po prostu wpisz reporting services, aby wyszukać aplikację, po czym kliknij kafelek Report Services Configuration Manager.
143
144
Rozdział 6: Raportowanie w chmurze
b . W oknie dialogowym Reporting Services Configuration Connection kliknij Connect. Zostanie wyświetlone okno konfiguracji dla usługi SSRS uruchomionej w maszynie wirtualnej, pokazane na rysunku 6-4.
3 . Utwórz katalog wirtualny dla usługi raportowania. Będzie to dopełnienie adresu
URL usługi Web, której oprogramowanie klienckie będzie używać do publikowania i pobierania raportów oraz wykonywania innych operacji SSRS. Nazwa ta zazwyczaj kończy się frazą /reportserver. a . Kliknij łącze Web Service URL w lewym panelu. b . Kliknij Apply (zastosuj) w prawej dolnej części okna dialogowego. Spowoduje
to utworzenie katalogu wirtualnego o ustawieniach domyślnych, udostępniającego usługę raportowania poprzez protokół HTTP (przez port 80). 4 . Utwórz bazę danych Reporting Services. Baza ta będzie przechowywana w lokal-
nej instancji SQL Server uruchomionej w maszynie wirtualnej (w przeciwieństwie do baz danych SQL Database, dla których będziemy budować raporty). Baza ta jest używana wewnętrznie przez Reporting Services do przechowywania metadanych hostowanych przez nie raportów. a . Kliknij łącze Database w lewym panelu. b . Kliknij Change Database (zmień bazę danych), aby uruchomić kreator Report
Server Database Configuration Wizard.
Tworzenie maszyny wirtualnej dla SQL Server Reporting Services
c . Klikaj Next na wszystkich stronach kreatora, nie zmieniając żadnych domyśl-
nych ustawień, po czym zaczekaj, aż kreator utworzy bazę danych. d . Kliknij Finish (zakończ). 5 . Utwórz katalog wirtualny dla narzędzia Report Manager. Jest to przyjazna witryna
frontonu, która umożliwia nawigowanie po hierarchii folderów raportów, przetwarzanie tych raportów i zarządzanie strukturą folderów, rolami użytkowników i uprawnieniami. Zazwyczaj nazwa ta kończy się na /reports. a . Kliknij łącze Report Manager URL w lewym panelu. b . Kliknij Apply w prawym dolnym rogu okna dialogowego. Spowoduje to utwo-
rzenie katalogu wirtualnego o ustawieniach domyślnych, udostępniającego Report Manager poprzez protokół HTTP (przez port 80). 6 . Kliknij Exit.
Skonfigurowaliśmy usługi SSRS w maszynie wirtualnej. Jednak dopóki nie otworzymy zapory dla portu 80, wszystkie żądania klienckie będą blokowane przez VM.
Otwieranie dostępu przez zaporę do serwera raportów Kolejną rzeczą, którą musimy zrobić, jest utworzenie reguły zapory otwierającej port 80 TCP w VM, tak by maszyna wirtualna przyjmowała żądania przesyłane przez klientów poprzez protokół HTTP. Aby otworzyć port 80 TCP w maszynie wirtualnej, wykonaj poniższe działania: 1 . Uruchom narzędzie Windows Firewall With Advanced Security w maszynie wirtual-
nej. W tym celu można albo przeszukać kafelki dostępne na ekranie startowym VM, albo wpisać na nim firewall w celu wyszukania aplikacji i kliknąć zlokalizowany kafelek. 2 . Kliknij węzeł Inbound Rules (reguły przychodzące) w widoku drzewa po lewej. 3 . Kliknij New Rule (nowa reguła) w panelu po prawej. 4 . Po uruchomieniu kreatora New Inbound Rule Wizard wykonaj następujące działania: a . Na stronie Rule Type (typ reguły) wybierz Port i kliknij Next. b . Na stronie Protocols And Ports (protokoły i porty) wpisz 80 w polu Specified Local Ports (wskazane porty lokalne) i kliknij Next.
c . Na stronie Action zaakceptuj domyślne ustawienie Allow The Connection (zezwa-
laj na połączenie) i kliknij Next. d . Na stronie Profile zaakceptuj wszystkie domyślne ustawienia i kliknij Next. e . Na stronie Name wpisz TCP Port 80 i kliknij Finish. Nowa reguła powinna
pojawić się na szczycie listy, jak na rysunku 6-5.
145
146
Rozdział 6: Raportowanie w chmurze
5 . Zamknij okno Windows Firewall With Advanced Security.
Rysunek 6-5 Tworzenie reguły zapory w celu otwarcia portu TCP 80 w maszynie wirtualnej i udostępnienia usług SSRS dla klientów
Od tego momentu nie ma już potrzeby korzystania z pulpitu zdalnego do pracy z maszyną wirtualną. Usługa SSRS została w pełni skonfigurowana w VM i jest dostępna dla klientów bezpośrednio poprzez zdefiniowane adresy URL. Aby wylogować się teraz z VM, wykonaj następujące działania: 1 . Na ekranie startowym maszyny wirtualnej kliknij nazwę użytkownika WineAdmin
w prawym górnym rogu. 2 . Kliknij Sign Out (wyloguj).
Spowoduje to wylogowanie z maszyny wirtualnej, ale pozostaje ona oczywiście uruchomiona (i cały czas naliczane są opłaty za jej działanie, jak wspomnieliśmy wcześniej). Pozostała jeszcze jedna rzecz, którą musimy zrobić, aby ta VM funkcjonowała jako serwer SSRS w chmurze. Musimy mianowicie utworzyć punkt końcowy (endpoint) dla tej maszyny wirtualnej w portalu zarządzania Microsoft Azure. Bez tego punktu końcowego żądania TCP kierowane do portu 80 będą blokowane przez Microsoft Azure i w ogóle nie dotrą do maszyny wirtualnej, a tym samym reguła zapory, którą właśnie utworzyliśmy wewnątrz VM, nie będzie miała nawet szansy na dopuszczenie żądań klientów do SSRS. Wracamy zatem do portalu zarządzania Microsoft Azure, w którym wiersz dla maszyny wirtualnej powinien być nadal zaznaczony. Aby utworzyć punkt końcowy, wykonaj następującą procedurę: 1 . Kliknij nazwę VM. Spowoduje to przejście do strony Quick Start (szybki start) dla
tej maszyny. 2 . Kliknij łącze ENDPOINTS w górnej części strony, jak na rysunku 6-6.
Tworzenie maszyny wirtualnej dla SQL Server Reporting Services
Rysunek 6-6 Łącze ENDPOINTS umożliwia otwarcie portu 80 TCP dla VM.
3 . Kliknij przycisk ADD w dolnej części strony. 4 . Pozostaw zaznaczoną opcję ADD A STAND-ALONE ENDPOINT (dodaj autonomiczny
punkt końcowy) i kliknij Next (ikonę ze strzałką w prawo w prawym dolnym rogu strony). 5 . W polu NAME wybierz HTTP z listy rozwijanej. Spowoduje to ustawienie pozosta-
łych wartości okna dialogowego dla portu TCP o numerze 80, jak na rysunku 6-7.
Rysunek 6-7 Tworzenie punktu końcowego HTTP powoduje otwarcie portu 80 TCP dla maszyny wirtualnej.
6 . Kliknij Finish (ikonę ze znacznikiem potwierdzenia w prawym dolnym rogu).
Tworzenie punktu końcowego zajmuje kilka chwil. Zaczekaj, dopóki nie zniknie komunikat UPDATE IN PROGRESS (aktualizacja w trakcie), zanim przejdziesz do dalszych działań.
147
148
Rozdział 6: Raportowanie w chmurze
Teraz, gdy usługa SSRS jest skonfigurowana i uruchomiona w maszynie wirtualnej, możemy zacząć myśleć o tworzeniu pierwszego raportu. Będzie to prosta lista klientów oparta na wariancie bazy danych WineCloudDb, utworzonej w rozdziale 1, „Poznajemy Microsoft Azure SQL Database”.
Tworzenie przykładowej bazy danych Na użytek raportu budowanego w tym rozdziale utworzymy nową bazę WineCloudDb, bardzo podobną do używanej wcześniej w tej książce. Listing 6-1 pokazuje skrypt, który należy wykonać w celu utworzenia kilku tabel i wypełnienia ich pewną ilością danych. Po skonfigurowaniu bazy danych utworzymy raport, który będzie wyliczał nazwiska poszczególnych klientów, ulubione wino tych klientów oraz całkowitą sumę wszystkich zamówień złożonych przez nich. lisTing 6-1 Kod przygotowujący przykładową bazę danych WineCloudDb dla potrzeb raportowania CREATE TABLE Wine ( WineId int PRIMARY KEY, Name nvarchar (50), Category nvarchar (15), Year int, Price money) CREATE TABLE Customer ( CustomerId int PRIMARY KEY, FirstName nvarchar(50), LastName nvarchar(15), FavoriteWineId int, CONSTRAINT FK_Customer_Wine FOREIGN KEY (FavoriteWineId) REFERENCES Wine (WineId)) CREATE TABLE [Order] ( OrderId int PRIMARY KEY, OrderedOn datetime2, CustomerId int, WineId int, Quantity int, Price money, CONSTRAINT FK_Order_Customer FOREIGN KEY (CustomerId) REFERENCES Customer(CustomerId), CONSTRAINT FK_Order_Wine FOREIGN KEY (WineId) REFERENCES Wine(WineId)) INSERT INTO Wine VALUES (1, ‘Chateau Penin’, ‘Bordeaux’, 2008, 34.90), (2, ‘McLaren Valley’, ‘Cabernet’, 2005, 48.50), (3, ‘Mendoza’, ‘Merlot’, 2010, 42.00), (4, ‘Valle Central’, ‘Merlot’, 2009, 52.00) INSERT INTO Customer VALUES (1, ‘Jeff’, ‘Hay’, 4), (2, ‘Mark’, ‘Hanson’, 3), (3, ‘Jeff’, ‘Phillips’, 2)
Skrypt ten tworzy tabele Wine, Customer oraz Order i ładuje do nich przykładowe dane. Zwróćmy uwagę na wiersze wstawiane do tabeli Order (na końcu skryptu). Identyfikator klienta jest pierwszą liczbą po dacie zamówienia. Jak widać, mamy tu sześć zamówień, z których trzy złożył klient 1, dwa klient 2, zaś jedno klient 4. Kolejna liczba to identyfikator wina, po czym następuje liczba zamówionych butelek i cena. Przy użyciu tych danych zbudujemy raport, który grupuje zamówienia poszczególnych klientów i wylicza sumę ich zamówień, opierając się na ilości i cenie. Aby utworzyć nową bazę danych WineCloudDb, wykonaj następujące kroki: 1 . Uruchom narzędzie SSMS. W tym celu możesz wyszukać kafelek na ekranie star-
towym (w kategorii Microsoft SQL Server) albo po prostu wpisać sql server management studio, aby rozpocząć wyszukiwanie, po czym kliknąć znaleziony kafelek. Po krótkiej chwili pojawi się okno dialogowe Connect To Server. 2 . W tym oknie dialogowym: a . W polu Server Name wpisz .database.windows.net. Jest to w pełni
kwalifikowana nazwa serwera SQL Database, w której frazę trzeba zastąpić nazwą przypisaną do twojego serwera. b . W polu Authentication wybierz z listy rozwijanej SQL Server Authentication (SQL Database nie wspiera uwierzytelniania Windows). c . W polach Login i Password wpisz nazwę użytkownika i hasło przypisane do serwera przy jego tworzeniu. d . Kliknij przycisk Connect. 3 . W panelu Object Explorer rozwiń węzeł Databases. 4 . Jeśli baza danych WineCloudDb istnieje (została utworzona w poprzednich roz-
działach), usuń ją teraz. a . Prawym klawiszem myszy kliknij bazę WineCloudDb i wybierz Delete. b . W oknie dialogowym Delete Object kliknij OK. 5 . Utwórz bazę danych. a . W panelu Object Explorer kliknij prawym klawiszem myszy nazwę serwera
i wybierz polecenie New Query, by otworzyć nowe okno zapytania połączone z bazą danych master. b . W oknie zapytania wpisz CREATE DATABASE WineCloudDb.
149
150
Rozdział 6: Raportowanie w chmurze
c . Naciśnij F5 (albo kliknij przycisk Execute w pasku narzędzi), aby utworzyć bazę
danych. d . Zamknij okno zapytania bez zapisywania skryptu. 6 . W panelu Object Explorer kliknij prawym klawiszem myszy węzeł Databases
i wybierz Refresh. Na liście powinna pojawić się nowo utworzona baza WineCloudDb. 7 . Prawym klawiszem myszy kliknij bazę danych WineCloudDb i wybierz polecenie New Query, aby otworzyć okno zapytań połączone z tą bazą danych.
8 . Wpisz kod pokazany w Listingu 6-1 do okna zapytania (albo skopiuj go z plików
pobranych z witryny powiązanej z ksiażką). 9 . Naciśnij F5 (albo kliknij przycisk Execute w pasku narzędzi), aby wykonać skrypt.
Mamy więc nową bazę danych WineCloudDb, która posłuży jako źródło danych dla pierwszego raportu. Uwaga Do utworzenia bazy danych i wypełnienia jej konieczne było użycie dwóch oddzielnych okien zapytań, gdyż SQL Database nie obsługuje wyrażenia USE, znanego z SQL Server, które pozwala przełączyć połączenie z bazy danych master na bazę WineCloudDb. Więcej informacji na ten temat zawiera rozdział 3, „Różnice pomiędzy SQL Server a Microsoft Azure SQL Database”.
Teraz, gdy maszyna wirtualna i baza danych są gotowe, możemy skupić się na raporcie. Do utworzenia pierwszego raportu wykorzystamy narzędzie Report Builder, zaś w dalszej części tego rozdziału posłużymy się Visual Studio do zbudowania bardziej zaawansowanego raportu.
Korzystanie z Report Builder Report Builder jest klienckim narzędziem autorskim wykorzystującym środowisko podobne do Microsoft Office (ze wstążką). Przy użyciu Report Builder można zdefiniować źródło danych raportu (informacje o połączeniu z SQL Database) oraz zestaw danych (dane dla raportu tworzone przez zapytanie). Następnie można użyć narzędzi projektowych i kreatorów do zdefiniowania układu raportu, dostosowania czcionek i kolorów, dodania tabel i macierzy dla danych numerycznych, a także wykresów i schematów zapewniających wizualną prezentację informacji. Po zdefiniowaniu źródła danych, zestawu danych i układu Report Builder udostępnia podgląd raportu, dzięki czemu można iteracyjnie projektować i sprawdzać wygląd raportu bez konieczności wdrażania go. Po zakończeniu projektowania Report Builder pozwala wdrożyć raport na serwerze SSRS, co zasadniczo sprowadza się
Korzystanie z Report Builder
do skopiowania pliku RDL ze środowiska projektanckiego do maszyny wirtualnej, na której działa usługa SSRS. Alternatywnie można wykorzystać Visual Studio do wykonania tego samego zadania, posługując się zbliżonymi, choć bardziej rozbudowanymi narzędziami. Zrealizujemy to nieco później, tworząc inny raport. Nieszczęśliwie, nie istnieje (jak dotąd) narzędzie projektowania raportów oparte na Web w portalu Microsoft Azure, które można by uruchomić w przeglądarce, zatem konieczne jest pobranie albo narzędzia Report Builder, albo wtyczki SSDT BI dla Visual Studio, aby móc projektować raporty dla SSRS.
Instalowanie Report Builder W celu zainstalowania Report Builder wykonaj poniższe działania (to tylko jednorazowa procedura): 1 . Otwórz przeglądarkę Internet Explorer i przejdź do strony http://www.microsoft.
com/en-us/download/details.aspx?id=29072. 2 . Kliknij wielki przycisk Download (Pobierz)4. 3 . W monicie, czy uruchomić, czy zapisać plik, wybierz Run (Uruchom), jak
4 Program Report Builder dostępny jest również w polskiej wersji, zatem Czytelnik może wybrać tę właśnie wersję, jeśli woli pracować z polskim interfejsem.
151
152
Rozdział 6: Raportowanie w chmurze
4 . Gdy pojawi się strona powitalna kreatora instalacji, kliknij Next (Dalej), jak
5 . Zaakceptuj warunki umowy licencyjnej i kliknij Next. 6 . Na stronie Feature Selection (Wybieranie funkcji) zaakceptuj domyślne wybory,
klikając Next. 7 . Na stronie Default Target Server (Domyślny serwer docelowy) pozostaw puste pole
tekstowe adresu URL i kliknij Next. 8 . Kliknij Install (Zainstaluj). 9 . Jeśli pojawi się okno dialogowe User Account Control (Kontrola konta użytkowni-
ka), kliknij Yes (Tak), aby rozpocząć instalację. 10 . Po zakończeniu instalacji kliknij Finish (Zakończ), aby zamknąć kreatora.
Tworzenie raportu przy użyciu Report Builder Po pierwszym uruchomieniu programu Report Builder pojawia się okno dialogowe Getting Started. W oknie tym można wybrać jeden z licznych kreatorów, zaprojektowanych w celu ułatwienia szybkiego rozpoczęcia pracy z najrozmaitszymi typami raportów. Jednak w przypadku naszego pierwszego raportu nie użyjemy żadnego z tych kreatorów. Zamiast tego zaczniemy od czystego tła, wybierając tworzenie pustego raportu. W celu uruchomienia programu Report Builder wykonaj poniższe działania: 1 . Na ekranie startowym systemu Windows 8 zlokalizuj kafelek Report Builder albo
wpisz report builder w celu jego wyszukania, po czym kliknij znaleziony kafelek.
Korzystanie z Report Builder
2 . W oknie dialogowym Getting Started (Wprowadzenie) kliknij Blank Report (Pusty
raport), jak na rysunku 6-10.
Rysunek 6-10 Wybieranie tworzenia pustego raportu w oknie dialogowym Getting Started
Okno Report Builder powinno teraz wyglądać podobnie jak na rysunku 6-11.
Rysunek 6-11 Program Report Builder gotowy do tworzenia nowego raportu
153
154
Rozdział 6: Raportowanie w chmurze
Zwróćmy uwagę na wstążkę w stylu Office – zawierającą karty Home (Narzędzia główne), Insert (Wstaw) oraz View (Widok) – oraz duży, okrągły przycisk z logo SQL Server w lewym górnym rogu, który wyświetla menu z opcjami zapisywania i wdrażania raportów. Główny obszar projektowy zawiera już pole tekstowe dla wpisania tytułu raportu oraz wbudowane pole &ExecutionTime w polu tekstowym w prawym dolnym rogu strony, które będzie prezentować datę i godzinę wykonania raportu. Po lewej stronie okna znajduje się panel Report Data (Dane raportu), zapewniający dostęp do kluczowych elementów raportu. Najważniejsze z nich to źródła danych, w których zdefiniujemy połączenie do bazy danych SQL Database, do której raport będzie się odwoływał. Ponadto mamy tu węzeł Datasets (Zestawy danych), w którym znajdą się definicje, jakie konkretnie dane mają wypełnić raport. Może być tabela, widok, wynik wywołania procedury składowanej lub dowolne zapytanie Transact-SQL (T-SQL), przesyłane do SQL Database w celu przetworzenia. Źródła danych i zestawy danych są zazwyczaj osadzane w poszczególnych raportach, ale można również zdefiniować współużytkowane źródła danych oraz współużytkowane zestawy i wdrożyć je jako obiekty wielokrotnego użytku w usłudze raportowania. W ten sposób łatwiej jest wykorzystywać te same zapytania i zapewnić spójne dane w wielu raportach. Po zdefiniowaniu przynajmniej jednego źródła i przynajmniej jednego zestawu danych pobierającego informacje z tego źródła można zacząć projektować układ i zachowanie raportu. Do prezentacji danych numerycznych można użyć formantu tabeli lub macierzy. Obydwa formanty wyświetlają dane w formacie tabelarycznym; różnica polega na tym, jak obsługiwane są kolumny. W obu przypadkach dane wyjściowe mogą zawierać zmienną liczbę wierszy. Jednak tabele mają ustaloną liczbę kolumn, podczas gdy w macierzach liczba kolumn może być zmienna, podobnie jak liczba wierszy. Podczas definiowania wierszy i kolumn wybierane do nich pola pojawiają się w panelach Row Groups (Grupy wierszy) oraz Column Groups (Grupy kolumn), widocznych w dolnej części okna. I owszem, jak wynika z tych nazw, zarówno tabele, jak i macierze obsługują grupowanie według wierszy lub kolumn. W istocie użytkownik może nawet interaktywnie zagłębiać się w kolejne poziomy hierarchii definiowanej przez grupowanie, co pokażemy w raporcie tworzonym w dalszej części tego rozdziału. Panel Report Data pozwala również zdefiniować parametry raportu, będące wartościami typowo używanymi w zestawach danych do filtrowania raportu (na przykład według zakresów dat lub kategorii produktów). W tym miejscu można również dodać do raportu obrazy. Panel ten zapewnia także dostęp do wbudowanych pól (zbioru poręcznych wartości, w tym bieżącej daty i czasu, numeru strony, całkowitej liczby stron, identyfikatora użytkownika i tak dalej), które można dołączyć do raportu. Jak się wydaje, mamy już dość informacji, aby rozpocząć. Zaczniemy od tworzenia źródła danych.
Korzystanie z Report Builder
Tworzenie źródła danych dla raportu W celu utworzenia źródła danych wykonaj poniższe działania: 1 . Prawym klawiszem myszy kliknij węzeł Data Sources (Źródła danych) w panelu Report Data po lewej stronie okna Report Builder, po czym wybierz Add Data Source (Dodaj źródło danych).
2 . W polu Name (Nazwa) zastąp domyślny tekst DataSource1 nazwą WineCloud-
DataSource. 3 . Wybierz opcję Use A Connection Embedded In My Report (Użyj połączenia osadzo-
nego w tym raporcie). 4 . Z listy rozwijanej Select Connection Type (Wybierz typ połączenia) wybierz opcję Microsoft SQL Azure.
5 . Kliknij przycisk Build (Kompiluj) po prawej stronie pola tekstowego Connection String (Parametry połączenia). Pojawi się dobrze znane okno dialogowe Connection Properties (właściwości połączenia5).
6 . Wpisz dane połączenia dla bazy WineCloudDb utworzonej w poprzednim
podrozdziale. a . W polu Server Name wpisz .database.windows.net (zastępując
nazwą własnego serwera SQL Database). b . Wybierz opcję Use SQL Server Authentication i wpisz nazwę użytkownika oraz
hasło przypisane do serwera. b . Zaznacz pole wyboru Save My Password (zapamiętaj moje hasło). c . Z listy rozwijanej poniżej Select Or Enter A Database Name (wybierz lub wpisz
nazwę bazy danych) wybierz WineCloudDb. Jeśli lista rozwijana okaże się pusta, możesz po prostu wpisać w niej WineCloudDb. d . Kliknij OK, aby zamknąć okno dialogowe. Okno Data Source Properties powinno teraz wyglądać podobnie do pokazanego na rysunku 6-12. 7 . Kliknij OK, aby zamknąć okno dialogowe Data Source Properties.
W panelu Report Data pojawi się nowe źródło WineCloudDataSource w węźle Data Sources. Kolejnym zadaniem będzie utworzenie zestawu danych.
5 Choć program Report Builder jest spolszczony, to wymienione okno dialogowe dostępne jest tylko w wersji angielskiej.
155
156
Rozdział 6: Raportowanie w chmurze
Rysunek 6-12 Tworzenie źródła danych
Tworzenie zestawu danych dla raportu Zestaw danych dostarcza informacji do zbudowania raportu. Zasadniczo jest on generowany poprzez jakąś formę zapytania do bazy danych. Może być ono tak proste, jak zrzucenie wszystkich wierszy i kolumn z pojedynczej tabeli, na przykład poprzez zapytanie SELECT * FROM Customer. Może to być również znacznie bardziej złożone zapytanie, które wykona złączenie wielu tabel, używa wyrażeń do budowania wynikowych kolumn i agreguje dane, takie jak pokazane w Listingu 6-2. To zapytanie tworzy listę klientów i dla każdego z nich podaje całkowitą wartość zamówień. Lista ta obejmuje również ulubione wino każdego klienta, o ile zostało ono zdefiniowane. lisTing 6-2 Kod zapytania dla raportu CustomerList SELECT CONCAT(c.LastName, ‘, ‘, c.FirstName) AS [Customer Name], CONCAT(w.Name, ‘ (‘, w.Category, ‘)’) AS [Favorite Wine], COUNT(*) AS Orders, SUM(o.Quantity * o.Price) AS Total FROM Customer AS c LEFT OUTER JOIN Wine AS w ON c.FavoriteWineId = w.WineId LEFT OUTER JOIN [Order] AS o ON c.CustomerId = o.CustomerId GROUP BY c.FirstName, c.LastName, w.Category, w.Name ORDER BY c.LastName, c.FirstName
Korzystanie z Report Builder
Zauważmy, jak tabele Customer i Wine zostały złączone w klauzuli FROM zapytania. Tabela Customer używa aliasu c, zaś tabela Wine aliasu w, przy czym złączenie następuje na podstawie identyfikatora ulubionego wina klienta. Aliasy te odpowiadają prefiksom c oraz w użytych w nazwach pierwszych dwóch kolumn na liście SELECT, [Customer Name] oraz [Favorite Wine]. Funkcja CONCAT łączy wszystkie przekazane do nich ciągi znaków, budując nazwę klienta w formacie „nazwisko, imię” i nazwę ulubionego wina jako „nazwa (kategoria).” Wracając do klauzuli FROM, możemy zauważyć, że tabela Customer jest również złączona z tabelą Order (używającą aliasu o), zwracającą zamówienia poszczególnych klientów. Normalnie spowodowałoby to zwrócenie po jednym wierszu na każde zamówienie, co z kolei zduplikowałoby informacje o kliencie w każdym wierszu zamówienia. Jednak dzięki użyciu klauzuli GROUP BY oraz funkcji COUNT i SUM w kolumnach Orders i Total zapytanie to agreguje (podsumowuje) powiązane zamówienia w pojedynczy wiersz zawierający liczbę zamówień i całkowitą ich wartość dla każdego klienta. Tym samym zapytanie zwraca dokładnie jeden wiersz dla każdego klienta w bazie danych. Warto zauważyć, że funkcja SUM dynamicznie wylicza wartość każdego zamówienia, mnożąc ilość przez cenę. Jest to konieczne, gdyż nasza tabela Order nie zawiera kolumny z całkowitą wartością zamówienia (w realnej bazie danych taka kolumna zapewne by istniała, ale w naszej prostej bazie przykładowej tak nie jest). W kolejnej procedurze utworzymy zestaw danych dla raportu oparty na tym zapytaniu. Choć możemy osadzić zapytanie pokazane w Listingu 6-2 bezpośrednio w raporcie, równie łatwo moglibyśmy utworzyć procedurę składowaną i wstawić zapytanie do niej. Użycie procedury składowanej jest alternatywnym podejściem zapewniającym współużytkowany zestaw danych, który będzie można wykorzystać w wielu raportach. Zauważmy, że nawet raporty używające swoich własnych zestawów danych (niewspółdzielonych) mogą odwoływać się do tych samych danych poprzez wywołanie tej samej procedury składowanej. Tworzenie zestawu danych dla raportu wymaga wykonania następujących działań: 1 . Prawym klawiszem myszy kliknij węzeł Datasets (Zestawy danych) w panelu Report Data po lewej stronie okna Report Builder i wybierz polecenie Add Dataset
(Dodaj zestaw danych). 2 . W polu Name zastąp domyślny wpis DataSet1 tekstem CustomerListDataset. 3 . Wybierz opcję Use A Dataset Embedded In My Report (Użyj zestawu danych osa-
dzonego w tym raporcie). 4 . Z listy rozwijanej Data Source (Źródło danych) wybierz WineCloudDataSource. 5 . Wpisz kod zawarty w Listingu 6-2 do pola tekstowego Query (Zapytanie). Okno
dialogowe Dataset Properties (Właściwości zestawu danych) powinno wyglądać podobnie do pokazanego na rysunku 6-13. 6 . Kliknij OK, aby zamknąć okno dialogowe Dataset Properties.
157
158
Rozdział 6: Raportowanie w chmurze
Rysunek 6-13 Tworzenie zestawu danych
Okno Report Builder powinno teraz wyglądać podobnie jak na rysunku 6-14.
Rysunek 6-14 Okno Report Builder ze zdefiniowanym źródłem i zestawem danych
Korzystanie z Report Builder
W panelu Report Data widoczny jest teraz wpis CustomerListDataSet poniżej węzła Datasets. Jeśli klikniemy znak plus obok nazwy zestawu, pojawią się również pola Customer_Name, Favorite_Wine, Orders i Total (pola te zostały utworzone na podstawie analizy kolumn zwracanych przez zapytanie, wykonanej przez Report Builder). Teraz, gdy mamy już zestaw danych, możemy przejść do projektowania układu raportu.
Projektowanie układu raportu Projektant zapytań zawiera już pole tekstowe dla tytułu raportu. W kolejnej procedurze wstawimy w nim tytuł raportu, a następnie posłużymy się narzędziem Table Wizard do utworzenia tabeli dla listy klientów. Aby zacząć tworzyć układ raportu, wykonaj poniższe kroki: 1 . Kliknij wewnątrz pola tekstowego w lewej górnej części obszaru projektowego
(zawierającego wpis Click To Add Title – Kliknij, by dodać tytuł), po czym wpisz Wine Customers. 2 . Kliknij Insert (Wstaw), aby wyświetlić kartę Insert wstążki. 3 . Kliknij Table (Tabela) we wstążce i wybierz polecenie Table Wizard (Kreator tabeli),
jak na rysunku 6-15. Pojawi się okno kreatora New Table Or Matrix (Nowa tabela lub macierz).
Rysunek 6-15 Wywoływanie kreatora tabeli
4 . Na stronie Choose A Dataset (Wybierz zestaw danych) kliknij CustomerListDataset,
a następnie Next (Dalej). 5 . Na liście Available Fields (Dostępne pola) zaznacz pierwsze pole, Customer_Name. 6 . Przytrzymaj klawisz SHIFT i kliknij ostatnie pole, Total. W ten sposób zostaną
zaznaczone wszystkie dostępne pola. 7 . Przeciągnij zaznaczone pola do listy Values (Wartości), jak na rysunku 6-16.
159
160
Rozdział 6: Raportowanie w chmurze
Rysunek 6-16 Wybieranie wszystkich dostępnych pól dla raportu
8 . Kliknij Next, aby przejść do strony Choose The Layout (Wybierz układ). 9 . Kliknij Next, aby przejść do strony Choose A Style (Wybierz styl). Domyślnie
wybrany jest styl Ocean. 10 . Kliknij Finish (Zakończ), aby zamknąć kreatora i dodać tabelę do obszaru projek-
towego raportu. 11 . Kliknij wewnątrz dowolnej komórki tabeli, aby wyświetlić szare pola wyboru
po lewej i u góry tabeli. 12 . Kliknij i przeciągnij linie pomiędzy kolumnami w pasku wyboru u góry tabeli,
aby poszerzyć kolumnę Customer Name. 13 . Powtórz poprzedni krok dla kolumny Favorite Wine. 14 . Kliknij komórkę [Sum(Total)] poniżej nagłówka kolumny Total. 15 . Kliknij przycisk ze znakiem dolara w panelu Number (Liczba) na karcie Home
wstążki. Spowoduje to sformatowanie całkowitych wartości zamówień jako danych walutowych (a nie zwykłych liczb dziesiętnych). 16 . Kliknij dowolne nieużywane (białe) miejsce w powierzchni projektowania raportu,
aby ukryć szare paski wyboru z tabeli. Gotowy projekt raportu powinien wyglądać podobnie jak na rysunku 6-17.
Korzystanie z Report Builder
Rysunek 6-17 Widok gotowego projektu raportu
Zapisywanie i lokalne uruchamianie raportu Przy korzystaniu z Report Builder można przejrzeć działanie raportu przed jego wdrożeniem. Pozwala to przyśpieszyć tworzenie raportów, gdyż możemy stopniowo projektować, zapisywać i przeglądać raport lokalnie, bez konieczności umieszczania go na serwerze SSRS, a wdrożenie wykonać dopiero po zakończeniu projektowania. Aby zapisać i uruchomić raport lokalnie, wykonaj poniższe działania: 1 . Kliknij ikonę Save (Zapisz) w pasku szybkiego dostępu w górnej części okna
Report Builder (powyżej wstążki), jak na rysunku 6-18. Alternatywnie możesz nacisnąć klawisze CTRL+S. Pojawi się okno dialogowe Save As Report (Zapisz jako raport), który domyślnie wybiera jako miejsce umieszczenia raportu lokalny folder Documents.
Rysunek 6-18 Ikona Save w pasku szybkiego dostępu
161
162
Rozdział 6: Raportowanie w chmurze
2 . Wpisz CustomerListLocal w polu Name, jak na rysunku 6-19.
Rysunek 6-19 Lokalne zapisywanie raportu
3 . Kliknij Save. 4 . Kliknij przycisk Run (Uruchom) na karcie Home wstążki, aby wykonać raport, jak
na rysunku 6-20.
Rysunek 6-20 Przycisk uruchamiania raportu we wstążce
5 . Po chwili powinien pojawić się podgląd raportu, podobny do pokazanego na rysun-
ku 6-21. Po przejrzeniu raportu kliknij przycisk Design (Projekt) we wstążce, aby powrócić do projektanta. Zwróć uwagę, że w trybie podglądu wstążka zawiera tylko jedną kartę o nazwie Run (Uruchom).
Korzystanie z Report Builder
Rysunek 6-21 Lokalne wykonywanie raportu
Podgląd pokazuje, że zapytanie poprawnie zwróciło liczbę i sumę zamówień poszczególnych klientów. Ponadto poprawnie zostały sformatowane nazwy klientów i win. Raport można więc wdrożyć, aby był dostępny dla użytkowników w chmurze.
Wdrażanie raportu w usłudze SSRS na maszynie wirtualnej Microsoft Azure Jedyną informacją, jaka będzie nam potrzebna do wdrożenia raportu, jest adres URL usługi SSRS uruchomionej w VM. Jest to zawsze adres w formacie http://. cloudapp.net/reportserver, gdzie jest globalnie unikatową nazwą przypisaną do maszyny wirtualnej podczas jej tworzenia we wcześniejszej części tego rozdziału (w naszych przykładach używamy nazwy winecloudvm). W celu wdrożenia raportu wykonaj poniższe działania: 1 . W programie Report Builder kliknij okrągły przycisk w stylu Office w lewym
górnym rogu okna i wybierz polecenie Save As (Zapisz jako), jak na rysunku 6-22. 2 . W polu tekstowym Name wpisz http://.cloudapp.net/reportserver
(zastępując frazę nazwą przypisaną do maszyny wirtualnej) i naciśnij Enter. 3 . W oknie dialogowym Connect To Report Server (które pojawi się po paru sekun-
dach) wpisz WineAdmin i hasło przypisane do konta administratora VM.
163
164
Rozdział 6: Raportowanie w chmurze
Rysunek 6-22 Menu obsługi plików w programie Report Builder
4 . Zaznacz pole wyboru Remember My Password, aby Report Builder nie pytał ponow-
nie o poświadczenia przy przyszłych wdrożeniach, po czym kliknij OK. 5 . W polu Name wpisz CustomerList, jak na rysunku 6-23.
Rysunek 6-23 Zapisywanie raportu w maszynie wirtualnej Microsoft Azure
6 . Kliknij Save.
Korzystanie z Report Builder
Raport został umieszczony na maszynie wirtualnej w Microsoft Azure i jest teraz dostępny z dowolnej przeglądarki. Obecnie konto administratora WineAdmin jest jedynym uprawnionym użytkownikiem, ale można utworzyć innych użytkowników z różnymi poziomami dostępu, co omówimy w końcowej części tego rozdziału.
Uruchamianie raportu w przeglądarce Istnieją dwie metody uruchomienia raportu w przeglądarce. Możemy posłużyć się adresem URL usługi raportowania (czyli tym, który kończy się na /reportserver) albo adresem Report Manager (kończącym się na /reports). Przypomnijmy, że włączyliśmy obydwa te adresy dla maszyny wirtualnej podczas jej konfigurowania na początku rozdziału. Jeśli w przeglądarce wpiszemy adres URL usługi raportowania, otrzymamy bardzo prosty interfejs, zawierający jedynie zwykłe, niebieskie hiperłącza na białych stronach. Łącza te pozwalają przechodzić do hierarchii folderów i podfolderów raportów i wybrać dowolny raport do wyświetlenia. URL Report Manager oferuje bardziej przyjazny interfejs, ułatwiający nawigowanie po hierarchii folderów. Udostępnia on również kilka innych funkcji, których można użyć do zarządzania strukturą folderów, użytkownikami, grupami, uprawnieniami i rolami. Aby uruchomić wdrożony raport w przeglądarce poprzez Report Manager, wykonaj poniższe działania: 1 . Otwórz nowe okno przeglądarki. 2 . Wpisz http://.cloudapp.net/reports (zastępując nazwą
maszyny wirtualnej) w pasku adresu przeglądarki, po czym naciśnij Enter. Jeśli pojawi się monit Windows Security o podanie poświadczeń, wpisz WineAdmin oraz hasło przypisane do konta administratora VM. Pojawi się strona startowa Report Manager z łączami do wszystkich dostępnych folderów i raportów zlokalizowanych na serwerze. W tym momencie istnieje tu tylko raport CustomerList w folderze głównym, co widać na rysunku 6-24.
Rysunek 6-24 Strona startowa Report Manager z łączami do raportów dostępnych w VM
165
166
Rozdział 6: Raportowanie w chmurze
3 . Kliknij łącze raportu CustomerList, aby go uruchomić. Po chwili raport powinien
pojawić się w oknie przeglądarki, jak na rysunku 6-25.
Rysunek 6-25 Uruchamianie w przeglądarce raportu obsługiwanego przez SSRS w maszynie wirtualnej
Przed zamknięciem przeglądarki warto poświęcić nieco czasu na poznanie funkcji oferowanych przez pasek narzędzi w górnej części strony. Można tu przechodzić pomiędzy kolejnymi stronami raportu (choć nasz prosty przykład zawiera tylko jedną stronę), zmieniać stopień powiększenia, wyszukiwać tekst w raporcie, wyeksportować raport w rozmaitych formatach lub go wydrukować. Te standardowe możliwości są dostępne dla każdego raportu przetwarzanego przez SSRS. Uwaga Niektóre wersje przeglądarki Internet Explorer wymagają włączenia widoku zgodności przy odwoływaniu się do maszyny wirtualnej Microsoft Azure obsługującej raporty za pomocą SSRS. W przeciwnym razie pasek narzędzi nie jest poprawnie wyświetlany w górnej części strony i pojawia się jako wiele pasków z pojedynczymi elementami, zamiast jednego paska z wieloma przyciskami, takiego jak widoczny na rysunku 6-25. Jeśli spotkamy się z takim zachowaniem, należy rozwinąć menu Tools (Narzędzia) w przeglądarce Internet Explorer i wybrać polecenie Compatibility View Settings (Ustawienia widoku zgodności). Następnie należy kliknąć Add (Dodaj), aby ustawić widok zgodności dla wszystkich witryn w domenie cloudapp.net. Po kliknięciu Close w celu zamknięcia okna dialogowego Internet Explorer odświeży stronę i pasek narzędzi powinien zostać poprawnie zaprezentowany.
Korzystanie z projektów Visual Studio Report Server
Korzystanie z projektów Visual Studio Report Server Podczas gdy Report Builder jest doskonałym, samodzielnym narzędziem do tworzenia raportów ad-hoc, Visual Studio oferuje znacznie bogatsze środowisko projektowania dla Report Server. Podobnie jak w przypadku Report Builder, można wykorzystać Visual Studio do tworzenia projektów raportów zawierających źródła danych i zestawy danych, posługując się kreatorami i narzędziami projektowymi, a gotowe raporty wdrożyć w usłudze SSRS uruchomionej na VM. Ale co więcej, projekty Report Server są faktycznymi projektami Visual Studio, co oznacza, że udostępniają wiele z tych samych korzyści, jakie zapewniają dowolne inne projekty Visual Studio. Można tu wymienić kontrolę kodu źródłowego i możliwość uczestnictwa w większych rozwiązaniach, obejmujących wiele powiązanych projektów różnych typów (na przykład projekty .NET napisane w języku C# lub Visual Basic .NET albo projekty bazodanowe SSDT).
Narzędzie o różnych nazwach Przez lata Visual Studio służyło jako podstawowe narzędzie autorskie dla SQL Server Reporting Services, choć pojawiły się nieporozumienia wynikające ze zmian nazewnictwa i nowych edycji. Do niedawna mieliśmy do czynienia z Business Intelligence Developer Studio (BIDS) jako specjalną wersją Visual Studio, zawierającą również analogiczne narzędzia dla projektów Analysis Services oraz Integration Services. Jednak w roku 2012 funkcjonalność ta została przemianowana na SQL Server Data Tools (SSDT). Nieszczęśliwie, obsługa projektów BI (bez względu na to, czy nazywamy ją BIDS, czy SSDT) nie była zsynchronizowana z cyklem wydawniczym produktu Visual Studio. W rezultacie po wydaniu wersji Visual Studio 2010 jeszcze przez parę lat BIDS działał tylko w środowisku Visual Studio 2008, wymagając od programistów pracujących nad aplikacjami .NET wykorzystujących raporty przełączania się pomiędzy dwiema wersjami Visual Studio. Następnie w roku 2012 SSDT zastąpiło BIDS (jednocześnie udostępniając nowy zestaw narzędziowy dla relacyjnych baz danych) i wreszcie ujednolicone zostało środowisko projektowe – wszystko w pojedynczej powłoce Visual Studio 2010. Niestety, radość była krótka, gdyż po opublikowaniu wersji Visual Studio 2012 środowisko SSDT zostało pozbawione wsparcia dla rozwiązań BI (czyli dla projektów Reporting Services, Analysis Services i Integration Services) i zachowało tylko narzędzia i funkcje dotyczące relacyjnych baz danych. W chwili pisania tych słów Visual Studio 2013 nadal nie zawiera wsparcia dla BI. Tym samym konieczne będzie pobranie i zainstalowanie SSDT BI w środowisku Visual Studio 2012
167
168
Rozdział 6: Raportowanie w chmurze
(procedurę tę pokażemy za chwilę), nawet jeśli do innych projektów używamy środowiska Visual Studio 2013. Zasadniczo jednak zawsze było (i nadal będzie) dostępne środowisko Visual Studio, udostępniające szablony projektów, narzędzia projektowe i wdrożeniowe dla Reporting Services. Tak więc niezależnie od niekiedy dziwnych zmian nazewnictwa i niezsynchronizowanych cykli wydawniczych, będziemy mówić po prostu o Visual Studio. W tym podrozdziale pokażemy, jak wykorzystać Visual Studio do zaprojektowania i wdrożenia projektów Report Server w usłudze SSRS. Jednak najpierw konieczne będzie wykonanie dwóch zadań przygotowawczych: ■
Zainstalowanie bazy danych AdventureWorks na serwerze SQL Database. Ta przykładowa baza danych jest nieporównywalnie większa niż WineCloudDb i posłuży jako lepsze źródło dla danych raportowania. Co więcej, pozwoli na poznanie wielu dodatkowych możliwości raportowania, wykraczających poza to, co omówimy w tym rozdziale. Zainstalowanie szablonów SSDT Business Intelligence dla Visual Studio. ❐ Jeśli korzystamy z Visual Studio 2012, szablony te będą niezbędne do utworzenia projektów Report Server. ❐ Jeśli wykorzystujemy Visual Studio 2013, nadal będą potrzebne te szablony, uruchamiane w powłoce Visual Studio 2012. ❐ Jeśli używamy Visual Studio 2010, szablony te już są dostępne. ❐
■
Instalowanie bazy danych AdventureWorks2012 w SQL Database Aby zainstalować bazę danych AdventureWorks2012 w SQL Database, wykonaj poniższe działania: 1 . Otwórz nowe okno przeglądarki. 2 . Przejdź do strony http://msftdbprodsamples.codeplex.com/releases/view/37304. Uwaga Podany URL może ulec zmianie do chwili, gdy książka trafi do rąk Czytelnika. W takim przypadku należy wyszukać w sieci frazę „download adventureworks2012 for windows azure sql database”, aby zlokalizować poprawny adres.
3 . Poniżej tytułu RECOMMENDED DOWNLOAD kliknij łącze AdventureWorks2012ForWindowsAzureSQLDatabase.
Korzystanie z projektów Visual Studio Report Server
4 . W monicie z pytaniem, czy otworzyć, czy zapisać plik, kliknij rozwijaną część
przycisku Save i wybierz polecenie Save As, jak na rysunku 6-26.
5 . W oknie dialogowym Save As przejdź do wybranego folderu (lub zaakceptuj
domyślny folder Downloads) i kliknij Save. 6 . Po zakończeniu pobierania kliknij przycisk Open Folder (Otwórz folder).
Spowoduje to otwarcie nowego okna Eksploratora Windows w folderze, w którym został zapisany plik AdventureWorks2012ForSQLAzure.zip. 7 . Prawym klawiszem myszy kliknij plik AdventureWorks2012ForSQLAzure.zip
i wybierz Extract All (Wyodrębnij wszystkie). 8 . Przejdź do folderu AdventureWorks w wyodrębnionych plikach. 9 . Kliknij kartę File (Plik) we wstążce, rozwiń pozycję Open Command Prompt (Otwórz
wiersz polecenia), po czym kliknij Open Command Prompt As Administrator (Otwórz wiersz polecenia jako administrator), jak na rysunku 6-27.
Rysunek 6-27 Otwieranie okna wiersza polecenia z podniesionymi uprawnieniami
10 . W oknie kontroli konta użytkownika kliknij Yes.
169
170
Rozdział 6: Raportowanie w chmurze
11 . W oknie wiersza poleceń wpisz CreateAdventureWorksForSQLAzure
name>.database.windows.net @, zastępując frazy , i nazwą serwera SQL Database, nazwą konta administratora i jego hasłem, jak na rysunku 6-28.
Rysunek 6-28 Wdrażanie bazy danych AdventureWorks2012 na serwerze Microsoft Azure SQL Database Uwaga Krok ten wymaga obecności .NET Framework 3.5 (nawet jeśli mamy zainstalowane środowisko .NET Framework 4.5 jako część Visual Studio 2012 lub 2013). Jeśli środowisko to nie jest jeszcze zainstalowane, polecenie to wygeneruje błędy i pojawi się okno dialogowe Windows Features, zachęcające do pobrania i instalacji .NET Framework 3.5. Kliknij Download And Install This Feature (Pobierz i zainstaluj tę funkcję). Po instalacji konieczne jest ponowne uruchomienie komputera. Następnie należy powrócić do folderu AdventureWorks i ponownie wykonać procedurę od kroku 9. Dodatkowo krok ten polega na dostępności narzędzia bcp, które jest dostarczane wraz z SQL Server. Jeśli na komputerze lokalnym nie jest zainstalowane oprogramowanie SQL Server, nie będzie tam również bcp. Jednak nie jest konieczne instalowanie całego SQL Server, aby uzyskać narzędzie bcp potrzebne do załadowania bazy danych AdventureWorks2012 na serwer SQL Database w Microsoft Azure. W celu zainstalowania narzędzia bcp bez SQL Server, należy pobrać pakiet Microsoft ODBC Driver 11 for SQL Server z adresu http://www.microsoft.com/en-us/download/details.aspx?id=36434, a następnie Microsoft Command Line Utilities 11 for SQL Server z adresu http://www.microsoft.com/en-us/download/details.aspx?id=36433.
12 . Po zakończeniu wykonywania skryptu zaloguj się w portalu Microsoft Azure, aby
się upewnić, że baza danych AdventureWorks2012 jest obecna i uruchomiona na serwerze, co pokazuje rysunek 6-29. wskazówka Skrypt bardzo szybko tworzy bazę danych, ale wypełnianie tabel danymi może trwać długo. Nie trzeba jednak czekać na zakończenie działania skryptu przed przejściem do instalowania pakietu SSDT Business Intelligence for Visual Studio 2012, który jest kolejnym krokiem. Ponieważ ta instalacja również jest dość czasochłonna, można oszczędzić wiele czasu nie czekając, aż baza danych AdventureWorks2012 zostanie całkowicie wypełniona. Konieczne będzie jednak upewnienie się, że proces ładowania danych się zakończył, zanim przystąpimy do tworzenia pierwszego projektu Report Server.
Korzystanie z projektów Visual Studio Report Server
Rysunek 6-29 Wyświetlanie wdrożonej bazy danych AdventureWorks2012 w portalu zarządzania Microsoft Azure
Następnym zadaniem będzie zainstalowanie pakietu SSDT BI dla Visual Studio.
Instalowanie SSDT Business Intelligence dla Visual Studio 2012 Do budowania projektów Report Server można wykorzystać zarówno Visual Studio 2010, jak i 2012. Jak już wspomnieliśmy, jeśli korzystamy z Visual Studio 2010 i zainstalowaliśmy w nim pakiet SSDT, mamy już zapewnione wsparcie dla szablonów projektów BI dla SSRS, zatem można pominąć kolejną procedurę. Jeśli jednak używamy Visual Studio 2012 lub 2013, konieczne jest zainstalowanie narzędzi SSDT Business Intelligence dla Visual Studio 2012 (nawet jeśli „zwykły” pakiet SSDT jest już zainstalowany). Uwaga Podczas instalacji może pojawić się monit o restart komputera. W takim przypadku należy kliknąć OK – procedura instalacyjna zostanie automatycznie wznowiona po ponownym uruchomieniu komputera.
W celu zainstalowania narzędzi SSDT Business Intelligence dla Visual Studio 2012 wykonaj poniższe działania: 1 . Otwórz nowe okno przeglądarki.
171
172
Rozdział 6: Raportowanie w chmurze
2 . Przejdź do strony http://www.microsoft.com/en-us/download/details.aspx?id=36843.
Jest to strona Download Center dla Microsoft SQL Server Data Tools – Business Intelligence For Visual Studio 20126, pokazana na rysunku 6-30.
Rysunek 6-30 Strona Download Center dla Microsoft SQL Server Data Tools – Business Intelligence For Visual Studio 2012 Uwaga Adres ten może ulec zmianie, zanim książka trafi do rąk Czytelnika. W takim przypadku należy wyszukać w Internecie frazę „download business intelligence for visual studio”, aby znaleźć zaktualizowaną stronę.
3 . Kliknij przycisk Download. Pojawi się zapytanie, czy uruchomić, czy zapisać plik. 4 . Kliknij Run, aby rozpocząć pobieranie. 5 . Po wyświetleniu okna kontroli konta użytkownika kliknij Yes, aby uruchomić
kreatora instalacji SQL Server 2012. 6 . Zaakceptuj warunki licencyjne na stronie License Terms i kliknij Next. 7 . Na stronie Product Updates kliknij Next, aby rozpocząć proces instalacji. 8 . Jeśli już masz zainstalowaną instancję SQL Server 2012 na swoim komputerze,
kreator instalacji wyświetli stronę Installation Type, na której można dokonać wyboru pomiędzy wykonaniem nowej instalacji SQL Server 2012 lub dodaniem funkcji do istniejącej instancji. a . Upewnij się, że wybrana jest opcja wykonania nowej instalacji (która jest
zaznaczona domyślnie), pomimo tego, że SQL Server jest już zainstalowany. 6 Ten program jest dostępny w kilku wersjach językowych, ale nie ma wśród nich wersji polskiej.
Korzystanie z projektów Visual Studio Report Server
W przeciwnym razie proces instalacji zakończy się niepowodzeniem z błędem „architecture mismatch” (niezgodność architektury). b . Kliknij Next. 9 . Na stronie Feature Selection kliknij Select All, po czym kliknij Next. 10 . Na stronie Error Reporting kliknij Next, aby rozpocząć proces instalacji. Po jej
zakończeniu pojawi się strona Complete sygnalizująca sukces, pokazana na rysunku 6-31. Jeśli pojawi się monit o ponowne uruchomienie komputera, kliknij OK.
Rysunek 6-31 Komunikat o udanej instalacji Microsoft SQL Server Data Tools – Business Intelligence For Visual Studio 2012
11 . Kliknij Close, aby zakończyć pracę kreatora.
Tworzenie raportu przy użyciu Visual Studio Baza danych AdventureWorks zawiera wiele danych w licznych tabelach, zaś tabele te podzielone są pomiędzy kilka schematów, takich jak Sales (sprzedaż), Person (osoby) czy HumanResources (zasoby ludzkie). Schematy te nie są niczym więcej, niż logicznym grupowaniem na kategorie – zamiast przechowywać wszystkie tabele w jednej, płaskiej przestrzeni (domyślnym schemacie dbo), informacje dotyczące sprzedaży są umieszczane w schemacie Sales, dane personalne w schemacie Person i tak dalej. W tym raporcie będziemy wykonywać zapytanie do tabel SalesOrderHeader oraz SalesTerritory w schemacie Sales. Zwróci ono dane zamówień wraz z powiązanymi informacjami terenowymi (hierarchią złożoną z krajów i regionów), choć nasz raport
173
174
Rozdział 6: Raportowanie w chmurze
będzie podsumowywał dane zamówień na poziomie regionu (jeśli ktoś nie może się powstrzymać, może zajrzeć do finalnego raportu, pokazanego na rysunku 6-46). Zapytanie tworzące zestaw danych dla raportu zawiera Listing 6-3. lisTing 6-3 Zapytanie dla raportu zwracające informacje o sprzedaży wraz z danymi terenowymi SELECT soh.SalesOrderID, DATEPART(YEAR, soh.OrderDate) AS [Year], soh.CustomerID, soh.TerritoryID, terr.Name as TerritoryName, terr.CountryRegionCode as Country, soh.TotalDue as TotalSales FROM Sales.SalesOrderHeader AS soh INNER JOIN Sales.SalesTerritory AS terr ON terr.TerritoryID = soh.TerritoryID ORDER BY [Year]
Przykład ten znacząco różni się od poprzedniego raportu dotyczącego klientów firmy winiarskiej. Przypomnijmy, że w Listingu 6-2 raport wykorzystywał klauzulę GROUP BY z funkcjami agregującymi COUNT i SUM, podsumowującymi informacje zamówień dla każdego klienta, zatem to mechanizm bazodanowy SQL Database wykonywał agregację. SSRS jedynie przenosiło te informacje do tabeli raportu; liczba wierszy zwracanych przez zapytanie jest zawsze taka sama jak liczba wierszy w raporcie. W nowym zapytaniu można zauważyć, że nie występuje żadna agregacja, co oznacza, że mechanizm bazy danych zwróci informacje na poziomie zamówień, które tylko ma dołączone informacje terytorialne (powielone dla zamówień z tego samego regionu) i to mechanizm raportowania będzie musiał wykonać agregację na poziomie terytorialnym. Będziemy mogli się przekonać, że zapytanie zwróci 31465 wierszy danych zamówień, zaś raport, który utworzymy, podsumuje te wyniki w 10 wierszach, po jednym dla każdego regionu. Oznacza to, że możemy wykonać sumowanie na poziomie bazy danych, jeśli ma to sens (lub jest wygodniejsze), a następnie przeprowadzać dalszą agregację w razie potrzeby na poziomie raportu. Dodatkowo poprzez złączenie z tabelą terytoriów i odczytanie hierarchii kraj-region można zapewnić użytkownikom automatyczną funkcjonalność drążenia w głąb (drill-down), pozwalając na rozwijanie lub zwijanie regionów wewnątrz każdego kraju. To tylko jeden z przykładów elastyczności, jaką zapewnia język RDL i usługa SSRS. Dodatkową różnicą w porównaniu z poprzednim przykładem jest to, że w tym raporcie użyjemy raczej formantu macierzy, a nie tabeli. Zauważmy, że zapytanie wykorzystuje funkcję DATEPART z parametrem YEAR do wydobycia roku z daty każdego zamówienia do oddzielnej kolumny. Wykorzystamy tę kolumnę do utworzenia macierzy, tak by oprócz generowania zmiennej liczby wierszy (po jednym na terytorium) raport będzie również tworzył zmienną liczbę kolumn (po jednej na rok).
Korzystanie z projektów Visual Studio Report Server
Korzystanie z kreatora raportów Najszybszą metodą utworzenia projektu typu Report Server jest wykorzystanie kreatora Report Server Project Wizard i tym właśnie zajmiemy się teraz. Oczywiście, wszystko, co można zrobić za pomocą kreatora, można również zrealizować w indywidualnych, ręcznych krokach. Jak zobaczymy, kreator prowadzi poprzez analogiczne kroki tworzenia źródła danych, zestawu danych i definiowania układu raportu, jak wykonane wcześniej przy posługiwaniu się narzędziem Report Builder. Aby utworzyć projekt typu Report Server w Visual Studio, wykonaj następujące działania. 1 . Uruchom SQL Server Data Tools For Visual Studio 2012. W tym celu możesz
odnaleźć odpowiedni kafelek na ekranie startowym VM albo wpisać sql server data tools, aby wywołać wyszukiwanie aplikacji. 2 . Jeśli narzędzie SQL Server Data Tools for Visual Studio 2012 jest uruchamiane
po raz pierwszy, pojawi się monit o ustawienie domyślnych parametrów środowiskowych. W takiej sytuacji wybierz opcję Business Intelligence Settings i kliknij przycisk Start Visual Studio. 3 . Kliknij menu FILE (Plik), a następnie wybierz New | Project, aby wyświetlić okno
dialogowe New Project. 4 . W lewym panelu okna dialogowego rozwiń kolejno węzły Templates, Business Intelligence, Reporting Services, po czym wybierz Report Server Project Wizard.
5 . Nazwij tworzone rozwiązanie i projekt AWReporting i wybierz odpowiednią loka-
lizację, jak na rysunku 6-32.
Rysunek 6-32 Tworzenie nowego projektu typu Report Server przy użyciu Report Server Project Wizard
6 . Kliknij OK, aby rozpocząć działanie kreatora.
175
176
Rozdział 6: Raportowanie w chmurze
7 . Na stronie powitalnej kliknij Next. 8 . Na stronie Select The Data Source (wybierz źródło danych) wykonaj poniższe
działania: a . Nazwij źródło danych AWDataSource. b . Z listy rozwijanej Type wybierz Microsoft SQL Azure. c . Kliknij przycisk Edit na prawo od pola tekstowego na ciąg połączenia, aby otwod . e . f . g . h .
rzyć dobrze znane okno dialogowe Connection Properties. W polu Server Name wpisz .database.windows.net (zastępując frazę nazwą przypisaną do serwera SQL Database). Zaznacz opcję Use SQL Server Authentication i wpisz nazwę użytkownika oraz hasło przypisane do serwera przy jego tworzeniu. Zaznacz pole wyboru Save My Password. Z listy rozwijanej poniżej opcji Select Or Enter A Database Name (wybierz lub wpisz nazwę bazy danych) wybierz AdventureWorks2012. Kliknij OK, aby zamknąć okno dialogowe Connection Properties. Ekran powinien wyglądać podobnie do pokazanego na rysunku 6-33.
Rysunek 6-33 Definiowanie źródła danych raportu jako AdventureWorks2012 w Microsoft Azure SQL Database
Korzystanie z projektów Visual Studio Report Server
i . Kliknij Next. 9 . Na stronie Design The Query (projektowanie zapytania) wpisz kod pokazany
wcześniej w Listingu 6-3 w polu Query String (lub skopiuj go z pliku pobranego z witryny powiązanej z książką). Ekran powinien wyglądać podobnie jak na rysunku 6-34.
Rysunek 6-34 Tworzenie zapytania zwracającego szczegóły zamówień wraz z informacjami terytorialnymi
10 . Kliknij Next. 11 . Na stronie Select The Report Type (wybieranie typu raportu) wybierz Matrix i kliknij Next.
12 . Po wyświetleniu strony Design The Matrix (projektowanie macierzy) wykonaj
poniższe działania: a . Przeciągnij pole TotalSales z obszaru Available Fields (dostępne pola) i upuść
je na liście Details (szczegóły). b . Przeciągnij pole Year i upuść na liście Columns (kolumny). c . Przeciągnij pole Country i upuść je na liście Rows (wiersze). d . Przeciągnij pole TerritoryName i upuść je na liście Rows, poniżej pola Country.
177
178
Rozdział 6: Raportowanie w chmurze
e . Zaznacz pole wyboru Enable Drilldown (włącz drążenie w głąb). Okno Report
Wizard powinno wyglądać tak, jak na rysunku 6-35.
Rysunek 6-35 Projektowanie układu macierzy
f . Kliknij Next. 13 . Na stronie Choose The Matrix Style (wybieranie stylu macierzy) zaakceptuj ustawie-
nia domyślne, klikając Next. 14 . W polu Report Server na stronie Choose The Deployment Location (wybieranie loka-
lizacji wzdrożenia) wpisz http://.cloudapp.net/reportserver (zastępując nazwą przypisaną do maszyny wirtualnej) i kliknij Next. 15 . W polu tekstowym Report Name na stronie końcowej kreatora wpisz Annual Sales
By Territory. 16 . Kliknij Finish, aby zakończyć działanie kreatora.
Kreator wygeneruje raport pokazany na rysunku 6-36. Można tu zauważyć, że Visual Studio udostępnia wiele takich samych funkcjonalności, jak znane już z Report Builder. Mamy tu obszar projektowania raportu, uzupełniony po lewej panelem Report Data (rozwiniętym na rysunku 6-36, aby pokazać źródło i zestaw danych), a u dołu o grupy wierszy i kolumn zdefiniowanych dla macierzy. (Zwróćmy uwagę na hierarchię country-territory (kraj-region) w grupach wierszy). Narzędzie projektowe zawiera też kartę Preview (podgląd), umożliwiającą uruchomienie raportu lokalnie, bez jego wdrażania na serwerze.
Korzystanie z projektów Visual Studio Report Server
Rysunek 6-36 Projekt utworzony przez Report Server Project Wizard, otwarty w widoku projektowania
Kreator jest doskonałym narzędziem do szybkiego zebrania razem wszystkich elementów raportu, ale niemal zawsze konieczne jest jakieś dostosowanie lub dopasowanie generowanego układu. W przypadku naszego raportu z firmy winiarskiej nie poświęcaliśmy zbyt wiele uwagi formatowaniu liczb, ale użytkownicy biznesowi zazwyczaj chcą widzieć liczby prezentowane w sposób, który się naprawdę liczy – jako pieniądze!
Formatowanie danych numerycznych przy użyciu Report Designer W celu sformatowania sum całkowitej sprzedaży jako danych walutowych wykonaj następujące działania: 1 . Prawym klawiszem myszy kliknij kolumnę [Sum(TotalSales)] i wybierz polecenie Text Box Properties (właściwości pola tekstowego).
2 . Kliknij Number w lewym panelu nawigacyjnym okna dialogowego. 3 . Kliknij Currency (waluta) na liście Category. 4 . Zmień opcję Decimal Places (miejsca dziesiętne) na 0 (podawanie końcówek
w zestawieniach zbiorczych jest często uważane za irytujące). 5 . Zaznacz pole wyboru Use 1000 Separator (użyj separatorów tysięcy). Okno dialo-
gowe Text Box Properties powinno wyglądać podobnie jak na rysunku 6-37.
179
180
Rozdział 6: Raportowanie w chmurze
Rysunek 6-37 Formatowanie pola wartości walutowych w macierzy
6 . Kliknij OK.
Ustawiliśmy już wszystkie parametry, zatem możemy kliknąć kartę Preview w górnej części okna. Początkowo raport wyświetli tylko sześć wierszy, gdyż hierarchia kraj-region jest zwinięta i pokazywane są informacje zagregowane na poziomie kraju. Jak się okazuje, baza danych AdventureWorks zawiera tylko po jednym regionie dla każdego kraju z wyjątkiem USA, w których istnieją regiony zdefiniowane jako Central, Northeast (północny wschód), Northwest (północny zachód), Southeast (południowy wschód) oraz Southwest (południowy zachód). Kliknięcie znaku plus (+) obok skrótu US powoduje rozwinięcie tych regionów i wyświetlenie sum sprzedaży dla poszczególnych regionów w USA, jak na rysunku 6-38.
Korzystanie z projektów Visual Studio Report Server
Rysunek 6-38 Podgląd funkcjonalności drążenia w głąb
Dodawanie wykresu słupkowego do raportu Uzupełnienie raportu o wykresy jest bardzo łatwe. Język RDL obsługuje wiele różnych typów wykresów, w tym wykresy kolumnowe, słupkowe, liniowe i powierzchniowe. Narzędzie projektowania raportów Visual Studio pozwala zdefiniować dane dla wykresu i dostosować jego właściwości, takie jak opcje 3D, widoczność poszczególnych komponentów, wypełnienie, obramowanie czy cieniowanie. Dla przykładu dodamy do raportu wykres kolumnowy, który będzie odzwierciedlał te same informacje, co pokazane w macierzy. Wykres będzie zatem pokazywał całkowitą sprzedaż dla każdego kraju (bez możliwości drążenia w głąb na poziom regionu) poprzez wszystkie lata. Będziemy musieli powiększyć obszar roboczy raportu, aby umieścić wykres poniżej tabeli danych. W celu skonfigurowania danych wykresu przypiszemy pole TotalSales jako jego wartości, pole Country jako kategorie, a pole Year jako serie. W celu utworzenia wykresu kolumnowego wykonaj poniższe działania: 1 . Kliknij kartę Design w górnej części okna, aby opuścić podgląd raportu i powrócić
do trybu projektowania. 2 . Kliknij dolną krawędź obszaru projektowego i pociągnij w dół, aby powiększyć
wysokość tego obszaru. Potrzebna jest znacząca ilość wolnego miejsca w pionie, aby pomieścić wykres. 3 . Kliknij VIEW | Toolbox, aby wyświetlić pasek narzędzi (o ile nie jest jeszcze
widoczny).
181
182
Rozdział 6: Raportowanie w chmurze
4 . Kliknij i przeciągnij element Chart (wykres) z paska narzędzi i upuść go w obsza-
rze projektowym, bezpośrednio pod macierzą przy lewej krawędzi. 5 . W oknie dialogowym Select Chart Type (wybieranie typu wykresu) domyślnie
wybrany jest typ Column (rysunek 6-39). Kliknij OK, aby zaakceptować ten wybór.
6 . Kliknij uchwyt wymiarowania po prawej stronie wykresu i przeciągnij go w pra-
wo, aby rozszerzyć wykres na pełną szerokość strony. 7 . Kliknij bezpośrednio wewnątrz wykresu, aby otworzyć panel Chart Data (dane
wykresu). 8 . W sekcji Values (wartości) kliknij zielony znak plus i wybierz TotalSales. 9 . W sekcji Category Groups kliknij znak plus i wybierz Country. 10 . W sekcji Series Groups kliknij znak plus i wybierz Year. Okno projektanta powinno
wyglądać tak jak na rysunku 6-40.
Korzystanie z projektów Visual Studio Report Server
Rysunek 6-40 Wybieranie wartości, grup kategorii i serii definiujących dane wykresu
11 . Dostosuj etykiety: a . Kliknij napis Chart Title, aby zaznaczyć pole tekstowe, a następnie kliknij
ponownie, by wejść do trybu edycji. Zastąp domyślny tekst Chart Title własnym tytułem (na przykład By Country), po czym naciśnij Enter. b . W analogiczny sposób przejdź do edycji tytułu osi pionowej (tekst zostanie tymczasowo obrócony do położenia poziomego, dzięki czemu łatwiej można go edytować). Zastąp domyślny tytuł Axis Title bardziej zrozumiałym opisem, na przykład Total Sales (całkowita sprzedaż) i naciśnij Enter. c . Zmień treść opisu osi poziomej na Country i naciśnij Enter. 12 . Kliknij kartę Preview.
Wykres zostanie wykreślony poniżej tabeli z liczbami, automatycznie dostosowując swoje położenie, jeśli zaczniemy drążenie w głąb w macierzy. Inaczej mówiąc, jeśli rozwiniemy wpis US w macierzy, aby pokazać dane dla poszczególnych regionów, wykres przesunie się niżej, jak widać na rysunku 6-41.
183
184
Rozdział 6: Raportowanie w chmurze
Rysunek 6-41 Podgląd raportu z wykresem kolumnowym
Wdrażanie raportu w usłudze SSRS na maszynie wirtualnej Microsoft Azure Wcześniej, przy tworzeniu raportu za pomocą kreatora, dostarczyliśmy do niego adres URL usługi SSRS. Adres ten jest przechowywany we właściwościach projektu i można go zmienić w dowolnej chwili, modyfikując właściwość TargetServerURL. Aby móc przejrzeć właściwości, można kliknąć projekt w panelu Solution Explorer prawym klawiszem myszy i wybrać Properties. Jak widać na rysunku 6-42, okno dialogowe Property Pages (strony właściwości) pokazuje pole TargetServerURL ustawione na adres URL podany w kreatorze, ale widać tam też kilka innych ciekawych właściwości. Na przykład można zauważyć właściwość TargetReportFolder ustawioną na wartość AWReporting. Oznacza to, że podczas wdrażania sam raport (czyli plik Annual Sales By Territory.rdl) zostanie umieszczony wewnątrz folderu AWReporting (która to nazwa domyślnie odzwierciedla nazwę projektu, ale można ją tu zmienić, jeśli to potrzebne). W celu zamknięcia okna dialogowego bez wprowadzania zmian należy kliknąć Cancel.
Korzystanie z projektów Visual Studio Report Server
Rysunek 6-42 Wyświetlanie właściwości projektu Report Server
Aby wdrożyć raport w usłudze SSRS na maszynie wirtualnej, wykonaj poniższe działania: 1 . Prawym klawiszem myszy kliknij projekt AWReporting w panelu Solution Explorer
i wybierz polecenie Deploy (wdróż). 2 . W wyświetlonym monicie wpisz nazwę konta administratora (WineAdmin
w naszym przykładzie) oraz hasło przypisane do maszyny wirtualnej, jak na rysunku 6-43.
Rysunek 6-43 Wprowadzanie informacji logowania w celu wdrożenia raportu
3 . Kliknij OK. Po zakończeniu operacji Visual Studio wyświetli komunikat w oknie
Output, jak na rysunku 6-44.
185
186
Rozdział 6: Raportowanie w chmurze
Rysunek 6-44 Informacje zwrotne o udanym wdrożeniu
Uruchamianie raportu w przeglądarce W celu wykonania raportu w przeglądarce za pośrednictwem strony Report Manager wykonaj poniższe działania: 1 . Otwórz nowe okno przeglądarki. 2 . W pasku adresu wpisz http://.cloudapp.net/reports (zastępując
me> nazwą maszyny wirtualnej) i naciśnij Enter. 3 . Jeśli pojawi się okno dialogowe Windows Security z pytaniem o poświadczenia,
wpisz WineAdmin i hasło dla konta administracyjnego maszyny wirtualnej. Zostanie wyświetlona strona startowa Report Manager z łączami do wszystkich dostępnych folderów i raportów. W tym momencie powinien być tam widoczny jeden folder podrzędny AWReporting, utworzony przez Visual Studio podczas wdrażania raportu, widoczny na rysunku 6-45.
Rysunek 6-45 Strona startowa Report Manager z łączem do folderu AWReporting
Korzystanie z projektów Visual Studio Report Server
4 . Kliknij łącze AWReporting, aby przejść do tego folderu. 5 . Kliknij łącze Annual Sales By Territory, aby wyświetlić raport.
Jak widać na rysunku 6-46, raport wygląda i działa w przeglądarce tak samo, jak wcześniej w podglądzie prezentowanym wewnątrz Visual Studio.
Rysunek 6-46 Wyświetlanie finalnego raportu w przeglądarce Internet Explorer
Ten prosty przykład demonstruje podstawowe kroki wymagane przy pracy z SSRS. Bez względu na to, czy wybierzemy narzędzie Report Builder, czy zbudujemy projekt Visual Studio Report Server, konieczne jest zdefiniowanie źródeł danych i zestawów danych i rozmieszczenie ich w raportach (plikach RDL). Tworzony raport można przejrzeć lokalnie i wprowadzić niezbędne poprawki, zanim zostanie wdrożony w chmurze. Teraz, gdy wdrożyliśmy już przykładowe raporty, musimy zastanowić się nad zagadnieniem zabezpieczeń.
187
188
Rozdział 6: Raportowanie w chmurze
Implementowanie zabezpieczeń raportu Usługa SSRS nigdy nie akceptuje żądań przekazywanych anonimowo. Każdy użytkownik lub aplikacja, uzyskujący dostęp do serwera raportów, wymagają uwierzytelnienia. Domyślnie SSRS używa zintegrowanego uwierzytelniania Windows, co oznacza, że do logowania na serwerze wykorzystywane są standardowe konta Windows (lokalne lub Active Directory). W tym rozdziale wykorzystywaliśmy takie uwierzytelnianie dla konta WineAdmin utworzonego jako konto administratora maszyny wirtualnej (w tym scenariuszu dane konta są przechowywane przez VM, choć często wybierany jest wariant umieszczenia ich w oddzielnej maszynie wirtualnej skonfigurowanej jako kontroler domeny, dzięki czemu konta są współdzielone przez wszystkie maszyny wirtualne przyłączone do domeny). Możemy oczywiście utworzyć więcej kont użytkowników. W ten sposób różne osoby mogą uzyskiwać dostęp do raportów przy użyciu swoich własnych poświadczeń. Uwierzytelnienie Windows jest wygodne i łatwe w stosowaniu, ale nie jest najlepszym wyborem w każdej sytuacji. SSRS wspiera również kilka innych typów uwierzytelniania, w tym uwierzytelnianie podstawowe (basic), oparte na formularzach i niestandardowe rozwiązania. Uwierzytelnianie podstawowe koduje nazwę użytkownika i hasło w postaci jawnego tekstu (jako ciąg base-64 w nagłówku HTTP), zatem może być uważane za „bezpieczne” jedynie wtedy, gdy zaszyfrujemy cały kanał transmisyjny w celu uniemożliwienia odczytania nagłówka, zazwyczaj poprzez użycie Secure Sockets Layer (SSL). Uwierzytelnianie oparte na formularzach jest rozszerzeniem zabezpieczeń, którego można użyć do zarządzania własnym magazynem użytkowników. Magazyn ten może być tabelą bazy danych lub plikiem tekstowym (konfiguracyjnym). Jeśli występują szczególne wymagania, których nie można spełnić żadnym ze standardowych typów uwierzytelniania, można zaimplementować własne rozwiązanie. Jest to zaawansowany scenariusz, który wymaga utworzenia własnego kodu i znaczącej wiedzy w zakresie zabezpieczeń ASP.NET. Autoryzacja jest czymś oddzielnym i różniącym się od uwierzytelnienia. Gdy użytkownik zostanie już uwierzytelniony, to, co może, a czego nie może zrobić, kontrolowane jest poprzez przypisanie do roli, zdefiniowane za pomocą strony Report Manager. Najmniej uprzywilejowaną rolą jest Browser (przeglądanie), która pozwala użytkownikom jedynie na wyświetlanie folderów i raportów. Najbardziej zaawansowaną rolą jest Content Manager (menedżer zawartości), pozwalająca użytkownikom na publikowanie raportów i dająca pełne prawa (włącznie z usuwaniem) do folderów, raportów i ich definicji. Użytkownicy przypisywani są do ról dla wskazanych raportów lub folderów, co pozwala określić, czy użytkownik może uzyskać dostęp do określonego zasobu i jakie operacje może wykonać (na przykład usunąć raport lub utworzyć nowy). Możliwe jest także tworzenie grup użytkowników i przypisanie tych grup do odpowiednich ról. W ten sposób można przypisać jednolite uprawnienia wielu kontom użytkowników i – generalnie – jest to zalecany sposób zarządzania
Wyłączanie maszyny wirtualnej SSRS
uprawnieniami, gdyż przyznanie (lub odebranie) uprawnień dla określonego konta sprowadza się do uczynienia tego konta członkiem odpowiedniej grupy. DODatkOwe infOrmacje Zabezpieczenia w SSRS są bardzo wyrafinowane i potencjalnie złożone. Dokumentacja online dostępna w portalu MSDN zawiera szczegółowe i pogłębione omówienie zabezpieczeń SSRS, z którym warto się zapoznać przy wybieraniu modelu zabezpieczeń dla konkretnych wymagań. Dokumentacja ta jest dostępna pod adresem http://msdn.microsoft.com/en-us/library/bb522728.aspx.
Wyłączanie maszyny wirtualnej SSRS Zanim zakończymy pracę z tym rozdziałem, zdecydowanie polecamy zamknięcie (wyłączenie) maszyny wirtualnej utworzonej do hostowania SSRS. W przeciwnym razie nasza subskrypcja będzie stale obciążana – nawet jeśli żadni użytkownicy nie tworzą ani nie przeglądają raportów. Aby zamknąć maszynę wirtualną, wykonaj poniższe działania: 1 . Zaloguj się w portalu Microsoft Azure. Zostanie wyświetlona strona ALL ITEMS. 2 . Kliknij łącze VIRTUAL MACHINES w lewym panelu. 3 . Kliknij maszynę wirtualną, aby ją zaznaczyć (kliknąć należy gdziekolwiek w wier-
szu, z wyjątkiem kolumny nazwy, gdyż wówczas portal wyświetli stronę Quick Start tej maszyny wirtualnej). 4 . Kliknij przycisk SHUT DOWN (zamknij) w dolnej części strony. 5 . Kliknij YES w monicie potwierdzenia.
VM używa wirtualnego dysku, który jest przechowywany w Microsoft Azure Blob Storage, zatem zachowuje swój stan, gdy zostanie wyłączona. Gdy pojawi się potrzeba ponownego dostarczania raportów, trzeba po prostu uruchomić VM z portalu zarządzania Microsoft Azure, aby usługa SSRS stała się dostępna.
Podsumowanie W tym rozdziale przedstawiliśmy podstawy SQL Server Reporting Services (SSRS) i pokazaliśmy, jak utworzyć maszynę wirtualną (VM) w Microsoft Azure z zainstalowanym oprogramowaniem SSRS w celu implementacji raportowania w chmurze. Zaczęliśmy od utworzenia VM i skonfigurowania jej na potrzeby usługi SSRS, definiując adresy URL usługi raportowania i strony Report Manager. Następnie użyliśmy narzędzia Report Builder do utworzenia prostego raportu z bazy danych WineCloudDb.
189
190
Rozdział 6: Raportowanie w chmurze
W dalszej części posłużyliśmy się bardziej złożoną bazą danych AdventureWorks w celu utworzenia raportu w Visual Studio jako projektu Report Server. Po pobraniu wtyczki SSDT Business Intelligence dla Visual Studio 2012 wykorzystaliśmy kreator Report Server Project Wizard do utworzenia źródła i zestawu danych i zaprojektowania układu. Po wykonaniu pewnych dostosowań i dołączeniu wykresu do raportu wdrożyliśmy go w usłudze SSRS na maszynie wirtualnej Microsoft Azure, bezpośrednio z wnętrza Visual Studio. Rozdział zakończyliśmy bardzo ogólnym omówienie zagadnień zabezpieczeń, uwierzytelniania i autoryzacji użytkowników. Bez wątpienia tematyka SSRS i RDL obejmuje bardzo wiele elementów, które warto poznać, jednak wykraczają one poza tematykę tej książki. Jednak w tym momencie Czytelnik zna już najważniejsze koncepcje i funkcjonalności i dysponuje podstawami do dalszego poznawania tych technik i rozwijania umiejętności budowania raportów w chmurze.
ROZDZI AŁ 7
Microsoft Azure SQL Data Sync Leonard Lobel
P
latforma Microsoft Azure udostępnia specjalną usługę o nazwie Microsoft Azure SQL Data Sync (synchronizacja danych). Usługi tej można użyć do automatycznego wykrywania zmian dokonanych w jednej bazie danych i replikowania tych zmian do innej bazy (lub dowolnej liczby innych baz danych). Rozdział ten zaczniemy od ogólnego przedstawienia Microsoft Azure SQL Data Sync, po czym zademonstrujemy serię procedur, które pozwalają wykorzystać tę usługę chmur w rozmaitych, choć typowych scenariuszach. Uwaga W tym rozdziale będziemy odwoływać się do usługi Microsoft Azure SQL Data Sync po prostu poprzez termin SQL Data Sync. Dodatkowo przypominamy, że zgodnie z zasadą przedstawioną w rozdziale 1 termin SQL Database odnosi się do baz danych Microsoft Azure SQL Database w chmurze, podczas gdy terminu SQL Server używamy, gdy chodzi o lokalną (w siedzibie firmy) instalację oprogramowania SQL Server.
Poznawanie SQL Data Sync SQL Data Sync jest (przynajmniej w czasie pisania tych słów) bezpłatną usługą Microsoft Azure, zapewniającą automatyczną synchronizację wewnątrz zbioru baz danych. Można sobie wyobrazić wiele typowych sytuacji, w których taka usługa jest przydatna, na przykład: ■ ■ ■ ■ ■
Eksportowanie danych przygotowanych w siedzibie firmy do aplikacji w chmurze Importowanie danych z chmury do aplikacji lokalnych Współużytkowanie danych pomiędzy aplikacją uruchomioną lokalnie i w chmurze Wzajemne udostępnianie danych pomiędzy wieloma lokalizacjami Skalowanie rozwiązania przy użyciu chmury
W kolejnych podrozdziałach omówimy te scenariusze i wyjaśnimy, jak można wykorzystać SQL Data Sync do implementacji rozwiązania dla każdego z nich. 191
192
Rozdział 7: Microsoft Azure SQL Data Sync
ważne Usługa SQL Data Sync jest dostępna jako „wydanie wstępne” (preview) dostępne dla wszystkich subskrybentów Microsoft Azure, zatem nie jest gwarantowane wsparcie firmy Microsoft. Zazwyczaj nie zalecamy używania rozwiązań wstępnych, takich jak SQL Data Sync, w aplikacjach produkcyjnych (podobnie jak czyni to firma Microsoft), głównie z tego powodu, że można się spodziewać udostępnienia nowocześniejszych i bardziej zaawansowanych rozwiązań tego typu w dalszej perspektywie czasowej. Tym niemniej SQL Data Sync jest obecnie jedyną usługą synchronizacji danych dla SQL Database oraz SQL Server, dostępną w Microsoft Azure. Jest też bardzo łatwa w użyciu i niezawodna, o czym mogli przekonać się użytkownicy korzystający z niej od jej pierwszego udostępnienia w roku 2007 (gdy usługa nosiła jeszcze nazwę SQL Azure Data Sync). Istnieje wiele doniesień o udanym wdrożeniu SQL Data Sync w środowiskach produkcyjnych wielu użytkowników, a nawet (w specjalnych okolicznościach) o uzyskiwaniu ograniczonej pomocy ze strony firmy Microsoft. Trzeba jednak powtórzyć, że w przypadku wstępnego wydania oprogramowania nie istnieją żadne gwarancje. Konieczne jest staranne rozważenie wszystkich za i przeciw, zanim zdecydujemy się na zastosowanie SQL Data Sync i zintegrowanie jej z rozwiązaniem produkcyjnym.
Konfigurowanie i korzystanie z SQL Data Sync jest bardzo proste. Wszystko odbywa się wewnątrz portalu Microsoft Azure – nie są potrzebne żadne lokalnie zainstalowane narzędzia. Za pośrednictwem portalu możemy wskazać bazy danych, które mają być synchronizowane, a nawet określić zestawy danych (wybrane tabele i kolumny w nich). Można również wybrać interwał czasowy, określający, jak często SQL Data Sync będzie wykonywać synchronizację danych, a tym samym kontrolujący to, jak bardzo aktualna będzie synchronizowana baza danych. Jedynym przypadkiem, w którym konieczne będzie zainstalowanie czegoś lokalnie, jest konfigurowanie lokalnej bazy danych SQL Server dla konfiguracji. Wymaga to zainstalowania niedużego komponentu agenta, lekkiej usługi systemu Windows, która wykonuje rejestrację lokalnych baz danych w SQL Data Sync. Zbiór baz danych, które mają być synchronizowane, (nazywany referencyjnymi bazami danych) definiowany jest wewnątrz grupy synchronizacji (sync group). Referencyjne bazy danych w grupie synchronizacji mogą obejmować dowolną liczbę lokalnych baz SQL Server (w siedzibie), dowolną liczbę baz danych w chmurze (SQL Database) albo dowolną kombinację jednych i drugich. Wewnątrz grupy synchronizacji jedna baza danych jest desygnowana jako oś (hub), zaś wszystkie pozostałe działają jako ramiona, zatem całość ma postać dobrze znanego modelu „oś i szprychy” (hub-and-spoke). W naszym omówieniu będziemy odnosić się do szprych modelu jako klientów, gdyż takiej terminologii używa sama usługa SQL Data Sync i jej dokumentacja. Pomiędzy hubem i każdym klientem można monitorować i aplikować zmiany w jednym kierunku (z huba do klienta lub odwrotnie) lub dwukierunkowo. Jeśli zostanie włączona dwukierunkowa synchronizacja pomiędzy
Poznawanie SQL Data Sync
hubem i wieloma klientami, zmiany wykonane w hubie są wypychane do wszystkich klientów. Modyfikacja danych na dowolnym kliencie jest najpierw przekazywana do huba, a następnie wypychana do wszystkich pozostałych klientów. Jeśli te same dane zostaną zmienione w dwóch miejscach pomiędzy kolejnymi przebiegami synchronizacji, możemy kontrolować to, która z nich „wygra”, definiując zachowania rozwiązywania konfliktów dla grupy synchronizacji. Jedynym wymaganiem w tym modelu jest to, że baza danych pełniąca rolę huba musi być bazą SQL Database (czyli musi być bazą danych działającą w chmurze). Lokalna baza danych SQL Server nie może działać jako hub grupy synchronizacji. Wszystkie pozostałe bazy referencyjne w grupie (klienci) mogą być albo innymi bazami SQL Database w chmurze, albo lokalnymi (w siedzibie) bazami SQL Server.
Eksportowanie danych z SQL Server do SQL Database Usługa SQL Data Sync daje nam możliwość synchronizowania danych pomiędzy lokalną (w siedzibie firmy) instalacją SQL Server a bazą danych Microsoft Azure SQL Database w chmurze. Funkcjonalność ta jest idealnym rozwiązaniem, gdy mamy już działające aplikacje i ich dane i projektujemy nowe rozwiązanie oparte na chmurze, które musi używać tych samych danych (być może tylko części) – danych, które zostały zgromadzone i przygotowane w lokalnej instalacji. W tym scenariuszu usługę SQL Data Sync można wykorzystać w trybie jednokierunkowej synchronizacji, od klienta SQL Server do huba SQL Database (rysunek 7-1). Chmura
Aplikacja
W siedzibie
SQL Database
Aplikacja
SQL Server
Rysunek 7-1 Jednokierunkowe publikowanie danych przygotowywanych na instalacji SQL Server w siedzibie do SQL Database w chmurze
193
194
Rozdział 7: Microsoft Azure SQL Data Sync
Zmiany wykonywane lokalnie w bazie SQL Server będą automatycznie replikowane do SQL Database w chmurze. Jednak aplikacja działająca w chmurze nie będzie w żaden sposób wpływała na bazę SQL Server w siedzibie firmy, gdyż przy jednokierunkowej synchronizacji usługa SQL Data Sync nie będzie monitorować huba (czyli bazy danych SQL Database) pod kątem zmian; tym samym nigdy nie będzie przesyłać modyfikacji do klienckiej bazy SQL Server.
Importowanie danych z SQL Database do SQL Server Równie często możemy mieć do czynienia z dokładnie odwrotnym scenariuszem. W tym przypadku będzie to aplikacja oparta na chmurze, która wstawia, aktualizuje i usuwa dane z SQL Database i dane te są wymagane przez aplikacje działające w siedzibie firmy. Możemy na przykład mieć lokalne rozwiązanie Business Intelligence (BI), analizujące dane gromadzone w chmurze i przekazywane do lokalnej bazy danych SQL Server przez usługę SQL Data Sync. W tym scenariuszu trzeba utworzyć jednokierunkową synchronizację w przeciwnym kierunku (od huba SQL Database do klienta SQL Server), co ilustruje rysunek 7-2. Poprzez zmianę kierunku synchronizacji SQL Data Sync będzie monitorować tylko SQL Database pod kątem występowania zmian i następnie wypychać te zmiany do lokalnej bazy SQL Server. Aplikacja działająca w siedzibie nie będzie mogła w żaden sposób wpływać na bazę danych w chmurze. Chmura
Aplikacja
W siedzibie
SQL Database
Aplikacja
SQL Server
Rysunek 7-2 Jednokierunkowe publikowanie danych przetwarzanych w chmurze w SQL Database do lokalnej bazy SQL Server
Poznawanie SQL Data Sync
Współużytkowanie danych w wielu lokalizacjach Istnieją również inne sytuacje, w których zarówno aplikacje w siedzibie, jak i w chmurze operują na współużytkowanej bazie danych – w tym przypadku potrzebna jest pełna, dwukierunkowa synchronizacja. Możliwy jest też bardziej rozbudowany scenariusz, w którym występuje kilka lokalizacji w siedzibie. Mogą to być różne oddziały przedsiębiorstwa, filie, sklepy, restauracje, hotele i tak dalej. Rysunek 7-3 prezentuje tylko dwie lokalizacje w siedzibie, ale oczywiście może być ich znacznie więcej. W siedzibie Aplikacja
Chmura
SQL Server
Aplikacja
SQL Database
Aplikacja
SQL Server
Rysunek 7-3 Dwukierunkowe publikowanie współużytkowanych danych pomiędzy wieloma lokalizacjami za pośrednictwem centralnego huba umieszczonego w chmurze
W przypadku posiadania wielu lokalizacji w każdej z nich może działać jej własny zbiór aplikacji, używający danych przechowywanych w lokalnej bazie SQL Server. W niektórych sytuacjach wymagane jest współużytkowanie danych przez te różne lokalizacje SQL Server (w siedzibie, a ściślej – w wielu siedzibach). Innymi słowy, każda lokalizacja zawiera pewne dane, które muszą być synchronizowane, aby były dostępne w innych lokalizacjach (na przykład mogą być to dane katalogu produktów). W takim przypadku SQL Data Sync wykorzystuje hub jako pośrednika, przez którego dane są synchronizowane w obu kierunkach. Zmiany są najpierw replikowane z lokalizacji w siedzibie do huba, a następnie wypychane do pozostałych lokalizacji. W ten sposób SQL Data Sync może zaktualizować każdą lokalizację zmianami wykonanymi w dowolnej z nich.
195
196
Rozdział 7: Microsoft Azure SQL Data Sync
Innym typowym scenariuszem jest wykorzystanie SQL Database w chmurze jako lokalizacji agregującej (łączącej) dane pochodzące z wielu lokalizacji. W takim przypadku można wykorzystać SQL Data Sync do pobierania danych specyficznych dla poszczególnych lokalizacji i zebrania ich razem w scentralizowanej bazie SQL Database. Następnie można utworzyć opartą na chmurze aplikację, wykorzystującą te zagregowane dane. To tylko jeden przykład, jak SQL Data Sync może zapewnić doskonałe wyniki poprzez zebranie rozproszonych danych w pojedynczej bazie SQL Database. Aplikacja w chmurze może nawet aktualizować dane w SQL Database (zarówno dane współużytkowane, jak i specyficzne dla poszczególnych lokalizacji) i następnie użyć SQL Data Sync do przesyłania tych zmian z powrotem; usługa będzie wysyłać wspólne dane do wszystkich lokalizacji, zaś dane specyficzne dla lokalizacji tylko do odpowiednich miejsc.
Skalowanie usług Na koniec możliwe jest również synchronizowanie wielu baz danych działających w chmurze, jak na rysunku 7-4. Może to działać w powiązaniu z wcześniej opisanymi scenariuszami i obejmować jedną lub więcej lokalizacji w siedzibie, co ilustruje lewa część diagramu. Jednak jest to w pełni opcjonalne – lokalna baza danych SQL Server nie jest nigdy wymagana do działania usługi SQL Data Sync.
W siedzibie
Chmura
Aplikacja
Aplikacja SQL Database
SQL Server
Aplikacja
Aplikacja
SQL Database SQL Database Aplikacja
SQL Server
Aplikacja
SQL Database
Rysunek 7-4 Synchronizowanie wielu baz danych w chmurze w wielu centrach danych Microsoft Azure
Poznawanie SQL Data Sync
Dzięki utrzymywaniu wielu kopii tych samych danych w chmurze (zarówno w jednym centrum danych, jak i potencjalnie w wielu różnych centrach) można uzyskać znaczące zwiększenie wydajności (przeskalowanie usługi). Możemy na przykład utworzyć jedną lub więcej replik podstawowej transakcyjnej bazy danych (często nazywanej bazą OLTP od online transactional processing – przetwarzanie transakcyjne w trybie online), utrzymując obie kopie w tym samym centrum danych (co ilustrują dwie instancje SQL Database w centralnej części diagramu). Następnie możemy wykorzystać replikę do przeprowadzania analiz i generowania raportów, bez dodatkowego obciążania „żywej” bazy OLTP. Przyjęcie takiego podejścia znacznie zmniejsza wymagania wobec głównej bazy danych, która musi być w stanie reagować na przychodzące żądania, być może bardzo intensywne. Bazy danych OLTP są skoncentrowane na (i starannie dostosowane do tego) wstawianie, aktualizowanie i usuwanie małych porcji danych wewnątrz „atomowych” transakcji (czyli krótkich serii operacji, które albo kończą się powodzeniem, albo są odrzucane w całości). Choć zdarzają się też żądania odczytu, jest ich stosunkowo niewiele i zazwyczaj dotyczą małych ilości danych. Ponieważ raportowanie często obejmuje stosowania intensywnych, długotrwałych zapytań odczytu, zazwyczaj ma negatywny (a często krytycznie negatywny) wpływ na wydajność, jeśli odwołuje się bezpośrednio do bazy OLTP. Dla porównania, gdy już baza OLTP i jej replika zostaną zsynchronizowane, utrzymanie tej zgodności ma stosunkowo niewielki wpływ na działanie podstawowej bazy, gdyż zapytania dotyczą tylko najświeższych zmian, które wystąpiły od poprzedniego przebiegu synchronizacji. Jedną z najcenniejszych cech platformy Microsoft Azure jest to, że firma Microsoft utrzymuje swoje centra danych w wielu regionach na całym świecie. Dzięki temu łatwiej można rozproszyć nasze aplikacje geograficznie, jeśli i gdy pojawi się potrzeba skalowania na tym poziomie. W ten sposób można utrzymywać aplikacje (i powiązane z nimi dane) fizycznie bliżej użytkowników korzystających z tych aplikacji. W takim przypadku usługa SQL Data Sync może zostać użyta do zachowania zgodności replikowanych baz danych (lub wybranych fragmentów tych baz danych), aby te same dane były dostępne we wszystkich instancjach naszej aplikacji, co ilustruje prawa strona rysunku 7-4. ważne Choć sama usługa SQL Data Sync jest bezpłatna (w czasie pisania tych słów), nasza subskrypcja Microsoft Azure zostanie obciążona opłatami za transfer danych pomiędzy różnymi centrami danych (patrz rozdział 2, „Konfiguracja i ceny”). Co więcej, należy się liczyć też z pewnym wpływem na wydajność wynikającym z dodatkowego ruchu sieciowego przekraczającego granice centrów danych. Z tych względu należy w miarę możliwości ograniczyć synchronizację, aby obejmowała tylko tę część bazy danych (minimalną liczbę tabel i kolumn), która bezwzględnie musi być dostępna globalnie.
197
198
Rozdział 7: Microsoft Azure SQL Data Sync
Narzędzie Microsoft Azure Traffic Manager SQL Data Sync ułatwia synchronizowanie baz danych dla aplikacji hostowanych w wielu centrach danych Microsoft Azure, ale właściwe przekierowanie użytkowników do aplikacji uruchomionej w najbliższym centrum danych to inna sprawa. Choć routing jest zagadnieniem wykraczającym poza tematykę tego rozdziału, trzeba mieć świadomość, że Microsoft Azure udostępnia usługę o nazwie Traffic Manager (menedżer ruchu), która ma na celu obsługę właśnie tego zagadnienia. Traffic Manager udostępnia funkcjonalność równoważenia obciążenia dla aplikacji uruchomionych w Microsoft Azure w wielu centrach danych (zauważmy, że jest to funkcja odrębna i dodatkowa w stosunku do równoważenia obciążeń, które uzyskujemy wewnątrz indywidualnego centrum danych przy korzystaniu z maszyn wirtualnych). Zasadniczo polega to na tym, że cały zbiór serwerów rozmieszczony w różnych centrach danych Microsoft Azure jest umieszczony za infrastrukturą DNS, pozwalającą na obsługę niezbędnych przekierowań. Następnie możemy wdrożyć aplikacje w wielu centrach danych, wykorzystując SQL Data Sync do replikowania bazy danych we wszystkich instancjach aplikacji, po czym użyć usługi Traffic Manager, aby kierować użytkowników do tego wystąpienia aplikacji, które działa w najbliższym centrum danych, opierając się na fizycznej lokalizacji użytkowników. Choć korzystanie z Traffic Manager w połączeniu z SQL Data Sync nie jest konieczne, jest to zdecydowanie zalecana opcja. Istnieją wprawdzie rozwiązania innych firm, które w analogiczny sposób wykorzystują DNS do kierowania użytkowników we właściwe miejsce na podstawie ich lokalizacji, ale rozwiązania te często są kosztowne i ich właściwa implementacja może być bardzo złożona. Natomiast działanie Traffic Manager jest stosunkowo proste w obsłudze, a przynajmniej w chwili pisania tych słów, usługa ta jest nadal w trybie wstępnym i dostępna bez opłat. Więcej informacji na temat Traffic Manager zawiera dokument dostępny pod adresem http://www.windowsazure.com/en-us/services/traffic-manager.
Tworzenie bazy SQL Database Na początek wykorzystamy narzędzie SQL Server Data Tools (SSDT) do szybkiego utworzenia bazy danych WineCloudDb, podobnej do używanej wcześniej w tej książce. Procedura zakłada, że wcześniej został utworzony serwer SQL Database, do którego można uzyskać dostęp przez zaporę, zgodnie z omówieniem zawartym w rozdziale 1. Jeśli serwer ten jeszcze nie istnieje, należy utworzyć go teraz, ustawiając odpowiednie reguły zapory zapewniające dostęp do niego z maszyny lokalnej (patrz „Tworzenie serwera” w rozdziale 1). Jak widać w Listingu 7-1, WineCloudDb jest prostą bazą zawierającą tabele Wine i Customer oraz kilka wierszy danych.
Tworzenie bazy SQL Database
Uwaga Ponieważ procedura nie robi nic poza utworzeniem bazy i wykonaniem skryptu, można równie dobrze wykonać ją przy użyciu SQL Server Management Studio (SSMS) zamiast Visual Studio i SSDT. Analogicznie można wybrać utworzenie bazy danych w portalu Microsoft Azure i użycie portalu zarządzania SQL Database do wykonania skryptu. W istocie jest to kwestia preferencji – należy po prostu użyć tego narzędzia, które jest wygodniejsze i gotowe do użycia w danym momencie. lisTing 7-1 Skrypt tworzący elementy bazy danych WineCloudDb CREATE TABLE Wine( WineId int IDENTITY PRIMARY KEY, Name nvarchar(50) NOT NULL, Category nvarchar(15) NOT NULL, Year int); CREATE TABLE Customer( CustomerId int IDENTITY PRIMARY KEY, FirstName nvarchar(50) NOT NULL, LastName nvarchar(50) NOT NULL, FavoriteWineId int, CONSTRAINT FK_Customer_Wine FOREIGN KEY (FavoriteWineId) REFERENCES Wine(WineId)); SET IDENTITY_INSERT Wine ON; INSERT Wine (WineId, Name, Category, Year) VALUES (1, 'Chateau Penin', 'Bordeaux', 2008), (2, 'McLaren Valley', 'Cabernet', 2005), (3, 'Mendoza', 'Merlot', 2010), (4, 'Valle Central', 'Merlot', 2009); SET IDENTITY_INSERT Wine OFF; SET IDENTITY_INSERT Customer ON; INSERT Customer (CustomerId, FirstName, LastName, FavoriteWineId) VALUES (1, 'Jeff', 'Hay', 4), (2, 'Mark', 'Hanson', 3), (3, 'Jeff', 'Phillips', 2); SET IDENTITY_INSERT Customer OFF;
Aby utworzyć bazę danych WineCloudDb przy użyciu Visual Studio 2013, wykonaj poniższe kroki: 1 . Uruchom Visual Studio 2013. 2 . Jeśli panel SQL Server Object Explorer (eksplorator obiektów SQL Server) nie jest
widoczny, kliknij menu VIEW i wybierz SQL Server Object Explorer. 3 . W panelu SQL Server Object Explorer prawym klawiszem myszy kliknij węzeł SQL Server i wybierz polecenie Add SQL Server, aby wyświetlić dobrze znane okno dialogowe Connect To Server.
199
200
Rozdział 7: Microsoft Azure SQL Data Sync
4 . W tym oknie dialogowym wykonaj następujące działania: a . W polu Server Name wpisz .database.windows.net. Jest to w pełni
kwalifikowana nazwa serwera SQL Database, w której frazę należy zastąpić nazwą przypisaną do serwera. b . W sekcji Authentication (uwierzytelnianie) wybierz SQL Server Authentication z listy rozwijanej (SQL Database nie obsługuje uwierzytelniania Windows). c . W polach Login i Password wpisz nazwę użytkownika i hasło przypisane do administratora serwera podczas jego tworzenia. d . Kliknij przycisk Connect. Serwer pojawi się jako zwinięty węzeł w panelu SQL Server Object Explorer. 5 . Rozwiń węzeł serwera w panelu SQL Server Object Explorer. 6 . Rozwiń węzeł Databases. 7 . Jeśli obecna jest poprzednia wersja bazy WineCloudDb, utworzona podczas pracy
we wcześniejszych rozdziałach, usuń ją teraz: a . Prawym klawiszem myszy kliknij istniejącą bazę WineCloudDb i wybierz Delete. b . Kliknij OK, aby potwierdzić usuwanie. 8 . Prawym klawiszem myszy kliknij węzeł Databases i wybierz polecenie Add New Database.
9 . Wpisz nazwę WineCloudDb i naciśnij Enter. Po chwili nowa baza danych pojawi
się w panelu SQL Server Object Explorer. 10 . Prawym klawiszem myszy kliknij bazę danych WineCloudDb i wybierz New Query,
aby otworzyć okno zapytania. 11 . Wpisz kod pokazany w Listingu 7-1 do okna zapytania (albo skopiuj go z pliku
pobranego z witryny powiązanej z ksiażką). 12 . Naciśnij Ctrl+Shift+E, aby wykonać skrypt (albo naciśnij ikonę z przyciskiem
odtwarzania w pasku narzędzi okna zapytania). 13 . Zamknij Visual Studio (nie trzeba zapisywać skryptu).
Korzystanie z SQL Data Sync Reszta tego rozdziału zawiera procedury, które zademonstrują proces tworzenia grupy synchronizacji i konfigurowania usługi SQL Data Sync dla wielu różnych scenariuszy przedstawionych w poprzednim podrozdziale. Rozpoczniemy od utworzenia prostej grupy replikującej bazę danych WineCloudDb do innej bazy w Microsoft Azure. Następnie zajmiemy się dodawaniem lokalnej instancji SQL Server do grupy synchronizacji. W dalszej części zajmiemy się również rozwiązywaniem konfliktów oraz konfigurowaniem harmonogramu automatycznej synchronizacji.
Korzystanie z SQL Data Sync
Tworzenie grupy synchronizacji Jako minimum, grupa synchronizacji wymaga jednej bazy danych SQL Database (jako huba) i co najmniej jednej bazy danych SQL Database lub SQL Server, z którą ma być wykonywana synchronizacja. W kolejnych kilku procedurach utworzymy pustą bazę WineCloudDb na nowym serwerze SQL Database, a następnie przygotujemy grupę synchronizacji zawierającą już wypełnioną bazę (hub) oraz pustą bazę. Skonfigurujemy synchronizację dwukierunkową, dzięki czemu usługa SQL Data Sync najpierw wykona replikację huba do pustej bazy, a następnie będzie powielać zmiany pomiędzy obiema bazami. Aby uniknąć dodatkowych opłat naliczanych dla subskrypcji Microsoft Azure podczas realizacji tych procedur, nowy serwer utworzymy w tym samym centrum danych, które aktualnie hostuje WineCloudDb. Z tego samego względu grupę synchronizacji również utworzymy w tym samym regionie. Jest to idealne rozwiązanie, jeśli chodzi o skalowanie w poziomie (podniesienie wydajności), ale równie łatwo można utworzyć nowy serwer w innym miejscu, jeśli chcemy osiągnąć geograficzne rozproszenie bazy danych i lepiej obsługiwać użytkowników rozrzuconych po całym świecie. W istocie na potrzeby tego ćwiczenia nie musimy nawet tworzyć nowego serwera; można użyć tego samego serwera, na którym znajduje się baza WineCloudDb. SQL Data Sync umożliwia również synchronizowanie dwóch baz SQL Databases na tym samym serwerze. Tym niemniej utworzymy dodatkowy serwer, a to z tego względu, że gdybyśmy chcieli umieścić drugą bazę danych na tym samym serwerze, musielibyśmy inaczej nazwać replikę (na przykład WineCloudDb2). Uwaga W rozdziale 1 utworzyliśmy już serwer, otworzyliśmy porty w zaporze i utworzyliśmy bazę danych. Choć poniższe instrukcje są bardzo podobne do tych pokazanych wówczas, Czytelnik może nadal zechcieć wrócić do podrozdziału „Tworzenie serwera” w rozdziale 1 ze względu na zamieszczone tam zrzuty ekranowe i szczegółowe wskazówki, których nie powtarzamy w tym miejscu.
Aby utworzyć nowy serwer, wykonaj poniższe działania: 1 . Zaloguj się w portalu Microsoft Azure pod adresem https://manage.windowsazu-
re.com. Zostaniesz przekierowany do głównej strony portalu ALL ITEMS. 2 . Kliknij SQL DATABASES w panelu nawigacyjnym po lewej. 3 . Kliknij łącze SERVERS w górnej części strony. 4 . Kliknij przycisk ADD w dolnej części strony. 5 . Wpisz nazwę logowania administratora oraz hasło, a następnie ponownie wpisz
hasło w celu potwierdzenia.
201
202
Rozdział 7: Microsoft Azure SQL Data Sync
wskazówka Aby uprościć ćwiczenia, można użyć tej samej nazwy logowania (w naszych przykładach saz) i hasła, które zostało przypisane do pierwszego serwera. Jednocześnie trzeba podkreślić, że takie działanie zdecydowanie nie jest zalecane w prawdziwym środowisku produkcyjnym.
6 . Wybierz region z listy rozwijanej. Jak wyjaśniliśmy wcześniej, należy wybrać ten
sam region, w którym zlokalizowany jest pierwszy serwer, aby uniknąć obciążania opłatami za transfer danych pomiędzy różnymi centrami danych. 7 . Upewnij się, że pole wyboru ALLOW WINDOWS AZURE SERVICES TO ACCESS THE SERVER jest nadal zaznaczone. Ustawienie to pozwala na dostęp do serwera usłu-
gom Microsoft Azure – takim jak SQL Data Sync. 8 . Kliknij ikonę potwierdzenia w prawym dolnym rogu okna dialogowego, aby
zatwierdzić ustawienia. 9 . Odczekaj, aż status nowego serwera zmieni się z „creating” (tworzenie) na „star-
ted” (uruchomiony). Następnie otworzymy zaporę Microsoft Azure, choć z technicznego punktu widzenia jest to opcjonalne. SQL Data Sync nie wymaga otwierania zapory Microsoft Azure, aby móc wykonywać synchronizację. Jednak, co wyjaśniliśmy w rozdziale 1, konieczne jest otwarcie zapory dla adresu IP komputera lokalnego, jeśli chcemy mieć dostęp do serwera z portalu zarządzania SQL Database (z którego będziemy korzystać w dalszych procedurach) i innych narzędzi (takich jak SQL Server Management Studio lub SSDT w Visual Studio). W celu otwarcia zapory wykonaj następujące działania: 1 . Kliknij nazwę nowego serwera. 2 . Kliknij łącze CONFIGURE w górnej części strony. 3 . Kliknij ADD TO THE ALLOWED IP ADDRESSES na prawo od wykrytego adresu IP
komputera lokalnego. 4 . Kliknij przycisk SAVE w dolnej części strony. 5 . Kliknij przycisk powrotu (wielką strzałkę wskazującą w lewo), aby powrócić
do strony SQL DATABASES. Teraz możemy utworzyć pustą bazę danych na nowym serwerze. W tym celu wykonaj poniższe działania: 1 . Kliknij łącze DATABASES w górnej części strony. 2 . Kliknij przycisk NEW u dołu strony. 3 . Kliknij QUICK CREATE.
Korzystanie z SQL Data Sync
4 . W polu DATABASE NAME wpisz WineCloudDb (możemy użyć tej samej nazwy, jak
już istniejąca baza danych, gdyż będzie ona umieszczona na innym serwerze). Uwaga Warto zauważyć, że jeśli wykonujemy skalowanie w poziomie, aby rozdzielić aktywność OLTP od aktywności analityczno-raportowej, powinniśmy użyć tego samego serwera. W tej sytuacji konieczne jest nadanie replice odmiennej, unikatowej nazwy, którą mogłoby być coś w rodzaju WineCloudReportingDb.
5 . Wybierz serwer utworzony w poprzedniej procedurze z listy rozwijanej SERVER. 6 . Kliknij CREATE SQL DATABASE.
Po kilku chwilach zostanie utworzona nowa baza danych WineCloudDb. W tym momencie jest ona jeszcze zupełnie pusta, ale niedługo będzie zawierać te same tabele z tymi samymi danymi, które możemy znaleźć w istniejącej bazie WineCloudDb na pierwszym serwerze. W tym celu musimy utworzyć grupę synchronizacji, skonfigurować reguły i uruchomić ręczną synchronizację. Podczas tworzenia grupy synchronizacji trzeba zdefiniować źródłową bazę danych (hub) oraz pierwszą bazę kliencką. W celu utworzenia grupy synchronizacji wykonaj poniższe działania: 1 . Kliknij przycisk ADD SYNC w dolnej części strony, po czym wybierz polecenie New Sync Group, jak na rysunku 7-5.
Rysunek 7-5 Tworzenie nowej grupy synchronizacji
203
204
Rozdział 7: Microsoft Azure SQL Data Sync
2 . Na stronie Sync Group Basic Settings (ustawienia podstawowe grupy synchronizacji)
wykonaj poniższe kroki: a . W polu NAME wpisz WineCloudSyncGroup. b . Z listy rozwijanej REGION wybierz ten sam region, w którym zlokalizowane
są obydwa serwery. Strona powinna wyglądać podobnie do pokazanej na rysunku 7-6.
Rysunek 7-6 Określanie nazwy grupy i wybieranie regionu
c . Kliknij przycisk ze strzałką w prawo. 3 . Na stronie Define Sync Hub wykonaj poniższe kroki: a . Z listy rozwijanej HUB DATABASE wybierz bazę danych WineCloudDb urucho-
mioną na pierwszym serwerze (tę bazę, która zawiera już pewne dane). b . Wpisz nazwę logowania administratora serwera i jego hasło w polach HUB USER NAME oraz HUB PASSWORD. c . Pozostaw opcję CONFLICT RESOLUTION (rozwiązywanie konfliktów) w ustawieniu domyślnym Hub Wins (hub wygrywa). (Zagadnienie rozwiązywania konfliktów omówimy niedługo). Strona powinna wyglądać podobnie do pokazanej na rysunku 7-7.
Korzystanie z SQL Data Sync
Rysunek 7-7 Konfigurowanie źródłowej bazy danych (huba) Uwaga Ustawienie rozwiązywania konfliktów nie może zostać zmienione po utworzeniu grupy synchronizacji. Jeśli konieczna jest zmiana, konieczne jest usunięcie grupy synchronizacji i ponowne jej utworzenie.
d . Kliknij przycisk ze strzałką w prawo. Ze względu na sposób, w jaki portal wyko-
nuje weryfikację tej strony, konieczne może być odczekanie chwili po kliknięciu i następnie ponowne kliknięcie. 4 . Na stronie Add A Reference Database (dodaj bazę referencyjną) wykonaj poniższe
działania: a . Z listy rozwijanej REFERENCE DATABASE wybierz bazę danych WineCloudDb
uruchomioną na nowym serwerze (dopiero co utworzoną pustą bazę). Można zauważyć, że baza wybrana jako hub nie jest dostępna na tej liście rozwijanej. b . Wpisz nazwę logowania administratora oraz hasło w polach USER NAME i PASSWORD. c . Pozostaw domyślne ustawienie opcji SYNC DIRECTION (kierunek synchronizacji) – Bi-Directional (dwukierunkowo). Strona powinna wyglądać podobnie do pokazanej na rysunku 7-8.
205
206
Rozdział 7: Microsoft Azure SQL Data Sync
Rysunek 7-8 Konfigurowanie klienckiej bazy danych Uwaga Pozostałe ustawienia kierunku synchronizacji to jednokierunkowo od huba do klienta oraz jednokierunkowo od klienta do huba (różne scenariusze jednokierunkowe zostały omówione na początku rozdziału). Warto też zauważyć, że ustawienia kierunku synchronizacji nie można zmienić po utworzeniu grupy. Jeśli konieczna jest zmiana kierunku, należy usunąć bazę kliencką z grupy synchronizacji i dodać ją ponownie z odpowiednim ustawieniem.
d . Kliknij przycisk ze znakiem wyboru, aby zatwierdzić ustawienia. Ponownie
konieczne będzie odczekanie chwilę na weryfikację hasła i ponowne kliknięcie przycisku. Jak widać na rysunku 7-9, grupa synchronizacji zostaje w tym momencie utworzona, ale nie jest jeszcze gotowa (status not ready). Stan ten pozostanie niezmieniony, dopóki nie skonfigurujemy grupy przy użyciu reguł synchronizacji. Można również zauważyć, że w w górnej części portalu pojawiło się trzecie łącze SYNC po standardowych pozycjach DATABASES oraz SERVERS. Po utworzeniu przynajmniej jednej grupy synchronizacji łącze to kieruje do widoku zarządzania wszystkimi grupami.
Korzystanie z SQL Data Sync
Rysunek 7-9 Nowo utworzona grupa synchronizacji
Tworzenie reguł synchronizacji Po utworzeniu grupy synchronizacji przychodzi czas na zdefiniowanie reguł synchronizacji. Zasadniczo reguły te definiują zestaw danych, który określa dokładnie, które tabele i kolumny mają być synchronizowane we wszystkich bazach referencyjnych w grupie. Dopóki choć jeden zestaw nie zostanie zdefiniowany, grupa synchronizacji pozostanie w stanie Not Ready (nie gotowa), zatem zajmiemy się tym teraz. Aby skonfigurować reguły synchronizacji i zdefiniować zestaw danych, wykonaj poniższe czynności: 1 . Kliknij nazwę grupy synchronizacji WineCloudSyncGroup. Spowoduje to wyświet-
lenie widoku REFERENCES (odwołania), pokazującego wszystkie bazy danych zawarte w grupie, jak na rysunku 7-10. Zwróć uwagę, że status każdej z baz to Not Ready, co spowodowane jest brakiem jakichkolwiek reguł synchronizacji. 2 . Kliknij łącze SYNC RULES w górnej części strony. 3 . Kliknij DEFINE SYNC RULES poniżej komunikatu informującego, że nie ma jeszcze
żadnych reguł.
207
208
Rozdział 7: Microsoft Azure SQL Data Sync
Rysunek 7-10 Strona REFERENCES zawiera listę wszystkich baz danych w grupie synchronizacji
bazę danych WineCloudDb działającą na pierwszym serwerze (tę, która zawiera już tabele i dane, a nie nową pustą). 5 . Kliknij ikonę potwierdzenia, aby zamknąć okno dialogowe. Strona SYNC RULES
pokaże wszystkie tabele wykryte w bazie danych WineCloudDb, jak na rysunku 7-11.
Rysunek 7-11 Strona SYNC RULES pokazująca wszystkie tabele w bazie danych
Korzystanie z SQL Data Sync
6 . Kliknij przycisk SELECT (wybierz) w dolnej części strony, po czym wybierz polece-
nie Select All The Columns In All The Tables (wybierz wszystkie kolumny we wszystkich tabelach), jak na rysunku 7-12.
Rysunek 7-12 Wybieranie całej bazy danych (wszystkich kolumn we wszystkich tabelach) do synchronizacji
7 . Kliknij przycisk SAVE w dolnej części strony, pokazany na rysunku 7-13.
Rysunek 7-13 Zapisywanie reguły synchronizacji
8 . Konieczne może być odczekanie kilku chwili, zanim portal znowu zacznie rea-
gować. Po zakończeniu przetwarzania kliknij łącze REFERENCES w górnej części strony. Obydwie bazy danych powinny mieć teraz ustawiony status Good (dobry), jak na rysunku 7-14.
Rysunek 7-14 Strona REFERENCES pokazuje teraz dla wszystkich baz danych w grupie synchronizacji status Good.
209
210
Rozdział 7: Microsoft Azure SQL Data Sync
9 . Kliknij ikonę powrotu (wielką strzałkę skierowaną w lewo), aby powrócić do stro-
ny SQL DATABASES dla grupy synchronizacji. Jak widać na rysunku 7-15, grupa również ma teraz status Good.
Rysunek 7-15 Strona SYNC prezentująca status Good dla grupy synchronizacji
W tym momencie usługa SQL Data Sync utworzyła już tabele w nowej bazie, dokładnie tak samo, jak zostały one zdefiniowane w źródłowej bazie danych. ważne Usługa SQL Data Sync wykonuje więcej zadań, niż tylko replikowanie tabel wybranych do synchronizacji; dodaje również specjalne obiekty do każdej bazy danych wchodzących w skład grupy synchronizacji (włącznie z lokalnymi bazami SQL Server). W celu śledzenia przyrostowych zmian danych SQL Data Sync tworzy tabelę śledzenia zmian dla każdej synchronizowanej tabeli, dodaje wyzwalacze do tabel bazowych i tworzy kilka procedur składowanych, które będą gromadzić i aplikować zmiany. Z tych względów zdecydowanie zalecane jest przetestowanie SQL Data Sync w nieprodukcyjnym środowisku w celu upewnienia się, że pojawią się jakieś niepożądane efekty uboczne w istniejących bazach danych lub aplikacjach.
Wykonywanie ręcznej synchronizacji Jak wspomnieliśmy wcześniej, usługa SQL Data Sync utworzyła już tabele w nowej bazie danych, ale jak dotąd nie wstawiła do nich żadnych wierszy danych (innymi słowy, skopiowany został tylko schemat bazy danych, ale nie same dane). Wynika to z faktu, że nie nastąpił jeszcze żaden przebieg synchronizacji, a co więcej, nie nastąpi, dopóki nie zdefiniujemy harmonogramu automatycznych synchronizacji lub ręcznie nie wywołamy takiego przebiegu.
Korzystanie z SQL Data Sync
Za chwilę utworzymy harmonogram automatyczny, ale najpierw wykonamy pierwszą ręczną synchronizację. W tym celu należy wykonać następujące działania: 1 . Kliknij przycisk SYNC w dolnej części strony, pokazany na rysunku 7-16. Po kilku
chwilach przetwarzania grupa synchronizacji powróci do statusu Good. Oznacza to, że synchronizacja zakończyła się powodzeniem.
Rysunek 7-16 Wykonywanie ręcznej synchronizacji
2 . Odczekaj kilka chwil na zakończenie przetwarzania, po czym kliknij nazwę grupy
synchronizacji WineCloudSyncGroup. 3 . Kliknij łącze LOGS (dzienniki) w górnej części strony. Portal wyświetli listę komu-
nikatów o zakończonych operacjach, a wśród nich informację o udanej synchronizacji baz danych, jak na rysunku 7-17.
Rysunek 7-17 Wyświetlanie dzienników grupy synchronizacji
Dla pewności lepiej jednak będzie przekonać się na własne oczy, że wszystko naprawdę działa jak powinno. Najlepszą metodą zrealizowania tego zadania jest monitorowanie obydwu baz obok siebie w trakcie wprowadzania indywidualnych zmian i następnie synchronizowanie tych zmian. Można to osiągnąć, otwierając dwie karty przeglądarki dla portalu SQL Database – po jednej dla każdej bazy WineCloudDb.
211
212
Rozdział 7: Microsoft Azure SQL Data Sync
Uwaga W rozdziale 1 pokazaliśmy, jak otworzyć portal SQL Database w nowej karcie przeglądarki. Choć poniższe instrukcje są bardzo podobne do pokazanych wówczas, można powrócić do rozdziału 1, gdyż tamte wskazówki zawierają zrzuty ekranowe i szczegóły, których nie powtarzamy w tym miejscu.
Aby otworzyć dwie karty w portalu SQL Database, wykonaj poniższe działania: 1 . Kliknij ikonę powrotu, aby wrócić do strony SQL DATABASES. 2 . Kliknij łącze DATABASES w górnej części strony. 3 . Kliknij pierwszą bazę danych WineCloudDb. 4 . Kliknij łącze DASHBOARD w górnej części strony. 5 . Przewiń stronę w dół i kliknij łącze MANAGE URL w sekcji przeglądowej po prawej
stronie. Zostanie otwarta nowa karta przeglądarki ze stroną logowania portalu SQL Database dla pierwszej bazy danych WineCloudDb. 6 . Na stronie logowania wpisz nazwę administratora oraz hasło i kliknij Log On.
Zostanie wyświetlona strona Summary (podsumowanie) dla tej bazy danych. 7 . Kliknij poprzednią kartę przeglądarki, aby powrócić do portalu Microsoft Azure,
z którego właśnie uruchomiłeś nową kartę. 8 . Kliknij ikonę powrotu, aby przejść do strony SQL DATABASES. 9 . Powtórz kroki 3−6 dla drugiej bazy danych WineCloudDb.
Teraz, po przygotowaniu środowiska pracy, wywołamy to samo proste zapytanie w każdej bazie, aby przejrzeć i porównać zawartość tabel. Aby wykonać zapytanie, pozostań na razie w bieżącej karcie przeglądarki, pokazującej portal zarządzania SQL Database dla drugiej bazy WineCloudDb i wykonaj poniższe działania: 1 . Kliknij New Query (nowe zapytanie) w górnej części strony, aby otworzyć okno
zapytania. 2 . Kliknij wewnątrz okna kodu i wpisz SELECT * FROM Customer. 3 . Kliknij Run w górnej części strony. SQL Database wykona zapytanie i zwróci wyni-
ki w dolnej części okna zapytania, jak na rysunku 7-18. 4 . Przejdź do karty przeglądarki z portalem zarządzania SQL Database dla pierwszej
bazy WineCloudDb. 5 . Kliknij New Query w górnej części strony. 6 . W oknie zapytania wpisz SELECT * FROM Customer. 7 . Kliknij Run. SQL Database wykona zapytanie i wyświetli wyniki, które powinny
być identyczne, jak wyniki zapytania uzyskane w drugiej bazie danych.
Korzystanie z SQL Data Sync
Rysunek 7-18 Odpytywanie zawartości tabeli Customer po pierwszej ręcznej synchronizacji
Uzyskanie identycznych wyników w obu zapytaniach jasno pokazuje, że pierwsza ręczna synchronizacja zadziałała prawidłowo i obydwie bazy są zgodne ze sobą. Teraz wykonamy pewne zmiany w danych po obu stronach i wywołamy ponowną synchronizację baz danych. Aby wykonać te modyfikacje, pozostań w bieżącej karcie przeglądarki i wykonaj następujące działania: 1 . W nowym wierszu poniżej wyrażenia SELECT wpisanego poprzednio napisz
UPDATE Customer SET FavoriteWineId = 2 WHERE CustomerId = 1. 2 . Kliknij i pociągnij myszą, aby zaznaczyć całe nowe wyrażenie UPDATE. 3 . Kliknij Run w górnej części strony. SQL Database wykona polecenie i zasygnalizu-
je, że dotyczyło ono jednego wiersza. Identyfikator ulubionego wina dla klienta o identyfikatorze równym 1 (Jeff Hay) został zmieniony z 4 na 2. 4 . Kliknij kartę przeglądarki z portalem zarządzania SQL Database dla drugiej bazy
danych WineCloudDb. 5 . W nowym wierszu poniżej wyrażenia SELECT wpisz INSERT INTO Customer
VALUES('Chris', 'Mayo', 3). 6 . Zaznacz całe wyrażenie INSERT.
213
214
Rozdział 7: Microsoft Azure SQL Data Sync
7 . Kliknij Run. SQL Database wykona wyrażenie i zasygnalizuje, że dotyczyło ono
jednego wiersza. Został utworzony nowy wiersz dla klienta Chris May z ulubionym winem o identyfikatorze równym 3. Zmodyfikowaliśmy niezależnie od siebie obie bazy danych; w jednej zaktualizowaliśmy dane klienta Jeff Hay (o identyfikatorze 1), zaś w drugiej dodaliśmy nowego klienta. Następnie wykonamy kolejną operację ręcznej synchronizacji i upewnimy się, że obie zmiany zostaną poprawnie powielone w obydwu bazach. W tym celu wykonaj poniższe działania: 1 . W przeglądarce wróć do karty otwartej w portalu Microsoft Azure. Powinna ona
nadal pokazywać stronę DASHBOARD dla jednej z baz danych WineCloudDb. 2 . Kliknij ikonę powrotu, aby wrócić do strony SQL DATABASES. 3 . Kliknij łącze SYNC u góry strony. 4 . Kliknij przycisk SYNC w dolnej części strony. Po kilku chwilach przetwarzania
grupa synchronizacji powróci do normalnego statusu Good. 5 . Kliknij kartę przeglądarki otwartą w portalu zarządzania SQL Database dla jednej
z baz danych WineCloudDb (nie ma znaczenia, której). 6 . Kliknij i pociągnij myszą, aby zaznaczyć wyrażenie SELECT. 7 . Kliknij Run. SQL Database wyświetli wyniki, które powinny odzwierciedlać zarów-
no aktualizację rekordu dla klienta Jeff Hay, jak i dodatkowy wiersz, jak na rysunku 7-19. 8 . Przejdź do karty zawierającej portal zarządzania SQL Database dla drugiej bazy
WineCloudDb. 9 . Zaznacz całe wyrażenie SELECT. 10 . Kliknij Run. SQL Database wykona zapytanie i wyświetli wyniki, które ponownie
powinny wyglądać identycznie, jak uzyskane w drugiej bazie, pokazane wcześniej na rysunku 7-19. Ponowne uzyskanie identycznych wyników dowodzi, że dwukierunkowa synchronizacja działa poprawnie. Kolejną rzeczą, którą się zajmiemy, jest rozwiązywanie konfliktów. Co się stanie, jeśli ten sam wiersz klienta zostanie w inny sposób zmodyfikowany w obydwu bazach danych w tym samym czasie (co należy rozumieć jako „pomiędzy synchronizacjami”, a niekoniecznie jednocześnie)?
Korzystanie z SQL Data Sync
Rysunek 7-19 Odpytywanie zawartości tabeli Customer po dwukierunkowej synchronizacji
Definiowanie rozwiązywania konfliktów Kiedykolwiek zdarzy się, że te same dane zostaną zmodyfikowane w różny sposób w więcej niż jednym miejscu, SQL Data Sync zawsze wybierze tylko jedną wersję tych zmian i zastąpi nią pozostałe. To, która wersja nadpisze którą, jest określane przez ustawienie rozwiązywania konfliktów ustanowione w czasie tworzenia grupy. Dostępne są dwa ustawienia: Hub Wins (hub wygrywa), będące domyślnym wyborem, oraz Client Wins (klient wygrywa). Podczas tworzenia grupy synchronizacji skonfigurowaliśmy ją, aby stosowane było ustawienie Hub Wins (zrobiliśmy to po prostu akceptując domyślną wartość, co można zobaczyć na rysunku 7-7). Tym samym, jeśli wystąpi konfliktowa zmiana dla tego samego wiersza w obu bazach danych, zmiana dokonana na hubie zastąpi tę wykonaną w bazie klienckiej. W kolejnej procedurze trzeba zwrócić uwagę na to, która karta przeglądarki jest otwarta dla bazy danych huba, a która dla bazy klienckiej. Można je rozróżnić po nazwach serwerów, które są wyświetlane w lewym górnym rogu strony portalu dla każdej z nich.
215
216
Rozdział 7: Microsoft Azure SQL Data Sync
Aby zademonstrować rozwiązywanie konfliktów, wykonaj poniższe działania: 1 . Kliknij kartę przeglądarki zawierającą portal zarządzania SQL Database dla bazy
danych huba (w tym celu sprawdź nazwę serwera w lewym górnym rogu). a . W oknie kodu usuń istniejące wyrażenie INSERT lub UPDATE (ale zostaw wyra-
żenie SELECT tak jak jest). b . W nowym wierszu poniżej wyrażenia SELECT wpisz UPDATE Customer SET
LastName = 'Mayo-Hub' WHERE CustomerId = 4. c . Kliknij i pociągnij myszą, aby zaznaczyć całe wyrażenie UPDATE. d . Kliknij Run. SQL Database wykona polecenie i zasygnalizuje, że dotyczyło ono
jednego wiersza. 2 . Przejdź do zakładki zawierającej portal zarządzania dla drugiej bazy danych
WineCloudDb (tej na nowym serwerze). a . W oknie kodu usuń istniejące wyrażenie INSERT lub UPDATE, zostawiając
wyrażenie SELECT. b . W nowym wierszu poniżej wyrażenia SELECT wpisz UPDATE Customer SET LastName = 'Mayo-Client' WHERE CustomerId = 4. c . Kliknij Run. SQL Database wykona polecenie i zasygnalizuje, że dotyczyło ono jednego wiersza – tego samego, który właśnie zmieniliśmy w bazie huba, ale z inną zmianą. 3 . Wróć do karty przeglądarki otwartej w portalu Microsoft Azure. Powinna nadal
tam być otwarta strona SYNC po ręcznej synchronizacji wykonanej w poprzedniej procedurze. 4 . Kliknij przycisk SYNC w dolnej części strony. Po kilku chwilach przetwarzania
grupa synchronizacji powróci do normalnego statusu Good. 5 . Przejdź do karty otwartej w portalu SQL Database dla bazy danych huba. a . Zaznacz całe wyrażenie SELECT. b . Kliknij Run. SQL Database wykona zapytanie i wyświetli wyniki. Jak widać
na rysunku 7-20, zmiana imienia na Mayo-Hub się utrzymała; nie została zastąpiona przez niezgodną zmianę nazwy dla tego samego wiersza w bazie klienckiej. 6 . Przejdź do karty portalu zarządzania SQL Database dla drugiej bazy WineCloudDb
(bazy klienckiej na nowym serwerze). a . Zaznacz całe wyrażenie SELECT. b . Kliknij Run. Jak można zobaczyć na rysunku 7-21, zmiana imienia na Mayo-
Client została nadpisana przez zmianę wykonaną w tym samym czasie w bazie huba.
Korzystanie z SQL Data Sync
Rysunek 7-20 Zmiana wykonana na hubie pozostaje po synchronizacji ze względu na ustawienie Hub Wins dla rozwiązywania konfliktów.
Rysunek 7-21 Zmiana po stronie bazy klienckiej została nadpisana przez zmianę wykonaną po stronie huba
217
218
Rozdział 7: Microsoft Azure SQL Data Sync
Gdyby rozwiązywanie konfliktów zostało ustawione na Client Wins, wystąpiłaby sytuacja odwrotna; zmiana wykonana w bazie klienckiej zostałaby zachowana w tej bazie, zaś zmiana po stronie huba zostałaby zastąpiona tak, aby odzwierciedlała zmianę wykonaną po drugiej stronie. Gdy grupa synchronizacji zawiera tylko jedną bazę kliencką, zachowanie jej przy obydwu ustawieniach jest całkowicie przewidywalne i zawsze działa tak, jak właśnie pokazaliśmy. Jednak w momencie, gdy zaangażowane są dwie lub więcej baz klienckich i pojawiają się konfliktowe zmiany w tych bazach (ale nie w hubie), nie można przewidzieć rezultatów rozwiązywania konfliktu bez względu na ustawienie: ■
■
W przypadku ustawienia Hub Wins pierwsza zmiana, która zostanie zapisana w hubie, zostaje zachowana. Każda konfliktowa zmiana wykonana w dowolnej z pozostałych baz klienckich zostanie odrzucona, gdyż jest w tym momencie niezgodna ze zmianą wykonaną (już) na hubie. W rezultacie zmiana, która (przypadkowo) została wczytana do huba jako pierwsza, będzie propagowana do pozostałych klientów. W przypadku ustawienia Client Wins konfliktowe zmiany wykonane na poszczególnych bazach klienckich są kolejno zapisywane w hubie, przy czym każda zastępuje poprzednią, co ostatecznie prowadzi do sytuacji, gdy zmiany wykonane przez ostatniego synchronizowanego klienta są propagowane do wszystkich pozostałych.
W obydwu przypadkach ostatecznego „zwycięzcy” nie da się przewidzieć, gdyż kolejność, w jakiej zmiany klienckie są zapisywane na hubie, nie jest deterministyczna i może zmieniać się pomiędzy jednym a drugim przebiegiem synchronizacji. Jedyna przewidywalna sytuacja w przypadku wielu klientów występuje wtedy, gdy jedna z konfliktowych zmian jest wykonana po stronie huba i ustawienie rozwiązywania konfliktów jest ustawione na Hub Wins. W tym przypadku zmiany dokonane w bazach klienckich zawsze zostaną nadpisane przez zmianę w hubie.
Tworzenie harmonogramu automatycznej synchronizacji Po wykonaniu kilku ręcznych synchronizacji i upewnieniu się, że wszystko przebiega zgodnie z oczekiwaniami, nie będziemy już chcieli więcej robić tego samodzielnie. Wygodniejsze będzie zdefiniowanie harmonogramu automatycznego wykonywania synchronizacji przez usługę SQL Data Sync. Usługa SQL Data Sync wspiera prosty mechanizm automatyzacji, który można po prostu włączyć lub wyłączyć. Jeśli automatyzacja synchronizacji jest włączona, częstość wykonywania może zostać ustawiona na dowolną wartość z zakresu od (około) pięciu minut do jednego miesiąca. Oznacza to, że najmniejsza rozpiętość czasowa w synchronizowanej grupie może wynosić pięć minut.
Korzystanie z SQL Data Sync
Uwaga Słowo około użyte w powyższym akapicie wynika z faktu, że usługa nie gwarantuje wykonania synchronizacji precyzyjnie w określonym momencie czasowym (co wynika m.in. z ruchu sieciowego, bieżącego obciążenia zaanagażowanych serwerów i wielu innych czynników). Na przykład możemy ustawić częstość synchronizacji na 10 minut, ale może się okazać, że pomiędzy dwoma kolejnymi przebiegami upłynęło 11 minut.
W celu ustawienia harmonogramu automatycznej synchronizacji wykonywanej co 10 minut wykonaj poniższe działania: 1 . Kliknij zakładkę przeglądarki z otwartym portalem Microsoft Azure. Powinna
w niej nadal być widoczna strona SYNC po wykonaniu ręcznej synchronizacji w poprzedniej procedurze. 2 . Kliknij nazwę grupy synchronizacji WineCloudSyncGroup. 3 . Kliknij łącze CONFIGURE u góry strony. 4 . Obok nagłówka AUTOMATIC SYNC kliknij przełącznik ON. 5 . W polu SYNC FREQUENCY (częstość synchronizacji) wpisz 10. 6 . Kliknij w dowolnym miejscu strony. Jest to konieczne, aby zabrać fokus z pola
tekstowego SYNC FREQUENCY, dzięki czemu w dolnej części strony pojawi się przycisk SAVE, jak pokazano na rysunku 7-22.
Rysunek 7-22 Konfigurowanie harmonogramu automatycznej synchronizacji, wykonywanej co 10 minut
219
220
Rozdział 7: Microsoft Azure SQL Data Sync
7 . Kliknij SAVE.
Harmonogram został zdefiniowany. Aby go przetestować, wykonaj poniższe działania: 1 . Kliknij zakładkę przeglądarki wyświetlającą portal zarządzania SQL Database dla
jednej z baz danych WineCloudDb (nie ma znaczenia, której). 2 . W oknie kodu usuń istniejące wyrażenie INSERT lub UPDATE (ale pozostaw
wyrażenie SELECT). 3 . W nowym wierszu poniżej wyrażenia SELECT wpisz UPDATE Customer SET
LastName = 'Mayo-Auto' WHERE CustomerId = 4. 4 . Zrób sobie przerwę na 10 minut (lub więcej). Polecamy kieliszek wina (lub dwa) –
zasłużyłeś na to! 5 . Wykonaj wyrażenie SELECT w obydwu zakładkach przeglądarki z otwartymi
oknami portalu zarządzania SQL Database (dla huba i klienta) i upewnij się, że nazwisko brzmi teraz Mayo-Auto w obydwu bazach danych. W czasie dziesięciominutowej przerwy wystąpił przebieg automatycznej synchronizacji, który skopiował zmianę do drugiej bazy danych. W tym momencie możemy pozostawić mechanizm samemu sobie i pozwolić usłudze na synchronizowanie zawartości baz co 10 minut, choć nadal możliwe będzie wykonanie ręcznej synchronizacji w dowolnym momencie, jeśli wystąpi taka potrzeba. Można też zmienić interwał lub wyłączyć automatyczną synchronizację. Każdy przebieg synchronizacji (zarówno ręczny, jak i automatyczny) jest rejestrowany i można go zweryfikować, klikając łącze LOGS, co pokazaliśmy wcześniej na rysunku 7-17.
Tworzenie lokalnej bazy SQL Server Po uzyskaniu działającego synchronizowania zawartości dwóch baz SQL Databases w chmurze jesteśmy gotowi do dodania lokalnej (w siedzibie) bazy danych SQL Server do grupy synchronizacji. Wymaga to zainstalowania lokalnie specjalnej usługi agenta, w której będzie można zainstalować bazę danych w siedzibie. Usługa SQL Data Sync w chmurze będzie uzyskiwać dostęp do lokalnych baz danych za pośrednictwem usługi agenta. Nie trzeba dodawać, że wszystko to wymaga lokalnej instalacji SQL Server. Jeśli Czytelnik ma dostęp do instancji SQL Server, w której może utworzyć lokalną bazę danych, może wykorzystać tę instancję w dalszej części ćwiczeń. W innym przypadku przed kontynuowaniem konieczne będzie zainstalowanie wydania SQL Server Express, które będzie hostowało lokalną bazę danych. Procedura instalacji krok po kroku zawarta jest we Wprowadzeniu do książki w podrozdziale „Instalowanie SQL Server Express Edition”.
Korzystanie z SQL Data Sync
Uwaga W rozdziale tym zakładamy, że używana jest instalacja SQL Server Express i że instancja ta nosi nazwę .\sqlexpress. W przypadku korzystania z innego wydania lub inaczej nazwanej instancji trzeba zastąpić nazwę .\sqlexpress zawartą w podanych instrukcjach odpowiednią nazwą używanej instancji. Na przykład przy korzystaniu z podstawowej instancji wydania SQL Server Developer na komputerze lokalnej należy po prostu podać symbol kropki (.) albo localhost. Jeśli używamy instancji nazwanej, trzeba dołączyć odwrotny ukośnik uzupełniony o nazwę instancji (na przykład .\myinstance lub localhost\myinstance).
W kolejnej procedurze utworzymy w lokalnej instancji SQL Server bazę danych o nazwie WineLocalDb. Ta lokalna baza będzie początkowo zupełnie pusta, ale szybko stanie się repliką bazy WineCloudDb, gdy już dodamy ją do grupy synchronizacji (jak widać, jest to podejście analogiczne do przyjętego wcześniej, gdy utworzyliśmy drugą bazę WineCloudDb i dołączyliśmy ją do grupy synchronizacji). W celu utworzenia lokalnej bazy danych wykonaj poniższe działania: 1 . Uruchom Visual Studio 2013. 2 . Jeśli panel SQL Server Object Explorer nie jest widoczny, kliknij menu VIEW
i wybierz polecenie SQL Server Object Explorer. 3 . W panelu SQL Server Object Explorer prawym klawiszem myszy kliknij SQL Server
i wybierz polecenie Add SQL Server, aby wyświetlić okno dialogowe Connect To Server. 4 . W polu Server Name wpisz .\sqlexpress (albo nazwę własnej lokalnej instancji
SQL Server). 5 . W polu Authentication wybierz Windows Authentication. Jeśli lokalna instancja
SQL Server nie jest skonfigurowana na obsługę uwierzytelniania Windows, wybierz SQL Server Authentication i podaj odpowiednie poświadczenia w polach Login oraz Password. Okno Connect To Server powinno wyglądać podobnie do pokazanego na rysunku 7-23. 6 . Kliknij Connect. Lokalna instancja pojawi się jako zwinięty węzeł w panelu
SQL Server Object Explorer. 7 . Rozwiń nowy węzeł. 8 . Prawym klawiszem myszy kliknij podwęzeł Databases i wybierz Add New Database
(dodaj nową bazę danych).
221
222
Rozdział 7: Microsoft Azure SQL Data Sync
Rysunek 7-23 Łączenie się z lokalną instancją wydania SQL Server Express
9 . Wpisz WineLocalDb w polu nazwy i naciśnij Enter. Nowa baza danych pojawi się
w panelu SQL Server Object Explorer, jak na rysunku 7-24.
Rysunek 7-24 Tworzenie bazy danych WineLocalDb w lokalnej instancji SQL Server
Mamy już przygotowaną pustą bazę danych WineLocalDb w siedzibie. Teraz zajmiemy się konfigurowaniem agenta synchronizacji, aby baza ta mogła uczestniczyć w grupie synchronizacji.
Korzystanie z SQL Data Sync
Tworzenie agenta synchronizacji Usługa SQL Data Sync komunikuje się z bazami danych SQL Server za pośrednictwem agenta klienckiego – specjalnej usługi lokalnej obsługującej interakcję pomiędzy lokalną bazą danych i grupą synchronizacji uruchomioną w Microsoft Azure. Dzięki takiemu podejściu usługa SQL Data Sync nie łączy się bezpośrednio z lokalną bazą danych; cała komunikacja pomiędzy oprogramowaniem zainstalowanym lokalnie a chmurą odbywa się poprzez agenta. W ten sposób usługa SQL Data Sync w chmurze może uzyskać dostęp do bazy danych SQL Server w siedzibie nawet wtedy, gdy jest ona umieszczona za zaporą (co jest typowe w środowiskach produkcyjnych). Gdy usługa komunikuje się z agentem, realizuje to poprzez połączenie szyfrowane przy użyciu unikatowego tokenu, nazywanego kluczem agenta. Bazy danych SQL Server uwierzytelniają agenta poprzez łańcuch połączenia i klucz agenta, co zapewnia wysoki poziom zabezpieczeń transmisji. W celu zainstalowania lokalnego agenta synchronizacji wykonaj poniższe działania: 1 . Zaloguj się w portalu Microsoft Azure (albo powróć do okna przeglądarki z uru-
chomionym portalem, jeśli nadal jest otwarte). 2 . Kliknij SQL DATABASES w panelu nawigacyjnym po lewej. 3 . Kliknij przycisk ADD SYNC w dolnej części strony i wybierz polecenie New Sync Agent (nowy agent synchronizacji), jak na rysunku 7-25.
Rysunek 7-25 Tworzenie agenta synchronizacji
4 . Kliknij łącze Install One Here (zainstaluj tutaj), pokazane na rysunku 7-26.
Spowoduje to otwarcie nowej karty przeglądarki ze stroną pobierania agenta.
223
224
Rozdział 7: Microsoft Azure SQL Data Sync
Rysunek 7-26 Korzystanie z okna dialogowego New Sync Agent do instalacji lokalnego agenta
5 . Kliknij wielki pomarańczowy przycisk Download. 6 . Z listy rozwijanej wybierz SQLDataSyncAgent-Preview-ENU.msi, jak na rysunku
7-27.
Rysunek 7-27 Pobieranie SQL Data Sync Agent
Korzystanie z SQL Data Sync
7 . Kliknij Next. 8 . Jeśli pojawi się wyskakujące okno ostrzeżenia, kliknij Allow Once (zezwól raz), jak
na rysunku 7-28.
Rysunek 7-28 Tymczasowe zezwalanie na pobieranie plików w razie potrzeby
9 . W monicie z zapytaniem, czy zapisać, czy uruchomić plik, wybierz Run (uru-
chom). Spowoduje to pobranie i uruchomienie kreatora instalacji Microsoft SQL Data Sync Agent Preview: a . Na powitalnej stronie kliknij Next. b . Zaakceptuj warunki licencyjne, klikając I Agree na stronie License Agreement And Privacy Information, a następnie Next.
c . Wpisz nazwę użytkownika i hasło dla lokalnego konta Windows, którego
powinna używać usługa agenta. Nazwa ta powinna być poprzedzona nazwą domeny albo komputera lokalnego, uzupełnioną o odwrotny ukośnik, jak na rysunku 7-29.
Rysunek 7-29 Konfigurowanie konta Windows, którego lokalna usługa agenta będzie używać w celu uzyskiwania dostępu do baz danych SQL Server.
d . e . f . g . h .
Kliknij Next. Na stronie Select Installation Folder zaakceptuj domyślny wybór i kliknij Next. Na stronie Confirm Installation Page kliknij Next, aby rozpocząć instalowanie. Jeśli pojawi się monit kontroli konta użytkownika, kliknij Yes (Tak). Po zakończeniu instalacji zamknij kreatora, klikając Close.
225
226
Rozdział 7: Microsoft Azure SQL Data Sync
Lokalna usługa agenta została zainstalowana. Za chwilę zarejestrujemy w niej bazę danych WineLocalDb. Najpierw jednak trzeba dokończyć konfigurację agenta w Microsoft Azure. Aby skonfigurować agenta w Microsoft Azure, wykonaj poniższe działania: 1 . Wróć do karty przeglądarki otwartej nadal w portalu Microsoft Azure na stronie New Sync Agent.
2 . W polu NAME wpisz WineSyncAgent. 3 . Z listy rozwijanej REGION wybierz region odpowiadający strefie czasowej ustawio-
nej w swoim komputerze lokalnym. Strona powinna wyglądać podobnie do pokazanej na rysunku 7-30. ważne Nie jest możliwe zarejestrowanie lokalnej bazy danych w agencie synchronizacji zlokalizowanym w innym regionie.
Rysunek 7-30 Konfigurowanie agenta synchronizacji w Microsoft Azure
4 . Kliknij ikonę zatwierdzenia w prawym dolnym rogu okna dialogowego, aby
zatwierdzić ustawienia. 5 . Po kilku chwilach agent zostanie utworzony i pojawi się w trybie offline, jak
na rysunku 7-31. 6 . Kliknij tytuł WineSyncAgent. Zostaną wyświetlone lokalne bazy danych zarejestro-
wane dla tego agenta, czyli w tym momencie będzie to pusta lista.
Korzystanie z SQL Data Sync
Rysunek 7-31 Nowy agent utworzony w Microsoft Azure
7 . Kliknij przycisk MANAGE KEY (zarządzaj kluczem) w dolnej części strony. 8 . Kliknij zielony przycisk Generate. 9 . Kliknij przycisk kopiowania do schowka na prawo od wygenerowanego klucza,
jak na rysunku 7-32. (Jeśli pojawi się monit o zezwolenie na dostęp do schowka, kliknij Allow Access).
Rysunek 7-32 Generowanie klucza dostępowego, który zostanie użyty do zarejestrowania lokalnej bazy danych SQL Server w usłudze agenta.
227
228
Rozdział 7: Microsoft Azure SQL Data Sync
Po skopiowaniu klucza dostępowego agenta do schowka ostatnim krokiem jest zarejestrowanie lokalnej bazy danych w agencie synchronizacji. W tym celu wykonaj poniższe kroki: 1 . Uruchom program Microsoft SQL Data Sync Agent Preview. W tym celu możesz
przeszukać kafelki na ekranie startowym, albo po prostu wpisać data sync agent w celu wyszukania aplikacji, po czym kliknąć znaleziony kafelek, pokazany na rysunku 7-33.
Rysunek 7-33 Uruchamianie agenta SQL Data Sync na ekranie startowym systemu Windows 8
2 . Jeśli pojawi się monit kontroli konta użytkownika, kliknij Yes (Tak). 3 . Kliknij przycisk Submit Agent Key (prześlij klucz agenta). 4 . Prawym klawiszem myszy kliknij pole tekstowe Agent Key i wybierz Paste (Wklej).
Klucz wygenerowany w portalu zostanie skopiowany do tego pola, jak pokazano na rysunku 7-34.
Rysunek 7-34 Dostarczanie klucza dostępu wygenerowanego przez usługę w chmurze do lokalnej usługi agenta
że próba połączenia z SQL Data Sync zakończyła się powodzeniem. Zamknij okno komunikatu klikając OK. 7 . Kliknij Register, aby wyświetlić okno dialogowe SQL Server Configuration.
Korzystanie z SQL Data Sync
a . W polu Authentication wybierz Windows Authentication. Jeśli lokalna instan-
cja SQL Server nie obsługuje uwierzytelniania Windows, wybierz SQL Server Authentication i podaj poprawne poświadczenia w polach Login oraz Password. b . W polu Server Name wpisz .\sqlexpress (albo nazwę lokalnej instancji SQL Server). c . W polu Database wpisz WineLocalDb. Okno dialogowe SQL Server Configuration powinno wyglądać tak jak na rysunku 7-35.
Rysunek 7-35 Okno dialogowe SQL Server Configuration służące do rejestracji lokalnej bazy danych SQL Server w usłudze SQL Data Sync
d . Kliknij Save. Baza danych zostanie zarejestrowana w lokalnej usłudze agenta,
co pokazuje rysunek 7-36.
Rysunek 7-36 Rejestrowanie bazy danych w siedzibie w usłudze agenta SQL Data Sync
229
230
Rozdział 7: Microsoft Azure SQL Data Sync
8 . Wróć do karty przeglądarki nadal otwartej na stronie Manage Access Key w portalu
Microsoft Azure. 9 . Kliknij ikonę ze znakiem zatwierdzenia w prawym dolnym rogu okna dialogowe-
go, aby zamknąć tę stronę. 10 . Strona WineSyncAgent w portalu powinna pokazywać teraz bazę danych
WineLocalDb zarejestrowaną w agencie, jak na rysunku 7-37.
Rysunek 7-37 Wyświetlanie lokalnej bazy SQL Server zarejestrowanej w agencie
Po zarejestrowaniu bazy WineLocalDb można ją już dodać do grupy synchronizacji. W tym celu wykonaj poniższe kroki: 1 . Kliknij ikonę powrotu (wielką strzałkę skierowaną w lewo), aby powrócić do stro-
ny SYNC. Jak widać na rysunku 7-38, status agenta synchronizacji zmienił się teraz z Offline na Online (być może trzeba będzie odświeżyć stronę naciskając F5, aby zobaczyć zmieniony status). 2 . Kliknij nazwę WineCloudSyncGroup. Zostaną wyświetlone wszystkie bazy referen-
cyjne tej grupy, czyli dwie bazy WineCloudDb w chmurze. 3 . Kliknij przycisk ADD w dolnej części strony, aby wyświetlić okno dialogowe Add A Reference Database.
Korzystanie z SQL Data Sync
Rysunek 7-38 WineSyncAgent pokazywany jest teraz jako online w portalu Microsoft Azure.
4 . Wykonaj następujące działania: a . W polu REFERENCE DATABASE wybierz bazę WineLocalDb pokazywaną poniżej
tytułu SQL Server Databases – WineSyncAgent, jak na rysunku 7-39.
Rysunek 7-39 Wybieranie bazy danych w siedzibie z zarejestrowanym agentem do dołączenia do grupy synchronizacji.
b . Jeśli lokalna baza danych została zarejestrowana przy użyciu uwierzytelnia-
nia Windows, żadne poświadczenia nie są wymagane i pola USER NAME oraz
231
232
Rozdział 7: Microsoft Azure SQL Data Sync
PASSWORD będą nieaktywne. W innym przypadku wpisz nazwę użytkownika
i hasło podane podczas rejestrowania bazy w 7 kroku poprzedniej procedury. c . Pozostaw domyślne ustawienie opcji SYNC DIRECTION, czyli Bi-Directional (dwukierunkowo). Strona powinna wyglądać podobnie do pokazanej na rysunku 7-40.
Rysunek 7-40 Dodawanie lokalnej bazy danych do grupy synchronizacji
d . Kliknij ikonę z symbolem potwierdzenia, aby zakończyć. 5 . Kliknij przycisk SAVE w dolnej części strony. Po kilku sekundach przetwarza-
nia baza danych zostanie dołączona do grupy synchronizacji, która teraz będzie prezentować trzy bazy (dwie bazy WineCloudDb w chmurze i jedną lokalną WineLocalDb) ze statusem Good, jak na rysunku 7-41. 6 . Odczekaj około 10 minut (interwał automatycznej synchronizacji skonfigurowany
wcześniej dla tej grupy) albo kliknij przycisk SYNC w dolnej części strony, jeśli nie chcesz czekać. Spowoduje to zaktualizowanie całej grupy, a więc również lokalnej bazy danych właśnie dodanej do grupy synchronizacji. 7 . Wróć do Visual Studio, które powinno być nadal otwarte po procedurze utworze-
nia pustej grupy WineLocalDb. 8 . Rozwiń węzeł bazy danych WineLocalDb w panelu SQL Server Object Explorer,
a następnie rozwiń podrzędny węzeł Tables. 9 . Prawym klawiszem myszy kliknij tabelę dbo.Customer i wybierz polecenie View Data (wyświetl dane). Jak widać na rysunku 7-42, tabela zawiera obecnie wszyst-
kie dane pobrane z bazy huba WineCloudDb.
Korzystanie z SQL Data Sync
Rysunek 7-41 Grupa synchronizacji zawierająca dwie bazy danych w chmurze Microsoft Azure SQL i jedną lokalną bazę SQL Server
Rysunek 7-42 Baza danych SQL Server w siedzibie zawiera teraz dane klientów zsynchronizowane z bazą WineCloudDb.
Gratulacje! Utworzyłeś właśnie w pełni funkcjonalną grupę synchronizacji, powielającą dane dwukierunkowo pomiędzy wieloma bazami danych SQL Databases w chmurze Microsoft Azure i lokalnie działającą bazą danych SQL Server. Ze względu na dwukierunkowość replikowane są zarówno zmiany wykonane w bazie huba, jak i te, które następują w jednej z klienckich baz danych (druga baza w chmurze i baza lokalna).
233
234
Rozdział 7: Microsoft Azure SQL Data Sync
Co więcej, ponieważ dla grupy synchronizacji wybrano ustawienie Hub Wins dla rozwiązywania konfliktów, zmiany wykonane w hubie zastąpią ewentualne zmiany w tym samym wierszu (wierszach) w dowolnej z baz klienckich, o ile modyfikacje te wystąpią w tym samym interwale synchronizacji. Jak wyjaśniliśmy w podrozdziale „Definiowanie rozwiązywania konfliktów”, jeśli konfliktowe zmiany wystąpią tylko w bazach klienckich, a nie w bazie huba, zmiana zapisana na hubie jako pierwsza staje się tą, która uaktualni resztę grupy synchronizacji, zaś zmiany wykonane w pozostałych bazach klienckich zostaną odrzucone. Warto poświęcić nieco czasu na eksperymenty z grupą synchronizacji i wykonywanie różnych zmian zarówno w bazie huba, jak i klienckich (włącznie ze zmianami konfliktowymi) i sprawdzanie efektów synchronizacji.
Potencjalne pułapki i najlepsze praktyki Na zakończenie rozdziału przedstawimy kilka zagadnień, które trzeba mieć na uwadze przy pracy z usługą SQL Data Sync. Istnieje kilka rzeczy, które można zrobić, aby uzyskać najlepszą możliwą wydajność, poczynając od lokalizacji baz danych w chmurze. Geograficzna lokalizacja hostowanych baz SQL Databases ma wpływ zarówno na sprawność działania, jak i na koszty (zasadniczo darmowej) usługi SQL Data Sync. W celu zminimalizowania opóźnień serwery SQL Database powinny być umieszczone w centrum danych położonych fizycznie tak blisko, jak to możliwe od miejsca instalacji lokalnej bazy SQL Server. Kolejna wskazówka to ograniczenie synchronizacji do tylko tych elementów, które muszą być zgodne. Jak pokazaliśmy, usługa SQL Data Sync nie wymaga uwzględniania całej bazy danych w grupie synchronizacji; zawsze możemy i powinniśmy wybrać tylko najmniejszą liczbę tabel i kolumn, które mają wchodzić w skład replikowanego zestawu danych. W ten sposób można znacząco zredukować czas trwania synchronizacji i związane z nią obciążenie. Inne zagadnienie, które trzeba mieć na uwadze, to częstość wykonywania synchronizacji. Jeśli próba kolejnego przebiegu synchronizacji nastąpi przed zakończeniem poprzedniego, synchronizacja zakończy się niepowodzeniem. Przy planowaniu harmonogramu trzeba więc zadbać o to, aby interwał był dostatecznie długi. Trzeba też pamiętać, że interwały te są w rzeczywistości przybliżone i że najczęstsza automatyczna synchronizacja, jaką można ustawić, odbywa się co pięć minut. Harmonogram synchronizacji może również wpływać na koszty działania SQL Database. Choć w chwili pisania tych słów firma Microsoft udostępnia SQL Data Sync jako bezpłatną usługę, naliczane opłaty zależą od ilości danych przesyłanych z centrum danych. W celu zminimalizowania kosztów warto rozważyć rozdzielenie danych na różne grupy synchronizacji w zależności od tego, jak często zmieniają się dane. Często modyfikowane, ulotne dane powinny być synchronizowane z większą częstotliwością, niż dane statyczne lub tabele wyszukiwania (lookup). Partycjonowanie grup
Podsumowanie
synchronizacji w ten sposób pozwala skonfigurować optymalny harmonogram, który pomoże obniżyć koszty dzięki rzadszemu przesyłaniu danych. Inną pułapką, której trzeba unikać przy konfigurowaniu wielu grup synchronizacji, jest sytuacja znana jako pętla synchronizacji. Występuje ona wtedy, gdy zmiana rekordu w jednej grupie synchronizacji jest nadpisywana przez drugą grupę, co daje efekt podobny do odwołania cyklicznego. Jest to zdecydowanie niepożądana sytuacja, która potencjalnie może doprowadzić do nieskończonej pętli i zużyć dostatecznie dużo zasobów, aby znacząco obniżyć wydajność. Dodatkowo będzie trzeba zapłacić za niepotrzebne przesyłanie danych do i z SQL Database. Pętli synchronizacji można uniknąć dwoma sposobami: ■
■
Projekt grup synchronizacji powinien wykluczać możliwość powstania pętli; innymi słowy, ta sama tabela nie powinna być synchronizowana przez dwie różne grupy. Określić kierunek synchronizacji, tak by sytuacja pętli nie mogła powstać.
Na koniec trzeba przypomnieć standardowe środki zabezpieczeń stosowane przez usługę SQL Data Sync: ■ ■ ■ ■
Dane są zawsze szyfrowane podczas przesyłania. Wszystkie punkty połączenia SQL Database używają uwierzytelniania SQL. Połączenia pomiędzy SQL Database i SQL Server są zawsze szyfrowane. Połączenia z SQL Server są dodatkowo zabezpieczane przy użyciu klucza agenta.
Podsumowanie W tym rozdziale przedstawiliśmy SQL Data Sync, usługę chmury Microsoft Azure, która zapewnia automatyczną replikację danych pomiędzy dowolną liczbą baz danych SQL Databases hostowanych w Microsoft Azure, a także lokalnymi bazami danych SQL Server utrzymywanymi w siedzibie firmy. Rozpoczęliśmy od wyjaśnienia architektury typu oś i szprychy, na której oparta jest usługa SQL Data Sync i omówienia różnych scenariuszy konfiguracji usługi. Należą do nich jednokierunkowa replikacja danych przygotowywanych w lokalnej bazie danych do bazy danych w chmurze lub odwrotnie oraz pełna, dwukierunkowa synchronizacja pomiędzy dowolną liczbą baz utrzymywanych zarówno w Microsoft Azure SQL, jak i lokalnie. Wykorzystując te informacje utworzyliśmy grupę synchronizacji obejmującą dwie bazy danych SQL Databases w chmurze i pokazaliśmy działanie dwóch ustawień rozwiązywania konfliktów (Hub Wins oraz Client Wins), po czym skonfigurowaliśmy harmonogram automatycznych synchronizacji, zapewniający uzgadnianie zawartości baz w regularnych odstępach czasu. Na koniec zainstalowaliśmy i skonfigurowaliśmy
235
236
Rozdział 7: Microsoft Azure SQL Data Sync
agenta synchronizacji dla lokalnej bazy danych SQL Server i dołączyliśmy ją do grupy synchronizacji, zapewniając pełną dwukierunkową replikację danych pomiędzy lokalną bazą danych i bazą SQL Database w chmurze.
ROZDZI AŁ 8
Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności Eric Boyd
W
ydajność jest ważnym, jeśli nie najważniejszym uwarunkowaniem, które trzeba uwzględnić przy projektowaniu aplikacji i systemów do rzeczywistego stosowania. Dzisiejsi użytkownicy przyzwyczaili się do uzyskiwania natychmiastowych rezultatów i ich „okno uwagi” jest bardzo wąskie, co oznacza, że aplikacje muszą być responsywne i szybko zwracać wyniki. Podstawą działania wielu systemów są dane, zazwyczaj przechowywane w relacyjnych bazach danych, takich jak SQL Database. Optymalizacja dostępu do danych często może zapewnić znaczące usprawnienie działania i poprawić wydajność całej aplikacji. W tym rozdziale zajmiemy się optymalizacją i dostrajaniem wydajności bazy danych Microsoft Azure SQL Database. Zagadnienia te obejmują zarówno optymalizację tempa wykonywania zapytań, jak i niezawodność. W celu zademonstrowania tych koncepcji potrzebna jest aplikacja stanowiąca punkt odniesienia. W drugim podrozdziale „Tworzenie API typu RESTful” utworzymy interfejs programowania aplikacji (Web API) ASP.NET, wykorzystujący dane z SQL Database przy użyciu zarówno mechanizmu ADO.NET, jak i Entity Framework (EF). Następnie będziemy usprawniać niezawodność i wydajność tego API zarządzając połączeniami z bazą danych, redukując opóźnienia i analizując inne optymalizacje, takie jak wybranie najbardziej odpowiedniej usługi magazynowej dla danych. W dalszej części rozdziału omówimy skalowanie bazy SQL Database w górę przy użyciu opcji SQL Database Premium. Ostatnie części rozdziału zostaną poświęcone skalowaniu bazy danych w poziomie przy użyciu strategii partycjonowania znanej jako łuskowanie (sharding). Entity Framework to platforma dostępu do danych firmy Microsoft, upraszczająca mapowanie obiektów bazodanowych na obiekty .NET. EF wykorzystuje wewnętrznie mechanizm ADO.NET, ale dodatkowe mapowanie obiektów relacyjnych wykonywanych przez EF powoduje spadek wydajności. Przy optymalizowaniu dostępu do danych jedną z typowych technik jest redukcja liczby poziomów abstrakcji 237
238
Rozdział 8: Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności
pomiędzy kodem naszej aplikacji a bazą danych. Bezpośrednie użycie technik niższego poziomu, takich jak ADO.NET, często pozwala podnieść wydajność dostępu do danych. Niezależnie od optymalizacji, wiele istniejących już aplikacji wykorzystuje ADO.NET jako mechanizm dostępu do danych. Z tych względów w tym rozdziale omówimy zarówno ADO.NET, jak i EF. Uwaga Rozdział ten wykorzystuje EF oraz Web API jedynie do demonstracji zagadnień wydajności. Rozdział 10, „Budowanie rozwiązania w chmurze”, zawiera więcej szczegółów na temat obydwu technologii.
Osiąganie wysokiej wydajności w chmurze Praktycznie nieograniczone zasoby sprzętowe i obliczeniowe stanowią jeden z najbardziej przekonujących argumentów za przejściem do chmury. Chociaż wielkość zasobów posiadanych i zarządzanych przez dostawcę chmury jest niewątpliwie skończona, poza momentami szczytowymi większość organizacji będzie potrzebowało jedynie nieznacznego ułamka dostępnej mocy obliczeniowej. Jednak większość aplikacji, a szczególnie typowe aplikacje do obsługi przedsiębiorstw, nie są zaprojektowane w sposób pozwalający im na wykorzystanie tej ogromnej puli sprzętowej. Większość aplikacji nie jest projektowana pod kątem skalowania horyzontalnego (często określanego terminem „skalowania w poziomie” – scaling out) – czyli „porcjowania” i rozdzielania obciążenia pomiędzy wiele serwerów i węzłów magazynowych. Zamiast tego większość przedsiębiorstw polega na zachowaniu kontroli nad sprzętem i skalowaniu w pionie (scaling up) – czyli zwiększaniu pojemności i wydajności scentralizowanych zasobów przetwarzania poprzez zakup większych i szybszych serwerów i urządzeń magazynujących. Dostawcy chmury, tacy jak firma Microsoft, zapewniają pewne możliwości skalowania w górę. W chwili pisania tych słów dostępne jednostki obliczeniowe w Microsoft Azure mieściły się w zakresie od współużytkowanego procesora 1GHz z 768 MB pamięci RAM do 16-procesorowej jednostki 2.6 GHz z pamięcią 112 GB. W przypadku usług typu „platforma jako usługa” (PaaS), takich jak SQL Database, również istnieją pewne możliwości skalowania w górę. Na przykład pojedyncza baza danych SQL Database może mieć wielkość od 100 MB do 150 GB, zaś w przypadku nowego wariantu SQL Database Premium możliwe jest zwiększenie zasobów przetwarzania pojedynczego serwera SQL Database. Microsoft Azure zapewnia zatem pewne możliwości skalowania w górę zasobów przetwarzania danych; nieszczęśliwie zawsze będzie istniała jakaś fizyczna granica, limitująca moc przetwarzania, którą można uzyskać z pojedynczego zasobu, bez względu na to, czy jest to serwer, urządzenie magazynowe, czy usługa. Aby naprawdę
Tworzenie API typu RESTful
urosnąć, musimy skalować nasze rozwiązania w poziomie. A żeby móc to zrealizować, aplikacje muszą zostać zaprojektowane w taki sposób, aby mogły zostać rozproszone pomiędzy wiele wystąpień sprzętu przetwarzającego. Jako uzupełnienie rozważań o skalowalności, ponieważ nie mamy kontroli nad konfiguracją sprzętu, na którym uruchomiona jest baza SQL Database, nie możemy skalować serwerów w analogiczny sposób, jak w naszej własnej serwerowni. A ponieważ SQL Database jest wielodostępną usługą z wieloma klientami współużytkującymi te same fizyczne zasoby, charakterystyki wydajnościowe będą się różnić od tych, które możemy uzyskać w prywatnym centrum danych. W rezultacie dostrajanie wydajności bazy danych musi być wykonywane inaczej niż w przypadku własnego centrum danych.
Tworzenie API typu RESTful Na początek utworzymy bazę danych WineCloudDb zawierającą tabele Wine oraz Customer. Następnie utworzymy nowy projekt ASP.NET typu Web Application. Ta aplikacja Web będzie zawierać ASP.NET Web API używającą mechanizmu ADO.NET dla tabeli Customer oraz Entity Framework dla tabeli Wine. W trakcie budowy tego projektu pokażemy, jak optymalizować wydajność, niezawodność i skalowalność naszego rozwiązania.
Tworzenie przykładowej bazy danych Dla celów budowy Web API w tym rozdziale utworzymy przykładową bazę danych i wypełnimy ją kilkoma rekordami danych, używając skryptu pokazanego w Listingu 8-1. Uwaga W innych rozdziałach baza danych WineCloudDb zawierała dodatkowo tabelę Order. W tym rozdziale nie będziemy jednak korzystać z tej tabeli i dlatego została pominięta w poniższym skrypcie. lisTing 8-1 Skrypt tworzący przykładową bazę WineCloudDb CREATE TABLE Wine ( WineId int PRIMARY KEY, Name nvarchar (50), Category nvarchar (15), Year int, Price money) CREATE TABLE Customer ( CustomerId int PRIMARY KEY, FirstName nvarchar(50), LastName nvarchar(15),
239
240
Rozdział 8: Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności
Aby utworzyć bazę WineCloudDb, wykonaj poniższe kroki: 1 . Uruchom SQL Server Management Studio (SSMS). W tym celu możesz przewi-
nąć ekran startowy w celu znalezienia kafelka aplikacji (w kategorii Microsoft SQL Server 2012) albo wpisać sql server management studio, aby rozpocząć wyszukiwanie, po czym kliknąć znaleziony kafelek. Po krótkiej chwili pojawi się okno dialogowe Connect To Server. 2 . W tym oknie dialogowym wykonaj poniższe działania: a . W polu Server Name wpisz .database.windows.net. Jest to w peł-
ni kwalifikowana nazwa serwera SQL Database, w której należy zastąpić nazwą przypisaną do naszego serwera. b . W polu Authentication wybierz z listy SQL Server Authentication (SQL Database nie wspiera uwierzytelniania Windows). c . W polach Login i Password wpisz nazwę użytkownika i hasło przypisane do administratora serwera. d . Kliknij przycisk Connect. 3 . Rozwiń węzeł Databases w panelu Object Explorer. 4 . Jeśi baza danych WineCloudDb istnieje po ćwiczeniach wykonanych w poprzed-
nich rozdziałach, usuń ją: a . Prawym klawiszem myszy kliknij WineCloudDb i wybierz polecenie Delete. b . W oknie Delete Object (usuwanie obiektu) kliknij OK. 5 . Utwórz nową bazę danych: a . Prawym klawiszem myszy kliknij nazwę serwera w panelu Object Explorer
i wybierz polecenie New Query, aby otworzyć nowe okno zapytania połączone z bazą danych master. b . W oknie zapytania wpisz CREATE DATABASE WineCloudDb. c . Naciśnij F5 (albo kliknij przycisk Execute w pasku narzędzi), aby utworzyć bazę danych.
Tworzenie API typu RESTful
d . Zamknij okno zapytania bez zapisywania skryptu. 6 . W panelu Object Explorer kliknij prawym klawiszem myszy Databases i wybierz
polecenie Refresh. W panelu powinien pojawić się węzeł nowej bazy WineCloudDb. 7 . Prawym klawiszem myszy kliknij bazę danych WineCloudDb i wybierz New Query,
aby otworzyć nowe okno zapytania połączone z bazą WineCloudDb. 8 . Wpisz kod pokazany w Listingu 8-1 w oknie zapytania (albo skopiuj go z plików
pobranych z witryny powiązanej z książką). 9 . Naciśnij F5, aby utworzyć schemat bazy danych i wypełnić tabele przykładowymi
danymi. Utworzona baza WineCloudDb posłuży jako źródło danych dla tworzonych API. Uwaga Konieczne było utworzenie bazy danych i jej wypełnienie w dwóch oddzielnych oknach zapytań, gdyż SQL Database nie wspiera wyrażenia USE, którego użylibyśmy w lokalnej instalacji SQL Server w celu przekierowania połączenia z bazy master na bazę WineCloudDb. Więcej informacji na temat rozbieżności pomiędzy SQL Server a Microsoft Azure SQL Database zawiera rozdział 3, „Różnice pomiędzy SQL Server a Microsoft Azure SQL Database”.
Tworzenie nowego rozwiązania Projekty Visual Studio są umieszczane wewnątrz rozwiązań (ang. solution), zatem rozpoczniemy od utworzenia pustego rozwiązania. Następnie dodamy do niego projekt ASP.NET Web Application. Projekt ten będzie zawierał budowane przez nas API. Nasze przykładowe rozwiązanie będzie zawierać tylko jeden projekt, ale Visual Studio wymaga umieszczenia projektu w rozwiązaniu. Zostałoby ono utworzone niejawnie, ale wówczas nie moglibyśmy określić jego nazwy, zatem zaczniemy właśnie od utworzenia rozwiązania. 1 . Uruchom program Visual Studio 2013. 2 . Kliknij menu FILE i wybierz polecenie New | Project; pojawi się okno dialogowe New Project.
3 . W lewej części okna dialogowego rozwiń kolejno węzły Templates (szablony)
i Other Project Types (inne typy projektów) i wybierz Visual Studio Solutions. 4 . Wybierz szablon Blank Solution, nazwij rozwiązanie WineSolution i wybierz loka-
lizację do jego zapisania, podobnie jak na rysunku 8-1.
241
242
Rozdział 8: Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności
Rysunek 8-1 Tworzenie nowego, pustego rozwiązania
5 . Kliknij OK.
W panelu Solution Explorer pojawi się wpis WineSolution (jeśli panel nie jest widoczny, kliknij menu VIEW i wybierz Solution Explorer).
Tworzenie projektu ASP .NET Przy tworzeniu nowych projektów ASP.NET w Visual Studio zalecane jest stosowanie typu projektu ASP.NET Web Application. Ten typ projektu może zawierać elementy Model-View-Controller (MVC), Web Forms oraz Web API. W kolejnych procedurach utworzymy interfejsy ASP.NET Web API w ramach projektu typu ASP.NET Web Application. Aby utworzyć nowy projekt ASP.NET, wykonaj poniższe kroki: 1 . Prawym klawiszem myszy kliknij wpis WineSolution w panelu Solution Explorer
i wybierz polecenie Add | New Project. 2 . W lewej części okna dialogowego rozwiń kolejno węzły Installed, Visual C#,
po czym zaznacz Web. 3 . Wybierz szablon ASP.NET Web Application (zazwyczaj jest on zaznaczony domyślnie). 4 . Nazwij projekt WineCloudWebApi i kliknij OK, jak na rysunku 8-2; pojawi się
okno dialogowe New ASP.NET Project.
Tworzenie API typu RESTful
Rysunek 8-2 Wybieranie projektu typu ASP.NET Web Application
5 . Wybierz szablon Web API i kliknij OK.
Rysunek 8-3 Tworzenie nowego projektu ASP.NET Web API
W ten sposób utworzyliśmy pusty projekt ASP.NET Web Application z odnośnikami do asemblacji ASP.NET Web API. Projekt ten odwołuje się również do asemblacji ASP.NET MVC, dzięki czemu można w ramach tego samego projektu budować zarówno aplikacje Web API, jak i MVC.
243
244
Rozdział 8: Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności
Dodawanie kodu pierwszego kontrolera Web API (typu Entity Framework) Po utworzeniu projektu typu ASP.NET Web Application możemy przystąpić do dodawania kontrolerów Web API. Kontrolery Web API są podobne do kontrolerów MVC pod tym względem, że odpowiadają na żądania HTTP, wysyłając odpowiedzi HTTP. Pierwszy kontroler Web API, który dołączymy do projektu, będzie używał mechanizmu Entity Framework Code First w celu uzyskiwania dostępu do danych zawartych w bazie WineCloudDb. We wcześniejszych wersjach Entity Framework modele elementów i mapowania bazy danych można było konfigurować jedynie poprzez plik EDMX, zazwyczaj przy użyciu projektanta graficznego Entity Data Model (EDM) w Visual Studio. Wraz z dodaniem funkcjonalności Code First w wersji EF 4 możemy zamiast tego wybrać tworzenie własnych klas Plain Old CLR Object7 (POCO) i skonfigurować konwencje bazy danych oraz mapowania w kodzie aplikacji. To podejście zapewnia wiele korzyści w porównaniu do korzystania z pliku EDMX. Jedną z najważniejszych przewag takiego rozwiązania jest luźniejsze powiązanie modelu z trwałą platformą. Ułatwia to testowanie modeli w izolacji od bazy danych, dołączanie dodatkowych właściwości i metod i wykorzystywanie ich na wielu warstwach aplikacji. Tworzenie klasy POCO do użycia w Entity Framework jest stosunkowo proste i istnieje tu kilka reguł, do których trzeba się stosować. Po pierwsze, klasa musi być publiczna. Po drugie, właściwości muszą być publiczne. I na koniec, typy danych modelu muszą pasować do kolumn naszej tabeli. Entity Framework Code First jest oparte na konwencjach, co oznacza wbudowanie w Entity Framework wielu wzorców. Jeśli nasz model jednostki stosuje się do tych wzorców i projektu bazy danych, Entity Framework jest w stanie automatycznie zamapować model na bazę danych bez jakiejkolwiek ręcznej konfiguracji. Model jednostki dla tabeli Wine, pokazany w Listingu 8-2, zawiera właściwości pasujące do kolumn tabeli, ale nie ma tu żadnej zależności od Entity Framework. Platforma „wie”, że właściwość WineId ma być mapowana na klucz główny tabeli Wine, gdyż nazwa ta stosuje się do konwencji wykorzystującej nazwę klasy uzupełnionej o przyrostek „Id” i że właściwość ta ma typ numeryczny albo GUID. Listing 8-3 zawiera klasę kontekstową, którą dostosujemy w celu zastąpienia domyślnej strategii nazewniczej EF. Domyślnie EF tworzy bazę danych oraz tabele używając konwencji Entity Framework i klas modelu jednostki POCO. Jednak ta strategia inicjowania bazy danych może zostać łatwo wyłączona, dzięki czemu można korzystać zarówno z podejścia „najpierw baza danych”, jak i „najpierw kod” (code-first). Mówiąc inaczej, nie musimy pozwalać EF na „odtwarzanie” (reverse-engineer) bazy danych na podstawie naszego kodu, jeśli chcemy użyć podejścia „najpierw kod”; cały czas możemy samodzielnie utworzyć bazę 7 „Stary dobry obiekt CLR”.
Tworzenie API typu RESTful
danych i nadal posłużyć się podejściem „najpierw kod”. Możemy łatwo nakazać Entity Framework, aby nie tworzył bazy danych i tabel, wywołując Database.SetInitializer (null) na końcu metody Application_Start w kodzie Global.asax.cs. Jedną z domyślnych konwencji Entity Framework Code First jest tworzenie nazw tabel jako liczby mnogiej. Oznacza to, że domyślnie Entity Framework oczekuje, że jednostka Wine będzie przechowywana w tabeli nazwanej Wines (liczba mnoga w języku angielskim). Jednak nasza baza danych WineCloudDb zawiera tabelę o nazwie Wine (liczba pojedyncza), a nie Wines. Na szczęście domyślne zachowanie można łatwo zastąpić, podmieniając metodę kontekstową EF OnModelCreating i wywołując modelBuilder.Conventions.Remove(). Usunięcie tej domyślnej konwencji pozwala dopasować nazwę klasy jednostki do nazwy tabeli i zamapować jednostkę Wine klasy POCO na tak samo nazwaną tabelę w bazie danych. DODatkOwe infOrmacje Więcej informacji na temat konwencji używanych w Entity Framework zawiera dokument dostępny pod adresem http://msdn.microsoft.com/en-us/data/ jj679962.aspx. lisTing 8-2 Klasa modelu Wine.cs using System; namespace WineCloudWebApi.Models { public class Wine { public int WineId { get; set; } public string Name { get; set; } public string Category { get; set; } public int? Year { get; set; } public Decimal? Price { get; set; } } }
lisTing 8-3 Klasa kontekstowa Entity Framework WineDbContext.cs using System.Data.Entity; using System.Data.Entity.ModelConfiguration.Conventions; namespace WineCloudWebApi.Models { public class WineDbContext : DbContext { public WineDbContext() : base("name=WineDbContext") {} public DbSet Wines { get; set; } protected override void OnModelCreating(DbModelBuilder modelBuilder) { base.OnModelCreating(modelBuilder);
245
246
Rozdział 8: Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności
modelBuilder.Conventions.Remove(); } } }
Aby utworzyć Web API dla tabeli Wine przy użyciu Entity Framework, wykonaj poniższe działania: 1 . Prawym klawiszem myszy kliknij folder Models poniżej projektu WineCloudWebApi
w panelu Solution Explorer, po czym wybierz Add | Class, aby wyświetlić okno dialogowe Add New Item. 2 . Nazwij klasę Wine.cs i kliknij Add, jak na rysunku 8-4.
Rysunek 8-4 Dodawanie klasy Wine.cs
3 . Zastąp kod szablonu wygenerowany automatycznie przez Visual Studio kodem
pokazanym w Listingu 8-2. 4 . Skompiluj WineSolution, wybierając polecenie Build | Build Solution w menu u góry
strony lub naciskając Ctrl+Shift+B. Uwaga W kolejnym kroku tej procedury dodamy nowy kontroler Web API, wykorzystujący utworzoną przed chwilą klasę modelu Wine. Visual Studio wyszukuje klasy modeli przy użyciu skompilowanych asemblacji wewnątrz rozwiązania. Dlatego konieczne jest skompilowanie rozwiązania już teraz, aby Visual Studio mogło odnaleźć klasę modelu w następnym kroku.
5 . Prawym klawiszem myszy kliknij folder Controllers w projekcie WineCloudWebApi
w panelu Solution Explorer i wybierz Add | Controller, aby wyświetlić okno dialogowe Add Scaffold (dodaj szkielet).
Tworzenie API typu RESTful
6 . Wybierz opcję Web API 2 Controller With Actions, using Entity Framework (kontroler
Web API 2 z akcjami, używający Entity Framework), po czym kliknij Add, jak na rysunku 8-5. Szkielet ten automatycznie tworzy metody Web API w nowej klasie kontrolera, umożliwiające pobieranie (GET) oraz uaktualnianie (PUT, POST, DELETE) jednostek.
Rysunek 8-5 Dodawanie kontrolera Web API 2
7 . W oknie dialogowym Add Controller wpisz informacje dla nowego kontrolera: a . W polu Controller name (nazwa kontrolera) wpisz WineController. b . Pozostaw niezaznaczone pole wyboru Use Async Controller Actions (użyj asyn-
chronicznych akcji kontrolera). c . Z listy rozwijanej Model class wybierz Wine (WineCloudWebApi.Models). d . Dla klasy kontekstowej kliknij przycisk New Data Context (nowy kontekst
danych) i wpisz WineCloudWebApi.Models.WineDbContext w polu tekstowym New Data Context Type, po czym kliknij Add, jak na rysunku 8-6.
Rysunek 8-6 Tworzenie kontekstu danych Entity Framework
e . Okno dialogowe Add Controller powinno teraz wyglądać tak, jak na rysunku
8-7. Kliknij Add, aby utworzyć kontroler.
247
248
Rozdział 8: Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności
Rysunek 8-7 Dodawanie i konfigurowanie klasy WineController dla Entity Framework
8 . Podwójnie kliknij plik Web.config wewnątrz projektu WineCloudWebApi w pane-
lu Solution Explorer i zlokalizuj łańcuch połączenia WineDbContext w sekcji connectionStrings. 9 . Zmień domyślną zawartość łańcucha WineDbContext na Server=tcp:.database.windows.net,1433; Database=WineCloudDb; User ID=@; Password=; Trusted_Connection=False; Encrypt=True; Connection Timeout=30;
W powyższym tekście wykonaj następujące zmiany: a . Zastąp nazwą serwera SQL Database, który zawiera bazę danych
WineCloudDb. b . Zastąp oraz nazwą użytkownika i hasłem przypisanymi do serwera przy jego tworzeniu. 10 . Podwójnie kliknij plik WineDbContext.cs w folderze Models w panelu Solution
Explorer i zastąp kod szablonu kodem pokazanym w Listingu 8-3. Kod ten zastępuje metodę OnModelCreating, usuwając domyślną konwencję nazewnictwa tabel. Nakazuje to EF szukanie tabeli nazwanej Wine (liczba pojedyncza), a nie Wines (liczba mnoga) do przechowywania wierszy jednostki Wine w bazie danych. 11 . Podwójnie kliknij plik Global.asax.cs wewnątrz projektu WineCloudWebApi. 12 . Wykonaj poniższe zmiany, aby usunąć domyślną strategię inicjowania bazy danych
i spowodować, by EF nie próbował tworzyć bazy danych (jako że baza ta już istnieje): a . Dodaj poniższe wyrażenia using na początku pliku: using System.Data.Entity; using WineCloudWebApi.Models;
b . Dodaj poniższy wiersz kodu na końcu metody Application_Start: Database.SetInitializer(null);
z menu u góry strony lub naciskając Ctrl+Shift+B. Utworzyliśmy właśnie Web API typu RESTful dla tabeli Wine, wykorzystujące ASP.NET Web API oraz Entity Framework i możemy przystąpić do jego testowania. Uwaga Więcej informacji na temat Entity Framework i ASP.NET Web API zawiera rozdział 10. Zajmiemy się w nim budowaniem wielowarstwowej aplikacji Web oraz aplikacji mobilnej wykorzystujących SQL Database.
Testowanie Web API Wine Po utworzeniu Web API konieczne jest przetestowanie go, aby się upewnić, że zwraca ono właściwe dane z tabeli Wine w bazie WineCloudDb. Aby przetestować Web API, wykonaj poniższe kroki: 1 . Zaznacz WineSolution w panelu Solution Explorer i naciśnij F5 albo kliknij Debug | Start Debugging. Spowoduje to otwarcie przeglądarki Internet Explorer (albo innej domyślnej przeglądarki dla debugowania, o ile została wybrana) z domyślną stroną projektu WineCloudWebApi, pokazaną na rysunku 8-8.
Rysunek 8-8 Domyślna strona generowana przez projekt WineCloudWebApi
2 . Uzupełnij URL w pasku adresu przeglądarki o api/Wine, po czym naciśnij Enter.
Spowoduje to wykonanie metody GetWines z WineController, która odpowiada
249
250
Rozdział 8: Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności
listą win odczytaną z bazy danych WineCloudDb. Domyślne zachowanie przeglądarki Internet Explorer w tym przypadku powoduje wyświetlenie zapytania, czy chcemy zapisać, czy też otworzyć wyniki wywołania Web API, co pokazuje rysunek 8-9.
Rysunek 8-9 Plik Wine.json zwracany przez Wine API Uwaga ASP.NET Web API implementuje funkcjonalność nazywaną negocjacją zawartości (content negotiation). Specyfikacja HTTP (patrz RFC 2616) definiuje negocjację zawartości jako „proces wybierania najlepszej reprezentacji dla danej odpowiedzi, jeśli istnieje wiele możliwych reprezentacji”. Najczęściej spotykaną techniką obsługi negocjacji zawartości jest wykorzystanie nagłówków żądań HTTP Accept. Przeglądarki używają różnych domyślnych nagłówków Accept. Jeśli wykonamy żądanie GET do Wine API z różnych przeglądarek, prawdopodobnie uzyskamy różne odpowiedzi. W przypadku Internet Explorer zazwyczaj odpowiedź będzie sformatowana jako JSON; dla odmiany w Chrome zwykle będzie to plik XML.
3 . Kliknij Open, aby wyświetlić listę win zwróconą jako wyniki JSON. Jeśli pojawi się
pytanie, jak otworzyć ten typ pliku, kliknij More Options (Więcej opcji) i wybierz Notepad (Notatnik).
4 . Uzupełnij URL w pasku adresu o /2 i naciśnij Enter. Spowoduje to wykonanie
metody GetWine i zwróci odpowiedź zawierającą rekord z WineId równym 2. 5 . Kliknij Open, aby wyświetlić wyniki.
Utworzyliśmy Web API Wine, używając ASP.NET Web API oraz Entity Framework Code First. Następnie przetestowaliśmy ją w przeglądarce i sprawdziliśmy, że zwraca ona wyniki odczytane z bazy danych WineCloudDb. W kolejnym kroku dodamy kontroler Web API dla tabeli Customer, używając tym razem samego ADO.NET, bez
Tworzenie API typu RESTful
sięgania po Entity Framework. Typowe aplikacje biznesowe używają ADO.NET, gdyż większość z nich powstała wcześniej, zanim pojawił się mechanizm Entity Framework. „Surowy” ADO.NET jest również powszechnie wykorzystywany, gdy chce się podnieść wydajność dostępu do danych. Z tych powodów w kolejnym podrozdziale użyjemy ADO.NET do zbudowania kontrolera Web API dla tabeli Customer.
Dodawanie kontrolera Web API ADO .NET Jak dotąd, utworzyliśmy rozwiązanie Visual Studio i dołączyliśmy do niego projekt typu ASP.NET Web Application. W projekcie tym utworzyliśmy kontroler Web API dla tabeli Wine, używając Entity Framework Code First. Teraz utworzymy drugi kontroler Web API dla tabeli Customer, posługując się surowym ADO.NET. Listing 8-4 pokazuje klasę modelu POCO dla jednostki Customer, zaś Listing 8-5 ukazuje odpowiadającą mu klasę kontrolera Web API. lisTing 8-4 Klasa modelu Customer.cs namespace WineCloudWebApi.Models { public class Customer { public int CustomerId { get; set; } public string FirstName { get; set; } public string LastName { get; set; } public int? FavoriteWineId { get; set; } } }
lisTing 8-5 Klasa kontrolera Web API CustomerController.cs using using using using using using using
namespace WineCloudWebApi.Controllers { public class CustomerController : ApiController { // GET api/Customer public IList GetCustomers() { IList customers = new List(); var connectionString = ConfigurationManager.ConnectionStrings["WineDbContext"].ConnectionString; using (var connection = new SqlConnection(connectionString)) {
251
252
Rozdział 8: Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności
var commandText = "SELECT * FROM Customer"; using (var command = new SqlCommand(commandText, connection)) { connection.Open(); using (var reader = command.ExecuteReader()) { while (reader.Read()) { var customer = new Customer { CustomerId = Convert.ToInt32(reader["CustomerId"]), FirstName = reader["FirstName"].ToString(), LastName = reader["LastName"].ToString(), FavoriteWineId = reader["FavoriteWineId"] as int? }; customers.Add(customer); } } } } return customers; } // GET api/Customer/5 [ResponseType(typeof(Customer))] public IHttpActionResult GetCustomer(int id) { Customer customer = null; var connectionString = ConfigurationManager.ConnectionStrings["WineDbContext"].ConnectionString; using (var connection = new SqlConnection(connectionString)) { var commandText = "SELECT * FROM Customer WHERE CustomerId = @CustomerId"; using (var command = new SqlCommand(commandText, connection)) { command.Parameters.AddWithValue("@CustomerId", id); connection.Open(); using (var reader = command.ExecuteReader()) { if (reader.Read()) { customer = new Customer { CustomerId = Convert.ToInt32(reader["CustomerId"]), FirstName = reader["FirstName"].ToString(), LastName = reader["LastName"].ToString(), FavoriteWineId = reader["FavoriteWineId"] as int? }; } } } }
W celu utworzenia Web API Customer używającej ADO.NET wykonaj poniższe działania: 1 . Prawym klawiszem myszy kliknij folder Models w projekcie WineCloudWebApi
w panelu Solution Explorer, po czym wybierz Add | Class, aby wyświetlić okno dialogowe Add New. 2 . Nazwij klasę Customer.cs i kliknij Add. 3 . Zastąp kod szablonu wygenerowany przez Visual Studio kodem zawartym
w Listingu 8-4, po czym skompiluj rozwiązanie WineSolution, wybierając polecenie Build | Build Solution z menu lub naciskając Ctrl+Shift+B. 4 . Prawym klawiszem myszy kliknij folder Controllers w projekcie WineCloudWebApi
i wybierz Add | Controller, aby wyświetlić okno dialogowe Add Scaffold. 5 . Zaznacz kontroler Web API 2 Controller – Empty i kliknij Add. Zostanie wyświet-
lone okno dialogowe Add Controller. 6 . W polu nazwy wpisz CustomerController i kliknij Add. 7 . Zastąp kod szablonu kodem pokazanym wcześniej w Listingu 8-5 i skompiluj
rozwiązanie WineSolution. Dodaliśmy właśnie nowy kontroler Web API dla tabeli Customer, używając czystego kodu ADO.NET zamiast Entity Framework. Web API Customer zawiera metody umożliwiające pobieranie danych, ale nie dodawanie ani aktualizowanie klientów. Analogicznie do modelu jednostki Wine, model Customer nie ma żadnych zależności i jest prostą klasą POCO. Kontroler Customer, pokazany w Listingu 8-5, odpytuje tabelę Customer używając klas ADO.NET SqlConnection, SqlCommand oraz SqlDataReader. Tworzy i wypełnia instancję klasy modelu jednostki Customer i zwraca obiekty Customer. Web API ASP.NET następnie serializuje obiekty Customer na odpowiednie formaty odpowiedzi i odsyła je do żądającego.
253
254
Rozdział 8: Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności
Testowanie Web API Customer Po utworzeniu Web API Customer konieczne jest przetestowanie go w celu upewnienia się, że faktycznie zwraca dane z tabeli Customer w bazie danych WineCloudDb: 1 . Zaznacz rozwiązanie WineSolution w panelu Solution Explorer i naciśnij F5 albo
kliknij Debug | Start Debugging. Otworzy to Internet Explorer (lub inną domyślną przeglądarkę) na stronie domyślnej projektu WineCloudWebApi. 2 . Na końcu URL w pasku adresu przeglądarki dodaj api/Customer i naciśnij Enter.
Spowoduje to wykonanie metody GetCustomers w kontrolerze WineController i zwróci odpowiedź zawierającą listę klientów z bazy danych WineCloudDb. Internet Explorer domyślnie zapyta, czy wyniki wywołania Web API mają być zapisane, czy wyświetlone. 3 . Kliknij Open, aby przejrzeć wyniki. 4 . Uzupełnij URL w pasku adresu przeglądarki o /3, po czym naciśnij Enter.
Spowoduje to wykonanie GetCustomer i zwrócenie rekordu z tabeli Customer o identyfikatorze równym 3. 5 . Kliknij Open, aby wyświetlić wyniki.
W tym momencie nasz projekt zawiera już ASP.NET Web API umożliwiające pobieranie danych z tabel Wine oraz Customer w bazie WineCloudDb. Dysponując tym projektem, zbudujemy na jego podstawie dalsze rozwiązania w kolejnych podrozdziałach, aby zademonstrować dostrajanie wydajności i skalowalność bazy danych SQL Database.
Zarządzanie połączeniami SQL Database Połączenia bazy danych w przypadku Microsoft Azure SQL Database ma inną charakterystykę i zachowanie, niż te, których możemy się spodziewać w przypadku lokalnej instalacji SQL Server. Aby zapewnić niezawodność i dobre wrażenia użytkowników, trzeba uwzględnić te cechy w aplikacjach wykorzystujących SQL Database. Dodatkowo poza uwzględnieniem tych różnic w zachowaniu powinniśmy również zastosować ogólne najlepsze praktyki dotyczące interakcji z bazami danych, niezależnie od tego, czy znajdują się one w siedzibie firmy, czy w chmurze.
Otwierać późno, zamykać wcześnie Wszystkie zasoby przetwarzania mają limity i dotyczy to zarówno chmury, jak i instalacji lokalnych. W przypadku SQL Database jednym z ograniczeń jest liczba połączeń do bazy danych, które możemy mieć otwarte w dowolnym momencie. Aby dobrze wykorzystywać zasoby i połączenia SQL Database, powinniśmy otwierać połączenia do bazy danych tylko wtedy, gdy musimy wykonać interakcję z SQL Database i zrobić
Zarządzanie połączeniami SQL Database
to tak późno, jak to możliwe. Po zakończeniu interakcji należy zamknąć i zwolnić połączenie. Entity Framework wprowadza warstwę abstrakcji dla połączeń do bazy danych i można oczekiwać, że będzie „dobrym konsumentem” zasobów. Jednak gdy bezpośrednio otwieramy połączenia przy korzystaniu z surowego ADO.NET, powinniśmy wykonywać tę czynność tak blisko interakcji z bazą danych, jak to możliwe. W Listingu 8-5 możemy zobaczyć, że wywołanie to connection.Open() następuje bezpośrednio przed wykonaniem polecenia SqlCommand. Ponieważ połączenie jest opakowane w wyrażenie using, bezpośrednio po wyjściu z tego wyrażenia połączenie zostanie odrzucone, co spowoduje jego zamknięcie i zwolnienie zasobów.
Korzystanie z pul połączeń Ustanawianie nowego połączenia do bazy danych łączy się z dodatkowym obciążeniem i spadkiem wydajności. Aby zminimalizować te niepożądane efekty, ADO.NET umożliwia tworzenie pul połączeń. Polega to na utrzymywaniu otwartych połączeń klientów w zarządzanej puli. Gdy klient potrzebuje otwarcia połączenia, ADO.NET sprawdza, czy w puli istnieje połączenie z pasującym łańcuchem. Jeśli takie połączenie istnieje, jest przekazywane do klienta, który może wykonać interakcję z bazą danych. Jeśli połączenia brak, zostaje ustanowione nowe połączenie. Gdy klient zakończy pracę i wyśle sygnał zamknięcia połączenia, zamiast niszczenia połączenia jest ono zwracane do puli. Tylko połączenia o dokładnie takiej samej konfiguracji mogą być łączone w pule, przy czym zakres puli jest ograniczony do AppDomain. Domyślnie ADO.NET używa pul połączeń i jest to generalnie zalecana praktyka, pozwalająca znacząco zredukować koszt tworzenia połączeń.
Przywracanie po błędach połączeń Połączenia z SQL Database mogą być nieoczekiwanie kończone z wielu powodów. Architektura sieciowa SQL Database obejmuje zapory, mechanizmy równoważenia obciążeń, routery i węzły bazodanowe. Istnieje więc wiele komponentów pomiędzy klientem a bazą danych. Błędy w dowolnych z tych komponentów mogą powodować zerwanie połączenia. SQL Database może również zakończyć połączenia, jeśli w ramach pracy awaryjnej będzie przenoszona na inny węzeł klastra. W uzupełnieniu do błędów i pracy awaryjnej SQL Database analizuje aktywność połączeń i zużycie zasobów węzła bazodanowego. Jeśli SQL Database ustali, że musi zdławić połączenie, aby zachować sprawność działania całej usługi i uniknąć negatywnego wpływu na innych „współlokatorów”, może zamknąć połączenie. Tego typu zamknięcia połączeń są określane mianem błędów przejściowych (transient fault). Błędy przejściowe są chwilowymi problemami lub błędami, które powinny być szybko naprawiane. Jeśli nasza aplikacja jest utworzona z uwzględnieniem możliwości występowania przejściowych błędów, może próbować ponownego połączenia po krótkim czasie i utrata
255
256
Rozdział 8: Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności
łączności może nawet nie zostać zauważona przez użytkownika. Jeśli tego nie zrobimy, aplikacja zwróci wyjątek i użytkownik najprawdopodobniej zobaczy komunikat o błędzie. Nie wszystkie zakończenia połączeń są powodowane przejściowymi błędami. Jednak błędy zgłaszane przez SQL Database zawierają numer błędu, który pozwala ustalić rodzaj błędu. Aplikacja może porównać ten numer ze znanymi błędami przejściowymi. Jeśli wystąpi dopasowanie, aplikacja może ponowić próbę połączenia i ponownie wywołać transakcję; jeśli dopasowania nie będzie, błąd nie jest przejściowy i musi być obsłużony inaczej. Być może wydaje się, że wymaga to wiele pracy, ale na szczęście nie musimy się martwić – zespół Microsoft Azure Customer Advisory Team, w połączeniu z Microsoft Patterns & Practices, uprościł to zadanie, tworząc bibliotekę Transient Fault Handling Application Block. Jest ona częścią rodziny Enterprise Library bloków aplikacji i może zostać zintegrowana z naszą aplikacją w celu ułatwienia przywracania działania podczas przejściowych błędów. Bibliotekę tę można wykorzystać wraz z SQL Database i innymi usługami Microsoft Azure, w których również mogą pojawiać się przejściowe błędy, takimi jak Service Bus lub Storage. W kolejnych podrozdziałach zintegrujemy bibliotekę Transient Fault Handling Application Block z projektem WineCloudWebApi. Mówiąc bardziej precyzyjnie, zmodyfikujemy Web API Wine i Customer, aby samoczynnie przywracały działanie w razie wystąpienia przejściowych błędów.
Dodawanie Transient Fault Handling Application Block W celu rozpoczęcia pracy z biblioteką Transient Fault Handling Application Block musimy dodać do niej odwołanie i zintegrować ją z naszym projektem. W kolejnych krokach dodamy odwołanie do niej przy użyciu NuGet. Jeśli ktoś nie używał dotąd NuGet, dobrze będzie poznać kilka podstawowych faktów. Jest to menedżer pakietów, który upraszcza dodawanie odwołań do projektów wraz ze wszystkimi powiązanymi zależnościami. NuGet ułatwia też aktualizowanie zależności i bibliotek, gdy publikowane są ich nowe wersje. Dokumentacja dotycząca NuGet i repozytorium publicznie dostępnych pakietów jest dostępna w witrynie www.nuget.org. Wykonaj poniższe kroki, aby dodać odwołanie do biblioteki Transient Fault Handling Application Block: 1 . Prawym klawiszem kliknij projekt WineCloudWebApi w panelu Solution Explorer
i wybierz polecenie Manage NuGet Packages (zarządzaj pakietami NuGet). Pojawi się okno dialogowe Manage NuGet Packages. 2 . W lewej części okna wybierz opcję Online, wpisz transient fault sql database
w polu wyszukiwania w prawym górnym rogu, po czym naciśnij Enter.
Zarządzanie połączeniami SQL Database
3 . W wynikach wyszukiwania zaznacz Enterprise Library – Transient Fault Handling Application Block – Microsoft Azure SQL Database Integration i kliknij Install, jak
na rysunku 8-10.
Rysunek 8-10 Instalowanie biblioteki Transient Fault Handling Application Block przy użyciu okna dialogowego Manage NuGet Packages
4 . W oknie License Acceptance kliknij I Accept, jak na rysunku 8-11. Spowoduje
to pobranie i dodanie odwołania do asemblacji Microsoft.Practices.EnterpriseLibrary. TransientFaultHandling.Data.dll i elementów zależnych.
Rysunek 8-11 Akceptowanie warunków licencyjnych dla biblioteki Transient Fault Handling Application Block
5 . Po zakończeniu instalacji kliknij Close.
Dodaliśmy do projektu odwołanie do biblioteki Transient Fault Handling Application Block i możemy teraz zacząć integrować ją z projektem WineCloudWebApi. W kolejnych
257
258
Rozdział 8: Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności
dwóch podrozdziałach zmodyfikujemy Web API Wine oraz Customer, aby wykonywały przywracanie po błędach przejściowych.
Stosowanie Transient Fault Handling Application Block w ADO .NET Biblioteka Transient Fault Handling Application Block udostępnia komponenty i klasy, których możemy użyć do określenia wykrywania i obsługi błędów przejściowych przez naszą aplikację. Tabela 8-1 ukazuje główne komponenty tej biblioteki. Tabela 8-1 Główne komponenty biblioteki Transient Fault Handling Application Block Komponent
Opis
Strategia wykrywania
Ustala, czy wyjątek jest spowodowany sytuacją błędu przejściowego
Strategia ponawiania
Określa, jak często i jak wiele razy próbować ponownie, gdy błąd zostanie zidentyfikowany jako przejściowy
Zasada ponawiania
Łączy strategię wykrywania i ponawiania i służy do wywoływania usług, które mogą podlegać błędom przejściowym
Strategie wykrywania są wykorzystywane przez bibliotekę Transient Fault Handling Application Block do ustalenia, czy błąd jest przejściowy i czy uszkodzone wywołanie usługi powinno zostać powtórzone. Strategie wykrywania są klasami, które implementują interfejs ITransientErrorDetectionStrategy, przy czym biblioteka zawiera implementacje dostosowane do usług SQL Database, Service Bus, Storage oraz Caching. Procedury pokazane w tym rozdziale wykorzystują klasę SqlDatabaseTransientErrorDetectionStrategy do wykrywania sytuacji błędu przejściowego SQL Database, ale można zaimplementować własną strategię wykrywania używając interfejsu ITransientErrorDetectionStrategy. Strategie ponawiania służą do definiowania częstości i liczby prób automatycznego przywrócenia po wystąpieniu błędu. Są to klasy dziedziczące z klasy RetryStrategy. Tabela 8-2 ukazuje strategie ponawiania zaimplementowane w bibliotece Transient Fault Handling Application Block. Tabela 8-2 Strategie ponawiania dostępne w Transient Fault Handling Application Block Klasa
Opis
ExponentialBackoff
Ponawia określoną liczbę razy, wykładniczo powiększając opóźnienia na podstawie wyspecyfikowanych parametrów
FixedInterval
Ponawia określoną liczbę razy ze stałym interwałem czasowym pomiędzy kolejnymi próbami
Incremental
Ponawia określoną liczbę razy z liniowo rosnącym interwałem pomiędzy kolejnymi próbami
Zarządzanie połączeniami SQL Database
Przy użyciu strategii wykrywania i ponawiania tworzona jest zasada ponawiania, wykorzystująca klasę RetryPolicy. Zasada ta analizuje błędy przy użyciu strategii wykrywania i wykonuje strategię ponawiania, jeśli błąd został zidentyfikowany jako przejściowy. Biblioteka Transient Fault Handling Application Block udostępnia kilka sposobów zintegrowania jej z aplikacją. Można użyć nowych klas opakowujących istniejące klasy, aby uczynić je wrażliwymi na przejściowe błędy. ReliableSqlConnection jest klasą opakowującą klasę SqlConnection. Można użyć jej zamiast SqlConnection, aby automatycznie obsłużyć ponawianie połączeń w razie wystąpienia błędów przejściowych. Istnieją także rozszerzone metody dla istniejących klas, w tym także klas SqlConnection oraz SqlCommand. Te rozszerzone metody mogą zostać wykorzystane do użycia zasad ponawiania, co pokażemy w kolejnych procedurach. W celu włączenia obsługi przejściowych błędów w metodzie GetCustomers wykonaj poniższe kroki: 1 . Rozwiń folder Controllers w projekcie WineCloudWebApi w panelu Solution
Explorer. 2 . Podwójnie kliknij plik CustomerController.cs, po czym dodaj następujące wyra-
żenie using do listy na początku pliku: using Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling;
3 . Zlokalizuj metodę GetCustomers i wpisz poniższe dwa wiersze kodu bezpośrednio
przypisania zmiennej connectionString: var retryStrategy = new Incremental(5, TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(2)); var retryPolicy = new RetryPolicy(retryStrategy);
Aby obsłużyć przejściowe błędy w metodzie GetCustomer, wykonaj poniższe działania: 1 . Zlokalizuj metodę GetCustomer i wpisz poniższe dwa wiersze kodu bezpośrednio
pod przypisaniem zmiennej connectionString: var retryStrategy = new Incremental(5, TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(2)); var retryPolicy = new RetryPolicy(retryStrategy);
W ten sposób dołączyliśmy obsługę przejściowych błędów, które mogą wystąpić przy korzystaniu z SQL Database, używającej strategii ponawiania Incremental w Web API Customer. Ta strategia ponawiania wykorzystuje trzy parametry. Pierwszy parametr definiuje liczbę prób ponowienia połączenia. W poprzedzającej procedurze skonfigurowaliśmy strategię Incremental na pięć prób. Drugi i trzeci parametr łącznie definiują wielkość interwału pomiędzy kolejnymi próbami ponowienia. Drugi parametr określa czas, który należy odczekać przed pierwszą próbą, zaś trzeci wskazuje wielkość czasu, o którą mają być zwiększane kolejne interwały. W tym przykładzie ustawiliśmy drugi parametr na jedną sekundę, zaś trzeci na dwie sekundy. Oznacza to, że pierwsza próba wznowienia połączenia nastąpi po jednej sekundzie, zaś kolejne po trzech, pięciu, siedmiu i dziewięciu sekundach – licząc od poprzedniej próby. Dzięki zdefiniowaniu zasady przywracania wykorzystującej bibliotekę Transient Fault Handling Application Block i użyciu metod rozszerzających dla klas SqlConnection oraz SqlCommand udostępnianych przez tę bibliotekę, Web API Customer jest obecnie odporna na sytuację przejściowego błędu, przy czym wymagane zmiany w kodzie były minimalne. W kolejnym podrozdziale zajmiemy się obsługą błędów przejściowych w rozwiązaniu opartym na Entity Framework.
Stosowanie Transient Fault Handling Application Block w Entity Framework W poprzednim podrozdziale zaimplementowaliśmy logikę ponawiania w razie wystąpienia błędu przejściowego. Zrealizowaliśmy to przy użyciu metod rozszerzających dla klas SqlConnection i SqlCommand, udostępnianych przez bibliotekę Transient Fault Handling Application Block. W przypadku Web API Customer rozwiązanie to działa doskonale, gdyż kod dostępu do danych to czyste ADO.NET wykorzystujące te klasy. Z drugiej strony Web API Wine używa Entity Framework w celu uzyskiwania dostępu do danych i klasy ADO.NET SqlConnection oraz SqlCommand nie są jawnie eksponowane. Tym samym obsłużenie sytuacji błędu przejściowego przy użyciu Entity Framework wymaga nieco innego rozwiązania. W poniższej procedurze wykorzystamy tę samą klasę RetryPolicy, której użyliśmy wcześniej wraz z metodami rozszerzającymi dla klas SqlConnection i SqlCommand. Klasa RetryPolicy zawiera metodę ExecuteAction, która pozwala wykonać kod opakowujący ADO.NET. Jest ona użyteczna przy pracy z obiektowym mapowaniem relacyjnym (object relational mapping – ORM) i stosowaniu platform dostępu do danych, takich jak Entity Framework. Listing 8-6 pokazuje zmodyfikowaną klasę WineController z wywołaniami Entity Framework, które powodują przekazywanie zapytań do SQL Database
Zarządzanie połączeniami SQL Database
opakowanych przez metodę ExecuteAction. Ręczne zmiany, które trzeba wprowadzić w kodzie wygenerowanym automatycznie ze szkieletu, zostały wyróżnione pogrubieniem. Dowolne zgłaszane wyjątki przekazywane do RetryPolicy będą analizowane w celu sprawdzenia, czy mamy do czynienia z sytuacją błędu przejściowego i odpowiednio ponawiane. lisTing 8-6 Klasa WineController.cs wykorzystująca bibliotekę Transient Fault Handling Application Block do obsługi błędów przejściowych using using using using using using using using using using using using
Rozdział 8: Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności
W celu wprowadzenia potrzebnych modyfikacji w klasie kontrolera Wine wykonaj poniższe działania: 1 . Rozwiń folder Controllers wewnątrz projektu WineCloudWebApi w panelu Solution
Explorer. 2 . Podwójnie kliknij plik WineController.cs. 3 . Zaktualizuj kod zgodnie z Listingiem 8-6. W szczególności: a . Dodaj wyrażenie using dla asemblacji Microsoft.Practices.EnterpriseLibrary.
TransientFaultHandling. b . Dodaj pole prywatne do przechowania zasady ponawiania. c . Dodaj konstruktor tworzący zasadę ponawiania. d . Opakuj każdy wiersz kodu, który inicjuje zapytanie lub wywołuje SaveChanges, w metodę zasady ponawiania ExecuteAction. Jak widać, biblioteka Transient Fault Handling Application Block jest wielką pomocą przy tworzeniu logiki obsługującej błędy przejściowe. Bez niej konieczne byłoby samodzielne napisanie kodu, identyfikującego błędy przejściowe poprzez porównanie numerów błędów zwracanych przez wyjątki z listą znanych błędów przejściowych. Następnie trzeba by napisać kod wykonujący ponawianie połączenia określoną liczbę razy w ustalonych odstępach czasu i zaimplementować to wszystko w naszym kodzie dostępu do danych. Wykorzystanie biblioteki Transient Fault Handling Application Block znacznie przyśpiesza prace projektowe. Sytuacje błędów przejściowych nie są czymś, co moglibyśmy zignorować. Jeśli nasza aplikacja nie będzie przygotowana na takie okoliczności, użytkownicy będą zauważać zrywane połączenia i dławienie wydajności, co znacząco obniży jakość pracy. Jest to częste źródło frustracji i wątpliwości dotyczących niezawodności, szczególnie w przypadku nowych użytkowników SQL Database. Na szczęście można tego uniknąć, od początku integrując bibliotekę Transient Fault Handling Application Block z naszą aplikacją.
Redukowanie opóźnień sieciowych Oprócz różnic dotyczących zarządzania połączeniami, co omówiliśmy w poprzednim podrozdziale, innym wielkim wyzwaniem z punktu widzenia wydajności i niezawodności są opóźnienia. Opóźnienie można zdefiniować jako czas upływający pomiędzy przyczyną i efektem. W przypadku SQL Database jest to czas pomiędzy wysłaniem zapytania od klienta do bazy danych a odebraniem wyliczonych wyników przez klienta. W przypadku lokalnych centrów danych typową metodą zredukowania opóźnień pomiędzy serwerami Web a serwerami bazodanowymi jest bezpośrednie połączenie tych serwerów przy użyciu szybkich, gigabitowych łączy sieciowych. Jednak
Redukowanie opóźnień sieciowych
w przypadku chmury publicznej nie mamy kontroli nad infrastrukturą i nie możemy wykonać żadnego dostrajania sprzętu sieciowego. Nadal jednak możemy wykonać optymalizację usług i aplikacji w celu zminimalizowania opóźnień.
Umieszczanie usług blisko siebie Podstawowym sposobem zmniejszenia opóźnień sieciowych jest minimalizowanie dystansu pomiędzy serwerami, które komunikują się ze sobą. W przypadku Microsoft Azure sprowadza się to do umieszczenia usług i serwerów w tym samym regionie. Nie zawsze jednak będzie możliwe utrzymanie niewielkiej odległości fizycznej. Jeśli mamy aplikację działającą w naszym własnym centrum danych, która musi wchodzić w interakcję z SQL Database, usługi te będą rozdzielone dystansem, którego nie możemy zredukować. W takiej sytuacji, jeśli opóźnienia stają się problemem, możemy rozważyć zastosowanie takich technik, jak buforowanie i przetwarzanie wsadowe.
Minimalizowanie ponownych obiegów Zawsze, gdy usługi są oddalone od siebie i występuje potencjalne ryzyko opóźnień, nawet w naszym własnym centrum danych, warto zredukować „gadatliwość” i liczbę ponownych obiegów w sieci w naszej aplikacji (przesyłania danych tam i z powrotem). Istnieje kilka rozwiązań, które pozwalają zmniejszyć liczbę obiegów do bazy danych SQL Database: ■
■
■
■
Opakowanie złożonego dostępu do danych w procedurach składowanych, jeśli wymagane jest wielokrotne przesyłanie zapytań i odbieranie wyników. Na przykład, jeśli zapytanie zależy od wyników poprzedniego zapytania, zamiast wykonywania wielu wywołań bazy danych od klienta, możemy połączyć te zapytania w jednej procedurze składowanej. W ten sposób wyjściowe zapytanie zostanie przesłane do bazy danych tylko raz i tylko raz będziemy odbierać wyniki. Przetwarzanie wsadowe przy użyciu parametrów tablicowych. Polega to na przesłaniu jednego parametru tablicowego do procedury składowanej, zamiast wielu wywołań z pojedynczymi parametrami dla tej samej procedury. Wykorzystanie magazynu i buforowania po stronie klienta w celu zredukowania ruchu sieciowego przy korzystaniu z danych wyszukiwania (i ogólnie takich, które zmieniają się stosunkowo rzadko). Oprócz magazynu po stronie klienta można również wykorzystać rozproszone usługi buforowania, takie jak Microsoft Azure Cache, aby przechować dane w pamięci i współużytkować ich w wielu węzłach. Unikanie pobierania metadanych w czasie wykonywania. Należy tu wymienić stosowanie takich klas, jak SqlCommandBuilder, która odpytuje metadane bazy danych podczas działania.
265
266
Rozdział 8: Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności
Efektywne korzystanie z SQL Database Często mamy do czynienia z sytuacją, gdy nierelacyjne lub binarne dane przechowywane są w relacyjnej bazie danych, takiej jak SQL Server. Jest to typowe w aplikacjach klasy przedsiębiorstwa, których projektanci postrzegają SQL Server jako zarządzaną platformę przechowywania danych – dowolnych danych. Przechowywanie wszystkiego w SQL Server upraszcza projektowanie aplikacji, gdyż programiści muszą poznać tylko jedną platformę i nauczyć się pojedynczego zestawu bibliotek klienckich. Oprócz wygody programistów jest jeszcze jeden powód, dla którego SQL Server jest często używany dla wszelkich typów danych: jest zazwyczaj skonfigurowany jako rozwiązanie o wysokiej dostępności, co ułatwia zbudowanie systemu z wieloma rozproszonymi klientami lub klastrem serwerów Web, połączonym z pojedynczą platformą SQL Server. Jednak w celu osiągnięcia takiego poziomu dostępności konieczne jest poniesienie znaczących inwestycji w infrastrukturę i sprzęt, przy czym duża część tych wysiłków poświęcana jest na architekturę i projekt samej instalacji SQL Server. Jeśli zastanowimy się nad wydajnością, skalowalnością i kosztami, relacyjne bazy danych zdecydowanie nie są najlepszym miejscem na przechowywanie niestrukturalnych, nierelacyjnych lub binarnych danych. (Funkcjonalność FILESTREAM w SQL Server stanowi wyjątek od tej podstawowej reguły, ale nie jest ona niestety obsługiwana w SQL Database). Jedną z metod, którymi można zwiększyć wydajność SQL Database, jest stosowanie jej do przechowywania danych relacyjnych – tylko relacyjnych – i wykorzystanie alternatywnych usług magazynowych dla danych niestrukturalnych lub „częściowo strukturalnych”, ale nierelacyjnych.
Używanie najlepszej usługi magazynowania Istnieje wiele usług danych dostępnych w Microsoft Azure, które są lepiej niż SQL Database przystosowane do zarządzania nierelacyjnymi i binarnymi danymi. Microsoft Azure Storage zawiera trzy usługi magazynowania dla innych typów danych: Table, Blob oraz Queue (kolejka). Wszystkie one mają na celu przechowywanie danych nierelacyjnych. Magazyn typu Table (tabela) działa dobrze dla wielkich ilości strukturalnych, ale nierelacyjnych danych. Magazyn Table jest pozbawionym schematu, jednostkowym magazynem pozwalającym przechować obiekt zawierający wiele par klucz-wartość. Przykładem tego typu danych mogą być dzienniki lub dane telemetryczne. Są one zazwyczaj nierelacyjne i ich analizy nie są wykonywane w tej samej strukturze, w której zostały początkowo zapisane. Tego typu dane dobrze pasują do magazynu Table. Magazyn Blob jest po prostu skalowalną usługą serwera plików w Microsoft Azure. Jego podstawowym przeznaczeniem jest przechowywanie plików binarnych, w tym dokumentów i multimediów. Jeśli nasze rozwiązanie obejmuje wielkie obiekty binarne (BLOB) przechowywane w bazie danych jako typ danych varbinary(max)
Optymalizowanie zapytań
(przypomnijmy, że typ FILESTREAM nie jest obsługiwany), magazyn Blob jest dobrą alternatywą dla przechowywania tych danych. Użycie magazynu Blob zredukuje obciążenie SQL Database i zmniejszy ilość danych przechowywanych w bazie danych. Oprócz korzyści wydajnościowych, magazyn Blob jest znacząco tańszy (cena za jednostkę pojemności), niż SQL Database. Magazyn Queue (kolejka) jest usługą zaprojektowaną do kolejkowania komunikatów w przetwarzaniu asynchronicznym. Często jest to realizowane przy użyciu tabeli bazy danych z kolumnami statusu. Można zmniejszyć obciążenie i rywalizację w SQL Database, używając magazynu Queue w takiej sytuacji. Jeśli dane są często odczytywane, ale rzadko zmieniane, są doskonałym kandydatem na buforowanie. Microsoft Azure udostępnia usługę Cache (pamięć podręczna), którą można wdrożyć we własnych instancjach przetwarzania w Microsoft Azure, ale możemy też skorzystać z zarządzanej usługi. W prostszych sytuacjach może nam wystarczyć przechowywanie i odwoływanie się do danych buforowanych w lokalnym systemie plików.
Optymalizowanie zapytań Większość technik dostrajania zapytań i reguł wydajnościowych znanych z SQL Server ma zastosowanie również w SQL Database. Optymalizowanie zapytań jest ogromnym tematem i wykracza poza zakres tej książki. W istocie jest wiele tytułów, które w całości poświęcone są temu zagadnieniu. Podstawowe zasady obejmujące analizowanie planów wykonania, optymalizowanie zapytań w celu zmniejszenia odczytów/zapisów dyskowych i związanego z nimi oczekiwania oraz dostrajanie indeksów są identyczne jak w SQL Server. Tym niemniej identyfikowanie powolnych zapytań i takich, które są dobrymi kandydatami na optymalizację, różni się nieco od techniki znanej z SQL Server. SQL Database nie zawiera tych funkcjonalności SQL Server, które wymagają podniesionych uprawnień lub mogą potencjalnie wpływać na wydajność i niezawodność innych użytkowników chmury; stąd nie możemy wykorzystać narzędzia SQL Profiler w SQL Database. Umiejętność identyfikowania wolno wykonywanych zapytań w SQL Database jest bardzo cenna i zagadnienie to omówimy w rozdziale 9, „Monitorowanie i zarządzanie SQL Database”.
Skalowanie SQL Database w górę SQL Database jest współużytkowaną, wielodostępną, relacyjną usługą bazodanową, która może mieć różne charakterystyki wydajnościowe. W chwili pisania tych słów nowa usługa o nazwie SQL Database Premium jest w stadium wstępnym (Preview). Można wykorzystać ją w celu osiągnięcia stałej i przewidywalnej wydajności poprzez zarezerwowanie zasobów obliczeniowych wyłącznie dla naszej bazy danych. SQL Database Premium obejmuje dwa poziomy usługi pokazane w tabeli 8-3.
267
268
Rozdział 8: Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności
Tabela 8-3 Poziomy usługi SQL Database Premium Poziom usługi
Opis
P1
1 rdzeń CPU, 8 GB pamięci oraz 150 operacji dyskowych wejścia/wyjścia na sekundę (IOPS)
P2
2 rdzenie CPU, 16 GB pamięci i 300 IOPS
Uwaga Microsoft regularnie udostępnia nowe funkcje Microsoft Azure. Funkcje te często zaczynają działanie jako wersje Preview, które nie są objęte umowami poziomu usługi (service level agreement – SLA) ani gwarancjami i zazwyczaj nie podlegają pomocy technicznej Microsoft. W wersji Preview usługi często mają zredukowane ceny (a niekiedy są bezpłatne). Gdy usługa przechodzi z wersji Preview do poziomu ogólnej dostępności (General Availability – GA), usługa uzyskuje SLA, gwarancje, wsparcie techniczne i (niestety) pełną cenę. Więcej informacji na temat usług wstępnych Microsoft Azure zawiera witryna http:// azure.microsoft.com/en-us/services/preview/.
Warto mieć na uwadze, że w chwili, gdy książka trafi do rąk Czytelnika, opisane warianty mogą już przejść z wersji testowej do wersji ogólnej, a także że mogą pojawić się inne poziomy usługi. Aby zarejestrować się dla SQL Database Premium Preview, wykonaj następujące działania: 1 . Zaloguj się w portalu zarządzania kontem Microsoft Azure pod adresem https://
account.windowsazure.com. 2 . Kliknij przycisk Preview Features (Funkcje do testowania8), pokazany na rysunku
8-12.
Rysunek 8-12 Łącze Preview Features w portalu Microsoft Azure 8 Ta część portalu Microsoft Azure jest dostępna w języku polskim i ta właśnie wersja pojawi się w przypadku logowania się z komputera zlokalizowanego w Polsce.
Skalowanie SQL Database w górę
3 . Kliknij przycisk Try It Now na prawo od wpisu Premium For SQL Database, pokaza-
nego na rysunku 8-13, aby aktywować wersję testową SQL Database Premium.
Rysunek 8-13 Aktywowanie funkcji testowej SQL Database Premium w portalu Microsoft Azure
4 . Wybierz subskrypcję, której chcesz użyć dla SQL Database Premium w oknie
dialogowym Add Preview Feature, pokazanym na rysunku 8-14, po czym kliknij ikonę zatwierdzenia w prawym dolnym rogu.
Rysunek 8-14 Wybieranie typu subskrypcji w oknie Add Preview Feature
Wysłaliśmy właśnie żądanie rejestracji dla wersji testowej SQL Database Premium. Żądania są kolejkowane i akceptowane w zależności od aktualnej dostępności i popytu. Po pewnym czasie otrzymamy email informujący o akceptacji żądania i aktywowaniu SQL Database Premium. Po aktywowaniu wersji testowej możemy zażądać przydziału SQL Database Premium dla naszych serwerów SQL Database.
269
270
Rozdział 8: Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności
Aby zażądać przydziału SQL Database Premium, wykonaj poniższe kroki: 1 . Zaloguj się w portalu Microsoft Azure pod adresem https://manage.windowsazure.
com. Pojawi się główna strona portalu. 2 . Kliknij SQL DATABASES w panelu nawigacyjnym po lewej. 3 . Kliknij łącze SERVERS w górnej części strony. Pojawi się lista serwerów Microsoft
Azure SQL Database. 4 . W kolumnie NAME kliknij serwer, dla którego chcesz zażądać przydziału Premium. 5 . Przejdź do strony domowej serwera, klikając ikonę chmury z błyskawicą (na lewo
od łączy w górnej części strony). 6 . Kliknij łącze Request Premium Database Quota w sekcji Premium Database, jak
na rysunku 8-15.
Rysunek 8-15 Żądanie przydziału SQL Database Premium w portalu zarządzania Microsoft Azure
Akceptacja żądania może zająć nieco czasu. Status żądania wyświetlany jest w sekcji Premium Database po jego zainicjowaniu. W okresie przejściowym (przed akceptacją) wyświetlany będzie komunikat Pending Approval (Oczekiwanie na akceptację), jak na rysunku 8-16. W tym czasie można anulować żądanie, klikając łącze Cancel Request. Gdy żądanie zostanie zaakceptowanie i uzyskamy przydział SQL Database Premium dla tego serwera, otrzymamy również email z powiadomieniem. Po uzyskaniu przydziału SQL Database Premium można utworzyć nowe bazy danych lub powiązać istniejące z nowym przydziałem.
Skalowanie SQL Database w górę
Rysunek 8-16 Wyświetlanie statusu żądania przydziału SQL Database Premium w portalu Microsoft Azure
W celu uaktualnienia istniejącej bazy danych do SQL Database Premium wykonaj poniższe działania: 1 . Zaloguj się w portalu Microsoft Azure pod adresem https://manage.windowsazure.
com i kliknij łącze SQL Databases w panelu nawigacyjnym. 2 . W kolumnie NAME kliknij bazę danych, którą chcesz uaktualnić do poziomu
SQL Database Premium. Baza ta musi znajdować się na serwerze z zaakceptowanym przydziałem SQL Database Premium. 3 . Kliknij łącze SCALE w górnej części strony, aby skonfigurować SQL Database
Premium: a . W sekcji Edition wybierz Premium. Spowoduje to podniesienie bazy danych
z wydania Web lub Business do wydania SQL Database Premium. b . W sekcji Reservation Size (wielkość rezerwacji) można wybrać poziom P1 lub P2. Poziom P1 oznacza 1 rdzeń procesora, 8 GB pamięci i 150 IOPS. Poziom P2 odpowiada dwóm poziomom P1. Strona powinna wyglądać podobnie do pokazanej na rysunku 8-17. 4 . Kliknij przycisk SAVE w dolnej części strony.
271
272
Rozdział 8: Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności
Rysunek 8-17 Wybieranie wielkości rezerwacji SQL Database Premium
Rozbudowaliśmy (przeskalowaliśmy w górę) naszą bazę SQL Database używając testowego wydania SQL Database Premium. Wydanie to pozwala zarezerwować część zasobów serwera hostującego SQL Database wyłącznie dla naszej bazy. Dzięki tej rezerwacji zasobów mamy zapewnioną jednolitą i przewidywalną charakterystykę wydajnościową SQL Database.
Partycjonowanie danych Skalowanie relacyjnych baz danych nie jest zadaniem trywialnym. Odróżnia to je od aplikacji bez pamięci stanu czy serwerów Web, których skalowanie jest zazwyczaj bardzo proste. Wystarczy wdrożyć nowy serwer i dodać go do mechanizmu równoważenia obciążeń, aby natychmiast powiększyć pojemność i przeskalować aplikację. Jednak charakterystyka relacyjna oraz właściwości ACID (Atomic, Consistent, Isolated i Durable – atomowe, spójne, izolowane i odporne) wymagane dla niemal każdej relacyjnej bazy danych powodują, że rozdzielenie baz danych pomiędzy wiele węzłów obliczeniowych staje się trudne. Jeśli zachodzi potrzeba przeskalowania relacyjnej bazy na wiele węzłów, konieczne jest partycjonowanie danych. W kolejnych podrozdziałach opiszemy dostępne podejścia i techniki partycjonowania baz danych.
Partycjonowanie danych
Skalowanie przy użyciu partycji funkcjonalnych Jednym z najbardziej powszechnych sposobów partycjonowania baz danych jest rozdzielanie ich według funkcji. Partycjonowanie funkcjonalne rozdziela dane na wiele baz danych, z których każda zawiera ściśle powiązane tabele. Jeśli sięgniemy po przykład naszej bazy danych WineCloudDb, moglibyśmy podzielić ją według funkcji, tworząc na przykład bazę danych Customer oraz bazę Catalog. Baza Customer będzie zawierała tabelę Customer (i być może wiele innych tabel zawierających bardziej szczegółowe informacje o klientach, na przykład dane adresowe), zaś baza Catalog będzie zawierała tabelę Wine (ponownie uzupełnioną o tabele pomocnicze). W przypadku prawdziwej aplikacji eCommerce sprzedającej wino, pojawi się również baza danych zamówień (nazwijmy ją Order) z tabelami Order i OrderDetail. Partycjonowanie funkcjonalne jest niekiedy nazywane partycjonowaniem pionowym. W ogólności jest to podejście łatwiejsze do implementacji i stosowania, niż partycjonowanie horyzontalne, które opiszemy w kolejnym podrozdziale. Aby podzielić dane funkcjonalnie, konieczne jest usunięcie wymuszanych na poziomie bazy danych relacji i kluczy obcych pomiędzy tabelami, które znajdą się w różnych bazach danych. Następnie możemy rozłożyć nasze tabele w wielu różnych bazach danych, ale bez ograniczeń na poziomie bazy danych to nasza aplikacja będzie musiała zająć się wymuszeniem powiązań pomiędzy tabelami w różnych bazach. Dowolne zapytania, które będą złączać dane z tabel zlokalizowanych w różnych bazach danych, również muszą zostać rozdzielone, a łańcuchy połączeń będą musiały zostać zaktualizowane, aby kierować aplikację do odpowiedniej bazy danych. Podział baz danych na partycje funkcjonalne może być zadaniem złożonym i czasochłonnym, jeśli istnieje wiele powiązań relacyjnych pomiędzy tabelami i wiele zapytań, widoków lub procedur, które trzeba będzie zaktualizować. Jednym z celów partycjonowania danych jest zrównoważenie i rozdzielenie obciążenia pomiędzy wiele węzłów przetwarzania. Choć funkcjonalne partycjonowanie bazy danych pozwoli podzielić obciążenie na wiele węzłów, mało prawdopodobne jest, aby udało się obciążenie to rozdzielić równomiernie. W kolejnym podrozdziale poznamy inną technikę partycjonowania nazywaną sharding (od ang. shard – odłamek). Dzięki tej technice łatwiej można osiągnąć równomierną dystrybucję obciążenia.
Skalowanie przy użyciu partycjonowania horyzontalnego Aby równomiernie rozdzielić obciążenie relacyjnej bazy danych pomiędzy wiele węzłów przetwarzania, konieczne jest rozważenie partycjonowania danych zawartych w pojedynczej tabeli. Rozdzielenie jednej tabeli na wiele baz danych jest określane terminem partycjonowania horyzontalnego lub sharding. W kolejnej procedurze podzielimy bazę danych WineCloudDb na wiele „odłamków” na podstawie danych klientów. Zbiór danych zawartych w WineCloudDb jest niewielki, ale wystarczy do zademonstrowania
273
274
Rozdział 8: Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności
shardingu. Podzielimy bazę danych na dwie: pierwszą zawierającą tylko jeden rekord klienta, oraz drugą, w której znajdą się dwa pozostałe rekordy. Przy rozdzielaniu baz na odłamki musimy zdefiniować algorytm, który będzie określał, które rekordy znajdą się w której części bazy danych. Dane klientów możemy spartycjonować na kilka odłamków na wiele sposobów. Możemy na przykład rozdzielić dane klientów na podstawie pierwszej litery nazwiska, co da nam 26 odłamków bazy danych9. Trzeba jednak pamiętać, że naszym celem jest możliwie równomierne rozdzielenie obciążenia i taka technika nam tego nie zapewni, gdyż niektóre litery występują znacznie częściej od innych. W naszym przykładzie bazy WineCloudDb wykonamy partycjonowania na podstawie zakresów wartości CustomerId. Ponieważ nasza baza zawiera tylko trzech klientów, przy podziale na dwie partycje klient o CustomerId równym 1 trafi do jednej części, zaś klienci z CustomerId od 2 do 3 znajdą się w drugiej części. Przy dzieleniu baz danych musimy też zdefiniować indeks lub mapowanie, jak dane są partycjonowane, aby po pierwsze móc odszukać potrzebne rekordy, a po drugie móc zmienić ich przydział do poszczególnych partycji, jeśli okaże się, że dystrybucja nie jest wyrównana i musi zostać ponownie zrównoważona. W pokazanym dalej przykładzie mapa podziału zostanie zaimplementowana w kodzie w celu uproszczenia i podniesienia czytelności. Jednak w typowym rozwiązaniu mapę podziału należy zaimplementować jako magazyn danych oddzielony od kodu. Podobnie jak w przypadku partycjonowania funkcjonalnego, podział danych może sprawiać trudności, jeśli istnieją ograniczenia relacyjne i klucze obce. Bardzo często dane odnośników i wyszukiwania muszą zostać zduplikowane i przechowywane w każdej partycji. (Usługa Microsoft Azure SQL Data Sync może pomóc w utrzymaniu zgodności wielu kopii tabel referencyjnych w poszczególnych partycjach; więcej informacji na ten temat zawiera rozdział 7, „Microsoft Azure SQL Data Sync”). W naszym przykładzie powielimy tabelę Wine w każdej partycji. Gdyby tabela klientów miała powiązania z innymi tabelami informacji pomocniczych o tych klientach, zazwyczaj konieczne jest partycjonowanie również tych tabel i przechowywanie powiązanych rekordów w tym samym odłamku bazy, co główny rekord danego klienta. W naszym prostym przykładzie WineCloudDb tabela Customer nie ma dodatkowych tabel dotyczących klientów, co znacznie uprości podział bazy danych.
Tworzenie podzielonych baz danych Na użytek ćwiczeń dotyczących Web API w tym rozdziale wykorzystamy skrypt pokazany w Listingu 8-7 do utworzenia dwóch fragmentów (shard) bazy danych WineCloudDb i wypełnienia każdego z nich tym samym zbiorem rodzajów wina. 9 Łatwo zauważyć, że w języku polskim liczba odłamków będzie inna ze względu na dodatkowe litery, które mogą wystąpić na początku nazwiska, takie jak Ć, Ł, Ś, Ź czy Ż, a jednocześnie niewielkie prawdopodobieństwo pojawienia się nazwisk rozpoczynających się od Q, X lub Y.
Partycjonowanie danych
Następnie wypełnimy każdy z nich różnymi klientami, po czym utworzymy Web API ASP.NET zwracające dane klientów z podzielonej bazy. lisTing 8-7 Skrypt tworzący podzielone bazy danych CREATE TABLE Wine ( WineId int PRIMARY KEY, Name nvarchar (50), Category nvarchar (15), Year int, Price money) CREATE TABLE Customer ( CustomerId int PRIMARY KEY, FirstName nvarchar(50), LastName nvarchar(15), FavoriteWineId int, CONSTRAINT FK_Customer_Wine FOREIGN KEY (FavoriteWineId) REFERENCES Wine (WineId)) INSERT INTO Wine VALUES (1, 'Chateau Penin', 'Bordeaux', 2008, 34.90), (2, 'McLaren Valley', 'Cabernet', 2005, 48.50), (3, 'Mendoza', 'Merlot', 2010, 42.00), (4, 'Valle Central', 'Merlot', 2009, 52.00)
Aby utworzyć fragmenty bazy WineCloudDb, wykonaj poniższe kroki: 1 . Uruchom SQL Server Management Studio (SSMS). W tym celu możesz przewi-
nąć ekran startowy w celu znalezienia kafelka aplikacji (w kategorii Microsoft SQL Server 2012) albo wpisać sql server management studio, aby rozpocząć wyszukiwanie, po czym kliknąć znaleziony kafelek. Po krótkiej chwili pojawi się okno dialogowe Connect To Server. 2 . W tym oknie dialogowym wykonaj poniższe działania: a . W polu Server Name wpisz .database.windows.net. Jest to w peł-
ni kwalifikowana nazwa serwera SQL Database, w której należy zastąpić nazwą przypisaną do naszego serwera. b . W polu Authentication wybierz z listy SQL Server Authentication (SQL Database nie wspiera uwierzytelniania Windows). c . W polach Login i Password wpisz nazwę użytkownika i hasło przypisane do administratora serwera. d . Kliknij przycisk Connect. 3 . Utwórz bazy danych. a . W panelu Object Explorer kliknij prawym klawiszem myszy nazwę serwera
i wybierz New Query, aby otworzyć nowe okno zapytania połączone z bazą danych master.
275
276
Rozdział 8: Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności
b . W oknie zapytania wpisz: CREATE DATABASE WineCloudDbShard1 GO CREATE DATABASE WineCloudDbShard2 GO
c . Naciśnij F5 (albo kliknij przycisk Execute w pasku narzędzi), aby utworzyć bazę
danych. d . Zamknij okno zapytania bez zapisywania skryptu. 4 . W panelu Object Explorer kliknij prawym klawiszem myszy Databases i wybierz
polecenie Refresh. W panelu powinny pojawić się dopiero co utworzone bazy WineCloudDbShard1 i WineCloudDbShard2. 5 . Prawym klawiszem myszy kliknij bazę WineCloudDbShard1 i wybierz polecenie New Query, aby otworzyć okno zapytania powiązane z tą bazą danych.
6 . Wpisz kod pokazany w Listingu 8-7 w oknie zapytania (albo skopiuj go z pliku
pobranego z witryny powiązanej z książką). 7 . Naciśnij F5. 8 . Usuń całą zawartość okna zapytania i wpisz nowy kod w oknie: INSERT INTO Customer VALUES (1, 'Jeff', 'Hay', 4)
9 . Naciśnij F5. Do tabeli Customer zostanie dodany jeden wiersz danych dla klienta
Jeff Hay. Zamknij okno zapytania bez zapisywania skryptu. 10 . Powtórz czynności z punktów 5-7 dla bazy danych WineCloudDbShard2. 11 . Usuń całą zawartość okna zapytania i wpisz poniższy kod: INSERT INTO Customer VALUES (2, 'Mark', 'Hanson', 3), (3, 'Jeff', 'Phillips', 2)
12 . Naciśnij F5, aby dodać dwa wiersze klientów do tabeli Customer w bazie
WineCloudDbShard2, po czym zamknij okno zapytania bez zapisywania skryptu. Mamy teraz dwie nowe bazy danych o nazwach WineCloudDbShard1 i WineCloudDbShard2, które posłużą nam jako źródło danych dla Web API do pobierania informacji o klientach. Każda z nich zawiera te same dane referencyjne w tabeli Wine, ale tabela Customer jest podzielona horyzontalnie.
Korzystanie z partycji przy użyciu ADO .NET i Web API ASP .NET Teraz, gdy skonfigurowaliśmy dwa fragmenty bazy danych, możemy przystąpić do modyfikowania Web API Customer, utworzonego wcześniej w tym rozdziale, aby móc odczytywać informacje z wielu baz danych. Listing 8-8 pokazuje klasy służące do pracy z indywidualnymi fragmentami baz danych. Klasa Shard definiuje podział bazy danych na podstawie zakresów
Partycjonowanie danych
identyfikatorów, które będą przechowywane we właściwościach BeginId i EndId. Klasa Shard zawiera też właściwość ConnectionString, przechowującą łańcuch połączenia dla danego fragmentu bazy. Klasa ShardRoot reprezentuje logiczny korzeń, który śledzi wiele fragmentów baz danych, razem tworzących pojedynczą logiczną bazę danych. Klasa CustomerShard jest logiczną implementacją korzenia dla bazy WineCloudDb. Wykorzystuje ona klasy Shard i ShardRoot do zebrania wielu baz danych w jeden logiczny kontener. Metoda GetShard w klasie CustomerShard upraszcza odnalezienie fragmentu bazy odpowiedniego dla wskazanego klienta. lisTing 8-8 Klasy fragmentacji tabeli Customer using System.Collections.Generic; using System.Linq; namespace WineCloudWebApi.Data { public class Shard { public int Id { get; set; } public int BeginId { get; set; } public int EndId { get; set; } public string ConnectionString { get; set; } } public class ShardRoot { public ShardRoot() { Shards = new List(); } public IList Shards { get; private set; } } public class CustomerShard { private static CustomerShard _instance; private static object _lockObj = new object(); public static CustomerShard Instance { get { if (_instance == null) { lock (_lockObj) { if (_instance == null) { _instance = new CustomerShard(); } } } return _instance; } }
277
278
Rozdział 8: Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności
Kontroler CustomerController, pokazany w Listingu 8-9, został zmodyfikowany, aby pobierał dane klientów z wielu baz danych, wykorzystując klasę CustomerShard. Zmiany w metodzie GetCustomer są proste. Używając ID przekazanego do metody GetCustomer baza danych, w której istnieje rekord tego klienta, jest zwracana przez metodę GetShard klasy CustomerShard. Następnie przy użyciu tej samej logiki, jak użyta w poprzedniej wersji CustomerController, odpytywana jest tabela klientów i zwracany jest odpowiedni rekord. Jak widać, zmiany wymagane do odczytania pojedynczego rekordu przez metodę GetCustomer są minimalne. Jednak zmiany wymagane w metodzie GetCustomers są nieco bardziej złożone. Gdy baza danych jest podzielona na wiele partycji, odpytywanie danych rozciągających się na wiele baz może stanowić wyzwanie. Aby wykonać zapytanie do kilku baz danych, musimy przesłać zapytanie do każdej z nich, po czym scalić rezultaty. Podejście to jest często nazywane zapytaniem wielowejściowym (fan-out). Jeśli mamy wiele baz danych, zazwyczaj nie będziemy chcieli wykonywać tych zapytań kolejno,
Partycjonowanie danych
czekając na zakończenie i odebranie wyników poprzedniego zapytania, gdyż zwiększa to czas reakcji i powoduje ogólne spowolnienie działania. Zamiast tego będziemy chcieli wykonać te zapytania jednocześnie i zagregować wyniki, gdy zostaną zwrócone równolegle. Metoda GetCustomers, pokazana w Listingu 8-9, pokazuje prostą implementację zapytania wielowejściowego, wykorzystującą bibliotekę Task Parallel Library. W tym przykładzie każdy fragment bazy danych jest odpytywany równolegle i wyniki każdego zapytania są scalane, po czym zwracane jako pojedyncza lista klientów. lisTing 8-9 CustomerController z obsługą partycjonowania tabeli Customer using using using using using using using using using
namespace WineCloudWebApi.Controllers { public class CustomerController : ApiController { // GET api/Customer public IList GetCustomers() { var customers = new List(); Parallel.ForEach(CustomerShard.Instance.ShardRoot.Shards, new ParallelOptions { MaxDegreeOfParallelism = CustomerShard.Instance.ShardRoot.Shards.Count }, shard => { var shardCustomers = new List(); var connectionString = shard.ConnectionString; var retryStrategy = new Incremental(5, TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(2)); var retryPolicy = new RetryPolicy(retryStrategy); using (var connection = new SqlConnection(connectionString)) { var commandText = "SELECT * FROM Customer"; using (var command = new SqlCommand(commandText, connection)) { connection.OpenWithRetry(retryPolicy); using (var reader = command.ExecuteReaderWithRetry(retryPolicy)) { while (reader.Read()) { var customer = new Customer
279
280
Rozdział 8: Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności
{ CustomerId = Convert.ToInt32(reader["CustomerId"]), FirstName = reader["FirstName"].ToString(), LastName = reader["LastName"].ToString(), FavoriteWineId = reader["FavoriteWineId"] as int? }; shardCustomers.Add(customer); } } } } customers.AddRange(shardCustomers); }); return customers; } // GET api/Customer/5 [ResponseType(typeof(Customer))] public IHttpActionResult GetCustomer(int id) { Customer customer = null; Shard customerShard = CustomerShard.Instance.GetShard(id); if (customerShard != null) { var connectionString = customerShard.ConnectionString; var retryStrategy = new Incremental(5, TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(2)); var retryPolicy = new RetryPolicy(retryStrategy); using (var connection = new SqlConnection(connectionString)) { var commandText = "SELECT * FROM Customer WHERE CustomerId = @CustomerId"; using (var command = new SqlCommand(commandText, connection)) { command.Parameters.AddWithValue("@CustomerId", id); connection.OpenWithRetry(retryPolicy); using (var reader = command.ExecuteReaderWithRetry(retryPolicy)) { if (reader.Read()) { customer = new Customer { CustomerId = Convert.ToInt32(reader["CustomerId"]), FirstName = reader["FirstName"].ToString(), LastName = reader["LastName"].ToString(), FavoriteWineId = reader["FavoriteWineId"] as int? }; } } } } }
W celu zmodyfikowania Web API dla danych klientów wykonaj poniższe kroki: 1 . Otwórz rozwiązanie WineSolution w Visual Studio 2013. 2 . Prawym klawiszem myszy kliknij projekt WineCloudWebApi w panelu Solution
Explorer i wybierz polecenie Add | New Folder. 3 . Nazwij nowy folder Data i naciśnij Enter. 4 . Prawym klawiszem myszy kliknij nowo utworzony folder Data i wybierz Add | Class, aby wyświetlić okno dialogowe Add New Item.
5 . Nazwij nową klasę CustomerShard.cs i kliknij Add. 6 . Zastąp kod szablonu kodem pokazanym wcześniej w Listingu 8-8. W łańcuchu
połączenia zawartym w tym kodzie wykonaj następujące poprawki: a . Zastąp nazwą serwera SQL Database zawierającego fragmenty
bazy danych. b . Zastąp wpisy i nazwą użytkownika i hasłem przypisanymi do serwera przy jego tworzeniu. 7 . Rozwiń folder Controllers poniżej projektu WineCloudWebApi w panelu Solution
Explorer. 8 . Podwójnie kliknij plik CustomerController.cs, po czym zastąp zawarty w nim kod
kodem pokazanym wcześniej w Listingu 8-9. 9 . Skompiluj rozwiązanie WineSolution, wybierając polecenie Build | Build Solution
w menu lub naciskając Ctrl+Shift+B. Możemy teraz przetestować nową wersję Win API, wykonując takie same kroki, jak opisane wcześniej w podrozdziale „Testowanie Web API Customer”. Listingi 8-8 i 8-9 pokazują prostą implementację partycjonowania bazy danych w naszej aplikacji. W Listingu 8-8 znajdziemy dwie klasy zarządzające i grupujące fragmentowaną bazę danych; w listingu 8-9 CustomerController zawiera prostą implementację zapytań wielowejściowych, wykorzystującą Task Parallel Library. Taka implementacja działa dobrze w sytuacjach, gdy zbiory danych są małe i nie nadmiernie złożone, ale w bardziej rozbudowanych scenariuszach konieczne będzie dołączenie dodatkowych możliwości śledzenia fragmentowania bazy i aktualizowania danych w wielu partycjach. Istnieją biblioteki, które można wykorzystać do dołączenia tych funkcjonalności. Zespół Microsoft Azure Customer Advisory Team tworzy wskazówki,
281
282
Rozdział 8: Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności
platformy i aplikacje wzorcowe oparte na tym, czego nauczył się z praktycznych rozwiązań. Microsoft Azure CAT opracował m.in. wzorcową aplikację o nazwie Cloud Service Fundamentals in Windows Azure, zawierającą bilbliotekę Microsoft.AzureCat.Patterns. Data.SqlAzureDalSharded. Biblioteka ta zawiera klasy, które mogą być pomocne przy partycjonowaniu relacyjnych baz danych. Biblioteka ta jest dostępna pod adresem http://code.msdn.microsoft.com/windowsazure/Cloud-Service-Fundamentals-4ca72649 i można ją swobodnie wykorzystywać w swoich rozwiązaniach. Uwaga EF również można używać przy fragmentowaniu baz danych. Przy użyciu takiego samego podejścia, jak pokazane w Listingi 8-9, możemy użyć Task Parallel Library do równoległego wykonywania zapytań do wielu baz danych. Jednak zamiast używania czystych obiektów ADO.NET w celu uzyskiwania dostępu do bazy danych, użyjemy obiektów EF. Dla każdej bazy danych będziemy konstruować EF DbContext, zamiast otwierania nowego SqlConnection. Przy użyciu obiektu DbContext możemy następnie odpytywać odpowiednią właściwość DbSet przy użyciu języka LINQ To Entities. Partycjonowanie przy użyciu EF jest możliwe, ale jeśli zależy nam na podniesieniu wydajności, dodatkowe obciążenie wynikające ze stosowania EF będzie nas raczej skłaniać do stosowania czystego ADO.NET.
Podsumowanie W tym rozdziale przedstawiliśmy wprowadzenie do optymalizowania wydajności i skalowania Microsoft Azure SQL Database. Utworzyliśmy rozwiązanie Web API ASP. NET, które posłużyło jako aplikacja referencyjna, po czym poprawiliśmy niezawodność i wydajność tego Web API, zarządzając połączeniami z bazą danych i błędami połączeń, a także redukując opóźnienia. Przedstawiliśmy też inne opcje optymalizacji, takie jak wykorzystanie bardziej odpowiednich usług magazynowych dla danych lub dostrajanie zapytań. W dalszej części rozdziału pokazaliśmy skalowanie w górę SQL Database przy użyciu wydania SQL Database Premium. Na koniec pokazaliśmy skalowanie bazy SQL Database w poziomie poprzez partycjonowanie. Projektowanie wysoko dostępnych, wydajnych i skalowalnych systemów to bardzo rozległy temat. W tym rozdziale przedstawiliśmy tylko ogólny przegląd najbardziej istotnych koncepcji, zasad i technik uzyskiwania wysokiej wydajności i skalowalności przy korzystaniu z SQL Database, ale jest jeszcze znacznie więcej rzeczy, które Czytelnik musi opanować samodzielnie.
ROZDZI AŁ 9
Monitorowanie i zarządzanie SQL Database Eric Boyd
D
owolna usługa, której chcielibyśmy użyć w aplikacji produkcyjnej, musi zapewniać funkcjonalność monitorowania i zarządzania. Monitorowanie powinno dawać wgląd w stan działania usługi, a w efekcie w kondycję naszej aplikacji. Tak więc w pierwszej części tego rozdziału zajmiemy się poznawaniem funkcji monitorowania SQL Database przy użyciu portalu zarządzania, strony Service Dashboard oraz wbudowanych dynamicznych widoków oraz funkcji. We wcześniejszych rozdziałach zarządzaliśmy SQL Database przy użyciu narzędzi graficznych (GUI), takich jak portal Microsoft Azure, portal zarządzania SQL Database, konsola SQL Server Management Studio (SSMS) oraz SQL Server Data Tools (SSDT). Te narzędzia są wygodne na początku, ale w miarę dopracowywania aplikacji i przygotowania się do jej wdrożenia w środowisku produkcyjnym będzie można rozpoznać procesy, które są często powtarzane, a wówczas GUI staje się niewygodne. W celu oszczędzenia czasu i wyeliminowania ryzyka ludzkich błędów lepiej będzie zautomatyzować takie procesy. W drugiej części rozdziału poznamy techniki zarządzania SQL Database za pośrednictwem interfejsu programowania aplikacji (API) Microsoft Azure Service Management.
Tworzenie przykładowej bazy danych Przed rozpoczęciem pracy z tym rozdziałem należy utworzyć przykładową bazę danych, o ile nie została ona przygotowana we wcześniejszych rozdziałach. Odpowiednie instrukcje znajdują się na początku rozdziału 8 i nie będziemy ich powtarzać w tym miejscu.
283
284
Rozdział 9: Monitorowanie i zarządzanie SQL Database
Monitorowanie SQL Database udostępnia wiele opcji monitorowania kondycji i działania serwerów i baz danych. W tym podrozdziale poznamy techniki monitorowania SQL Database przy użyciu portalu Microsoft Azure, tablicy kontrolnej Microsoft Azure, portalu zarządzania SQL Database oraz dynamicznych widoków i funkcji zarządzania. Przy użyciu kombinacji narzędzi opisanych w tym rozdziale będziemy w stanie uzyskać szczegółowy i kompletny obraz stanu (kondycji) naszych serwerów i baz danych.
Stosowanie portalu zarządzania Portal zarządzania Microsoft Azure jest scentralizowanym miejscem zarządzania wszystkimi usługami Microsoft Azure, w tym SQL Database. Przy użyciu tego portalu można tworzyć i usuwać serwery SQL Database, tworzyć i usuwać bazy danych, a także zarządzać tymi serwerami i bazami, co pokazaliśmy wielokrotnie w tej książce. Dodatkowo portal ten udostępnia również funkcje monitorowania, które pomagają poznać wzorce użytkowania i stan kondycji naszych serwerów i baz. Jeśli zarządzamy wieloma bazami danych SQL Database, potrzebna jest możliwość szybkiego sprawdzenia, ile baz zostało wdrożonych i jak wiele potencjalnych jeszcze pozostało w naszym przydziale SQL Database. Podobnie bowiem, jak w przypadku wielkości samych baz danych, SQL Database narzuca limit na liczbę baz danych, które może zawierać pojedynczy serwer. W chwili pisania tych słów przydział ten wynosił 150 baz danych na serwer. Aby sprawdzić wykorzystanie serwera SQL Database, wykonaj poniższe kroki: 1 . Zaloguj się w portalu Microsoft Azure pod adresem https://manage.windowsazu-
re.com. Pojawi się główna strona portalu, ukazująca ALL ITEMS. 2 . Kliknij SQL DATABASES w panelu nawigacyjnym po lewej. 3 . Kliknij łącze SERVERS w górnej części strony. Pojawi się lista naszych serwerów
Microsoft Azure SQL Database. 4 . Kliknij nazwę serwera zawierającego przykładową bazę WineCloudDb. Zostanie
wyświetlona strona z łączami dotyczącymi tego serwera. 5 . Kliknij łącze DASHBOARD (tablica kontrolna) w górnej części strony. Zostanie
wyświetlona strona prezentująca ogólne wykorzystanie serwera, podobna do pokazanej na rysunku 9-1. W sekcji usage overview (przegląd wykorzystania) wyświetlany jest pasek ukazujący liczbę aktualnie używanych baz danych oraz liczbę możliwych do utworzenia baz (w granicach przydziału). Rysunek 9-1 pokazuje przeglądy wykorzystania serwera SQL Database o nazwie kdhlvxlmhi. Serwer ten zawiera jedną bazę danych z przydziału 150 baz.
Monitorowanie
Rysunek 9-1 Widok wykorzystania serwera SQL Database
Oprócz pokazywania wykorzystania serwera i limitów portal Microsoft Azure wyświetla wykorzystanie i miary operacyjne dla każdej utworzonej bazy danych. Tablica kontrolna bazy danych pokazuje wielkość alokowaną dla bazy danych, aktualnie używaną przestrzeń dyskową oraz wielkość pozostałego wolnego miejsca. W celu wyświetlenia miar wykorzystania bazy danych wykonaj poniższe kroki: 1 . Jeśli zamknąłeś portal Microsoft Azure po poprzedniej procedurze, zaloguj się
ponownie w portalu pod adresem https://manage.windowsazure.com. W przeciwnym razie po prostu kliknij łącze DATABASES w górnej części strony i pomiń punkt 2 procedury. 2 . Kliknij łącze SQL DATABASES w panelu nawigacyjnym, aby wyświetlić listę baz
danych. 3 . Kliknij nazwę bazy danych WineCloudDb. 4 . Kliknij łącze DASHBOARD w górnej części strony. 5 . Przewiń stronę w dół w razie potrzeby, aby znaleźć sekcję Usage Overview, poka-
zaną na rysunku 9-2. Ukazuje ona wykorzystane i dostępne miejsce przydzielone dla tej bazy danych.
285
286
Rozdział 9: Monitorowanie i zarządzanie SQL Database
Rysunek 9-2 Wykorzystanie miejsca przez bazę danych SQL Database
W górnej części strony wyświetlany jest wykres wybranych miar operacyjnych, pokazany na rysunku 9-3.
Rysunek 9-3 Wykres miar operacyjnych w tablicy kontrolnej SQL Database
Monitorowanie
Domyślnie wykres ten zawiera dane na temat zakleszczeń, nieudanych i udanych połączeń, które wystąpiły w ciągu ostatnich 24 godzin. Okres prezentowany w raporcie można zmienić – dostępne wartości to 1 godzina, 24 godziny, 7 dni lub 14 dni. Można również przełączyć wykres pomiędzy wyświetlaniem wartości względnych (relative), ukazujących poszczególne miary proporcjonalnie do pozostałych, albo wartości bezwzględnych (absolute), co powoduje wyświetlenie faktycznych liczb względem zera (osi Y). Obie opcje można zmienić przy użyciu rozwijanych list w prawym górnym rogu wykresu. Można również ukryć lub ponownie wyświetlić poszczególne rodzaje danych na wykresie. Kliknięcie przycisku odświeżenia w prawym górnym rogu powoduje ponowne wczytanie zaktualizowanych miar i narysowanie wykresu. Strona Monitor (łącze w górnej części strony) wyświetla ten sam wykres, ale uzupełniony o wartości numeryczne. Dodatkowo umożliwi wybranie miar, które są wyświetlone na liście szczegółów i w wykresie. Oprócz zakleszczeń (deadlocks), nieudanych połączeń (failed connections) i udanych połączeń (successful connections) wyświetlanych domyślnie, można włączyć również prezentowanie innych miar, takich jak liczba połączeń zablokowanych przez zaporę, bieżącego rozmiaru bazy danych oraz połączeń dławionych (throttled connections). DODatkOwe infOrmacje Więcej informacji na temat zapory SQL Database zawierają rozdziały 2, „Konfiguracja i ceny” i 5, „Bezpieczeństwo i kopie zapasowe”. Informacje na temat zarządzania połączeniami zawiera rozdział 8, „Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności”.
Aby wyświetlić dodatkowe miary dla bazy danych, wykonaj poniższe kroki: 1 . Kliknij łącze MONITOR w górnej części strony. Zostanie wyświetlony wykres oraz
lista prezentowanych miar z ich wartościami minimalnymi, maksymalnymi, średnimi i całkowitymi w tabeli poniżej, jak na rysunku 9-4.
287
288
Rozdział 9: Monitorowanie i zarządzanie SQL Database
Rysunek 9-4 Strona SQL Database Monitor z wykresem i szczegółowymi informacjami o skonfigurowanych miarach
2 . Kliknij przycisk ADD METRICS (dodaj miarę) w dolnej części strony, aby wyświetlić
okno dialogowe CHOOSE METRICS (wybierz miary). 3 . Zaznacz pole wyboru Blocked By Firewall (zablokowane przez zaporę), jak na rysun-
ku 9-5.
Rysunek 9-5 Okno dialogowe Choose Metrics
Monitorowanie
4 . Kliknij ikonę zatwierdzenia w prawym dolnym rogu, aby zamknąć okno dialogowe.
Nowa miara Blocked By Firewall pojawi się na liście w dolnej części strony Monitor. Domyślnie nowo dodane miary nie są uwzględniane w wykresie. W celu dołączenia miary do wykresu należy kliknąć szare kółko na lewo od nazwy miary na liście. Po kliknięciu zmieni się ono na kolorowe kółko ze znacznikiem i miara pojawi się na wykresie, jak na rysunku 9-6.
Rysunek 9-6 Nowo dodana miara na stronie Monitor
W celu usunięcia miary z listy i wykresu należy zaznaczyć ją na liście. Na dole strony pojawi się wówczas przycisk DELETE METRIC (usuń miarę). Po jego kliknięciu miara zostanie usunięta z listy i wykresu. Trzeba zauważyć, że zmiany te dotyczą tylko strony Monitor – strona Dashboard stale wyświetla trzy domyślnie zdefiniowane miary.
Tablica kontrolna Microsoft Azure Kondycja naszych serwerów i baz danych SQL Database jest zależna od stanu całej usługi Microsoft Azure SQL Database. Centra danych, serwery i usługi w chmurze mogą doznawać różnego typu problemów lub wyłączeń z rozmaitych powodów.
289
290
Rozdział 9: Monitorowanie i zarządzanie SQL Database
Wiedza, że istnieje jakiś problem dotyczący całej usługi, może oszczędzić wiele czasu i frustracji podczas rozwiązywania problemów z naszą aplikacją. Tablica kontrolna Microsoft Azure (pokazana na rysunku 9-7) jest witryną ukazującą aktualną i historyczną kondycję wszystkich usług wchodzących w skład Microsoft Azure. W celu jej wyświetlenia należy przejść do strony http://azure.microsoft.com/pl-pl/status/.
Rysunek 9-7 Tablica kontrolna Microsoft Azure
Strona ta prezentuje listę wszystkich usług Microsoft Azure. Na prawo od nazwy usługi znajdziemy ikony reprezentujące bieżący stan usługi w poszczególnych regionach. Zielony znaczek wyboru oznacza normalne funkcjonowanie usługi. Pomarańczowy trójkątny znak ostrzeżenia informuje, że usługa działa aktualnie ze zmniejszoną wydajnością. Czerwona ikona błędu sygnalizuje, że usługa jest wyłączona. Niektóre usługi opatrzone są znakiem plus na lewo od nazwy – kliknięcie go ukazuje usługi podrzędne, takie jak SQL Database Management Portal i SQL Data Sync. Kliknięcie ikony RSS na prawo od nazwy usługi wyświetla kanał RSS z opisową historią statusu, podobny do pokazanego na rysunku 9-8. Kanał ten można zasubskrybować w dowolnym
Monitorowanie
czytniku RSS, a także można utworzyć niestandardową tablicę operacyjną jako API, wykorzystując kanały RSS.
Rysunek 9-8 Kanał RSS statusu SQL Database
Domyślnie strona stanu automatycznie odświeża statusy usług co 10 minut. Interwał ten może zostać zmieniony na 1 minutę, 2 minuty, 5 minut lub Off (wyłączony), co blokuje automatyczne odświeżanie. Dane można przefiltrować, ukrywając te regiony, które nas nie interesują i zostawiając tylko regiony, w których zlokalizowane są nasze usługi. Jeśli Microsoft Azure jest wykorzystywana do obsługi produkcyjnych rozwiązań, strona statusu lub powiązane z nią kanały RSS pozwala na bieżąco uzyskiwać informacje o dowolnych przerwach w działaniu usług.
291
292
Rozdział 9: Monitorowanie i zarządzanie SQL Database
Portal zarządzania SQL Database Portal zarządzania SQL Database (który zaprezentowaliśmy w rozdziale 1, „Poznajemy Microsoft Azure SQL Database”) jest innym użytecznym narzędziem monitorowania wykorzystania i wydajności SQL Database. Strona podsumowania bazy danych zawiera informacje o alokowanej pojemności, bieżącej wielkości bazy danych oraz dostępnym wolnym miejscu, wraz z liczbą aktywnych użytkowników i połączeń, jak na rysunku 9-9.
Rysunek 9-9 Strona podsumowania bazy danych w portalu zarządzania SQL Database
Monitorowanie i rozwiązywanie wydajności zapytań może być trudnym zadaniem. Do identyfikowania wąskich gardeł i możliwości usprawnień potrzebne są odpowiednie narzędzia. Portal zarządzania SQL Database udostępnia kilka narzędzi, które pomagają w identyfikowaniu niewydajnych zapytań. W celu wyświetlenia wydajności ostatnio realizowanych zapytań wykonaj poniższe kroki: 1 . Jeśli zamknąłeś portal zarządzania SQL Database po poprzedniej procedurze, wróć
do portalu Microsoft Azure lub zaloguj się w nim ponownie pod adresem https:// manage.windowsazure.com. Pojawi się główna strona portalu ALL ITEMS.
Monitorowanie
2 . Kliknij SQL DATABASES w panelu nawigacyjnym po lewej. Pojawi się lista baz
danych. 3 . Kliknij bazę WineCloudDb. 4 . Kliknij przycisk MANAGE (zarządzaj) w dolnej części strony, aby otworzyć portal
zarządzania SQL Database. 5 . Wpisz nazwę użytkownika (w naszych przykładach saz) oraz hasło przypisane
do niego przy tworzeniu serwera, po czym kliknij Log On. Po chwili pojawi się strona Summary dla tej bazy danych, pokazana wcześniej na rysunku 9-9. 6 . Kliknij łącze Query Performance (wydajność zapytań) w górnej części strony, aby
wyświetlić listę kosztownych zapytań, podobną do pokazanej na rysunku 9-10. Tabelę tę można posortować wedle wybranej cechy, klikając odpowiednie nagłówki kolumn.
Rysunek 9-10 Strona Query Performance w portalu zarządzania SQL Database
7 . Kliknij jedno z zapytań na liście, aby wyświetlić stronę Query Plan Details (szcze-
góły planu zapytania). Portal wyświetli treść zapytania (w języku T-SQL), zasoby użyte przez to zapytanie i informacje o planie wykonania, jak na rysunku 9-11.
293
294
Rozdział 9: Monitorowanie i zarządzanie SQL Database
Rysunek 9-11 Strona Query Plan Details w portalu zarządzania SQL Database Uwaga Zapytanie wyświetlane na stronie Query Plan Details jest dostępne tylko do odczytu. Można jednak przejść do trybu edycji i zmodyfikować zapytanie, klikając przycisk Edit w pasku narzędzi u góry strony.
8 . Kliknij łącze Query Plan (plan zapytania) poniżej okna z treścią zapytania, aby
wyświetlić plan wykonania (rysunek 9-12). Przy użyciu przycisków dostępnych po prawej stronie powyżej graficznego planu wykonania można przełączać wyświetlanie pomiędzy widokami graficznym, siatki i drzewa. Ikony po lewej pozwalają wyróżnić operacje wchodzące w skład planu wykonania na podstawie ich kosztu procesora lub podsystemu dyskowego albo typów operacji.
Monitorowanie
Rysunek 9-12 Graficzny plan wykonania zapytania w portalu SQL Database
9 . Kliknij jakąś operację w planie wykonania, aby zobaczyć szczegóły i koszt tej
operacji (rysunek 9-13). W przypadku przeglądania bardzo dużego planu wykonania obejmującego wiele operacji widok można powiększać lub pomniejszać przy użyciu suwaka w lewym dolnym rogu.
295
296
Rozdział 9: Monitorowanie i zarządzanie SQL Database
Rysunek 9-13 Szczegóły operacji w planie wykonania prezentowanym w portalu SQL Database
Jak widać, portal SQL Database umożliwia zidentyfikowanie tych zapytań wykonywanych w naszej bazie danych, które wiążą się z wysokim kosztem wydajnościowym. Można następnie przeanalizować szczegóły planu wykonania tego zapytania, zidentyfikować kosztowne operacje i przejrzeć szczegóły wybranych operacji, aby znaleźć najlepszą drogę optymalizacji. Portal zarządzania SQL Database czerpie dane prezentowane na stronie Query Performance z dynamicznych widoków zarządzania SQL Database, którymi zajmiemy się w kolejnym podrozdziale.
Monitorowanie
Dynamiczne widoki i funkcje zarządzania Dynamiczne widoki zarządzania (dynamic management views – DMV) oraz dynamiczne funkcje zarządzania (dynamic management functions – DMF) zapewniają wgląd w szczegóły operacji i zużycie zasobów wewnątrz Microsoft Azure SQL Database. DMV po raz pierwszy pojawiły się w wydaniu SQL Server 2005 i zostały zaprojektowane jako alternatywa dla korzystania z systemowych tabel i funkcji w celu monitorowania SQL Server. SQL Database zawiera podzbiór tych widoków dynamicznych znanych z SQL Server, pozwalających monitorować serwery i bazy danych, a przede wszystkim diagnozować problemy wydajnościowe powodowane przez blokowane lub długo działające zapytania, nieefektywne plany wykonania i wąskie gardła zasobów. SQL Database zawiera wsparcie dla trzech kategorii DMV: widoków bazodanowych, widoków wykonania i widoków transakcji. Wszystkie te widoki są zdefiniowane w schemacie sys.
Bazy danych Dynamiczne widoki i funkcje zarządzania dotyczące baz danych udostępniają miary i informacje dla poszczególnych baz. Bazodanowe DMV dołączone do SQL Database zostały zebrane w tabeli 9-1. Bazodanowe DMF zawarte są w tabeli 9-2. Tabela 9-1 Dynamiczne widoki zarządzania dotyczące baz danych Nazwa
Opis
dm db index usage stats
Zwraca zliczenie różnych typów operacji na indeksach i czas, gdy każda z tych operacji była wykonana
dm db missing index details
Zwraca szczegółowe informacje o brakujących indeksach
dm db missing index group stats Zwraca podsumowujące informacje o grupach brakujących indeksów dm db missing index groups
Zwraca informacje o tym, jakie brakujące indeksy są zawarte w określonej grupie
dm db objects impacted on version change
Zapewnia „system wczesnego ostrzegania”, identyfikując obiekty, na które wpływ mogą mieć aktualizacje (zmiany wersji) wydania oprogramowania
dm db partition stats
Zwraca informacje o liczbie stron i wierszy dla każdej partycji bazy danych
dm db wait stats
Zwraca informacje o stanach oczekiwania (waits) dla wątków, które wystąpiły podczas operacji
297
298
Rozdział 9: Monitorowanie i zarządzanie SQL Database
Tabela 9-2 Dynamiczne funkcje zarządzania dotyczące baz danych Nazwa
Opis
dm db index operational stats
Zwraca bieżące operacje I/O niskiego poziomu, blokady, zatrzaski i aktywność dostępu dla każdej partycji tabeli lub indeksu w bazie danych
dm db index physical stats
Zwraca informacje o wielkości i fragmentacji danych i indeksów wybranej tabeli lub widoku
dm db missing index columns
Zwraca informacje o kolumnach tabel, dla których brakuje indeksów
Jedną z miar bazodanowych, która jest szczególnie ważna podczas monitorowania, jest rozmiar bazy. Jeśli wielkość naszej bazy osiągnie poziom limitu, zapytania zwrócą kod błędu 40544 (więcej informacji na temat limitów wielkości baz danych zawiera rozdział 2). Po osiągnięciu limitu nie będzie można dodawać ani aktualizować danych lub tworzyć nowych obiektów bazodanowych, dopóki nie zwiększymy maksymalnego rozmiaru bazy danych lub nie usuniemy części danych. Przy użyciu DMV można aktywnie monitorować wielkość bazy danych i podejmować odpowiednie działanie, zanim aplikacja zacznie odbierać komunikaty błędów wynikające z osiągnięcia maksymalnych rozmiarów. DODatkOwe infOrmacje SQL Database zgłasza błędy unikatowe dla SQL Database i każdy błąd jest identyfikowany poprzez jego kod (numer). Do błędów tych należą ogólne błędy dotyczące funkcji, obiektów i składni nie obsługiwanych przez SQL Database, błędy występujące podczas kopiowania baz danych oraz błędy połączeń. Więcej informacji wraz z pełną listą kodów błędów SQL Database zawiera strona http://msdn.microsoft.com/en-us/library/ff394106.aspx.
Aby wyliczyć wielkość bazy danych przy użyciu bazodanowych DMV, wykonaj poniższe kroki: 1 . Jeśli zamknąłeś portal zarządzania SQL Database po poprzedniej procedurze, zalo-
guj się ponownie i przejdź do portalu dla wybranej bazy danych. Pojawi się strona podsumowania. 2 . Kliknij przycisk New Query w pasku narzędzi u góry strony. 3 . Wpisz SELECT SUM(reserved_page_count) * 8.0 / 1024 AS ‘MBs Used’ FROM sys. dm_db_partition_stats
i kliknij Run (uruchom) w pasku u góry strony. Spowoduje to wykonanie zapytania i wyświetlenie bieżącego rozmiaru bazy danych, jak na rysunku 9-14.
Monitorowanie
Rysunek 9-14 Odczytywanie wielkości bazy danych przy użyciu DMV w portalu zarządzania SQL Database
To oczywiście tylko przykład uzyskiwania informacji z bazodanowych widoków zarządzania. Inne widoki pozwalają uzyskać szczegółowe informacje o wykorzystaniu indeksów, jakie indeksy należałoby utworzyć lub o czasie oczekiwania, jaki wystąpił podczas wykonywania zapytań.
Wykonywanie Widoki dynamiczne dotyczące wykonywania zapewniają wgląd w informacje o połączeniach, sesjach i żądaniach odbieranych przez serwery SQL Database. Widoki te zostały zebrane w tabeli 9-3. Dynamiczne funkcje zarządzania dotyczące wykonywania zawiera tabela 9-4. Tabela 9-3 DMV dotyczące wykonywania Nazwa
Opis
dm exec cached plans
Zwraca wiersz dla każdego planu zapytania buforowanego przez SQL Database
299
300
Rozdział 9: Monitorowanie i zarządzanie SQL Database
Tabela 9-3 DMV dotyczące wykonywania Nazwa
Opis
dm exec connections
Zwraca informacje o połączeniach utworzonych do serwera SQL Database
dm exec procedure stats
Zwraca zagregowane statystyki wydajności dla buforowanych procedur składowanych
dm exec query memory grants
Zwraca informacje o zapytaniach, które uzyskały przydział pamięci lub nadal wymagają takiego przydziału w celu wykonania
dm exec query stats
Zwraca zagregowane statystyki wydajności dla buforowanych planów zapytań
dm exec requests
Zwraca informacje na temat każdego aktualnie wykonywanego żądania
dm exec sessions
Zwraca informacje o wszystkich aktywnych połączeniach użytkowników i zadaniach wewnętrznych
dm exec trigger stats
Zwraca zagregowane statystyki wydajności dla buforowanych wyzwalaczy
Tabela 9-4 DMF dotyczące wykonywania Nazwa
Opis
dm exec describe first result set
Zwraca opis metadanych dla pierwszego zestawu wyników wskazanego wyrażenia
dm exec describe first result set for object
Zwraca opis metadanych dla pierwszego wyniku na podstawie identyfikatora obiektu
dm exec query plan
Zwraca plan wykonania w formacie XML dla zadania wskazanego przez uchwyt planu
dm exec sql text
Zwraca tekst wsadu SQL identyfikowanego przez wskazany uchwyt sql
dm exec text query plan
Zwraca plan wykonania w formacie tekstowym dla wsadu wskazanego przez uchwyt planu lub konkretne wyrażenie wewnątrz wsadu
Połączenia do bazy danych to ograniczone zasoby, które muszą być pod kontrolą zarówno w przypadku lokalnej instalacji w siedzibie, jak i w chmurze. Przy użyciu DMV dotyczących wykonywania można zobaczyć wszystkie aktywne połączenia SQL Database i ich właściwości, takie jak użyty login, zużywany czas CPU, moment wystąpienia ostatniego żądania i wiele innych.
Monitorowanie
Aby wyświetlić aktywne połączenia SQL Database przy użyciu dynamicznego widoku zarządzania, wykonaj poniższe kroki: 1 . Jeśli zamknąłeś portal zarządzania SQL Database po poprzedniej procedurze, zalo-
guj się ponownie i przejdź do portalu dla wybranej bazy danych. Pojawi się strona podsumowania. 2 . Kliknij przycisk New Query w pasku u góry strony. 3 . W oknie zapytania wpisz SELECT e.connection_id, s.session_id, s.login_name, s.cpu_time, s.last_request_end_time FROM sys.dm_exec_sessions s INNER JOIN sys.dm_exec_connections e ON s.session_id = e.session_id
i kliknij Run. Po wykonaniu zapytania pojawi się lista połączeń i sesji, jak na rysunku 9-15.
Rysunek 9-15 Wyświetlanie połączeń SQL Database i sesji przy użyciu dynamicznego widoku zarządzania
301
302
Rozdział 9: Monitorowanie i zarządzanie SQL Database
Widoki i funkcje zarządzania dotyczące wykonywania zapewniają informacje o połączeniach, sesjach, żądaniach i bieżącej wydajności. Widoki te i funkcje są szczególnie przydatne przy rozwiązywaniu problemów z połączeniami i niską wydajnością zapytań.
Transakcje Dynamiczne widoki zarządzania dotyczące transakcji udostępniają informacje o transakcjach przeprowadzanych w bazie danych i zakładanych blokadach. DMV transakcyjne zawarte w SQL Database zostały zebrane w tabeli 9-5. SQL Database nie udostępnia dynamicznych funkcji zarządzania powiązanych z transakcjami. Tabela 9-5 DMV dotyczące transakcji Nazwa
Opis
dm tran active transactions
Zwraca informacje o aktywnych transakcjach w bieżącej bazie danych
dm tran database transactions
Zwraca informacje o transakcjach na poziomie bazy danych
dm tran locks
Zwraca informacje o aktywnych zasobach menedżera blokad
dm tran session transactions
Zwraca informacje korelacji dla powiązanych transakcji i sesji
Rywalizacja o dostęp do obiektów bazy danych, blokady i zakleszczenia mogą powodować spowolnienie lub brak reagowania aplikacji, zawieszanie się i błędy. DMV dotyczące transakcji pozwalają przejrzeć bieżącą aktywność i blokowanie w bazie danych SQL Database.
Tabele zdarzeń DMV są bardzo pomocne przy monitorowaniu i rozwiązywaniu problemów dotyczących bieżącej aktywności, jednak gdy chcemy przeanalizować problemy, które wystąpiły w przeszłości, dynamiczne widoki nie pomogą nam, gdyż udostępniają tylko informacje o tym, co właśnie teraz dzieje się w bazie danych. Aby pomóc w badaniu problemów, które wystąpiły w przeszłości, ale już się nie pojawiają, SQL Database udostępnia dwa widoki katalogowe w bazie danych master o nazwach sys.database_ connection_stats oraz sys.event_log. Te tabele zdarzeń, jak się je często nazywa, gromadzą i przechowują zdarzenia, które mogą następnie zostać użyte do rozwiązywania problemów. Widok sys.database_connection_stats udostępnia podsumowanie połączeń wykonywanych do bazy danych – zarówno udanych, jak i nieudanych. Widok sys.event_log zawiera szczegóły dotyczące zdarzeń powiązanych z połączeniami. Łącznie widoki
Programowanie API typu REST do zarządzania usługą
te pozwalają analizować aktywność w bazie danych, w tym nieudane lub zakończone połączenia, dławienie połączeń oraz zakleszczenia. Obydwa widoki istnieją w bazie master i można je odpytywać przy użyciu dowolnie wybranego narzędzia, takiego jak SQL Server Management Studio, SQL Server Data Tools lub portal SQL Database.
Programowanie API typu REST do zarządzania usługą Zdolność do monitorowania kondycji usług takich jak SQL Database jest niezbędna, jeśli używamy ich w zastosowaniach produkcyjnych. W poprzednim podrozdziale zademonstrowaliśmy funkcje monitorowania udostępniane przez portal Microsoft Azure, stronę statusu Microsoft Azure, portal zarządzania SQL Database oraz dynamiczne widoki zarządzania (DMV). Wykorzystanie tych interfejsów do zarządzania SQL Database może znacznie ułatwić początkową pracę, ale w miarę rozwoju aplikacji i korzystania z bazy danych w chmurze coraz ważniejsze staje się automatyzowanie często wykonywanych zadań. W tym podrozdziale pokażemy, jak można zautomatyzować powtarzalne zadania w SQL Database, używając API Service Management. Uwaga Do efektywnego automatyzowania zarządzania SQL Database można również wykorzystać polecenia PowerShell. Rozdział 2 zawiera szczegółowe informacje na temat pobierania, instalowania i korzystania z modułu PowerShell dla Microsoft Azure SQL Database.
API Service Management wchodzi w skład rdzenia wszystkich usług w Microsoft Azure. API to można wykorzystać do tworzenia nowych serwerów i baz danych SQL Database, zarządzania regułami zapory, a nawet do resetowania hasła administratora. API to opiera się na protokole HTTP oraz REST, jest publicznie dostępne i może zostać użyte na dowolnym urządzeniu lub platformie, które potrafią generować żądania HTTP. API SQL Database można pogrupować na trzy główne kategorie: API do zarządzania serwerami SQL Database, API do zarządzania bazami danych oraz API do zarządzania regułami zapory na poziomie serwera. Aby móc użyć API Service Management, musimy się uwierzytelnić i mieć autoryzację do zarządzania subskrypcją Microsoft Azure. Uwierzytelnienie można wykonać przy użyciu certyfikatu zgodnego ze standardem X.509 v3 (nazywanego certyfikatem zarządzania) lub za pomocą mechanizmu OAuth 2.0 w powiązaniu z Microsoft Azure Active Directory. Do uwierzytelnienia przy użyciu certyfikatu trzeba albo mieć już certyfikat zarządzania dodany do subskrypcji Microsoft Azure, albo utworzyć nowy certyfikat X.509 v3 w tym celu.
303
304
Rozdział 9: Monitorowanie i zarządzanie SQL Database
Aby utworzyć nowy certyfikat zarządzania, wykonaj poniższe kroki: 1 . Uruchom Developer Command Prompt (Wiersz polecenia dla deweloperów – jest
to komponent pakietu Visual Studio) jako administrator. Najłatwiej można to zrobić, naciskając klawisz Windows, wpisując Developer Command Prompt, klikając prawym klawiszem znaleziony wynik Developer Command Prompt i wybierając polecenie Run As Administrator (Uruchom jako administrator). Spowoduje to otwarcie konsoli Developer Command Prompt z podniesionymi uprawnieniami. 2 . Wpisz makecert -sky exchange -r -n „CN=Microsoft Azure Service Management Certificate” -pe -a sha1 -len 2048 -ss My „\ MicrosoftAzureServiceManagementCertificate.cer”
i naciśnij Enter. Spowoduje to wygenerowanie nowego certyfikatu X.509 v3, dodanie go do osobistego magazynu certyfikatów i zapisanie go w pliku o nazwie MicrosoftAzureServiceManagmentCertificate.cer w wyspecyfikowanym folderze. Uwaga Frazę należy zastąpić ścieżką do folderu, w którym ma zostać zapisany certyfikat.
Po utworzeniu certyfikatu X.509 v3, który ma posłużyć jako certyfikat zarządzania Microsoft Azure, trzeba go załadować do naszej subskrypcji Microsoft Azure. Aby załadować nowy certyfikat do Microsoft Azure, wykonaj poniższe kroki: 1 . Jeśli zamknąłeś portal Microsoft Azure po poprzedniej procedurze, zaloguj się
ponownie w portalu pod adresem https://manage.windowsazure.com. 2 . Kliknij SETTINGS (ustawienia) na dole panelu nawigacyjnego po lewej. 3 . Kliknij łącze Management Certificates (certyfikaty zarządzania) u góry strony, aby
wyświetlić listę certyfikatów (aktualnie pustą). 4 . Kliknij przycisk Upload (załaduj) w dolnej części strony. Pojawi się okno dialogowe Upload A Management Certificate, pokazane na rysunku 9-16.
5 . Kliknij ikonę folderu, po czym zlokalizuj utworzony w poprzedniej procedurze
plik MicrosoftAzureServiceManagementCertificate.cer. 6 . Kliknij ikonę potwierdzenia w prawym dolnym rogu, aby załadować certyfikat.
Po zakończeniu przesyłania certyfikat pojawi się na liście, jak na rysunku 9-17.
Programowanie API typu REST do zarządzania usługą
Rysunek 9-16 Okno dialogowe Upload A Management Certificate w portalu Microsoft Azure
Rysunek 9-17 Lista certyfikatów zarządzania w portalu Microsoft Azure
305
306
Rozdział 9: Monitorowanie i zarządzanie SQL Database
Po utworzeniu i załadowaniu certyfikatu do subskrypcji Microsoft Azure możemy użyć go do uwierzytelniania API Service Management i wykorzystać te API do zarządzania usługą SQL Database. W kolejnej procedurze zbudujemy aplikację konsolową, która będzie tworzyć żądania HTTP do API Service Management w celu utworzenia bazy danych. Kod tej aplikacji pokazany w Listingu 9-2 pobiera certyfikat zrządzania z lokalnego magazynu na podstawie odcisku palca tego certyfikatu. Następnie buduje wywołanie HttpWebRequest dla API Service Management, dołącza do żądania certyfikat zarządzania i wykonuje to żądanie w trybie asynchronicznym. Rezultat i odpowiedź na żądanie zostaje wypisane w konsoli, gdy żądanie zostanie zakończone. lisTing 9-2 Kod aplikacji konsolowej wykorzystującej API Microsoft Azure Service Management using using using using using
namespace AzureServiceManagementApi { class Program { static void Main() { var subscriptionId = ""; var certThumbprint = ""; var serverName = ""; var databaseName = ""; var certificateStore = new X509Store(StoreName.My, StoreLocation.CurrentUser); certificateStore.Open(OpenFlags.ReadOnly); X509Certificate2Collection certs = certificateStore.Certificates.Find (X509FindType.FindByThumbprint, certThumbprint, false); if (certs.Count == 0) { Console.WriteLine ("Couldn't find the certificate with thumbprint:" + certThumbprint); return; } certificateStore.Close(); var request = (HttpWebRequest)HttpWebRequest.Create(new Uri( "https://management.core.windows.net:8443/" + subscriptionId + "/services/sqlservers/servers/" + serverName + "/databases")); request.Method = "POST"; request.ClientCertificates.Add(certs[0]); request.ContentType = "application/xml"; request.Headers.Add("x ms version", "2012 03 01");
Programowanie API typu REST do zarządzania usługą
var sb = new StringBuilder(""); sb.Append(""); sb.AppendFormat("{0}", databaseName); sb.Append("Web"); sb.Append("1"); sb.Append("SQL_Latin1_General_CP1_CI_AS"); sb.Append(""); var formData = UTF8Encoding.UTF8.GetBytes(sb.ToString()); request.ContentLength = formData.Length; using (var postStream = request.GetRequestStream()) { postStream.Write(formData, 0, formData.Length); } Console.WriteLine("Creating Database: " + databaseName); try { RequestState state = new RequestState(); state.Request = request; IAsyncResult result = request.BeginGetResponse(RespCallback, state); } catch (WebException ex) { var error = new StreamReader(ex.Response.GetResponseStream()).ReadToEnd(); Console.WriteLine("Error: " + error); } catch (Exception ex) { Console.WriteLine("Error: " + ex.Message); } Console.ReadKey(); } public static string EncodeToBase64String(string original) { return Convert.ToBase64String(Encoding.UTF8.GetBytes(original)); } private static void RespCallback(IAsyncResult result) { var state = (RequestState)result.AsyncState; var request = state.Request; var response = (HttpWebResponse)request.EndGetResponse(result); var statusCode = response.StatusCode.ToString(); var reqId = response.GetResponseHeader("x ms request id"); Console.WriteLine("Creation Return Value: " + statusCode); Console.WriteLine("RequestId: " + reqId); } }
307
308
Rozdział 9: Monitorowanie i zarządzanie SQL Database
public class RequestState { const int BufferSize = 4096; public StringBuilder RequestData; public byte[] BufferRead; public WebRequest Request; public Stream ResponseStream; public Decoder StreamDecode = Encoding.UTF8.GetDecoder(); public RequestState() { BufferRead = new byte[BufferSize]; RequestData = new StringBuilder(String.Empty); Request = null; ResponseStream = null; } } }
Wykonaj poniższe kroki, aby zbudować aplikację tworzącą nową bazę danych SQL Database za pośrednictwem API Service Management: 1 . Uruchom Visual Studio 2013 jako administrator. W tym celu na ekranie starto-
wym Windows odszukaj odpowiedni kafelek lub po prostu wpisz visual studio 2013, aby wyszukać aplikację. Prawym klawiszem myszy kliknij kafelek Visual Studio 2013 i wybierz opcję Run As Administrator z paska narzędzi u dołu ekranu. Spowoduje to uruchomienie Visual Studio 2013 z podniesionymi uprawnieniami. Uwaga Uruchomienie Visual Studio 2013 jako administrator jest niezbędne, gdyż budowana przez nas aplikacja będzie musiała mieć uprawnienia do pobrania certyfikatu z lokalnego magazynu w celu uwierzytelnienia się wobec Microsoft Azure Service Management API. W celu zdebugowania aplikacji potrzebne są więc uprawnienia administratora.
2 . Kliknij menu FILE i wybierz New | Project, aby wyświetlić okno dialogowe New Project.
3 . W lewej części okna New Project rozwiń kolejno węzły Templates, Visual C#
i wybierz Console Application. 4 . Nazwij rozwiązanie i projekt AzureServiceManagementApi i wybierz dowolną
wygodną lokalizację do zapisania plików, jak na rysunku 9-18. 5 . Zastąp kod szablonu w pliku Program.cs kodem pokazanym wcześniej w Listingu
9-2, zmieniając wartości zmiennych na początku tego kodu jak poniżej: a . Zastąp frazę identyfikatorem swojej subskrypcji Microsoft
Azure. Można go znaleźć w sekcji Settings | Subscriptions w portalu zarządzania Microsoft Azure.
Programowanie API typu REST do zarządzania usługą
Rysunek 9-18 Tworzenie nowej aplikacji konsolowej w Visual Studio 2013
b . Zastąp odciskiem palca swojego certyfikatu zarządzania.
Można go znaleźć w sekcji Settings | Management Certificates w portalu Microsoft Azure. c . Zastąp nazwą swojego serwera SQL Database. d . Zastąp wpisem WineCloudDbMgmtApi. Jest to nazwa bazy danych, którą utworzy aplikacja konsolowa przy użyciu API Service Management. 6 . Naciśnij F5 lub kliknij Debug | Start Debugging. Spowoduje to otwarcie aplikacji
i utworzenie bazy danych, jak na rysunku 9-19.
Rysunek 9-19 Tworzenie bazy danych w SQL Database za pośrednictwem API Service Management
Powstanie nowej bazy danych można zweryfikować poprzez portal Microsoft Azure. Oprócz tworzenia i usuwania baz danych można w ten sposób tworzyć, aktualizować,
309
310
Rozdział 9: Monitorowanie i zarządzanie SQL Database
usuwać lub przeglądać dowolne inne zasoby SQL Database, włącznie z serwerami i regułami zapory. Wyczerpujące informacje na temat dostępnych funkcji API Service Management dla SQL Database zawiera strona http://msdn.microsoft.com/en-us/library/ gg715283.aspx.
Podsumowanie W tym rozdziale przedstawiliśmy podstawy technik monitorowania SQL Database przy użyciu graficznych interfejsów i narzędzi, takich jak portal Microsoft Azure, strona stanu Microsoft Azure oraz portal zarządzania SQL Database. Przyjrzeliśmy się również operacjom i wydajności naszej bazy danych SQL Database poprzez dynamiczne widoki i funkcje zarządzania, a także poznaliśmy tabele zdarzeń. Usługi, które mają być stosowane w aplikacjach produkcyjnych, muszą zapewniać możliwości monitorowania i Microsoft Azure SQL Database udostępnia wiele opcji tego rodzaju. Na koniec zajęliśmy się automatyzowaniem zarządzania naszymi bazami danych za pośrednictwem API Service Management. Stanowią one zbiór API typu REST, które pozwalają programistycznie zarządzać usługami w Microsoft Azure. Te API typu REST stanowią ośrodek mechanizmów zarządzania Microsoft Azure i zapewniają podstawy zarówno graficznych narzędzi, takich jak portal Microsoft Azure, jak i interfejsów wiersza polecenia, takich jak moduł PowerShell dla Microsoft Azure. Rozdział ten stanowił jedynie wprowadzenie do możliwości monitorowania i zarządzania SQL Database, zapewniając podstawy, na których Czytelnik może budować własne rozwiązania. Warto poświęcić trochę czasu i głębiej wejść w te zagadnienia, tworząc własne zapytania monitorowania wykorzystujące dynamiczne widoki i funkcje zarządzania, a także własne rozwiązania automatyzujące wykorzystujące API Service Management.
ROZDZI AŁ 1 0
Budowanie rozwiązania w chmurze Leonard Lobel
N
a samym początku książki w rozdziale 1 przedstawiliśmy koncepcję przetwarzania w chmurze. Rozpoczęliśmy od wyjaśnienia pojęć infrastruktury jako usługi (Infrastructure as a Service – IaaS), platformy jako usługi (Platform as a Service – PaaS) oraz oprogramowania jako usługi (Software as a Service – SaaS). Wyjaśniliśmy też, że Microsoft Azure SQL Database jest dostarczana jako platforma – innymi słowy, jest to oferta typu PaaS. W kolejnych rozdziałach poznaliśmy różne obszary tej platformy. Teraz, w ostatnim rozdziale książki, zaprezentujemy pełną, od początku do końca, procedurę budowania rozwiązania w chmurze opartego na SQL Database. Poprzez „od początku do końca” rozumiemy utworzenie pełnego stosu komponentów, w którym każda warstwa jest wyróżniana poprzez jej własny obszar odpowiedzialności. Wszystkie te elementy współdziałają ze sobą w celu skonstruowania kompletnej, funkcjonalnej aplikacji. W tym rozdziale pokażemy, jak łączyć SQL Database z innymi komponentami w celu utworzenia własnego rozwiązania typu SaaS. Mówiąc inaczej, zajmiemy się budowaniem dodatkowych warstw ponad SQL Database, aby stworzyć gotową do użycia aplikację działającą wyłącznie w chmurze Microsoft Azure. Rozwiązanie, które utworzymy, będzie oparte na przykładowej bazie WineCloudDb, której używaliśmy w innych rozdziałach książki i będzie zawierało witrynę sieci Web umożliwiającą użytkownikom składanie zamówień poprzez przeglądarkę oraz mobilną aplikację pozwalającą na zarządzanie katalogiem win w bazie danych z urządzeń klasy Windows Phone. Aplikację będziemy budować warstwa po warstwie, od dołu do góry, zaczynając od bazy danych i posuwając się w górę aż do interfejsu użytkownika (UI). Kompletny stos rozwiązania jest zaprezentowany na rysunku 10-1.
311
312
Rozdział 10: Budowanie rozwiązania w chmurze
Windows Phone
Przeglądarka
Witryna Web ASP.NET MVC
ASP.NET Web API
Warstwa dostępu do danych
Microsoft Azure
Entity Framework
SQL Database Procedury składowane Tabele
Rysunek 10-1 Pełne rozwiązanie jest złożone z odrębnych warstw aplikacji.
Oto ogólne przedstawienie zadań, które wykonamy w tym rozdziale: ■
Zaczniemy od istniejącej bazy danych Microsoft Azure SQL Database: Utworzymy bazę danych WineCloudDb z przykładowymi danymi w tabelach Wine i Customer. Tworzenie nowego projekt SQL Server Database: ❐ Zaimportujemy schemat bazy danych z WineCloudDb do nowego projektu bazodanowego SQL Server. Pozwoli to na wykorzystanie narzędzia SQL Server Data Tools (SSDT) w trybie offline, odłączonego od SQL Database. Rozszerzenie schematu bazy danych w projekcie: ❐ Dodamy nową kolumnę w tabeli Wine. ❐ Utworzymy nową tabelę Order. ❐ Utworzymy procedury składowane kontrolujące sposób wstawiania, aktualizowania lub usuwania danych w tabeli Order. ❐ Wdrożenie zmiany wykonane offline w projekcie bazy danych z powrotem w Microsoft Azure SQL Database. ❐
■
■
313
■
Tworzenie warstwy dostępu do danych (data access layer – DAL): Użyjemy Entity Framework (EF) do zarządzania wszystkimi połączeniami i poleceniami przekazywanymi do bazy danych. ❐ Zaprojektujemy Entity Data Model (EDM), aby skonfigurować interakcję EF z tabelami i procedurami składowanymi w bazie danych. Tworzenie witryny ASP.NET: ❐ Zbudujemy aplikację Web typu Model-View-Controller (MVC), poprzez którą użytkownicy będą mogli składać zamówienia, używając dowolnej przeglądarki. ❐ Utworzymy Web API eksponującą operacje tworzenia, odczytywania, aktualizowania i usuwania (create, retrieve, update, delete – CRUD) w tabeli win w bazie danych. Tworzenie aplikacji Windows Phone 8 przy użyciu zestawu narzędziowego Windows Phone Software Development Kit (SDK): ❐ Zbudujemy aplikację mobilną, komunikującą się z poprzednio utworzonym Web API, implementującą katalog win; w katalogu tym użytkownicy będą mogli przeglądać, dodawać, modyfikować i usuwać gatunki win, używając urządzenia typu Windows Phone 8. ❐
■
■
Każdy z tych elementów zostanie zbudowany jako oddzielny, ale powiązany projekt w ramach pojedynczego rozwiązania Microsoft Visual Studio.
Tak wiele wyborów! Rozdział ten prezentuje kompletne, wielowarstwowe rozwiązanie w chmurze, wykorzystujące SQL Database jako zaplecze (back end). Istnieje wiele technologii Microsoft, które pozwalają zrealizować ten cel – trzeba wyraźnie podkreślić, że implementacja rozwiązania chmurowego nie musi koniecznie używać tych technik i mechanizmów, które my wybraliśmy. Warstwę dostępu do danych utworzymy przy użyciu Entity Framework, ale równie dobrze moglibyśmy sięgnąć po inną technologię .NET dostępu do danych (choćby po tradycyjny ADO.NET), która może być doskonale pasującą alternatywą w zależności od scenariusza. Witrynę zamówień zbudujemy przy użyciu platformy ASP.NET Model-View-Controller (MVC), jednak oczywiście moglibyśmy wybrać zastosowanie standardowych formularzy ASP.NET i stron .aspx, albo zupełnie innego, własnego rozwiązania. Zaś w przypadku usługi Web, zdecydowaliśmy się posłużyć coraz popularniejszym Web API ASP. NET, aby zaimplementować usługi protokołu Representational State Transfer (REST). Trzeba jednak pamiętać, że istnieją inne platformy usług, takie jak Simple Object Access Protocol (SOAP) w połączeniu z Windows Communication
314
Rozdział 10: Budowanie rozwiązania w chmurze
Foundation (WCF), następnie WCF Data Services (które także oferują szybkie i łatwe implementowanie usług REST dla EF), a także WCF RIA (Rich Internet Application) Services i wiele innych. Powodem, dla którego wybraliśmy te właśnie, a nie inne technologie, była chęć maksymalnego uproszczenia potencjalnie przytłaczającego scenariusza. Naszym celem nie jest pokazanie wszelkich możliwości projektowania aplikacji (do wyczerpania tej tematyki nie wystarczyłaby cała książka – raczej cała biblioteka), ale przedstawienie podstawowej warstwowej architektury gotowego rozwiązania. Stąd wybór technologii, które można wykorzystać tak szybko i prosto, jak to możliwe. Entity Framework automatycznie zarządza za nas wszystkimi połączeniami, poleceniami i mechanizmami odczytującymi i udostępnia gotowe do użycia obiekty dostępu do danych. W przypadku witryny, technologia ASP. NET MVC ułatwia budowanie aplikacji, którymi łatwiej zarządzać i je testować, niż tradycyjne formularze Web w stronach .aspx. Zaś co do Web API, funkcje szkieletowania Visual Studio sprawiają, że eksponowanie opartej na REST usługi Web odbywa się niemal bez wysiłku. Tym niemniej zdecydowanie zachęcamy do poznawania i eksplorowania alternatywnych podejść przy tworzeniu własnych rozwiązań w chmurze, opartych na SQL Database. Platforma MVC stała się już bardzo popularna wśród projektantów witryn, ale tradycyjne formularze ASP.NET wcale nie są jeszcze przestarzałe i nadal oferują wiele znaczących przewag w porównaniu do MVC, których nie powinno się ignorować. Analogicznie, Web API gwałtownie zdobywa popularność przy tworzeniu lekkich, opartych na REST usługach Web, ale można również rozważyć tworzenie własnej usługi w chmurze Microsoft Azure, hostującej w pełni funkcjonalne mechanizmy WCF, WCF Data Services lub WCF RIA Services. Przy budowaniu własnej usługi chmurowej w Visual Studio trzeba będzie pobrać i zainstalować zestaw Microsoft Azure SDK dla platformy .NET, dostępny na stronie pobierania http://www.windowsazure.com/ en-us/downloads. Niezależnie jednak od tego, jakie konkretnie technologie wybierzemy, podstawowe koncepcje wielowarstwowego projektowania i przetwarzania, zaprezentowane w tym rozdziale, pozostają w mocy.
Tworzenie bazy danych SQL Database Aby rozpocząć, wykorzystamy SSDT wewnątrz Visual Studio do szybkiego utworzenia bazy danych WineCloudDb, podobnej to tych, których używaliśmy w poprzednich rozdziałach tej książki. Jak można zauważyć w Listingu 10-1, baza ta będzie zawierać początkowo tylko tabele Wine i Customer oraz po kilka wierszy danych, ale szybko
Tworzenie bazy danych SQL Database
ją rozbudujemy poprzez dołączenie dodatkowych kolumn, tabel i procedur składowanych, aby w pełni obsłużyć projektowane rozwiązanie. lisTing 10-1 Skrypt tworzący bazę danych WineCloudDb CREATE TABLE Wine( WineId int IDENTITY PRIMARY KEY, Name nvarchar(50) NOT NULL, Category nvarchar(15) NOT NULL, Year int); CREATE TABLE Customer( CustomerId int IDENTITY PRIMARY KEY, FirstName nvarchar(50) NOT NULL, LastName nvarchar(50) NOT NULL, FavoriteWineId int, CONSTRAINT FK_Customer_Wine FOREIGN KEY (FavoriteWineId) REFERENCES Wine(WineId)); SET IDENTITY_INSERT Wine ON; INSERT Wine (WineId, Name, Category, Year) VALUES (1, ‘Chateau Penin’, ‘Bordeaux’, 2008), (2, ‘McLaren Valley’, ‘Cabernet’, 2005), (3, ‘Mendoza’, ‘Merlot’, 2010), (4, ‘Valle Central’, ‘Merlot’, 2009); SET IDENTITY_INSERT Wine OFF; SET IDENTITY_INSERT Customer ON; INSERT Customer (CustomerId, FirstName, LastName, FavoriteWineId) VALUES (1, ‘Jeff’, ‘Hay’, 4), (2, ‘Mark’, ‘Hanson’, 3), (3, ‘Jeff’, ‘Phillips’, 2); SET IDENTITY_INSERT Customer OFF;
Aby utworzyć bazę danych WineCloudDb, wykonaj poniższe kroki: 1 . Uruchom Visual Studio 2013. 2 . Jeśli panel SQL Server Object Explorer nie jest widoczny, kliknij menu VIEW
i wybierz SQL Server Object Explorer. 3 . W panelu SQL Server Object Explorer kliknij prawym klawiszem myszy węzeł SQL Server i wybierz Add SQL Server. Pojawi się dobrze znane okno dialogowe Connect To Server.
4 . W tym oknie dialogowym wykonaj następujące czynności: a . W polu Server Name wpisz .database.windows.net, czyli w pełni
kwalifikowaną nazwę serwera SQL Database, zastępując nazwą przypisaną do swojego serwera. b . W polu Authentication wybierz z listy rozwijanej SQL Server Authentication (SQL Database nie wspiera uwierzytelniania Windows). c . W polach Login i Password wpisz nazwę użytkownika i hasło przypisane do serwera przy jego utworzeniu.
315
316
Rozdział 10: Budowanie rozwiązania w chmurze
d . Kliknij Connect. Serwer pojawi się jako zwinięty węzeł w panelu SQL Server
Object Explorer. 5 . Rozwiń węzeł serwera. 6 . Rozwiń węzeł Databases. 7 . Jeśli na liście istnieje wcześniejsza wersja WineCloudDb po ćwiczeniach wykony-
wanych w poprzednich rozdziałach, usuń ją: a . Prawym klawiszem myszy kliknij istniejącą WineCloudDb i wybierz Delete. b . Kliknij OK w monicie potwierdzenia. 8 . Prawym klawiszem myszy kliknij węzeł Databases i wybierz Add New Database. 9 . Wpisz WineCloudDb i naciśnij Enter. Nowa baza danych pojawi się w panelu
SQL Server Object Explorer. 10 . Prawym klawiszem myszy kliknij bazę danych WineCloudDb i wybierz New Query,
aby otworzyć okno zapytania powiązane z tą bazą danych. 11 . Wpisz kod pokazany w Listingu 10-1 do okna zapytania (albo skopiuj go z pliku
pobranego z witryny powiązanej z książką). 12 . Naciśnij Ctrl+Shift+E, aby wykonać skrypt (albo naciśnij przycisk odtwarzania
w pasku narzędzi okna zapytania). 13 . Zamknij okno zapytania (nie ma potrzeby zapisywania zmian).
Rozbudowywanie bazy danych Jak dotąd, posługiwaliśmy się narzędziami SQL Server Data Tools (SSDT) wewnątrz Visual Studio 2013 do pracy z SQL Database w trybie połączonym. Używanie SSDT do projektowania w trybie połączonym jest analogiczne do posługiwania się SQL Server Management Studio (SSMS), przy czym praca w taki sposób jest doskonałym wyborem, gdy wszystko, co trzeba zrobić, to wykonanie zapytania lub szybkie poprawienie czegoś na działającym serwerze. Jednak nie jest to preferowana metoda projektowania baz danych przy użyciu SSDT. Bardziej pożądana droga budowania baz danych to praca w trybie offline (bez połączenia), przy użyciu projektu typu SQL Server Database. Dzięki takiemu podejściu można polegać na definicji bazy danych zawartej wewnątrz projektu Visual Studio (a nie na samej bazie danych), co pozwala na jej zabezpieczenie i wersjonowanie przy użyciu mechanizmów kontroli kodu źródłowego (SCC). W przykładach prezentowanych w tym rozdziale zaczniemy od już istniejącej bazy danych SQL Database w chmurze, którą właśnie utworzyliśmy przy użyciu połączonego SSDT, i zaimportujemy jej definicję schematu do nowego projektu SQL Server Database. Następnie będziemy kontynuowali pracę, używając niepołączonego SSDT – czyli pracując w trybie offline i stopniowo wdrażając zmiany w aktywnej bazie SQL Database.
Rozbudowywanie bazy danych
Tworzenie nowego rozwiązania Projekty Visual Studio są zawsze zawarte wewnątrz rozwiązania (solution) Visual Studio, zatem rozpoczniemy od utworzenia pustego rozwiązania. Następnie zaimportujemy schemat bazy danych z SQL Database do nowego projektu SQL Server Database, pierwszego z kilku projektów, które utworzymy wewnątrz tego rozwiązania. Po utworzeniu projektu rozbudujemy bazę danych WineCloudDb, dodając nowe kolumny, tabele i procedury składowane. Na koniec wdrożymy zaktualizowany schemat, publikując projekt z powrotem do SQL Database w chmurze. Wykonaj poniższe kroki, aby utworzyć nowe rozwiązanie: 1 . W programie Visual Studio 2013 kliknij menu FILE i wybierz New | Project, aby
wyświetlić okno dialogowe New Project. 2 . W lewej części okna dialogowego New Project rozwiń kolejno węzły Templates
(szablony), Other Project Types (inne typy projektów) i wybierz Visual Studio Solutions. 3 . Wybierz szablon Blank Solution (puste rozwiązanie), nazwij je WineCloudSolution
i wybierz odpowiednią lokalizację do zapisania rozwiązania, jak na rysunku 10-2.
Rysunek 10-2 Tworzenie nowego, pustego rozwiązania
4 . Kliknij OK.
Panel Solution Explorer powinien pokazywać nowy węzeł WineCloudSolution (jeśli panel ten nie jest widoczny, kliknij VIEW i wybierz Solution Explorer). Możemy teraz przystąpić do tworzenia nowego projektu SQL Server Database.
317
318
Rozdział 10: Budowanie rozwiązania w chmurze
Tworzenie projektu typu SQL Server Database Za pomocą projektu SQL Server Database można zaprojektować kompletną bazę danych bez połączenia z instancją SQL Server, SQL Database czy w ogóle z Internetem. Projekt SQL Server Database jest projektem Visual Studio, zawierającym indywidualne, deklaratywne pliki źródłowe języka Transact SQL (T-SQL), które łącznie definiują pełną strukturę bazy danych. Ponieważ definicja bazy jest utrzymywana wewnątrz projektu Visual Studio, można ją zabezpieczyć i chronić przy użyciu różnych systemów kontroli kodu, takich jak Team Foundation Server lub Git, podobnie jak w przypadku dowolnych innych typów projektów Visual Studio. Co więcej, SSDT udostępnia lokalną instancję SQL Server (localdb), której można użyć do przetestowania projektu bazy danych przed wdrożeniem jej z powrotem na właściwym serwerze. Istnieje wiele sposobów tworzenia projektów SQL Server Database. Można zacząć od pustego projektu, zaprojektować strukturę bazy od podstaw wewnątrz projektu i opublikować całą tę strukturę w nowej bazie SQL Database. Znacznie częściej jednak mamy już istniejącą bazę danych (jak baza danych WineCloudDb w naszym scenariuszu). W takiej sytuacji można zaimportować tę bazę danych do projektu. W kilku kolejnych procedurach utworzymy nowy projekt i zaimportujemy do niego strukturę bazy WineCloudDb. Aby utworzyć projekt SQL Server Database, wykonaj poniższe kroki: 1 . Prawym klawiszem myszy kliknij WineCloudSolution w panelu Solution Explorer,
po czym wybierz polecenie Add | New Project. Pojawi się okno dialogowe New Project.
2 . W lewej części okna dialogowego rozwiń węzeł Installed (zainstalowane) i wybierz SQL Server.
3 . Zaznacz szablon SQL Server Database Project i nazwij projekt WineCloudDb (zale-
cane jest nazywanie projektu tak samo jak bazy danych), jak na rysunku 10-3. 4 . Kliknij OK, aby utworzyć projekt i dodać go do rozwiązania.
Nasze rozwiązanie zawiera już projekt bazodanowy, ale nie ma jeszcze żadnych elementów zdefiniowanych w tym projekcie.
Rozbudowywanie bazy danych
Rysunek 10-3 Tworzenie nowego projektu SQL Server Database
Ustawianie platformy docelowej Jedną z przewag zapewnianych przez projekty SQL Server Database jest to, że umożliwają one projektowanie baz danych, które mają działać w różnych wersjach SQL Server (w tym SQL Server 2005, 2008, 2008 R2 oraz 2012) lub w Microsoft Azure SQL Database. Docelową platformę ustawiamy we właściwościach projektu, wybierając określoną wersję SQL Server, na której projekt ma zostać wdrożony. Poprzez wybór platformy docelowej nakazujemy Visual Studio przeprowadzić walidację projektu i sprawdzenie, że projekt bazy jest kompatybilny z wybraną wersją. Walidacja odbywa się w czasie rzeczywistym – w miarę modyfikowania projektu Visual Studio na bieżąco sprawdza w tle nasz projekt i zgłasza błędy, jeśli spróbujemy zrobić coś nieobsługiwanego przez wybraną platformę docelową. (Rozdział 3 zawiera omówienie ważnych różnic pomiędzy Microsoft Azure SQL Database a lokalnymi (w siedzibie) instalacjami SQL Server). Przy tworzeniu nowego projektu SQL Server Database docelowa platforma jest domyślnie ustawiana na SQL Server 2012. Zatem przed wykonaniem dowolnych zmian w projekcie bazy dobrą rzeczą będzie zmiana platformy docelowej, aby Visual Studio wiedziało, że zamierzamy wdrożyć projekt w Microsoft Azure SQL Database, a nie instancji SQL Server 2012 w siedzibie. Aby ustawić platformę docelową projektu na SQL Database, wykonaj poniższe kroki: 1 . Prawym klawiszem myszy kliknij projekt WineCloudDb w panelu Solution Explorer
i wybierz Properties (właściwości). W górnej części karty Project Settings (ustawienia projektu) opcja Target Platform (platforma docelowa) powinna być ustawiona na SQL Server 2012.
319
320
Rozdział 10: Budowanie rozwiązania w chmurze
2 . Kliknij listę rozwijaną Target Platform i wybierz Windows Azure SQL Database, jak
na rysunku 10-4. (Zauważmy, że nadal występuje tu stara nazwa, choć usługa została przemianowana na Microsoft Azure SQL Database).
Rysunek 10-4 Zmienianie platformy docelowej projektu bazodanowego
3 . Kliknij menu FILE i wybierz Save Selected Items (albo naciśnij Ctrl+S).
Po wykonaniu tej zmiany możemy spokojnie pracować nad naszym projektem, mając świadomość, że Visual Studio ostrzeże nas, jeśli spróbujemy zrobić coś niekompatybilnego ze specyfikacją SQL Database. Kolejnym zadaniem jest zaimportowanie bazy WineCloudDb do naszego projektu.
Importowanie bazy SQL Database do projektu Importowanie bazy danych wypełnia projekt wszystkimi plikami T-SQL, które w pełni definiują strukturę bazy WineCloudDb – w tym przypadku będą to tabele Wine i Customer utworzone przy użyciu kodu zawartego w Listingu 10-1. Można to łatwo zrealizować poprzez okno dialogowe Import Database. Aby zaimportować bazę WineCloudDb do projektu, wykonaj poniższe kroki: 1 . Prawym klawiszem myszy kliknij projekt WineCloudDb w panelu Solution Explorer
i wybierz polecenia Import | Database. Pojawi się okno dialogowe Import Database, pokazane na rysunku 10-5.
Rozbudowywanie bazy danych
Rysunek 10-5 Okno dialogowe Import Database
2 . Kliknij przycisk New Connection poniżej tytułu Source Database Connection (połą-
czenie źródłowej bazy danych), aby wyświetlić okno dialogowe Connection Properties.
3 . W polu Server Name wpisz pełną nazwę hosta swojego serwera SQL Database.
Przypomnijmy, że nazwa ta składa się z losowej nazwy przypisanej przy tworzeniu serwera, uzupełnionej o .database.windows.net. 4 . Wybierz opcję Use SQL Server Authentication i wpisz nazwę użytkownika i hasło
przypisane do serwera. 5 . Kliknij listę rozwijaną poniżej przycisku radiowego Select Or Enter A Database Name (wybierz lub wpisz nazwę bazy danych) i wybierz z niej bazę WineCloudDb. Okno dialogowe powinno wyglądać podobnie, jak na rysunku 10-6.
6 . Kliknij OK. Okno Connection Properties zostanie zamknięte i powrócimy do okna
Import Database. 7 . Kliknij Start. Potrzeba będzie tylko kilka chwil, aby Visual Studio przeanalizowało
bazę danych i odkryło wszystkie zawarte w niej obiekty, co widać na rysunku 10-7.
321
322
Rozdział 10: Budowanie rozwiązania w chmurze
Rysunek 10-6 Okno dialogowe Connection Properties
Rysunek 10-7 Importowanie bazy WineCloudDb do projektu WineCloudDb typu SQL Server Database
8 . Kliknij Finish.
Rozbudowywanie bazy danych
Możemy zauważyć teraz, że w panelu Solution Explorer pojawił się folder dbo, stanowiący schemat, w którym zawarte są zaimportowane obiekty bazodanowe. Jeśli rozwiniemy ten folder, znajdziemy w nim folder Tables, a w nim po jednym pliku .sql dla każdej zaimportowanej tabeli (w naszym przypadku będą to pliki Customer.sql oraz Wine.sql). Pliki możemy teraz edytować, co oznacza w istocie, że możemy kontynuować projektowanie bazy danych całkowicie offline. Później, gdy zechcemy, możemy wdrożyć zmodyfikowany projekt ponownie w bazie danych SQL Database w chmurze.
Dodawanie nowej kolumny do tabeli Wine W kolejnej procedurze wykorzystamy narzędzie projektowania tabel w SSDT do utworzenia dodatkowej kolumny w tabeli Wine. Tabela ta zawiera już kolumny WineId, Name, Category i Year, ale aby móc użyć jej jako katalogu do składania zamówień, potrzebna jest jeszcze kolumna z ceną (Price). Wykonaj poniższe działania, aby utworzyć nową kolumnę Price w tabeli Wine: 1 . W panelu Solution Explorer rozwiń folder dbo i w nim rozwiń folder Tables. 2 . Prawym klawiszem myszy kliknij plik Wine.sql i wybierz polecenie View Designer
(projektant widoku) (albo po prostu podwójnie kliknij plik Wine.sql). Spowoduje to otwarcie narzędzia projektanta w widoku podzielonego ekranu; górna część projektanta pokazuje strukturę tabeli w postaci siatki, zaś w dolnej połowie widoczny jest kod T-SQL tworzący tabelę zawierającą te kolumny. 3 . W obszarze siatki w górnej części projektanta kliknij komórkę Name w pustym
wierszu u dołu siatki. 4 . Wpisz Price w komórce Name i naciśnij klawisz Tab, aby przejść do komórki Data Type (typ danych).
5 . Wpisz money w komórce Data Type i naciśnij klawisz Tab. 6 . Wyczyść pole wyboru Allow Nulls (zezwalaj na wartości null) i naciśnij klawisz
Tab. Oznacza to, że SQL Database nie zezwoli na puste wartości przy zapisywaniu nowych wierszy w bazie danych; innymi słowy, każde wino musi mieć określoną cenę. 7 . Wpisz 0 w komórce Default. Jest to konieczne, gdyż tabela Wine już zawiera jakieś
dane. Ponieważ nie są dozwolone wartości null w kolumnie Price, ustawienie wartości domyślnej spowoduje nadanie ceny 0 wszystkim istniejącym wierszom danym w tabeli, gdy wdrożymy nowy projekt ponownie w SQL Database. 8 . Kliknij menu FILE i wybierz polecenie Save Wine.sql (albo naciśnij Ctrl+S).
Projektant tabel powinien wyglądać w tym momencie tak, jak na rysunku 10-8.
323
324
Rozdział 10: Budowanie rozwiązania w chmurze
Rysunek 10-8 Dodawanie nowych kolumn do tabeli przy użyciu projektanta tabel
wskazówka W tej procedurze zmiany wprowadzaliśmy w obszarze siatki (projektowym) w górnej części projektanta, zaś Visual Studio automatycznie zaktualizowało powiązany kod T-SQL w dolnej części. Jednak projektant tabel obsługuje dwukierunkową edycję. Moglibyśmy równie dobrze wprowadzać zmiany poprzez bezpośrednią edycję kodu T-SQL w dolnej części, a Visual Studio uaktualniłoby siatkę projektową w górnej części. Tej techniki użyjemy niedługo podczas dodawania do bazy danych tabeli Order w kolejnej procedurze.
Zwróćmy uwagę, że musieliśmy przypisać wartość domyślną dla kolumny Price, gdyż tabela Wine już zawiera dane i jednocześnie określiliśmy, że tabela nie będzie pozwalała na stosowanie wartości null w tej nowej kolumnie. W tej sytuacji konieczne jest narzucenie wartości domyślnej, gdyż jakaś wartość dla kolumny Price musi zostać przypisana istniejącym wierszom. Jednak po wdrożeniu nowej tabeli i uaktualnieniu istniejących wierszy domyślnymi wartościami można zdecydować się na usunięcie wartości domyślnej z projektu tabeli, aby w przyszłości przy wprowadzaniu nowych wierszy wymusić podanie jakiejś (nie-NULL) wartości dla kolumny Price.
Rozbudowywanie bazy danych
Wdrażanie zmodyfikowanego projektu z powrotem w Microsoft Azure SQL Database Okno dialogowe Publish Database (publikuj bazę danych) pozwala wdrożyć projekt typu SQL Server Database w faktycznej bazie danych. Proces publikowania wywołuje operację porównania schematu, która wykonuje analizę struktury projektu źródłowego i docelowej bazy danych, po czym generuje skrypt zmieniający – zestaw wyrażeń T-SQL, modyfikujących bazę danych tak, aby pasowała do projektu. W kolejnej procedurze wykorzystamy okno dialogowe Publish Database do wdrożenia zmiany wykonanej w projekcie (czyli dodania nowej kolumny Price w tabeli Wine) w oryginalnej bazie SQL Database w chmurze. Aby wdrożyć projekt, wykonaj poniższe kroki: 1 . Prawym klawiszem myszy kliknij projekt WineCloudDb w panelu Solution Explorer
i wybierz polecenie Publish. Pojawi się okno dialogowe Publish Database, pokazane na rysunku 10-9.
Rysunek 10-9 Okno dialogowe Publish Database
2 . Kliknij przycisk Edit na prawo od wpisu Target Database Connection (połączenie
docelowej bazy danych); pojawi się znajome okno dialogowe Connection Properties. Wpisz informacje połączenia z bazą WineCloudDb, jak to już robiliśmy wielokrotnie wcześniej: a . W polu Server Name wpisz pełną nazwę hosta serwera SQL Database (losowo
wybraną nazwę serwera uzupełnioną o database.windows.net). b . Wybierz Use SQL Server Authentication. c . Wpisz nazwę użytkownika i hasło przypisane wcześniej do serwera. d . Kliknij listę rozwijaną poniżej przycisku radiowego Select Or Enter A Database Name i zaznacz bazę WineCloudDb (o ile nie jest już domyślnie zaznaczona).
325
326
Rozdział 10: Budowanie rozwiązania w chmurze
3 . Kliknij OK, aby zamknąć okno dialogowe Connection Properties. Okno Publish Database powinno teraz wyglądać tak, jak na rysunku 10-10.
4 . Kliknij przycisk Save Profile As (zapisz profil jako), wpisz WineCloudDb i klik-
nij Save. Spowoduje to zapisanie informacji połączenia wpisanych przed chwilą do pliku nazwanego WineCloudDb.publish.xml, dzięki czemu nie będziemy musieli wpisywać ich ponownie za każdym razem, gdy będziemy wdrażać kolejne zmiany w bazie danych.
Rysunek 10-10 Okno Publish Database po wprowadzeniu informacji połączenia z docelową bazą danych
5 . Kliknij przycisk Publish, aby rozpocząć proces wdrażania. wskazówka Zamiast przycisku Publish można użyć przycisku Generate Script. Spowoduje to również wywołanie operacji porównania schematu i wygenerowanie skryptu zmian. Jednak zamiast wykonywania tego skryptu, Visual Studio wyświetli go w nowym oknie zapytania. W ten sposób uzyskujemy możliwość przejrzenia skryptu przed jego wykonaniem, aby móc zobaczyć, jakie dokładnie działania będą podejmowane. Następnie możemy zdecydować się na wykonanie skryptu tak jak jest, przeedytować go lub zapisać do wykonania w późniejszym terminie.
W trakcie procesu wdrażania Visual Studio wyświetla postęp działań i ich status w panelu Data Tools Operations (operacje narzędzi danych). Rysunek 10-11 pokazuje ten panel chwilę po udanym zakończeniu wdrażania. Tabela Wine zawiera teraz nową kolumnę Price, ale wszystkie ceny istniejących win wynoszą 0, gdyż taką wartość domyślną ustanowiliśmy dla kolumny Price w projekcie. W kolejnej procedurze wykorzystamy panel SQL Server Object Explorer do uaktualnienia tabeli Wine i przypisania niezerowych cen dla każdego wiersza.
Rozbudowywanie bazy danych
Rysunek 10-11 Status wdrażania wyświetlany w panelu Data Tools Operations
W celu ustawienia cen win wykonaj poniższe kroki: 1 . Jeśli panel SQL Server Object Explorer nie jest widoczny, kliknij menu VIEW i wybierz SQL Server Object Explorer.
2 . W panelu tym rozwiń węzeł SQL Server. 3 . Poniżej węzła SQL Server rozwiń węzeł serwera dla twojej bazy SQL Database (czyli
ten, który zawiera nazwę serwera uzupełnioną o .database.windows.net). 4 . Rozwiń węzeł Database. 5 . Rozwiń węzeł WineCloudDb. 6 . Rozwiń węzeł Tables. 7 . Prawym klawiszem myszy kliknij węzeł tabeli dbo.Wine i wybierz View Data.
Spowoduje to wyświetlenie nowego okna zawierającego cztery wiersze danych wstawionych przy tworzeniu tabeli w Listingu 10-1, przy czym wszystkie one mają teraz przypisaną cenę równą 0 w kolumnie Price. 8 . Kliknij komórkę Price w pierwszym wierszu i zmień jej wartość na dowolną nie-
zerową liczbę, na przykład 34.90.
327
328
Rozdział 10: Budowanie rozwiązania w chmurze
9 . Powtórz poprzedni krok dla każdego z pozostałych wierszy, wpisując dowolne
wartości różne od zera, na przykład 48.50, 42.00 i 52.00. Ekran powinien wyglądać podobnie jak na rysunku 10-12.
Rysunek 10-12 Wykorzystanie panelu SQL Server Object Explorer do edytowania cen w tabeli Wine
Tworzenie tabeli Order Kolejną rzeczą, którą musimy zrobić, jest utworzenie tabeli Order, tak by użytkownicy mogli składać zamówienia w celu zakupu wina. W realnych aplikacjach typu eCommerce utworzylibyśmy również dodatkową tabelę szczegółów, tak by pojedyncze zamówienie mogło zawierać wiele różnych produktów (wiele gatunków wina). Jednak dla uproszczenia tego scenariusza ograniczymy się do pojedynczej tabeli Order; w tej aplikacji w jednym zamówieniu będzie można zakupić tylko jeden gatunek wina (choć w dowolnej ilości). W kolejnej procedurze wrócimy do projektu bazy danych, aby utworzyć nową tabelę Order, a następnie ponownie wdrożymy projekt w SQL Database. To działanie demonstruje iteracyjne cykle projektowania, najczęściej stosowane przy projektowaniu baz danych za pomocą projektów SQL Server Database w Visual Studio: ■ ■
Tworzenie zmian offline w projekcie SQL Server Database. Wdrażanie zmian w SQL Database poprzez proces publikowania. W ten sposób zmiany wprowadzane są stopniowo i przez cały czas zachowujemy nad nimi kontrolę.
Rozbudowywanie bazy danych
Aby utworzyć tabelę Order, wykonaj poniższe kroki: 1 . W panelu Solution Explorer rozwiń folder dbo. 2 . Wewnątrz tego folderu prawym klawiszem myszy kliknij folder Tables i wybierz
polecenie Add | Table. 3 . Nazwij tabelę Order.sql i kliknij przycisk Add, aby wyświetlić projektanta tabel.
Projektant zaczyna pracę z pojedynczą kolumną typu całkowitoliczbowego o nazwie Id, zdefiniowanej już jako klucz główny tabeli. 4 . Utwórz kolumnę OrderId: a . Kliknij pole Name i zmień nazwę kolumny Id na OrderId. b . W oknie Properties (właściwości) rozwiń węzeł Identity Specification (specyfikacja
tożsamości) i zmień właściwość (Is Identity) z domyślnej wartości False na True (prawda). (Jeśli okno Properties nie jest widoczne, kliknij menu VIEW i wybierz Properties Window). Ustawienie to sprawia, że podczas wstawiania nowych wierszy zamówień do tabeli SQL Database będzie automatycznie przypisywać inkrementowane wartości całkowite w tej kolumnie dla każdego wiersza. 5 . Dodaj kolumnę OrderedOn (zamówione): a . Wpisz OrderedOn w komórce Name poniżej OrderId, po czym naciśnij klawisz
Tab, aby przejść do komórki Data Type. b . Wpisz datetime2(7) w komórce Data Type. c . Usuń zaznaczenie z pola Allow Nulls (zezwalaj na wartości null). 6 . Dodaj pozostałe kolumny, ale tym razem posługując się oknem kodu, zamiast
siatki projektowania schematu, wykonując poniższe kroki: a . Kliknij w oknie kodu poniżej siatki schematu tabeli, aby umieścić kursor bez-
pośrednio za znakiem zamykającego nawiasu. b . Wpisz poniższy kod definiujący pozostałe kolumny (zwróć uwagę, że projektant aktualizuje schemat w siatce w miarę pisania): ,CustomerId int NOT NULL ,WineId int NOT NULL ,Quantity int NOT NULL ,UnitPrice money NOT NULL ,Price money NOT NULL ,AddedOn datetime2 NOT NULL DEFAULT SYSDATETIME() ,UpdatedOn datetime2 NULL
Kolumny CustomerId oraz WineId będą kluczami obcymi powiązanymi z tabelami Customer i Wine odpowiednio, zatem ostatnim krokiem projektowania tabeli Order będzie ustanowienie relacji klucza obcego dla tych kolumn. W ten sposób zagwarantujemy, że nie będzie można utworzyć zamówień dla klientów lub gatunków win, które w rzeczywistości nie istnieją.
329
330
Rozdział 10: Budowanie rozwiązania w chmurze
Aby utworzyć relację klucza obcego pomiędzy tabelami Order i Customer, wykonaj poniższe działania: 1 . W górnej części projektanta tabel kliknij prawym klawiszem myszy Foreign Keys
(klucze obce) i wybierz polecenie Add New Foreign Key (dodaj nowy klucz obcy). 2 . Nazwij nowy klucz FK_Order_Customer. (Zalecaną praktyką jest nadawanie
kluczom obcym nazw wskazujących tabele uczestniczące w relacji). Spowoduje to utworzenie niepełnej klauzuli FOREIGN KEY w oknie kodu T-SQL w dolnej części projektanta. 3 . Przejdź do klauzuli FOREIGN KEY w oknie kodu i uzupełnij ją, aby brzmiała FOREIGN KEY (CustomerId) REFERENCES Customer(CustomerId). Następnie wykonaj analogiczne kroki, aby utworzyć relację obcego klucza pomiędzy tabelami Order i Wine: 1 . W górnej części projektanta tabel prawym klawiszem myszy kliknij Foreign Keys
i wybierz Add New Foreign Key. 2 . Nazwij nowy klucz FK_Order_Wine. 3 . Przeedytuj nową klauzulę FOREIGN KEY dodaną w oknie kodu T-SQL, aby brzmiała FOREIGN KEY (WineId) REFERENCES Wine(WineId). 4 . Kliknij menu FILE i wybierz Save Order.sql (albo naciśnij Ctrl+S). Gotowy projekt tabeli Order powinien wyglądać tak, jak na rysunku 10-13.
Rysunek 10-13 Ukończony projekt tabeli Order
Rozbudowywanie bazy danych
Tworzenie procedur składowanych dla tabeli Order Projekt tabeli Order jest gotowy. Jednak nie powinniśmy pozwalać aplikacjom na bezpośrednie wstawianie, aktualizowanie czy usuwanie wierszy w tabelach. Lepszym wyjściem jest utworzenie procedur składowanych kontrolujących dostęp do tabel. Takie podejście pozwala zabezpieczyć się przed wprowadzaniem do tabel danych nieprawidłowych z punktu widzenia reguł biznesowych. Na przykład na razie nie istnieje nic, co powstrzymałoby użytkownika (lub aplikację) przed zapisaniem ujemnej wartości w kolumnie Quantity (ilość) lub nieprawidłowej wartości w kolumnach UnitPrice (cena jednostkowa) i Price (cena). Nie ma też żadnej gwarancji, że nowe wiersze dodawane do tabeli otrzymają bieżącą datę i czas w kolumnie AddedOn, ani że przy aktualizowaniu wierszy w tabeli zostanie odpowiednio ustawiona bieżąca data i czas w kolumnie UpdatedOn. Tworzenie procedur składowanych do obsługi dostępu do tabeli pozwala zabezpieczyć bazę danych przed zapisywaniem nieprawidłowych danych i zagwarantować, że krytyczne obliczenia biznesowe i reguły walidacyjne nie zostaną pominięte. Tak więc, zamiast pozwalać na bezpośredni dostęp do tabel, aplikacja kliencka otrzyma dostęp pośredni, poprzez procedury składowane, które będą aplikować wybrane przez nas reguły. W istocie tworzy to „warstwę usługi” dla tabel w bazie danych. W kolejnych kilku procedurach utworzymy trzy procedury składowane dla tabeli Order, aby zagwarantować, że przestrzegane będą następujące reguły: ■
■
■
■
■
■
Kolumna Quantity w każdym wierszu zawsze będzie zawierać liczbę dodatnią (większą od zera). Kolumna UnitPrice dla każdego wiersza będzie zawsze wynikać z bieżącej ceny wina wskazywanego przez kolumnę WineId. Kolumna Price w każdym wierszu będzie zawsze wyliczana jako wynik mnożenia Quantity i UnitPrice. W nowych wierszach kolumna AddedOn będzie miała przypisaną bieżącą datę i czas serwera bazodanowego. W przypadku aktualizowania wierszy kolumna UpdatedOn będzie miała przypisywaną bieżącą datę i czas, zaś oryginalna wartość w kolumnie AddedOn nigdy nie będzie nadpisywana. Zamówienia (rekordy) młodsze niż jeden rok nie mogą być usuwane z bazy.
Procedury składowane narzucające te reguły są przedstawione w Listingu 10-2 (wstawianie), Listingu 10-3 (aktualizacja) i Listingu 10-4 (usuwanie): lisTing 10-2 Procedura składowana InsertOrder CREATE PROCEDURE InsertOrder @OrderedOn datetime2, @CustomerId int,
331
332
Rozdział 10: Budowanie rozwiązania w chmurze
@WineId int, @Quantity int AS Nie zezwalamy na wartość zero lub ujemną w kolumnie Quantity IF @Quantity < 1 THROW 50000, ‘Ilość musi wynosić 1 lub więcej’, 1; Odczytanie ceny jednostkowej z tabeli Wine DECLARE @UnitPrice money = (SELECT Price FROM Wine WHERE WineId = @WineId); Sprawdzenie, że podany gatunek wina istnieje IF @@ROWCOUNT = 0 THROW 50000, ‘Nie znaleziono wskazanego wina’, 1; Wyliczenie ceny całkowitej DECLARE @Price money = @Quantity * @UnitPrice; Wstawienie bieżącej daty i czasu w kolumnie AddedOn DECLARE @AddedOn datetime2 = SYSDATETIME(); INSERT INTO [Order] (OrderedOn, CustomerId, WineId, Quantity, UnitPrice, Price, AddedOn) VALUES (@OrderedOn, @CustomerId, @WineId, @Quantity, @UnitPrice, @Price, @AddedOn); Zwrócenie nowej wartości OrderId SELECT OrderId = SCOPE_IDENTITY();
lisTing 10-3 Procedura składowana UpdateOrder CREATE PROCEDURE UpdateOrder @OrderId int, @OrderedOn datetime2, @CustomerId int, @WineId int, @Quantity int AS Nie zezwalamy na wartość zero lub ujemną w kolumnie Quantity IF @Quantity < 1 THROW 50000, ‘Ilość musi wynosić 1 lub więcej’, 1; Odczytanie ceny jednostkowej z tabeli Wine DECLARE @UnitPrice money = (SELECT Price FROM Wine WHERE WineId = @WineId); Sprawdzenie, że podany gatunek wina istnieje IF @@ROWCOUNT = 0 THROW 50000, ‘Nie znaleziono wskazanego wina’, 1; Wyliczenie ceny całkowitej DECLARE @Price money = @Quantity * @UnitPrice; Wstawienie bieżącej daty i czasu w kolumnie UpdatedOn DECLARE @UpdatedOn datetime2 = SYSDATETIME(); Aktualizowanie danych UPDATE [Order] SET
lisTing 10-4 Procedura składowana DeleteOrder CREATE PROCEDURE DeleteOrder @OrderId int AS Nie zezwalamy na usuwanie zamówień złożonych później niż rok temu DECLARE @DaysOld int = (SELECT DATEDIFF(DAY, OrderedOn, SYSDATETIME()) FROM [Order] WHERE OrderId = @ OrderId); Sprawdzenie, że wskazane zamówienie istnieje IF @@ROWCOUNT = 0 THROW 50000, ‘The specified order was not found’, 1; Zapewnienie, że zamówienia młodsze niż rok nie zostaną usunięte IF @DaysOld < 365 THROW 50000, ‘Zamówienia złożone później niż rok temu nie mogą być usuwane’, 1; Usunięcie wiersza DELETE FROM [Order] WHERE OrderId = @OrderId;
W procedurze składowanej InsertOrder przekazywany do niej parametr @Quantity jest weryfikowany w celu zapewnienia, że przekazano liczbę większą od zera. Zmienna @UnitPrice otrzymuje wartość ceny wybranego wina poprzez odpytanie tabeli Wine pod kątem parametru @WineId. Po przetestowaniu zmiennej @@ROWCOUNT w celu sprawdzenia, że wybrane wino istnieje, wyliczana jest zmienna @Price jako iloczyn @Quantity i @UnitPrice. Następnie zostaje zadeklarowana zmienna @AddedOn i otrzymuje bieżącą datę i czas poprzez funkcję SYSDATETIME. Wyrażenie INSERT wstawia nowy wiersz zawierający kombinację wartości dostarczonych jako parametry wejściowe i wyliczone w procedurze. Na koniec wyrażenie SELECT zwraca nową wartość klucza głównego przypisaną dla kolumny OrderId nowego wiersza, pobraną poprzez funkcję SCOPE_IDENTITY. Procedura składowana UpdateOrder wykonuje taką samą weryfikację przychodzącego parametru @Quantity w celu zagwarantowania, że ilość zamawiana w istniejącym zamówieniu nie zostanie zmieniona na zero lub liczbę ujemną. Następnie powtarzana jest ta sama logika wyliczenia @UnitPrice i @Price, jeśli dotychczasowa ilość zamówienia lub wybrany gatunek wina zostały zmienione. (Oczywiście, wspólny kod obliczania cen mógłby być umieszczony w oddzielnej funkcji zdefiniowanej przez użytkownika, do której odwoływałyby się obydwie procedury składowane InsertOrder
333
334
Rozdział 10: Budowanie rozwiązania w chmurze
i UpdateOrder). Następnie deklarowana jest zmienna @UpdatedOn i przypisywana jest jej bieżąca data i czas poprzez funkcję SYSDATETIME. Wyrażenie UPDATE modyfikuje wiersz. Zwróćmy uwagę, że kolumna AddedOn nie jest zmieniana przez wyrażenie UPDATE, co gwarantuje, że data i czas oryginalnego złożenia zamówienia zapisana w tej kolumnie nie zostanie zmieniona. W procedurze składowanej DeleteOrder wyliczana jest liczba dni, które upłynęły od wartości zapisanej w OrderDate i wynik umieszczany jest w zmiennej @DaysOld. Następnie sprawdzana jest funkcja @@ROWCOUNT w celu weryfikacji, że wskazane zamówienie rzeczywiście istnieje, po czym testowana jest zmienna @DaysOld, aby upewnić się, że data zamówienia wypada co najmniej rok (365 dni) wcześniej. Na koniec wykonywane jest wyrażenie DELETE, które usuwa wskazany wiersz z tabeli. DODatkOwe infOrmacje Istnieją także inne techniki poza procedurami składowanymi, które pozwalają ochronić tabele przed umieszczaniem nieprawidłowych danych. Na przykład moglibyśmy zdefiniować ograniczenie (check constraint) dla kolumny Quantity, aby zagwarantować, że nie pojawią się w niej liczby mniejsze lub równe zero, zamiast testowania tego warunku w procedurze. Można również utworzyć wyzwalacz (trigger) sprawdzający, że zamówienie ma co najmniej rok, zanim pozwolimy na jego usunięcie. Jednak w ogólności lepiej unikać stosowania wyzwalaczy, gdyż niekiedy mogą one prowadzić do niedeterministycznych zachowań. (Problem w tym, że jeśli dla tabeli zdefiniowanych jest wiele wyzwalaczy, nie można zagwarantować kolejności, w jakiej będą one wywoływane, co z kolei prowadzi do subtelnych bugów, które bardzo trudno diagnozować i eliminować). Stosowanie procedur składowanych zazwyczaj jest najlepszym podejściem, gdyż zapewniają czystą i zrozumiałą warstwę ponad tabelami, w której można skonsolidować całą wymaganą logikę ( jak wyliczanie cen i kontrolowanie wartości daty i czasu w naszym przykładzie).
W celu utworzenia tych procedur składowanych wykonaj poniższe kroki: 1 . W panelu Solution Explorer kliknij prawym klawiszem myszy folder dbo i wybierz Add | New Folder.
2 . Nazwij nowy folder Stored Procedures (procedury składowane) i naciśnij Enter. Uwaga Folder ten może już istnieć (utworzony automatycznie), podobnie jak folder Tables, jeśli w bazie danych istniała choć jedna procedura składowana w chwili, gdy zaimportowaliśmy ją do projektu.
3 . Prawym klawiszem myszy kliknij folder Stored Procedures i wybierz Add | Stored Procedure.
4 . Nazwij nowy plik InsertOrder.sql i kliknij Add.
Rozbudowywanie bazy danych
5 . Usuń szablon kodu wygenerowany przez Visual Studio i zastąp go kodem poka-
zanym wcześniej w Listingu 10-2. Ekran powinien wyglądać podobnie do pokazanego na rysunku 10-14.
Rysunek 10-14 Dodawanie nowej procedury składowanej do projektu SQL Server Database
6 . Prawym klawiszem myszy kliknij folder Stored Procedures i wybierz Add | Stored Procedure.
7 . Nazwij plik UpdateOrder.sql, kliknij Add i zastąp jego zawartość kodem pokaza-
nym wcześniej w Listingu 10-3. 8 . Prawym klawiszem myszy kliknij folder Stored Procedures i wybierz Add | Stored Procedure.
9 . Nazwij plik DeleteOrder.sql, kliknij Add i zastąp jego zawartość kodem pokaza-
nym wcześniej w Listingu 10-4. 10 . Kliknij menu FILE i wybierz polecenie Save All (albo naciśnij Ctrl+Shift+S).
Po dodaniu nowej tabeli i trzech procedur składowanych trzeba wprowadzić te zmiany z powrotem do bazy danych SQL Database w chmurze. Wykorzystamy do tego tę samą procedurę publikowania, którą posłużyliśmy się poprzednim razem. Jednak tym razem nie będziemy musieli wpisywać wszystkich danych połączenia, gdyż zapisaliśmy te informacje w profilu podczas poprzedniego wdrożenia.
335
336
Rozdział 10: Budowanie rozwiązania w chmurze
Aby ponownie wdrożyć projekt, wykonaj poniższe kroki: 1 . Prawym klawiszem myszy kliknij projekt WineCloudDb w panelu Solution Explorer
i wybierz polecenie Publish, aby wyświetlić okno dialogowe Publish Database (pokazane wcześniej na rysunku 10-10). 2 . Kliknij przycisk Load Profile (załaduj profil) w dolnej części okna. 3 . Podwójnie kliknij plik XML WineCloudDb.publish, aby załadować informacje połą-
czenia zapisane w trakcie poprzedniego wdrożenia. 4 . Kliknij przycisk Publish, aby rozpocząć wdrażanie.
Podobnie jak za pierwszym razem, Visual Studio wygeneruje i wykona skrypt zmian, który zaktualizuje bazę danych w chmurze tak, by dokładnie odpowiadała strukturze bazy danych w projekcie. Tym razem oznacza to, że baza danych WineCloudDb w chmurze zostanie uzupełniona o nową tabelę Order z jej relacjami obcego klucza do tabel Customer i Wine oraz o trzy nowe procedury składowane na potrzeby wstawiania, modyfikowania i usuwania wierszy z tabeli Order. Aby przekonać się, że baza danych WineCloudDb faktycznie zawiera teraz nowe obiekty, należy odświeżyć zawartość SQL Server Object Explorer. Zakończyliśmy projektowanie samej bazy danych i możemy przejść do pracy nad warstwą dostępu do danych naszego rozwiązania.
Tworzenie warstwy dostępu do danych (DAL) Warstwa dostępu do danych (data access layer – DAL) jest komponentem, który służy jako interfejs pomiędzy bazą danych stanowiącą zaplecze a resztą aplikacji. Mamy do dyspozycji wiele opcji konstruowania DAL; w kolejnych podrozdziałach zbudujemy ją przy użyciu platformy Entity Framework (EF). Platforma EF jest dziś postrzegana jako zalecana technologia firmy Microsoft dla implementacji warstwy dostępu do danych. EF, która została pierwotnie udostępniona jako część .NET 3.5 SP1 w roku 2008, podnosi poziom abstrakcji powyżej tego, który oferował mechanizm ADO.NET. Entity Framework jest mechanizmem mapowania relacyjnych obiektów (object relational mapper – ORM), którym można znacząco podnieść produktywność programisty w wielu scenariuszach, ale nie można uważać tej technologii za jedyny możliwy wybór, jeśli chodzi o tworzenie DAL. Platforma programistyczna Microsoft .NET Framework zawiera składnik ADO. NET udostępniający zbiór klas, których można użyć do budowy warstwy dostępu do danych. Począwszy od pierwszej wersji .NET opublikowanej w 2002 roku programiści mieli co najmniej dwa wybory sposobu pracy z ADO.NET. Jedną opcją było bezpośrednie użycie surowych obiektów ADO.NET, obejmujących połączenia, polecenia i czytniki (reader). Podejście takie wymaga sporo ręcznej pracy, gdyż konieczne jest jawne napisanie kodu wykonującego połączenie z bazą danych, wysyłać polecenia
Tworzenie warstwy dostępu do danych (DAL)
żądające danych, przesyłać pobrane dane z czytników do obiektów aplikacji, śledzić zmiany występujące w tych obiektach, po czym na koniec tworzyć polecenia w celu przesłania zmodyfikowanych obiektów ponownie do bazy danych. Choć nieco staroświecka i prymitywna, technika taka zdecydowanie nie może być uważana za przestarzałą. W istocie niezależnie od zapewnianej wygody i rosnącej popularności Entity Framework wnosi również znaczące dodatkowe obciążenie, które może prowadzić do obniżenia wydajności w wielkoskalowych scenariuszach, jeśli porównamy to z szybkością bezpośredniego dostępu do bazy danych poprzez surowe ADO.NET. Drugą opcją przy korzystaniu z ADO.NET jest użycie obiektów Dataset w połączeniu z adapterami danych. Visual Studio zawiera graficznego projektanta obiektów Dataset, który automatycznie generuje znaczącą część kodu. Wygenerowany kod konfiguruje połączenia i obiekty poleceń, a zarazem wykonuje mapowanie indywidualnych elementów danych (tabel i kolumn) pomiędzy bazą danych z jednej strony, a silnie typizowanym obiektem Dataset w pamięci. Po wypełnieniu Dataset potrafi śledzić swoje własne zmiany, dzięki czemu wysyłanie zaktualizowanych danych ponownie do bazy danych staje się stosunkowo łatwe. Podejście takie zapewnia warstwę abstrakcji, która uwalnia nas (czyli programistów) od znaczącej części pracy koniecznej do uzyskania tego samego efektu przy użyciu czystych klas ADO.NET. Trzeba jednak mieć na uwadze, że Dataset nie jest prawdziwym obiektem modelującym wymogi biznesowe (jednostką). Z tego względu obecnie nie spotkamy wielu sytuacji, w których lepsze byłoby użycie Dataset zamiast EF przy budowaniu DAL dla aplikacji .NET. Trzeba zwrócić uwagę, że dużo ważniejsze jest to, aby mieć właściwie zaimplementowaną DAL, niż to, w jaki sposób zechcemy ją zbudować. Bez wątpienia każdy przypadek jest inny, ale w wielu typowych zastosowaniach biznesowych (line-of-business – LOB) możemy się przekonać, że EF jest bardziej niż wystarczające do wykonania zadania. Wybranie EF znacząco upraszcza dostęp do danych, abstrahując leżące w tle obiekty połączeń z bazą danych, poleceń i czytników i udostępniając solidny zestaw obiektów usług, zdolnych do materializowania obiektów odczytywanych przez zapytania do bazy danych, śledzenie ich w pamięci i przekazywania zmian z powrotem do bazy danych. EF może też dynamicznie generować wyrażenia SELECT w celu odpytywania bazy danych oraz wyrażenia INSERT, UPDATE i DELETE, gdy trzeba ją zaktualizować. Wreszcie te same obiekty usług mogą równie dobrze wywoływać procedury składowane, dzięki czemu zachowujemy pełną kontrolę nad tym, jak zapytania i aktualizacje są przetwarzane. W EF dostępne są również bardziej zaawansowane możliwości mapowania obiektów, które znacząco wykraczają poza tematykę omawianą w tym rozdziale, takie jak zdolność do modelowania dziedziczenia, dzielenia jednostek, tabel lub relacje typu „wiele-do-wielu”.
337
338
Rozdział 10: Budowanie rozwiązania w chmurze
Wprowadzenie do Entity Data Model Sercem Entity Framework jest Entity Data Model (model jednostki danych, EDM), zaś Visual Studio udostępnia rozbudowane, graficzne narzędzie projektowania, które ułatwia zarządzanie i utrzymywanie EDM. W rozdziale 8, „Projektowanie i dostrajanie na potrzeby skalowalności i wysokiej wydajności” zbudowaliśmy prostą aplikację wykorzystującą podejście „najpierw kod”. Przy takim podejściu EDM jest obecny, ale niewidoczny. Zamiast tego podejście „najpierw kod” wywodzi EDM z klas jednostek wpisywanych przez nas w kodzie, jednak model EDM nadal jest obecny. W tym podrozdziale wykorzystamy podejście „najpierw baza danych”, aby utworzyć w Visual Studio plik .edmx na podstawie bazy danych WineCloudDb. W ten sposób poznamy narzędzie projektowania EDM w Visual Studio i poznamy sposoby dostosowywania modelu na wiele sposobów, a w szczególności zagadnienie mapowania procedur składowanych. EDM składa się z trzech części. Pierwszą jest schemat magazynowania (storage schema), opisujący fizyczną strukturę bazy danych. Drugi element to schemat koncepcyjny (conceptual schema), opisujący klasy dla jednostek biznesowych użytych w aplikacji. Na koniec mamy schemat mapowania (mapping schema), definiujący zależności pomiędzy schematem magazynowania a koncepcyjnym. Te trzy elementy (razem nazywane metadanymi modelu) są zawarte w pojedynczym pliku .edmx wewnątrz projektu. Po utworzeniu EDM nasze aplikacje i usługi same z siebie muszą uwzględniać tylko schemat koncepcyjny, podczas gdy EF dynamicznie obsługuje całość działań związanych z dostępem do danych w czasie wykonywania. Oznacza to, że gdy potrzebujemy pobrać dane do obiektów, EF automatycznie rozpoznaje to i wykonuje odpowiednie zapytania SELECT (lub procedury składowane) i wypełnia gotowe do użycia obiekty. Później, gdy przychodzi czas na zapisanie zmodyfikowanych obiektów, EF w podobny sposób tworzy i wykonuje odpowiednie wyrażenia T-SQL (INSERT, UPDATE i DELETE albo dostępne procedury składowane) konieczne do utrwalenia tych zmian w bazie danych. EF jest w stanie wykonać tę magię, gdyż wie, jak koncepcyjne jednostki biznesowe są mapowane na fizyczną strukturę bazy danych dzięki metadanym EDM. EDM, który utworzymy w kolejnym podrozdziale, definiuje proste mapowanie jeden do jednego pomiędzy schematem koncepcyjnym i magazynowym. Trzeba jednak mieć na uwadze, że możliwe są znacznie bardziej złożone mapowania. Przykładowo pojedyncza jednostka schematu koncepcyjnego może być mapowana na wiele tabel w bazie danych; w takiej sytuacji EF będzie złączać tabele razem przy wykonywaniu zapytań i rozdzielać aktualizacje pomiędzy różne tabele podczas zapisywania zmian. Możliwa jest też sytuacja przeciwna, gdy wiele typów jednostek jest mapowanych na jedną tabelę w bazie danych. W tym przypadku EF rozróżnia poszczególne wiersze w tabeli na podstawie wyznaczonej kolumny identyfikującej typ jednostki. Tego typu mapowanie może również zostać użyte do zdefiniowania dziedziczenia w schemacie koncepcyjnym.
Tworzenie warstwy dostępu do danych (DAL)
Tworzenie projektu Data Access Layer Na potrzeby szybkiego prototypowania typowe jest tworzenie EDM bezpośrednio wewnątrz aplikacji, która będzie z niego korzystać. Jednak w scenariuszach produkcyjnych właściwą praktyką jest umieszczenie pliku EDM w jego własnym projekcie biblioteki klasy (DLL), dzięki czemu może być łatwo współużytkowany przez wiele aplikacji. Wszystko, co musimy wówczas zrobić, to dodanie odwołania do asemblacji DLL zawierającej EDM i dołączenie odpowiednich łańcuchów połączenia z bazą danych do pliku konfiguracyjnego aplikacji (web.config albo app.config). W tym podrozdziale utworzymy EDM w jego własnym projekcie biblioteki klas, aby uzyskać łatwą do wykorzystania warstwę dostępu do danych (DAL). Następnie dodamy odwołanie do biblioteki klas DAL z oddzielnego projektu ASP.NET MVC. Jak wkrótce zobaczymy, skopiowanie łańcucha połączenia z pliku app.config biblioteki klas do pliku konfiguracyjnego web.config w projekcie MVC jest łatwe i zapewnia dostęp do bazy danych. DODatkOwe infOrmacje Inną często zalecaną praktyką jest implementacja wzorca repozytorium. Jest to inna warstwa, którą można dodać do naszego rozwiązania, bezpośrednio zarządzająca DAL, podczas gdy cała reszta aplikacji wchodzi w interakcję tylko z repozytorium. W ten sposób tylko warstwa repozytorium wie, że wykorzystujemy EF (lub cokolwiek innego) jako DAL, a w konsekwencji tylko tę warstwę trzeba modyfikować, jeśli kiedyś zdecydujemy się na zmianę rozwiązania z EF na surowe ADO.NET lub dowolną inną opcję DAL. Choć w naszym przykładzie nie będziemy implementować wzorca repozytorium, warto pamiętać, że dodanie tej warstwy pośredniej w produkcyjnej aplikacji pozwoli znacząco uprościć przełączanie pomiędzy różnymi opcjami DAL z minimalnymi zmianami pozostałych komponentów rozwiązania, jeśli kiedyś pojawi się taka potrzeba.
Aby utworzyć projekt biblioteki klas dla DAL, wykonaj poniższe działania: 1 . Prawym klawiszem myszy kliknij rozwiązanie WineSolution w panelu Solution Explorer i wybierz polecenie Add | New Project, aby wyświetlić okno dialogowe New Project.
2 . W lewej części okna dialogowego rozwiń węzeł Installed i wybierz Visual C#. 3 . Zaznacz szablon Class Library i nazwij projekt WineCloudModel. 4 . Kliknij OK, aby utworzyć projekt i dodać go do rozwiązania. 5 . Plik Class1.cs utworzony automatycznie przez Visual Studio można usunąć (nie
będzie nam potrzebny), zatem kliknij go prawym klawiszem myszy, wybierz Delete, po czym kliknij OK w monicie potwierdzenia. Możemy teraz przystąpić do tworzenia Entity Data Model w projekcie WineCloudModel.
339
340
Rozdział 10: Budowanie rozwiązania w chmurze
Tworzenie Entity Data Model Aby utworzyć Entity Data Model (EDM), wykonaj poniższe kroki: 1 . Prawym klawiszem myszy kliknij projekt WineCloudModel w panelu Solution Explorer i wybierz Add | New Item (dodaj nowy element).
2 . W lewej części okna dialogowego Add New Item rozwiń węzły Installed, Visual C#
i wybierz Data. 3 . Kliknij element ADO.NET Entity Data Model i nazwij plik WineModel.edmx, jak
na rysunku 10-15.
Rysunek 10-15 Tworzenie nowego Entity Data Model
4 . Kliknij Add, aby uruchomić kreator Entity Data Model Wizard. 5 . Na stronie Choose Model Contents (wybierz zawartość modelu) opcja Generate From Database (generuj z bazy danych) jest domyślnie zaznaczona, zatem po prostu kliknij Next.
6 . Na stronie Choose Your Data Connection (wybierz połączenie danych) kliknij przy-
cisk New Connection (nowe połączenie). 7 . Jeśli pojawi się okno dialogowe Choose Data Source (wybierz źródło danych), klik-
nij Microsoft SQL Server, a następnie Continue. 8 . W dobrze znanym oknie dialogowym Connection Properties wpisz informacje
potrzebne do połączenia z bazą danych WineCloudDb, używane już wcześniej w tym rozdziale: a . W polu Server Name wpisz pełną nazwę hosta serwera SQL Database (losowo
wybraną nazwę serwera uzupełnioną o database.windows.net). b . Wybierz Use SQL Server Authentication. c . Wpisz nazwę użytkownika i hasło przypisane wcześniej do serwera.
Tworzenie warstwy dostępu do danych (DAL)
d . Kliknij listę rozwijaną poniżej przycisku radiowego Select Or Enter A Database Name i zaznacz bazę WineCloudDb (o ile nie jest już domyślnie zaznaczona).
e . Kliknij OK, aby zamknąć okno dialogowe Connection Properties. 9 . Kliknij Yes, aby pozwolić na zawarcie poufnych danych (konkretnie chodzi
tu o hasło) w łańcuchu połącenia. Kreator Entity Data Model Wizard powinien teraz wyglądać podobnie do pokazanego na rysunku 10-16. ważne W aplikacji produkcyjnej niedopuszczalne byłoby umieszczenie hasła w łańcuchu połączenia (który jest przechowywany jako jawny tekst w pliku konfiguracyjnym aplikacji). Zamiast tego należałoby w tym miejscu wybrać No i przypisać hasło w kodzie C# podczas wykonywania aplikacji.
Rysunek 10-16 Definiowanie połączenia danych w kreatorze Entity Data Model Wizard
10 . Kliknij Next, aby wyświetlić stronę Choose Your Version (wybierz wersję). 11 . Pożądana wersja, czyli Entity Framework 6.0, powinna być wybrana domyślnie,
zatem kliknij Next, aby przejść do strony Choose Your Database Objects And Settings (wybierz obiekty bazy danych i ustawienia). 12 . Rozwiń węzły Tables, dbo, po czym zaznacz pola wyboru przy tabelach Customer,
Order i Wine (nie dołączaj do modelu tabeli _RefactorLog; ta tabela jest generowana automatycznie i jest używana tylko przez funkcje refaktoryzacji SQL Server Database Project).
341
342
Rozdział 10: Budowanie rozwiązania w chmurze
13 . Rozwiń węzły Stored Procedures and Functions, dbo i zaznacz pola wyboru przy
procedurach składowanych InsertOrder, UpdateOrder i DeleteOrder. 14 . Usuń zaznaczenie z ostatniego pola wyboru Import Selected Stored Procedures And Functions Into The Entity Data Model (importuj zaznaczone procedury składowane
i funkcje do modelu jednostek danych). Kreator powinien teraz wyglądać podobnie, jak na rysunku 10-17. DODatkOwe infOrmacje Ostatni krok nie jest niezbędny, ale pozwoli wyeliminować niepotrzebną nadmiarowość w EDM. Usunięcie tego zaznaczenia oznacza, że nie zamierzamy nigdy wywoływać procedur składowanych InsertOrder, UpdateOrder lub DeleteOrder bezpośrednio z EF, a tym samym nie ma potrzeby, aby kreator tworzył funkcje importujące i złożone typy (zasadniczo są to silnie typizowane opakowania dla wywołań procedur składowanych i zmian schematu zwracanych przez te wywołania). Zamiast tego wkrótce zamapujemy te procedury składowane do jednostki Order, dzięki czemu EF będzie je wywoływał automatycznie, gdy pojawi się potrzeba zapisania zmian w tabeli Order w bazie danych.
Rysunek 10-17 Wybieranie tabel i procedur składowanych, które mają zostać zaimportowane do Entity Data Model.
15 . Kliknij Finish.
Tworzenie warstwy dostępu do danych (DAL)
Uwaga Po kliknięciu Finish może pojawić się wiele komunikatów ostrzeżeń zabezpieczeń przed uruchomieniem szablonu (chodzi tu o specjalny szablon używany wewnętrznie przez projektanta EDM do automatycznego wygenerowania kodu). Jeśli pojawią się takie ostrzeżenia, należy po prostu kliknąć OK (można też zaznaczyć pole wyboru, wyłączające ponowne wyświetlanie tych ostrzeżeń).
Visual Studio doda niezbędne odwołania EF do projektu, wygeneruje Entity Data Model i wyświetli go w projektancie EDM, jak na rysunku 10-18.
Rysunek 10-18 Entity Data Model wyświetlony w projektancie EDM
Jednostki Wine, Customer i Order wyświetlone w projektancie EDM reprezentują klasy odpowiadające tabelom o tych samych nazwach, które zostały znalezione w bazie danych. Analogicznie każda z tych klas ma właściwości, które są mapowane na kolumny o tej samej nazwie w każdej tabeli. Co więcej, możemy zauważyć, że każda jednostka ma właściwości navigation i powiązania oparte na relacjach klucza obcego wykrytych dla tabel w bazie danych: ■
Jednostka Wine zawiera właściwości Customers i Orders (zwróćmy uwagę, że nazwy tych właściwości używają liczby mnogiej w języku angielskim). ❐ Przy tworzeniu tabel (Listing 10-1) ustanowiliśmy relację klucza obcego pomiędzy kolumną FavoriteWineId w tabeli Customer a kolumną WineId (klucza głównego) w tabeli Wine. Zdefiniowaliśmy tę kolumnę, aby pozwalała na wartości null, co oznacza, że niektórzy klienci mogą nie mieć ustawionej wartości ulubionego wina. Dlatego powiązanie pomiędzy jednostkami jest wyświetlone
343
344
Rozdział 10: Budowanie rozwiązania w chmurze
❐
graficznie w projektancie jako łącząca linia z napisem „0..1” widocznym po stronie Wine (co oznacza zero lub jedno ulubione wino) i symbolem gwiazdki (*) po stronie Customer (co oznacza wiele możliwych wyborów). Właściwość nawigacyjna Customers znajduje się po stronie „wiele” tej relacji, zatem wszyscy klienci, którzy mają ustawione konkretne wino, są dostępni poprzez właściwość nawigacyjną Customers jednostki Wine. Później utworzyliśmy relacje klucza obcego pomiędzy kolumną WineId w tabeli Order a kolumną klucza głównego WineId w tabeli Wine. W tym przypadku nie pozwoliliśmy na wartości null, co oznacza, że każdy wiersz w tabeli Order musi mieć wartość w kolumnie WineId, identyfikującą zamówione wino. Tak więc to powiązanie pomiędzy jednostkami jest wyświetlane graficznie jako linia łącząca, z liczbą „1” wyświetlaną po stronie Wine (co oznacza jedno i tylko jedno wino) i gwiazdką (*) po stronie Order. Właściwość nawigacyjna Orders znajduje się po stronie „wiele” tej relacji, zatem wszystkie zamówienia wybranego wina są dostępne za pośrednictwem właściwości Orders w jednostce Wine.
■
Jednostka Customer ma dwie właściwości nawigacyjne: Wine (liczba pojedyncza) i Orders (liczba mnoga). ❐ Właściwość Wine znajduje się po stronie „zero lub jeden” relacji z tabelą Customer, zatem ulubione wino klienta (o ile jest zdefiniowane) można odnaleźć poprzez właściwość nawigacyjną Wine jednostki Customer. ❐ Utworzyliśmy też relację klucza obcego pomiędzy kolumną CustomerId tabeli Customer (klucza głównego) a kolumną CustomerId w tabeli Order. Również w tym przypadku kolumna ta nie dopuszcza wartości null, co oznacza, że każdy wiersz w tabeli Order musi mieć wartość CustomerId, identyfikującą klienta, który złożył to zamówienie. Właściwość nawigacyjna Orders znajduje się po stronie „wiele” tej relacji, co oznacza, że wszystkie zamówienia danego klienta są dostępne poprzez właściwość nawigacyjną Orders jednostki Customer.
■
Jednostka Order zawiera dwie właściwości nawigacyjne Customer i Order (obydwie pojedyncze). ❐ Właściwość Customer jest po stronie „jeden” relacji z tabelą klientów, zatem można uzyskać dostęp do klienta składającego zamówienie poprzez właściwość Customer jednostki Order. ❐ Analogicznie właściwość Wine jest po stronie „jeden” relacji z tabelą win, dzięki czemu można odnaleźć wino wybrane w zamówieniu poprzez właściwość Wine jednostki Order.
Kreator Entity Data Model Wizard zaimportował zarówno tabele, jak i procedury składowane. Jednak w odróżnieniu do tabel, które kreator zamapował na tak samo nazwane jednostki w modelu koncepcyjnym, procedury składowane nie są mapowane automatycznie. Wykonanie tego zadania należy do nas. Trzy procedury składowane
Tworzenie warstwy dostępu do danych (DAL)
(InsertOrder, UpdateOrder i DeleteOrder) zamapujemy na jednostkę Order w modelu. Domyślnie (czyli jeśli tego nie zrobimy), EF wygenerowałby po prostu bezpośrednie wyrażenia T-SQL (INSERT, UPDATE i DELETE), aby zapisać zmiany wykonane w jednostce Order i nie mielibyśmy do dyspozycji dodanej funkcjonalności (takiej jak weryfikacja poprawności i wyliczanie cen), którą zaprogramowaliśmy w procedurach składowanych. Przypomnijmy, że InsertOrder zwraca jednowierszowy zbiór wynikowy z wartością OrderId przypisaną do nowego wiersza w tabeli Order (patrz wyrażenie SELECT na końcu Listingu 10-2). Gdy mapujemy tę procedurę składowaną do jednostki Order, musimy poinformować EDM, czym jest zwracana wartość, definiując wiązanie wyników (result bindings). Nakazuje to EF odświeżenie obiektów jednostki Order i „przepchnięcie” zwróconej wartości do właściwości OrderId instancji rezydującej w pamięci po wykonaniu wstawienia wiersza. Aby zamapować procedury składowane InsertOrder, UpdateOrder i DeleteOrder na tabelę Order, wykonaj poniższe kroki: 1 . Prawym klawiszem myszy kliknij jednostkę Order i wybierz polecenie Stored Procedure Mapping (mapowanie procedur składowanych). Pojawi się okno Mapping Details (szczegóły mapowania).
2 . W oknie Mapping Details kliknij
Recommend Documents
Microsoft Azure ExpressRouteMichael Washam
Summary: Microsoft Azure ExpressRoute makes it easy to establish dedicated and private circuits
between you...