Limitation de la croissance de la base de données temporaire SQL

Question

Je suis confronté à un problème sérieux sur mon serveur de production où la base de données temporaire augmente de façon exponentielle. Est-il possible de récupérer l'espace tempDB sans redémarrer le service SQL?

À votre santé Kannan.

Answer 1

Je voudrais ignorer les messages vous conseillant de changer le modèle de récupération ou de limiter la taille de tempDB (!).

Vous devez rechercher la cause réelle de la croissance.

Si vous avez la trace par défaut activée (elle est activée par défaut, de la boîte), vous pouvez rétrospectivement savoir ce qui a causé la croissance en lançant ceci:

--check if default trace is enabled 
if exists (select 1 from sys.configurations where configuration_id = 1568) 
BEGIN 

declare @defaultTraceFilepath nvarchar(256) 

--get the current trace rollover file 
select @defaultTraceFilepath = CONVERT(varchar(256), value) from ::fn_trace_getinfo(0) 
where property = 2 

SELECT ntusername,loginname, objectname, e.category_id, textdata, starttime,spid,hostname, eventclass,databasename, e.name 
FROM ::fn_trace_gettable(@defaultTraceFilepath,0) 
     inner join sys.trace_events e 
      on eventclass = trace_event_id 
     INNER JOIN sys.trace_categories AS cat 
      ON e.category_id = cat.category_id 
where 
     databasename = 'tempDB' and 
     cat.category_id = 2 and --database category 
     e.trace_event_id in (92,93) --db file growth 

END 

Sinon, vous pouvez démarrer une SQL Profiler trace pour capturer ces événements. Activez la capture des événements Croissance automatique, Trier les avertissements et Joindre les avertissements et recherchez les jointures croisées, les jointures de hachage ou les conditions de jointure manquantes.

SQL Server expose un moyen d'identifier les allocations d'espace tempdb en cours d'exécution des requêtes, en utilisant DMVs: (. Ref)

-- This DMV query shows currently executing tasks and tempdb space usage 
-- Once you have isolated the task(s) that are generating lots 
-- of internal object allocations, 
-- you can find out which TSQL statement and its query plan 
-- for detailed analysis 
select top 10 
    t1.session_id, 
    t1.request_id, 
    t1.task_alloc, 
    t1.task_dealloc, 
    (SELECT SUBSTRING(text, t2.statement_start_offset/2 + 1, 
      (CASE WHEN statement_end_offset = -1 
       THEN LEN(CONVERT(nvarchar(max),text)) * 2 
        ELSE statement_end_offset 
       END - t2.statement_start_offset)/2) 
    FROM sys.dm_exec_sql_text(sql_handle)) AS query_text, 
(SELECT query_plan from sys.dm_exec_query_plan(t2.plan_handle)) as query_plan 
from  (Select session_id, request_id, 
sum(internal_objects_alloc_page_count + user_objects_alloc_page_count) as task_alloc, 
sum (internal_objects_dealloc_page_count + user_objects_dealloc_page_count) as task_dealloc 
     from sys.dm_db_task_space_usage 
     group by session_id, request_id) as t1, 
     sys.dm_exec_requests as t2 
where t1.session_id = t2.session_id and 
(t1.request_id = t2.request_id) and 
     t1.session_id > 50 
order by t1.task_alloc DESC 

Answer 2

En mode SIMPLE, le journal de la base de données tempdb est constamment tronqué et ne peut jamais être sauvegardé. Donc, vérifiez qu'il est en mode simple

Answer 3

Vous pouvez utiliser DBCC SHRINKFILE pour réduire les fichiers tempdb et récupérer une partie espace.

DBCC SHRINKFILE ('tempdev', 1) DBCC SHRINKFILE ('templog', 1)

Les noms des fichiers peuvent être trouvés dans la table sysfiles.

Vous devez toujours découvrir la cause profonde, mais cela peut vous donner un peu de répit jusqu'à ce que vous le fassiez. La quantité d'espace que vous récupérez dépend de l'utilisation et d'autres facteurs.

aussi:

Comment réduire la base de données tempdb dans SQL Server

http://support.microsoft.com/kb/307487