Megosztás a következőn keresztül:


Hogyan állapíthatja meg, hogy külső nyomás történt-e?

Ez a cikk azt ismerteti, hogyan állapítható meg, hogy egy PolyBase-lekérdezésnek előnyös-e a leküldés a külső adatforrásba. További információért a külső pushdown műveletekről lásd: Leküldéses számítások a PolyBase-ben.

A lekérdezésem kihasználja a külső push-down technológiát?

A továbbított számítás javítja a külső adatforrásokon lévő lekérdezések teljesítményét. Bizonyos számítási feladatokat a rendszer a külső adatforrásba delegál ahelyett, hogy az SQL Server-példányba kerül. Különösen a szűrés és a leküldéses csatlakozás esetében az SQL Server-példány számítási feladatai jelentősen csökkenthetők.

A PolyBase leküldési számítása jelentősen javíthatja a lekérdezés teljesítményét. Ha egy PolyBase-lekérdezés lassan fut, ellenőrizze, hogy a PolyBase-lekérdezés leküldése történik-e.

A végrehajtási tervben három különböző forgatókönyvben figyelheti meg a leküldést:

  • Szűrési predikátum leküldése
  • Csatlakozás leküldéshez
  • Összesítés optimalizálása

Az SQL Server 2019 (15.x) két új funkciója lehetővé teszi a rendszergazdák számára, hogy megállapíthassák, hogy egy PolyBase-lekérdezés le van-e küldve a külső adatforrásba:

Ez a cikk részletesen bemutatja, hogyan használhatja a két használati eset mindegyikét három leküldéses forgatókönyv mindegyikéhez.

Korlátozások

Az alábbi korlátozások befolyásolják, hogy mit lehet leküldeni külső adatforrásokra a PolyBase leküldéses számítások alkalmazásával.

  • Egyes T-SQL-függvények megakadályozhatják a leküldést. További információkért lásd a PolyBase funkcióit és korlátait.

  • Az egyéb módon leküldhető T-SQL-függvények listáját a PolyBase Leküldéses számítások című témakörben találja.

Használja a 6408 nyomkövetési jelzőt.

Alapértelmezés szerint a becsült végrehajtási terv nem teszi elérhetővé a távoli lekérdezési tervet. Csak a távoli lekérdezéskezelő objektum jelenik meg. Például egy becsült végrehajtási terv az SQL Server Management Studióból (SSMS):

Képernyőkép egy becsült végrehajtási tervről az SSMS-ben.

Az SQL Server 2019 (15.x) verziójától kezdve az új 6408 számú jelzősávot globálisan engedélyezheti a DBCC TRACEONhasználatával. Például:

DBCC TRACEON (6408, -1);

Ez a nyomkövetési jelző csak a becsült végrehajtási tervekkel működik, és nincs hatással a tényleges végrehajtási tervekre. Ez a nyomkövetési jelző a Távoli lekérdezés operátorral kapcsolatos információkat jeleníti meg, amelyek bemutatják, hogy mi történik a távoli lekérdezési fázisban.

A végrehajtási terv áttekintése a nyilak iránya szerint jobbról balra olvasható. Ha egy operátor egy másik operátortól jobbra van, akkor előtte van. Ha egy operátor egy másik operátortól balra van, akkor az utána lesz.

  • Az SSMS-ben jelölje ki a lekérdezést, és válassza a Becsült végrehajtási terv megjelenítése lehetőséget az eszköztáron, vagy használja a CtrlL+.

Az alábbi példák mindegyike tartalmazza az SSMS kimenetét.

A szűrő predikátumának átdobása (végrehajtási terv megtekintése)

Fontolja meg a következő lekérdezést, amely a WHERE záradékban egy szűrő predikátumot használ:

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

Ha a szűrő predikátuma leküldésre kerül, a szűrő operátor a végrehajtási terv külső operátora előtt jelenik meg. Ha a szűrőoperátor a külső operátor előtt van, a szűrés azelőtt történik, hogy a lekérdezési motor adatokat kér le a külső adatforrásból, ami azt jelenti, hogy a szűrő predikátum le lesz küldve.

A szűrő predikátum leküldésével (végrehajtási terv megtekintése)

Ha engedélyezi a 6408 nyomkövetési jelzőt, további információ jelenik meg a becsült végrehajtási terv kimenetében.

Az SSMS-ben a távoli lekérdezési terv 2. lekérdezésként (sp_execute_memo_node_1) jelenik meg a becsült végrehajtási tervben. Megfelel az 1. lekérdezés távoli lekérdezési operátorának. Például:

Képernyőkép egy végrehajtási tervről az SSMS-ből származó szűrő predikátum leküldésével.

Szűrő predikátum áthelyezése nélkül (végrehajtási terv megtekintése)

Ha a szűrő predikátum nincs lejjebb tolva, a szűrőoperátor a külső operátor után jelenik meg.

Az SSMS becsült végrehajtási terve:

Képernyőkép egy SSMS-beli végrehajtási tervről szűrési predikátum-továbbítás nélkül.

A JOIN művelet közvetlen végrehajtása

Fontolja meg az alábbi lekérdezést, amely az JOIN operátort használja két külső táblához ugyanazon a külső adatforráson:

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

Ha a lekérdezési motor leküldi a JOIN műveletet a külső adatforrásba, az Illesztés operátor megjelenik a külső operátor előtt. Ebben a példában [BusinessEntity] és [BusinessEntityAddress] is külső táblák.

Pushdown-alapú csatlakozás (végrehajtási terv megtekintése)

Az SSMS becsült végrehajtási terve:

