Resetting DMVs

Question

Resetting DMVs

Steve Jones - SSC Editor

SSC Guru

Points: 736162
More actions
March 13, 2013 at 12:13 am

#291044

Comments posted to this topic are about the item Resetting DMVs
March 13, 2013 at 2:20 am

This was removed by the editor as SPAM

Viewing 11 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply

David.Poole SSC Guru Points: 76000 More actions · Answer 1

Well said. Index usage stats are particularly revealing.

I'm in the process of deprecating and consolidating systems and key weapon in the arsenal is being able to proove categorically that the data has not been read in any way other than by system processes.

LinkedIn Profile

Gary Varga SSC Guru Points: 82166 More actions · Answer 2

I agree. Also, default to save and make it configurable as those databases which may require it to be off are exactly the ones with a professional DBA to evaluate the choice.

Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!

Simon D Richards Ten Centuries Points: 1048 More actions · Answer 3

This would work, especially if there is a default retention time for the data, any data beyond that would be cleared out by a garbage collector, and any databases that need extra special trouble shooting can be extended, for analysis.

This would also save all the un-managed systems that exist out there from becoming bloated with months of unused dmv data.

Jeff Moden SSC Guru Points: 1004312 More actions · Answer 4

That got me thinking. Why is this data removed? I'm sure some of the data is stored in memory and automatically reset, but is this the best way to handle this data? Wouldn't it be better to persist this data and allow the DBA to reset values when they were ready?

BWAA-HAA!!! I really have to laugh at this one. Welcome to the nature of "Agile" programming. 😛 If enough people bitch about it, maybe they'll make it so 2 or 3 revs from now. Hmmm... ironically, that would put it out around 2020, the year of "perfect vision". :hehe:

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Stephen_W_Dodd SSCommitted Points: 1628 More actions · Answer 5

Couldn't you accomplish the same thing with extended events?

TravisDBA SSCoach Points: 15780 More actions · Answer 6

Because these DMV's are directly tied into the Performance Dashboards that people use everyday in order to get an updated POINT IN TIME look at their SQL Server and their databases. Secondly, these DMV's just don't have enough cache available for historical performance, that's why. Even if the cache was large enough, as you stated there would probably be performance issues that would result from doing that anyway. However, you can set up a "DMV repository" by just creating specific jobs to warehouse all DMV results in a specific repository at particular intervals that could be stored in msdb or somewhere else like a DBA Utility database for example. Here is a link that will give you a good starting point for doing just that:

http://www.sqlserverpath.org/2012/03/31/better-dba-dashboards-using-dmv-monitors-14/

😀

"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

aleksey2001 SSC Veteran Points: 237 More actions · Answer 7

Microsoft will implement it eventually. Just like Oracle did few years ago. Oracle has a separate AWR repository to store this type of information. Just wait =)

SQLRNNR SSC Guru Points: 281334 More actions · Answer 8

Jeff Moden (3/13/2013)
That got me thinking. Why is this data removed? I'm sure some of the data is stored in memory and automatically reset, but is this the best way to handle this data? Wouldn't it be better to persist this data and allow the DBA to reset values when they were ready?
BWAA-HAA!!! I really have to laugh at this one. Welcome to the nature of "Agile" programming. 😛 If enough people bitch about it, maybe they'll make it so 2 or 3 revs from now. Hmmm... ironically, that would put it out around 2020, the year of "perfect vision". :hehe:

+1

Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events

mattmc Right there with Babe Points: 787 More actions · Answer 9

I agree with the post completely.

On our end, pertaining to Index maintenance, we have a scheduled job which run daily to persist query data from the Index Usage Stats DMV

etc so that we have "The Whole Story" when it comes time to review the history of a particular index.

Having the historical log gives you that confidence when you look at an indexes stats that you can see a more holistic picture and not just up till the

SQL service restart, especially when you are identifying indexes to Remove due to low\Zero usage.

The setup to persist the data is a 5 min job as all we have is a scheduled job which queries the DMV once a Day and logs the data to a log table but of course having the option to do that through the GUI would of course save time and increase agility and perhaps promote doing it for other DMV's more easily.

I speculate that any solution would just be a GUI Control to create and manage Scheduled Jobs (SQL Replication as an example) based on frequency requirements anyways on the Server but at least you dont have don'tdmin them yourself I suppose.

Anyways a really great thread and I would be interested to hear if the suggestion is able to gain any traction for a future service pack as i would most

definatly be using it 😀

Kind Regards,

MattMck