Not your usual documentation question

  • I am a server/SQL admin in a large organization. We have thousands of SQL databases on many clusters and individual servers supporting many departments. Each major department has their own DBA's who (we hope) document their database structures.

    The issue we have is not the actual database documentation, but rather the high level "what is out there", "who owns it", "what application connects to it", etc. We do have some documentation that has been compiled over the years, but nothing comprehensive and complete. Us admins have been asking management to get involved in this for years now (apps, servers, SQL, etc.) and nothing went forward so I have taken it as my personal task in what little free time I can scrape up.

    Before I spend too much time building requirements I wanted to see if there are any tools, templates, scripts, etc. that have been created for this purpose. Commercial or non-commercial is OK. Something that goes beyond just SQL to document servers, applications, etc. would be a huge benefit. Tools that would scan the servers for info would be great because none of us really has time to manually discover and document the basic data. I have been hunting for something like this without much luck.

    Can anyone make some suggestions?

    Thanks

  • This might be a good suite of products to look into. Very solid and professional and used by many large enterprises with hundreds of servers. Free trial downloads available and they provide very good technical support. (No...I don't work there, so this isn't a just a plug.)

    http://www.sqlsentry.net/[/url]

      

  • Here comes a silly question...

    What product does SQL Sentry offer that does what the OP requires?

  • Try a search for ITIL CMDB tools for an introduction to available productss that do what you are looking for.

  • There are several tools in the market that can build (and monitor) an inventory of "what is out there" but, when it comes about "who is the owner", "what application connects to it", etc., I'm afraid it would be an old fashioned investigative job involving phone calls, endless meetings and Excel documents.

    Either way, a good starting point is to really know "what is out there", not only because it will be the foundation for the rest of the documentation work but also because it will help to track the "licensing" issue.

    _____________________________________
    Pablo (Paul) Berzukov

    Author of Understanding Database Administration available at Amazon and other bookstores.

    Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
  • Maybe the article Finding lost or forgotten SQL Servers will give you a single tool for your tool box: http://www.sqlservercentral.com/articles/powershell/72809/

  • The Microsoft Assessment and Planning Toolkit will go out and find any SQL instances out in an environment.

    Microsoft Assessment and Planning (MAP) Toolkit

    Joie Andrew
    "Since 1982"

  • OTF (7/18/2013)


    Here comes a silly question...

    What product does SQL Sentry offer that does what the OP requires?

    I use SQL Sentry myself and love it. It is a great product and I'd recommend it to anyone. No, I don't work there either.

    However, OTF asked what it has to do with the original post. My answer is "not much". It provides many metrics and keeps a history of query activity, plans, etc., but it will not compile a list for documentation purposes.

    PaulB pointed out that old-fashioned investigation is required and I believe he's absolutely correct. You're in for a long haul on this one. If there are tools out there to see what applications connect to what database, I'd be interested in them too.

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply