Jakie są 3 najważniejsze problemy z wydajnością, które napotykasz na swoich serwerach SQL?

Jestem studentem Fontys University w Eindhoven, a obecnie przeprowadzam serię wywiadów, aby pomóc w opracowaniu narzędzia SQL Server i chciałbym uzyskać opinie od ekspertów w tej dziedzinie.

Jedno z moich pytań to:

Jakie są 3 najważniejsze problemy z wydajnością występujące w wystąpieniach programu SQL Server i jak je rozpoznać?

Szczególnie interesują mnie skrypty i narzędzia używane do mierzenia tego.

Z czubka mojej głowy - 3 najważniejsze problemy z zapytaniami:

• Niejawne konwersje
• Złe strategie indeksowania (za dużo lub za mało lub niewłaściwy rodzaj)
• Używanie WYBIERZ * zamiast nazywania tylko potrzebnych pól

Jest wiele innych problemów z konfiguracją na poziomie serwera, problemów ze schematem bazy danych, problemów ze sprzętem itp. Napisałem skrypt do szybkiej analizy serwerów szukających tego rodzaju problemów:

http://www.brentozar.com/blitz/

• Zły projekt / zapytania / indeksowanie
• Niedozwolone jest kupowanie prawidłowego sprzętu
• Braindead ORM (alias „SQL is dead”)

Nie w pierwszej trójce, ale pomyślałem, że wspomnę o rzeczach jeszcze nie wymienionych:

1. SQL umieszczony na maszynach wirtualnych bez DBA zapewniających szczegóły / przejrzystość. Serwer hosta dynamicznie zmieni ustawienia komputerów-gości, powodując spadek wydajności i pozostawiając DBA bez pojęcia. Funkcje takie jak hipertekst, łączenie w sieć i balonowanie z pamięci sprawiają, że liczniki wydajności są ruchomym celem do monitorowania.Tools: sysmon/perfmon, DMVs, maintaining a history of performance counters in tables.
2. Podobnie brak przejrzystości / możliwości weryfikacji ustawień SAN dostarczonych do DBA. Miałem jednostki LUN z różnymi preferencjami pamięci podręcznej odczytu / zapisu, ale powiedziałem, że wszystkie są takie same.Tools: IO DMVs, SQLIO.
3. Zła architektura DB: jak zmiana rozmiaru i rozmieszczenie danych i plików dziennika oraz tempdb. Niewłaściwe użycie równoległości. Tworzenie wielu aplikacjami na tych samych dyskach fizycznych.Tools: experience.

Kolejnym narzędziem, które teraz sprawdzam, jest Project Lucy . Wydaje się schludne.

• brak odpowiednich indeksów
• użycie z nolock w kodzie produkcyjnym przez kogoś, aby spróbować rozwiązać problemy z wydajnością. Szczególnie źle, jeśli kod modyfikuje dane w tabelach
• aplikacja wybierająca więcej danych niż jest to potrzebne w większej liczbie przypadków niż jest to konieczne. Ex posiadający plik binarny zwracany za każdym razem, nawet jeśli chcesz tylko dane tekstowe tej samej tabeli.

Kwerendy, które źle skalują się (otrzymuj wszystkie zamówienia przez X lat dla wszystkich klientów itp., W tym wszystkie wiersze, w tym dane sumowane i inne dane źle obliczone)

Po prostu odpytuję wszystko naraz.

Tabele zawierające pola opisowe varchar / tekst, które należy przeszukiwać przy każdym zapytaniu.

• Niewłaściwa konserwacja, tzn. Brak zmian indeksów, statystyk, brak kopii zapasowych dziennika
• Brakujące indeksy
• Źle napisane zapytania

• Zły projekt bazy danych i aplikacji
• słabe wykorzystanie zalet platformy (programiści chcieli mieć zintegrowany z platformą kod dostępu do bazy danych. brak SP, brak funkcji itp.)
• oczywiście złe indeksowanie.

• zapytania ad-hoc dotyczące danych prod - tak, programiści uważają, że jest to konieczne, a niektórzy mogą nawet mieć dostęp :-)
• zły projekt aplikacji korzystającej z bazy danych - np .: zbyt dużo danych dodanych i nigdy nie usuniętych, nawet jeśli nie jest to już konieczne (co prowadzi do problemów z wydajnością, ponieważ kopie zapasowe rosną, zadania konserwacyjne trwają dłużej itd.)
• wszystkie pliki bazy danych na tym samym rajdzie lub gorzej, na tym samym dysku (np .: system dbs, tempdb, użytkownik dbs wszystkie razem na tym samym dysku / rajdzie)

• Zły projekt bazy danych
• Zła strategia indeksowania (w tym zbyt wiele indeksów, brak indeksów i brak konserwacji indeksów)
• Złe decyzje dotyczące architektury sprzętu

Indeksowanie ma kluczowe znaczenie dla wydajności, ale zauważyłem, że większość DBA wie o tym, więc jest to jedna z pierwszych rzeczy, które można naprawić dzięki optymalizacji zapytań. Obszary, które często nie są dobrze rozwiązane:

1. Zbyt wiele podróży w obie strony DB. Chattiness jest jednym z głównych problemów z wydajnością, jakie widzę.
2. Uzyskiwanie właściwych granic transakcji. Transakcja przy każdym INSERT / UPDATE / DELETE może być dużym zabójcą wydajności.
3. Brak optymalizacji strony sprzętowej; w szczególności umieszczenie dziennika DB na innym wolumenie niż dane DB.

Gdybym mógł dodać czwarty element do listy, byłoby to nadmierne i niewłaściwe użycie wyzwalaczy i / lub kursorów. W dzisiejszych czasach nie wydaje się to zbyt częste, ale kiedy tak się dzieje, jest bolesne z punktu widzenia wydajności.