• Artykuł

     gg512815(v=msdn.10).md

SQL Server 2008 R2 – Data Tier Application widziana oczami programisty oraz administratora, cz.1/2  ![Udostępnij na: Facebook](images/gg670867.udostepnij_fb(pl-pl,MSDN.10).png \\"Udostępnij na: Facebook\\")

Autor: Tomasz Wiśniewski, Damian Widera

Opublikowano: 2010-12-14

SQL Server 2008 R2 daje możliwość skorzystania z nowego podejścia do pracy z bazą danych. To podejście ma wpływ na pracę zarówno administratorów baz danych, jak i programistów. Programiści mogą tworzyć przy użyciu Visual Studio 2010 nowe projekty bazodanowe, a administratorzy  w łatwiejszy i dużo bardziej pewny sposób niż do tej pory wdrażać te projekty w środowisku SQL Server. W artykule prezentujemy dwa podejścia do Data Tier Application – w jaki sposób rozpocząć pracę z punktu widzenia programisty, a jak powinien zacząć pracę administrator.

Wprowadzenie do DTA

Aplikacja DTA jest komponentem zawierającym wszystkie obiekty bazy danych. Komponent ten może być przenoszony pomiędzy SQL Server 2008 R2 Enterprise Edition a Visual Studio 2010.

Fizycznie ten komponent składa się z czterech plików w formacie XML, które zawierają następujące informacje:

  • o logicznej strukturze bazy danych,
  • o fizycznej strukturze bazy danych,
  • o profilu komponentu,
  • o wersji komponentu.

W ramach struktury logicznej przechowywane są informacje m.in. o tabelach, widokach , procedurach składowanych, typach użytkownika czy funkcjach.

W ramach struktury fizycznej przechowywane są informacje o loginach,użytkownikach oraz definicjach indeksów.

Pliki te są osadzone w jednym pliku z rozszerzeniem dacpac. Interpretacja graficzna komponentu znajduje się na poniższym rysunku:

Rysunek 1, Komponent DTA.

Komponent DTA może być przenoszony pomiędzy serwerami i na nich odtwarzany – zainstalowana zostanie wtedy baza danych wraz ze wszystkimi obiektami zawartymi w opisanych powyżej plikach. W przypadku gdy istnieje na serwerze wcześniejsza wersja takiej bazy danych, to komponent dokona jej aktualizacji .

Cel stawiany aplikacjom DTA

Głównym założeniem wprowadzenia nowego typu komponentu było umożliwienie łatwiejszego tworzenia projektów bazodanowych. W pierwszej edycji komponentu DTA, która jest obecnie jedyną dostępną, należy zwrócić uwagę, że istnieją pewne ograniczenia zdefiniowane przez architektów tego rozwiązania, które mają wpływ na jego zastosowanie w rozwiązaniach produkcyjnych. Bazy danych, które mogą zostać skonwertowane na komponenty DTA powinny posiadać następującą charakterystykę:

  • rozmiar bazy danych powinien być nie większy niż kilka GB (maksymalnie do 10 GB). To ograniczenie nie jest ograniczeniem technologicznym, ale operacyjnym – większe rozmiary baz danych powodują dość duże opóźnienie podczas aktualizacji wersji takiej bazy;
  • baza danych nie powinna zawierać więcej niż 1000 obiektów;
  • bazy danych, które mogą zostać poddane konwersji na komponenty DTA, mogą pochodzić ze SQL Server 2000 lub późniejszych, ale ich odtworzenie będzie możliwe tylko na wersji SQL Server 2008 R2;
  • komponent DTA daje możliwość konwersji większości obiektów bazodanowych – ich pełna lista jest aktualizowana i znajduje się na stronie: https://msdn.microsoft.com/en-us/library/ee210549;
  • w przypadku gdy baza danych posiada wiele plików lub grup plików, to po jej odtworzeniu zostanie utworzony pojedynczy plik o domyślnej charakterystyce (jak przy tworzeniu nowej bazy danych).

Ze względu na powyższe ograniczenia stosowanie aplikacji DTA rekomendowane jest dla niedużych baz danych, tzw. modeli departamentowych.

Poniższy rysunek pokazuje zastosowanie aplikacji DTA w wersji V1.

Rysunek 2. Zastosowanie aplikacji DTA.

DTA od strony silnika baz danych

SQL Server Management Studio (SSMS) jest podstawowym narzędziem dla administratorów, którzy będą przygotowywać bazy danych jako komponenty DTA. Możliwe są różne scenariusze działania administratora:

  1. zarejestrowanie bazy danych jako komponentu (aplikacji) DTA,
  2. wyrejestrowanie bazy danych jako komponentu (aplikacji) DTA,
  3. odłączenie bazy danych,
  4. usunięcie bazy danych,
  5. aktualizacja bazy danych po jej wcześniejszej rejestracji jako aplikacja DTA,
  6. wygenerowanie pliku .dacpac,
  7. przesunięcie aplikacji DTA między instancjami SQL Server.

W każdym przypadku możliwych jest kilka alternatywnych ścieżek działania. Można wszystkie wymienione operacje wykonać za pomocą wygodnych graficznych wizardów, ale do dyspozycji są także skrypty Powershell oraz komendy T-SQL.

Poniżej przedstawiono wszystkie, wypunktowane metody przy użyciu graficznych kreatorów dostępnych w SSMS (w następnym artykule operacje te zostaną opisane przy użyciu komend Powershell).

· Wygenerowanie pliku .dacpac

Opcja wygenerowania pliku zawierającego aplikację DTA może być przeprowadzona zarówno przed, jak i po zarejestrowaniu bazy danych jako aplikacja DTA. W tym celu należy wybrać opcję Extract Data-tier Application z menu podręcznego bazy danych, jak pokazano na rysunku poniżej.

Rysunek 3. Opcja generowania pliku z menu bazy danych.

W kolejnych krokach graficzny kreator wspomaga omawiany proces.

Pierwszym z kroków jest zapisanie własności komponentu DTA, do których należą:

  • numer wersji komponentu – domyślnie jest to wartość 1.0.0.0,
  • nazwa aplikacji – domyślnie zgodnej z wybraną bazą danych,
  • opis – dodatkowy opis identyfikujący aplikację DTA,
  • ścieżka, pod którą plik .dacpac zostanie zapisany po pomyślnie przeprowadzonych walidacjach obiektów bazy danych.

Na poniższym rysunku przedstawiono widok własności komponentu DTA dla bazy danych Northwind.

Rysunek 4. Okno własności komponentu DTA dla wybranej bazy danych.

Zanim plik .dacpac zostanie wygenerowany, SQL Server przeprowadza szereg walidacji, aby mieć pewność, że wszystkie obiekty wybranej bazy danych mogą zostać skonwertowane. W przypadku bazy danych Northwind walidacja przebiega poprawnie (rysunek 5).

Rysunek 5. Walidacja bazy danych Northwind przed wygenerowaniem pliku .dacpac.

W przypadku bazy danych AdventureWorks2008 można znaleźć takie obiekty, które nie są wspierane w wersji V1, przez co nie jest możliwe wygenerowanie pliku .dacpac dla tej bazy danych (rysunek 6) do momentu poprawienia wszystkich niewspieranych obiektów.

Rysunek 6. Walidacja bazy danych AdventureWorks2008 przed wygenerowaniem pliku .dacpac.

W przypadku pomyślnie przeprowadzonej walidacji plik .dacpac zostaje zapisany w miejsce wskazane w pierwszym kroku kreatora.

Zawartość pliku .dacpac została już wcześniej omówiona w tym artykule, ale warto zwrócić uwagę, że można przejrzeć i przeanalizować jego zawartość samodzielnie (jak pokazano na rysunku 8).

Rysunek 7. Zawartość pliku .dacpac dla bazy danych Northwind.

Rysunek 8. Przykładowa procedura składowana zapisana w pliku .dacpac w formacie XML.

·  Zarejestrowanie bazy danych jako komponentu DTA

Drugim scenariuszem, który może wykonać administrator serwera baz danych, jest zarejestrowanie bazy danych jako aplikacji DTA. Ten scenariusz jest podobny do omówionego powyżej scenariusza wygenerowania pliku .dacpac. W celu zarejestrowania bazy danych jako komponetu DTA należy z menu podręcznego bazy danych (pokazanego na rysunku 3) wybrać opcję Register as Data-tier Application i postępować w sposób omówiony w punkcie powyżej.

Zauważalna różnica w procesie rejestracji jest na samym jego końcu, kiedy zamiast budowania pliku .dacpac odbywa się rejestracja bazy danych. Technicznie ten proces wygląda w taki sposób, że plik .dacpac zostaje wygenerowany „w  locie”, a następnie na jego podstawie baza jest rejestrowana w SQL Server:

Rysunek 9. Proces rejestrowania bazy danych Northwind jako aplikacji DTA w SQL Server.

Po zarejestrowaniu bazy danych informacja ta jest dostępna w SSMS w węźle Management, Data-tier Applications, jak pokazano na rysunku 10:

Rysunek 10. Informacja o zarejestrowanych bazach danych w SSMS.

Informacja o pomyślnie zakończonym procesie rejestracji zapisana zostaje w bazie danych msdb. Informacje o wszystkich zarejestrowanych w ten sposób bazach danych można uzyskać z dynamicznego widoku sysdac_instances:

Rysunek 11. Widok sysdac_instances zawierający informacje o wszystkich zarejestrowanych jako komponenty DTA bazach danych.

Wszystkie operacje wykonywane na aplikacji DTA są odnotowywane w tabeli sysdac_history_internal w bazie danych msdb.

Rysunek 12. Informacje uzyskane z tabeli sysdac_history_internal.

·  Operacje usuwania DTA

SQL Server daje możliwość usuwania aplikacji DTA (a więc bazy danych również) na kilka sposobów:

  • Wyrejestrowananie bazy danych jako aplikacji DTA, co skutkuje usunięciem wpisów o tej bazie danych z odpowiednich tabel w bazie msdb. Baza danych staje się taką bazą, jaką była przed konwersją na aplikację DTA.
  • Odłączenie bazy danych, co równa się jej usunięciu z bieżącej instancji SQL Server. Pliki bazy danych pozostają w systemie i mogą posłużyć do ponownego podłączenia takiej bazy danych lub jej odtworzenia na innym serwerze.
  • Usunięcie bazy danych, co jest równoznaczne z jej odłączeniem i skasowaniem plików w systemie.

· Aktualizacja bazy danych z pliku .dacpac

Plik .dacpac zawierający definicję obiektów bazy danych może być przesłany do deweloperów, którzy mogą go modyfikować w zależności od potrzeb biznesowych aplikacji. Po dokonaiu wszystkich zmian generowana jest automatycznie nowa wersja  pliku ze zmienionym numerem wersji. Po dostarczeniu pliku na serwer baz danych administrator może dokonać aktualizacji bazy danych, wybierając odpowiednią opcję z menu:

Rysunek 13. Aktualizacja bazy danych z pliku .dacpac.

Graficzny kreator wymaga wskazania lokalizacji pliku .dacpac, a nastepnie przeprowadzana jest operacja porównania obiektów bazodanowych.

Rysunek 14. Operacja porównywania obiektów bazy danych z obiektami pliku .dacpac.

Po wykonanym porównaniu można zapoznać się z podsumowaniem prezentowanym w kolejnym kroku. Jest to tylko krok informacyjny, ale jeśli w trakcie poprzedniej operacji nastąpiłby błąd, to system nie pozwoliłby na przejście do aktualizowania bazy danych.

Rysunek 15. Podsumowanie porównania obiektów.

Proces aktualizacji bazy danych składa się z wielu kroków, które zostały pokazane na rysunku 16. Warto prześledzić wszystkie akcje  wykonywane w trakcie aktualizacji bazy danych, ponieważ sposób jej przeprowadzenia odpowiada na pytanie – dlaczego można wersję V1 aplikacji DTA używać do rozwiązań departamentowych. Kluczem do odpowiedzi jest istnienie co najmniej dwóch baz danych po przeprowadzonej aktualizacji, jak to zostało pokazane na rysunku 17.

Rysunek 16. Proces aktualizacji bazy danych z pliku .dacpac.

Po przeprowadzonym procesie aktualizacji aplikacji w instacji SQL Server znajdować się będą dwie bazy danych Northwind (rysunek 17):

  • aktualna, która powstała w wyniku aktualizacji z pliku .dacpac,
  • wersja poprzednia bazy danych (Northwind_1_0_0_0__129318509284120864), która powstała po aktualizacji bazy danych.

Rysunek 17. Baza danych Northwind po aktualizacji z pliku .dacpac.

     gg512815(v=msdn.10).md