Så här ser du om extern nedtryckning har inträffat

Den här artikeln beskriver hur du avgör om en PolyBase-fråga drar nytta av pushdown till den externa datakällan. Mer information om extern pushdown finns i pushdown-beräkningar i PolyBase.

Får min frågeställning nytta av extern pushdown?

Pushdown-beräkningen förbättrar prestandan för förfrågningar på externa datakällor. Vissa beräkningsuppgifter delegeras till den externa datakällan i stället för att överföras till SQL Server. Särskilt vid filtrering och join pushdown kan arbetsbelastningen på SQL Server-instansen minskas avsevärt.

Beräkning av PolyBase-pushdown kan avsevärt förbättra sökfrågans prestanda. Om en PolyBase-fråga går långsamt bör du avgöra om en pushdown för din PolyBase-fråga inträffar.

Det finns tre olika scenarier där pushdown kan observeras i utförandeplanen.

• Predikat-pushdown för filtrering
• Gå med i pushdown
• Aggregerings-pushdown

Not

Det finns begränsningar för vad som kan överföras till externa datakällor med PolyBase-beräkningar för pushdown:

• Vissa T-SQL-funktioner kan förhindra pushdown, mer information finns i PolyBase-funktioner och begränsningar.
• En lista över T-SQL-funktioner som annars kan behandlas med pushdown-teknik finns i Pushdown-beräkningarna i PolyBase.

Två nya funktioner i SQL Server 2019 (15.x) har introducerats för att administratörer ska kunna avgöra om en PolyBase-fråga skickas ned till den externa datakällan:

• Visa beräknad exekveringsplan med spårningsflagga 6408
• Visa read_command i visningen sys.dm_exec_external_work dynamisk hanteringsvy

Den här artikeln innehåller information om hur du använder var och en av dessa två användningsfall för var och en av tre pushdown-scenarier.

Använd TF6408

Som förval visar den uppskattade exekveringsplanen inte fjärrfrågeplanen, och du ser bara fjärrfrågeoperatorn. Till exempel en uppskattad exekveringsplan från SQL Server Management Studio (SSMS):

Eller i Azure Data Studio:

Från och med SQL Server 2019 (15.x) kan du aktivera en ny spårningsflagga 6408 globalt med hjälp av DBCC TRACEON. Till exempel:

DBCC TRACEON (6408, -1);  

Den här spårningsflaggan fungerar bara med uppskattade körningsplaner och har ingen effekt på faktiska körningsplaner. Den här spårningsflaggan visar information om fjärrfrågeoperatorn som visar vad som händer under fjärrfrågefasen.

Körningsplaner läses från höger till vänster, enligt pilarnas riktning. Om en operatör är till höger om en annan operatör, säger man att den är "före" den. Om en operatör är till vänster om en annan operatör, säger man att den är "efter" den andra.

• I SSMS markerar du frågan och väljer Visa uppskattad exekveringsplan i verktygsfältet eller använder Ctrl+L.
• Markera frågan i Azure Data Studio och välj Förklara. Överväg sedan följande scenarier för att avgöra om en "pushdown" inträffade.

Vart och ett av exemplen nedan innehåller utdata från SSMS och Azure Data Studio.

Pushdown för filterpredikat (vy med exekveringsplan)

Tänk på följande fråga, som använder ett filterpredikat i WHERE-satsen:

SELECT *
FROM [Person].[BusinessEntity] AS be
WHERE be.BusinessEntityID = 17907;

Om pushdown för filterpredikatet inträffar ligger filteroperatorn före den externa operatorn. När filteroperatorn är före den externa operatorn inträffade filtreringen innan den valdes tillbaka från den externa datakällan, vilket indikerar att filterpredikatet trycktes ned.

Med nedtryckning av filtervillkor (vy med körningsplan)

När spårningsflaggan 6408 är aktiverad, ser du nu ytterligare information i utdata för den uppskattade exekveringsplanen. Utdata varierar mellan SSMS och Azure Data Studio.

I SSMS visas fjärrfrågeplanen i den uppskattade körningsplanen som Fråga 2 (sp_execute_memo_node_1) och motsvarar fjärrfrågeoperatorn i Fråga 1. Till exempel:

I Azure Data Studio representeras fjärrfrågekörningen i stället som en enskild frågeplan. Till exempel:

