Más de un año después, quiero que todos sepan mi experiencia y el resultado final de esta pregunta / tema.
Empecé creando cosas por mi cuenta. Inicialmente seguí el artículo Recopilar y almacenar datos históricos del contador de rendimiento de SQL Server con CMV de Tim Ford para obtener algo y lo extendí con los datos que deseaba recopilar. Entonces, una vez al día, ejecuto varios procedimientos almacenados en cada servidor SQL que recopilan información específica de los DMV y almacenan los resultados en el servidor local dentro de una base de datos. Esto incluye el uso del índice, índices faltantes, entradas de registro específicas como crecimiento automático, configuración del servidor, configuración de la base de datos de la aplicación, fragmentación, ejecución del trabajo, información del registro de transacciones, información del archivo, estadísticas de espera y más.
Además, agregué los resultados de ejecución regular sp_blitz de Brent Ozar a este repositorio para recopilar indicaciones valiosas adicionales para trabajar, mejorar e informar.
Posteriormente, se recopilan todos los datos en un Servidor SQL de monitoreo dedicado y de esta manera creo una tienda agrupada para obtener información relevante sobre el rendimiento de todos mis servidores y la uso como base para la investigación y los informes.
Luego creé hojas de Excel y también informes utilizando servicios de informes para analizar e interpretar. Algunas muestras:
También configuré algunos contadores de rendimiento con TYPEPERF, inspirado en el artículo " Recopilación de datos de rendimiento en una tabla de SQL Server " de Fedor Georgiev.
Desde mi instancia de Monitoreo SQL, desencadené typeperf para ejecutar y recolectar un número configurable de muestras con un intervalo de muestra configurable y almacenar los resultados en mi base de datos de monitoreo central.
Esto me permite observar valores de rendimiento a largo plazo, muestra:
Después de un tiempo de usar esto para recopilar información de línea de base, se dio cuenta de que es una gran cantidad de trabajo de mantenimiento que debe gastarse en buscar trabajos fallidos, procedimientos de eliminación de errores (por ejemplo, en caso de que una base de datos se desconectara, algunos scripts fallidos), manteniendo la configuración después de reemplazar un servidor ...
Además, la base de datos que recopila todos los registros necesita mantenimiento y ajuste de rendimiento, por lo que surge un trabajo adicional para mantener los datos útiles ...
Lo que finalmente falta por completo es la capacidad de ver las cosas que suceden en vivo. En Best Case, podré decir lo que posiblemente estaba sucediendo al día siguiente después de que los recopiladores de datos hayan corrido. También faltan todos los detalles. No tengo acceso a gráficos de punto muerto, no puedo ver los planes de consulta de consultas que se estaban ejecutando en un marco de tiempo sospechoso ...
Todo eso me obligó a cobrarle a la administración para gastar dinero en una solución profesional que no puedo crear por mi cuenta.
La elección final fue comprar SentryOne porque, en comparación con otros, es convincente y ofrece mucha información necesaria para identificar nuestros puntos débiles.
Como conclusión final, recomendaría a cualquiera que busque respuestas a preguntas similares que no intente crear cosas por su cuenta, siempre y cuando no tenga un entorno pequeño y básicamente saludable. Si tiene un par de sistemas y muchos problemas, es mejor buscar inmediatamente una solución profesional y usar la asistencia del proveedor en sus problemas en lugar de gastar mucho tiempo y dinero para crear algo menos útil. Sin embargo, esta ruta seguía siendo muy interesante y me hizo aprender mucho que no quiero perderme.
Espero que encuentres esto útil una vez que te encuentres con este hilo de preguntas.
EDITAR 20 de abril de 2017:
Brent Ozar publicó recientemente el siguiente artículo en Facebook que es una especie de enfoque similar adoptado por el equipo SQL Tiger: https://blogs.msdn.microsoft.com/sql_server_team/sql-server-performance-baselining -reports-desatado-para-Enterprise-Monitoring /