web-dev-qa-db-fra.com

Octroi excessif de mémoire de tri

Pourquoi cette simple requête reçoit-elle autant de mémoire?

-- Demo table
CREATE TABLE dbo.Test
(
    TID integer IDENTITY NOT NULL,
    FilterMe integer NOT NULL,
    SortMe integer NOT NULL,
    Unused nvarchar(max) NULL,

    CONSTRAINT PK_dbo_Test_TID
    PRIMARY KEY CLUSTERED (TID)
);
GO
-- 100,000 example rows
INSERT dbo.Test WITH (TABLOCKX)
    (FilterMe, SortMe)
SELECT TOP (100 * 1000)
    CHECKSUM(NEWID()) % 1000,
    CHECKSUM(NEWID())
FROM sys.all_columns AS AC1
CROSS JOIN sys.all_columns AS AC2;
GO    
-- Query
SELECT
    T.TID,
    T.FilterMe,
    T.SortMe,
    T.Unused
FROM dbo.Test AS T 
WHERE 
    T.FilterMe = 567
ORDER BY 
    T.SortMe;

Pour environ 50 lignes, l'optimiseur réserve près de 500 Mo pour le tri:

Estimated plan

sql-serverexecution-planmemory-grant
46
Paul White 9

Il s'agit d'un bogue dans SQL Server (de 2008 à 2014 inclus).

Mon rapport de bogue est ici.

La condition de filtrage est poussée vers le bas dans l'opérateur de balayage en tant que prédicat résiduel, mais la mémoire accordée pour le tri est calculée par erreur sur la base de estimation de cardinalité du préfiltre .

Pour illustrer le problème, nous pouvons utiliser (non documenté et non pris en charge) indicateur de trace 9130 pour empêcher le filtre d'être poussé vers le bas dans l'analyse opérateur. La mémoire accordée au tri est désormais correctement basée sur la cardinalité estimée de la sortie du filtre, et non sur l'analyse:

SELECT
    T.TID,
    T.FilterMe,
    T.SortMe,
    T.Unused
FROM dbo.Test AS T 
WHERE 
    T.FilterMe = 567
ORDER BY 
    T.SortMe
OPTION (QUERYTRACEON 9130); -- Not for production systems!

Estimated plan

Pour un système de production , des mesures devront être prises pour éviter la forme de plan problématique (un filtre poussé dans un scan avec un tri sur une autre colonne). Une façon de procéder consiste à fournir un index sur la condition du filtre et/ou à fournir l'ordre de tri requis.

-- Index on the filter condition only
CREATE NONCLUSTERED INDEX IX_dbo_Test_FilterMe
ON dbo.Test (FilterMe);

Avec cet index en place, l'allocation de mémoire souhaitée pour le tri est seulement 928 Ko :

With filter index

En allant plus loin, l'index suivant peut éviter complètement le tri ( zéro allocation de mémoire):

-- Provides filtering and sort order
-- nvarchar(max) column deliberately not INCLUDEd
CREATE NONCLUSTERED INDEX IX_dbo_Test_FilterMe_SortMe
ON dbo.Test (FilterMe, SortMe);

With filter and sort index

Testé et bogue confirmé sur les versions suivantes de SQL Server x64 Developer Edition:

2014   : 12.00.2430 (RTM CU4)
2012   : 11.00.5556 (SP2 CU3)
2008R2 : 10.50.6000 (SP3)
2008   : 10.00.6000 (SP4)

Cela a été corrigé dans SQL Server 2016 Service Pack 1 . Les notes de version incluent les éléments suivants:

Numéro de bogue VSTS 8024987
Les analyses de table et d'index avec le prédicat Push down ont tendance à surestimer l'allocation de mémoire pour l'opérateur parent.

Testé et confirmé fixé sur:

  • Microsoft SQL Server 2016 (SP1) - 13.0.4001.0 (X64) Developer Edition
  • Microsoft SQL Server 2014 (SP2-CU3) 12.0.5538.0 (X64) Developer Edition

Les deux modèles CE.

42
Paul White 9

À partir de SQL 2012, vous pourriez rechercher une grande différence entre SerialRequiredMemory et SerialDesiredMemory, par exemple quelque chose comme ceci:

-- Search plan cache for Memory Grant issues
IF OBJECT_ID('tempdb..#tmp') IS NOT NULL DROP TABLE #tmp

-- Collect more info about the plan here if required, eg usecounts, objtype etc, 
SELECT IDENTITY( INT, 1, 1 ) rowId, query_plan
INTO #tmp
FROM sys.dm_exec_cached_plans cp WITH(NOLOCK)
    CROSS APPLY sys.dm_exec_query_plan(plan_handle)
GO


;WITH cte AS
(
SELECT
    rowId,
    query_plan,
    m.c.value ('@SerialRequiredMemory', 'INT' ) AS SerialRequiredMemory,
    m.c.value ('@SerialDesiredMemory', 'INT' ) AS SerialDesiredMemory

FROM #tmp t
    CROSS APPLY t.query_plan.nodes ( '//*:MemoryGrantInfo[@SerialDesiredMemory[. > 0]]' ) m(c)
), cte2 AS (
SELECT *,
    CAST( CAST( SerialDesiredMemory AS DECIMAL(10,2) ) / CAST( SerialRequiredMemory AS DECIMAL(10,2) ) AS DECIMAL(10,2) ) Desired_to_Required_ratio
FROM cte
)
SELECT TOP 20
    rowId,
    query_plan,
    SerialRequiredMemory SerialRequiredMemory_KB,
    SerialDesiredMemory SerialDesiredMemory_KB,
    CAST( SerialRequiredMemory / 1024. AS DECIMAL(10,2) ) SerialRequiredMemory_MB,
    CAST( SerialDesiredMemory / 1024. AS DECIMAL(10,2) ) SerialDesiredMemory_MB,
    Desired_to_Required_ratio
FROM cte2
WHERE Desired_to_Required_ratio > 100
ORDER BY Desired_to_Required_ratio DESC

Quelques notes supplémentaires sur ces nouveaux attributs ici . Cette requête est un peu approximative et prête, mais elle a récupéré la requête de tri excessive de ma boîte de développement SQL Server 2014 avec un ratio de 975,47 plus quelques autres plans époustouflants. Le rapport "normal" (du moins d'après mes tests limités) semble être d'environ 1.

HTH

5
wBob

Merci pour votre aide. J'ai pensé envoyer une version mise à jour de la requête ci-dessus que nous avons trouvée utile.

-- Search plan cache for Memory Grant issues
IF OBJECT_ID('tempdb..#tmp') IS NOT NULL DROP TABLE #tmp

-- Collect more info about the plan here if required, eg usecounts, objtype etc, 
SELECT IDENTITY( INT, 1, 1 ) rowId, query_plan, db = DB_NAME(CAST(pa.value AS int))
INTO #tmp
FROM sys.dm_exec_cached_plans cp WITH(NOLOCK)
    CROSS APPLY sys.dm_exec_query_plan(cp.plan_handle)
    OUTER APPLY sys.dm_exec_plan_attributes(cp.plan_handle) pa 
    WHERE pa.attribute = 'dbid' 
GO

;WITH cte AS
(
SELECT
    rowId,
    query_plan,
    m.c.value ('@SerialRequiredMemory', 'INT' ) AS SerialRequiredMemory,
    m.c.value ('@SerialDesiredMemory', 'INT' ) AS SerialDesiredMemory,
    db
FROM #tmp t
    CROSS APPLY t.query_plan.nodes ( '//*:MemoryGrantInfo[@SerialDesiredMemory[. > 0]]' ) m(c)
), cte2 AS (
SELECT *,
    CAST( CAST( SerialDesiredMemory AS DECIMAL(10,2) ) / CAST( SerialRequiredMemory AS DECIMAL(10,2) ) AS DECIMAL(10,2) ) Desired_to_Required_ratio
FROM cte
)
SELECT TOP 20
    rowId,
    query_plan,
    SerialRequiredMemory SerialRequiredMemory_KB,
    SerialDesiredMemory SerialDesiredMemory_KB,
    CAST( SerialRequiredMemory / 1024. AS DECIMAL(10,2) ) SerialRequiredMemory_MB,
    CAST( SerialDesiredMemory / 1024. AS DECIMAL(10,2) ) SerialDesiredMemory_MB,
    Desired_to_Required_ratio,
    db
FROM cte2
WHERE Desired_to_Required_ratio > 100
ORDER BY Desired_to_Required_ratio DESC
3
Doug B