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". )
SELECT SomeColumn
FROM SomeTable
OPTION(QUERYTRACEON 4199)
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:
DBCC TRACEON (4199, -1);
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 :
sp_recompile 'dbo.SomeTable'
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.