Czy SentryOne Plan Explorer zlicza odczyty w UDF?

Mam takie zapytanie:

select dbo.fn_complexFunction(t.id)
from mytable t

W SQL Sentry Plan Explorer zauważyłem, że muszę uruchomić Get Estimated Plan, aby Plan zapytań zawierał UDF.

Po uruchomieniu polecenia „Pobierz aktualny plan” nie wydaje się, aby odczyty logiczne i inne metryki obejmowały operacje występujące w UDF. W takich przypadkach, czy jedynym obejściem jest użycie Profiler?

Największe problemy, jakie tu mamy, to:

1. Jak mówi @JNK, SQL Server zaciemnia użycie UDF i robi z nimi okropne rzeczy (jak zawsze szacuje jeden wiersz). Kiedy generujesz rzeczywisty plan w SSMS, w ogóle nie widzisz jego zastosowania. Plan Explorer podlega tym samym ograniczeniom, ponieważ może dostarczyć tylko informacje o planie, który zapewnia SQL Server.
2. Kod generuje rzeczywisty plan w oparciu o różne źródła metryk środowiska wykonawczego. Niestety, plan XML nie zawiera wywołań funkcji, a SQL Server nie ujawnia operacji we / wy poniesionych przez funkcję podczas korzystania z SET STATISTICS IO ON;któregoś z nich (w ten sposób Table I/Ozapełniana jest karta).

Rozważ następujący widok i funkcję AdventureWorks2012. To tylko głupia próba zwrócenia losowego wiersza z tabeli szczegółów, biorąc pod uwagę losowy wiersz z tabeli nagłówka - głównie po to, aby za każdym razem wygenerować jak najwięcej operacji we / wy.

CREATE VIEW dbo.myview 
WITH SCHEMABINDING
AS
  SELECT TOP (100000) rowguid, SalesOrderID, n = NEWID() 
    FROM Sales.SalesOrderDetail ORDER BY NEWID();
GO

CREATE FUNCTION dbo.whatever(@SalesOrderID INT)
RETURNS UNIQUEIDENTIFIER
WITH SCHEMABINDING
AS
BEGIN
  RETURN 
  (
    SELECT TOP (1) rowguid FROM dbo.myview 
     WHERE SalesOrderID = @SalesOrderID ORDER BY n
  );
END
GO

Co Studio Management mówi (a czego nie mówi)

Wykonaj następujące zapytanie w SSMS:

SET STATISTICS IO ON;

  SELECT TOP (5) SalesOrderID, dbo.whatever(SalesOrderID) 
    FROM Sales.SalesOrderHeader ORDER BY NEWID();

SET STATISTICS IO OFF;

Podczas szacowania plan, ty dostać plan dla zapytania oraz z pojedynczym planu funkcji (nie 5, jak można mieć nadzieję):

Oczywiście nie dostajesz żadnych danych we / wy, ponieważ zapytanie nie zostało w rzeczywistości wykonane. Teraz wygeneruj aktualny plan. Otrzymujesz 5 wierszy, których oczekiwałeś w tabeli wyników, następujący plan (który absolutnie nie czyni widocznej wzmianki o UDF, z wyjątkiem XML, który można znaleźć jako część tekstu zapytania i jako część operatora skalarnego):

I następujące STATISTICS IOdane wyjściowe (które absolutnie nie wspominają o tym Sales.SalesOrderDetail, chociaż wiemy, że trzeba było odczytać z tej tabeli):

Tabela „SalesOrderHeader”. Liczba skanów 1, logiczne odczyty 57, fizyczne odczyty 0, odczyt z wyprzedzeniem 0, lob logiczne odczyty 0, lob fizyczne odczyty 0, lob odczyty z wyprzedzeniem 0.

Co mówi Eksplorator planu

Kiedy PE generuje szacunkowy plan dla tego samego zapytania, wie o tym samym, co SSMS. Jednak pokazuje rzeczy w nieco bardziej intuicyjny sposób. Na przykład plan szacunkowy dla zewnętrznego zapytania pokazuje, w jaki sposób dane wyjściowe funkcji są łączone z danymi wyjściowymi zapytania, i od razu jest jasne - na jednym schemacie planu - że we / wy jest z obu tabel :

Pokazuje również sam plan funkcji , który uwzględniam tylko dla kompletności:

Teraz rzućmy okiem na faktyczny plan, który jest tysiące razy bardziej użyteczny. Minusem tutaj jest to, że ma tylko informacje, które SQL Server postanawia wyświetlić, więc może ujawnić tylko schematy graficzne, które udostępnia SQL Server. To nie jest sytuacja, w której ktoś postanowił nie pokazywać ci czegoś pożytecznego; po prostu nic o tym nie wie na podstawie dostarczonego planu XML. W tym przypadku jest tak jak w SSMS, możesz zobaczyć tylko plan zewnętrznego zapytania i to tak, jakby funkcja nie była w ogóle wywoływana :

Karta Tabela we / wy również nadal opiera się na danych wyjściowychSTATISTICS IO , co również ignoruje dowolne działanie wykonywane w wywołaniu funkcji:

Jednak PE otrzymuje dla ciebie cały stos wywołań. Od czasu do czasu słyszę, jak ludzie pytają: „Pffft, kiedy będę potrzebować stosu połączeń?” Cóż, możesz właściwie podzielić czas, wykorzystany procesor i liczbę odczytów (oraz, dla TVF, liczbę wyprodukowanych wierszy) dla każdego wywołania funkcji :

Niestety nie masz możliwości skorelowania tego, z których tabel pochodzi tabela I / O (ponownie, ponieważ program SQL Server nie udostępnia tych informacji) i nie jest oznaczony nazwą UDF (ponieważ jest przechwytywany jako instrukcja ad hoc, a nie samo wywołanie funkcji). Ale to, co pozwala ci zobaczyć, że Management Studio nie, jest tym, jakim psem jest Twój UDF. Nadal musisz dołączyć kilka kropek, ale jest ich mniej i są one bliżej siebie.

O programie Profiler

Na koniec zdecydowanie zalecam trzymanie się z dala od Profiler, chyba że jest to skonfigurowanie śledzenia po stronie serwera, które zamierzasz wykonać w skrypcie, a następnie uruchomić poza zakresem jakiegokolwiek narzędzia interfejsu użytkownika. Używanie Profiler przeciwko systemowi produkcyjnemu prawie na pewno spowoduje więcej problemów niż kiedykolwiek rozwiąże . Jeśli chcesz uzyskać te informacje, użyj śledzenia po stronie serwera lub zdarzeń rozszerzonych i upewnij się, że filtrujesz bardzo mądrze. Nawet bez profilera, ślad może wpłynąć na twój serwer, a pobieranie showplanów poprzez dłuższe wydarzenia nie jest również najbardziej wydajną rzeczą na świecie .