August 24, 2005 at 9:01 pm
Hi all,
I had scheduled a job and it was running fine from last 6 months and tonight it gave me error .
Could not allocate space for object '(SYSTEM table id: -669903346)' in database 'TEMPDB' because the 'DEFAULT' filegroup is full.
August 26, 2005 at 8:21 am
I think your job contains some code, which takes lots of space in the tempdb. Is the autogrow option in your tempdb on.
August 26, 2005 at 8:22 am
Check the growth properties on tempdb, and the disk that the tempdev file is on. The problem is not (necessarily) with the log file but with the .mdf file.
Dylan Peters
SQL Server DBA
August 26, 2005 at 8:36 am
Temp DB is in simple recovery mode - accordingly truncating the log is unnecessary.
The error message you got indicates that the Default file group (Primary) was full - this indicates that tempdev (tempdb.mdf) ran out of room to accomodate more data. You may not have allowed autogrow on this file - or autogrow failed due to a possible SQL I/O stall when trying to autogrow in increments too large for the speed of a disk subsystem.
You may want to run sp_helpdb 'tempdb' in QA and post the result here for us to look at.
August 27, 2005 at 12:14 am
Hi,
Below is the result of sp_helpdb.
tempdb 263.31 MB sa 2 Aug 24 2005 Status=ONLINE, Updateability=READ_WRITE, UserAccess=MULTI_USER, Recovery=SIMPLE, Version=539, Collation=Thai_CI_AS, SQLSortOrder=0, IsAutoCreateStatistics, IsAutoUpdateStatistics 80
tempdev 1 d:\program files\MSSQL\data\tempdb.mdf PRIMARY 1258432 KB Unlimited 10% data only
templog 2 d:\program files\MSSQL\data\templog.ldf NULL 111200 KB Unlimited 10% log only
from
Killer
August 28, 2005 at 7:28 pm
Several aspects stand out. Your collation is Thai_CI_AS which might add addtional overhead (double byte for unicode?) (I am assuming your whole server is in the same collation. Your temp db mdf is over 1 GB in size with a current total temp db consumption of 'only' 263 MB.
To me this indicates that a) yiur temp db sizing is potentially off - since it' mdf had to autogrow up to 1.2 GB and its startup value is apparently significantly smaller (if adjusted from default at all) You may have significant i/o throughput requirements which basically inflate your temp db possibly due to slow checkpoint writes on yur disk subsystem (are you running yiur data files on Raid 5? (consider Raid 10).
Watch your temp db startup size - adjust it up and watch where temp db is autogrowing to in your environment - size it accordingly.
You will help out your server and underlying i/o system since autogrowth is certainly overhead you dont want to experience when disk i/o subsystem demand is already high during production.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply