I have been running queries for pretty much most of the day with success.

However when trying to find out if the posthistory table might hold records for deleted posts I naively ran this query:

select  *
from posthistory ph
left outer join posts p on ph.postid = p.id
where p.id is null

expecting it to timeout due to the large record counts in both tables.

Instead of that I was greeted with this message:

Could not allocate a new page for database 'TEMPDB' because of insufficient disk space in filegroup 'DEFAULT'. Create the necessary space by dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

If I did brake SEDE I appologize for that.

Do note that subsequent queries did return results without error or showed the timeout error.

Is this error a sign that something crucial is going wrong? If so, can this be fixed?

  • 3
    The bill for breaking SEDE is already on its way to your mail box. :-D Commented Jun 29, 2014 at 17:50
  • If Nick puts the extra storage on his amazon wishlist I'm happy to donate @ShadowWizard ;)
    – rene
    Commented Jun 29, 2014 at 17:58
  • 2
    I think we should just DROP the ball on this one. Commented Jun 29, 2014 at 20:09

1 Answer 1


Yep it's out of space. We'll be discussing how to handle SEDE at tomorrow's call. My wager would be larger consumer-grade SSDs for that Dell r610 server (maybe something like an Samsung EVO 1TB set?).

I have temporarily shuffled some things in hopes one last restore can run within the current space constraints...we'll see if it actually works in the next hour or so.

Update: We sent Super Dalgas to get a burrito yesterday and he decided to stop at the data center along the way. We have upgraded from 4x Intel 320 300Gb SSDs to 4x Samsung EVO 1 TB SSDs for the data drives - we should have quite a bit more space to grow now.

Note: we don't recommend these particular Samsung EVO drives for SQL Server installs - they do not have power loss protection via capacitors and such that enterprise-friendly drives would. In the Data Explorer case though, we backup the DE database often and the site databases on it can be regenerated in just a few hours - and the code's already in place to do that as the normal weekly refresh.

  • 1
    I'll start a fundraiser to collect some money...
    – rene
    Commented Jun 29, 2014 at 19:53
  • And? Did the Dell server get fitted with those nice Samsung EVO 1TB disks? Or was the shuffeling enough to prevent disaster for another couple of months?
    – rene
    Commented Jul 12, 2014 at 9:10
  • @rene shuffling made it just squeeze by, it may very well fail again tomorrow. 5 EVO drives have been ordered (1 spare) and Super Dalgas and I will be installing those along with another pair of 2TB spinnys to help with the data dump next week when I'm back from vacation. Commented Jul 12, 2014 at 12:43
  • I assume this makes it status-completed? I did try that awful query in my question and it times out now, so that is good ;)
    – rene
    Commented Jul 24, 2014 at 10:21
  • @rene yep, we're also doubling the RAM in that server with a SQL 2014 upgrade, which will bring it to 128GB usable - that'll help perf quite a bit as well. Commented Jul 24, 2014 at 10:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .