February 18, 2019 at 12:16 am
Okay so this should be pretty much everywhere and in every business that you come across a situation wherein the application users reach out to the DBA(Default Blame Acceptor) that there is slowness observed on the DB server. My point is since we are not sure what is slow where should our troubleshooting efforts be focused i.e what should be our starting point or for that what questions can we ask the app users in order to get more detail to focus on the cause rather than just running wild to somehow get to the root cause. I know each one of you'll might have dealt with this one way or another but would like to know what would be the starting point and how do we troubleshoot this in order to fix the issue.
February 18, 2019 at 2:25 am
Feivel - Monday, February 18, 2019 12:16 AMOkay so this should be pretty much everywhere and in every business that you come across a situation wherein the application users reach out to the DBA(Default Blame Acceptor) that there is slowness observed on the DB server. My point is since we are not sure what is slow where should our troubleshooting efforts be focused i.e what should be our starting point or for that what questions can we ask the app users in order to get more detail to focus on the cause rather than just running wild to somehow get to the root cause. I know each one of you'll might have dealt with this one way or another but would like to know what would be the starting point and how do we troubleshoot this in order to fix the issue.
You have to capture everything running on the server by using - extend events or server side trace or whoisactive etc. Once you have some code you can compare and correlate it.
Muthukkumaran Kaliyamoorthy
https://www.sqlserverblogforum.com/
February 18, 2019 at 2:26 am
muthukkumaran Kaliyamoorthy - Monday, February 18, 2019 2:25 AMFeivel - Monday, February 18, 2019 12:16 AMOkay so this should be pretty much everywhere and in every business that you come across a situation wherein the application users reach out to the DBA(Default Blame Acceptor) that there is slowness observed on the DB server. My point is since we are not sure what is slow where should our troubleshooting efforts be focused i.e what should be our starting point or for that what questions can we ask the app users in order to get more detail to focus on the cause rather than just running wild to somehow get to the root cause. I know each one of you'll might have dealt with this one way or another but would like to know what would be the starting point and how do we troubleshoot this in order to fix the issue.You have to capture everything running on the server by using - extend events or server side trace or whoisactive etc. Once you have some code you can compare and correlate it.
+ brent ozar blitz.
Muthukkumaran Kaliyamoorthy
https://www.sqlserverblogforum.com/
February 18, 2019 at 4:01 am
I generally gather two sets of metrics. I like to get the wait statistics because they tell me where the overall bottlenecks are. I also like to get query performance metrics (the two most lightweight ways to get this done, Query Store or Extended Events, Query Store has fewer details, but lots of aggregations, Extended Events has all the details, but you have to work with the data yourself). Assuming a properly configured server (which can be a big assumption), most of the time the problems are in the queries. With the query metrics and the wait stats, you can look at where your bottlenecks are and which queries are causing them. Then, tune 'em.
Clearly, there's a lot more to this, but that's the gist of it. For all the details, I have a 1,000 page book I wrote on the topic linked in my signature down below.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply