Narzędzie Performance Dashboard Reports w użyciu, cz. I
Instalacja, uruchomienie raportów, ograniczenia, własny raport
Zawartość strony
Wstęp
W dzisiejszym artykule chciałbym pokazać, w jaki sposób można korzystać i co nam daje nowe narzędzie firmy Microsoft – Performance Dashboard Reports. Omówię główne zalety prezentowanej aplikacji oraz pokażę, w jaki sposób można łatwo rozszerzyć jej zakres poprzez wykonanie funkcjonalnego raportu do audytu wybranej czynności serwera. Postaram się przekonać również, iż narzędzie Performance Dashboard Reports może być cenną pomocą dla każdego administratora baz danych na co dzień.
Performance Dashboard Reports są zbiorem raportów, które mogą być uruchomione z SQL Server Management Studio (SSMS). Raporty te prezentują dane zebrane z dynamicznych widoków zarządczych (DMV) oraz dynamicznych funkcji zarządczych (DMF), które są dostępne w aparacie baz danych SQL Server 2005. Nie powinniśmy o tych raportach myśleć w kontekście zastępowania istniejących narzędzi oferowanych przez SQL Server, takich jak SQL Profiler czy Database Tuning Advisor (DTA). Służą one raczej administratorom baz danych do szybszego wykrycia problemów związanych chociażby z wydajnością serwera (ale nie tylko). Performance Dashboard Reports są podobne do wielu raportów wbudowanych w SSMS (patrz rysunek 1) i pomimo tego, że raporty zbudowano w oparciu o pliki definicji raportów Reporting Services (*.rdl), to nie jest konieczne instalowanie tej usługi.
Rys. 1. Przykładowy widok opcji raportów wbudowanych w SSMS.
Instalacja
Przed rozpoczęciem instalacji warto upewnić się, iż zainstalowaliśmy dodatek Service Pack 2 (SP2) dla SQL Server zarówno na serwerze baz danych, jak i na maszynie, na której zamierzamy uruchomić Performance Dashboard Reports. Jeżeli nie jesteśmy pewni czy odpowiedni dodatek został już zainstalowany, możemy to sprawdzić w następujący sposób:
1. | otworzyć SQL Server Management Studio |
2. | odczytać numer wersji serwera baz danych:  Rys. 2. Numer wersji aparatu SQL Server. |
3. | Liczba 9.0.3042 określa, iż w systemie zainstalowano dodatek Service Pack 2 dla SQL Server. Dokładnie rzecz ujmując – należy przeanalizować wartość znajdującą się po numerze 9.0. Jeżeli jest ona większa niż 3000, to oznacza iż dodatek SP2 został zainstalowany. |
Następnym krokiem jest pobranie pliku z podanego poniżej adresu (rysunek 3):
Rys. 3. Informacje o pliku zawierającym instalator raportów.
Plik SQLServer2005_PerformanceDashboard.msi ma jedynie 1.4MB. Instalacja raportów nie powinna sprawić nikomu problemów, nie będę więc jej opisywać, ponieważ nie różni się od innych tego typu procesów. Nadmienić należy tylko, iż jest możliwość zapisania raportów w innej lokalizacji niż domyślna, sugerowana przez program instalacyjny (rysunek 4). Nie jest to oczywiście szczególna cecha tego właśnie instalatora, ale cieszy możliwość zapisania instalowanych plików w wybranym przez użytkownika folderze (np. zawierającym inne raporty).
Rys. 4. Okno wyboru lokalizacji plików raportów na twardym dysku.
Po zakończeniu pracy instalatora pozostaje do wykonania jeszcze jeden krok, który musi zostać wykonany ręcznie. Należy otworzyć katalog, w którym zostały zainstalowane raporty i w SSMS uruchomić skrypt setup.sql (patrz rysunek 5 poniżej).
Rys. 5. Lokalizacja skryptu setup.sql.
Skrypt setup.sql tworzy procedury składowane oraz funkcje niezbędne dla wypełnienia raportów danymi. Uruchamiany skrypt wykonuje się w kontekście bazy danych msdb, więc w przypadku, gdy raporty mają zostać uruchomione dla innej bazy danych (a tak zazwyczaj właśnie będzie), należy zmodyfikować odpowiedni wpis - jak pokazano na rysunku 6 (pamiętając, iż dla bazy msdb skrypt także trzeba jeden raz uruchomić!):
Rys. 6. Skrypt setup.sql.
Kod zawarty w skrypcie nie tworzy żadnych tabel w bazie danych, w kontekście której został uruchomiony.
Uruchomienie raportów
Do uruchomienia Performance Dasboard Reports, jak już wspomniałem wcześniej, nie jest potrzebna instalacja usługi Reporting Services. Raporty należy uruchomić za pomocą SQL Server Mangement Studio w kontekście bazy danych, dla której uruchomiony został skrypt setup.sql . W tym celu należy z menu kontekstowego dla wybranej bazy danych zaznaczyć opcje Reports->Custom reports, jak pokazano na rysunku 7 poniżej.
Rys. 7. Uruchomienie raportów.
Następnie należy wskazać plik performace_dashboard_main.rdl, ponieważ ten plik zawiera definicje raportów i musi zostać wybrany przy pierwszym uruchomieniu raportów w SSMS (rysunek 8).
Rys. 8. Plik z definicją raportów.
SQL Server ostrzeże użytkownika, iż uruchamianie raportów może się wiązać z potencjalnym niebezpieczeństwem dla serwera (rysunek 9). Należy nacisnąć przycisk Run w celu uruchomienia raportu.
Rys. 9. Okno ostrzeżenia o potencjalnym niebezpieczeństwie dla serwera baz danych.
Po uruchomieniu raportu SSMS wyświetla główne okno Performance Dashboard Reports, które składa się z pięciu głównych sekcji (patrz rysunek 10 poniżej):
1. | System CPU Utilization |
2. | Current Waiting Requests |
3. | Current Activity |
4. | Historical Information |
5. | Miscellaneous Information |
Rys. 10. Performace Dashboard - główne okno raportowania.
Ograniczenia podczas pracy z raportami
Omawiane narzędzie posiada kilka ograniczeń, które warto znać:
| • | nie można korzystać z opcji Cut & Paste. Dane powinny zostać wyeksportowane do zewnętrznych aplikacji za pomocą menu kontekstowego. To ograniczenie wynika z konstrukcji przeglądarki raportów wbudowanej w SSMS. |
| • | SQL Server Management Studio posiada błąd, który powoduje, iż przycisk Back jest czasami niedostępny w przypadku wykonywania raportów szczegółowych. Zainstalowana poprawka SP2 nie rozwiązała tego problemu. |
| • | Nie można uzyskać dostępu do systemowych liczników wydajności (performance counters). Można by co prawda uzyskać wiele wymaganych informacji przy pomocy dynamicznego widoku zarządczego sys.dm_os_performance_counters, ale wymagałoby to dodatkowego czasu na obliczenie przyrostu licznika i przechowania co najmniej jednej jego wartości poprzedniej, co z kolei spowodowałoby wydłużenie czasu oczekiwania na raport. |
| • | Nie można zmieniać kolejności kolumn w tablicach w prezentowanych raportach, skalować raportów oraz ich ukrywać. To ograniczenie wynika z konstrukcji przeglądarki raportów wbudowanej w SSMS. |
W mojej opinii istniejące ograniczenia nie wpływają znacząco na komfort pracy z Performance Dashboard Reports i nie zmniejszają jego funkcjonalności. Należy mieć tylko nadzieję, iż następne wersje omawianego narzędzia rozwiążą chociaż część ze znanych problemów.
Własny raport – propozycja rozszerzenia istniejącej funkcjonalności Performance Dashboard Reports
Pracując na co dzień z opisywanym narzędziem zastanawiałem się, jakie jeszcze dodatkowe, inne informacje można by wyświetlić w Performance Dashboard Reports. Kierowałem się oczywiście podstawowymi wytycznymi każdego chyba administratora baz danych – chciałem wiedzieć jak najwięcej i jak najmniej się dla otrzymania tej informacji napracować. Postanowiłem zmodyfikować nieco główny raport, dodając informację o statusie planów konserwacyjnych (maintenance plans) oraz jobów w danym dniu. Istotne jest, iż na głównym raporcie chciałem mieć informacje jak najbardziej oszczędną, która przyciągnie mój wzrok tylko wtedy, gdy którekolwiek z zadań nie zakończyłoby się pomyślnie. W tym przypadku postanowiłem posłużyć się systemowymi tablicami znanymi jeszcze z wcześniejszych wersji SQL Server – sysjobs, sysjobhistory oraz sysjobsteps, które znaleźć można w systemowej bazie danych msdb. Niektóre z tych tablic, w odróżnieniu od dynamicznych widoków zarządczych wprowadzonych w SQL Server 2005, przechowują znaczne ilości informacji historycznych.
Najpierw zmieniłem procedurę składowaną [MS_PerfDashboard].[usp_Main_GetMiscInfo], która odpowiada za wyświetlenie informacji w sekcji Miscellaneous Information:
ALTER PROCEDURE [MS_PerfDashboard].[usp_Main_GetMiscInfo] as BEGIN DECLARE @today varchar(8) SET @today = CONVERT(varchar(8),GETDATE(),112) select (select count(*) from sys.traces) as running_traces, (select count(*) from sys.databases) as number_of_databases, (select count(*) from sys.dm_db_missing_index_group_stats) as missing_index_count, (select waiting_tasks_count from sys.dm_os_wait_stats where wait_type = _ N'SQLCLR_QUANTUM_PUNISHMENT') as clr_quantum_waits, (select count(*) from sys.dm_os_ring_buffers where ring_buffer_type = _ N'RING_BUFFER_SCHEDULER_MONITOR' and record like N'%<NonYieldSchedBegin>%') as non_yield_count, (select cpu_count from sys.dm_os_sys_info) as number_of_cpus, (select scheduler_count from sys.dm_os_sys_info) as number_of_schedulers, (SELECT count(*) FROM sysjobhistory WHERE run_date = @today and run_status=0 and step_id=0) _ AS failed_jobs_count, (SELECT count(*) FROM sysjobhistory WHERE run_date = @today and run_status=0 and step_id=0 and _ job_ID IN(SELECT job_id FROM sysjobs WHERE category_id=3)) AS failed_mtnplans_count END
Następnym krokiem była zmiana wyglądu głównego raportu, jak pokazałem na rys. 11:
Rys. 11. Rozszerzenie funkcjonalności Performance Dashboard Reports – zmiany w głównym raporcie.
Wszystkich zmian w plikach definicji raportów *.rdl dokonywałem przy pomocy SQL Server Business Inteligence Development Studio (BIDS).
Dla pola odpowiadającego za wyświetlenie o statusie jobów zmieniłem nastepujące własności:
1. | Kolor =IIF(Sum(Fields!failed_jobs_count.Value, "MISC_INFO") > 0,"RED","BLACK") |
2. | b) Tekst =IIF(Sum(Fields!failed_jobs_count.Value, "MISC_INFO") > 0,"ERROR","OK") |
W podobny sposób przygotowałem pole wyświetlające status zdefiniowanych planów konserwacji serwera.
W efekcie po uruchomieniu głównego raportu uzyskałem efekt jak na rysunku 12:
Rys. 12. Wygląd zmienionej sekcji Miscellaneous Information.
Jak widać, co najmniej jedno z zadań nie zakończyło się sukcesem. W takim przypadku chciałem wyświetlić informacje o wszystkich problemach, które wydarzyły się w danym dniu. Dla wyświetlenia szczegółów raportu o nieudanych Jobach, wykonałem w kontekście bazy danych msdb procedurę składowaną usp_JobsFailed, które zwraca 10 najnowszych informacji dla każdego joba. Procedura przedstawia się następująco:
CREATE PROCEDURE usp_JobsFailed AS BEGIN DECLARE @today varchar(8) SET @today = CONVERT(varchar(8),GETDATE(),112) DECLARE @today_desc varchar(15) SET @today_desc =CONVERT(varchar(15),GETDATE(),111) SELECT D.job_id , instance_id ,D. step_id , command ,run_time ,message ,run_duration ,sql_severity ,j.name ,j.date_created , j.date_modified ,@today_desc as today FROM (SELECT job_ID , instance_ID , step_id , run_time ,message ,run_duration ,sql_severity ,ROW_NUMBER() OVER(PARTITION BY job_id ORDER BY instance_id desc) as R FROM dbo.sysjobhistory WHERE run_date = @today and run_status=0 and step_id<>0 GROUP BY Job_ID,instance_ID,step_id,run_time, message,run_duration,sql_severity ) as D JOIN dbo.sysjobsteps S on D.job_id=S.job_id JOIN dbo.sysjobs J on D.job_id = J.job_id WHERE R < 10 AND s.step_id=d.Step_id END
Podobna procedura została wykonana dla planów konserwacyjnych serwera (maintenance plans).
Następnym krokiem było wykonanie możliwie najbardziej prostego i czytelnego raportu za pomocą BIDS i podłączenie go na głównej stronie Performance Dashboard Reports do odpowiednich linków jak pokazano na rys. 13 poniżej:
Rys. 13. Sposób podłączenia nowego raportu do odnośników na głównej stronie Performance Dashboard Reports.
Na rysunku 13 przedstawiłem podstawowe informacje o sposobie wykonania raportu informującego o detalach jobów wykonanego w BIDS. Na zakładce Data wskazałem na procedurę usp_JobsFailed, natomiast na zakładce Layout wykonałem prosty, acz funkcjonalny zarys raportu.
Rys. 14. Przykład wykonania raportu w BIDS.
Po skopiowaniu zmienionych plików do katalogu, w którym zainstalowałem Performance Dashboard Reports i uruchomieniu głównego raportu otrzymałem wynik jak na rysunku 15:
Rys. 15. Zmieniony, główny raport Performance Dashboard.
Po wybraniu odnośnika Jobs status (today) uruchomił się wykonany przeze mnie raport, który w działaniu zaprezentowałem na rysunku 16.
Rys. 16. Raport prezentujący niezakończone sukcesem joby.
Wykonanie wszystkich opisanych czynności zajęło mi mniej niż trzy kwadranse i otrzymałem praktycznie bez wysiłku raport, który informował mnie o potencjalnych problemach z jobami oraz planami konserwacji serwera. Oczywiście, można zadać sobie pytanie po co to robiłem? Przecież wystarczy kilka razy kliknąć w SSMS i otrzymałbym nawet bardziej szczegółową informację. Odpowiedź jest w zasadzie jedna – dzięki Performnce Dashboard Reports muszę kliknąć tylko raz – na przycisk Refresh.
Stosując podobną metodologię można wykonać dużo bardziej skomplikowane raporty, chociaż trzeba przyznać, że na szczęście większość z nich została już za nas wykonana.
Przeczytaj pozostałe części tego artykułu
| • |
 | Damian Widera, Project Manager & Team Lead (MCT, MCITP – DBA, MCSD.NET) |