Képernyőkép egy végrehajtási tervről a SQL Server Management Studio-ban, ahol a csatolás optimalizálása történik.

Csatlakozás leküldése nélkül (megtekintés végrehajtási tervvel)

Ha a lekérdezési motor nem küldi le a JOIN műveletet a külső adatforrásba, az Illesztés operátor a külső operátor után jelenik meg. Az SSMS-ben a lekérdezési terv a külső operátort sp_execute_memo_node is tartalmazza. Ez az operátor az 1. lekérdezés távoli lekérdezési operátorának része.

Az SSMS becsült végrehajtási terve:

Képernyőkép az SSMS-ből való csatlakozás nélküli végrehajtási tervről.

Az összesítés optimalizálása (végrehajtási terv szerint)

Fontolja meg a következő lekérdezést, amely egy összesítő függvényt használ:

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

Az összesítések leküldésével (megtekintés végrehajtási tervvel)

Ha a rendszer leküldi az aggregációt, az összesítő operátor a külső operátor előtt jelenik meg. Ha az aggregációs operátor a külső operátor előtt van, a lekérdezés végrehajtja az összesítést, mielőtt adatokat választ ki a külső adatforrásból, ami azt jelenti, hogy a rendszer leküldi az összesítést.

Az SSMS becsült végrehajtási terve:

Képernyőkép egy aggregátumok leküldésével végzett végrehajtási tervről az SSMS-ből.

Összesítés leküldése nélkül (megtekintés végrehajtási tervvel)

Ha az aggregációt nem küldi le, az aggregációs operátor a külső operátor után helyezkedik el.

Az SSMS becsült végrehajtási terve:

Képernyőkép egy végrehajtási tervről az SSMS összesítő leküldése nélkül.

DMV használata

Az SQL Server 2019 (15.x) és újabb verzióiban a read_commandsys.dm_exec_external_work DMV oszlopa megjeleníti a külső adatforrásnak küldött lekérdezést. Megállapíthatja, hogy a leküldés történik-e, de nem teszi közzé a végrehajtási tervet. A távoli lekérdezés megtekintéséhez nincs szükség a 6408-at jelző nyomkövetési jelzőre.

Jegyzet

A Hadoop és az Azure Storage esetében a read_command mindig NULLad vissza.

Futtassa a következő lekérdezést, és használja az start_time/end_time és read_command az értékeket a vizsgált lekérdezés azonosításához:

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

Jegyzet

A sys.dm_exec_external_work metódus egyik korlátozása, hogy a read_command DMV mezője legfeljebb 4000 karakter hosszúságú lehet. Ha a lekérdezés elég hosszú, előfordulhat, hogy a read_command csonkolódik, mielőtt megjelenne a WHERE, JOIN, vagy az aggregációs függvény a read_command-ban.

A szűrő predikátum leküldése (megtekintés dinamikus kezelési nézetekkel)

Vegye figyelembe az előző szűrő predikátumában használt lekérdezést:

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

Szűrőleküldés (megtekintés DMV-vel)

A DMV-ben ellenőrizheti read_command, hogy a szűrő predikátumának leküldése történik-e. A következő lekérdezéshez hasonló példa jelenik meg:

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;

A külső adatforrásnak küldött parancs tartalmazza a WHERE záradékot, ami azt jelenti, hogy a szűrő predikátum kiértékelése a külső adatforrásban történik. Az adathalmaz szűrése a külső adatforrásban történik, a PolyBase pedig csak a szűrt adathalmazt kéri le.

Szűrő leküldése nélkül (megtekintés DMV segítségével)

Ha a pushdown nem történik meg, valami ilyesmit fog látni:

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

A külső adatforrásnak küldött parancs nem tartalmaz záradékot WHERE , így a szűrő predikátumát nem küldi le a rendszer. A teljes adathalmaz szűrése az SQL Server oldalán történik, miután a PolyBase lekérte az adathalmazt.

A JOIN művelet optimalizálása (nézet Dynamic Management Views-szel)

Vegye figyelembe az előző JOIN példában használt lekérdezést:

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

Csatlakozás leküldése (DMV nézet)

Ha a JOIN-t leküldi a külső adatforrásba, a következőhöz hasonlót fog látni:

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;

A külső adatforrásnak küldött parancs tartalmazza a JOIN záradékot, ezért a JOIN mélyebbre kerül. A külső adatforrás kezeli az illesztéseket az adathalmazon, a PolyBase pedig csak az illesztési feltételnek megfelelő adathalmazt kéri le.

Csatlakozás leküldése nélkül (megtekintés DMV-vel)

Ha az illesztés végrehajtása nem történik meg, két különböző lekérdezés fut le a külső adatforráson.

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;

Az SQL Server-oldal kezeli a két adathalmaz összekapcsolását, miután a PolyBase mindkét adathalmazt lekérte.

Az aggregáció leküldése (DMV nézet)

Fontolja meg a következő lekérdezést, amely egy összesítő függvényt használ:

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

Az aggregálás leküldésével (DMV nézet)

Ha az aggregáció végrehajtása leküldéssel történik, az aggregációs függvényt látni fogja a read_command-ban. Például:

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

Az aggregációs függvény a külső adatforrásnak küldött parancsban található, így a rendszer leküldi az összesítést. Az összesítés a külső adatforráson történik, a PolyBase pedig csak az összesített adatkészletet kéri le.

Az összesítés áttolása nélkül (DMV nézet)

Ha az aggregáció továbbítása nem történik meg, nem látja az aggregációs függvényt a read_command. Például:

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

A PolyBase lekéri a nem összesített adathalmazt, és az SQL Server végrehajtja az összesítést.