Episode 116: Are people still using PSSDiag?

If you have ever worked with Microsoft support, you probably came across the PssDiag tool they use to collect information about your environment.  My experience with the tool is it always seemed, well–a bit clunky.  Now, it does collect lots of information and seemed to be a bit overwhelming when I was first a DBA.  Fast forward a few years and PssDiag was not a tool I use anymore and was not sure if anyone outside of Microsoft was using it.  I run into Jared Poche in Raleigh and he mentions he really likes the tool and mentions some of the improvements they have made over the years.  Well, you can guess where this is heading.

We talk with Jared about his experience with the tool and cover some of the basics about how you might go about using this tool in your environment.  There are two pieces to this tool, the first is the utility that collects the data and the second is the reporting piece SQL Nexus.

Are you using PssDiag?  Let us know in the comments below.

Episode Quotes

“It’s a really good tool in that it captures data from a lot of different sources and you tend not to miss much with PSSDIAG.”

“It is absolutely the go to tool for Microsoft.”

“Again using PSSDIAG and the Nexus will give you very visible data.”

“My biggest concern with PSSDIAG is people being too aggressive with the data they are trying to return from it.”

“Running it over the network is a really bad idea.”

Listen to Learn

02:47   What is PSSDIAG? What it runs and its usage?
04:54   Is Microsoft’s PSSDIAG and the publicly available different?
05:38   Using PSSDIAG in a small shop or in a large shop.
06:51   SQL Nexus
08:19   Improvements on PSSDIAG
09:42   How often Jared uses PSSDIAG?
10:13   Compelling reasons why to use PSSDIAG
16:04   Hand off point of getting information about the system, transitioning to smaller data set
20:52   PSSDIAG or DMVs? Which is a great place to start with baselining
24:12   Other common parameters in PSSDIAG, light capture vs. detailed capture
28:14   Tips and suggestions for starters
32:02   SQL Family questions

About Jared Poche

Jared Poché began working with SQL Server as an instructor for certification classes and has a passion for teaching and performance troubleshooting. Jared spent 10 years providing customer support at Microsoft, most recently as a Sr. Support Escalation Engineer. He is currently a database engineer working in Morrisville, NC and is leveraging his extensive knowledge to develop online coursework for SQL Server.

*Untranscribed introductory portion*

Carlos: This is Carlos Chacon.

Steve: I’m Steve Stedman.

Jared: I’m Jared Poche.

Carlos: Jared, welcome to the program.

Jared: Thanks for having me.

Carlos: Yes, it’s good to have you on and we’re kind of taking a break from our usual suspects at ChannelAdvisor. We met at the SQL Saturday in Raleigh and we’re talking. Ultimately our conversation is on PSSDIAG, but always good to talk with the ChannelAdvisor folks and your team is growing. You’ve added a few new community members that I know of and that’s always fun.

Jared: Yeah, Anders spoke at the SQL Saturday in Charlotte recently. I think we have 5 people there.

Carlos: Ok, very good.

Jared: I’m still kind of astonished by how active the DBEs and DBAs are in the community.

Carlos: That’s right, and so companeros, for those listening and I go back to a comment that Brian made, one of the DBA Managers over there. He said, “Some of the folks at ChannelAdvisor are very bright people and you don’t hear about them in the community.” And while Jared you’re getting out there a bit more of late, I kind of feel like you may fit that mold. Lots of the companeros may not know you unless they are kind of in the Raleigh or North Carolina area but hopefully that will change particularly with this interview.

Jared: Yeah, I’m trying to fit that mold. Yes.

Steve: Yeah, and I think the podcast is definitely changing that for some of the ChannelAdvisor DBAs that have been on.

Carlos: That’s right.

Steve: I think ChannelAdvisor has the record now for the company that has had the most guest.

Carlos: Unless we’re going to count Microsoft. Microsoft may technically still be ahead with all the PM they’ve had on.

Steve: Oh sure, yeah.

