August 19, 2015 at 11:19 pm
[font="Verdana"]
DMVs offer us performance counters; CPU/IO cost etc. If these are affected by Parallelism then what max till date (updated versions as well) we are sound enough to actually collect the ACTUAL expensive queries. Any strategy/Suggestion?
[/font]
August 20, 2015 at 2:48 am
Sorry, I don't understand your question
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
August 20, 2015 at 3:31 am
GilaMonster (8/20/2015)
Sorry, I don't understand your question
My apologies,
the queries which run on multiple processor cores (multi-threaded); if DMVs log their information correctly then fine, otherwise do we have any mechanism/queries which can actually log accurate results of their costs (CPU/IO etc)?
Do all DMVs shows information correctly either the query is multi-threaded or single thread?
August 20, 2015 at 3:34 am
AFAIK, the DMVs show correct data.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
August 20, 2015 at 3:58 am
Ok.
Please if i have confused due to this old post?
http://blog.calvett.co.uk/2011/05/05/parallelism-cpu-time-amp-dmv-s/
?
August 20, 2015 at 4:10 am
But for getting the expensive queries you won't be using sys.dm_exec_requests (that shows currently running queries), so CPU not being displayed correctly in that one doesn't matter for your problem.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply