Erkennen, ob ein externer Pushdown aufgetreten ist

In diesem Artikel wird erläutert, wie Sie ermitteln können, ob eine PolyBase-Abfrage von Pushdown auf die externe Datenquelle profitiert. Weitere Informationen zu externen Pushdowns finden Sie unter Weitergabeberechnungen in PolyBase.

Profitiert meine Abfrage von einem externen Pushdown?

Weitergabeberechnungen verbessern die Leistung von Abfragen in externen Datenquellen. Bestimmte Berechnungsaufgaben werden nicht an die SQL Server-Instanz weitergegeben, sondern an die externe Datenquelle delegiert. Dadurch kann die Workload auf der SQL Server-Instanz insbesondere bei Filtervorgängen und Join-Pushdowns erheblich reduziert werden.

Eine PolyBase-Pushdownberechnung kann die Leistung der Abfrage deutlich verbessern. Wird eine PolyBase-Abfrage langsam ausgeführt, sollten Sie ermitteln, ob für die PolyBase-Abfrage ein Pushdown erfolgt.

In den folgenden drei Szenarios kann es zu einem Pushdown im Ausführungsplan kommen:

• Pushdown des Filterprädikats
• Pushdown von JOIN
• Pushdown der Aggregation

Es wurden zwei neue Features von SQL Server 2019 (15.x) eingeführt, damit Administratoren ermitteln können, ob eine PolyBase-Abfrage an die externe Datenquelle übertragen wird:

• Anzeigen des geschätzten Ausführungsplans mit Ablaufverfolgungsflag 6408
• Anzeigen von read_command in der dynamischen Verwaltungssicht sys.dm_exec_external_work

Dieser Artikel enthält Details zur Verwendung dieser beiden Anwendungsfälle für jedes von drei Pushdownszenarien.

Verwenden von TF6408

Standardmäßig macht der geschätzte Ausführungsplan den Remoteabfrageplan nicht verfügbar, und es wird nur das Remoteabfrageoperatorobjekt angezeigt. Das folgende Beispiel zeigt einen geschätzten Ausführungsplan in SQL Server Management Studio (SSMS):

Das folgende Beispiel zeigt den geschätzten Ausführungsplan in Azure Data Studio:

Ab SQL Server 2019 (15.x) können Sie ein neues Ablaufverfolgungskennzeichnung 6408 global mit DBCC TRACEON aktivieren. Beispiel:

DBCC TRACEON (6408, -1);  

Dieses Ablaufverfolgungsflag kann nur mit geschätzten Ausführungsplänen verwendet werden und hat keine Auswirkungen auf die tatsächlichen Ausführungspläne. Dieses Ablaufverfolgungskennzeichnung macht Informationen zum Remoteabfrageoperator verfügbar, der anzeigt, was während der Remoteabfragephase geschieht.

Ausführungspläne werden von rechts nach links gelesen (wie durch die Pfeilrichtung angegeben). Ein Operator rechts neben einem anderen Operator befindet sich „vor“ diesem. Ein Operator links neben einem anderen Operator befindet sich „nach“ diesem.

• Markieren Sie in SSMS die Abfrage, und wählen Sie "Geschätzten Ausführungsplan anzeigen" auf der Symbolleiste aus, oder verwenden Sie STRG+L.
• Markieren Sie in Azure Data Studio die Abfrage, und wählen Sie "Erläutern" aus. Betrachten Sie dann die folgenden Szenarien, um zu bestimmen, ob Pushdown aufgetreten ist.

Jedes der folgenden Beispiele enthält die Ausgabe von SSMS und Azure Data Studio.

Pushdown des Filterprädikats (mit Ausführungsplan anzeigen)

Die folgende Abfrage verwendet ein Filterprädikat in der WHERE-Klausel:

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

Wenn der Pushdown des Filter-Prädikats auftritt, liegt der Filteroperator vor dem externen Operator. Wenn sich der Filteroperator vor dem externen Operator befindet, ist die Filterung aufgetreten, bevor die Auswahl aus der externen Datenquelle erfolgt ist, die angibt, dass das Filter-Prädikat nach unten verschoben wurde.

