Today, I’m not thankful that it’s Friday, although I am happy about it. Today I am thankful for the wisdom of Grant Fritchey ( b/t ). No Grant didn’t help me with any kind of problem, at least directly. Hell, I have never even met the man in person anyway. No, I’m not some kind of weirdo interwebs creeper either. I do, however, follow Grant’s blog and occasional twitter posts. What can I say, he’s a pretty sharp crayon when it comes to SQL, and as a DBA I like and listen to, sharp crayons. Although today I’m not thankful for Grant’s technical wisdom. Today I am thankful for his wisdom related to making the relationships between the DBAs, devs, IT, and business folks better.

As you know, COVID-19 has upended well…everything. This means, that at my company priorities have been upended as well. So with fast responses to technical and business problems, IT hasn’t had to polish things out and make them experiences seamless. This week, I forgot about that and started letting my ego and my own self-importance get the better of me. I was focused on the problems related to databases and the SQL instances I work with, I forgot about the bigger IT picture. During a SCRUM call, I was a little too honest about my frustration related to connecting to instances in the cloud and how unintuitive access currently is, along with the inability to use our toolsets. It was pointed out to me later, that my frustration was a little too apparent and could have been seen as hostile towards the IT folks on the call.

Own itOwn It

So today, I used some wisdom from both Jocko and Grant, I chose to own it. I decided it was better to apologize for my ego whether it was misconstrued or not and make sure to foster a better relationship between IT and the Data Team. So instead of dismissing it as just as a misunderstanding in a moment, I opted to take 20 minutes to send an apology accepting all of the blame. I’m not posting this as a humble brag about my moment of empathy either, I am posting this to both remind myself I will be better publicly and to reinforce the lesson. The bottom line, it is better to remain humble and approachable than to fracture getting work done because of some unmet, implied expectation that neither side had agreed to.

I will be better.

 

As a DBA, working from home (WFH) is not a new concept or new experience, I do it a lot. However, this shift to working from home due to the office being closed for Covid-19 is a little different. First off, I’m enjoying getting my commute time and saving money on fuel. The downside is, since moving in 2017, I haven’t put a lot of effort into getting my work area properly set up for me. So that’s a bit distracting.

Other things I have learned Working from home

  • I need to keep my schedule as similar to the office as possible
  • I need to structure my day as I normally would – times for learning and deep dives, etc.
  • I need to remember to get up and move
  • I need to remember to take breaks

Work from homeI’m naturally an introvert and don’t mind being without a lot of people, so I imagine that’s been a little easier on me than most. Although there are times when I need to communicate or just banter with people: I can use Teams for that at work and Twitter for the SQL community, not that I’m on Twitter a lot.

With everyone else working from home, I have noticed a few things that I do differently that has made my life easier. I leave my work laptop at the office, mostly because it’s 10lb brick and I prefer carrying my MacBook instead. So instead of VPN’ing into the Office, I have a LogMeIn account, so I was spared all the issues with the VPN being maxed out. I also prefer LogMeIn because if my connection gets dropped to the laptop, and I’m running a script than the script doesn’t get ghosted on the SQL side.

Please don’t

Somethings I have seen people do that they probably shouldn’t over VPN:

  • Don’t do virtual meetings over the VPN, you’re chewing up bandwidth. Instead, drop the VPN connection to have the meeting.
  • Have a backup plan in case the VPN has an outage
  • Please, please for the sake of those you work with – pay attention to the ambient noises. We know your kids and pets are cute, but listening to them in the background makes it harder to hear.
  • Use Mute. Really….if you’re not talking, put yourself on mute.
  • Don’t drink or chew on calls unless you are muted.
  • If you have a webcam set up, be careful what you broadcast, and don’t forget it’s there.

It’s going to be awhile

Just because you are not in the office, that is no reason to act unprofessional or forget to take care of yourself. Working from home can provide a golden opportunity to get your diet under control, get some training in, as well as spending time with your family and doggos. You can feel good about reducing your carbon footprint (if that’s important to you), you can use the savings from commuting and eating out to fund a vacation when practical, or you can just enjoy the slowdown and quiet in your daily life. We’re going to be at this a while, so we may as get good at it.

