SQL Server Administration: Stwórz własny monitoring baz danych!


Monitoring to podstawa

Czy jako administrator baz danych zetknąłeś się z pytaniem: czy z bazą wszystko OK? Pytanie takie zwykle pada, kiedy użytkownicy aplikacji zauważają spowolnienia w pracy systemu. I jak to w takich sytuacjach bywa, trzeba znaleźć przyczynę. Właśnie diagnoza jest największym wyzwaniem: rozpoznanie, czy bieżący stan bazy danych jest przyczyną, czy raczej skutkiem powstałych problemów?

Nawet jeśli mamy pełne dane o stanie naszej instancji, nie jest łatwo postawić właściwą diagnozę. A będzie o wiele trudniej, gdy nie będziemy dysponować bieżącymi i historycznymi wskazaniami liczników systemu. Wówczas poruszalibyśmy się raczej w sferze wróżb i horoskopów. Natomiast szczegółowy monitoring pozwoli w pewnych sytuacjach z pełną odpowiedzialnością od razu odpowiedzieć: po stronie baz danych – wszystko jest w normie! Albo i nie jest…

No właśnie – co to znaczy, że wszystko jest albo nie jest w normie? Nie odpowiemy na to pytanie bez wskazań liczników w czasie, gdy aplikacja działała poprawnie, bo po prostu nie będziemy mieli do czego się odnieść. To jest właśnie podstawowa funkcja monitoringu – linia bazowa. Chcemy wiedzieć, czy na przykład rosnąca utylizacja procesora w godzinach od 12:00 do 12:15 to norma czy raczej symptomy zbliżającej się awarii. Taka wiedza dla dobrego administratora baz danych jest bezcenna. Nierzadko da mu czas, by zareagować, zanim użytkownik spostrzeże, że aplikacja spowolniła…

Ponadto, w trudniejszych przypadkach historyczne dane pozwolą spokojnie diagnozować zdarzenia po awarii, a gdy połączymy siły z innymi zespołami – np. z zespołem opiekującym się systemami operacyjnymi, siecią czy macierzami dyskowymi – umożliwią pełną analizę po stronie infrastruktury.

Dlatego też monitoring obejmujący instancję bazy danych powinien być permanentny i kompletny, czyli obejmować wiele poziomów. W przypadku MSSQL chodzi o następujące elementy:

  1. Zbieranie i bieżąca analiza liczników systemu operacyjnego, na którym działa nasza instancja (CPU, Pamięć, dyski, sieć).
  2. Zbieranie i bieżąca analiza liczników instancji baz danych (waity, latche, locki, statystyki baz, transakcje itp.).
  3. Cykliczne sprawdzanie errorloga.
  4. Stałe trace’y lub lepiej stałe sesje Extended Events dla wybranych zdarzeń, a następnie ich raportowanie oraz analiza.
  5. Krótkie, pełne trace’y lub lepiej sesje Extended Events dla stworzenia linii bazowej zapytań.
  6. Okresowy zrzut z wybranych widoków lub funkcji dynamicznych (np. z sys.dm_db_index_operational_stats) w celu wybrania np. momentu do przebudowy indeksów.

Oczywiście, na rynku są dostępne komercyjne narzędzia do monitoringu baz danych, które robią  to kompleksowo. Jednak, po pierwsze, dobre systemy monitorujące nie są tanie. Po drugie: niekoniecznie spełnią wszystkie nasze oczekiwania, a po trzecie: tworząc własny monitoring, możemy się sporo nauczyć. Poza tym wcale nie jest to takie trudne, co chciałbym udowodnić w tym artykule podczas realizacji punktów 1 i 2: ustawienia mechanizmu do zbierania liczników Performance Counters z poziomu systemu operacyjnego Windows.

Baza liczników

Na początku musimy się zastanowić, gdzie chcemy trzymać nasze dane z Performance Counters. Naturalnym miejscem składowania wydaje się baza danych, najlepiej na dedykowanej do tej roli instancji SQL Server. Możemy użyć już istniejącej instalacji, ale lepszym rozwiązaniem będzie postawienie osobnych binarek SQL’a. Zakładając, że monitoring będzie obejmował więcej systemów, rekomenduję założenie dla każdego systemu lub hosta osobnej bazy z licznikami. Nazwijmy naszą instancję MONITORSQL1, natomiast poszczególne bazy liczników – host1_counters, host2_counters itd. Schemat całego mechanizmu będzie wyglądał następująco:

W ramach jednej bazy pomiarów można trzymać informacje o jednym lub więcej hostach, a także o jednej lub więcej instancjach SQL Server. Jak to będziemy robić – to już zależy od nas. Ja przyjąłem zasadę, że w jednej bazie pomiarów trzymam liczniki hostów i instancji powiązanych biznesowo. Tworzę więc na przykład jedną bazę pomiarów dla systemu sprzedażowego obejmującego, załóżmy, 2 hosty i 3 instancje bazy danych.

Do obsługi około 20 baz pomiarów w zupełności wystarczy nam darmowa wersja SQL Server 2016, czyli edycja Express. Gdy będziemy chcieli monitorować większą liczbę hostów i instancji, zalecam posadowienie baz pomiarów na edycji Standard. Ale to też zależy nie tylko od liczby monitorowanych systemów, ale również od liczby i częstotliwości zrzucanych liczników na system oraz od czasu, przez jaki będziemy trzymać archiwalne dane. Wrócimy jeszcze do tej kwestii pod koniec artykułu, gdzie postaramy się oszacować wagę zbieranych danych.

W każdym razie, jeżeli nasz wybór padnie na edycję Express i będzie to całkiem nowa instalacja  dedykowana monitoringowi, pamiętajmy, aby podczas instalacji, poza silnikiem bazy danych, wybrać również usługę Reporting Services (w trzeciej części artykułu pokażę, jak wykorzystać SSRS do wizualizacji zebranych danych):

W naszym przykładzie zdecydowałem się również na instancję domyślną, więc komunikacja z bazą będzie odbywała się po standardowym dla SQL Server’a porcie TCP: 1433.

Instancję mamy przygotowaną, pora zatem założyć pierwszą bazę liczników. Jako pierwszy system podłączymy naszego hosta MONITORSQL1 wraz default’ową instancją SQL Server. Zgodnie z wcześniej przedstawionym schematem baza danych będzie miała nazwę MONITORSQL1_counters:

Baza na razie jest pusta, nie zawiera żadnych struktur poza obiektami systemowymi. Teraz zdefiniujemy listę liczników, które będą zasilały naszą bazę pomiarów.

Performance Counters

Instancja MONITORSQL1 jest postawiona na Windows 2012 R2 Datacenter, więc liczniki znajdziemy, wpisując po prostu Performance Monitor:

W Perfomance Monitorze rozwijamy ścieżkę Data Collector Sets à User Defined i klikamy na nim prawym przyciskiem myszy, wybierając New à Data Collector Set:

Na następnym ekranie wpisujemy nazwę naszego licznika – Monitoring – oraz wybieramy Create manually:

Następnie zaznaczamy Create data logs i Performance counter:

W ten sposób stworzyliśmy zestaw liczników, który na razie jest pusty, więc w kolejnym kroku wstawimy do niego kilka podstawowych liczników. Wybieramy nasz zestaw Monitoring i w prawym okienku wchodzimy we właściwości DataCollector01:

W górnej części DataCollector01 Properties widzimy listę liczników (panel Available conters), a poniżej przycisk Add… Klikamy w niego i dodajemy nasz pierwszy licznik: utylizację CPU. W Select counters from computer znajdujemy naszego hosta, zaznaczamy licznik Processor, rozwijamy podlistę liczników, wyszukujemy % Processor Time, zaznaczamy instancję _Total i klikamy Add >>. Licznik pojawi się po prawej stronie dodanych liczników.

W analogiczny sposób dodajmy jeszcze kolejne liczniki:

– ilość wolnego miejsca na dysku C (LogicalDisk -> Free Megabytes -> C),

– średni czas odczytu z dysk C w ms (LogicalDisk -> Avg. Disk sec/Read -> C),

– liczba transakcji na sekundę (SQLServer:Databases -> Transactions/sec -> <All instances>),

– średni czas życia strony w buforze (SQLServer:Buffer Manager -> Page life expectancy).

Potraktujmy te liczniki jako zestaw startowy, potrzebny do tego, aby zrozumieć zasadę działania naszego monitoringu i zrozumieć, jak te dane będą składowane w bazie. Kompletny zestaw liczników, wraz z ich krótkim omówieniem pojawi się w części 2 tego tematu na blogu. Omówię w nim również, w jaki sposób zautomatyzować dodawanie kolejnych zestawów, bo jak pewnie zauważyliście, ręczne dodawanie tych liczników jest zbyt czasochłonne…

W każdym razie, po dodaniu powyższych liczników nasz zestaw startowy powinien się prezentować jak poniżej (panel Added counters):

Klikamy OK i nasz zestaw liczników jest gotowy do uruchomienia. Zanim to jednak zrobimy, musimy skierować go do właściwej bazy danych.

ODBC

W tym celu użyjemy interfejsu ODBC do połączenia z bazą MONITORSQL1_counters na instancji MONITORSQL1. Szukamy źródeł danych w wersji 64-bitowej:

Wchodzimy w zakładkę System DSN i klikamy Add… i dodajemy sterownik SQL Server w wersji 6 (na innych nie zadziała):

W następny oknie wpisujemy nazwę źródła danych, opis i adres docelowego serwera:

W następnym okienku nic nie zmieniamy – czyli pozostawiamy autentykację Windows. Ewentualnie, gdyby w naszej podsieci nazwa serwera monitorującego nie byłaby rozwiązywana, możemy w Client Confifguration… ustawić ręcznie IP oraz port. Jeżeli jednak bez problemu przechodzimy dalej, to w następnym oknie wybieramy tylko domyślną bazę, do której będzie się łączyło nasze źródło danych:

Klikamy Next, Finish i w ostatnim okienku mamy przycisk Test Data Source… Jeżeli wszystko jest OK, to po kliknięciu powinniśmy mieć taki komunikat:

Klikamy dwa razy OK i mamy zdefiniowany interfejs ODBC dla naszych liczników:

Teraz należy go tylko wskazać z poziomu liczników. Wracamy zatem do Performance Monitora, wyszukujemy nasz zestaw Monitoring i wchodzimy we właściwości DataCollector01. Wybieramy Log format: SQL, Sample interval: 20 (liczniki będą zrzucane co 20 sekund) i Data source name: Monitoring:

Klikamy OK i jesteśmy gotowi do zbierania liczników. Wystarczy kliknąć wskazany przycisk PLAY:

Jeżeli nie dostaniemy żadnego błędu, to od tej chwili do naszej bazy danych, co 20 sekund, będzie zrzucany aktualny stan wybranych liczników:

UWAGA: Gdy system zakomunikuje nam poniższy błąd, musimy sprawdzić właściwy komunikat w Application Event Viewerze:

Najczęstszym problemem jest brak uprawnień do połączenia z bazą danych, komunikat wygląda wtedy następująco: Call to SQLAllocConnect failed with [Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user ‚DOMAIN\HOST1$’. Oznacza on, że tożsamość komputera HOST1 w domenie DOMAIN musi zostać uwierzytelniona na naszej instancji monitorującej zanim zrzuci właściwe liczniki. Problem rozwiązujemy, nadając tożsamości tego hosta minimalne uprawnienia dla stworzenia struktury tabel i dla wstawienia danych z liczników. Te minimalne uprawnienia to: db_datareader, db_datawriter oraz db_ddladmin:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
USE [master]
GO
CREATE LOGIN [DOMAIN\HOST1$] FROM WINDOWS WITH DEFAULT_DATABASE=[MONITORSQL1_counters]
GO
USE [MONITORSQL1_counters]
GO
CREATE USER [DOMAIN\HOST1$] FOR LOGIN [DOMAIN\HOST1$]
GO
USE [MONITORSQL1_counters]
GO
ALTER ROLE [db_datareader] ADD MEMBER [DOMAIN\HOST1$]
GO
USE [MONITORSQL1_counters]
GO
ALTER ROLE [db_datawriter] ADD MEMBER [DOMAIN\HOST1$]
GO
USE [MONITORSQL1_counters]
GO
ALTER ROLE [db_ddladmin] ADD MEMBER [DOMAIN\HOST1$]
GO

Struktura bazy pomiarów

Wracamy do naszej bazy pomiarów MONITORSQL1_counters. Pierwsze, poprawne uruchomienie liczników założyło nam całą strukturę, czyli trzy poniższe tabele:

Przyjrzyjmy się poszczególnym tabelom:

DisplayToID – bazowa tabela naszych liczników. Każdy zestaw liczników będzie tu odkładał jeden rekord na każdy uruchomiony Data Collector. Jeżeli w naszym zestawie liczników będziemy mieli więcej Data Collectorów, znajdziemy ich nazwy właśnie w tej tabeli, w kolumnie DisplayString. W zasadzie najmniej używana przeze mnie tabela, ale dokładny jej opis można znaleźć na stronach MSDN (link na końcu artykułu).

CounterDetails – tabela opisująca, co tak naprawdę zbieramy. Każdy z liczników dostanie swój identyfikator (CounterID), poza tym interesować nas będą host (MachineName), główny obiekt (ObjectName), licznik (CounterName) oraz konkretne wystąpienie lub, inaczej mówiąc, podgrupa tego licznika, o ile takowa jest możliwa (InstanceName). Brak podgrupy jest widoczny jako NULL. W naszej bazie wygląda to w następujący sposób:

Ostatnia i najważniejsza tabela to CounterData. Będziemy mieli w niej wskazania naszych liczników. Uzyskamy je, robiąc złączenie po kolumnach GUID i CounterID. Gdybyśmy chcieli zrobić schemat logiczny naszej bazy danych, korzystając ze zdefiniowanych przez system kluczy, wyglądałby on następująco:

W połączeniu z RecordIndex wszystkie trzy kolumny są kluczem głównym na tej tabeli. To właśnie RecordIndex zapewnia unikalność tego klucza, bo dla każdego licznika jest wartością narastającą w czasie odkładania się nowych wskazań liczników. Powyższe relacje nie są zdefiniowane automatycznie, ale ich zobrazowanie pomoże nam zbudować zapytania wyciągające konkretne wartości.

Do kompletu potrzebujemy z tej tabeli jeszcze tylko kolumn CounterValue i CounterDateTime. CounterValue zawiera sformatowane wskazanie licznika w danym czasie (CounterDateTime w standardzie UTC). Pozostałe kolumny zawierają surowe, niesformatowane dane, potrzebne w wąskim zakresie zastosowań – dla naszego monitoringu w zupełności wystarczy CounterValue.

Liczniki już jakiś czas się odkładają – zobaczmy zatem, jakie informacje możemy z nich wydobyć.

Przeglądamy dane liczników

Załóżmy, że na początek potrzebujemy ostatnich 10 pomiarów z utylizacji procesora. Nasze zapytanie będzie wyglądało jak poniżej:

Jak widać, nie używamy w złączeniu tabeli DisplayToID. I póki nie mamy dwóch różnych zestawów liczników, z dwóch różnych hostów o tych samych nazwach, to ta tabela nie jest nam potrzebna. Gdyby jednak tak było, musielibyśmy dodatkowo identyfikować dane po polu GUID. Gdy jednak założymy, że baza pomiarów będzie robiona dla grupy hostów powiązanych biznesowo lub aplikacyjnie, o czym pisałem wcześniej, to taka sytuacja się nie zdarzy.

Spróbujmy teraz wyciągnąć średnie, maksymalne i minimalne pomiary z każdej godziny, sięgając od teraz do 24 godzin wstecz. Powstanie przegląd z ostatniej doby z ładnie sformatowanymi wynikami, do dwóch miejsc po przecinku i z liczbą próbek dla każdego zestawu:

Zobaczmy wreszcie, jak można porównać ze sobą dwa analogiczne okresy, czyli kolejne dni w tygodniu w godzinach od 8:00 do 16:00:

Możliwości wykorzystania naszych pomiarów są jeszcze większe. Wykorzystując wbudowane w SQL Servera funkcje okna, możemy szybko policzyć percentyle naszych próbek:

Z powyższego zrzutu wynika, że np. mediana dla 30 stycznia wynosi 0,84% utylizacji CPU, natomiast zaledwie 1% wszystkich próbek przekroczyło wartość 12,30%, co także łatwo sprawdzić:

Mając tak dokładne dane, łatwo będzie analizować różne okresy działania naszej instancji, porównując poszczególne próbki czy obliczone średnie. To nam daje naprawdę duże możliwości w diagnostyce ewentualnych awarii czy w tworzeniu linii bazowej naszego systemu.

Ale jeszcze łatwiej będzie prowadzić diagnozę, gdy te wyniki zobrazujemy. I tu ogranicza nas tylko nasza wyobraźnia. Jest tyle różnych języków programowania, tyle możliwości dają nam komercyjne i darmowe aplikacje do generowania wykresów, że wystarczy tylko trochę czasu przeznaczyć na eksport tych danych do czytelnego dla tych systemów formatu. A przecież mamy do czynienia z danymi przechowywanymi w bazie MS SQL, więc zdecydowana większość aplikacji czy języków ma już gotowe sterowniki przystosowane do łączenia się z tym źródłem. Naprawdę, nic prostszego – wystarczy tylko podstawowa znajomość programowania, a resztę tak naprawdę można wyklikać. 😉

Poniżej przedstawiam kilka print screenów mojej autorskiej aplikacji opartej na Performance Counters, HTML i PHP. Pierwszy zrzut pokazuje, że na jednym ekranie możemy pokazać kilka kluczowych liczników, na przykład z ostatniej godziny, wraz z informacją, jak to się ma do danych z identycznego kresu czasu w dniu poprzednim i sprzed tygodnia. W razie problemów czasami wystarczy jeden rzut oka na ten obraz, by dowiedzieć się, gdzie leży przyczyna spowolnień lub jaki element naszej instancji jest afektowany. Większość tych danych jest brana właśnie z Performance Counters, kilka informacji jest bezpośrednio dociągana z instancji baz danych:

Następny zrzut przedstawia interfejs do podglądu danych historycznych:

Jest to średni czas blokad w godzinach od 8:00 do 9:00 z dwóch tygodni, zagregowany dniami. Z każdego dnia mamy średnią, minimalny oraz maksymalny pomiar. Oczywiście nic nie stoi na przeszkodzie, by podejrzeć sobie na wykresie konkretny dzień:

Na wykresie widać dokładnie intensywność blokad w czasie oraz to, że blokady ustąpiły dokładnie o godzinie 8:35.

Możemy również okresowo sprawdzać, czy wartości liczników nie przekraczają wcześniej zdefiniowanych progów. Jeżeli przekraczają, możemy sobie wyświetlić ranking liczników, których progi są przekroczone i od jakiego czasu:

A na koniec możemy zrobić zbiorczego dashborda z wszystkich kluczowych systemów na jednym ekranie. Fragment takiego ekranu przedstawiam poniżej:

Takie zestawienie wszystkich kluczowych systemów na jednym ekranie bardzo często pomaga w diagnozie problemów o charakterze globalnym, na przykład: spowolnienie na sieci lub na macierzy dyskowej.

Jeżeli do tego dorzucimy system powiadomień drogą meilową (np. o przekroczonych progach), to w zasadzie dwa pierwsze punkty ze wstępu tego artykułu mamy zrealizowane.

Ale do takiej prezentacji danych jeszcze kawałek drogi – wcześniej musimy zadbać o jakość danych w naszej bazie pomiarów.

Konserwacja bazy pomiarów

Czas płynie, liczniki cały czas się zbierają i nagle zauważamy, że nasza baza pomiarów puchnie, a wyszukiwanie i prezentacja danych na monitoringu spowalnia.

Już podczas pisania zapytań wyciągających dane z naszej bazy pomiarów warto zastanawiać się nad indeksami mogącymi przyśpieszyć kwerendy. Na przykład dla zapytań o dane z pewnego zakresu dat przydatny będzie indeks na kolumnie [CounterDateTime] w tabeli [CounterData]. W zasadzie tylko dla tej tabeli będziemy rozważać indeksy, ponieważ [CounterDetails] jest tak mała, że w całości zmieści się na jednej lub dwóch stronach danych.

I tak dla zapytania nr 1 z tego artykułu warto założyć indeks na kolumnie biorącej udział w złączeniu. Aby nie dociągać po kluczu daty i wartości, te dwie kolumny należy dodać w klauzuli INCLUDE:

1
2
3
4
5
6
USE [MONITORSQL1_counters]
GO
CREATE NONCLUSTERED INDEX [IX_CounterID_INCL_TimeAndValue]
ON [dbo].[CounterData] ([CounterID])
INCLUDE ([CounterDateTime],[CounterValue])
GO

To jest wręcz obligatoryjny indeks, zakładając, że tylko te trzy kolumny z tabeli [CounterData] tak naprawdę nas interesują. Do każdego innego zapytania musimy podchodzić indywidualnie i za każdym razem uważnie oglądać plan wykonania. Jednak w większości przypadków ten indeks oraz indeks na kolumnie z datą powinny wystarczyć.

Jak już pisałem, w miarę upływu czasu baza cały czas rośnie, więc warto również pomyśleć o jej regularnym odchudzaniu. Mam tu na myśli cykliczne agregowanie danych pomiarów. I tak na przykład, jeżeli zbieramy liczniki co 20 sekund, to tak dokładne pomiary możemy trzymać np. przez tydzień. Starsze dane możemy agregować do minuty, zachowując średni, minimalny i maksymalny pomiar. Idąc dalej, dane starsze niż miesiąc możemy agregować do 10 minut. Wszystko zależy od tego, jak dużo mamy przestrzeni dyskowej, ile instancji monitorujemy i jak daleko musimy cofać się w czasie, zaglądając do historycznych danych.

Poniżej przedstawiam wielkość naszej bazy po całodobowym zbieraniu liczników według naszego startowego zestawu (czyli 14 liczników zrzucanych co 20 sekund).

To tylko nieco ponad 9 MB. Oczywiście, pełny zestaw będzie odpowiednio większy. Czasem spotkamy też instancje, gdzie ten pełny zestaw trzeba będzie dodatkowo jeszcze powiększyć i gdzie duża liczba dysków oraz duża liczba baz spowoduje, że liczba liczników wzrośnie do kilku tysięcy. Mój osobisty rekord to ponad 5 tysięcy liczników. Dlatego, mimo wszystko, najlepiej liczniki agregować na bieżąco, w innej tabeli lub nawet w innej bazie, a co ustalony interwał czasu (np. o północy) główną tabelę [CounterData] truncate’ować.

Jak zatem powinien wyglądać pełny zestaw liczników? Już wkrótce zapraszam do lektury drugiej części artykułu pod tytułem: Performance Counters dla MS SQL. Natomiast w trzeciej części pokażę, jak wizualizować nasze pomiary za pomocą Reporting Services.

Kod:

https://github.com/miros72/MonitoringRepositoryCounters

Źródła:

https://msdn.microsoft.com/en-us/library/aa373198(v=vs.85).aspx

 


Mirosław Świerk

O Mirosław Świerk

Zawodowo już kilkanaście lat zajmuję się administracją SQL Server, staram się być na bieżąco, co wcale nie jest łatwe, ale lubię również dzielić się zdobytą wiedzą jako trener... Prywatnie natomiast najbardziej lubię rozmawiać z ludźmi (bezpośrednio a nie przez telefon czy Skype'a) oraz jestem fanem Commodorków, Spectrumów czy innych Amstradów ;-)


Dodaj komentarz

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

4 komentarzy do “SQL Server Administration: Stwórz własny monitoring baz danych!

    • Mirosław Świerk
      Mirosław Świerk Autor wpisu

      Założyłem, że czytający artykuł ma już wiedzę na temat administracji bazami danych MS SQL. Ale nawet jeżeli takiej wiedzy nie ma nic nie stoi na przeszkodzie by zainstalować sobie edycję Express i prześledzić krok po kroku cały tekst. Kodu oczywiście nie trzeba przepisywać – jest dostępny na https://github.com/miros72/MonitoringRepositoryCounters. Zachęcam do eksperymentowania 🙂

  • Adrian Chodkowski

    Bardzo fajny artykuł 🙂 Co do jednej sprawy mamy wątpliwość – chodzi mianowicie o fakt zapisywania logów bezpośrednio w bazie: przy krótkim interwałach zbierania danych mogą przez samo ich zapisanie negatywnie wpłynąć na pracę serwera- jak to wygląda w Pana przypadku? Z drugiej zaś strony jeśli nie potrzebujemy danych z OS to można użyć standardowo joba SQL Server Agent i widoku dynamicznego sys.dm_os_performance_counters – dzięki temu trochę mniej pracy:)

    • Mirosław Świerk
      Mirosław Świerk Autor wpisu

      Dziękuję za komentarz!
      Używam regularnie opisanego rozwiązania od blisko 10 lat na kilkudziesięciu instancjach baz danych – wpływ na instancję monitorowaną jest pomijalnie mały. Tym bardziej, że zakładamy, iż baza liczników jest na dedykowanej do tego instancji. Ale nawet, jeżeli te dane byłyby zbierane na instancji monitorowanej, to i tak bardziej to zależy od naszych zapytań analizujących obciążenie (selekty po wynikach). Sam zapis to jest naprawdę szybki BULK INSERT.
      Jeżeli chodzi o widok sys.dm_os_performance_counters:
      Po pierwsze chodzi nam właśnie o zminimalizowanie wpływu naszego monitoringu na instancję monitorowaną, sam select jest po tym widoku z założenia będzie miał większy wpływ niż wbudowane narzędzie Performance Counters, który ma niejako bezpośredni dostęp do tych liczników od strony systemu operacyjnego.
      Po drugie: czy będzie to mniej pracy? Niekoniecznie – przy wysyłaniu liczników z tego widoku na inną instancję musimy posłużyć się na przykład dblinkiem, poza tym musimy sami przygotować strukturę bazy. Natomiast Performance Counters robi to za nas 😉 My musimy tak naprawdę przygotować tylko ODBC.
      Poza tym, część liczników w tym widoku udostępnia dane tylko kumulatywnie. Musimy zatem przed prezentacją je przeliczyć lub robić to na bieżąco.
      Ale po trzecie i najważniejsze – jak Pan zauważył – widok sys.dm_os_performance_counters nie zawiera liczników systemu operacyjnego takich jak CPU, dyski, pamięć i sieć. Jak dla mnie, te liczniki są równie istotne jak liczniki samej instancji baz danych.
      Myślę, że niedługo powstanie druga część tego artykułu, gdzie zamierzam opisać konkretne liczniki, więc zapraszam do śledzenia naszego bloga!