Carlos: Other than Microsoft… those two different layers are way ahead of everybody else. So ultimately one of the conversations we had, again kind of going back to that Raleigh conversation, and we were talking about performance and collecting information about the database. I can’t remember exactly what your comment was but you mentioned PSSDIAG. And I think my comment was, “Ugh, does anybody still use that?” And you said, “Yes, it’s great.” And I thought, “Oh, we’ve got to have you on the program to talk a little bit about it.” And so for those who haven’t use that, I guess let’s do a little groundwork here. Let’s just talk about PSSDIAG, what it is, and maybe even a little bit of history of it.

Jared: Ok, so PSSDIAG is this fairly own composing tool that Microsoft has developed and makes publicly available. It’s up on, I can’t think about the site is currently, but it’s publicly available for download. And this own composing tool that is used primarily for SQL Server performance issues. There are a few other odd circumstances you might want to run this but mainly you use it for, and Microsoft encourages to use it to gather data about performance issues they are having with SQL Server. And it runs a performance monitor output in the background. It runs a profile or trace on the latest version an xEvents trace if you want. It runs a bunch of queries to get information in DMVs. It will produce like 50 or 80 files of output in the folder that produces and it can produce quite a large volume of data. And the idea is you run this thing, you might run it for half an hour or whatever or if you had a different window when the problem occurs. And you know the problem might happen sometime in the next hour or so, you want to run it and capture data while whatever problem is going on. It’s a really good tool in that it captures data from a lot of different sources and you tend not to miss much with PSSDIAG. There are a few odd things occasionally that you might want to add on to say the normal configuration but it’s a really own composing tool and it puts a lot of data at your disposal.

Carlos: Right. Now, you are a former Microsoft employee, right?

Jared: I am. I was working at the CSS site in Charlotte for about 10 years. And a little bit of a contractor as well, a year and a half.

Carlos: I have heard, I guess maybe you can clarify for us. So traditionally you’re going to be exposed to PSSDIAG for the first time, at least I was. If you’re company has Microsoft support you call them up, you know, you’re looking at a performance issue. This is the go to tool, right, for them?

Jared: Yes, it is absolutely the go to tool for Microsoft.

Carlos: One of the things that I had heard was that if you go to their support site and what’s publicly available is slightly different, true or false?

Jared: They have an internal version of the tool, yes.

Carlos: Ok, but from the nuts and bolts perspective ultimately the same?

Jared: Ultimately the same. There might be some slight differences in some of the specifics of what options you have available. GitHub was what I was thinking of earlier. The current publicly available version is available on GitHub, and in the past there were some slight differences in kind of the custom configuration options you had in the internal tool and the publicly facing tool but they are 98% the same.

Carlos: Got you. Ok.

Steve: So then, I mean if you’re doing a support ticket with Microsoft they are going to ask you to run this. But if you are a DBA out there in a small shop and you’re having some performance issues, is this something that’s going to be easy to use and just that they could run and dig through the results and get some value out of it or is it more just for Microsoft to use?

Jared: It is something that you can use. As far as somebody who is in a smaller shop, I would actually have less concern about somebody in a smaller shop using it than somebody in a bigger shop with very big, very active, very busy servers. They don’t know what’s configured. The question that is being asked many times, “Will PSSDIAG affect my performance?” And the answer is possibly, and it depends on how you configure it and how busy your servers are. So in a smaller shop I’d be less worried about it. When I started using PSSDIAG in 2004 I think, I wasn’t very versed in performance troubleshooting at that time either and so I spend a lot of time looking at the perfmon manually. I’m looking for the profiler manually. There is also basically a sister tool with this which is SQL Nexus which is also available on GitHub. And what SQL Nexus does is basically grind through a lot of the data that PSSDIAG provides. Does some analytics on it, you know, figures out what’s the biggest resource consuming queries are. Your big wait types and puts it into a nice GUI set that you can see that stuff and consume it much more easily. You can select through it manually but SQL Nexus does make a good job of making that easier to understand.

Carlos: And worth noting in the beginning, I can remember being in that same state as far as just kind of getting my feet wet so to speak from all the tools that are available and taking a peek at that. One of the things that is a bit I’ll used the word overwhelming, or can be overwhelming of PSSDIAG is because it’s collecting all that data. It’s almost like where do you start.

Jared: It is difficult to know where to start.

