Interview – Erland Sommarskog

I decided to start a series of blogs where I interview key people in the SQL Server community. Instead of me asking technical questions, I plan on asking about their outlook on the future, books they read (non-fiction and/or technical), and their overall thoughts on where technology (mainly SQL Server) is headed. You can find more interviews here.

Next up: Erland Sommarskog (b ):

Mohammad: Do you think people who dismiss the cloud as a “fad” or just don’t take it serious enough to learn about it (i.e. Azure, AWS, etc), will be in a tough spot to find a job 5 years from now?

Erland: The cloud is certainly not a fad. Fads don’t last this long. At this same time, the cloud does not really seem to take off like Microsoft and others want us to believe. I work very little with the cloud myself, and I have only had one client that was cloud-based. All my other client seem to be on-prem, although there is more than one for which the cloud would make perfect sense.

So, yes, I think there will still be work for earth-based people five years from now, but I think more and more people will start to look into the cloud, and they will be dragged into, whether they like or not. It may even happen to me!

Mohammad: Do you ever see the traditional SQL Server DBA role being replaced/eliminated?

Erland: They’ve been saying that for the last twenty years. I remember when SQL 7 came out and Microsoft made a fuzz about ZAI, Zero Administrative Initiative. It hasn’t happened yet. There certainly still are DBAs out there – although many shops seem to think they can do without a real one. I’m not sure they making the right choice there. You need a dedicated professional to get high availability and preparedness for disaster recovery right. And let’s not forget security and keeping data confidential – this gets more and more important with GDPR and similar regulations.

Disclaimer: I have never worked as a DBA myself, as my profile has been with systems development.

Mohammad: What are you most proud of doing/accomplishing for the SQL Server community so far in your career?

Erland: I’m not the sort of person that finds it important to express in pride in anything. I do what I do, and if people like that, that’s certainly nice. I have my web site, which I usually describe as “a small collection of large articles”, and some of them seem to be frequently referenced to by others. Rather than writing short snippets about various things, my articles are longer and go in depth of the topic they cover. That is just my style.

Over the years, I have answered a lot of questions in the forum. People do not always follow they advice I give them – and sometimes they may be right in doing so, since I don’t know the exact situation are in – but it is always rewarding when you see that your answer has helped someone.

Mohammad: What non-technical/non-fiction book/s would you recommend? If you only read technical books…what do you recommend?

Erland: I don’t read many books, but this summer I did read a book which really got me thinking “Everyone should read this book!”. That book was “Factfullness” by the late Swedish researcher Hans Rosling and his son Ola Rosling and his daughter-in-law Anna Rosling Rönnlund. In this age of “fake news” and where it seems that many people live in their sphere of “news” and rely on hearsay and old information about the state of this world, this book is very refreshing. The world has changed a lot in the last fifty years – and in many aspects to the better than most people are aware of.

Mohammad: For someone who’s career focus has been on one aspect of SQL Server (i.e. Database Engine), do you think it would be wise for them to become a “jack of all trades” by starting to learn, SSRS/IS/Azure, etc. or remain focused on their area of expertise? In another words, which would you say is more valuable? mile wide / inch deep or inch wide / mile deep?

Erland: I’m not really the person to give professional advice, but if I look at my own career, I started as a general consultant who did both real-time programming in embedded systems and worked with applications that used a database. By time I became more and more specialized on SQL Server and the Database Engine. I have yet to learn SSIS or Reporting Services. Or PowerBI or whatever they are cranking out this year.

I don’t think this is unique – most people start out broad, and then narrow down their focus as they get older.

You obviously have to be careful, so that you don’t specialize in some¬thing that dies. You must always be prepared to pick up new things. For instance, myself I’m trying to pick up Python, and I’ve started dabbling in PowerShell. I know Perl well, but it is obvious that Perl is past its prime.

But, no, I don’t believe that if you hold expertise in one area – and then I mean that you really qualify as an expert – that you should “dilute” that and become a jack of all trades. On the other hand, if you are in that “jack of all trades” role today, don’t feel pressed to leave that role. I have kind of been there, and I enjoyed it. And particularly, that is also a role that can make you an expert, to wit, an overall experience of how to build systems.

I like to add one thing that I find important for everyone who work with application development: try to learn and understand as much of the business the application works with. There are many techies who only care about the latest cool technology, but they are not the people who will deliver solutions that users are satisfied with. You need to be able to talk with business people and try to understand as much as you can. That can help you a lot to make a design that the users will like.

Mohammad: Lastly, I really believe in not only learning from your mistakes but, if possible…learning from the mistakes of others. What is your biggest mistake? If you could go back in time, is there something that you regret not doing? And if so, what?

Erland: I have made many mistakes in my career, too many tell about them all. For instance, within twelve months I managed to cause outages in two different production systems. In one case because I was playing around, another because I thought I was smart.

I will tell about the first one as it relates to an item on my web site that I am really happy with, sp_sqltrace, which written by Lee Tudor, and I am very glad that he asked me to host it on my site. This procedure accepts a batch of SQL text, and then sets up a trace that is filtered for your spid. When the batch has completed, it collects the data and aggregates it per statement. This is particularly useful if you have something that runs a loop and statements are executed many times.

sp_sqltrace also has an option to collect execution plans, either estimated or actual. When Lee had just sent me the first version, I wanted to test this option on some real-world data, so I ran it the production environment of one my client’s customers. Something did not really go as planned, so I had to cancel the execution. Later there were reports about serious performance problems. As the customer had made a radical change the day before in their environment, they thought that was the reason. As the day went on, the performance problem sort of faded away only to came back the next morning. (Because the nature of the business, there is a peak just around nine o’clock.) I was working and trying to find out where the problems were. At some point, I noticed that there were some traces running, which I realized was from my failed attempt to run sp_sqltrace the day before. Because I had cancelled execution, the traces had been left running. I stopped the traces, but I did not really make the connection until later, when I was trying to find the bottleneck of a very critical stored procedure. I used sp_sqltrace to see if could find something. I was puzzled to see that when I activated execution plans, all statements in the procedure was taking longer time.

Eventually it dawned on me, something I knew very well: when you activate actual execution plans in a trace, this is activated for all spids, even if you filter for a certain spid. And then I realized the reason why the customer had experienced performance problems. It was exactly because of those two traces I had left running for over 24 hours.

As a consequence of this embarrassing incident, sp_sqltrace now sets up the trace with a stop time, so that even if sp_sqltrace is interrupted, the trace will by default not run for more than five minutes.