7 Deadly Sins Of Microsoft SQL Server Database Management (Sin 1)

After my last post, I thought about it and I have decided to create a series of 7 Posts for Oracle Databases and 7 posts for Microsoft SQL Server Databases. Where I will identify the 7 things that we see far to often and represent very bad practices in database administration.

The first and most deadly sin concerns the Database Backups.

Over the past years we have come across quite a few SQL Server databases that were not being backed up at all. They thought they were but when we looked under the covers the backup was not working. See my previous post titled “Have your fire drilled your Oracle or Microsoft SQL server backup posted on December 18th, 2007 about the important of fire drills. If you don’t test your backup, then experience has taught me it won’t work when you really need it.

Another thing we see in the Microsoft SQL Server environment is that that frequent dumps of the transaction logs are not being done. Without frequent dumps of the transaction logs there is no ability to recover the database to a point in time. There are some major advantages to frequent dumps of your transaction logs. By doing this you greatly enhance your ability to recover the database when you need it. It’s really nice to be able to recover your database to 12:01 when you accidentally deleted a table you needed at 12:02 and not loose a days work.

Microsoft SQL Server Deadly Sin 1: Poor or Untested Database Backups

Make sure you are doing frequent dumps of the transaction logs so that you have the ability to recover the database in the event of a disaster. Also make sure that your backup is tested. What I mean mby tested, is that you run a fire drill and actually physically recover something.

Posted Michael Corey, Ntirety



View blog top tags

Add to Technorati Favorites

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.