Utan pushdown av filterpredikat (vy med utförandeplan)

Om pushdown för filterpredikatet inte sker kommer filtret att vara efter den externa operatorn.

Den uppskattade exekveringsplanen från SSMS:

Den uppskattade körningsplanen från Azure Data Studio:

Nedtryckning av JOIN

Tänk på följande fråga som använder JOIN-operatorn för två externa tabeller på samma externa datakälla:

SELECT be.BusinessEntityID, bea.AddressID
FROM [Person].[BusinessEntity] AS be
INNER JOIN [Person].[BusinessEntityAddress] AS bea
ON be.BusinessEntityID = bea.BusinessEntityID;

Om JOIN skickas ned till den externa datakällan visas kopplingsoperatorn före den externa operatorn. I det här exemplet är både [BusinessEntity] och [BusinessEntityAddress] externa tabeller.

Med pushdown av koppling (visa med körningsplan)

Den uppskattade utförandeplanen från SSMS:

Den uppskattade utförandeplanen från Azure Data Studio:

Utan pushdown av sammanfogning (vy med exekveringsplan)

Om JOIN inte skickas ned till den externa datakällan kommer Join-operatorn att placeras efter den externa operatorn. I SSMS finns den externa operatorn med i frågeplanen för sp_execute_memo_node, som är en del av Fjärrfråga-operatören i fråga 1. I Azure Data Studio är kopplingsoperatorn efter de externa operatorerna.

Den uppskattade körningsplanen från SSMS:

Den uppskattade utförandeplanen från Azure Data Studio:

Pushdown av aggregering (vy med exekveringsplan)

Tänk på följande fråga, som använder en aggregeringsfunktion:

SELECT SUM([Quantity]) as Quant
FROM [AdventureWorks2022].[Production].[ProductInventory];

Med pushdown av aggregering (vy med exekveringsplan)

Om pushdown för aggregeringen sker ligger aggregeringsoperatorn före den externa operatorn. När aggregeringsoperatorn är före den externa operatorn inträffade aggregeringen innan den valdes tillbaka från den externa datakällan, vilket indikerar att aggregeringen pushades ned.

Den uppskattade utförandeplanen från SSMS:

Den uppskattade körningsplanen från Azure Data Studio:

Utan pushdown av aggregering (vy med utförandeplan)

Om pushdown för aggregeringen inte sker kommer aggregeringsoperatorn att vara efter den externa operatorn.

Den uppskattade körningsplanen från SSMS:

Den uppskattade exekveringsplanen från Azure Data Studio:

Använda DMV

I med SQL Server 2019 (15.x) och senare versioner visar kolumnen read_command i sys.dm_exec_external_work DMV frågan som skickas till den externa datakällan. På så sätt kan du avgöra om pushdown inträffar, men inte visa utförandeplanen. Att visa fjärrfrågan kräver inte TF6408.

Notera

För Hadoop och Azure Storage returnerar read_command alltid NULL.

Du kan köra följande fråga och använda start_time/end_time och read_command för att identifiera frågan som undersöks:

SELECT execution_id, start_time, end_time, read_command
FROM sys.dm_exec_external_work
ORDER BY execution_id desc;

Obs.

En begränsning för metoden sys.dm_exec_external_work är att fältet read_command i DMV är begränsat till 4 000 tecken. Om frågan är tillräckligt lång kan read_command komma att avkortas innan du kan se WHERE/JOIN/aggregationsfunktionen i read_command.

Pushdown för filterpredikat (vy med DMV)

Överväg den fråga som användes i föregående exempel på filterpredikat:

SELECT *
FROM [Person].[BusinessEntity] be
WHERE be.BusinessEntityID = 17907;

Med pushdown av filter (vy med DMV)

Du kan avgöra om filterpredikatet trycks ner genom att kontrollera read_command i DMV. Du ser något som liknar det här exemplet:

SELECT [T1_1].[BusinessEntityID] AS [BusinessEntityID], [T1_1].[rowguid] AS [rowguid], 
  [T1_1].[ModifiedDate] AS [ModifiedDate] FROM 
  (SELECT [T2_1].[BusinessEntityID] AS [BusinessEntityID], [T2_1].[rowguid] AS [rowguid], 
    [T2_1].[ModifiedDate] AS [ModifiedDate] 
FROM [AdventureWorks2022].[Person].[BusinessEntity] AS T2_1 
WHERE ([T2_1].[BusinessEntityID] = CAST ((17907) AS INT))) AS T1_1;

