Regarding the comments in sql from ORM, I know the Entity Framework added the Tag() option that will allow you to output those to aid in debugging. Has some limitations but it's out there.
I`ve had one occurrence where I had to manually create statistics for a table, because SQL was doing crazy table scans and the server CPU hit more than 99% and everything on the server was freezing/lagging. The app servers were constantly firing table scans on that SQL, even though we stopped some of them to reduce the stress, it still was a nightmare.. Don`t ask me how I managed to triage a system with blown up CPU cores, because there was 5second lag/timeouts on each action on the server... and the server didn`t crash funnily enough :) The stats update resolved the query plans against that DB table and CPU usage was back to normal (no more scans). Weird thing is that - I think Stats update was running each day (or week) , so I bet the App or Devs did a lot of data changes in PROD (that actually triggered a cardinality change of the plans) DB size was >500GB , the table in question had >15 million rows. P.S Brent, you`re the best! :)
Thank you, Brent, for the great answers.
My pleasure, sir!
Always love to learn something new! Thank you for the brain charge!
My pleasure, ma'am!
Regarding the comments in sql from ORM, I know the Entity Framework added the Tag() option that will allow you to output those to aid in debugging. Has some limitations but it's out there.
I`ve had one occurrence where I had to manually create statistics for a table, because SQL was doing crazy table scans and the server CPU hit more than 99% and everything on the server was freezing/lagging. The app servers were constantly firing table scans on that SQL, even though we stopped some of them to reduce the stress, it still was a nightmare..
Don`t ask me how I managed to triage a system with blown up CPU cores, because there was 5second lag/timeouts on each action on the server... and the server didn`t crash funnily enough :)
The stats update resolved the query plans against that DB table and CPU usage was back to normal (no more scans).
Weird thing is that - I think Stats update was running each day (or week) , so I bet the App or Devs did a lot of data changes in PROD (that actually triggered a cardinality change of the plans)
DB size was >500GB , the table in question had >15 million rows.
P.S Brent, you`re the best! :)
That's most likely not a statistics issue - it's parameter sniffing. Check out my parameter sniffing class when you get time.
Send a link to the BringATrailer auction!
bringatrailer.com/listing/2013-jaguar-xkr-s-coupe/
Did you get your nails trimmed?
Yep!