• Artykuł

Microsoft SQL Server 2008

SQL Server 2008 – Declarative Management Framework krok po kroku Udostępnij na: Facebook

Autor: Damian Widera

Opublikowano: 3 stycznia 2008

Zawartość strony
Wstęp   Wstęp
Podstawowe informacje o Declarative Management Framework.   Podstawowe informacje o Declarative Management Framework.
Praca z Declarative Management Framework   Praca z Declarative Management Framework
Declarative Management Framework w ujęciu programowym   Declarative Management Framework w ujęciu programowym
Podsumowanie   Podsumowanie

Wstęp

Declarative Management Framework (DMF) jest z całą pewnością jedną z najważniejszych nowości, która została wprowadzona do SQL Server 2008. DMF pozwala na zarządzanie instancjami SQL Server poprzez definiowanie polis (policies). Po raz pierwszy można było zapoznać się z nową funkcjonalnością przy okazji pierwszego, czerwcowego CTP (informacja o DMF pojawiła się na stronach TechNet w artykule Marcina Guzowskiego - „Co nowego w silniku bazodanowym SQL Server 2008 June CTP”). Dodatkowo, na stronach TechNet znajduje się webcast, autorstwa Pawła Potasińskiego, w którym pokazano, jak rozpocząć pracę z DMF.

Ostatni publiczny CTP z listopada przyniósł długo oczekiwane i niezwykle istotne z punktu widzenia administratora baz danych nowości i z tego powodu warto się tematowi Declarative Management Framework przyjrzeć z bliska.

 Do początku strony Do początku strony

Podstawowe informacje o Declarative Management Framework.

Declarative Management Framework (DMF) jest systemem opartym na politykach służącym do zarządzania instancjami SQL Server 2008. Administratorzy baz danych mogą używać DMF za pomocą SQL Server Management Studio (SSMS) i za jego pomocą tworzyć polisy oraz zarządzać serwerem, bazami danych, tabelami, indeksami lub innymi obiektami zawartymi w SQL Server. DMF składa się z trzech komponentów:

  1. Zarządzania polisami – administratorzy polis tworzą polisy;

  2. Bezpośredniej administracji – administrator wybiera jeden lub więcej obiektów, które muszą być zgodne z utworzoną polisą;

  3. Zautomatyzowanej administracji – administrator polisy umożliwia automatyczne wykonanie polisy w jednym z trzech trybów:

    1. Tryb on change, w którym następuje sprawdzenie zgodności obiektu z polisą w sytuacji, w której zmienia się stan obiektu. Dostępne są dwie opcje dla tego trybu działania polisy:

      1. Prevent – zmiany, które spowodowały naruszenie zasad określonych w polisie, zostaną odrzucone,
      2. Log - zmiany, które spowodowały naruszenie zasad określonych w polisie, nie zostaną odrzucone. Zamiast tego zostanie utworzony raport zawierający opis problemu.

  4. Tryb on schedule, w którym następuje okresowe sprawdzenie polisy przy udziale SQL Server Agent. Obiekty, które nie spełniają zasad określonych w polisach, zostaną oznaczone w raporcie podsumowującym wykonanie sprawdzenia.

  5. Tryb on demand, w którym polisa jest sprawdzana przez użytkownika za pomocą opcji Test polisy z menu kontekstowego (rys . 2.) . Obiekty, które nie spełniają zasad określonych w polisach, zostaną oznaczone w raporcie podsumowującym wykonanie sprawdzenia.

Dla zrozumienia działania DMF należy poznać jej podstawowe składniki. System Declarative Management Framework ma strukturę hierarchiczną i składa się z trzech podstawowych elementów:

Dla zrozumienia działania DMF należy poznać jej podstawowe składniki. System Declarative Management Framework ma strukturę hierarchiczną i składa się z trzech podstawowych elementów:

  1. DMF management facets – jest to zestaw reguł modelujących zachowanie lub charakterystykę określonego obiektu. Liczba i charakterystyka własności jest wbudowana w każdą regułę i może być zmieniona (dodana, usunięta) tylko przez twórcę reguły. Każda polisa może wykorzystywać jedną lub więcej reguł.
  2. DMF conditions – są to warunki określające zestaw dozwolonych stanów, w których może znaleźć się obiekt kontrolowany przez polisę. Dozwolone stany dla każdego obiektu są określane przez omówione powyżej zestawy reguł i charakterystyk (facets).
  3. DMF policies – polisy składają się z warunków, które wymuszają określone zachowanie obiektu. Polisa może zawierać tylko jeden warunek oraz być włączona (enabled) bądź wyłączona (disabled).

Rys. 1. SQL Server Management Studio wraz z systemem DMF.

Każda polisa zawiera dokładnie jeden warunek, a ten z kolei może składać się z co najmniej jednego zestawu reguł (facets), o ile dotyczą one jednego obiektu. Każda polisa może zostać sprawdzona okresowo (tryb on schedule). Tryb sprawdzania polisy on change może nastąpić, gdy zmiana stanu reguł i własności obiektu zostanie przechwycona przez odpowiednie zdarzenie. Z kolei tryb on demand pozwala sprawdzić stan obiektu z określoną polisą na żądanie użytkownika. Opcja ta (Test policy) jest dostępna z menu kontekstowego dla każdej z polis.

Rys. 2. Menu kontekstowe umożliwiające zarządzanie polisą.

W tym momencie należy zaznaczyć, iż dla ułatwienia zarządzania polisami każda z nich należy do dokładnie jednej kategorii. SQL Server 2008 CTP5 został dostarczony z ośmioma predefiniowanymi kategoriami, ale administrator może dodać do systemu swoje grupy. Dokładniejszy spis kategorii znajduje się w dalszej części artykułu.

Polisy przechowywane są w systemowej bazie danych msdb. Firma Microsoft zaleca, aby po każdej zmianie polisy lub warunków wykonać kopię zapasową bazy danych msdb.

Na zakończenie omawiania podstawowych informacji o DMF należy wspomnieć o mechanizmach bezpieczeństwa (security) związanych z DMF. Administrowanie systemem DMF wymaga, aby użytkownik należał do bazodanowej roli PolicyAdministrationRole w bazie msdb. Ta rola umożliwia pełną kontrolę nad systemem polis, to znaczy umożliwia tworzenie, edytowanie, usuwanie polis oraz warunków, a także włączanie i wyłączanie polis.

Należy pamiętać, iż użytkownicy posiadający tak rozległe uprawnienia mogą utworzyć wyzwalacz na poziomie serwera i zaplanować cykliczne wykonanie sprawdzenia zgodności obiektów z polisami, co z kolei może wpłynąć negatywnie na operacje wykonywane w silniku bazodanowym. Zgodnie z Books Online dla DMF obowiązują następujące reguły bezpieczeństwa:

Dla zrozumienia działania DMF należy poznać jej podstawowe składniki. System Declarative Management Framework ma strukturę hierarchiczną i składa się z trzech podstawowych elementów:

  1. DMF management facets – jest to zestaw reguł modelujących zachowanie lub charakterystykę określonego obiektu. Liczba i charakterystyka własności jest wbudowana w każdą regułę i może być zmieniona (dodana, usunięta) tylko przez twórcę reguły. Każda polisa może wykorzystywać jedną lub więcej reguł.
  2. DMF conditions – są to warunki określające zestaw dozwolonych stanów, w których może znaleźć się obiekt kontrolowany przez polisę. Dozwolone stany dla każdego obiektu są określane przez omówione powyżej zestawy reguł i charakterystyk (facets).
  3. DMF policies – polisy składają się z warunków, które wymuszają określone zachowanie obiektu. Polisa może zawierać tylko jeden warunek oraz być włączona (enabled) bądź wyłączona (disabled).

 Do początku strony Do początku strony

Praca z Declarative Management Framework

SQL Server 2008 CTP 5 zawiera predefiniowane zestawy reguł, warunki oraz polisy zgodne z najlepszymi rekomendacjami firmy Microsoft z zakresu administracji bazami danych. Do dyspozycji administratora baz danych zostało zdefiniowanych:

  1. 38 zestawów reguł (facets),
  2. 69 warunków,
  3. 47 polis – domyślnie wyłączonych.

Po przeczytaniu niniejszego artykułu analiza dostarczonych zestawów reguł, warunków oraz polis będzie łatwiejsza. Poza tym, ze względu na ilość zawartych obiektów, nie ma możliwości przeanalizowania w sposób szczegółowy każdego z nich w ramach tego artykułu. Zamiast tego w artykule pokazane zostaną sposoby na tworzenie polisy od podstaw oraz możliwości programowego odnajdywania informacji o DMF za pomocą odpytywania istniejących widoków systemowych (w dalszej części artykułu).

Istniejące zestawy reguł (facets) pokrywają w zasadzie wszystkie dostępne w instancji serwera obiekty. Użytkownik znajdzie tam m.in. takie obiekty, jak Server, Database, Table,View, Index, Stored Procedure, User, Login itd. oraz obiekty zawierające bardziej szczegółowe własności, np.: Database DDL Trigger, Database Maintenance, Database Options, Database Performance, Database Role oraz Database Security.

