Co by było, gdybyś zadał sobie trud wdrożenia lub uaktualnienia do nowego programu SQL Server, aby zapewnić klientom lepsze wrażenia — a oni narzekali, że w rzeczywistości jest gorzej?
Czy nie byłbyś zakłopotany, gdybyś przeskoczył przez wszystkie te biznesowe i techniczne obręcze, aby uzyskać lepszą wydajność SQL Server, a potem tego nie zrobił?
Może powinieneś był przeprowadzić testy wydajności SQL Server przed przejściem do produkcji. Wtedy wiedziałbyś, czy Twoje wyniki się poprawią, pozostaną takie same, czy, co najgorsze, spadną.
Ale przynajmniej nie byłbyś niemile zaskoczony.
Most wydajności SQL Server, z którym wszyscy przechodzimy
Niezależnie od tego, czy chodzi o przejście z innej bazy danych na SQL Server, czy o aktualizację ze starszej wersji SQL Server do nowszej, w końcu trzeba było przejść przez most wydajności.
„Czy naprawdę będzie działać lepiej niż wcześniej?” zapytał twój szef.
„Och, jasne”, powiedziałeś. „Dzięki wirtualizacji danych w SQL Server 2019 możemy uruchamiać zapytania bez przenoszenia lub replikowania danych. Jest też automatyczne dostrajanie dzięki inteligentnemu przetwarzaniu zapytań w celu skalowania zapytań. Dane wylecą z serwerów.” Byłeś tak pewny siebie, że zapisałeś „FLY”.
Jak więc mogłeś lepiej przetestować swoją wydajność?
4 sposoby testowania wydajności . . .
Brent Ozar, wybitny znawca SQL Server, mówi, jak sprawdzić wydajność nowego SQL Servera:
- łatwy sposób, porównując czasy przed i po na pełnej kopii zapasowej i CHECKDB
- łatwy, ale zły sposób, z syntetycznym obciążeniem i TPC-C w HammerDB
- w trudniejszy sposób, testowanie poszczególnych zapytań za pomocą sp_BlitzCache, jego skryptu analizy pamięci podręcznej planu
- naprawdę trudny sposób, uruchamiając te same zapytania, które wykonujesz w środowisku produkcyjnym
Ale jak wyjaśnia Brent, monitorowanie wydajności serwera SQL i stwierdzenie, że spadła ona o X procent, to dopiero początek; nadal musisz dowiedzieć się, skąd pochodzi uderzenie.
Oznacza to szukanie trendów w danych dotyczących skuteczności w ciągu całych tygodni i miesięcy, a nie tylko w ciągu ostatnich kilku godzin.
Im więcej masz punktów danych i historii, tym lepszy obraz tego, co się dzieje w środowisku SQL Server, w jego otoczeniu i wokół niego.
A im więcej mocy obliczeniowych możesz uzyskać na wszystkich tych danych, tym szybciej możesz je przeanalizować.
Monitorowanie wydajności SQL Server:brzmi jak praca dla chmury
Tak. To zadanie dla chmury, jedynego miejsca, w którym można skalować na tyle daleko, aby zebrać i przeanalizować wszystkie te dane, aby uzyskać szeroki, głęboki obraz tego, jak SQL Server zużywa zasoby. I jak z biegiem czasu zużywa te zasoby. Na przykład:
- W określonych porach dnia lub miesiąca często uruchamiane zapytania muszą odczytywać dane z dysku zamiast z bufora bufora, który jest kopią w pamięci ostatnio używanych stron bazy danych. Czy musisz przydzielić więcej pamięci do bufora pamięci podręcznej? Czy możesz poświęcić na to więcej pamięci?
- To samo dotyczy oczekiwanej długości życia strony. Jeśli jest niski, prawdopodobnie dzieje się tak dlatego, że SQL Server zbyt często usuwa strony z pamięci podręcznej bufora i musi uruchamiać wyszukiwania z magazynu zamiast z pamięci. To utrudnia wydajność.
- Czy maksymalny czas oczekiwania na we/wy nie jest zbyt długi? Jaka jest popularność? To wskazówka, że urządzenie I/O może być nasycone.
- Jak długa jest teraz kolejka procesora? Jak długo to zwykle trwa? Zbyt wiele ciągle oczekujących wątków może wskazywać na przeciążenie procesora.
- Czy procesor działa wbrew ograniczeniom, które może obsłużyć Twój serwer? Co zrobić, jeśli nie możesz już skalować serwera w górę? Jeśli masz pewność, że Twoje zapytania są dobrze dostrojone, a inne zasoby systemowe są wystarczające, być może będziesz musiał dodać gniazdo dla fizycznego sprzętu lub procesorów wirtualnych do swoich maszyn wirtualnych.
- Pofragmentowane indeksy to powolne indeksy, ale nie wiesz, że są winowajcą, dopóki nie sprawdzisz poziomów fragmentacji. Obserwowanie efektów reorganizacji i przebudowy w czasie może pomóc w ustanowieniu niezawodnego procesu konserwacji indeksu.
Znajdowanie problemów takich jak te we wszystkich lokalnych i chmurowych bazach danych staje się łatwiejsze i szybsze, gdy możesz monitorować wydajność serwera SQL z chmury. Co najlepsze, możesz monitorować z dowolnego miejsca w znanej galaktyce, gdy wszystkie obliczenia, pamięć masowa i analiza znajdują się w chmurze, a w dowolnej przeglądarce dzieli Cię tylko kilka kliknięć.
Rozpocznij testowanie wydajności SQL Server w chmurze
W Quest nikt nie musi nam powtarzać dwa razy, że nasi klienci chcą narzędzi opartych na chmurze, czy to do migracji do chmury, monitorowania wydajności, czy do usługi Office 365. Udostępniamy więcej naszych produktów jako oferty w chmurze, ponieważ przyciągają je technologie i rynki.
Jak więc przeprowadzić testy wydajności na nowych lub zaktualizowanych serwerach SQL?
- Uruchamiam CHECKDB.
- Uruchamiam HammerDB.
- Obsługuję narzędzia Brenta Ozara.
- Testuję z obciążeniami produkcyjnymi.
- Rzucam kostką i czekam, aż użytkownicy narzekają.
- Mam ludzi, którzy robią to dla mnie.
- Używam Spotlight Cloud z Quest. Ty też powinieneś.