Erfolgter Pushdown des Filterprädikats (mit Ausführungsplan anzeigen)

Ist das Ablaufverfolgungsflag 6408 aktiviert, werden in der Ausgabe des geschätzten Ausführungsplans zusätzliche Informationen angezeigt. Die Ausgabe in SSMS unterscheidet sich von der in Azure Data Studio.

In SSMS wird der Remoteabfrageplan im geschätzten Ausführungsplan als Abfrage 2 (sp_execute_memo_node_1) angezeigt und entspricht dem Remoteabfrageoperator in Abfrage 1. Beispiel:

In Azure Data Studio wird die Ausführung der Remoteabfrage dagegen als einzelner Abfrageplan dargestellt. Beispiel:

Nicht erfolgter Pushdown des Filterprädikats (mit Ausführungsplan anzeigen)

Wird kein Pushdown des Filterprädikats ausgeführt, befindet sich der Filter nach dem externen Operator.

Das folgende Beispiel zeigt einen geschätzten Ausführungsplan in SSMS:

Das folgende Beispiel zeigt einen geschätzten Ausführungsplan in Azure Data Studio:

JOIN-Pushdown

Betrachten Sie die folgende Abfrage, die den JOIN-Operator für zwei externe Tabellen in derselben externen Datenquelle verwendet:

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

Wird ein Pushdown von JOIN an die externe Datenquelle ausgeführt, befindet sich der Join-Operator vor dem externen Operator. In diesem Beispiel sind beide Tabellen und [BusinessEntity] [BusinessEntityAddress] externe Tabellen.

Erfolgter Pushdown von JOIN (mit Ausführungsplan anzeigen)

Das folgende Beispiel zeigt einen geschätzten Ausführungsplan in SSMS:

Das folgende Beispiel zeigt einen geschätzten Ausführungsplan in Azure Data Studio:

Nicht erfolgter Pushdown von JOIN (mit Ausführungsplan anzeigen)

Wird kein Pushdown von JOIN an die externe Datenquelle ausgeführt, befindet sich der Join-Operator nach dem externen Operator. In SSMS befindet sich der externe Operator im Abfrageplan sp_execute_memo_node, der sich im Remoteabfrageoperator in Abfrage 1 befindet. In Azure Data Studio befindet sich der Join-Operator nach dem bzw. den externen Operator(en).

Das folgende Beispiel zeigt einen geschätzten Ausführungsplan in SSMS:

Das folgende Beispiel zeigt einen geschätzten Ausführungsplan in Azure Data Studio:

Pushdown der Aggregation (mit Ausführungsplan anzeigen)

Das folgende Beispiel zeigt eine Abfrage, in der eine Aggregatfunktion verwendet wird:

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

Erfolgter Pushdown der Aggregation (mit Ausführungsplan anzeigen)

Wenn der Pushdown der Aggregation erfolgt, liegt der Aggregationsoperator vor dem externen Operator. Wenn sich der Aggregationsoperator vor dem externen Operator befindet, ist die Aggregation vor dem Abrufen der Auswahl aus der externen Datenquelle aufgetreten, die angibt, dass die Aggregation nach unten verschoben wurde.

Das folgende Beispiel zeigt einen geschätzten Ausführungsplan in SSMS:

Das folgende Beispiel zeigt einen geschätzten Ausführungsplan in Azure Data Studio:

Nicht erfolgter Pushdown der Aggregation (mit Ausführungsplan anzeigen)

Wird kein Pushdown der Aggregation ausgeführt, befindet sich der Aggregationsoperator nach dem externen Operator.

Das folgende Beispiel zeigt einen geschätzten Ausführungsplan in SSMS:

Das folgende Beispiel zeigt einen geschätzten Ausführungsplan in Azure Data Studio:

Verwenden von DMV