I don’t know why I am slow to take up new tools, but I am. I recently, like back in December, began working with DBATools. In case you’re not familiar, DBATools is a PowerShell module assembled by the community over at DBATools.io. This module, oh this wonderful module, makes some of the most aggravating parts of a DBA’s job so much easier. Things like server migrations, copying users, adding Ola’s jobs, and a slew of other things so much simpler.

What sold me? Well in December I had to migrate 70 some small databases off to a new SQL AG. I knew I was going to have to script out the backups so I decided this was a good as a time as any to learn Powershell and solve a problem. That thought process got me thinking about DBATools, and I decided to see if the module could help me out. Oh, and help me out it did. This module is a tool EVERY DBA should be using.

DBATools works

I went about setting up the list of databases into a Powershell list, created a specific UNC file location for the backups to land on, and ran the following the code:

Backup-DbaDatabase -SqlInstance $server -Database $dblist -Path $path -Type Full -CopyOnly -compressbackup

Where $server was the name of the server I was backing up from, $dblist was the list of databases I needed, $path was the UNC location. The -CopyOnly switch, made sure I didn’t affect the backup chain on the server I was migrating from. Although, this was less of a concern post-migration.

The really cool part about this, or at least I thought it was cool, was the restore command.

Restore-DbaDatabase -SqlInstance $newServer -path $path 

The restore command allowed me to point the restore command to the path, and it restored each database in the directory to the default file locations. Pure genius.

Other areas of the toolset I used were copy users, migrate settings, migrate jobs, and copy linked servers to name a few. Oh, this tool saved me so much work and time. I’m not sure why I did not embrace it earlier.

“The Only Thing That Is Constant Is Change ”

– Heraclitus

A long way back, a Greek philosopher said something about change being the only constant. The guy was right, but he would have made a horrible IT project manager. It’s a true statement, but at the same time forecasts an ever-changing landscape that is hard to pin down and stay on top of.

The rate of change is always about the same, as fast as possible, but the directions have shifted back on itself. Twenty years ago, when I was starting out in IT, the focus was to move off the centralized computing platform with terminal interfaces in favor of multiple servers and client access. Now we’re shifting back to a centralized platform. Of course, back then, it was mainframes and terminals versus today being the cloud and devices (phones, tablets, laptops, etc). I suppose with the promise of high mobile bandwidth that makes sense.

Containerization

I think in the next 10 years, probably more like 5, containers are going to push out Virtual Machines. Less to manage, easier to spin up, and can use Orchestrators like Kubernetes to manage the systems. Why troubleshoot a failed system, if you can just quickly replace it? I also think it’ll be an easy way to horizontally scale SQL Availability Groups (this is probably a pipe dream) across containers. Toss a load balancer in the mix….and suddenly you’re not as constrained on reads. The only problem to solve is that of licensing. Of course, if it’s a write-heavy application than you may still need the power of a traditional node.

Infrastructure as Code (IaC)

IaC is the next move forward in the infrastructure space. Why? Because why should we be sitting around clicking next when we can define a server or application with declarative code and it takes care of the build? Oh ya, and add in source control, the config file is maintained, documented, and versioned. I don’t know why anyone would fight this, except those who feel threatened. Plus, a positive is when Azure has a sale and you have to move your entire organization over from AWS, or vice versa, it’ll be a lot less work the second time.

The downside is, I think for those coming up in the ranks now and in the future are going to lose some valuable troubleshooting skills. Although I say that, I can’t remember the last time I’ve thought about if a comm port issue that was related to an IRQ or memory address. It is good for trivia when you ask the younger crowd what the difference is between the different comm ports are.

Source Control

I honestly don’t know why it has taken so long for Source Control to catch on outside of development. I mean I get it, there’s a bit of a learning curve and branching isn’t something I have completely figured out yet. But dammit, it makes working on the same piece of code so much easier for me to work on between different computers. With my team at work finally embracing it, I’m looking forward to seeing how it helps us.

DevOps