Carlos: Yeah, and you kind of have to. I think if you have a good understanding of what all of those pieces are. It makes a little bit easier but starting there like your first troubleshooting starting place. Yeah, it’s going to take some time to get through, so be patient.

Jared: It can be intimidating at first. I do think that SQL Nexus makes a lot of that easier by kind of figuring out what’s important for you in doing a lot of the analysis by itself.

Carlos: Well now, let’s talk about some of the improvements. Again, so my experience with PSSDIAG is probably, gosh. You know, 7-8 years ago at least now. I remember SQL Nexus being a bit, I hate this word, clunky. But I felt like it was beyond maybe what I could do at that time. I felt like I didn’t have the experience to get it all set up. I never quite seem to fit that right. Is that getting better? Is that easier to use now?

Jared: For me it has gotten a lot better over the years. The last couple of releases have done more, there is more things exposed such as they added in something to get out the details of say sp_configure which is something that PSSDIAG has gathered for a long time but it will flag things in that that are unusual and things you might want to reconsider. I think that the GUI interface is better than it was. I think there is a lot to positive say for that tool, so I feel really good about SQL Nexus. And I kind of feel like I was doing myself a disservice because when it came out at first I was just kind of like, “Ahh, I don’t need that thing.” Because at that point I’ve been using PSSDIAG for a couple of years and I knew what to go and get and what to look for although it does in the long run it did saved me a lot of time using Nexus.

Carlos: I see, interesting.

Steve: How often do you end up using PSSDIAG in your job?
Jared: Currently I do not use it very often. I mean currently if I’m looking at a performance issue, and this is something that I started doing a lot when I was still working at Microsoft. A lot of times I’ll just use DMV queries and figure out what I can from that about an ongoing situation, and I feel like that gives me information very very quickly I can use to diagnose problems.

Steve: Ok, great.

Carlos: Now, again going back to our conversation. One of the things you got to mention was one of the things you thought PSSDIAG was really really good at. So we’ve talked about kind of collecting the metrics and whatnot, so what are some of the compelling reasons of why you use PSSDIAG? Other than just collecting a whole bunch of metrics, like you everything that you might need.

Jared: Well, it is all encompassing and doesn’t miss a lot so that’s a positive. The perfmon collector gets you everything you’re going to need in the vast majority of cases. The fact that it gets the information from the windows event viewer can really be helpful on occasion too especially if you’ve got a situation that you have disk issues. You might have errors that will come up and say the system log. That’s not something you’d necessarily think of unless you had a tool that’s helping to expose that information for you. One of the things that I got to really be fond of. In the latest version they have improved the ability get xEvent traces, so that’s something that’s been in the last couple of releases. But the last one that I saw before the current release, it was till kind of a stub, like there was a tab for configuring profiler and you really want to get away from profiler. I wouldn’t even think about running PSSDIAG with profiler on the servers on ChannelAdvisor in production. There’s no way.

Carlos: Interesting. I guess I want to come back to that, right.

Jared: Well, that’s a matter of overhead. I mean using xEvent traces and I’m more familiar with looking at profiler traces but I’m getting pretty familiar with xEvent traces. And the xEvent has a lot less overhead and the overhead of profiler can affect the performance of our system. That’s the thing in the past. And the busier your server is, the more likely that is to be a problem. So the fact that they’ve improve it because the xEvent thing used to just be a stub. And actually I remember one of the releases a couple of years ago there was a tab for configuring an xEvent trace and if you try to use it it would say, “Wait, this isn’t actually working yet.” So now it’s fully functional, now it’s fully complementary or equivalent to what you could get out of profiler so that’s good. One of the things I really really like out of it is in the output file there’s, it names a lot of things based on the name and the system and then the version of SQL Server, so the file is really long. There’s one file that is the perf_stats_startup.out, and what the script does it has like three different sets of DMV queries that runs. And it does one every minute that will do things like getting information from DMOS wait stats and it has another one that run maybe every 30 seconds that will get information about memory consumption. But the main loop, the thing that it runs like every 5-10 seconds runs queries against dm_exec_requests to tell you what all the active queries are especially the ones that are waiting or causing waits in the system. It does a second query, that for all the things that it got with the first query. The second query will return the statement that’s being run and the procedure it’s a part of which is very helpful for narrowing down what you want to look at and finding the section of code you actually care about. And the third query that tells you what the head blocker is if any blocking chains you might have. One of the things I would do at times to diagnos the situation very quickly is I would just open up that file, look at the information we’re getting from dm_exec_requests about active queries. I would have that open in Notepad++ or Textpad and I would just scan through that very quickly. Because it will run these queries like, I don’t know it it’s every 5 or 10 seconds. But each one you’re just getting one snapshot of what you’re running queries and what your waits look like. But if you see one snapshot, and another and another and you can thong through them all really quickly, it’s easy to come up with an overall impression of what’s going on. And to say, “Oh well, yeah I’ve got some I/O waits here and there but that’s not a big of a deal. But I’ve got cxpacket waits lined up for days. I need to figure out what’s going on with that.”