In sql Server 2019 (15.x) und höheren Versionen zeigt die read_command Spalte sys.dm_exec_external_work DMV die Abfrage an, die an die externe Datenquelle gesendet wird. Auf diese Weise können Sie ermitteln, ob Pushdown auftritt, aber den Ausführungsplan nicht verfügbar macht. Zum Anzeigen der Remoteabfrage ist TF6408 nicht erforderlich.

Zur Identifikation der aktuell untersuchten Abfrage können Sie die folgende Abfrage mit start_time/end_time und read_command ausführen:

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

Pushdown des Filterprädikats (mit DMV anzeigen)

Das folgende Beispiel zeigt die vorherige Abfrage des Filterprädikats:

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

Erfolgter Pushdown des Filters (mit DMV anzeigen)

Sie können feststellen, ob der Pushdown des Filter-Prädikats erfolgt, indem Sie das read_command DMV überprüfen. Die Ausgabe sollte etwa folgendermaßen aussehen:

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;

Der Befehl, der an die externe Datenquelle gesendet wird, enthält die WHERE-Klausel. Dies bedeutet, dass das Filterprädikat in der externen Datenquelle ausgewertet wird. Die Filterung des Datasets erfolgte in der externen Datenquelle, und es wurde nur das gefilterte Dataset von PolyBase abgerufen.

Nicht erfolgter Pushdown des Filters (mit DMV anzeigen)

Wird kein Pushdown ausgeführt, sollte die Ausgabe etwa folgendermaßen aussehen:

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

Der Befehl, der an die externe Datenquelle gesendet wird, enthält keine WHERE-Klausel. Das bedeutet, dass das Filterprädikat nicht per Pushdown weitergegeben wird. Die Filterung des gesamten Datasets erfolgte in SQL Server, nachdem das Dataset von PolyBase abgerufen wurde.

Pushdown von JOIN (mit DMV anzeigen)

Das folgende Beispiel zeigt die vorherige Abfrage von JOIN:

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

Erfolgter Pushdown von JOIN (mit DMV anzeigen)

Wird ein Pushdown von JOIN an die externe Datenquelle ausgeführt, sollte die Ausgabe etwa folgendermaßen aussehen:

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;

Der Befehl, der an die externe Datenquelle gesendet wird, enthält die JOIN-Klausel. Das bedeutet, dass JOIN per Pushdown weitergegeben wird. Der Join-Vorgang für das Dataset erfolgte in der externen Datenquelle, und es wurde nur das Dataset von PolyBase abgerufen, das der Join-Bedingung entspricht.

Nicht erfolgter Pushdown von JOIN (mit DMV anzeigen)

Wird der Join-Vorgang nicht per Pushdown weitergegeben, werden für die externe Datenquelle zwei verschiedene Abfragen ausgeführt:

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;

Die Verknüpfung der beiden Datasets ist auf der SQL Server-Seite aufgetreten, nachdem beide Datasets von PolyBase abgerufen wurden.

Pushdown der Aggregation (mit DMV anzeigen)

Das folgende Beispiel zeigt eine Abfrage, in der eine Aggregatfunktion verwendet wird:

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

Erfolgter Pushdown der Aggregation (mit DMV anzeigen)

Wenn der Pushdown der Aggregation auftritt, wird die Aggregationsfunktion in der read_command. Beispiel:

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

Der Befehl, der an die externe Datenquelle gesendet wird, enthält die Aggregationsfunktion. Das bedeutet, dass die Aggregation per Pushdown weitergegeben wird. Die Aggregation ist an der externen Datenquelle aufgetreten, und nur das aggregierte Dataset wurde von PolyBase abgerufen.

Nicht erfolgter Pushdown der Aggregation (mit DMV anzeigen)

Wird kein Pushdown der Aggregation ausgeführt, enthält read_command die Aggregationsfunktion nicht. Beispiel:

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

Die Aggregation wurde in SQL Server durchgeführt, nachdem das nicht aggregierte Dataset von PolyBase abgerufen wurde.

Nächste Schritte

• Problembehandlung für PolyBase
• PolyBase-Fehler und mögliche Lösungen