Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

snapshot of window and spaceI am developing a log analyzer tool and After queering it and generating reports Tempdb is getting full very quickly .

Is there any solution to clean the tempdb file in microsoft sql server 2008 on a timely basis other than restarting the server ?

Thank you so much in Advance

share|improve this question

migrated from stackoverflow.com Jun 14 '12 at 4:07

This question came from our site for professional and enthusiast programmers.

    
You could analyse it and see what's being added to it, and truncating it regularly? –  Preet Sangha Jun 13 '12 at 14:44
    
Are you using temp tables in your queries? Are you batching the queries properly? –  David Manheim Jun 13 '12 at 16:54

5 Answers 5

Tempdb is growing like this because something is using it. No attempt to fix, clean or manipulate tempdb is going to work as long as this is going on.

To address this problem, you need to find out what is causing it to grow like this and then fix that problem first. This alone may resolve the whole issue and remove your need to do anything else with tempdb. In my experience, the most likely cause for something like this is an out-of-control Cross Join query (though there are lots of other possibilities).

share|improve this answer
2  
In addition it may just not be sized appropriately to the work loaded being demanded. –  Bob Jul 14 '12 at 16:02

developing a log analyzer tool and After queering it and generating reports Tempdb is getting full very quickly .

Depending on what your tool does when generating reports - creates lot of tempdb tables, spills data to tempdb when using sort operators, etc, I would suggest you to presize your tempdb.

You are better off optimizing the SQL that is generating the report. May be putting proper index/s will definitely help.

Its always a best practice to only query the data that you require.

Start by analyzing wait stats.

You can use sp_whoisactive to analyze whats going on your server instance.

Below query will help you to identify the sessions that use the tempdb heavily :

/*
Lists the TempDB usage per each active session.
It helps identifying the sessions that use the tempdb heavily with internal objects.

When the internal objects usage is high, the session is probably using big hash tables or spooling in worktables. It could be a symptom of an inefficient plan or a missing index.

Shrinking a TempDB full of internal objects will probably have no effect, because the engine will not release the deallocated space. 

Ref: http://dba.stackexchange.com/a/19871/8783
*/


;WITH task_space_usage AS (
    -- SUM alloc/delloc pages
    SELECT session_id,
           request_id,
           SUM(internal_objects_alloc_page_count) AS alloc_pages,
           SUM(internal_objects_dealloc_page_count) AS dealloc_pages
    FROM sys.dm_db_task_space_usage WITH (NOLOCK)
    WHERE session_id <> @@SPID
    GROUP BY session_id, request_id
)
SELECT TSU.session_id,
       TSU.alloc_pages * 1.0 / 128 AS [internal object MB space],
       TSU.dealloc_pages * 1.0 / 128 AS [internal object dealloc MB space],
       EST.text,
       -- Extract statement from sql text
       ISNULL(
           NULLIF(
               SUBSTRING(
                   EST.text, 
                   ERQ.statement_start_offset / 2, 
                   CASE WHEN ERQ.statement_end_offset < ERQ.statement_start_offset THEN 0 ELSE( ERQ.statement_end_offset - ERQ.statement_start_offset ) / 2 END
               ), ''
           ), EST.text
       ) AS [statement text],
       EQP.query_plan
FROM task_space_usage AS TSU
--- Changed from inner join to left outer join to return rows for sessions that aren't currently actively running queries.
left outer join sys.dm_exec_requests ERQ WITH (NOLOCK)
    ON  TSU.session_id = ERQ.session_id
    AND TSU.request_id = ERQ.request_id
OUTER APPLY sys.dm_exec_sql_text(ERQ.sql_handle) AS EST
OUTER APPLY sys.dm_exec_query_plan(ERQ.plan_handle) AS EQP
WHERE EST.text IS NOT NULL OR EQP.query_plan IS NOT NULL
ORDER BY 3 DESC, 5 DESC

Is there any solution to clean the tempdb file in microsoft sql server 2008 on a timely basis other than restarting the server ?

Use it carefully on a production server !!

The only possible alternative to restarting the service, is running

DBCC FREESYSTEMCACHE('ALL')-- that will clear all cached objects, including not only internal objects, but also cached query plans.

DBCC FREESYSTEMCACHE ('tempdb') -- clears cache for tempdb

DBCC FREESYSTEMCACHE ('Temporary Tables & Table Variables') -- clears all the temp table and variables

Also, refer to Difference between FreeProcCache and FreeSystemCache

share|improve this answer

We recently faced the same issue. I got a marvellous solution over here : Cleaning tempdb
This will definitely help you. All the best !!

share|improve this answer
    
Hi Thanks for your reply but this did not work . The query runs successfully but did not see any changes . I even tried using 1 hh instead of 12 –  Rishi Ranka Jun 13 '12 at 15:02
    
Probable reason for this can be that either you do not have the permission to drop tempdb objects or the objects are currently in use by some session (as you have reduced old objects' age from 12 to 1 hr). –  Saurabh Jun 13 '12 at 15:11

Sharing a query to get the usage sizing. Little easier than MS kb query.

use tempdb
go;

SELECT sum(unallocated_extent_page_count) [Free_Pages],
 (sum(unallocated_extent_page_count)*1.0/128) [Free_Space_MB]
FROM sys.dm_db_file_space_usage;
share|improve this answer

If you have a nightly maintenance window for the DB the simplest method is to change your database from FULL logging to SIMPLE and then back to FULL again.

All other methods, e.g. http://support.microsoft.com/kb/307487 are overly complicated but you may be forced to consider them nonetheless.

share|improve this answer
6  
tempdb is always simple. And this is generally a bad idea because of backup chain issues getting broken... –  gbn Jun 14 '12 at 14:35
    
Yes, you will need to do backups after changing the logging. –  Jimbo Jun 15 '12 at 12:08
    
We have full backup every week, diffs every morning and log backups every 15 minutes. After flipping the logging from full to simple and then back again we do the diff. All restores work correctly and we never have issues with large temp DBs... –  Jimbo Jun 15 '12 at 12:20

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.