Tempdb data file fills up very often

  • Tempdb fills up very often.

    tempdb configuration is

    namefileidfilenamefilegroupsizemaxsizegrowthusage

    tempdev1N:\Data\tempdb.mdfPRIMARY29428480 KBUnlimited10%data only

    templog2N:\Data\templog.ldfNULL512 KBUnlimited10%log only

    I want to know why its happening very often and when i try to shrink tempdb it gives me below message.

    DBCC SHRINKDATABASE: Page 1:3678552 could not be moved because it is a work table page.

    Please suggest what needs to be done to solve the issue.

  • Why are you shrinking a file that's already too small for the workload? Surely if the file's getting full all the time you'd want to make it larger, not smaller?

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • Tempdb has 30GB drive and it ran out of space.

    So i had to shrink the tempdb database.

  • p.swathi4 (8/17/2013)


    Tempdb has 30GB drive and it ran out of space.

    So i had to shrink the tempdb database.

    TempDB grows to fit the need. For example, it's used for certain types of joins, index and tables spools, and a whole lot of other stuff.

    That being said, the "need" might be the problem. If you have queries with accidental many-to-many joins, the "need" will be great to store that data temporarily in TempDB. You need to find such queries and fix them or shrinking TempDB will be to no avail.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • How to find the queries thats causing tempdb fill very often.

  • p.swathi4 (8/17/2013)


    Tempdb has 30GB drive and it ran out of space.

    So i had to shrink the tempdb database.

    Then you need to find another drive to extend it on.

    30 GB is not really a small tempdb, but it not excessive either. All depending on your workload 30 GB may make sense, be too small, or be inflated by one single bad query.

    You can find out which processes that are using a lot of tempdb from this DMV: sys.dm_db_task_space_usage

    Do you have any databases that uses any form of snapshot isolation? You can see how much space the version store takes up in this DMV: sys.dm_db_file_space_usage.

    [font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]

  • p.swathi4 (8/17/2013)


    How to find the queries thats causing tempdb fill very often.

    It's a fairly large subject so you need to ask your assistant DBA the question. In fact, you and I have the same assistant DBA... His first name is "Google". 😀

    Seriously... go to Google and type in "find the queries thats causing tempdb fill" (the exact wording of part of your question) and you'll find a lot of posts on the subject.

    One of the MS White Papers on the subject has a wealth of data concerning this problem. It also has a method for helping to track down things that are using TempDB the most near the end of the paper. Here's the URL for that.

    http://technet.microsoft.com/library/Cc966545#EGAA

    As a bit of a sidebar, many people have written queries to attempt to find out what's causing TempDB to grow. I've not tested the query at the following link but it's written someone that I have high regard for.

    http://www.sqlservercentral.com/scripts/tempdb/72007/

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Thank you all.

  • Something that hasn't been mentioned yet, is that having the autogrow set to 10% isn't usually the best practice and this could be causing the out of space error because a 28GB file is trying to grow another 2.8GB on a drive that is smaller than the required 30.8 GB. In addition to all the other recommendations, I'd recommend setting the data file to the size of the drive, not allow autogrowth, and monitor space available (% used) and have an alert setup that lets you know when you are running out of space.

  • Can you suggest me the best autogrowth settings on the tempdb files

  • p.swathi4 (8/19/2013)


    Can you suggest me the best autogrowth settings on the tempdb files

    That depends on your workload, but really autogrowth should only be there for emergencies not as part of the plan. You should size tempdb (really all your databases) to what you need for your load. In your case it looks like at max load you need at least 30GB, so that should be the initial size of the database and, if that is all the space available, it shouldn't have autogrow on. If you have more space then, based on the information you've provided, I'd start with 1GB growth. But first I'd put some monitoring in place to track usage and an agent alert that fires when I reached a set % used (probably 80% in your case) so I could check what it using the space.

  • Can you see if something is leaving allocated pages in tempdb.

    select * from sys.dm_db_task_space_usage

    where internal_objects_alloc_page_count <> 0

    Anything which has an high alloc and low dealloc. Then whatever that spid is doing is the problem.

  • Something below will help to find relveant information .

    SELECT SUM (internal_object_reserved_page_count) AS internal_pages ,

    ( SUM (internal_object_reserved_page_count) * 1.0 / 128 ) AS internal_page_MB ,

    SUM(internal_object_reserved_page_count ) AS user_page ,

    SUM(user_object_reserved_page_count ) AS user_pages ,

    SUM(user_object_reserved_page_count ) * 1.0 / 128 AS user_page_MB

    FROM sys .dm_db_file_space_usage

    SELECT session_id ,

    SUM(internal_objects_alloc_page_count ) AS task_pages ,

    SUM(internal_objects_alloc_page_count ) AS deloc_pages

    FROM sys .dm_db_task_space_usage

    GROUP BY session_id

  • ok thank you all.

  • p.swathi4 (8/19/2013)


    Can you suggest me the best autogrowth settings on the tempdb files

    In this particular case I would have NO autogrowth. Make your tempdb file(s) consume the ENTIRE 30GB on SQL Server startup. Now you get ZERO fragmentation and all 30GB of space is immediately available to any and all queries without any growth. Consider having Instant File Initialization enabled to speed the file creations at startup.

    I may have missed it, but where is your tempdb log file at? That could have an effect on the above statement if it too is on the same drive (which is suboptimal but may not be avoidable in smaller environments).

    Best,
    Kevin G. Boles
    SQL Server Consultant
    SQL MVP 2007-2012
    TheSQLGuru on googles mail service

Viewing 15 posts - 1 through 15 (of 35 total)

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