August 17, 2013 at 1:55 pm
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.
August 17, 2013 at 2:44 pm
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
August 17, 2013 at 3:03 pm
Tempdb has 30GB drive and it ran out of space.
So i had to shrink the tempdb database.
August 17, 2013 at 3:12 pm
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
Change is inevitable... Change for the better is not.
August 17, 2013 at 3:16 pm
How to find the queries thats causing tempdb fill very often.
August 17, 2013 at 4:10 pm
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]
August 17, 2013 at 4:38 pm
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
Change is inevitable... Change for the better is not.
August 19, 2013 at 8:28 am
Thank you all.
August 19, 2013 at 12:53 pm
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.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
August 19, 2013 at 1:12 pm
Can you suggest me the best autogrowth settings on the tempdb files
August 19, 2013 at 1:59 pm
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.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
September 9, 2013 at 9:36 am
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.
September 9, 2013 at 10:14 am
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
September 9, 2013 at 10:17 am
ok thank you all.
September 11, 2013 at 6:59 am
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