Carlos: That’s interesting as you mentioned that and I agree that that idea of the snapshot is very important. One of the things that I actually will have done at the PASS Summit is talking about baselines. So how do you, I guess thoughts around leveraging a tool like this which is kind of a snapshot but in a sense to give you, you want a broader than just what’s my current CPU, right? You want a little bit more history than that but it’s not something that you’re going to be running for weeks at a time either.

Jared: Yes. I would really consider using Nexus with that because of the fact that you can gather PSSDIAG whatever time you want to. If you want to gather an hour or two worth of data at whatever time of the day you feel will be much appropriate, go ahead and do that. But then use Nexus with that and you’ve got a very visible, you’ve taken that data set and made it very visible and very easy to look at and to refer back to it later because it’s like you’ve got all the perfmon data is in there, and average out. And you can say, “Ok, for these two hours this is my CPU consumption. This is what disks look like. This is how much free memory I had. Here’s what my main queries were, here’s what my mian wait types were, here’s what my resource consumption per procedure look like and you can have that kind of information for multiple sources and have it easily accessible through SQL Nexus.

Carlos: Ok, so you mentioned you kind of switch off of it, so when do you feel like it’s the hand off point? It seems like it’s a very handy tool particularly when you’re, I don’t want to say going in blind, but again if you think about the origin, right? So I am a support person, somebody calls me up, I don’t know who they are, I’ve never seen the system before, I want to get as much information as possible. Where do you see the hand off or the evolution perhaps of I need to get information about the system even if whether I’m new or whatever. I’ve just been tasked to this database to using PSSDIAG to, “Ok, now I know something about it. Maybe I don’t need to use all the pieces. I am more comfortable with the DMVs or something like that.”

Jared: Well, I think the more that you know the environment that you’re dealing with; the easier it is to transition to using a smaller data set. I think part of the reason PSSDIAG is as usual it is for say a Microsoft engineer is they don’t know what you environment looks like, and they don’t necessary know what they’re looking for. They don’t necessarily know what say unusual sp_configure settings you had. There is a lot of things that could potentially be the problem and there are more things that they might need you to consider. Now, in my case, part of the reason I made the transition, started doing more of my troubleshooting with DMVs at least were possible and to me there are still circumstances you just can’t replace PSSDIAG because of some of the things that it does. But part of the reason I made the transition was just for efficiency. So let me give you a hypothetical. Let’s say that you’re the customer and I’m working as Microsoft. We gather half an hour of data off of your very busy production server. You end up with say, three or four gigabytes worth of data in your output folder. You start zipping that up, you’re going to have to upload that to Microsoft. There’s a tool within Microsoft that when you upload that it will go ahead and unzip it and run it through the SQL Nexus output and I’ll eventually as the support engineer would get an email with basically the Nexus stuff already run. And the Nexus analysis that could take some time, a large data set, that can take a couple of hours. So I was actually on a critsit, if you’re familiar with the term. I was on a critsit with somebody in one case and they had a high CPU issue. He had been troubleshoot it himself and actually the problem went away before he contacted Microsoft and I was still working with Microsoft at that time. But the time I get on the phone with him the situation has been over for two hours. Now, PSSDIAG, I could configure PSSDIAG and send it to him and say, “Ok, if your problem happens again start running this and give me a call.” But I kind of wanted to see if I can do something more than that. I was thinking and I said, “So how did the problem go away? What happened?” And he told me, “Well, it stopped on its own. I was trying to figure out what was going on and it just stopped. I didn’t do anything.” So I asked the guy, “Ok, did you restart SQL or did you say flush the procedure cache?” Because that’s something a lot of people will do and it was kind of frustrating when you’re a Microsoft engineer. “Is the problem still going on?” “Oh no, I rebooted the server.” “Oh well, I guess I can’t gather any actual data.” But it hadn’t restarted, it hadn’t flush the procedure cache and so I thought to myself, “Well, whatever plans were consuming all the resources, consuming all the CPU, they should still be cached.” Let’s go run a query against dm_exec_query_stats that I had and I ran that and we looked at the output. And he had about 5-6 queries that were consuming significantly more CPU than anything else. Like you look at them in descending order and after about query 5 the CPU dropped by three digits. That’s actually unusual very often when I see a high CPU case and I’m looking on the DMVs. You’ll see that there is one or two things that’s really killing it. But in this case, I used the DMVs, I’m able to see the cache plans. We can look at the cache plans. We can go find the procedure that is related to it. We look at the table, we look at the indexes. I was able to get to everything I needed just from running a query basically against dm_exec_query_stats. And I didn’t have to have him gather data and upload it to me and I spent hours waiting for the data and then analyzing the data and then get back to him. I had an idea very quickly of what was going on. And after that one, that made a really compelling argument to me about the efficiency of using the DMVs.

Steve: Ok, so then just sort of comparing that efficiency and then getting all the information there. I mean, if you’ve got a new server that you are now responsible for you’re going to take over maintenance on. Would you say that, I mean, PSSDIAG would be a great place to start to get that sort of baseline and so that you know what’s going on with it and then later deal with the DMVs or you just sort of skipping it sometimes and go directly to the DMVs.

Jared: I think you could do either approach? Again using PSSDIAG and the Nexus will give you very visible data. I think the way it presents things might be easier for some people to see and understand and realize what normal and how this is different from that. But with the DMVs I think one thing that would be effective would be to have ongoing normal processes where you collect information from say dm_exec_query_stats or dm_exec_request and put that into a permanent table that you’re willing to keep for x amount of days. We some of this at ChannelAdvisor to keep track of say dm_exec_request information so that we can see waits that are going on inside the system and we can look back at a given period of time and see what kind of waits we normally see on a Wednesday at 2 o’clock in the afternoon. We can see that. You could do either approach. Like I said I like Nexus for the fact that it has a decent GUI on it. But you could also just take the DMVs have automated things to gather that sort of information. It depends on how long you want to retain that information. You have to be a little careful about trimming your tables if you’re taking that raw DMV information and storing it somewhere as opposed to say running the PSSDIAG and running the Nexus. Now you have the nexus output, you can actually get rid of the PSSDIAG data, however any gigabytes that is. You can also, Nexus takes the data and puts it into a database and it actually needs a database within SQL server that can connect to and juggle the numbers around. But you can backup that database and then at whatever point you can move it to another server. You can point SQL Nexus at it and it’s very effective in that fashion. Ok so for baselining to me you could use either one. It just depends on your preferences.

Carlos: So we talked about wanted to hit some of the new features and I think you’ve mentioned a couple of them, obviously Nexus being one. So as far as like, I’m sure even the documentation has improved a bit so you mentioned some of the parameters or settings you could have. So if I just run PSSDIAG with no parameters I’m going to get the event log, I’m going to get the SQL Server log, I’m going to get the profiler trace. I am assuming it’s still the default. You mentioned I could get xEvents, now I’m assuming parameter change and then I’m going to get the performance monitor metrics. So what other common parameters am I using when I am talking about PSSDIAG?