Zestaw reguł i charakterystyk opisujący obiekt może zostać odczytany w oknie Facet Properties dla wybranego obiektu. Okno zawiera trzy zakładki, które logicznie grupują informacje o wybranym obiekcie.

Zakładka General zawiera informacje o dostępnych własnościach obiektu (patrz rys. 3.), opis obiektu oraz informację, do jakiego typu obiektu odnoszą się omawiane własności – w omawianym przykładzie Server Security facet dotyczy obiektu Server.

Rys. 3. Własności obiektu Server Security.

Zakładka Dependent Policies (patrz rys. 4.) informuje o istniejących (o ile takowe są) polisach wykorzystujących wybrany obiekt. Dla każdej odnalezionej polisy wyświetlane są także najistotniejsze informacje, tj. jej nazwa, status – czy polisa jest włączona (aktywna), czy wyłączona, datę jej utworzenia oraz link View history, który umożliwia szybkie odnalezienie informacji historycznych dotyczących sprawdzenia zgodności polisy z obiektem, którego ta polisa dotyczy.

Rys. 4. Polisy zależne od obiektu Server Security.

Ostatnia zakładka (patrz rys. 5.) – Dependent Conditions – wyświetla informacje o warunkach, które zostały utworzone i wykorzystują wybrany zestaw reguł (facet).

Rys. 5. Warunki zależne od obiektu Server Security.

Obiektem stojącym w hierarchii systemu DMF powyżej facet są warunki. Każdy warunek może składać się z co najwyżej jednego zestawu reguł, to znaczy może dotyczyć tylko jednego obiektu. Niedozwolone jest tworzenie warunków złożonych, które wykorzystują informacje zawarte z np. dwóch różnych zestawów reguł.

Jak wspomniałem powyżej, trudne byłoby omawianie wszystkich istniejących warunków dostarczonych z SQL Server 2008 CTP 5. Zamiast tego zostanie utworzony nowy warunek, który w dalszej części będzie podstawą do zdefiniowania nowej polisy. Warunek ten będzie dotyczył zestawu reguł opisujących wyzwalacze (Trigger), a jego zadaniem będzie zapewnienie, iż wyzwalacze są niedostępne w bazie danych Northwind, tzn. nie można będzie ich tworzyć na tabelach tej bazy danych, ale w innych bazach danych (pubs, AdventureWorks) będzie to możliwe. Utworzenie warunku jest bardzo proste i polega na zaznaczeniu zestawu reguł i z menu kontekstowego wybraniu opcji New condition (rys. 6.).

Rys. 6. Tworzenie nowego warunku dla wybranego zestawu reguł dla obiektu Trigger.

W oknie Create New Condition należy wprowadzić wszystkie wymagane informacje potrzebne do utworzenia warunku. Pierwszą z nich jest podanie jego nazwy a następnie należy wybrać własność, która zostanie skonfigurowana (z pola Expression). W naszym przykładzie, jak pokazano na rys. 7., należy wybrać własność @IsEnabled.

Rys. 7. Tworzenie nowego warunku - wybór własności.

Następnym krokiem jest wybranie odpowiedniego operatora z listy w polu Operator. Dla własności @IsEnabled dostępne są tylko dwa operatory: = oraz ! = , ale dla innych własności, takich jak @Name można wybrać inne, znane z klauzuli WHERE – takie, jak LIKE, NOT LIKE, IN, NOT IN, >, <, >= itd.

Następnie należy wybrać odpowiednią wartość z listy Value, która dla operatora @IsEnabled zawiera dwie pozycje – true i false. W naszym przykładzie należy wybrać wartość false, ponieważ wyzwalacze mają być niedostępne.

Dla innego typu własności, jak np. własność @Name, której wartość może być z punktu widzenia systemu dowolna, należy wprowadzić ją samodzielnie, stosując dokładnie te same kryteria, jakie obowiązują dla klauzuli WHERE (zobacz webcast Pawła Potasińskiego).

W wielu przypadkach (innych niż wybór wartości pomiędzy true i false) system DMF tworzy odpowiednie słowniki, umożliwiając wybór odpowiedniej wartości z listy, co zapobiega wielu niezamierzonym błędom (literowym – patrz rys. 8. wykonany dla warunku obiektu Server Security) .

Rys. 8. Wybór wartości dla własności LoginMode obiektu Server Security.

Każdy warunek może składać się z więcej niż jednej reguły dla wybranego obiektu. Można wskazywać kolejne własności oraz relacje pomiędzy nimi – OR lub AND. Na rys. 9. pokazano szczegóły zdefiniowanego warunku User or Model , który sprawdza czy baza danych jest bazą danych użytkownika lub systemową bazą danych model i jest w trybie Online. Warunek ten logicznie można zapisać za pomocą pseudokodu w następującej postaci:

(IsUserDatabase OR IsModelDatabase) AND IsOnline

Warunek ten został skonstruowany w DMF w następujący sposób:

Rys. 9. Konstruowanie warunku złożonego z wielu własności tego samego zestawu reguł.

Wracając do naszego przykładu - tak skonstruowany warunek (z rys. 7.) należy zatwierdzić klikając przycisk OK.

Dodatkowo należy wykonać jeszcze jeden warunek, który sprawdzi, czy nazwa bazy danych to Northwind (rys. 10).

Rys. 10. Warunek sprawdzający, czy nazwa bazy danych to Nortwhind.

Lista warunków dostępnych w systemie DMF zostanie automatycznie odświeżona i utworzone na potrzeby przykładu, nowe warunki są na niej natychmiast dostępne (rys. 11.).

Rys. 11. Lista warunków systemu DMF z nowoutworzonymi warunkami.

Po utworzeniu warunków można przystąpić do skonstruowania polisy. Z menu kontekstowego na węźle Policies należy wybrać opcję New policy i w nowym oknie właściwości należy wprowadzić wszystkie wymagane informacje (patrz rys. 12.). Po pierwsze należy nazwać polisę i wskazać warunek, który będzie sprawdzany. W naszym przypadku jest to warunek Wyzwalacze (triggers są niedozwolone domyślnie) z zestawu reguł Triggers.

Rys. 12. Tworzenie nowej polisy.

Po wybraniu warunku odświeża się lista obiektów, względem których polisa będzie sprawdzana (rys. 13.). Oczywistym jest, iż w przypadku wyzwalaczy lista będzie zawierała tablice i widoki. Skonfigurować można natomiast, w jakich tablicach i widokach oraz w ramach jakich baz danych odbędzie się wykonywanie polisy. W założeniu do naszego przykładu określiłem, iż wyzwalacze będą niedozwolone w bazie danych Northwind i taki warunek należy wybrać z listy dla warunków Database.

Rys. 13. Lista obiektów do sprawdzenia w ramach tworzonej polisy.

Kolejną informacją, którą należy wskazać jest sposób, w jaki polisa będzie sprawdzana. W tym przypadku możliwe są dwa z czterech omówionych wcześniej trybów:

  1. On demand – tryb na żądanie – w takim przypadku nie trzeba zaznaczać pola enabled przy tworzeniu polisy,
  2. On schedule – okresowo – należy wtedy wskazać oraz zaznaczyć pole enabled.

Następną informacją, którą należy wypełnić na zakładce General jest pole server restriction (rys. 14.). Służy ono do określenia czy na serwer, na którym polisa ma zostać uruchomiona, zostają nałożone dodatkowe warunki. W naszym przykładzie założyłem, iż serwer baz danych dla tej polisy musi to być SQL Server 2005 z zainstalowanym dodatkiem SP1 lub nowszym. Dostępne są także inne predefiniowane warunki (np. dotyczące architektury serwera, które sprawdzą, czy mamy architekturę 32- czy 64- bitową i uzależnią wykonanie polisy od założonego warunku), można także zdefiniować własne warunki.

Rys. 14. Określenie warunków stawianych serwerowi dla tworzonej polisy.

Ostatnią informacją, którą należy wskazać przed utworzeniem polisy to kategoria, do której polisa będzie należeć. Kategoryzacja polis znacznie ułatwia zarządzanie systemem DMF, łatwiej także polisy odszukać programowo (o czym w dalszej części artykułu). SQL Server 2008 CTP5 definiuje 8 kategorii polis, zgodnych z najlepszymi praktykami firmy Microsoft:

  1. Database Engine Audit
  2. Database Engine Configuration
  3. Database Engine Performance
  4. Database Engine Security
  5. Database Maintenance
  6. Database Performance
  7. Database Security
  8. Windows Log File Analysis

do których klasyfikuje wszystkie predefiniowane polisy. Administrator baz danych może utworzyć nowe kategorie spełniające np. założenia polityki firmy w zakresie administracji instancjami SQL Server. Tworzenie kategorii jest bardzo proste i sprowadza się do kliknięcia na przycisk New i podania nazwy kategorii.

Rys. 15. Przyporządkowanie polisy do określonej kategorii.

W naszym przykładzie zdefiniowałem nową kategorię, którą nazwałem Kategoria testowa i zapisałem polisę w bazie danych.

System, podobnie jak w przypadku warunków, automatycznie odświeżył listę dostępnych polis (rys. 16.).

Rys. 16. Lista polis wraz z nową, zdefiniowana polisą.

