SQL Server Administration: Stwórz własny monitoring baz danych! Część 2 – Performance Counters


SQL Server Administration: Stwórz własny monitoring baz danych! Część 1

Zestaw liczników

Po co nam monitoring? Ktoś może powiedzieć, że chce wiedzieć o wszystkich problemach, które pojawią się w jego systemie. Poszedłbym jednak dalej: monitoring miałby, w pewnych przypadkach, odpowiednio wcześniej sygnalizować ewentualność takich problemów. Potrzebujemy do tego odpowiedniego zestawu liczników, które zbieramy i na bieżąco analizujemy.

W pierwszej części tej serii pokazałem, jak stworzyć przykładowy zestaw startowy liczników Windows i SQL Server. Było ich zaledwie 14, co oczywiście nie wyczerpuje kwestii monitoringu. Jak zatem powinien wyglądać pełny, wzorcowy zestaw, dzięki któremu nasza instancja będzie śledzona jak należy? W tym artykule podzielę liczniki na CPU, pamięć, dyski, sieć oraz inne. Postaram się także określić, jak należy ustawić progi, po przekroczeniu których powinniśmy otrzymać informację, że nasza instancja nie pracuje poprawnie. Na koniec pokażę, jak zautomatyzować instalację nowych liczników za pomocą gotowego szablonu.

Procesor

Jednym z podstawowych wskaźników określających kondycję naszego hosta i instancji baz danych jest utylizacja procesora.

W wielu opracowaniach możemy znaleźć informację, że powinniśmy zacząć się martwić o procesory, gdy przekroczymy próg 80% utylizacji CPU. Odnosi się to do sytuacji, w której już nie jesteśmy wstanie zoptymalizować zapytań na tej instancji bazy danych, co zdarza się bardzo rzadko. O wiele częściej zdarza się, że zanotujemy znaczną różnicę utylizacji w stosunku do dotychczasowych wskazań. Z doświadczenia wiem, że powinniśmy zacząć uważnie analizować sytuację, gdy wskazania zmienią się w stosunku do dotychczasowych o ponad 25%. I nie ma tu znaczenia, w którą stronę. Znaczny spadek utylizacji może wskazywać na awarię po stronie aplikacji lub infrastruktury. Wzrost natomiast, na przykład, na nieoptymalny plan jednej z procedur składowanych w bazie danych. I to, jaki mamy tzw. „zapas mocy”, determinuje, ile pozostaje czasu na reakcję.

Przykład z życia wzięty: dla średniej utylizacji CPU na poziomie 20% zaczynamy obserwować wzrost przekraczający 25% normy (średnie CPU wzrasta o 5% i dalej rośnie). Szybka analiza wskazuje na to, że wpadł nieoptymalny plan dla jednej z kluczowych procedur składowanych. Spowolnienie tej procedury powoduje, że sesje na bazie dłużej są utrzymywane i liczba aktywnych sesji także zaczyna rosnąć. Od razu mamy efekt nakładania się sesji wywołujących tę procedurę. Zanim jednak utylizacja sięgnęła 80%, zdążyliśmy przetestować poprawkę i wdrożyć na produkcję. Gdyby alert zapalił się dopiero przy 80% utylizacji, byłoby już za późno. Z pewnością mielibyśmy zgłoszenie klienta o spowolnieniu systemu. Zapas 80% wolnego czasu procesora dał nam 30 minut na niezbędne prace.

Drugim licznikiem z grupy CPU, jaki powinniśmy obserwować, jest kolejka na procesorze:

Licznik pokazuje chwilową kolejkę dla wszystkich procesorów w danej chwili. Inaczej mówiąc, ile wątków w stanie gotowości czeka na przetworzenie. Licznik ten można w różny sposób interpretować, spotyka się zalecenia, że próg może być nawet na poziomie 5 lub nawet 10 x liczba procesorów. Moim zdaniem utrzymująca się przez 5 minut kolejka większa niż 2 x liczba procesorów – w godzinach normalnego funkcjonowania biznesu – wymaga sprawdzenia, co może być tego powodem.

Są to dwa główne liczniki CPU, ale warto zbierać również inne z nimi powiązane, które mogą pomóc naprowadzić na trop przyczyny w mniej oczywistych przypadkach. Poniżej ich lista z krótkim opisem:

Pamięć

Odpowiednia ilość pamięci jest jednym z najistotniejszych czynników mogących zagwarantować poprawną pracę instancji bazy danych. Ponadto pamięć jest relatywnie tania w stosunku do innych podzespołów, które obsługują naszą instancję. Mam tu na myśli nie tylko ich cenę, ale również koszty licencji (w MS SQL’u płacimy za cory CPU, a nie za ilość obsługiwanej pamięci). Większość problemów powiązanych z brakiem RAM można zatem szybko wyeliminować. Tylko jak namierzyć problemy wywołane niedostateczną ilością pamięci?

Na przykład poprzez obserwację licznika PLE (Page Life Exptentancy):

Najprościej rzecz ujmując, licznik pokazuje nam średni czas życia strony danych w buforze SQL Servera (w sekundach). Jeżeli silnik baz danych często wymienia strony (pamięć jest ‘wypłukiwana’), oznacza to, że mamy jej za mało albo na naszej instancji pracują ciężkie zapytania, które przetwarzają olbrzymią ilość danych. Te nie mieszczą się w pamięci i nowe dane cały czas są pobierane z dysku. Takie „wypłukanie” bufora może, na przykład, spowodować miesięczny lub roczny raport. W godzinach pracy biznesu nie powinno w ogóle dochodzić do tego typu sytuacji. Generalnie zaleca się, by strona przebywała w buforze co najmniej 5 minut (300 sekund), ale to także zależy od ilości RAM i rodzaju obciążenia naszej instancji.

Podobnie działa kolejny licznik:

Ten licznik określa w istocie procentowy udział kesza danych w dostarczaniu stron danych bez udziału dysku. Wskazania zaczynają spadać, jeżeli pobierana strona musi zostać dobrana z dysku. Idealny wykres z całego dnia pracy bazy OLTP powinien wyglądać następująco:

Łatwo zatem rozpoznać symptomy braku pamięci. Musimy jednak pamiętać, że ten licznik będzie miał niskie wskazania podczas startu systemu oraz podczas uruchamiania „grubszych” raportów. Dziesięciominutowa tolerancja niższych wskazań jest więc jak najbardziej dopuszczalna.

Jednoznacznie wskazujący na problemy z pamięcią jest licznik Memory Grants Pending (obiekt Memory Manager):

Liczba procesów SQL Server, które oczekują na przydzielenie pamięci. Powinno być zawsze zero. Jeżeli nawet tylko jeden z procesów czeka na przydzielenie RAM, oznacza to, że zapytanie jest tak bardzo zasobożerne, że trzeba chwilę poczekać na przydział. Być może trzeba wtedy spróbować zoptymalizować to zapytanie. Więcej procesów może oznaczać zbyt małą wielkość pamięci RAM. W każdym razie licznik ten w większości przypadków wskazuje już na poważne kłopoty… Nawet jedna nieoptymalna procedura może spowodować sytuację, w której sesje będą czekać na granta pamięci, a ich liczba, z biegiem czasu, będzie się zwiększać:

Kolejny ważny licznik patrzy na pamięć od strony systemu operacyjnego. To oczywiście Available MBytes (obiekt Memory):

To jest dostępna, fizyczna pamięć dla OS. Alarm powinien się uaktywnić przy spadku dostępnej pamięci poniżej 256 MB dla maszyn z 4 GB RAM. Generalna zasad brzmi, że przynajmniej te 5% fizycznego RAM powinno być dostępne dla zadań uruchomionych w ramach systemu operacyjnego. Administrator SQL Server’a powinien to uwzględnić, ustawiając odpowiednio parametr max server memory (MB). Przy obliczaniu tego parametru, należy również wziąć po uwagę inne, niezależne od silnika baz danych serwisy, takie jak SSIS czy SSAS.

Omówiłem cztery podstawowe liczniki dotyczące pamięci. Obok nich powinniśmy prześledzić jeszcze kolejne:

Jak widać, liczników związanych z pamięcią jest całkiem sporo w naszej linii bazowej. Ale jest to uzasadnione podejście, ponieważ stosunkowo trudno zdiagnozować presję na pamięć. Powyższy zestaw powinien nam w tym pomóc.