Jared: Well, the thing currently is and this is where people go wrong with it or can go wrong with it is now there is basically default packages or default scenarios or scenarios that you can just basically say I want to gather general performance or I want to gather detailed performance. And one of the things that I would suggest people not to do with PSSDIAG especially on the production environment would be to go in and start by telling it to do a detailed performance output before you’re familiar with the tool and have an idea of how much data it’s going to capture in your environment. I would go with a general or light option. The big difference between a general or a light capture and doing a detailed capture is that when you do a light capture you will gather the events for whether you’re on profiler or xEvents, you will get RPC started and completed and you will get SQL Batch started and completed. And you will get errors and you will get a bunch of other things as well but the main things will be interested is batches and stored procedures started and completed. When you go to detailed, you’re going to gather a lot more events because you’re going to gather statement level events. You’re going to gather every statement starting and completed within SQL Server and you’re going to gather execution plans of whatever type you’ve selected or whatever type is the default for the detailed package currently. And think about it, if you got a store procedure and that store procedure has 50 statements in it then by going to a detailed trace you’re going to gather, instead of gathering two events for that stored procedure – starting and stopping, you’re going to gather those two plus 50 for each statement starting, 50 more for each statement stopping and for each non-trivial statement that you’re going to capture the execution plan. So there is a big difference in terms of how much data that you’re going to be gathering and thus it’s going to be more likely to affect the performance of the system in some way, and it can. And if you’re SQL Server is pushing 2,000 transactions per second that’s probably not a problem. If it’s pushing 25,000 transactions per second the same package might bring that server to its knees. And especially if I’m not familiar with running PSSDIAG in my environment I would start off by doing a general or a doing a light and seeing how that works before I try to crank it up.

Steve: So I guess from that perspective it also makes sense if someone is just learning it if they have access to a test server that might have far less load to just give it a test there first to make sure you understand what do light versus the more detailed is going to do.

Jared: Absolutely. And there are some interesting circumstances like there are things in there that are made for gathering information about always on or gathering information specifically about memory issues or things like that. I think there is used to be one for, like there is still a collector for service broker and there are circumstances you might want to gather those things because it provides a lot of information. There is one for link servers that will run all the queries to get information about what link servers you have set up. So there are a number of useful little things like that. But my biggest concern with PSSDIAG is people being too aggressive with the data they are trying to return from it because it can affect performance. I had cases when I was working at Microsoft that I would go in with the PSSDIAG package and we’d run it and we gather data and I analyze the data and realized, “You know what I can’t use this because all I can see is the SQL trace waits.” I can’t tell what else is causing problems on the system because the tool is gathering too much information that were waiting for that information to be written out. And I can’t see any other bottlenecks because of this bottleneck.

Carlos: Ok, so I guess then at this point for someone who is about to go and give it a shot maybe after listening to the podcast. I mean, besides keeping the sampling light there. Any other tips or suggestions to help someone get started?

Jared: One or two that’s big. Another thing that affects performance is running this over the network as oppose to running it locally on the server. Running it over the network is a really bad idea. I would dissuade you from doing this if it all possible. The idea is that SQL has these delays when it’s trying to write the information out. Now, PSSDIAG does server side trace but if you’re going to be using profiler or using some other tool to do your tracing, I would really suggest not doing it remotely. You can run PSSDIAG remotely and tell it to connect to this server and this name but it introduces a much longer latency in terms of how long it takes for the trace to write out that data because now you’re… And that is affecting how the SQL Server engine operates now, so that’s a whole different magnitude. The other thing that I’ve seen that causes problems and it’s not specifically with PSSDIAG is not to run a whole lot of traces at one time whether you’re using xEvents or profiler. There used to be commercial tools. I won’t name any, and I probably couldn’t remember them all of them. But that would run four or five or more profiler traces at a time and that would affect the performance of the system because SQL Server is trying to write out things and keep track of things for each one of those different trace files. Especially when you’re doing multiple and you’re doing it over the network, that can really be consequential.

Steve: Yup, interesting. Well, ok so a side note put on that running profiler traces. I mean, what would your take be if someone wanted to run a profiler trace like 24/7/365, all day, all year just to keep track of every query that’s ever being run? How big of an impact something like that can have on performance?

Jared: Again it would depend on how busy the server is. On a busy production environment I would ask them to find exactly what it is they are trying to find out here because I don’t think that’s what they are trying to find out. I think that’s a lot more information than you could reasonably use. How would you aggregate that information? What are planning to do with it? And in any case I would stay away from using profiler at this point in any case because xEvents is now a super set. It has been since SQL 2012, has been a super set of what profiler can do. We have more kinds of events of xEvents now. It provides more information to you and it’s more efficient. It was designed from the ground up to be faster and to have less overhead than profiler. I really encourage you. If you’re more familiar with profiler, I entirely understand. But I would really go ahead and pay that price because I think it’s more than worth it.

