July 5, 2012 at 6:07 am
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.
July 5, 2012 at 6:13 am
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
July 5, 2012 at 6:48 am
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/
-- Gianluca Sartori
July 6, 2012 at 3:50 am
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.....
July 6, 2012 at 6:24 am
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.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply