Utrzymanie wysokowydajnych instancji SQL Server to ogromna część obowiązków służbowych administratora baz danych. Brak wykrycia i skorygowania nietypowych działań może wpłynąć na operacje wewnętrzne, a także zaszkodzić wynikom finansowym firmy.
Jeśli zauważysz szczytowe zmiany aktywności lub anomalie w instancji SQL Server, oto trzy miejsca, w których możesz rozpocząć wyszukiwanie odpowiedzi.
Oczekiwana długość życia strony
Oczekiwana długość życia strony instancji (PLE) powinna utrzymywać dość spójny zakres wartości. Jeśli ta wartość spadnie i pozostanie niska, oznacza to, że pula buforów doświadcza zwiększonego zapotrzebowania.
Zanim wyczerpie się pamięć, spójrz na aktywność związaną z obciążeniem. Jeśli obciążenie wzrosło, uwzględniłoby to dodatkowe obciążenie puli buforów. Ale jeśli obciążenie się nie zmieniło, będziesz musiał przyjrzeć się dokładniej, aby określić, co wykorzystuje dodatkową pamięć.
Możliwe przyczyny spadku liczby PLE obejmują aktywne działania konserwacyjne, przebudowy indeksu lub aktualizacje statystyk, operacje DBCC i zmiany w planie zapytań.
Jeśli zauważysz spadek PLE, który nie jest związany ze wzrostem obciążenia, możesz spróbować ulepszyć PLE instancji na kilka sposobów:
- Upuść nieużywane indeksy
- Połącz zduplikowane indeksy
- Uważaj na duże zapytania
- Defragmentuj
- Wyczyść dane
Czas oczekiwania WRITELOG
Gdy czas oczekiwania WRITELOG jest zbyt duży w stosunku do całkowitego czasu oczekiwania, prawdopodobnie masz wąskie gardło w instancji SQL Server. Wąskie gardło jest prawdopodobnie spowodowane problemem na dysku, na którym przechowywany jest dziennik transakcji, lub nieefektywnym wprowadzaniem danych.
Aby określić, z jakim wąskim gardłem masz do czynienia, zacznij od analizy liczby instrukcji SQL oczekujących na zdarzenie WRITELOG. Jeśli czeka na Ciebie wiele wyciągów, masz wąskie gardło dysku. Jeśli czeka tylko kilka instrukcji, prawdopodobnie dane są przekazywane zbyt często.
Istnieje kilka sposobów rozwiązania długiego czasu oczekiwania WRITELOG po ustaleniu, czy wąskie gardło jest związane z dyskiem, czy z zatwierdzeniem:
- Dodaj przepustowość I/O do dysku, na którym przechowywany jest dziennik transakcji
- Przenieś we/wy dziennika niezwiązanego z transakcjami z dysku
- Przenieś dziennik transakcji na mniej zajęty dysk
- Zmniejsz rozmiar dziennika transakcji
- Upewnij się, że instrukcja COMMIT jest umieszczona w kodzie, aby dane nie były wprowadzane zbyt często
TempDB
TempDB to tymczasowy obszar roboczy w SQL Server, który przechowuje obiekty tymczasowe. Ponieważ obiekty przechowywane w TempDB są przejściowe, wystąpienie SQL Server odtwarza TempDB przy każdym ponownym uruchomieniu. To sprawia, że optymalizacja TempDB ma kluczowe znaczenie dla utrzymania wydajności i uniknięcia wąskich gardeł operacyjnych.
Rywalizacja o TempDB jest jednym z głównych winowajców pogorszenia wydajności. Rywalizacja występuje, gdy wiele zasobów wymaga dostępu do TempDB, ale istnieje tylko jeden plik danych TempDB. Powoduje to wąskie gardło, ponieważ procesy nie mogą uzyskać dostępu do bazy danych TempDB wystarczająco szybko, co prowadzi do przekroczenia limitu czasu połączeń i cofnięcia alokacji procesów.
Na szczęście wąskie gardła TempDB można dość łatwo rozwiązać, dostosowując liczbę i rozmiar plików TempDB. Podczas instalacji domyślnym serwerem SQL Server jest jeden plik danych TempDB. Jeśli zauważysz konflikt, zaleca się dodanie ośmiu nowych plików danych i ustalenie, czy to rozwiązuje problem. Jeśli problem nie zostanie rozwiązany, spróbuj dodać dodatkowe pliki danych w wielokrotnościach czterech, aż do przywrócenia wydajności.
Chociaż dobrze jest wiedzieć, od czego zacząć szukać, gdy wystąpią problemy z wydajnością, każdy z powyższych problemów i wynikające z nich wąskie gardła można złagodzić lub całkowicie uniknąć, wdrażając jedną twardą i szybką regułę:Monitorowanie metryk wydajności nie jest opcjonalne. Oto kilka przykładów kluczowych wskaźników do śledzenia:
Oczekiwana długość życia strony:Śledź PLE dzięki ciągłemu monitorowaniu i bądź proaktywny, gdy spada i utrzymuje się poniżej typowej wartości dla określonej instancji SQL Server.
Czasy oczekiwania WRITELOG:Monitoruj metryki, takie jak wzrost dziennika, kurczenie się dziennika, procent wykorzystania dziennika i czas oczekiwania na opróżnianie dziennika/s.
Nieefektywność TempDB:Monitoruj, co jest przydzielane do obiektów użytkownika, magazynu wersji lub obiektów wewnętrznych. Śledź ich trendy w czasie, a następnie określ, jakie sesje zużywają TempDB i ile.
Na rynku dostępnych jest kilka doskonałych, bogatych w funkcje, niedrogich narzędzi do monitorowania wydajności programu SQL Server, które mogą pomóc w uniknięciu problemów z obniżeniem wydajności. Stań się MVP DBA firmy, proaktywnie badając rozwiązania, które zapewniają najwyższą wydajność zarówno operacji skierowanych do wewnątrz, jak i usług biznesowych skierowanych na zewnątrz.
