Tempdb grows suddenly.

  • Hi

    I know that TempDB grows if it needs and if you restart the sql server the TempDB resets to it's configured size.

    On a sql server we have i have never had any problem with TempDB.

    The size has always been about 2 GB.

    I have run many big querys against it and it have never grown.

    Every week a rebuild index is being run on the databas that is about 40GB.

    But suddenly , the size jump up to 24 GB on the TempDB.

    I restart the server and everything is normal.

    But then over a night the size jump up to 42 GB.

    And during that time the only thing that has happen is the same thing that

    has happend every night.

    If i run:

    SELECT SUM(unallocated_extent_page_count) AS [free pages],

    (SUM(unallocated_extent_page_count)*1.0/128) AS [free space in MB]

    FROM sys.dm_db_file_space_usage;

    It says that about 40 GB is free space in TempDB.

    I am very confused.

    What should i do ?

  • Every week a rebuild index is being run on the databas that is about 40GB.

    Is this running with SORT_IN_TEMPDB ON?

    But then over a night the size jump up to 42 GB.

    And during that time the only thing that has happen is the same thing that

    has happend every night.

    Are you talking about rebuild index or some other activity, can you specify.

    Regards
    Durai Nagarajan

  • Wrong thread!

  • Beatrix Kiddo (8/29/2013)


    Wrong thread!

    Why?

    Regards
    Durai Nagarajan

  • Hi

    The "sort results in TempDB" is off.

    During the night the only activity is backup and some calculation.

    But nothing off this is a new activity.

    Rebuild index runs only ones a week on sundays.

  • put a server side trace on the DB to see what is running overnight to impact the TempDB. If its happening everynight then you'll only need to do it for a day or two to locate the culprit.

  • what is that some calculation and is that log grows after this or during this ?

    Regards
    Durai Nagarajan

  • You might be able to get the information from the default trace:

    DECLARE @tracefile nvarchar(1000)

    SELECT @tracefile = CAST(value AS NVARCHAR(1000)) FROM ::fn_trace_getinfo(0) where traceid = 1 and property = 2;

    PRINT @tracefile

    SELECTgt.HostName,

    gt.ApplicationName,

    gt.LoginName,

    gt.Duration/1000 AS [Duration (ms)],

    gt.StartTime,

    gt.DatabaseName,

    gt.[FileName],

    gt.IsSystem,

    te.name,

    CAST(gt.IntegerData*8 AS FLOAT)/1024 AS [MB Growth]

    FROM fn_trace_gettable(@tracefile, default) gt

    INNER JOIN sys.trace_events te ON te.trace_event_id = gt.eventclass

    WHERE te.category_id = 2

    ORDER BY gt.StartTime DESC

    GO

  • Run this...

    select * from sys.dm_db_task_space_usage

    where internal_objects_alloc_page_count <> 0

    See which spid has an high 'internal_objects_alloc_page_count'

    and a low 'internal_objects_dealloc_page_count'

    then see what these spids are doing.

    Do you use Service Broker at all.

  • The trace option is probably a good place to start in finding your culprit (my preferred method) - although i'd probably create a custom trace in profiler say tracking only items that had a lengthy duration or high logical reads...

    I also wanted to ask: Does this server have Reporting Services installed? If so, you may want to check and see if someone has scheduled a report to run during the night. If so, depending on the query/procedure used in the report it might be the cause of the sudden spike in TempDB

    Just a shot in the dark, but may be worth a look

    ______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience

  • Since it's happening overnight, there has to be a process that is getting run overnight. Do you have scheduled jobs. If so, what are they doing?

    I wouldn't suggest rebooting the server over and over as a fix. Instead, leave it where it is, figure out what the issue is, then determine if you just need a bigger tempdb or if it can be shrunk permanently because you've fixed the issue.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

Viewing 11 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply