DBA Best Practices - A Blog Series: Episode 3 - Use a Wiki for Documentation

re: DBA Best Practices - A Blog Series: Episode 3 - Use a Wiki for Documentation

merrillaldrich — Wed, 13 Feb 2013 18:06:52 GMT

Excellent! We are implementing the SharePoint wiki for this and it's a fantastic way to handle ops-type documentation. SharePoint lists in the mix also have great uses (issues log, anyone?) :-). SharePoint obviously has its warts, but it's already present many places and this was a natural fit.

re: DBA Best Practices - A Blog Series: Episode 3 - Use a Wiki for Documentation

AlexK — Wed, 13 Feb 2013 18:22:10 GMT

What happens when something changes and renders your wiki page incorrect?

Documentation gets out of sync with reality all-too-easily, you know...

re: DBA Best Practices - A Blog Series: Episode 3 - Use a Wiki for Documentation

Jason — Wed, 13 Feb 2013 18:54:39 GMT

Thanks Argenis! I've got a set of Powershell Scripts that I run that dump information into Excel files. Things like database file locations, DB configuration settings. Also instance level information such as Configuration information, logins. Even have sheets that view down to OS level information like Memory, IPs, # of Procs, Cores, etc.

Right now, I manually run these once or twice a month and upload to a site that the DBA team has access to. I'll start thinking about using our SharePoint system fuller.

My scripts - http://www.the-fays.net/blog/?p=142

re: DBA Best Practices - A Blog Series: Episode 3 - Use a Wiki for Documentation

Argenis — Wed, 13 Feb 2013 19:00:44 GMT

@Jason that's hilarious, somebody on Twitter was telling me about his own effort to do the same thing, only it saves the information to XML and not Excel. Perhaps we should get a CodePlex project going for this stuff...there's also the work that Chad Miller has done.

re: DBA Best Practices - A Blog Series: Episode 3 - Use a Wiki for Documentation

Argenis — Wed, 13 Feb 2013 19:04:35 GMT

@AlexK - I'm not sure I follow your scenario. If you're careful with your templates and your doc. scripts, you can certainly minimize the likelihood of these "out of sync" issues arising.

re: DBA Best Practices - A Blog Series: Episode 3 - Use a Wiki for Documentation

Brent Ozar — Thu, 14 Feb 2013 13:51:48 GMT

Two other important considerations with this kind of project.

One, you want it to be available when your datacenter is having major problems. At one company, we had a wiki like this, but the database back end was stored on the SAN. When we had a SAN outage, we desperately needed to know all of the affected systems, but ... you can see where that's going.

Two, you don't want it to be available to outsiders. I'm not saying there's a security risk if someone gets a detailed list of IPs, OSs, hardware, etc - good security guys should be able to create that list from scratch quickly anyway - but amongst executives, there's at least the thought that this list is a security risk. Setting aside the actual risk, the perceived risk is high enough that you probably don't want to just dump it in an insecure cloud or DMZ system in an overreaction to the first problem.

re: DBA Best Practices - A Blog Series: Episode 3 - Use a Wiki for Documentation

Argenis — Thu, 14 Feb 2013 15:52:33 GMT

@Brent - great points, thanks for commenting.

re: DBA Best Practices - A Blog Series: Episode 3 - Use a Wiki for Documentation

Ty — Sat, 16 Feb 2013 15:37:11 GMT

Tiddlywiki is a single HTML file wiki... We recently used it to document a sql application with great success.

re: DBA Best Practices - A Blog Series: Episode 3 - Use a Wiki for Documentation

Hugo Mendes — Mon, 18 Feb 2013 10:19:22 GMT

Great article! A wiki is a great tool to store documentation. We currently use confluence which is easy to use and adopted well within the team - even for colleagues who are not fond of documentation they quickly saw how easy it was to update and then how good the search utility is (searches within uploaded content too).

One downside (to add to Brent's comment) is when we perform our yearly off-site DR test, this wiki server has to be built and recovered first (using printed off DR build documents), before we can recover any of our other servers.

On another note, we've also implemented a script (vbs/wmi) that runs weekly, which grabs all prod server information and writes to individual server text files, which are then imported into an infrastructure database. It’s really handy having these [servername_date_config.txt] files at hand.

Scripting really is the only way to ensure that your infrastructure database is up-to-date and correct. Humans are really good at forgetting to update server lists and it only takes one row of incorrect data to put the whole database integrity at stake prompting your manager to assign a ‘please check and update our entire server inventory table’ task to your name.