Time for another T-SQL Tuesday and this time I’ll finish my entry in time. This month we are talking about why DBA skills are necessary. Definitely a topic right up my alley since I’ve been having discussions along these lines with peers and co-workers for some time now.
a.k.a. What You Don’t Know Can Hurt You?
It’s true; not knowing DBA skills can hurt. There are a lot of situations that I’ve been called out to assist with, that boil down to not knowing is hurting an organization. A little bit a polishing of the DBA skills could have prevented the issues completely.
A few situations where not knowing hurt:
- One client awoke on a Saturday morning to discover their database was offline because the transaction log had grown substantially and run out of space. To help out, one of the directors deleted the transaction log and then fired the SQL Server back up. A couple days and restores later they were able to bring the database back up.
- Another client’s app had been slowing down for months. It had finally gotten to the point where it took a week to close the books for a month. Any time an error occurred they’d have to start over and potentially miss their billing deadline. A few indexes later and the performance was restored and they could close the books in a few minutes instead of days.
- A friend sent me an IM about a company he was attempting to help. He wanted to know if there was anything that I could think of that could be leverage to read the bits erased on a hard drive. Somehow the database had been deleted and the last backup was a few years old. Last I heard this company was no longer in business.
There are countless other stories like these. Almost every DBA has one or ten, please share any that you have in the comments.
In many of these, a DBA with the necessary skills is brought in to get things fixed, as best they can. The DBA is seen as a hero to the organization and sometimes all that was done was a simple modification that “knowing more” would have prevented the need for.
Some take aways from the above examples – areas where everyone should strengthen their DBA skills.
Right Skills, Right Permissions
In the first example, someone that didn’t know what they were doing attempted to fix something that appeared obvious to them. The long story short here is that someone had permissions that they shouldn’t.
SQL Server has more than db_owner and sysadmin rights. Make sure you are using these. There are hundreds to thousands of variations to permissions on your SQL Server instances – make sure you apply them as needed. Make yourself some scripts to easily apply and re-apply the permissions to prevent yourself from getting lazy.
Who do you trust at 5 PM on a Friday before they leave for vacation when they are under a deadline?
Indexing Matters
Indexing is an important aspect of SQL Server databases. They are the card catalogs that allow the database to be able to find the data that your applications require. Learning methods to analyze your indexes can help uncover indexes that can improve the performance the environment.All too often, the solution to a performance issue may be only an index or two away.
True, some raw horsepower through additional hardware can get around some performance issues. But there is always a point where the return on hardware decreases and further point where no additional hardware will improve the performance of the environment.
Take this a little further and the performance tuning skills that accompany the DBA skillset are critical. Beyond indexing, there are wait stats and performance counters to look at. Both of these can provide insight into performance issues and sometimes lead to small improvements with great performance returns.
Get A Recovery Strategy
If you are storing the data in a database, chances are that there is a purpose for the data. It isn’t likely that just deleting the database will win you any friends. Because of this let’s agree that the data and the database is important.Since it’s important, chances are that if something happened to the database then you’d need to recover it. And you are taking backups, right? Such a silly question, but it’s not uncommon for people to miss this or to just assume someone else is taking care of it.
Make certain it’s happening. But do more…
Backing up a database is only an act of copying the data from point A to point B. The reason this is done is so that you can copy the data back from point B to point A. If you can’t do that then who cares that the backup was taken in the first place.
Expand your backup strategy to recovery strategies. Then act like you are back in Elementary School and have a fire drill. Pick a point in time and recover to it. Take notes. Wait a couple months. Rinse and repeat.
Conclusion
Hopefully you can see that the items I mentioned have highlighted areas where the lack of DBA skills lead to significant business issues. As I explained, each of these were preventable. I’ve made light of each of the areas I covered, but it shouldn’t be hard to find posts from others to expand the information and learn more.
Related posts:
- Interesting Backup Failure
- An Index on Indexing #TSQL2sDay
- TSQL Tuesday #005 – Wait Stat Report – #TSQL2sDay
