| Wstęp | |
| Wymagania | |
| Instalacja | |
| Praca z programem | |
| Podsumowanie |
Systemy bazodanowe stają się coraz bardziej skomplikowane. Gromadzimy już nie pojedyncze gigabajty danych, ale dziesiątki i setki gigabajtów na potrzeby naszych aplikacji. Z jednej strony chcemy zapewnić maksymalne bezpieczeństwo danych, z drugiej strony chcemy mieć do nich jak najszybszy dostęp. Do poprawnego administrowania bazami danych potrzebna jest wiedza ekspertów, gdyż od nich tak naprawdę zależy wszystko – włącznie z „być albo nie być” firmy. Praktyka pokazuje, że znaczną cześć zadań administracyjnych można zautomatyzować i w tym kierunku idą zmiany proponowane przez firmę Microsoft w systemie SQL Server 2005. Okazuje się, że istnieje narzędzie, które pozwala administratorom (i nie tylko) baz danych na szybkie sprawdzenie, czy serwer baz danych jest skonfigurowany zgodnie z rekomendacjami firmy Microsoft. Narzędzie to nazywa się Microsoft SQL Server Best Practices Analyzer 2.0 (autor oparł artykuł o wersję Community Preview z lutego 2007).
Wymagania dla zainstalowania i poprawnego działania programu zostały określone następująco:
1. | Zainstalowany .NET Framework w wersji co najmniej 2.0 |
2. | System operacyjny – Windows Server 2003, Windows XP lub Windows Vista |
3. | Co najmniej 256 MB RAM co wystarcza na przeskanowanie do 50 instancji SQL Servera |
4. | Dla każdej skanowanej instancji program wymaga co najmniej 2MB wolnego miejsca na dysku |
5. | Użytkownik korzystający z programu musi mieć prawa do zapisu/odczytu w katalogu, w którym pracuje SQL Best Practices Analyzer |
6. | Usługi Remote Registry oraz WMI muszą być aktywne na komputerze, na którym działa aplikacja i na każdej skanowanej instancji SQL Serwer |
7. | Usługi IIS muszą być skonfigurowane na komputerze, na którym zainstalowano aplikację. |
Aplikacja może być zainstalowana na dowolnym komputerze, który spełnia opisane wymagania, nie musi to być serwer baz danych.
Instalacja programu jest bardzo prosta i nikomu nie powinna nastręczyć najmniejszych kłopotów. Dla zainstalowania programu wystarczy uruchomić plik SQLBPASetup.msi (który można pobrać tutaj). Program po zainstalowaniu zajmuje ok. 3.5 MB miejsca na twardym dysku. Program jest w stanie przetestować zarówno system SQL Server 2005 (Database Engine, Analysis Services, Reporting Services i Integration Services) jak i jego poprzednią wersję – SQL Server 2000 (Database Engine).
SQL Server 2005 Best Practices Analyzer będzie w stanie skanować instancje systemu SQL Server, o ile użytkownik posiada odpowiednie uprawnienia:
| • | Administratora domeny lub jest w grupie BUILTIN\Administrators na skanowanych komputerach (wymaganie odnośnie WMI) |
| • | Jeżeli skanowany jest komputer będący hostem dla Reporting Services, to należy aplikację uruchomić na koncie członka grupy Local Administrators (dostęp do IIS) |
| • | W przypadku, gdy uruchamiamy program korzystając z konta, które nie posiada odpowiednich uprawnień, należy skorzystać z jednej z dwóch opcji: |
| • | Uruchomić aplikację z opcją ‘Run as’ lub z linii poleceń uruchomić program z konta, które ma odpowiednie uprawnienia: runas /netonly /user:<DomainName>\<UserName>SQLBPA.exe |
| • | Ustawić odpowiednie uprawnienia na stronie ‘Connect to Active Directory’ w programie. |
Po uruchomieniu program sprawdza, czy jest dostępna nowa wersja aplikacji i proponuje uaktualnienie, jeżeli taką wersje odnajdzie:

Rys. 1. Okno aktualizacji programu.
Oczywiście, zawsze można anulować sprawdzanie dostępności aktualizacji oprogramowania. Po sprawdzeniu dostępności aktualizacji aplikacja umożliwia nam rozpoczęcie pracy. Będąc na ekranie powitalnym użytkownik może zdecydować, czy chce rozpocząć proces nowego skanowania, czy przeanalizować zachowane wcześniej raporty (Rysunek 2). Raporty zachowywane są w plikach XML, można je więc łatwo poddawać dalszej obróbce, o ile oczywiście ktoś ma taką potrzebę.

Rys. 2. Plansza powitalna programu.
Dla ułatwienia omówię wszystkie opcje w kolejności, w jakiej pokazane są one w części nawigacyjnej aplikacji. Opcja Scan SQL Services pozwala na skonfigurowanie procesu analizy instancji SQL.

Rys. 3. Wybór serwerów do analizy.
Po pierwsze – użytkownik musi wskazać, który serwer (serwery) mają zostać poddane analizie. Na pierwszy rzut oka dostępne są trzy opcje:
| • | SQL Server instance name |
| • | Computer name |
| • | File name |
Proszę zwrócić uwagę także na pozostałe opcje zawarte na Rysunku 3:
1. | Export/Import registered SQL components - Import from file – należy wskazać na plik XML z zapisanymi serwerami sql. Plik taki jest generowany przez SQL Server Management Studio i zawiera listę zarejestrowanych serwerów, do których można szybko się podłączyć z poziomu SSMS, |
2. | Select the scan level – Detailed/Limited scan. Sens jest oczywisty – jeżeli można sobie pozwolić (czasowo) na skanowanie szczegółowe, |
3. | Enter a name for the scan – użytkownik może nadać nazwę aktualnemu procesowi skanowania. Opcja bardzo przydatna, gdyż będący efektem przeprowadzonej analizy raport będzie zawierał nadaną w tym polu nazwę. |
Wracając ponownie do opcji wyboru skanowania instancji - każda z nich powinna być użyta w innych okolicznościach, np. opcja ‘SQL Server instance name’ jest bardzo przydatna w sytuacji, gdy znamy nazwę serwera – patrz Rysunek 4.

Rys. 4. Konfigurowanie analizy dla instancji SQL Servera określanej wg nazwy.
Dla wybranego serwera użytkownik powinien określić, które komponenty będą podlegały skanowaniu:
| • | Database Engine |
| • | Analysis Services |
| • | Integration Services |
| • | Reporting Services |
Oczywiście – jest to też dobry moment, aby wprowadzić informacje dotyczące sposobu uwierzytelniania (SQL / Windows) oraz podać nazwę użytkownika i hasło (dla uwierzytelniania SQL).
Opcja ‘Computer name’ pozwala łatwo odnaleźć wszystkie zainstalowane serwery na określonym komputerze. Wystarczy zaznaczyć na drzewku, które instancje mają zostać przeanalizowane. Stosując poprzednio omówioną metodę stracili byśmy cenny czas na wprowadzanie informacji dotyczących tego samego komputera.

Rys. 5. Konfigurowanie analizy dla instancji SQL Servera podawanej po nazwie komputera.
Ostatnią opcją jest możliwość wskazania pakietu DTSX i przeprowadzenia analizy za jego pomocą (należy wtedy wybrać opcję File Type).

Rys. 6. Konfigurowanie analizy za pomocą zapisanego pliku DTSX.
Następnym krokiem (i ostatnim) przed rozpoczęciem skanowania jest wskazanie baz danych, na których ma być przeprowadzona analiza. Najważniejsza informacja ukryta jest jednak w dolnej części ekranu – w przypadku, gdy użytkownik nie wybierze żadnej bazy danych, zostaną zeskanowane tylko usługi systemu SQL Server – patrz rys. 7.

Rys. 7. Okno wyboru baz danych do analizy.
Program posiada jeszcze jedną bardzo pożyteczną funkcję, dostępną w panelu nawigacyjnym aplikacji – ‘Schedule a scan’ – harmonogram analiz. Dla administratorów baz danych jest to oczywiste rozwiązanie, znacznie ułatwiające i poprawiające komfort codziennej pracy. Na Rysunku 8 pokazałem możliwości, jakie oferuje okno harmonogramu skanowań dla aktualnie konfigurowanych instancji. Do dyspozycji użytkownika są cztery sposoby uruchomienia harmonogramu:
| • | Jednorazowo (ustawienie domyślne) – Once |
| • | Dziennie |
| • | Raz w tygodniu |
| • | Raz w miesiącu |
Wykorzystanie opcji domyślnej pozwala użytkownikowi na zaplanowanie uruchomienia analizy w określonym momencie w przyszłości. Można więc jednorazowo wykonać zamierzone analizy w porze najmniejszego obciążenia serwera (w niektórych przypadkach tak dzieje się w nocy, ale oczywiście nie jest to reguła). Wydaje się, iż te cztery opcje są wystarczające z punktu widzenia celu, jakiego osiągnięcie umożliwia nam omawiana aplikacja.

Rys. 8. Opcja wygenerowania harmonogramu analiz.
Dobra wiadomość – właśnie zakończono konfigurowanie aplikacji. Wydawać się to może zawiłe lub trudne – ale nic bardziej mylnego!!! Przeczytanie tekstu do tego momentu zajęło Ci z pewnością więcej czasu niż skonfigurowanie programu. Po uruchomieniu procesu skanowania (na testowym komputerze i testowym serwerze trwało to niecałe 2 minuty – patrz na koniec artykułu) użytkownik jest na bieżąco informowany o przebiegu procesu analizy – jak pokazano na Rysunku 9.

Rys. 9. Okno informujące o przebiegu procesu skanowania.
Program, po zakończeniu skanowania, udostępnia użytkownikowi szereg raportów:
| • | Raport w postaci listy – moim zdaniem najbardziej przejrzysty. Dodatkowo umożliwia pogrupowanie elementów po ważności, klasie błędu oraz problemie |
| • | Raport w postaci drzewka elementów – trudniejszy w odbiorze i analizie, zwłaszcza dla początkujących użytkowników programu |
| • | Inne raporty – podsumowuje i umożliwia wyświetlenie raportu z przeprowadzonych operacji ‘krok po kroku’. Nie jest to może szczególnie interesujące zestawienie, biorąc pod uwagę poprzednio zaprezentowane raporty z analizy konfiguracji serwera bazy danych |
Przykładowy raport w postaci listy pogrupowanej po ważności błędu pokazano na Rysunku 10. W moim przypadku rekomendacje podzielono na dwie grupy – ostrzeżenia i ‘best practices’. W grupie zawierającej ostrzeżenia mogłem znaleźć między innymi informacje, iż uruchamianie kodu CLR jest dozwolone, ale posiadam starszą wersję systemu SQL Server (old build) oraz iż integralność bazy danych należy sprawdzać minimum raz na 2 tygodnie. W grupie związanej z ‘best practices’ otrzymałem informacje, iż używane hasła nie spełniają norm dotyczących długości (minimum 7 znaków) oraz stopnia złożoności. Istotnym jest fakt, że aplikacja podpowiada również, w jaki sposób należy problem rozwiązać i jest to moim zdaniem największa zaleta (i cel stosowania) omawianego programu. Podpowiedzi otrzymujemy po kliknięciu na element listy. Rekomendacja odnosząca się do wybranego problemu zostanie wyświetlona w postaci pliku pomocy, po kliknięciu na link ‘Tell me more about…’ (patrz Rysunek 11). Dodatkowo można nakazać aplikacji, aby o podobnym przypadku nie informowała dla tej bądź każdej instancji.

Rys. 10. Przykładowy raport wygenerowany przez program – pogrupowany względem ważności błędu.

Rys. 11. Przykładowe rekomendacje wygenerowane przez aplikację.
SQL Server 2005 Best Practices Analyzer jest przydatnym i cennym narzędziem w pracy każdego administratora baz danych. Program posiada prosty i bardzo intuicyjny interfejs oraz dobrze napisany plik pomocy (w języku angielskim – nie należy się raczej spodziewać spolszczenia produktu). Praca z aplikacją nie jest uciążliwa, a opcja harmonogramu wykonywania analiz jest bardzo przydatna i umożliwia śledzenie zmian aplikowanych na serwerach przez inne osoby. Należy mieć jednak świadomość, że program analizuje serwer pod ustalonym kątem i z całą pewnością pozostają obszary, które nie zostały jak na razie włączone przez firmę Microsoft, jako objęte rekomendacjami. Moim zdaniem SQL Server 2005 Best Practices Analyzer pozwoli administratorom na jeszcze większe zautomatyzowanie pracy skutecznego zarządzania serwami baz danych.
Uzupełnienie
Strona domowa programu: http://blogs.msdn.com/sqlrem/
Stanowisko testowe: Komputer z zainstalowana aplikacją – system operacyjny Windows XP PRO SP2, 2 GB RAM, procesor AMD Athlon 2800 +.
Stanowisko z serwerem baz danych – system operacyjny Windows Server 2003 z zainstalowanym ostatnim SP, 3 GB RAM, procesor Intel Core Duo 3GHz, SQL Server 2005 wersja Enterprise.
![]() | Damian Widera, Project Manager & Team Lead (MCT, MCITP – DBA, MCSD.NET) |