Dyski

Dyski mają bardzo duży wpływ na wydajność naszej instancji. Zależy ona nie tylko od szybkości dysków, ale również od optymalnego rozmieszczenia na dyskach plików bazy tempdb i plików baz użytkowników. W zasadzie każdy duży i poprawnie skonfigurowany system bazodanowy lokalnie powinien mieć tylko dysk z OS’em i ewentualnie dysk na binarki aplikacji. Reszta to przeważnie dyski „wykrojone” z macierzy dyskowej o olbrzymiej wydajności. Taka konfiguracja nie zwalnia nas jednak od śledzenia wydajności dysków. A to z jednej prostej przyczyny: nawet macierze na dyskach SSD mają swoje granice możliwości. Nic nam nie dadzą tysiące IO, jeżeli macierz będzie udostępniała przestrzeń dla dużej liczby wymagających systemów – najzwyczajniej kiedyś te IO się skończą. Aby przewidzieć, kiedy taka sytuacja może nastąpić, należy posłużyć się kilkoma podstawowymi licznikami:

Średni czas odczytu/zapisu z dysku. A w zasadzie to jest czas, jaki musi czekać dane żądanie na dostarczenie/zapisanie danych. Gdy ten będzie on oscylował w granicach 15 ms, nie jest jeszcze źle, ale już powinniśmy zacząć analizować zapytania powodujące liczne odczyty (bo to przeważnie odczyty będą częściej nas alarmowały niż zapisy). Jeżeli nie jesteśmy wstanie nic poprawić, być może warto zacząć analizować zakup wydajniejszych dysków.

Przykład: 5 lipca 2017 roku w głównym systemie jednego z naszych klientów zakończyła się migracja macierzy ze zwykłych dysków „talerzowych” na SSD (IBM V7000). To, że system „nabrał oddechu”, widać było od samego początku – czasy procedur składowanych w niektórych wypadkach poprawiły się kilkukrotnie, spadła liczba timeoutów, system zauważalnie przyśpieszył. To samo pokazał monitoring dysków:

Jak widać, przyśpieszenie było imponujące. Nowe maksima praktycznie zrównały się z poprzednimi minimami!

To chyba jedyne liczniki, dla których możemy jasno określić poziom alertu, bez względu na konfigurację dysków w naszej infrastrukturze. Jeśli chodzi o wydajność, tak jest oczywiście. Jednak poza wydajnością naszych dysków interesować powinna nas również dostępna przestrzeń:

Powyższe liczniki wzajemnie się uzupełniają, ponieważ dla małych dysków pierwszy zaświeci się czujnik Free Megabytes, który w przypadku kilku terabajtowych dysków alarmowałby za późno przy takim ustawieniu progu. I właśnie dlatego ustawiamy dodatkowo licznik procentowy, który przy 2TB przestrzeni zacznie monitować, gdy zostanie około 100 GB wolnego miejsca.

Alerty powinny zaświecić się natychmiast bez względu na to, czy sytuacja zdarzyła w nocy czy w czasie godzin pracy biznesu. Szczególnie ważne jest także raportowanie na maila takich zdarzeń. Wyobraźmy sobie mechanizm backupu baz na dysk, który dopiero po wykonanym bieżącym backupie usuwa poprzednie wersje kopii. Taka operacja przeważnie przebiega w nocy, kiedy nikt nie patrzy na monitoring. Gdyby podczas wykonywania kopii nie wysłalibyśmy wiadomości o kończącym się miejscu na dysku, rano nic by na to nie wskazywało, ponieważ następny krok mechanizmu usunąłby stare dane. Pewnie dowiedzielibyśmy się o takim zdarzeniu dopiero wtedy, gdyby backup zakończył się błędem. Tymczasem w skrzynce rano zobaczymy coś takiego:

O godzinie 1:15 przyszło powiadomienie, że miejsce się kończy (tutaj próg był ustawiony na < 1650 MB):

Zaledwie siedem minut później było już w porządku:

Dzięki temu wiemy, że miejsce na dysku się kończy i możemy w porę zareagować.

A oto inne liczniki związane z dyskami, które warto zbierać do ewentualnej analizy lub do tworzenia linii bazowej:

Sieć

W przypadku liczników dotyczących sieci sprawa wydaje się stosunkowo prosta. Musimy mieć tylko zmierzoną przepustowość interfejsów sieciowych, a w razie jakichś problemów dane mogą okazać się przydatne do badania okoliczności awarii. Możemy ustawiać różne alerty, np. mające na celu wykrycie sytuacji, że ktoś robi pełny backup po LAN w środku dnia pracy. Musimy jednak uwzględnić również fakt, że backupy logów transakcyjnych także mogą nam wygenerować spore piki na interfejsach sieciowych. Ja w każdym razie zbieram poniższe liczniki tylko do linii bazowej.

Do liczników powiązanych z siecią dodałbym natomiast jeden licznik z Wait’ów:

Najczęstsza przyczyna tego typu oczekiwań to sytuacja, w której klient nie jest w stanie odebrać danych, jakich zażyczył sobie od naszej instancji. Innymi słowy, mówiąc bardzo obrazowo, „zapchał się” danymi albo jego usługa „padła”. Licznik ten może również wskazać sytuację, w której klient zaczytuje dane do kesza aplikacj, co ma na przykład miejsce podczas restartu aplikacji typu klient – serwer. Sam  używam z powodzeniem tego licznika do diagnozowania problemów właśnie po stronie aplikacji (sesje na bazie będą miały oczekiwania typu Async Network IO):

O wiele rzadziej wskazuje on na rzeczywiste problemy z siecią, jednak ze względu na nazwę wylądował on właśnie w tym rozdziale.

Większość przedstawionych liczników opisywała kondycję systemu operacyjnego (oprócz liczników memory i wspomnianego przed chwilą Network IO waits). Teraz zajmiemy się licznikami stricte SQL’owymi. Zaczniemy od blokad, zatrzasków i zakleszczeń.

Blokady i oczekiwania

Ideą relacyjnych baz danych jest udostępnienie użytkownikowi wszystkich wymaganych danych w taki sposób, by myślał, iż jest jedynym, a przynajmniej uprzywilejowanym, użytkownikiem instancji bazy danych, którego żądania są spełniane niemal natychmiast. Jednak ta idea kłóci się z rzeczywistością, bo przeważnie równie istotna jak dostępność jest spójność danych. Tę z kolei zapewnia szereg mechanizmów, mogących spowodować spadek dostępności. Są to między innymi blokady użytkownika, które dbają o logiczną spójność danych (inaczej mówiąc, dbają o integralność transakcji) oraz zatrzaski, które pilnują fizycznej spójności danych. Są to zatem mechanizmy pożądane, ale tylko wtedy, gdy nie trwają zbyt długo. Jak zatem wykryć nieprawidłowości?

Jednym z podstawowych liczników dla blokad jest średni czas oczekiwania na blokadę (w ms). Generalnie blokady powinny być krótkie, rzędu kilku milisekund lub mniej. Jednak zdarza się, że „grubszy” skrypt lub zapytanie z aplikacji potrafi przytrzymać tę blokadę na dłużej. Inny proces chcący założyć niekompatybilną blokadę na dany zasób musi czekać. Wydaje mi się, że poniższy próg ustawiony na 15 sekund eliminuje sporo fałszywych alarmów związanych właśnie z takimi sytuacjami. Jeżeli taka średnia utrzymuje się już ponad 5 minut, oznacza to, że w systemie pojawiła się sesja, która – blokując zasoby –powoduje przestoje na bazie.

Natomiast dla zatrzasków równie reprezentatywny jest licznik opisujący średni oczekiwania na zatrzask w milisekundach:

Jak widać, podejście do zatrzasków jest bardziej restrykcyjne niż w przypadku blokad. Z doświadczenia wiem, że w zasadzie próg 5 ms zależy od obciążenia systemu, czyli od liczby i długości transakcji na sekundę. Wybitnie obciążone systemy mogą stale mieć ten próg powyżej 5 ms. Są również systemy, które nie przekraczają 1 ms, a wartość powyżej 2 ms świadczy już o problemach w środowisku. Ja przyjąłem 5 ms jako wartość uniwersalną, przeznaczoną do korekty po zrobieniu kilkutygodniowej linii bazowej.

Ostatnim z liczników, dla których należałoby ustawić powiadomienie o przekroczeniu progu, jest  liczba zakleszczeń na sekundę:

Generalnie ten rodzaj blokad z punktu widzenia administratora jest najmniej uciążliwy. Dlaczego? Ponieważ z założenia zakleszczenia nie powinny trwać dłużej niż 5 sekund zanim zostaną rozwiązane. Odpowiedni proces systemowy sam wybierze więc spośród zakleszczonych sesji tę mniej kosztowną do wycofania i ją przerwie. Ponadto zakleszczenia przeważnie wskazują na problem jakości kodu a nie na typowe problemy administracyjne wynikające na przykład z braku zasobów. Tutaj zakładamy optymistycznie, że deadlocki się nie pojawiają, ale jak to w życiu bywa, są systemy, gdzie takie rzeczy to norma. Próg ten musimy więc odpowiednio zwiększyć.

Co jeszcze warto zbierać do linii bazowej? Jeśli chodzi o blokady i zatrzaski, jest tego całkiem sporo:

Metody składowania i dostępu do danych

Wiedza o tym, co nasza instancja baz danych robi, aby składować lub pobierać dane, jest bardzo cenna. Szczególnie istotne mogą być informacje na temat trendów lub nagłych zmian w tych sposobach. Może się na przykład zdarzyć tak, że system regularnie spowalnia zaraz po okienkach przeznaczonych na konserwację baz danych, w tym na przebudowę indeksów. Analiza jednego z poniżej zaprezentowanych liczników pozwoli wykluczyć lub potwierdzić sytuację, w której jedna z opcji przebudowy indeksów jest niepoprawnie ustawiona. Wystarczy mianowicie, że często aktualizowany indeks przebudujemy z opcją Fill Factor ustawioną na 100, a licznik Page Splits/sec zacznie nam iść w górę.

Jeszcze jeden przykład: poniżej widoczny problem z Full Scan’ami – normą na tym systemie było nieco ponad 1000 skanów na sekundę. Widać tu ewidentny wzrost podczas wykonywania jednej z procedur składowanych (dalsza analiza wykazała nieoptymalny plan tej procedury).

A teraz pora na …

Bazy Danych

Ten zestaw liczników pozwoli śledzić konkretne bazy na naszej instancji. Analizowanie liczników poszczególnych baz to jak tzw. drilldowning naszego monitoringu. Można powiedzieć, że w dużym środowisku ze sporą ilością baz (>=10) wskazanie bazy odpowiedzialnej za problemy to połowa sukcesu.

Niezwykle czułym punktem naszej bazy jest log transakcyjny, szczególnie w bazach z modelem odtwarzania danych FULL. Brak miejsca w logu transakcyjnym jest równoznaczne z wycofywaniem transakcji. Szczególną uwagę trzeba zatem zwrócić na ten licznik:

Procentowe zapełnienie loga transakcyjnego z ustawionym progiem alarmu na 90% powinno nas odpowiednio wcześnie powiadomić o możliwym problemie. Oczywiście zakładamy, że rozmiar loga został wcześniej obliczony i ustawiony ręcznie.

A co zbierać do linii bazowej?

Poniżej widać przykładową charakterystykę danych w logu transakcyjnym dla bazy, której logi backupowane są co godzinę:

Wykres ten doskonale pokazuje, o której dla tej bazy zaczyna się wzmożona praca.

Statystyki

Pora na zestaw liczników, które pomogą określić nominalne obciążenie poszczególnych baz danych. To dzięki nim, patrząc równolegle na CPU czy dyski, będziemy wiedzieć, czy wzrost utylizacji zasobów nie jest czasem spowodowany większą ilością obrabianych danych. Wiadomo, że są okresy w pracy naszych systemów biznesowych, w których łączy się do instancji większa liczba klientów lub w których rośnie ilość zamówień czy zakładanych polis. My chcemy wiedzieć, czy ma to odzwierciedlenie w informacjach o kondycji instancji. Gdy będziemy to wiedzieć, łatwiej będzie wyjaśniać nieoczywiste problemy i spowolnienia. Innymi słowy stawiamy pytanie: czy wzrost CPU o 30% wynika ze wzrostu ilości transakcji czy może musimy zacząć szukać nieoptymalnych planów zapytań?

