Kontynuacja Summer Performance Palooza 2013

27 czerwca PASS Performance Virtual Chapter zorganizował Summer Performance Palooza 2013 – rodzaj zmniejszonych 24 godzin PASS, ale skupionych wyłącznie na tematach związanych z wydajnością. Prowadziłem sesję zatytułowaną „10 złych nawyków, które mogą zabić wydajność”, omawiając 10 następujących pojęć:

1. WYBIERZ *
2. Ślepe indeksy
3. Brak przedrostka schematu
4. Domyślne opcje kursora
5. przedrostek sp_
6. Zezwalanie na rozrost pamięci podręcznej
7. Szerokie typy danych
8. Domyślne ustawienia serwera SQL
9. Nadużywanie funkcji
10. „Działa na moim komputerze”

Być może pamiętasz niektóre z tych tematów z takich prezentacji, jak mój wykład „Złe nawyki i najlepsze praktyki” lub nasze cotygodniowe seminaria internetowe dotyczące dostrajania zapytań, które prowadzę z Kevinem Klinem od początku czerwca do tego tygodnia. (Nawiasem mówiąc, te 6 filmów będzie dostępnych na początku sierpnia w YouTube).

Na moją sesję wzięło udział 351 osób i otrzymałem świetne opinie. Chciałem poruszyć niektóre z nich.

Po pierwsze, kwestia konfiguracji:używałem zupełnie nowego mikrofonu i nie miałem pojęcia, że ​​każde naciśnięcie klawisza będzie brzmiało jak grzmot. Rozwiązałem ten problem, poprawiając rozmieszczenie moich urządzeń peryferyjnych, ale chcę przeprosić wszystkich, których to dotyczy.

Następnie pliki do pobrania; pokład i próbki są publikowane na miejscu imprezy. Znajdują się na dole strony, ale możesz je również pobrać tutaj.

Na koniec poniżej znajduje się lista pytań, które zostały zadane podczas sesji i chciałem się upewnić, że odpowiedziałem na te, na które nie udzielono odpowiedzi podczas pytań i odpowiedzi na żywo. Przepraszam, że wcisnąłem to w niecały miesiąc , ale były dużo pytań i nie chciałem publikować ich w częściach.

O: Będziesz musiał podejść do tego indywidualnie dla każdego przypadku, ponieważ będzie to naprawdę zależeć od wielu czynników (w tym złożoności planu). Należy również zauważyć, że można przeprowadzić ponowną kompilację na poziomie instrukcji w taki sposób, że tylko instrukcje, których dotyczy problem, muszą przyjąć trafienie, w przeciwieństwie do całego modułu. Paul White przypomniał mi, że ludzie często „naprawiają” wąchanie parametrów za pomocą RECOMPILE , ale zbyt często oznacza to WITH RECOMPILE w stylu 2000 zamiast znacznie lepszej OPTION (RECOMPILE) , który nie tylko ogranicza się do instrukcji, ale także umożliwia osadzanie parametrów, które WITH RECOMPILE nie. Tak więc, jeśli zamierzasz użyć RECOMPILE aby udaremnić podsłuchiwanie parametrów, dodaj je do instrukcji, a nie do modułu.

O: Jak wyżej, będzie to zależeć od kosztów i złożoności planów i nie ma sposobu, aby powiedzieć „Tak, zawsze będzie duży hit wydajności”. Musisz także porównać to z alternatywą.

O: Nie jestem pewien, co oznacza „czytelny w prawdziwym świecie”. Jeśli masz na myśli, że chcesz uzyskać dane wyjściowe w określonym formacie, zwykle lepiej jest przekonwertować na ciąg po stronie klienta. C# i większość innych języków, których prawdopodobnie używasz w warstwie prezentacji, są w stanie sformatować dane wyjściowe daty/godziny z bazy danych w dowolnym formacie regionalnym.

O: Większość DMV jest ważna dopiero od ostatniego uruchomienia usługi, a nawet inne można opróżniać częściej (nawet na żądanie – zarówno nieumyślnie, jak i celowo). Pamięć podręczna planu jest oczywiście w ciągłym ruchu, a plany AFAIK, które wypadają z pamięci podręcznej, nie zachowują poprzedniej liczby, jeśli wrócą. Więc nawet gdy widzisz plan w pamięci podręcznej, nie jestem w 100% przekonany, że możesz uwierzyć w znalezioną liczbę zastosowań.

To powiedziawszy, prawdopodobnie szukasz sys.dm_exec_cached_plans.usecounts możesz również znaleźć sys.dm_exec_procedure_stats.execution_count aby pomóc w uzupełnieniu informacji o procedurach, w których poszczególne instrukcje w ramach procedur nie znajdują się w pamięci podręcznej.

O: Głównymi problemami związanymi z tym jest możliwość użycia określonej składni, takiej jak OUTER APPLY lub zmienne z funkcją wycenianą w tabeli. Nie są mi znane przypadki, w których używanie niższej kompatybilności ma jakikolwiek bezpośredni wpływ na wydajność, ale kilka rzeczy zwykle zalecanych to przebudowa indeksów i aktualizacja statystyk (oraz aby dostawca jak najszybciej wspierał nowszy poziom kompatybilności). Widziałem, jak rozwiązało to nieoczekiwane pogorszenie wydajności w znacznej liczbie przypadków, ale słyszałem też opinie, że nie jest to konieczne, a może nawet nierozsądne.

