303
9.3 Cache des requêtes ad hoc
ces plans à l’aide de la fonction sys.dm_exec_cached_plan_dependent_objects, à
laquelle vous passez en paramètre un plan_handle venant de
sys.dm_exec_cached_plans. Si la procédure est en cours d’exécution plusieurs fois
simultanément, vous trouverez plusieurs références au même plan_handle.
Les plans compilés contiennent un tableau d’instructions SQL. Chaque ordre
SQL dans la procédure ou le batch sont compilés séparément dans des Cstmt, ou
Compiled Statements. Les plans d’exécution génèrent des Xstmts, les versions runtime
des Cstmt 1 . Voici une requête pour voir la taille et l’utilisation des différents objets :
SELECT
COUNT(*) as cnt,
SUM(size_in_bytes) / 1024 as total_kb,
MAX(usecounts) as max_usecounts,
AVG(usecounts) as avg_usecounts,
CASE GROUPING(cacheobjtype)
WHEN 1 THEN 'TOTAL'
ELSE cacheobjtype
END AS cacheobjtype,
CASE GROUPING(objtype)
WHEN 1 THEN 'TOTAL'
ELSE objtype
END AS objtype
FROM sys.dm_exec_cached_plans
GROUP BY cacheobjtype, objtype
WITH ROLLUP
Le code de la procédure ou du batch est stocké dans un cache à part, le SQL
Manager Cache (SQLMGR). Il s’agit d’un stockage différent du plan réellement utilisé à l’exécution. Vous pouvez voir les informations générales de ce cache à l’aide de
cette requête :
SELECT *
FROM sys.dm_os_memory_objects
WHERE type = 'MEMOBJ_SQLMGR'
Pourquoi maintenir le code de la requête séparément du plan compilé ? Simplement parce que ce plan peut changer, selon l’état de la session, c’est-à-dire le contexte d’exécution. Il est important de s’y arrêter, car cela influe sur la possibilité qu’a
SQL Server de réutiliser un plan en cache.
9.3.1 Réutilisation des plans
Imaginons que nous exécutions le même code, dans deux sessions qui comportent
des options de session différentes (SET…, comme DATEFORMAT, ANSI NULLS…), ou
dans la même session, avec un changement d’option intermédiaire. Par exemple :
1. Si vous voulez entrer plus en détail dans l’observation des éléments du cache, une série très
complète d’articles a été publiée dans le blog de l’équipe Microsoft « SQL Programmability & API
Development » : http://blogs.msdn.com/sqlprogrammability/
9.3 Cache des requêtes ad hoc
ces plans à l’aide de la fonction sys.dm_exec_cached_plan_dependent_objects, à
laquelle vous passez en paramètre un plan_handle venant de
sys.dm_exec_cached_plans. Si la procédure est en cours d’exécution plusieurs fois
simultanément, vous trouverez plusieurs références au même plan_handle.
Les plans compilés contiennent un tableau d’instructions SQL. Chaque ordre
SQL dans la procédure ou le batch sont compilés séparément dans des Cstmt, ou
Compiled Statements. Les plans d’exécution génèrent des Xstmts, les versions runtime
des Cstmt 1 . Voici une requête pour voir la taille et l’utilisation des différents objets :
SELECT
COUNT(*) as cnt,
SUM(size_in_bytes) / 1024 as total_kb,
MAX(usecounts) as max_usecounts,
AVG(usecounts) as avg_usecounts,
CASE GROUPING(cacheobjtype)
WHEN 1 THEN 'TOTAL'
ELSE cacheobjtype
END AS cacheobjtype,
CASE GROUPING(objtype)
WHEN 1 THEN 'TOTAL'
ELSE objtype
END AS objtype
FROM sys.dm_exec_cached_plans
GROUP BY cacheobjtype, objtype
WITH ROLLUP
Le code de la procédure ou du batch est stocké dans un cache à part, le SQL
Manager Cache (SQLMGR). Il s’agit d’un stockage différent du plan réellement utilisé à l’exécution. Vous pouvez voir les informations générales de ce cache à l’aide de
cette requête :
SELECT *
FROM sys.dm_os_memory_objects
WHERE type = 'MEMOBJ_SQLMGR'
Pourquoi maintenir le code de la requête séparément du plan compilé ? Simplement parce que ce plan peut changer, selon l’état de la session, c’est-à-dire le contexte d’exécution. Il est important de s’y arrêter, car cela influe sur la possibilité qu’a
SQL Server de réutiliser un plan en cache.
9.3.1 Réutilisation des plans
Imaginons que nous exécutions le même code, dans deux sessions qui comportent
des options de session différentes (SET…, comme DATEFORMAT, ANSI NULLS…), ou
dans la même session, avec un changement d’option intermédiaire. Par exemple :
1. Si vous voulez entrer plus en détail dans l’observation des éléments du cache, une série très
complète d’articles a été publiée dans le blog de l’équipe Microsoft « SQL Programmability & API
Development » : http://blogs.msdn.com/sqlprogrammability/