Earlier in the month I shared with you 10 Things That Every DBA Should Do and so it only seems natural to also consider some things that every Database Administrator should NOT be doing right.

I’m going to let you in on a little secret here, I have actually done some of these things myself once upon a time and I’m sure other DBAs have too. It’s important that as a DBA you understand that you will inevitably make a wrong call at some point. It is how you handle it that is truly telling.

In no particular order, here are 5 things that I really really really hope you are NOT doing if you’re a DBA.

1. Shrinking Your Databases

If you’re shrinking your SQL Server databases on a regular basis then you either have a storage shortage to address, poor transaction log management, a dodgy process or a screw loose. Either way you need to get things sorted.

I’m not got to repeat what many others have already said on the matter (Why you should not shrink your data files / Why you want to be restrictive with shrink of database files), just heed my advice that you should really not be doing this unless you have a very good and exceptional reason for doing so.

2. Giving Regular Users sysadmin Rights

Just like you, I too have heard all the excuses. Whether they be from developers or power users that have been at the company since the dawn of time thereby having been granted full blown administrative rights as if it were some sort of right of passage.

The truth that we all know as DBAs of course is that there’s just no need for this level of privileges to be granted. The overwhelming majority of functionality that your users genuinely need in order to go about their work can be provided for without granting sysadmin level rights. The same can even be said for a large proportion of the tasks performed by us DBAs. Take the responsibility for your environment and data assets seriously.

3. Performance Tuning Queries in Production

"Some things you just shouldn't do"

As tempting as the urge may be, it’s really not a good idea to query tune directly in your production environment. You’re making changes to your code base without actually knowing for sure, the consequences of your actions. Don’t even get me started on a DBA running Ad-hoc queries live on a production server.

So you’ve identified an index that will make a currently poorly performing query run like lightning, great! Now go away and test it properly in your performance tuning environment so you can see how well it plays with the other queries and be confident that there will be no adverse affects.

4. Making Changes Without Testing (a.k.a Winging-it)

Even if you are a T-SQL Ninja, if you’re making changes to production that you have not tested then in my opinion that makes you a fool. You may think I’m being harsh but the experienced folk out there know that I speak the truth. If you are not testing your changes before they go to production then you are putting the data assets that you are ultimately responsible for at unnecessary risk. Doing so goes completely against your primary responsibility as a DBA. Why take the chance?

5. Rebuilding All Indexes Every Time

If  a couple of bricks had come loose and fallen off of the garden wall, would you knock down the entire wall first in order to repair the damage? Of course not! So why do it to your indexes? If a given index only has a small amount of fragmentation say 15% then why not repair the damage (using REORGANIZE) rather than REBUILD the entire index completely from scratch. If your current index maintenance strategy is to bulldoze your entire database on a nightly basis then you are likely generating a lot of wasted effort and unnecessary transaction log activity.

Invest some time in your index maintenance strategy so that you are performing a suitable amount of reorganization or rebuilding, dependant on the needs expressed by the current state of each index.

As with a lot of things in life, there are some great index tuning procedures out there, such as the excellent Index Defrag Script V4.0 and there are some not so great ones. Whether you choose to devise your own index maintenance strategy or to use one that another DBA wrote, it’s important that you make sure you understand how the process works so that you can be confident that you are making informed choices for optimizing your environment.

5.1 Restarting the SQL Server Service to “fix” issues

I was originally going to allow this one to slide from the list but then I thought I would be doing you readers a genuine disservice by ignoring what I consider to be one of the most frustrating habits that I encounter in DBAs. So just to make certain and be absolutely clear here, restarting the SQL Server service in order to “fix” or remedy a problem is NOT an acceptable solution. You are fooling yourself if you think that this is an acceptable practice for a DBA to perform and in the long run you are doing yourself a real disservice. If you break it down, what the person is actually doing here by their action is accepting the fact that they don’t know how to solve the problem. Don’t be a quitter and accept defeat, take the time to investigate and troubleshoot the problem, like the Outstanding DBA that I know you are!

There you have it, 5 things that I don’t think you should be doing as a DBA, some of which I may even have learned about the hard way myself. I will leave you guessing as to which…..

In your experience, what are some of the things that you think Database Administrator’s should not do?