Od tej chwili polisa jest gotowa. Należy pamiętać, iż utworzona w przykładzie polisa jest wykonywana na żądanie i domyślnie nie jest aktywną.

Dla przetestowania działania polisy należy utworzyć co najmniej dwa wyzwalacze – jeden w bazie danych innej niż Northwind i ten wyzwalacz nie będzie sprawdzany w ramach utworzonej polisy. Drugi trigger należy utworzyć na tablicy lub widoku w bazie danych Northwind. Poniżej znajduje się najprostszy kod spełniający te wymagania.

--wyzwalacz w bazie danych pubs, w tablicy dbo.jobs

--ten będzie dozwolony przez polisę

USE pubs

GO



CREATE TRIGGER dbo.jobs_Test_UPDATE 

   ON  dbo.jobs 

   AFTER UPDATE

AS 

BEGIN

        SELECT * FROM inserted

END

GO

--wyzwalacz w bazie danych Northiwnd, w tablicy dbo.Orders

--ten będzie powodował naruszenie naszej polisy

USE Northwind

GO



CREATE TRIGGER dbo.Orders_TestTrigger_UPDATE 

   ON  dbo.Orders

   AFTER UPDATE

AS 

BEGIN

        SELECT * FROM inserted

END

GO

Test działania polisy można wykonać za pomocą opcji Test Policy z menu kontekstowego, które jest dostępne po zaznaczeniu polisy, jak to zostało pokazane na rys. 2. Po wykonaniu testu administrator otrzymuje krótkie podsumowanie, które zawiera najistotniejsze informacje (jak to pokazano na rys. 17.):

  1. Czy wykonanie sprawdzenia polisy z obiektem, którego polisa dotyczy zakończyło się sukcesem,
  2. Nazwę instancji serwera, na której został przeprowadzony test,
  3. Ścieżkę w formacie XPath, która pozwala na szybkie zidentyfikowanie obiektu, względem którego nastąpiło sprawdzenie zgodności z polisą,
  4. Datę wykonania sprawdzenia,
  5. Link do informacji szczegółowej.

Rys. 17. Wynik działania polisy.

Zwróćmy uwagę, iż sprawdzenie polisy nastąpiło tylko z obiektem w bazie danych Northwind, nie były sprawdzane wyzwalacze w bazie danych pubs.

Z punktu widzenia administratora baz danych najistotniejszą informacją jest ta, która natychmiast wskaże odpowiedź na pytanie, dlaczego określony obiekt spowodował naruszenie warunków zawartych w polisie. Do tego celu służy wspomniany już link View details, za pomocą którego można otworzyć nowe okno pokazujące, które warunki spowodowały naruszenie polisy. Na rys. 18. pokazano, iż polisa oczekiwała, że warunek @IsEnabled będzie miał wartość false, natomiast rzeczywista, aktualna wartość tego warunku miała wartość true, co było przyczyną powstania błędu.

Rys. 18. Szczegóły wykonania sprawdzenia polisy z obiektem - wskazanie wykrytych nieprawidłowości.

System DMF nie tylko wykrywa, które warunki spowodowały naruszenie zasad zawartych w polisie oraz którego obiektu to sprawdzenie dotyczyło. System DMF jest w stanie również skonfigurować obiekt tak, aby był zgodny z polisą. Wystarczy w oknie podsumowania uruchomienia polisy wybrać przycisk Configure, aby odpowiednio skonfigurować obiekt. Ponowne uruchomienie sprawdzenia polisy nie znajduje już błędów (patrz na rys. 19.).

Rys. 19. Automatyczne konfigurowanie obiektów tak, aby spełniały warunki zawarte w polisach.

Na rysunku 20. pokazano, iż system DMF rzeczywiście wyłączył wyzwalacz w bazie danych Northwind, a pozwolił na jego użycie w innej bazie danych, w tym wypadku w bazie danych pubs.

Rys. 20. Skonfigurowane wyzwalacze jako wynik działania testowej polisy.

Dla porządku należy przypomnieć, iż użytkownik bez odpowiednich uprawnień nie będzie mógł utworzyć, modyfikować, uruchamiać oraz usuwać polis. Każdorazowa próba wykonania operacji, do której użytkownik nie ma uprawnień w systemie DMF zakończy się wyświetleniem informacji o błędzie, podobnej do tej na rys. 21.

Rys. 21. Próba uruchomienia polisy przez użytkownika bez wymaganych uprawnień do tej operacji.

Należy wspomnieć jeszcze o kolejnej możliwości, którą oferuje Declarative Management Framework, a o której już wspomniałem w tym artykule – a mianowicie o zarządzaniu kategoriami polis. Dla węzła Policy Mangement należy z menu kontekstowego wybrać opcję Manage Categories i w nowym oknie zostanie wyświetlona lista dostępnych kategorii (rys. 22.).

Rys. 22. Zarządzanie kategoriami polis.

W przypadku, gdy pole Mandate Database Subscription jest odznaczone to polisy zawarte w tej kategorii muszą być indywidualnie subskrybowane do odpowiednich obiektów serwera baz danych. I tak, gdyby wyłączyć Kategorię testową, to dla każdej bazy danych użytkownik z odpowiednimi uprawnieniami może indywidualnie tę kategorię włączyć co spowoduje, iż polisy będą dotyczyły obiektów serwera, który je subskrybuje (o ile nie zostały wykluczone warunkami). Operacja subskrybowania kategorii jest dostępna z menu kontekstowego, jak pokazano na rys. 23.

Rys. 23. Menu kontekstowe umożliwiające subskrybowanie kategorii polis.

W oknie kategorii należy zaznaczyć kategorię (rys. 24), która ma zostać subskrybowana. Istotne jest, iż nie można wyłączyć żadnej innej kategorii, która została uznana jako obowiązkowa (mandatory) .

Rys. 24. Subskrybowanie bazy danych do odpowiedniej kategorii polis.

Na zakończenie tego rozdziału należy wspomnieć o jeszcze jednej, niezwykle istotnej i przyjaznej administratorowi baz danych funkcjonalności, która została zawarta w systemie DMF. Tą funkcjonalnością jest możliwość wyeksportowania utworzonej polisy do pliku XML i zaimportowania na innej instancji SQL Server 2008 bez konieczności ponownego jej tworzenia. Eksportowanie polisy odbywa się poprzez wybór opcji Export policy z menu kontekstowego dostępnego dla każdej polisy. Importowanie polisy do systemu DMF jest również bardzo proste – należy zaznaczyć węzeł Policies i z menu kontekstowego wybrać opcję Import Policy (rys. 25.).

Rys. 25. Import polisy z pliku.

 Do początku strony Do początku strony

Declarative Management Framework w ujęciu programowym

Systemem DMF oferuje administratorom baz danych możliwość programowego nadzoru nad polisami. Do dyspozycji użytkownika jest 9 widoków systemowych:

1. syspolicy_conditions

2. syspolicy_policies

3. syspolicy_policy_execution_history

4. syspolicy_policy_execution_history_details

5. syspolicy_policy_categories

6. syspolicy_policy_category_subscriptions

7. syspolicy_system_health_state

8 syspolicy_target_set_levels

9. syspolicy_target_sets

Poniżej zostaną omówione widoki z punktów 1-4 ze względu na ciekawe informacje, które zostały w nich zawarte. Informacje te pozwolą na programowe diagnozowanie wielu problemów wynikających np. ze zmian warunków tworzących polisy lub problemów z obiektami, które nie spełniają kryteriów zawartych w polisach.

Widok syspolicy_conditions wyświetla po jednym wierszu dla każdego warunku zapisanego przez DMF. Prezentowane są takie informacje jak identyfikator warunku, jego nazwa, data utworzenia oraz data modyfikacji oraz informacje kto utworzył i kto zmodyfikował warunek. Dostępna jest także informacja z jakiego zestawu reguł warunek został utworzony oraz jak został skonstruowany (funkcyjnie). Ten widok może być użyty do sprawdzenia kto i kiedy warunek utworzył i zmienił.

Widok syspolicy_policies wyświetla po jednym wierszu dla każdej polisy. Prezentowane są informacje o identyfikatorze polis, jej nazwie, identyfikatorze warunku, z którego powstała polisa, identyfikatorze grupy, do której polisa należy oraz data jej utworzenia. Dostępna jest także informacja o tym, w jaki sposób polisa zostaje wykonana. W przypadku wykonywania okresowego można z tego widoku odczytać identyfikator joba. Inną ważną informacją, poza danymi o czasie modyfikacji i informacji, kto zmodyfikował polisę, jest możliwość odczytania, czy polisa jest aktywna, czy została wyłączona.

Widok syspolicy_policy_execution_history prezentuje informacje o czasie rozpoczęcia i zakończenia testu polisy wraz ze szczegółową informacją o wszystkich błędach, które mogły nastąpić podczas uruchomienia sprawdzenia polis. Kolumna result pozwala szybko stwierdzić, czy wykonanie sprawdzenia polisy zakończyło się sukcesem, gdyż przyjmuje wartość 0 dla poprawnego sprawdzenia i 1 w przypadku, gdy zostanie wykryty błąd.

Widok systemowy syspolicy_policy_execution_history_details prezentuje szczegółowe informacje o każdym sprawdzeniu polisy, takie jak:

  1. Czy wykonanie sprawdzenia polisy z obiektem, którego polisa dotyczy zakończyło się sukcesem,
  2. Nazwę instancji serwera, na której został przeprowadzony test,
  3. Ścieżkę w formacie XPath, która pozwala na szybkie zidentyfikowanie obiektu, względem którego nastąpiło sprawdzenie zgodności z polisą,
  4. Datę wykonania sprawdzenia,
  5. Link do informacji szczegółowej.

Widok syspolicy_policy_execution_history_details pozwala znaleźć odpowiedź na pytanie, które z warunków i obiektów spowodowały powstanie błędów i jaka jest ich przyczyna. W Books Online można znaleźć zapytanie, które łączy omawiane do tej pory widoki i wyświetla nazwę polisy, nazwę warunku oraz wszystkie szczegóły umożliwiające znalezienie odpowiedzi na pytanie dlaczego dany obiekt nie spełnił wymagań zawartych w polisie:

SELECT Pol.name AS Policy, 

Cond.name AS Condition, 

PolHistDet.target_query_expression, 

PolHistDet.execution_date, 

PolHistDet.result, 

PolHistDet.result_detail, 

PolHistDet.exception_message, 

PolHistDet.exception 

FROM msdb.dbo.syspolicy_policies AS Pol

JOIN msdb.dbo.syspolicy_conditions AS Cond

    ON Pol.condition_id = Cond.condition_id

JOIN msdb.dbo.syspolicy_policy_execution_history AS PolHist

    ON Pol.policy_id = PolHist.policy_id

JOIN msdb.dbo.syspolicy_policy_execution_history_details AS PolHistDet

    ON PolHist.history_id = PolHistDet.history_id

WHERE PolHistDet.result = 0 ;

Uwaga – widoki te są dostępne tylko dla użytkowników posiadających uprawnienia PolicyAdministratorRole w bazie danych msdb.

Dostępne są także nieudokumentowane procedury składowane, które m.in. umożliwiają tworzenie warunków, polis oraz określanie obiektów, których te polisy dotyczą. Łatwiejszym wydaje się używanie graficznego intefejsu podczas pracy z systemem DMF, ale może zdarzyć się konieczność założenia odpowiednich polis beż możliwości korzystania z GUI. Poniżej zaprezentuję użycie procedur składowanych, dzięki czemu można utworzyć polisę z przykładu zawartego w niniejszym artykule.

Procedura składowana sp_syspolicy_add_condition umożliwia utworzenie i zapisanie warunku w bazie danych msdb.

-- wstawiam nowy warunek. 

-- atrybut Name okresla jego nazwê a TypeClass typ danych

-- Fragment <Function> definiuje funkcjê do sprawdzenia warunku

Declare @condition_id int

EXEC msdb.dbo.sp_syspolicy_add_condition @name=N'Wyzwalacze (triggers) sa niedozwolone - domyslnie'

, @description=N'', @facet=N'Trigger'

, @expression=N'<Operator>

  <TypeClass>Bool</TypeClass>

  <OpType>EQ</OpType>

  <Count>2</Count>

  <Attribute>

    <TypeClass>Bool</TypeClass>

    <Name>IsEnabled</Name>

  </Attribute>

  <Function>

    <TypeClass>Bool</TypeClass>

    <FunctionType>False</FunctionType>

    <ReturnType>Bool</ReturnType>

    <Count>0</Count>

  </Function>

</Operator>', @is_name_condition=0, @obj_name=N'', @condition_id=@condition_id OUTPUT

Select @condition_id

Kolejna procedura tworzy polisę:

-- wstawiam nową polisę. 

-- parametr @condition_name okresla nazwê warunku użytego do zbudowania polisy

-- parametr @root_condition_name okresla warunki nałozone na serwer baz danych

Declare @policy_id int

EXEC msdb.dbo.sp_syspolicy_add_policy @name=N'Wyzwalacze domyslnie niedostepne w bazie danych Northwind'

, @condition_name=N'Wyzwalacze (triggers) sa niedozwolone - domyslnie'

, @policy_category=N'Kategoria testowa'

, @execution_mode=0

, @policy_id=@policy_id OUTPUT

, @root_condition_name=N'SQL Server 2005 SP1 or a Later Version'

Select @policy_id

Ostatnie procedury:

– sp_syspolicy_add_target_set 

- sp_syspolicy_add_target_set_level

