I have been using SQL Server for around 8 years and I have never, ever had to use a DBCC command. Why? Because I backup regularly and I design it "the right way' from the start, software and hardware wise.

Any DBA interviewer that asks you to know DBCC commands means that that shop isn't run correctly and has databases that are poorly designed and crashes regularly.

DBCC commands are wild goose chases when a siimple restore of backup is what's needed and needed ASAP.

Any DBA that thinks they need DBCC commands spends more time on DBA CERTIFICATION TESTING instead of producing reliable databases in a production environment that doesn't need constant maintenance. (By the way, that what SQL Server is designed for, to ELIMINATE this MAINTENANCE and HENCE the use of DBCC commands in the first place.)

When a DB crashes, do you think management and your customers have time for you to fish around using DBCC commands to figure out what's wrong? NO WAY!!!. It's restore, restore, restore and get it up and running, NOW!! Not tomorrow, not the end of the day, not a few hours, not one hour from now, but RIGHT NOW!!! All that time trying to figuring out wrong with DBCC commands could have been used to get a full restore up and running. Or for that matter, a partial restore or switch to the backup.

And by the way, DTS is total crap. If you are a DBA that says his shop uses it, it means they are ANTIQUATED and have to constantly support some legacy app with some GUI interface when t-SQL and SQL Server Agent will be far more powerful and more easily diagnosed.

And if you use DTS to import another database then you are a DBA that can't see the forest between the trees as you again can more easily write t-SQL to catch and modify exceptions when importing to your new database. Bottom line, t-sql will have a CLEANER import and less hassle. i.e. it's all in the code.

The article sound like it was from a booksmart DBA but clueless in the real world of production. Wait a second, the author says he works in an "academic" institution!!! That explains everything. And he can't find any DBA for over 6 month? Why? it's call JOB SECURITY, that's why. Wouldn't want someone coming in and showing management a better, faster and MORE RELIABLE way of using SQL Server would we?

It's no wonder that more than 70% of all I.T. projects fail. Clueless developers and DBA's that again are book smart and production clueless. Not to mention they are horribly SLOW in production.. Hmmm, I wonder why????