Comments on: What’s the Largest Database You’ve Worked With? http://www.brentozar.com/archive/2008/02/interviewing-a-sql-server-dba-size-matters/ Your technology pain-relief experts. Wed, 08 Feb 2012 16:37:59 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: jfogg http://www.brentozar.com/archive/2008/02/interviewing-a-sql-server-dba-size-matters/comment-page-1/#comment-30341 jfogg Tue, 05 Apr 2011 20:34:04 +0000 http://www.brentozar.com/archive/2008/02/interviewing-a-sql-server-dba-size-matters/#comment-30341 I think you are right on with your estimations... We have an 80GB db that is growing rapidly, as we crossed the 75GB threshold, the amount of administration immediately increased. As we begin to reach the 100GB mark, I can see where we are going to NEED more experience. I think you are right on with your estimations… We have an 80GB db that is growing rapidly, as we crossed the 75GB threshold, the amount of administration immediately increased. As we begin to reach the 100GB mark, I can see where we are going to NEED more experience.

]]> By: Igor Besprozvanny http://www.brentozar.com/archive/2008/02/interviewing-a-sql-server-dba-size-matters/comment-page-1/#comment-19362 Igor Besprozvanny Thu, 01 Apr 2010 06:14:18 +0000 http://www.brentozar.com/archive/2008/02/interviewing-a-sql-server-dba-size-matters/#comment-19362 link for a "are you junior or senior dba" goes to another article. link for a “are you junior or senior dba” goes to another article.

]]> By: Brent Ozar http://www.brentozar.com/archive/2008/02/interviewing-a-sql-server-dba-size-matters/comment-page-1/#comment-10292 Brent Ozar Tue, 25 Aug 2009 18:45:15 +0000 http://www.brentozar.com/archive/2008/02/interviewing-a-sql-server-dba-size-matters/#comment-10292 GSquared - great point. Would you agree that those situations are exceptions to the norm, rather than the norm? I agree with you, though, in that if you've only got experience managing a 20 gig database, you need to spell out its complexity on your resume lest someone think you aren't qualified to manage a much larger one. GSquared – great point. Would you agree that those situations are exceptions to the norm, rather than the norm? I agree with you, though, in that if you’ve only got experience managing a 20 gig database, you need to spell out its complexity on your resume lest someone think you aren’t qualified to manage a much larger one.

]]> By: GSquared http://www.brentozar.com/archive/2008/02/interviewing-a-sql-server-dba-size-matters/comment-page-1/#comment-10291 GSquared Tue, 25 Aug 2009 18:32:26 +0000 http://www.brentozar.com/archive/2008/02/interviewing-a-sql-server-dba-size-matters/#comment-10291 Size of database doesn't necessarily correlate with complexity of management. For example, I used to have a half-petabyte database that was very simple to administer, because it consisted of one table split into three partitions, and a couple of procs. Was just used for processing address lists. Had no activity off business hours most days, all transactions were in large batches, only one of the tables needed any non-clustered indexes, inserts were sequential, there were no deletes, the only columns subject to updates were non-indexed, and if the database got corrupted or lost, restore from the prior night's full backup was adequate, since lists could simply be re-run. That database is currently being administered by someone who can just barely spell "SQL", and is most certainly NOT a senior DBA, and it's doing just fine. On the other hand, I also used to have a 20 Gig database that had over 400 tables, was highly transactional (hundreds per second), needed 24x7 uptime, and where the loss of even 1 minute's data would cause major problems for the business. That one required a significant amount of skill and expertise to administer. Definitely not something a junior DBA could have handled. Size does matter, but, as always, skill matters more. Both is best. Size of database doesn’t necessarily correlate with complexity of management.

For example, I used to have a half-petabyte database that was very simple to administer, because it consisted of one table split into three partitions, and a couple of procs. Was just used for processing address lists. Had no activity off business hours most days, all transactions were in large batches, only one of the tables needed any non-clustered indexes, inserts were sequential, there were no deletes, the only columns subject to updates were non-indexed, and if the database got corrupted or lost, restore from the prior night’s full backup was adequate, since lists could simply be re-run.

That database is currently being administered by someone who can just barely spell “SQL”, and is most certainly NOT a senior DBA, and it’s doing just fine.

On the other hand, I also used to have a 20 Gig database that had over 400 tables, was highly transactional (hundreds per second), needed 24×7 uptime, and where the loss of even 1 minute’s data would cause major problems for the business. That one required a significant amount of skill and expertise to administer. Definitely not something a junior DBA could have handled.

Size does matter, but, as always, skill matters more. Both is best.

]]>