A couple of weeks ago, I did a post about fire fighting and how I often find that it’s almost identical to what I do for a living (to a point anyway). Of course, fighting the fire is only half the battle. Preventing the fire in the first place is the other half. Usually, one is inversely proportional to the other. If you lack fire prevention, you probably stand a greater risk of having a fire. If have (or perform) fire prevention, your risk of a fire is probably lower.
In case you are interested, you can find a lot of excellent information here: http://www.nfpa.org/categoryList.asp?categoryID=2017&URL=Safety%20Information/Fire%20Prevention%20Week. Everybody should be familiar with the basic fire prevention methods.
Just as you should be aware of fire safety, as a DBA, you should also be aware of “safety” measures for your databases. Now, everybody probably has their own version of fire safety for their databases, but here are a couple of mine that I use.
Know your backups.
There really isn’t any excuse not to know your backups. What is being backed up? Where is being backed up too? When was the last time you restored from one of the backups to verify? This particular one is a huge things that I have seen in environments and it’s probably one of the more simpler ones to accomplish. Do you want to be the one who has to tell your business “Oops, I’m sorry, I can’t restore the database”. I certainly don’t.
One thing to think about regarding backups is to ask the business why they are being backed up the way that they are. Do they need a point in time restore? If not, change the recovery mode to SIMPLE and free up some resources on the server. Talk to the business. Communicate with them.
Know your security.
This is also an easy one in my opinion, at least to check on. There are a slew of scripts out there that will help you determine what holes you might have in your security. You don’t want your private information being shared out to the world because of a lack of security do you? Go find out who has DBO rights to which databases, who can do what do your servers. You might be surprised.
Know your hardware.
Some might disagree with me on this one. I like to know what my hardware is. By knowing that, you should have a rough idea on how things are going to run and you can use the various DMV’s to help validate things are running smoothly. A TON of information is available out on the net. Develop some scripts that suit your needs and get comfortable with them. This will pay off down the road.
Know your performance tuning techniques.
There is a wealth of information on how to performance tune your database as well as your SQL Server. Know where to look and what to at least look for. I keep a list of various scripts ready in the template explorer in the event I need to look at something. You don’t have to be a wizard at it, but at least know where to start. You can always reach out to the expert in the various social networking sites to help find an answer. The ones that I’ve seen thus far are willing to point you in the right direction. The #sqlhelp tag in Twitter is a great resource.
Know your high availability/performance solutions.
Some might consider this a little off the charts, but if you think about it makes sense. If you know your hardware and it’s capabilities and you know the high availability/performance solutions available to you, you will be able to provide a much better solution for when the business comes calling (and they will!). Often I’ve seen such solutions thrown into place without much fore thought which causes fires down the road. Again, a little prevention goes a long way.
Know your business.
An online business with a high transactional volume is going to behave different than say, one that might be a small shop with a minimal transaction load. Either way, by knowing the business and what their requirements are, you can adjust your prevention plan accordingly to ensure that your databases meet (if not exceed!) all of their expectations. In conjunction with knowing your business, know the service level agreements that your business might have or would like to have. Do they require 99.99% up time or can they afford to be down for 30 minutes? This information will be critical for some of the points I listed above.
Granted your fire prevention plan might be different than what I’ve listed above, which is totally fine as long as you have a plan! I seem to recall a saying, “Failing to plan is planning to fail”. In my opinion, this is 100% guaranteed if you don’t have some sort of fire prevention plan in place.
© 2011, John Morehouse. All rights reserved.