Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Worst Practice - Detailed Disaster Plans


Worst Practice - Detailed Disaster Plans

Author
Message
Steve Jones
Steve Jones
SSC-Dedicated
SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)

Group: Administrators
Points: 36012 Visits: 18730
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnist

Follow me on Twitter:
@way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
David.Poole
David.Poole
Hall of Fame
Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)Hall of Fame (3.7K reputation)

Group: General Forum Members
Points: 3666 Visits: 3111

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.

  • Investment in time.
  • Investment in tools to do the job.
  • Investment in training.

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.



LinkedIn Profile

Newbie on www.simple-talk.com
cppwiz
cppwiz
SSC-Enthusiastic
SSC-Enthusiastic (184 reputation)SSC-Enthusiastic (184 reputation)SSC-Enthusiastic (184 reputation)SSC-Enthusiastic (184 reputation)SSC-Enthusiastic (184 reputation)SSC-Enthusiastic (184 reputation)SSC-Enthusiastic (184 reputation)SSC-Enthusiastic (184 reputation)

Group: General Forum Members
Points: 184 Visits: 470

Steve,

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:





nhughes
nhughes
Forum Newbie
Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)

Group: General Forum Members
Points: 2 Visits: 75

Good Morning!

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.

Nik Hughes





Mike Dougherty
Mike Dougherty
SSC-Enthusiastic
SSC-Enthusiastic (112 reputation)SSC-Enthusiastic (112 reputation)SSC-Enthusiastic (112 reputation)SSC-Enthusiastic (112 reputation)SSC-Enthusiastic (112 reputation)SSC-Enthusiastic (112 reputation)SSC-Enthusiastic (112 reputation)SSC-Enthusiastic (112 reputation)

Group: General Forum Members
Points: 112 Visits: 952
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.
John Scarborough
John Scarborough
SSC Veteran
SSC Veteran (290 reputation)SSC Veteran (290 reputation)SSC Veteran (290 reputation)SSC Veteran (290 reputation)SSC Veteran (290 reputation)SSC Veteran (290 reputation)SSC Veteran (290 reputation)SSC Veteran (290 reputation)

Group: General Forum Members
Points: 290 Visits: 52
>>"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.

John Scarborough
MCDBA, MCSA
einman33
einman33
Mr or Mrs. 500
Mr or Mrs. 500 (575 reputation)Mr or Mrs. 500 (575 reputation)Mr or Mrs. 500 (575 reputation)Mr or Mrs. 500 (575 reputation)Mr or Mrs. 500 (575 reputation)Mr or Mrs. 500 (575 reputation)Mr or Mrs. 500 (575 reputation)Mr or Mrs. 500 (575 reputation)

Group: General Forum Members
Points: 575 Visits: 512

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.


Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search