I got in at 9 AM, and found an empty spot in the back of the room between two fellow DBA’s. I said good morning. Only the guy on my left responded with a similar gesture. I felt a bit awkward as this was my first day amongst this many computer scientists nerds ever. I did not know what to expect, but at least I expected people to say “Hello” or “Good morning”. I felt astranged, asking myself: “Am I also like this?”. I know I am not, because my friends repeatedly tell me I am overly social. I have got quite reserved feelings about what they mean when they say this, but at least I say “Hello”.
This was my first morning at SQLbits. Not knowing what to expect, and feeling a little shy as wel because I didn’t know anything about the other guys in the room. “Do they know more? Are they better than me? Am I at the right place here to learn something new?”
“Good morning! How y’all doin’!?”. A Texas voice sounded through the room. I looked up from my laptop and there were our gurus: Sean and Jennifer McCown. A husband and wife couple, and I don’t remember if this is what they said exactly but they are from Texas, so let’s just stay with that, y’all.
Let’s get a view of the audience: “How many sql servers are you guys managing, right now?”
He wanted to hear from all of us, going left to right, front to back of the room: “4 I heard. 20, 15, 50, 150, (me:)200, 400”. 400 was about the largest number I heard that day, thinking: “Damn, I’m a pretty big fish in this pond of sql server dba’s.”
“WRONG!” Sean exlaimed. “One!”
“Huh?” We just told this guy we have to manage hundreds of servers, and he is like: “One!”? Of course, he wanted to make a statement. Theatrical, like all things from the US, but effective nonetheless.
Watching and learning from Sean and Jennifer was a treat.
Sean told us how we should standardize our sql servers across our environment, like: standardizing mountpoint names so you can script operations across your entire farm.
“How would you go about updating server settings across your server farm?” Sean asked us. Again, lots of different answers from the room: use a cursor to loop over instances from your management db, or get your junior dba to do manual updates for you on all the servers. (This is a nice one, I think. Let’s see how long the junior guy (m/f) takes before he/she figures out how to script things instead of doing them manually :p). “Umf pwfswl!”, was what I heard someone say from the right side of the room… “Pwfswl!” turned out to be the answer Sean had been waiting for. Of course the guy meant “Powershell” but hey, in a time of ethnic emoji, this guy was entirely right.
Standardization is key. Like, for instance, you have your set of maintenance scripts: instead of installing this script manually on all of your servers, use Powershell to push it to all of your servers.
It’s quite simple: say you have your own little custom made management db where you keep a list of all your known instances. (I have mine; have you?). If you do, it is very easy. Use Powershell to get a list of all your managed instances. When you have that list, use something like Invoke-Sqlcmd to run your sql script on all your managed instances. It’s that easy. It will take less than an A4 paper size (or Letter size) of coding to get your stuff running.
This is where the core of their presentation was about: using tools like Powershell, deploying scripts, updates, etcetera across your server farm just like you were managing only one server. Great stuff.
Of course, there were a lot more things they talked about. I have about 5 A4 pages (I’m from Europe. Letter size would be 5.5 pages :)) full of notes, so I couldn’t possibly go into them all without boring you.
One thing more though, and…
It’s about backups. Of course it is. In my company, we are using Ola Hallengren’s backup scripts. Take a look at his free maintenance solution which has won best-of prices in consequtive years in SQL Server Magazine. It does a lot more than making backups, but there is one drawback to his solution: it doesn’t allow you to manage your backup intervals in a central location.
Why would I want that? Well, I know, right now, all my backup schedules are allright. Meaning: I know some of the backup schedules for specific applications by heart and I know my standard schedule. That should be enough. I mean, I know I am performing a log backup on my BizTalk Messagebox database every 3 minutes. Generic non-sla dependent application databases have hourly log backups, VMWare’s VCenter database is in simple recovery model according to VMWare’s recommendation (although I am not so sure if this recommendation is right to our needs; I’m going to talk to my VMWare admin about this) and my SCCM databases are being backed up by SCCM itself, using snapshots of the Windows disk.
Right now, when and if a db should be backed up is configured locally on each server, without centralized oversight. This is really bad, because this means I can’t push a new version of my maintenance script to my servers without manually checking for discrepancies, and also having to manually set backup schedules accordingly.
So, in the next few weeks I will be investigating what my options are in centralizing my backup settings. I am waiting on Minion Backup for inspiration, but if I find something in the meantime, I will keep you posted!