Esto puede caer en la categoría de opinión, pero tengo curiosidad por saber si las personas están usando el indicador de seguimiento 4199 como parámetro de inicio para SQL Server. Para aquellos que lo han usado, ¿bajo qué circunstancias experimentó regresión de consultas?
Ciertamente parece un beneficio potencial de rendimiento en todos los ámbitos, estoy considerando habilitarlo globalmente en nuestro entorno de no producción y dejarlo reposar durante un par de meses para descubrir cualquier problema.
¿Las correcciones en 4199 se incorporaron al optimizador de forma predeterminada en 2014 (o 2016)? Aunque entiendo el caso de no introducir cambios inesperados en el plan, parece extraño mantener todas estas correcciones ocultas entre versiones.
Estamos usando 2008, 2008R2 y principalmente 2012.
fuente
Respuestas:
Personalmente, cada vez que construyo un nuevo servidor para un nuevo proyecto, siempre habilito TF4199 a nivel mundial. Lo mismo se aplica cuando actualizo instancias existentes a versiones más nuevas.
El TF permite nuevas correcciones que afectarían el comportamiento de la aplicación, pero para nuevos proyectos el riesgo de regresión no es un problema. Para las instancias actualizadas de versiones anteriores, las diferencias entre la versión antigua y la nueva son una preocupación por sí mismas y, de todos modos, se espera tener que lidiar con la regresión del plan, por lo que prefiero pelear con TF4199 habilitado.
En lo que respecta a las bases de datos existentes, solo hay una forma de saberlo: probarlo. Puede capturar una carga de trabajo en la configuración existente y reproducirla después de habilitar el indicador. RML Utilities puede ayudarlo a automatizar el proceso, como se describe en esta respuesta .
Obviamente, la bandera afecta a toda la instancia, por lo que tendrá que probar todas las bases de datos que se encuentran allí.
fuente
Mi búsqueda sobre el tema me trajo aquí, así que me gustaría compartir mi experiencia reciente sobre el tema.
Estaba ejecutando SQL 2014, así que pensé que estaría a salvo de tener que preocuparme por 4199 por un tiempo ... pero simplemente no era cierto ...
Cómo diagnosticar si necesita 4199
Si su consulta parece funcionar mal , particularmente cuando cree que no debería hacerlo, intente agregar lo siguiente al final para ver si soluciona todos sus problemas, ya que podría necesitar 4199 ("Habilitar todas las correcciones del Optimizador de consultas". )
En mi situación, tuve una cláusula de los 10 principales que explotó una consulta que funcionó bien sin ella, que es lo que me hizo pensar que algo sospechoso estaba sucediendo, y que 4199 podría ayudar.
Sobre 4199
Las correcciones de errores / rendimiento del Optimizador de consultas del servidor SQL que se crean después de la nueva versión principal se ocultan y bloquean. Esto es en caso de que en realidad puedan dañar algún otro programa teóricamente perfectamente optimizado. Por lo tanto, instale las actualizaciones como podría, los cambios reales del optimizador de consultas no están habilitados de forma predeterminada. Por lo tanto, una vez que se ha realizado una única corrección o mejora, 4199 se convierte en una necesidad si desea aprovecharla. A medida que aparecen muchas soluciones, eventualmente te encontrarás activando esto cuando una de ellas te afecte. Estas correcciones generalmente están vinculadas a sus propios indicadores de rastreo, pero 4199 se usa como el maestro "Activar cada corrección".
Si sabe qué arreglos necesita, puede habilitarlos por partes en lugar de usar 4199. Si desea habilitar todos los arreglos, use 4199.
Ok, entonces quieres 4199 a nivel mundial ...
Simplemente cree un trabajo del Agente SQL que se ejecute todas las mañanas con la siguiente línea para habilitar el indicador de rastreo de forma global. Esto asegura que si alguien los apagó o etc., que se vuelvan a encender. Este paso de trabajo tiene sql bastante simple:
Donde -1 especifica la parte Global en DBCC TRACEON. Para más información ver:
https://msdn.microsoft.com/en-us/library/ms187329.aspx?f=255&MSPPError=-2147217396
Planes de consulta de "recompilación"
En mi intento más reciente, tuve que habilitar 4199 a nivel mundial y luego también eliminar los planes de consulta en caché existentes :
https://msdn.microsoft.com/en-us/library/ms181647.aspx?f=255&MSPPError=-2147217396
Donde el procedimiento almacenado de recompilación encuentra planes de consulta relacionados con el objeto de la base de datos (como una tabla) y los elimina, lo que requiere el siguiente intento de ejecutar una consulta similar para compilarlos.
Entonces, en mi caso, 4199 evitó que se crearan los planes de consulta erróneos, pero también tuve que eliminar aquellos que todavía estaban en caché a través de sp_recompile. Elija cualquier tabla de la consulta conocida afectada y debería ser bueno intentar esa consulta nuevamente, suponiendo que ahora haya habilitado 4199 globalmente y borrado el plan de consulta en caché ofensivo.
En conclusión sobre 4199
A medida que utiliza índices, una optimización inteligente del plan de consultas se vuelve importante para usar esos índices de manera inteligente, y suponiendo que con el tiempo se lanzará alguna solución al proceso de optimización de consultas, generalmente estará en condiciones de seguridad para ejecutar con 4199 habilitado globalmente, siempre y cuando se dé cuenta de que alguna nueva solución podría no funcionar tan bien con una base de datos altamente optimizada que estaba tan optimizada en el entorno anterior a dicha solución. ¿Pero qué hace 4199? Simplemente habilita todas las correcciones.
fuente
Quería compartir mi experiencia con trace flag 4199.
Acabo de terminar de diagnosticar un problema de rendimiento en un sistema de cliente que ejecuta SQL Server 2012 SP3. El cliente movía una base de datos de informes de su servidor OLTP de producción a un nuevo servidor. El objetivo del cliente era eliminar la competencia por los recursos con las consultas OLTP. Desafortunadamente, el cliente dijo que el nuevo servidor de informes era muy lento.
Una consulta de muestra ejecutada en el sistema OLTP se completó en 1.6 segundos. El plan de consulta realizó una búsqueda de índice en una tabla de ~ 200 millones de filas que formaba parte de una vista.
En el nuevo servidor, la misma consulta se completó en 10 minutos y 44 segundos. Realizó una exploración de índice en la misma tabla de ~ 200 millones de filas.
Los datos del servidor de informes eran una copia de los datos OLTP, por lo que no parecía haber una diferencia en los datos.
Me quedé perplejo hasta que recordé que nuestro software (que ejecuta su sistema OLTP) habilitó algunas marcas de seguimiento en el inicio. Uno de ellos, 4199, recordé, fue una corrección del optimizador de consultas.
Probé habilitar la marca de seguimiento 4199 en el nuevo servidor de informes del cliente, y la consulta de informes se completó en 0.6 segundos. (¡Guau!) Deshabilité el indicador de seguimiento, y la consulta volvió a completarse en 10 minutos y 44 segundos. Habilitado el indicador: volver a 0.6 segundos. Aparentemente, habilitar la marca de seguimiento permitió al optimizador usar una búsqueda de índice en la vista de la tabla de 200 millones de filas.
En este caso, las optimizaciones de consulta habilitadas por el indicador de traza 4199 hicieron una enorme diferencia. Tus experiencias pueden variar. Sin embargo, en base a esta experiencia, definitivamente parece que vale la pena permitirme.
fuente