Wbrew pozorom nie zawsze jest łatwo to zdiagnozować, bo rzadko przekłada się to w stosunku 1 do 1. Pomocne okazuje się zbieranie również liczników biznesowych, takich jak wolumen sprzedaży za dany okres itp. Jednak nawet bez informacji z biznesu wiedza na poziomie instancji będzie bezcenna.

Statystyki dotyczące liczby użytkowników i operacji logowań zaczną nam się zmieniać w przypadku problemów wydajnościowych. Wynika to z prostej zależności: spowolnione, czyli dłuższe wykonywanie się zapytań spowoduje dłuższe utrzymywanie sesji na bazie. Szybko pojawi się efekt lawinowy, ponieważ dodatkowe sesje jeszcze bardziej dociążą bazę. Jednocześnie spadnie nam liczba zapytań na sekundę. To wszystko zostanie ładnie odzwierciedlone w powyższych statystykach.

Transakcje

To już ostatnia grupa liczników, jaką opisuję w tym artykule. Służą one do monitorowania liczby aktywnych transakcji na naszej instancji. Przedstawione poniżej liczniki szczególnie badają wpływ tych transakcji na bazę tempdb, gdy przynajmniej jedna z naszych baz jest przestawiona w tryb wersjonowania wierszy. Jak wiemy, baza tempdb przechowuje nie tylko obiekty użytkowników w postaci tabel tymczasowych czy zmiennych tabelarycznych, ale służy również jako magazyn wersji dla baz pracujących na poziomie izolacji transakcji READ COMMITTED SNAPSHOT lub ALLOW SNAPSHOT ISOLATION. Gdy mamy takie bazy na naszej instancji, powinniśmy śledzić poniższe liczniki:

Licznik ten pokazuje, ile wolnej przestrzeni mamy w bazie tempdb w KB. Zakładamy, że docelową wielkość plików bazy tempdb mamy już wcześniej obliczoną i ustawioną. Jest to bardzo przydatny licznik nie tylko dla baz w trybie wersjonowania wierszy.

Do linii bazowej przydadzą się również:

O tym, jak istotne są opisane w tym rozdziale liczniki, niech poświadczy poniższy przykład. Pewnego dnia, na jednej z kluczowych instancji naszego klienta, zapaliła się właśnie kontrolka na Free Space in tempdb. Analiza wykazała, że jedna z sesji na bazie, pracującej na poziomie izolacji transakcji READ COMMITTED SNAPSHOT, nie zatwierdziła ani nie wycofała swojej transakcji na dużej liczbie  rekordów. W efekcie magazyn wersji zaczął zajmować coraz większą przestrzeń w bazie tempdb:

Skąd było wiadomo, że to był magazyn wersji? Między innymi ze wskazań opisanych liczników. Jak widać na poniższym zrzucie, w pewnym momencie zajmował prawie 40 GB przestrzeni. Natomiast po zabiciu feralnej sesji od razu ją zwolnił:

No dobrze. Wydaje się, że mamy pełen zestaw liczników do monitorowania naszej instancji SQL Server. Jest ich blisko sto. Czy to wystarczy? Uważam, że dla większości przypadków tak. Jednak każdorazowe wrzucanie do Performance Counters nawet kilkunastu liczników, już po dwóch opomiarowanych hostach, okaże się uciążliwe. Jak zatem uzyskać efekt automatyzacji?

Logman

Logman jest windowsowym programem uruchamianym z linii poleceń, który służy między innym do zarządzania licznikami wydajności. Można za jego pomocą utworzyć, uruchomić, zatrzymać oraz skasować taki zestaw liczników. Co istotne, można to zrobić na zdalnym hoście, wystarczy mieć do tego odpowiednie uprawnienia (konto musi należeć do grupy Performance Monitor Users).

Składnia do założenia kolekcji liczników jest bardzo prosta:

1
logman create counter MonitorSQL -s Host -f SQL -o DSNName -cf "C:\countersALL.config"

