Jako DBA rozwiązywanie problemów z wydajnością jest często wydarzeniem reaktywnym; pojawi się problem, musisz zareagować. Czasami patrzysz na instancję SQL Server, którą dobrze znasz, innym razem może to być Twoje pierwsze spotkanie ze środowiskiem. Dzieje się tak również w świecie konsultingu. Pomagając klientowi długoterminowemu, mam już zapisane szczegóły dotyczące środowiska. Jednak gdy otrzymujemy wiadomość e-mail od kogoś, z kim wcześniej nie współpracowaliśmy, i jest to sytuacja awaryjna, w której osoba ta potrzebuje natychmiastowej pomocy, nie mamy pojęcia o środowisku i nie mamy pojęcia, w co się wkraczamy. Zapewniamy pomoc bez przechodzenia przez rozległy proces zbierania i analizy danych, który rozpoczyna każde nowe zaangażowanie klienta.
Z tego powodu mam zestaw pięciu elementów, które sprawdzam natychmiast, gdy konfrontuję się z nowym środowiskiem. Zbierane przeze mnie informacje stanowią podstawę do tego, jak podchodzę do rozwiązywania problemów w przyszłości, i chociaż rzadko wskazują, NAJLEPIEJ konkretny problem, pomaga mi wykluczyć to, co NIE problem, który czasami jest równie ważny.
Metody zbierania danych
Zdaję sobie sprawę, że każdy ma inne podejście do radzenia sobie z nowym środowiskiem. Istnieje kilka darmowych, powszechnie dostępnych skryptów, które można pobrać i uruchomić, aby określić „ukształtowanie terenu” dla instancji SQL Server (przychodzą mi na myśl skrypty DMV firmy Glenn Berry). Nie skupiamy się tutaj na jak zbierasz dane, to co zbierane dane i to, co analizujesz najpierw .
Właściwości serwera
Pierwszą rzeczą, którą chcę wiedzieć, kiedy patrzę na instancję, jest wersja i edycja SQL Server. Najszybszym sposobem uzyskania tych informacji jest wykonanie:
SELECT @@VERSION;
Dzięki tym wynikom mogę sprawdzić kompilację, aby określić zastosowane dodatki Service Pack, aktualizacje zbiorcze i poprawki, a także wiem, jaka edycja jest używana. Lubię też wiedzieć, czy instancja jest klastrowana, więc wykonuję również:
SELECT SERVERPROPERTY('IsClustered'); Czasami otrzymuję te informacje od klienta, ale weryfikacja nigdy nie zaszkodzi, ponieważ wersja i wydanie mogą wpłynąć na kolejne kroki rozwiązywania problemów i zalecenia. Na przykład klient niedawno skontaktował się z nami w sprawie sporadycznych problemów z wydajnością, które napotkał w programie SQL Server 2008. Szybkie sprawdzenie wersji ujawniło, że korzysta z dodatku SP3 dla programu SQL Server 2008, a po dodatku SP3 wydano kilka aktualizacji zbiorczych, które dotyczyły szeregu problemy z wydajnością. Chociaż zebrałem więcej informacji przed wydaniem zalecenia, aby zastosować najnowszą CU, była to natychmiastowa czerwona flaga, co może być przyczyną problemu.
konfiguracje.sys
Ten widok katalogu pomaga budować na fundamencie rozpoczętym od właściwości serwera i pomaga nam zrozumieć, jak skonfigurowana jest instancja. W tym widoku szukam ustawień, które zostały zmienione od domyślnych, ale nie powinny, oraz tych, które nie został zmodyfikowany, ale powinien.
SELECT [name], [value], [value_in_use], [description] FROM [sys].[configurations] ORDER BY [name];
Rozważ ustawienie maksymalnej pamięci serwera (MB), które ogranicza ilość pamięci dostępnej dla puli buforów. Wartość domyślna to 2147483647, ale należy ją zmienić na wartość mniejszą niż całkowita pamięć na serwerze, aby zapewnić wystarczającą ilość pamięci dla systemu operacyjnego, innych aplikacji i innych zadań programu SQL Server, które wymagają pamięci niepobranej z puli buforów . Aby uzyskać wskazówki dotyczące ustawiania odpowiedniej wartości dla maksymalnej pamięci serwera (MB), polecam post Jonathana:Ile pamięci faktycznie potrzebuje mój SQL Server?
I odwrotnie, ustawienie zwiększania priorytetu ma wartość domyślną zero i zawsze powinno być pozostawione jako takie. W rzeczywistości Microsoft zaleca, aby tego nie zmieniać, a opcja zostanie usunięta w przyszłej wersji SQL Server.
bazy danych sys.
Po zrozumieniu konfiguracji instancji, następnie sprawdzam, co istnieje na poziomie bazy danych.
SELECT * FROM [sys].[databases] ORDER BY [database_id];
Kiedy sprawdzam dane wyjściowe tego widoku katalogu, szukam w danych antywzorców — wszystkiego, co wydaje się nieoczekiwane lub nietypowe. Dane wyjściowe sprzyjają szybkiej analizie — wiele ustawień podaje wartość 0 lub 1 (wyłączone lub włączone), a ja odnotowuję w pamięci, co się zmieniło. Spodziewam się, że statystyki automatycznego tworzenia i statystyki automatycznej aktualizacji będą włączone (ustawione na 1). Oczekuję, że automatyczne zamykanie i automatyczne zmniejszanie będą wyłączone (ustawione na 0). Sprawdzam, jakie jest sortowanie dla baz danych użytkowników, a konkretnie, czy wszystkie mają to samo sortowanie i czy to sortowanie jest takie samo jak tempdb. Zwracam również uwagę na opcje bezpieczeństwa, takie jak łańcuchowanie między bazami danych i opcja is_trustworthy, obie domyślnie wyłączone (0). Jeśli stwierdzę, że którekolwiek z tych ustawień odbiega od oczekiwań, odnotowuję to i idę dalej. W żadnym momencie nie przerywam zbierania lub analizowania, aby dokonać zmiany, ponieważ po prostu zbieram informacje tak szybko, jak tylko mogę, aby dobrze zrozumieć środowisko.
Oprócz sprawdzenia ustawień dla baz danych, zwracam również uwagę na liczbę baz danych użytkowników. Nie ma „właściwej liczby” baz danych użytkowników dla instancji – instancja może działać słabo z jedną bazą danych i może działać wspaniale z 100. Istnieje mnóstwo czynników, a liczba baz danych to po prostu punkt danych warte uwagi.
Dzienniki błędów
Przyznaję, kiedyś zaniedbywałem SQL Server ERRORLOG; to było jak refleksja, kiedy badałem problem z SQL Serverem. Wtedy zdałem sobie sprawę z błędu moich dróg i od tego czasu nie uważałem tego za pewnik. Zwykle poruszam się po Management Studio, aby uzyskać dostęp do dziennika (w Management | SQL Server Logs), chociaż możesz użyć procedury składowanej sp_readerrorlog lub przejść do pliku i otworzyć go w swoim ulubionym edytorze tekstu.
W ERRORLOG szukam ostatnich błędów – na przykład wszystkiego związanego z pamięcią – a także sprawdzam, jakie flagi śledzenia, jeśli w ogóle, są używane. Sprawdzam również, czy opcja Zablokuj strony w pamięci jest włączona, czy pamięć podręczna jest opróżniana (celowo lub nie) i czy regularnie występują inne nietypowe czynności. W zależności od tego, jak pilny jest problem, patrzę również na dzienniki systemu Windows (zdarzenia, aplikacje i zabezpieczenia), ponownie szukając nie tylko błędów, ale także nieoczekiwanych wzorców wiadomości.
Statystyki oczekiwania
Ostatnim obszarem SQL Server, który przeglądam, patrząc na problem z wydajnością nieznanej instancji, są statystyki oczekiwania. Każda instancja SQL Server będzie musiała czekać — bez względu na to, jak dobrze dostrojony jest kod, bez względu na to, ile sprzętu stoi za nim. Jako administrator baz danych chcesz wiedzieć, jakie są Twoje typowe oczekiwania na instancję, a kiedy patrzę na nowe środowisko, nie od razu wiem, czy oczekiwania, które widzę, są typowe, czy też wynikają z problemu z wydajnością. Pytam klienta, czy ma bazowe statystyki oczekiwania, a jeśli nie, pytam, czy mogę je wyczyścić i pozwolić im zacząć się gromadzić, gdy wystąpi problem z wydajnością. Aby sprawdzić statystyki oczekiwania, możesz użyć skryptu w często cytowanym poście Paula Randala lub wersji w zapytaniach DMV Glenna.
Po przejrzeniu skumulowanych statystyk oczekiwania uzyskasz ostatni element, który zapewnia „pełny obraz” instancji SQL Server oraz informacje potrzebne do rozpoczęcia rozwiązywania problemów. Często zdarza się, że podczas rozwiązywania problemów najpierw sprawdza się statystyki oczekiwania, ale samo czekanie nie jest wystarczającym źródłem informacji, aby określić, co należy dalej zbadać, chyba że rozumiesz również podstawową konfigurację SQL Server.
Dalsze kroki
Jak wspomniałem wcześniej, zazwyczaj nie ma jednego elementu danych, który mówi, gdzie leży problem z wydajnością, to wiele uzyskanych punktów danych wskazuje właściwy kierunek. To, w jaki sposób przechwycisz te informacje, zależy od Ciebie, ale po przejrzeniu wyników powinieneś dobrze zrozumieć, jak skonfigurowane jest środowisko SQL Server, a ta wiedza, w połączeniu ze statystykami oczekiwania, może pomóc Ci zdecydować, co dalej badać. Rozwiązywanie problemów działa najlepiej przy metodycznym podejściu, więc zacznij od podstaw i pracuj dalej, a kiedy uznasz, że udało Ci się ustalić przyczynę, poszukaj jeszcze trochę i znajdź jeden lub dwa dodatkowe dowody, które wspierają Twoje odkrycie. Po uzyskaniu tych danych możesz wydać zalecenie, które pomoże ulepszyć lub rozwiązać problem.