O: Nie, przynajmniej pod względem wydajności, jeden wyjątek, w którym SELECT * nie ma znaczenia, gdy jest używany wewnątrz EXISTS klauzula. Ale dlaczego miałbyś używać * tutaj? Wolę używać EXISTS (SELECT 1 ... – optymalizator potraktuje je tak samo, ale w pewien sposób sam dokumentuje kod i zapewnia, że ​​czytelnicy rozumieją, że podzapytanie nie zwraca żadnych danych (nawet jeśli przegapią duże EXISTS na zewnątrz). Niektórzy używają NULL , i nie mam pojęcia, dlaczego zacząłem używać 1, ale znalazłem NULL trochę nieintuicyjne.

*Uwaga* musisz być ostrożny, jeśli spróbujesz użyć EXISTS (SELECT * wewnątrz modułu, który jest powiązany ze schematem:

CREATE VIEW dbo.ThisWillNotWork
WITH SCHEMABINDING
AS
  SELECT BusinessEntityID
    FROM Person.Person AS p
	WHERE EXISTS (SELECT * FROM Sales.SalesOrderHeader AS h
	  WHERE h.SalesPersonID = p.BusinessEntityID);

Pojawia się ten błąd:

Jednak zmieniając go na SELECT 1 działa dobrze. Może to kolejny argument za unikaniem SELECT * nawet w tym scenariuszu.

O: Prawdopodobnie istnieją setki w różnych językach. Podobnie jak konwencje nazewnictwa, standardy kodowania są bardzo subiektywne. Tak naprawdę nie ma znaczenia, która konwencja, którą uznasz, będzie dla Ciebie najlepsza; jeśli lubisz tbl przedrostki, zwariuj! Wolisz Pascala od bigEndianu. Chcesz poprzedzić nazwy kolumn typem danych, np. intCustomerID , nie zamierzam cię zatrzymywać. Ważniejsze jest to, że definiujesz konwencję i stosujesz ją *konsekwentnie.*

To powiedziawszy, jeśli chcesz moich opinii, nie brakuje mi ich.

O: Nie znam żadnych planów wycofania XACT_ABORT więc powinno nadal działać dobrze. Szczerze mówiąc, nie widzę tego zbyt często, ponieważ mamy TRY / CATCH (i THROW od SQL Server 2012).

O: Nie testowałem tego, ale w wielu przypadkach zastąpienie funkcji skalarnej wbudowaną funkcją z wartością tabelaryczną może mieć duży wpływ na wydajność. Problem, który znalazłem, polega na tym, że wprowadzenie tego przełącznika może wymagać znacznej ilości pracy w systemie, który został napisany przed APPLY istniały lub nadal są zarządzane przez osoby, które nie przyjęły tego lepszego podejścia.

O: Przychodzą mi na myśl dwie rzeczy:(1) opóźnienie ma związek z czasem kompilacji lub (2) opóźnienie ma związek z ilością danych, które są ładowane w celu zaspokojenia zapytania i kiedy po raz pierwszy muszą pochodzić z dysku a nie pamięć. W przypadku (1) możesz wykonać zapytanie w Eksploratorze planów SQL Sentry, a pasek stanu pokaże czas kompilacji dla pierwszego i kolejnych wywołań (chociaż minuta wydaje się dość przesadna i mało prawdopodobna). Jeśli nie znajdziesz żadnej różnicy, może to być po prostu natura systemu:niewystarczająca pamięć do obsłużenia ilości danych, które próbujesz załadować za pomocą tego zapytania w połączeniu z innymi danymi, które już znajdowały się w puli buforów. Jeśli nie uważasz, że którykolwiek z tych problemów stanowi problem, sprawdź, czy te dwie różne egzekucje faktycznie dają różne plany — jeśli są jakieś różnice, opublikuj plany na adres Answers.sqlperformance.com, a z przyjemnością się przyjrzymy . W rzeczywistości przechwytywanie rzeczywistych planów dla obu wykonań przy użyciu Eksploratora planów w każdym przypadku może również poinformować o wszelkich różnicach we/wy i może prowadzić do tego, że SQL Server spędza swój czas przy pierwszym, wolniejszym uruchomieniu.

O: Nie, nie sądzę, aby ustawienie Optymalizuj dla obciążeń ad hoc pomogło w tym scenariuszu, ponieważ podsłuchiwanie parametrów oznacza, że ​​kolejne wykonania tego samego planu są używane dla różnych parametrów i ze znacznie różnymi zachowaniami wydajnościowymi. Optymalizacja pod kątem obciążeń ad hoc służy do minimalizowania drastycznego wpływu na pamięć podręczną planu, który może mieć miejsce w przypadku dużej liczby różnych instrukcji SQL. Więc jeśli nie mówisz o wpływie na pamięć podręczną planu wielu różnych instrukcji, które wysyłasz do sp_executesql – co nie byłoby scharakteryzowane jako wąchanie parametrów – myślę, że eksperymentując z OPTION (RECOMPILE) może mieć lepszy wynik lub, jeśli znasz wartości parametrów, które *dają* dobre wyniki w różnych kombinacjach parametrów, użyj OPTIMIZE FOR . Ta odpowiedź Paula White'a może zapewnić znacznie lepszy wgląd.

O: Jasne, po prostu dołącz OPTION (RECOMPILE) w dynamicznym tekście SQL:

DBCC FREEPROCCACHE;
 
USE AdventureWorks2012;
GO
SET NOCOUNT ON;
GO
 
EXEC sp_executesql 
  N'SELECT TOP (1) * INTO #x FROM Sales.SalesOrderHeader;';
GO
EXEC sp_executesql 
  N'SELECT TOP (1) * INTO #x FROM Sales.SalesOrderDetail OPTION (RECOMPILE);'
GO
 
SELECT t.[text], p.usecounts
FROM sys.dm_exec_cached_plans AS p
CROSS APPLY sys.dm_exec_sql_text(p.[plan_handle]) AS t
WHERE t.[text] LIKE N'%Sales.' + 'SalesOrder%';

Wyniki:1 wiersz pokazujący Sales.SalesOrderHeader zapytanie.

Teraz, jeśli jakakolwiek instrukcja w partii NIE zawiera OPTION (RECOMPILE) , plan może być nadal przechowywany w pamięci podręcznej, po prostu nie można go ponownie wykorzystać.

DBCC FREEPROCCACHE(0x06.....);