If you have three minutes to spare, swing by Paul Randal’s blog and answer his survey questions about the size and distribution of your database. The results are very interesting. I was most interested in the number of respondents to each of the questions. As each size category switched, fewer and fewer people responded. However, a lot more people responded than I expected. 94 last I looked had databases under 10gb in size, but 42 had databases over 1tb. Yeah, that’s only 1/2, but, holy cow, it’s 1/2.
I wish I had a database to manage that was over 1tb. Back in the 7.0/2000 days I was at a dot com that was getting close. When I left they had 700gb. I understand they got close to 850 before the company folded. Managing that much data in SQL Server 7 and 2000 was like wrestling a very serious bear. I’d love to see what it’s like now.
The database I manage is currently 10TB, I’ve watched over it since it was 1.5TB and thankfully it’s all been on SQL Server 2005 (migrating to 2008 right now). I’d say with careful planning (and the budget) management of it is not too bad. However, in a pinch it’d be nice to have online file moves and a bit more robust partitioning adjustments.
I’m hoping that with SQL Server 2010 and its push to make SQL Server a better data warehouse database that they address these two issues.
My hat is off to you. I wish I was managing data that size. It’s a pretty incredible challenge and a terrific learning opportunity.
Biggest I’ve worked with so far hit 1.2TB just before I left the company.
The size of it wasn’t really an issue, until it broke. Worst combination I can think of is a large DB on slow drives. 10 hours to restore (full, diff, 80 log backups)
I hear you Gail. When I first started here it took 11 days to restore 1.5 TB. One challange I don’t think people see right off (those not responsible to manage something over a TB) is that your supporting infrastructure needs to be able to keep up! Thus your backup solution (we have spinning disks and tape) needs to be robust enough not to hinder disaster recovery.