Zostają wykonane dwukrotnie, ponieważ określają obiekty i definiują filtry, których będzie dotyczyła polisa. W naszym przykładzie wyzwalacze miały zostać sprawdzane w każdej tabeli (pierwsze wywołanie) oraz na każdym widoku (drugie wywołanie) w bazie danych Northwind:

Declare @target_set_id int

EXEC msdb.dbo.sp_syspolicy_add_target_set 

@policy_name=N'Wyzwalacze domyslnie niedostepne w bazie danych Northwind'

, @type_skeleton=N'Server/Database/Table/Trigger'

, @type=N'TRIGGER'

, @target_set_id=@target_set_id OUTPUT

Select @target_set_id



EXEC msdb.dbo.sp_syspolicy_add_target_set_level 

    @target_set_id=@target_set_id

    , @type_skeleton=N'Server/Database/Table/Trigger'

    , @level_name=N'Trigger'

    , @condition_name=N''

    , @target_set_level_id=0



EXEC msdb.dbo.sp_syspolicy_add_target_set_level 

    @target_set_id=@target_set_id

    , @type_skeleton=N'Server/Database/Table'

    , @level_name=N'Table'

    , @condition_name=N''

    , @target_set_level_id=0



EXEC msdb.dbo.sp_syspolicy_add_target_set_level 

    @target_set_id=@target_set_id

    , @type_skeleton=N'Server/Database'

    , @level_name=N'Database'

    , @condition_name=N'Baza danych Northwind'

    , @target_set_level_id=0

Ze względu na ograniczoną ilość miejsca zaprezentowałem tylko wywołanie dotyczące tablic. Drugie wywołanie, które określa zachowanie wyzwalaczy dla widoków, jest analogiczne.

Większość parametrów pobieranych przez każdą z procedur jest na tyle samoopisujące się, iż ich analizę autor artykułu pozostawia czytelnikom.

Uwaga - ze względu na fakt, iż brak jest oficjalnej dokumentacji na temat omawianych powyżej procedur składowanych, należy wykonywać je tylko w ostateczności, jako iż błędne określenie parametrów może spowodować niepoprawne zachowanie utworzonych obiektów.

 Do początku strony Do początku strony

Podsumowanie

W niniejszym artykule pokazałem, w jaki sposób można utworzyć polisę krok po kroku, sprawdzić jej działanie oraz wymusić takie zachowanie obiektu, którego polisa dotyczy, aby był z tą polisą zgodny. Należy jednak pamiętać, iż SQL Server 2008 CTP5 został dostarczony z gotowymi rozwiązaniami systemu DMF - polisami odzwierciedlającymi najlepsze praktyki firmy Microsoft, które są gotowe do natychmiastowego użycia.

Declarative Management Framework to doskonałe, potężne narzędzie pozwalające na zarządzanie instancjami SLQ Server na wysokim poziomie abstrakcji. Wygodny i intuicyjny interfejs użytkownika pozwala szybko i sprawnie utworzyć polisy i kontrolować zachowanie obiektów. Zdolność systemu DMF do natychmiastowego korygowania zachowania się obiektów tak, aby były zgodne z polisami czyni to rozwiązanie jeszcze atrakcyjniejszym.

W moim przekonaniu Declarative Management Framework jest jedną z najważniejszych nowych funkcjonalności, która została wprowadzona do SQL Server 2008.

  Damian Widera, Project Manager & Team Lead (MCT, MCITP - DBA, MCSD.NET)
Od 8 lat zajmuje się projektowaniem, tworzeniem i wdrażaniem aplikacji wykorzystujących platformę .NET, SQL Server oraz Oracle. Obecnie pracuje jako project manager dla LGBS Polska. Pracował także jako trener, programista, administrator baz danych, twórca domumentacji oraz analityk biznesowy. Aktywnie współpracuje z polskim oddziałem Microsoft publikując atykuły, webcasty oraz porady z zakresu SQL Server na stronach TechNet. Jest współautorem książki „Serwer SQL 2008. Administracja i programowanie".

Speaker na wielu konferencjach, m.in. Microsoft Heroes Happen Here, C2C, European PASS Conference, Microsoft Technology Summit, Energy Launch, TechED. Od 2004 r. posiada certyfikaty firmy Microsoft: MCT, MCITP-DBA oraz MCSD.NET. Jest współtwórcą oraz liderem jednej z najwiekszych grup pasjonatów SQL Server w Polsce - Śląskiej Regionalnej Grupy Microsoft (PLSSUG Katowice). Od listopada 2008 jest prezesem Polish SQL Server Users Group (PLSSUG) w Polsce. W styczniu 2009 nagrodzony tytułem MVP w kategorii SQL Server.
 Do początku strony Do początku strony

Microsoft SQL Server 2008