What information should I keep for each database ??

  • garry.lovesey

    SSC Veteran

    Points: 289

    Hello,

    I have just become our SQL DBA (we haven't had one for a few years) and we have no documentation for any of our servers or databases.

    I have no experience of being a DBA and would appreciate any help.......

    I am currently putting together a spreadsheet with information about our SQL landscape.

    So far I have identified the following:

    Instance:

    . PRODUCT

    . EDITION

    . PRODUCTLEVEL

    . VERSION

    . PLATFORM

    Databases:

    . DATABASE NAME

    . STATUS

    . COLLATION

    . COMPATIBILITY LEVEL

    . AUTOSHRINK

    . RECOVERY MODEL

    . SIZE (MB)

    . SPACE AVAILABLE (MB)

    . Data Drive

    . Data Size (MB)

    . Data Used Space (MB)

    . Log Drive

    . Log Size (MB)

    . Log Used Space (MB)

    Am I missing anything ??

    I have made this into a powershell script so that it can be created and updated whenever we need it.

  • GSquared

    SSC Guru

    Points: 260824

    Automated basics like that are definitely a good place to start.

    The most important thing about a database, however, isn't something you can automatically document. The most important thing is "what is it for and who uses it?"

    Once you know what a database is for, and to whom it is important, you can determine things like "what recovery model should it be in?" Automated scripts will tell you what recovery model it is in, but not what recovery model it needs to be in.

    You're definitely heading the right direction.

    And, there are two things I always like to tell new DBAs:

    1. A backup plan isn't what you need, a restore plan is what you need.

    2. Your job is to make your work as boring as possible. When things get adrenalized for the DBA, that's usually really bad for the business, because it usually means a database or server is down. (Doesn't mean the work can't be interesting. Just it shouldn't be heart-pumping-exciting.)

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • spaghettidba

    SSC Guru

    Points: 105661

    Brad McGehee has a nice spreadsheet that you could use to document your instances.

    You can find it here: http://www.bradmcgehee.com/2012/06/do-you-document-your-sql-server-instances/

  • garry.lovesey

    SSC Veteran

    Points: 289

    Thanks Guys.....Brad has some great stuff on his website that should keep me busy for a while. My agenda runs:

    1. Document systems

    2. Implement backups and maintenance tasks

    3. Investigate / fix security issues

    As well as the daily tasks.....

  • Brandie Tarvin

    SSC Guru

    Points: 172707

    Another recommendation:

    Learn the data, learn the business.

    If you know the data well enough to recognize bad data the instant you see it on a report or in an administrative request, you can make yourself a hero to your customers.

    Of course, you can't always learn the data & the business (it's easier to do in small shops). But if you can learn something, you can help the end users automate things (reports, etc.) they never thought about.

    And, as has already been mentioned, your job is to be the forgotten one. They'll only remember your name when things go wrong (or when you help them remove a lot of their manual workload). If things go well, they'll barely know you're there.

    Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.

Viewing 5 posts - 1 through 5 (of 5 total)

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