Last week I asked the following question on twitter: –

I had a load of responses from a lot of DBAs out there who have worked some crazy shifts, you can see all the responses here

My personal record is due to a data centre migration. We moved all our physical kit from on-site to a data centre. I racked up 23 hours straight, followed by another 14 hours.

Pretty heavy going but nowhere near some of the responses I had (seriously there were some mammoth shifts in there).

I’m not sure how everyone else feels about these kinds of shifts. They’re definitely not enjoyable when they’re happening but I kind of hold onto mine as a badge of honour. Something that every DBA goes through and it’s one of those experiences that I feel has made me a more seasoned DBA.

Saying that, I don’t want any 20+ hour shifts again any time soon 🙂

Have a good (hopefully not too long) week!

Last week I was reading this article in which a Professor argues that students should be allowed to take smartphones and laptops into exams: –

Professor Mazur urged academics to take the next leap allowing students to use their laptops and phones in exams. He himself encourages students to bring their mobile devices into exams to “look up whatever you want, whenever you want” arguing that in the era of the Google search, students “don’t need to memorize anything.”

Now I don’t completely agree with saying that students don’t need to memorise anything but I do agree with the following statement: –

…he prefers students to be creative and use critical thinking and other analytical skills.

Analytical skills are absolutely critical to any IT professional. The ability to figure out what the problem is, research, and then deploy a solution (with a rollback in mind) is pretty much a cornerstone of what we do.

Ok, I fully admit that “googling” an issue doesn’t appear to be much of a skill but if you think about it, yes it is. Googling follows the same exact analytical procedure I identified above; figuring out the problem, searching for a solution and then identifying the correct one from the results.

However, a certain amount of base knowledge is required for this process. You need knowledge of the systems that you work with in order to identify the solution. Blindly googling and deploying the first solution displayed is a recipe for disaster.

Have a good week!

This month’s T-SQL Tuesday’s topic was set by Rob Sewell (b|t) and entitled Let’s all get PoSH

It had a massive response with loads of people writing about how they use powershell to automate tasks in their day to day work.

(Shameless self promotion – I wrote a post about how to create VMs with powershell, you can check it out here)

It was really cool to see how everyone uses powershell and for me answers the question “Should DBAs be learning powershell?”

Yes, yes you should.

I’d actually go further and say that you need to be learning powershell if you want to get anywhere in your career as a DBA. It’s a tool that in my opinion, every DBA needs. Yes you can get by without it but then you’re limiting your skills.

Here’s some of the posts that should give you an idea of how powershell can help you out: –

Daily database copy using Powershell
Disabling the named pipes protocol for SQL Server using Powershell
Using Invoke-SQLCmd to run SQL Jobs Remotely
Automation Through PowerShell Checking the Status of AGs
Turn on/off Azure VMs with Powershell

That’s a wide ranging area that powershell can help in, right? Pretty much anything you do as a DBA can be run in powershell. If you type something more than once? Hey, guess what!?

So if you’re not working with powershell, I highly recommend that you start looking into it. You’ll find a whole load of cool stuff that you can get into, from basic functions to modules like dbatools

One piece of advice for when you start writing…if it works, it works. Oh, and get your scripts reviewed by someone. It helps in ways you won’t even think of.

Remember that we’re all learning this stuff.

For example, I’d consider myself fairly decent at writing powershell scripts and recently asked a friend of mine to review a script I wrote. Here’s his response: –

Andrew, powershell is a beautiful language and you, are butchering it…

Ouch! 🙂

Thankfully he followed that up with a whole bunch of good tips on how I could improve my code.

But the point is, we’re all learning and there’s a whole bunch of people out there ready to help. So, give it a go and see what you can script.

Have a good week!

Back in March I did my first “feature length” presentation at SQL Saturday Iceland

At that point I’d done a few lightening talks and wanted to see if I could move into hour long presentations. I was really nervous doing it but after the first 10 minutes I settled down and really enjoyed presenting.

Since then I’ve done a couple of online webinars, SQL Bits and have started sending abstracts to nearly every SQL event that I can attend.

I was expecting to only get a couple of sessions over the next few months but I have been blown away with the amount of sessions that I have been given.

Here’s the current list (hopefully there’ll be more): –

SQL Saturday Cambridge: 9th of September

Cork SQL User Group: 20th of September

SQL Saturday Holland: 30th of September

SQL Saturday Denmark: 7th of October

SQLRelay
– Reading: 9th of October
– Leeds: 11th of October
– Birmingham: 12th of October
– Bristol: 13th of October

If you’re at any of these locations and want to learn about SQL & Containers, come and jump into my session! Even if you can’t make it to my session, I’ll be at the event all day so just come up and say hi! 🙂

Have a good week!

Last week I was working on an upgrade and ran into a few issues. Whilst waiting for the company’s support team to come back to me I had a few attempts on my own to resolve the problem but had no luck.

When the support team came back it didn’t take them long to uncover the problem, me.

I’d tried to be a bit clever at the start of the upgrade and made a change to the system that I thought would be of no impact. As soon as that change was reversed, surprise! The issue was resolved.

After eating quite a lot of humble pie I got to thinking about my problem solving process. To be honest, I’d forgotten about the initial change that I’d made and spent too long focusing on other areas. What I should have done is gone back to the start of the process, detailed each step I’d taken and what impact those steps could have had.

Now, I was going to give the advice of “Always follow the instructions” but, I’m a tinkerer by nature and not likely to change.

So with that in mind, here’s the advice I’m going to give to any fellow tinkerers out there: –

• Read the instructions
• Note any changes that you want to make
• Test those changes on a development system
• Does the system still work?
• Roll back those changes
• Does the system still work?

Hopefully following that advice will prevent you (and me) from repeating the mistake that I made last week.

By noting down any changes that you’ve made, when you encounter issues you will know where to start. Sounds simple huh? Yeah, I know…

Still not going to stop tinkering though 🙂

Have a good week!