WHERE-satsen finns i kommandot som skickas till den externa datakällan, vilket innebär att filterpredikatet utvärderas vid den externa datakällan. Filtrering på datamängden inträffade vid den externa datakällan och endast den filtrerade datauppsättningen hämtades av PolyBase.

Utan pushdown av filter (vy med DMV)

Om pushdown inte sker ser du något i stil med:

SELECT "BusinessEntityID","rowguid","ModifiedDate" FROM "AdventureWorks2022"."Person"."BusinessEntity"

Det finns ingen WHERE-sats i kommandot som skickas till den externa datakällan, så filterpredikatet trycks inte ned. Filtrering på hela datamängden inträffade på SQL Server-sidan efter att datauppsättningen hämtades av PolyBase.

Nedtryckning av JOIN (datavy med DMV)

Överväg den fråga som användes i föregående JOIN-exempel:

SELECT be.BusinessEntityID, bea.AddressID
FROM [Person].[BusinessEntity] be
INNER JOIN [Person].[BusinessEntityAddress] bea ON be.BusinessEntityID = bea.BusinessEntityID;

Med pushdown av koppling (vy med DMV)

Om JOIN skickas ned till den externa datakällan ser du ungefär så här:

SELECT [T1_1].[BusinessEntityID] AS [BusinessEntityID], [T1_1].[AddressID] AS [AddressID] 
FROM (SELECT [T2_2].[BusinessEntityID] AS [BusinessEntityID], [T2_1].[AddressID] AS [AddressID] 
FROM [AdventureWorks2022].[Person].[BusinessEntityAddress] AS T2_1 
INNER JOIN  [AdventureWorks2022].[Person].[BusinessEntity] AS T2_2  
ON ([T2_1].[BusinessEntityID] = [T2_2].[BusinessEntityID])) AS T1_1;

JOIN-satsen finns i kommandot som skickas till den externa datakällan, så JOIN skickas nedåt. Kopplingen till datamängden inträffade vid den externa datakällan och endast den datauppsättning som matchar kopplingsvillkoret hämtades av PolyBase.

Utan pushdown av koppling (vy med DMV)

Om pushdown för kopplingen inte sker kommer du att se att det finns två olika förfrågningar som körs mot den externa datakällan.

SELECT [T1_1].[BusinessEntityID] AS [BusinessEntityID], [T1_1].[AddressID] AS [AddressID] 
FROM [AdventureWorks2022].[Person].[BusinessEntityAddress] AS T1_1;

SELECT [T1_1].[BusinessEntityID] AS [BusinessEntityID] FROM [AdventureWorks2022].[Person].[BusinessEntity] AS T1_1;

Anslutningen till de två datauppsättningarna inträffade på SQL Server-sidan, efter att båda datauppsättningarna har hämtats av PolyBase.

Pushdown av sammansättning (vy med DMV)

Tänk på följande fråga, som använder en aggregeringsfunktion:

SELECT SUM([Quantity]) as Quant
FROM [AdventureWorks2022].[Production].[ProductInventory];

Med nedtryckning av aggregering (vy med DMV)

Om pushdown för aggregeringen sker visas aggregeringsfunktionen i read_command. Till exempel:

SELECT [T1_1].[col] AS [col] FROM (SELECT SUM([T2_1].[Quantity]) AS [col] 
FROM [AdventureWorks2022].[Production].[ProductInventory] AS T2_1) AS T1_1

Aggregeringsfunktionen finns i kommandot som skickas till den externa datakällan, så aggregeringen skickas nedåt. Aggregeringen inträffade vid den externa datakällan och endast den aggregerade datamängden hämtades av PolyBase.

Utan pushdown av aggregering (visning med DMV)

Om pushdown för aggregeringen inte sker visas inte aggregeringsfunktionen i read_command. Till exempel:

SELECT "Quantity" FROM "AdventureWorks2022"."Production"."ProductInventory"

Aggregeringen utfördes i SQL Server efter att den oaggregerade datamängden hämtades av PolyBase.

Nästa steg

• PolyBase-felsökning
• PolyBase-fel och möjliga lösningar