Prestandajustering med cachelagring av resultatuppsättningar

När cachelagring av resultatuppsättningar är aktiverat cachelagrar dedikerad SQL-pool automatiskt frågeresultat i användardatabasen för repetitiv användning. Detta gör att efterföljande frågekörningar kan hämta resultat direkt från den bevarade cachen, så omberäkning behövs inte. Cachelagring av resultatuppsättningar förbättrar frågeprestanda och minskar användningen av beräkningsresurser. Dessutom använder frågor som använder cachelagrade resultatuppsättningar inte några samtidighetsfack och räknas därför inte mot befintliga samtidighetsgränser. För säkerhet kan användarna bara komma åt cachelagrade resultat om de har samma behörigheter för dataåtkomst som de användare som skapar cachelagrade resultat. Cachelagring av resultatuppsättningar är av som standard på databas- och sessionsnivåerna.

Anteckning

Cachelagring av resultatuppsättningar ska inte användas tillsammans med DECRYPTBYKEY. Om den här kryptografiska funktionen måste användas kontrollerar du att cachelagringen för resultatuppsättningen är inaktiverad (antingen på sessionsnivå eller databasnivå) vid tidpunkten för körningen.

Nyckelkommandon

Aktivera/inaktivera cachelagring av resultatuppsättningar för en användardatabas

Aktivera/INAKTIVERA cachelagring av resultatuppsättningar för en session

Kontrollera storleken på cachelagrad resultatuppsättning

Rensa cacheminnet

Vad cachelagras inte

När cachelagring av resultatuppsättningar har aktiverats för en databas cachelagras resultaten för alla frågor tills cacheminnet är fullt, förutom följande frågor:

• Frågor med inbyggda funktioner eller körningsuttryck som inte är deterministiska, även om bastabellernas data eller fråga inte ändras. Till exempel DateTime.Now(), GetDate().
• Frågor som använder användardefinierade funktioner
• Frågor med hjälp av tabeller med säkerhet på radnivå
• Frågor som returnerar data med radstorlek som är större än 64 KB
• Frågor som returnerar stora data i storlek (>10 GB)

Anteckning

• Vissa icke-deterministiska funktioner och körningsuttryck kan vara deterministiska för repetitiva frågor mot samma data. Till exempel ROW_NUMBER().
• Använd ORDER BY i frågan om ordningen/sekvensen för rader i frågeresultatuppsättningen är viktig för din programlogik.
• Om data i ORDER BY-kolumnerna inte är unika finns det ingen garanterad radordning för rader med samma värden i ORDER BY-kolumnerna, oavsett om cachelagring av resultatuppsättningar är aktiverat eller inaktiverat.

Viktigt

Åtgärder för att skapa resultatuppsättningscache och hämta data från cachen sker på kontrollnoden för en dedikerad SQL-poolinstans. När cachelagring av resultatuppsättningar är aktiverat kan frågor som returnerar stora resultatuppsättningar (till exempel >1 GB) orsaka hög begränsning på kontrollnoden och sakta ned det övergripande frågesvaret på instansen. Dessa frågor används ofta vid datautforskning eller ETL-åtgärder. För att undvika att betona kontrollnoden och orsaka prestandaproblem bör användarna inaktivera cachelagring av resultatuppsättningar i databasen innan de kör dessa typer av frågor.

Kör den här frågan för den tid det tar för resultatuppsättningens cachelagringsåtgärder för en fråga:

SELECT step_index, operation_type, location_type, status, total_elapsed_time, command
FROM sys.dm_pdw_request_steps
WHERE request_id  = <'request_id'>;

Här är ett exempel på utdata för en fråga som körs med cachelagring av resultatuppsättningen inaktiverad.

Här är ett exempel på utdata för en fråga som körs med cachelagring av resultatuppsättning aktiverat.

När cachelagrade resultat används

Cachelagrad resultatuppsättning återanvänds för en fråga om alla följande krav är uppfyllda:

• Användaren som kör frågan har åtkomst till alla tabeller som refereras i frågan.
• Det finns en exakt matchning mellan den nya frågan och den tidigare frågan som genererade resultatuppsättningens cacheminne.
• Det finns inga data- eller schemaändringar i tabellerna där den cachelagrade resultatuppsättningen genererades från.

Kör det här kommandot för att kontrollera om en fråga kördes med en resultatcacheträff eller -miss. Kolumnen result_cache_hit returnerar 1 för cacheträff, 0 för cachemiss och negativa värden av orsaker till varför cachelagring av resultatuppsättningar inte användes. Mer information finns i sys.dm_pdw_exec_requests .

SELECT request_id, command, result_cache_hit FROM sys.dm_pdw_exec_requests
WHERE request_id = <'Your_Query_Request_ID'>

Hantera cachelagrade resultat

Den maximala storleken på resultatuppsättningens cacheminne är 1 TB per databas. Cachelagrade resultat ogiltigförklaras automatiskt när underliggande frågedata ändras.

Cacheborttagningen hanteras automatiskt av en dedikerad SQL-pool enligt det här schemat:

• Var 48:e timme om resultatuppsättningen inte har använts eller har ogiltigförklarats.
• När resultatuppsättningens cache närmar sig den maximala storleken.

Användarna kan tömma hela resultatuppsättningens cache manuellt med något av följande alternativ:

• Inaktivera cachefunktionen för resultatuppsättningen för databasen
• Kör DBCC DROPRESULTSETCACHE när du är ansluten till databasen

Om du pausar en databas töms inte cachelagrad resultatuppsättning.

Nästa steg

Fler utvecklingstips finns i utvecklingsöversikt.