More than one year later I want to let everyone know my experience and the final result of this question / topic. I started out creating things on my own. Initially I followed the Article [Collect and store historical SQL Server performance counter data with CMVs][1] of Tim Ford to get something up and extended this with whatever Data I wanted to collect. So one a day I run several stored procedures on each Sql Server that collect some specific information from DMVs and stores the results on the local Server inside of a database. This includes index usage, missing indexes, specific log entries like autogrow, server settings, application database settings, fragmentation, job execution, transaction log info, file information, wait stats and more. Additionally I added Brent Ozar's sp_blitz regulary execution results to this repository to collect additional valuable indcications to work, improve and report. All data is lateron collected from there into a dedicated monitoring Sql Server and this way I create a bundeled store for performance relevant information about all my servers and use this a a base for investigation and reporting. Then I created excel sheets and also reports using reporting services to analyze and interpret. Some samples: [![enter image description here][2]][2] [![enter image description here][3]][3] [![enter image description here][4]][4] Also I configured some performance counters monitoring using TYPEPERF inspired by the article "[Collecting Performance Data into a SQL Server Table][5]" by Fedor Georgiev. From my SQL Monitoring instance I trigger typeperf to run and collect a configurable number of samples with a configurable sampleinterval and store the results in my central monitoring db. This allows me to observer longterm performance values, sample: [![enter image description here][6]][6] After a while of using this to gather baseline information, it tunred out that it is quite a lot of maintenance work that has to be spent on looking at failed jobs, de-buggin procedures (for example in case a DB was taken offline, some scripts failed), maintaining settings after a server was replaced...). Also the database collectiong all the records tiself needs maintenance and performance tuning, so additional work comes up ti keep the data useful... What is finally completely missing is the ability to look at things that happen live. If, I am able to tell what was possibly going on the next day after the data collectors have ran. Also all the details are missing. I do not have access to deadlock graphs, I can't look at query plans of queries that were running in a suspicious timeframe.... All of that made me going to charge management to spend money for a prefessional solution I am not able to create on my own. The final choice was to buy SentryOne because in comparison to others it is convincing and delivers a lot of information required to identify our pain points. I hope you find this useful once you ran into this question thread. [1]: https://www.mssqltips.com/sqlservertip/2188/collect-and-store-historical-sql-server-performance-counter-data-with-dmvs/ [2]: https://i.sstatic.net/A4pmw.png [3]: https://i.sstatic.net/jOWhH.png [4]: https://i.sstatic.net/Hwike.png [5]: https://www.simple-talk.com/sql/performance/collecting-performance-data-into-a-sql-server-table/ [6]: https://i.sstatic.net/AyiQ5.png