August 29, 2013 at 3:50 am
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 ?
August 29, 2013 at 4:42 am
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
August 29, 2013 at 4:43 am
Wrong thread!
August 29, 2013 at 4:55 am
Beatrix Kiddo (8/29/2013)
Wrong thread!
Why?
Regards
Durai Nagarajan
August 29, 2013 at 7:10 am
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.
August 29, 2013 at 7:17 am
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.
August 29, 2013 at 7:48 am
what is that some calculation and is that log grows after this or during this ?
Regards
Durai Nagarajan
August 29, 2013 at 8:20 am
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
August 29, 2013 at 8:31 am
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.
August 29, 2013 at 8:46 am
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
August 30, 2013 at 4:55 am
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