Pourquoi tronquer une table temporaire à la fin de la procédure stockée qui lui crée un espace tempdb libre plus rapidement?
SQL Server met en cache les tables temporaires créées dans les procédures stockées et les renomme simplement lorsque la procédure se termine et est ensuite exécutée. Ma question porte sur le moment où l'espace tempdb est libéré. J'ai lu que le tableau est tronqué à la fin de la procédure . J'ai lu dans les commentaires que c'était géré par session et vu une question sur la nécessité ou non d'un nettoyage répondu sur MSDN . Mais que se passe-t-il s'il n'est jamais exécuté deux fois par la même session?
J'ai également entendu dire qu'il existe un processus de récupération de place en arrière-plan qui libère cet espace une fois que la table est hors de portée.
La troncature d'une table temporaire à la fin de la procédure stockée qui la crée semble entraîner la libération plus rapide de l'espace utilisé par la table dans tempdb que si aucune instruction tronquée n'est utilisée, malgré les attentes contraires. Pourquoi?
Quelles seraient les implications relatives aux performances de l'utilisation ou de la non-utilisation d'une telle instruction tronquée? Lorsque vous utilisez l'isolement SNAPSHOT, tempdb est souvent souligné et je pense que libérer l'espace utilisé dans tempdb à partir d'une grande table temporaire le plus tôt possible empêcherait une croissance autrement inutile de tempdb. Ces économies d'espace potentielles se feraient-elles au détriment des performances?
Voici du code pour reproduire le problème (principalement de @TheGameiswar, avec quelques modifications):
SET NOCOUNT ON;
GO
ALTER PROC usp_test
AS
BEGIN
IF object_id('tempdb..#temp') IS NOT NULL
DROP TABLE #temp
SELECT *
INTO #temp
FROM [dbo].[Event_28] -- This is a table with 15313 rows, using 35648 KB according to sp_spaceused
--SELECT SUM(user_object_reserved_page_count) AS [user object pages used]
-- ,(SUM(user_object_reserved_page_count) * 1.0 / 128) AS [user object space in MB]
-- ,getdate() AS BeforeTruncate
--FROM tempdb.sys.dm_db_file_space_usage;
-- TRUNCATE TABLE #temp
--SELECT SUM(user_object_reserved_page_count) AS [user object pages used]
-- ,(SUM(user_object_reserved_page_count) * 1.0 / 128) AS [user object space in MB]
-- ,getdate() AS AfterTruncate
--FROM tempdb.sys.dm_db_file_space_usage;
END
GO
SELECT SUM(user_object_reserved_page_count) AS [user object pages used]
,(SUM(user_object_reserved_page_count) * 1.0 / 128) AS [user object space in MB]
,getdate() AS 'before'
FROM tempdb.sys.dm_db_file_space_usage;
EXEC usp_test
GO
SELECT SUM(user_object_reserved_page_count) AS [user object pages used]
,(SUM(user_object_reserved_page_count) * 1.0 / 128) AS [user object space in MB]
,getdate() AS 'final'
FROM tempdb.sys.dm_db_file_space_usage;
GO 40
Les lignes commentées ont été laissées commentées pour certains passages et non commentées pour d'autres. Lorsque le TRUNCATE a été commenté, il a fallu entre 2,25 et 4,5 secondes avant que les résultats du tempdb.sys.dm_db_file_space_usage requête (4472 pages de plus et 34,9375 Mo de plus) correspondait au résultat avant l'exécution de la procédure. Avec les lignes (y compris le TRUNCATE) non commentées, cela n'a pris que 0,11 à 0,9 secondes. Ces résultats proviennent d'un système en direct, avec une légère croissance des données dans la table source au cours de cette expérience.
Exemple de sortie avec le code commenté (2,69 secondes de la première à la dernière entrée "finale"):
user object pages used user object space in MB before
---------------------- --------------------------------------- -----------------------
1536 12.000000 2017-10-04 21:03:42.197
Beginning execution loop
user object pages used user object space in MB final
---------------------- --------------------------------------- -----------------------
6000 46.875000 2017-10-04 21:03:42.423
user object pages used user object space in MB final
---------------------- --------------------------------------- -----------------------
6000 46.875000 2017-10-04 21:03:42.533
user object pages used user object space in MB final
---------------------- --------------------------------------- -----------------------
6000 46.875000 2017-10-04 21:03:42.643
user object pages used user object space in MB final
---------------------- --------------------------------------- -----------------------
6000 46.875000 2017-10-04 21:03:42.883
user object pages used user object space in MB final
---------------------- --------------------------------------- -----------------------
6000 46.875000 2017-10-04 21:03:42.990
user object pages used user object space in MB final
---------------------- --------------------------------------- -----------------------
6000 46.875000 2017-10-04 21:03:43.100
user object pages used user object space in MB final
---------------------- --------------------------------------- -----------------------
6000 46.875000 2017-10-04 21:03:43.450
user object pages used user object space in MB final
---------------------- --------------------------------------- -----------------------
6000 46.875000 2017-10-04 21:03:43.650
user object pages used user object space in MB final
---------------------- --------------------------------------- -----------------------
6000 46.875000 2017-10-04 21:03:43.767
user object pages used user object space in MB final
---------------------- --------------------------------------- -----------------------
6000 46.875000 2017-10-04 21:03:43.993
user object pages used user object space in MB final
---------------------- --------------------------------------- -----------------------
6000 46.875000 2017-10-04 21:03:44.103
user object pages used user object space in MB final
---------------------- --------------------------------------- -----------------------
6000 46.875000 2017-10-04 21:03:44.213
user object pages used user object space in MB final
---------------------- --------------------------------------- -----------------------
6000 46.875000 2017-10-04 21:03:44.437
user object pages used user object space in MB final
---------------------- --------------------------------------- -----------------------
6000 46.875000 2017-10-04 21:03:44.553
user object pages used user object space in MB final
---------------------- --------------------------------------- -----------------------
6000 46.875000 2017-10-04 21:03:44.663
user object pages used user object space in MB final
---------------------- --------------------------------------- -----------------------
6000 46.875000 2017-10-04 21:03:44.887
user object pages used user object space in MB final
---------------------- --------------------------------------- -----------------------
6000 46.875000 2017-10-04 21:03:45.003
user object pages used user object space in MB final
---------------------- --------------------------------------- -----------------------
1536 12.000000 2017-10-04 21:03:45.113
Exemples de résultats avec le code non commenté (0,11 seconde de la première à la dernière entrée "finale"):
user object pages used user object space in MB before
---------------------- --------------------------------------- -----------------------
1536 12.000000 2017-10-04 21:07:39.807
user object pages used user object space in MB BeforeTruncate
---------------------- --------------------------------------- -----------------------
6016 47.000000 2017-10-04 21:07:39.923
user object pages used user object space in MB AfterTruncate
---------------------- --------------------------------------- -----------------------
6016 47.000000 2017-10-04 21:07:39.923
Beginning execution loop
user object pages used user object space in MB final
---------------------- --------------------------------------- -----------------------
6016 47.000000 2017-10-04 21:07:40.160
user object pages used user object space in MB final
---------------------- --------------------------------------- -----------------------
1536 12.000000 2017-10-04 21:07:40.270
La troncature d'une table temporaire à la fin de la procédure stockée qui la crée semble entraîner la libération plus rapide de l'espace utilisé par la table dans tempdb que si aucune instruction tronquée n'est utilisée, malgré les attentes contraires. Pourquoi?
Si la table temporaire est suffisamment grande ( plus de 128 extensions ), les désallocations de pages physiques sont différées et effectuées par une tâche système en arrière-plan. Cela est vrai, qu'un TRUNCATE TABLE Explicite soit utilisé ou non.
La seule différence est un petit détail d'implémentation. Un TRUNCATE TABLE Explicite crée une tâche avec un temporisateur plus court que la tâche de suppression différée (sinon identique) créée par le nettoyage temporaire de la table:
Que ce soit par accident ou par conception est une supposition. Cela pourrait bien sûr changer à tout moment, car ce niveau de détail va bien au-delà de la surface de produit prise en charge.
Si vous désactivez la suppression différée globalement avec un indicateur de trace (principalement) non documenté:
DBCC TRACEON (671, -1);
... les désallocations sont effectuées de manière synchrone dans les deux cas, et vous ne verrez aucune différence de timing.
Quelles seraient les implications relatives aux performances de l'utilisation ou de la non-utilisation d'une telle instruction tronquée? Lorsque vous utilisez l'isolement SNAPSHOT, tempdb est souvent souligné et je pense que libérer l'espace utilisé dans tempdb à partir d'une grande table temporaire le plus tôt possible empêcherait une croissance autrement inutile de tempdb. Ces économies d'espace potentielles se feraient-elles au détriment des performances?
Je doute sérieusement que cela fasse une grande différence dans les deux cas. Si tempdb est dimensionné de manière appropriée aux besoins de pointe de votre charge de travail, que la baisse différée se produise après une seconde ou trois ne devrait pas avoir d'importance. Le même travail est effectué; c'est juste une petite différence de timing.
D'un autre côté: si vous vous sentez plus à l'aise d'utiliser TRUNCATE TABLE Sur des tables temporaires à la fin de vos procédures stockées, allez-y. Je ne suis au courant d'aucun inconvénient particulier à le faire.