I think the ’20s are going to be the decade of DevOps. And by that, I mean on 12/31/29, DevOps will have been the default for years. Spinning up servers by hand will be a rare exception, but more like a novelty. And all of the previous things I listed are components of DevOps anyway. See, it’s already happening.

Change is Change

Change can be either good or bad, but I think it depends on how you see the change. Regardless of how you view it, it’s going to happen. Perhaps instead of fighting it, embrace it…..use the new decade as a launch platform to retool your skillset, embrace new technology, geek out and have some fun learning.

This comes as no great shock, I haven’t been as active with blogging as I once was. Or that I was ever really that consistent of a blogger. Most of my traffic that shows up on this site is from Google searches on specific problems, and most people bounce right off my site. I’m ok with that. I tend to use this blog more as an online repository for the things I learn anyway. Which brings me back to…. I haven’t been blogging much lately.

You could read into that, that I haven’t been learning anything, or even that I haven’t been learning anything worth blogging about. There is probably an element of truth to that, but for the most part, my lack of blogging has been more about not taking the time to do it. I could list off excuses, but then I wouldn’t be owning the problem.

The rededication part

write it downSo what am I rededicating? Me. I’m re-dedicating myself to blogging. I intend to work on a few projects, languages, and other things that others might find interesting. At the very least, I’ll work on my writing.

Some of the things I hope to, nay…I will blog about in the future are IaC, source control, DevOps, Python, PowerShell, containers, Kubernetes, c#, terraform, puppet, PowerShell DSC, and always SQL. This is my learning list for the year. I hope to make at minimum one post per week, but I am going to shoot for two.

Then as time allows, and I get more comfortable again with the blog, I hope to update the template, code snippets and add other things. In addition, I also hope to go back through earlier posts to make them better. As I also work on this blog, I also hope to be more active on twitter and slack in regards to SQL.

Lofty goals I know, and without accountability too easy to miss after the first two weeks of the year. So each month I am going to post a reflection on what I have learned this month as well as how I did blogging.

When it comes to working with other people it is always best to remember that others are not always on the same page. In fact, when dealing with others that work alongside you, it is imperative to remember they are most likely to see and evaluate issues and opportunities differently from you, especially when you work in different technologies. These differences typically are what makes teams work so well and helps everyone get along.

I recently had an interaction with a colleague who is a developer. This interaction came about when another DBA and I saw a query come across our monitoring tool in a different fashion. The conversation went from a question with the purpose of trying to understand what the developers were doing to sliding off the rails because the initial explanation was dismissive.  Which led to the DBA’s questioning the security and performance of the developer’s new strategy. What came next was just appalling. The developer responded with some snide remark about questioning their approach, their intent was beyond the understanding of the DBAs, and source control was the main objective.

I have to admit, I was left floored. In all my time in IT, I don’t think I have ever been patronized or dismissed so out of hand because I questioned the performance impacts of a development approach in regards to a database server. I also understand that source control is the new hotness and all the rage, but writing code strictly for the sake of better source control sacrifices performance.

Developers and DBAs should be working together. Lord knows most DBAs do not understand all of the implications and complexity of writing front end code, and the same is true of developers with SQL. Getting along is what makes the late nights easier, the troubleshooting faster, and inevitable pissing matches less. It also removes the resentment that leads to higher turnover.

It’s been a couple of years since I have been able to attend a SQL Saturday. I was grateful I was able to make it this year. This year however was a first for me, it was my first SQL Saturday in Minnesota and the first time I went to a precon, both were enjoyable.

On Friday, I went to Monica Rathburn’s (b/t) precon – SQL Server Performance Tuning and Optimization for the DBA. It was definitely worth the time and expense. I learned a lot and Monica is an excellent, as well as an energetic, speaker. I was reminded, when it comes to SQL not everything is set in stone.

Saturday was equally as good…although the weather turned and spent the day watching snow squalls. It made the 3-hour drive home a bit longer. I concentrated on DevOps tracks, with the exception of a presentation on leadership given by James Phillips (b/t). I really enjoyed James’ presentation and wish more managers were as focused on being leaders as he was.

All in all, it was a great couple of days of learning. My only regret was I wish I had stayed overnight one more night to attend the after-party. Ah well, maybe next year.