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.

Everyone has seen the meme that the cloud is just someone else’s computer. Or that people don’t understand the cloud. I think either has become too simplistic of an explanation. The fact of the matter is, we all have embraced the cloud in some fashion.

cloud outageThink about our Google or iCloud drives that we save documents, music, or photos to. How many of us subscribe to a music app that delivers music over the net? Streamers? Do we have TV streamers around? The cloud is taking over for sure. It’s starting to become the platform of choice in business. It’s fast to ramp additional resources, it simplifies the infrastructure, and all you need to do as the consumer is to feed it money.

No ground under the cloud

What happens to your music, documents, pictures, or SQL server if the internet is down? Or there is an outage because not only did a fiber line get cut, but the electrical grid had a massive failure? How resilient is the cloud then? What’s the cost associated with that outage and is it worth it?

Obviously the cloud is here to stay….but jumping all in may not be the best practice either. As a DBA, I always work at leaving myself an out. If code goes bad, a server crashes or some other unplanned nuisance rears its ugly head, I generally have an alternative in mind. We should be adopting that same strategy with the cloud as well. If Amazon, Azure, or someone else goes down for an extended time…..what’s the fall back plan other than just being down? In other words, do you have a parachute, and is it working?

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.

Recently, I was working with a gentleman in our IT department and we were discussing adding redundancy to a couple of SQL Servers that were used for web apps. Turns out, VMware’s disk consolidation can, and will, take a server offline. That tends to make customers unhappy, and rightly so. Anyway…I digress.

We were discussing adding redundancy to a couple of single-node environments and the gentleman kept referencing Always On, so naturally, I thought he was talking about Availability Groups. Another lesson here is to listen completely and not just for buzz words. So did he, in a fashion. He had seen what the licensing changes were with SQL2016 SP1, basic availability groups were an option on the standard license. I pointed out that basic AGs only allowed for one DB to be put into the AG per listener. In our case, that wouldn’t work. The IT gentleman continued to push, pointing out that AlwaysOn Failover Cluster Instance would work under the Standard license with two nodes.

Then it hit me

Microsoft’s marketing team throws a monkey wrench in the terminology. When I looked up what AlwaysOn Failover Cluster Instance really is, I realized it read a lot like traditional SQL clusters. You know, two nodes, shared storage, only node active at a time, with 30-90 second fail overtimes. That IS a traditional SQL cluster.

I don’t know why MS decided to rename something that has been around since forever, but they did. It’s probably more likely that I missed a press release or some other email. If that’s the case then this post is probably redundant. However, if someone else gets caught unaware, hopefully, this comes up on Google to quickly help them.

 

It’s Thanksgiving Day and before we know it, Christmas and the New Year will be upon us. 2018 hasn’t worked out as I planned. In fact, 2018 has been a difficult year for me personally.

The first half of the year

Jan – April was rough for a number of reasons. It was a cold and snowy winter in the Northland. The cold didn’t recede until the end of April and snow hug around until May. It was a rough welcome after moving up here in December.

In Jan my wife’s grandfather was diagnosed with advanced Alzheimer’s. He was placed into a nursing home and my wife was made his guardian in Feb. We spent all of our free time from then to June conducting an inventory and listing repairs to his estate. 

The Summer

After getting the inventory under control, my parents moved up from Denver. They were just as sick of the traffic, crowds, and cost of the Front Range as I was. So after visiting a couple of times, they decided to spend their retirement here.

So we spent the month of June and part of July helping them get settled. The rest of the summer was spent doing outside work on various properties. We also started the process of sorting her grandfather’s “stuff”. Which is really just a nice way of saying his dementia had been occurring longer than we realized. So there is lots of stuff to clean up and go through.

The fall

We didn’t have much of a fall. It kind of went from summer to rainy to winter. Now it’s time to get things ready for winter, which kind of snuck upon us. We did however replace our fifth wheel this fall, so next spring/summer we can take some time for us. Unfortunately, my Dad’s cancer has had a resurgence. So I help my parents with whatever they need while my Dad goes through chemo again.

What’s coming

The upside is, things are slowing down with winter moving in So maybe we can get finally get settled into our house, we still have things to unpack. I am also hoping I can spend some time focused on learning a development language or two.

I’ve had time to reflect over the last year, and I’m thankful we moved up here when we did. There is no way we could have handled this from Denver. It’s been rough and we’ve made sacrifices, but living in the woods has made it worth it.

I hope 2019 is a bit easier, and I hope everyone who reads this has a good holiday season.

One of the hardest things to do when looking to start out in the SQL world is to find quality sources to learn from, or just not get overwhelmed with information. To help alleviate that, I have assembled a list of resources that I use to continue learning and research problems I might encounter.

What follows is a list of places to go. I also will periodically update this list as I find new sources, or old sources drop off.

Web sites

SQL Server Central  – Has Stairways, articles, and other various resources to learn Microsoft SQL

PASS – Microsoft Professional Association of SQL Server professionals – free to join and do monthly training webinars that are free. https://www.pass.org/

SQL Saturday – Local SQL events that provide free SQL training one Saturday a year. https://sqlsaturday.com/ – It’s also a good networking event.

Twitter – Microsoft SQL pros are very active on twitter. Check out the #SQLHelp to get a feel for problems. It’s also a good way to meet other SQL folks.

SQL slack channel – How to join the SQL slack channel – Oh and another good way to meet SQL folks.

TSQL Tuesdays is a monthly Blog party based on topics of interest to SQL professionals. – http://tsqltuesday.com/

Bloggers

There are a number of bloggers to follow. Most of the resources are free, but there are a few that have paid materials

Blog

To help build your IT credentials it’s helpful to start a professional blog to document what you learn, showcase your work, and help others with similar situations. You don’t have to pay someone to do or invest a lot of money into it. You can start off with free blog website services to get your feet wet.

Podcasts

Podcasts are a good place to learn about the SQL profession. Although sometimes it can be overwhelming and tough to follow, it still helps to listen. Sometimes the topics will trigger “aha” moments that lead to a small epiphany.

Learning about proper development isn’t such a bad idea either. You can pick up a lot of information about SQL and what is needed by the devs from the SQL perspective.

Soft skills are important as well. I recommend checking out the following podcasts to help in that arena.

Other areas to explore

Other areas to explore would be to pick up Powershell and Python.