SQL Server Club
Home Articles Essential Guides Blogs Links Twitter Facebook Join Contact About
Ten Things a SQL Server DBA Should Never Do
Web Monkey About the Author

With security clearance and well over a decade of experience with SQL Server, Web Monkey is the resident DBA at Norb Technologies and a real database guru.

A regular contributor to SQL Server Club, his background includes software development, hardware, a smattering of essential networking knowledge and an unhealthy interest in web security. He has an obsession with automating repetitive tasks, but has a tendency to forget where he left his last open bag of fruit and nut...

Typepad Profile RSS Feed Web Monkey on Twitter
Send to a Friend Printer Friendly Version

With around ten years of SQL Server experience himself, our database expert Jon Reade has put together this list of things he feels you should never do as a DBA...

Being a database administrator (DBA), even in a development environment, is a responsible job. Some developers look at their DBA as a power-mad, overpaid ogre but in reality, it's a highly responsible job where one false move can cause you at best a lot of explaining and at worse, your career.

For those of you who are contemplating becoming a DBA, here are ten top tips for what not to do in your next role. And for those of you who already are, read on - you might be doing some of these things without knowing it! It's actually 11 things you should never do - I've given you a tip for free!

  1. Rebuilding an index in daylight hours - this will hit disk I/O very heavily. It is rarely useful to do this during normal working hours, so always schedule it for the evening or overnight - that is, during the period of lowest user activity.

  2. Stopping the database engine without warning - why? Lots of frustrated users and a telephone (yours) that won't stop ringing.

  3. Performing a service pack upgrade during working hours - usually this involves re-starting the core database engine. Don't do it, it'll annoy many people.

  4. Running test queries against live servers - do you really know how long they'll run for or how much disk I/O they will demand? I thought not!

  5. Defragmenting the drive on which the database files sit - have you ever done this to your home PC? Then you'll know why you shouldn't do it to a live box in working hours. No, no, no.

  6. Being arrogant towards developers - why? A few can be a complete pain, but explaining to them the issues and trying to work towards a good working compromise is usually more productive than treating them unsympathetically. Likewise the support guys - you need each other. Foster good relationships with your work colleagues, in the long term it pays dividends.

  7. Backing up during working hours - it's all about disk I/O. It serves the backup or it serves your users. If you have to do it, look at differentials or transaction log backups: they take less time and reduce dropped connections as a result. Alternatively, monitor the server and talk to your users about the best time to perform one - but only if you really have to.

  8. Executing updates against live data - you are kidding, right? At the very least, write a script, test it against a live copy, and backup the live database before you apply it. And if possible have a regression script which will allow you to back out the updates if reverting to a backup is not possible (ie: when the fix is applied but an issue with it is spotted after a few days in production).

  9. Performing vendor upgrades without testing or backing up - sad as it seems, vendors don't always test their upgrades thoroughly. Nor can they practically test against every hardware and software configuration available out there. Customers put multiple systems on a single server to save cost, which can introduce compatibility problems, especially prior to .NET. So always back up before running a patch. And if you can apply it to a test or development server first, do it.

  10. Not securing your database servers - run the Microsoft Baseline Security Analyzer against your servers to find out your vulnerabilities and get clued up on security.

  11. Dropping a live database and the effect on your career - I once worked with someone who did this. He got sacked on the spot, and rightly so. If you only engage your brain to do one thing as a DBA, make sure it kicks off the alarm bells whenever you issue a DROP command.
Send to a Friend Printer Friendly Version
Top of Page
© Norb Technologies 2007-2010 Privacy Policy Norb Technologies Devdex Feedback Home
Feedback Form