Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnist
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
I agree that keeping documentation up-to-date is an absolute pain in the arse but when you need it and it isn't there you are in trouble.
I work for a company that specialises in information mapping. Rather than write four sides of A4 prose they try and condense it to a diagram and a set of bullet points. I'd be shot on sight if they heard this over-simplification of it.
The problem with maintaining disaster recovery documentation is one of investment.
If I browse around this site there are various scripts to automate the various SQL Server admin tasks and even one to blast DBCC SHOWCONTIG info into a database table.
I believe that it is not beyond the wit and wisdom to develop a tool that will maintain the bulk of the disaster recovery documentation.
I also work with content management systems. Rather than building pages of information they tend to allow authoring of blocks of re-usable text. This tends to have versioning and including localisation facilities.
If the money was invested in such a system for use as a disaster recovery tool then the job of updating the disaster recovery information would be much simpler. Unfortunately the attitude is no-one got a pat on the head for putting in a better admin system.
Oh, rule one of disaster recover. The first machine to recover is the one with the disaster recovery documentation on it.
Have you taken a look at the SQL Server Health and History tool to provide some change management? The Reporting Services reports detail exact patches, configuration changes and software that is on the server. I have just started to use this tool, but it certainly supports your premise that the details are best left out of the official documentation. However, the reports could be printed and taken off site once a week. Just a thought...
Here's the link to download the SQL Server Health and History tool:
I agree that it is a huge mistake to over document. I have a Developer's Mantra that I try to have my entire development team repeat to the customers/clients/users: "Don't tell me your solutions! Tell me your problems!" We developers are in the business of solving problems. While I am always interested in hearing how the user would approach the solution, until I know what the problem actually is, I can't really be anything more than a coder.
Same for Disaster Recovery. If the server farm explodes, the problem is that I need live_Database_X up ASAP. I then need devel_Database_X up within a week. The folks doing the Disaster Recovery should have enough information to know how to rebuild a working SQL Server box and reload database from backups. (Or backup backups.)
So document enough so they know WHAT they are doing. Don't bother telling them HOW to do it.
Great article. So was the inline article "Should He Be Fired?" in this morning's email. I especially liked the approach that building trust in your team's ability to handle any situation (with or without a plan) is a key goal of managing that team. It's unfortunate managers do not instinctively know this, but at least someone is making the suggestion.
>>"admins hate it worse since most of them can't type that well."
Steve, you're kidding, right? I've never noticed this tragic inability of admins to type. LOL. There are few things that make me crazier than an IT person who can't type, spell, use basic punctuation, and at least make some sort of primitive attempt at grade school grammer. It's amazing how many of that sort soar right up the corporate ladder.
Thanks Steve, good info.
I rely more on a document that tells me what my people are best at. Then we can put them into the spot where they will succeed in these type of situations.
Viewing 7 posts - 1 through 6 (of 6 total)