Carlos: Well now I’m interested to find out what happens with profiler. I don’t think it’s going away and the reason I say that is that they just announced. Or maybe not just but one of the things we talked about SQL Server in the News is they’ve added query store as a source for profiler.

Steve: Alright, shall we move in to the SQL Family section?

Jared: Sure, go for it.

Carlos: So Jared, how did you first get started with SQL Server?

Jared: I got started when I was a part-time community college instructor. I had been teaching for one semester and my older sister actually work at one of the colleges I was working at and she asked me if I knew anything about databases and my answer was no. At that point the college and this was Forsyth Tech in Winston, Salem. They did some certification classes for SQL Server and one of them has actually in one of their 2-year degree. And they needed somebody to teach this classes for the next semester, so she came to me and asked if I could do that and I said, “Ok, I’ll look into it.” And I basically picked up a book and taught myself enough of SQL Server to get certified in it and then I taught the classes there for about three years. And from there at that point, the interesting thing about teaching is whenever you’re trying to teach people something you have to know it to a greater degree than your teaching. And also they’ll ask you questions about the subject that you’ll never think to ask yourself. So it’s like you as a teacher end up learning even more from having students because you’ve already figured out all the questions you had in your head but now you’ll get a whole bunch more questions and you have to figure out how to answer them too. So I taught that for about three years and that was when I applied for this helpdesk e-job that I saw on Monster which actually turned out to be a contract position to go work at Microsoft at Charlotte.

Carlos: Interesting. So it’s very similar almost to like getting started with presenting in a sense, right?

Jared: Yeah.

Steve: So if you could change one thing about SQL Server, what would it be and why?

Jared: That’s actually pretty difficult. Trying to think of, you know, I’ve had pain points here and there over the time. I’ve seen people do some horrible things with service broker. I’m trying to think, what else? At the moment I guess the biggest thing I would come up with is page latch waits because there is such a big consideration and a kind of a thorn in the side currently at work so I guess I would try to some find way to eliminate that level of pessimistic concurrency. We’re trying to move to doing a lot of things doing in-memory optimized tables and whatnot to move to more optimistic concurrency because with our throughput, with our load, we need to have that. We need to get rid of the contention we get from page latch waits. That’s a big consideration.

Carlos: Got you.

Steve: Ok, very nice.

Carlos: What’s the best piece of career advice you’ve ever received?

Jared: Difficult to say, I think one of the things I would go back to is when I was still contracting, when I was still starting off at Microsoft. I was speaking with one, my tech lead at that time was Bill Carroll. He is now an Escalation Engineer. He’s been at Microsoft forever. I was working on some performance case and at that point hadn’t a lot of experience working. I had no experience before I came to Microsoft working on performance cases. I was finding them difficult and Bill Carroll said, “We will always have room for somebody who knows how to handle performance cases around here.” And so that I think really probably was the best piece of career advice because at that point it gave me a niche. It gave me something to figure out and try to focus on and I’ve done a lot with that so I’ll give Bill Carroll the nod there.

Carlos: There you go.

Steve: Alright, and our final question. If you could have one superhero power what would it be and why would you want it?

Jared: That’s funny to me in part because I’m an avid video gamer and my wife and I used to play City of Heroes so we have played superheroes many times. For selfish reasons I would like to say either flight or teleportation because that would really be cool. But honestly in real life if I could have a super power that would be the power to heal other people just because who I am as a person if I could do something that could make life better for somebody else. If I could take away something horrible that’s happened to them that would be a great thing to do.

Carlos: Very cool. Well, awesome.

Steve: Alright.

Carlos: Well Jared, thanks so much for being with us today. We appreciate the conversation.

Jared: Well, thanks for having me.

Steve: Yeah, that was great to be able to chat with you, Jared.

Jared: Same here.
[/et_pb_toggle][/et_pb_column][/et_pb_row][/et_pb_section]