gdzie poszczególne parametry to:

MonitorSQL – nazwa naszej kolekcji liczników,

-s Host – nazwa DNS lub IP hosta, na którym zakładamy liczniki,

-f SQL – format, w jakim dane mają być zbierane (SQL – wrzucane bezpośrednio do bazy),

-o DSNName – nazwa systemowego DSN, który wskazuje konkretną bazę danych przechowującą liczniki (patrz: http://blog.atena.pl/sql-server-administration-stworz-wlasny-monitoring-baz-danych, rozdział ODBC),

-cf „C:\countersALL.config” – ścieżka do szablonu liczników.

Jedyną rzeczą, której nam brakuje, to wskazany w ostatnim parametrze szablon liczników. Aby go stworzyć ,możemy posłużyć się dołączonym do tego artykułu arkuszem excela:

https://github.com/miros72/MonitoringRepositoryCounters/blob/master/PerformanceCounters.xlsx

Arkusz zawiera opisane w tym artykule liczniki wraz z krótkim opisem, zalecanymi progami do monitorowania oraz szablonami dla instancji domyślnych i nazwanych.

U góry arkusza wpisujemy nazwę hosta, dla którego instalujemy liczniki, oraz nazwę instancji, którą możemy pominąć w przypadku instancji domyślnej:

Teraz wystarczy zaznaczyć właściwą kolumnę szablonu (bez nagłówka) i skopiować do pustego pliku tekstowego, który zapisujemy jako np. countersALL.config:

Następnie z linii poleceń uruchamiamy przygotowaną instrukcję logman’a:

Możemy teraz go uruchomić, a później zatrzymać za pomocą standardowego interfejsu lub za pomocą logman’a:

Świetna sprawa! Z jednego miejsca w sieci możemy zarządzać wszystkimi kolekcjami naszych liczników. Nic nie stoi na przeszkodzie, aby porobić sobie skrypty, które będą zatrzymywać lub uruchamiać całe grupy liczników, np. podczas przerw serwisowych, kiedy z jakichś powodów będziemy musieli wyłączyć hosty z naszymi instancjami. Oczywiście omija nas przy tym proces żmudnego definiowania liczników z poziomu interfejsu.

Czas na wykresy!

Mam nadzieję, artykułem tym zachęciłem do proaktywnego monitorowania instancji baz danych. Oczywiście, nie wyczerpałem tematu, jeśli chodzi o liczniki wydajności systemu Windows i SQL Server. Uważam wręcz, że zaprezentowany zestaw liczników to podstawa służąca do wstępnego rozpoznania problemów na naszej instancji. Sprawdzi się również do robienia linii bazowej. Ale to mój subiektywny wybór, zdeterminowany specyfiką środowisk pozostających pod moją opieką. Jak to w życiu bywa, mogą pojawić się przypadki wymagające głębszej analizy oraz zaprzęgnięcia do działania kolejnych liczników i –co wydaje się oczywiste – użycia widoków dynamicznych po stronie MS SQL’a.

W każdym razie zebrane dane to także wspaniały materiał do zaprezentowania ich w formie graficznej. Tym bardziej, że wykresy pozwalają trafniej i szybciej diagnozować ewentualne problemy, szczególnie wtedy, gdy zostaną z sobą w umiejętny sposób zestawione. Jak to zrobić za pomocą Reporting Services lub Power BI Desktop? Wkrótce zapraszam do kolejnej części SQL Server Administration: Stwórz własny monitoring baz danych – część 3: Wykresy.

Kod:

https://github.com/miros72/MonitoringRepositoryCounters

https://github.com/miros72/MonitoringRepositoryCounters/blob/master/PerformanceCounters.xlsx

Źródła:

https://docs.microsoft.com/en-us/sql/relational-databases/performance-monitor/sql-server-plan-cache-object

https://technet.microsoft.com/en-us/library/bb490956.aspx

Poniżej również artykuły Mileny Petrovic – polecam wszystkie 6 części:

SQL Server memory performance metrics – Part 1 – Memory pages/sec and Memory page faults/sec


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

2 komentarzy do “SQL Server Administration: Stwórz własny monitoring baz danych! Część 2 – Performance Counters