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.