Мой поиск по теме привел меня сюда, поэтому я просто хотел бы поделиться своим недавним опытом по этой теме.
Я работал под управлением SQL 2014, поэтому решил, что мне не нужно будет немного заботиться о 4199 ... но это просто неправда ...
Как диагностировать, если вам нужно 4199
Если ваш запрос работает плохо , особенно если вам кажется, что это не так, попробуйте добавить следующее в конец, чтобы увидеть, исправит ли он все ваши проблемы, поскольку вам может потребоваться 4199 («Включить все исправления оптимизатора запросов»). )
SELECT SomeColumn
FROM SomeTable
OPTION(QUERYTRACEON 4199)
В моей ситуации у меня была статья из топ-10, взорвавшая запрос, который без проблем работал, что заставило меня думать, что происходит что-то подозрительное, и что 4199 может помочь.
Около 4199
Любые исправления ошибок и производительности оптимизатора запросов SQL Server, созданные после выхода новой основной версии, фактически скрыты и заблокированы. Это на тот случай, если они действительно могут навредить какой-то другой теоретически идеально оптимизированной программе. Таким образом, устанавливайте обновления, как вы могли бы, фактические изменения оптимизатора запросов не включены по умолчанию. Поэтому, как только будет сделано одно исправление или улучшение, 4199 становится необходимостью, если вы хотите воспользоваться этим преимуществом. По мере появления многих исправлений вы в конечном итоге включите их, когда один из них повлияет на вас. Эти исправления обычно связаны с собственными флагами трассировки, но 4199 используется в качестве основного «Включить все исправления».
Если вы знаете, какие исправления вам нужны, вы можете включить их по частям вместо использования 4199. Если вы хотите включить все исправления, используйте 4199.
Итак, вы хотите 4199 глобально ...
Просто создайте задание агента SQL, которое запускается каждое утро со следующей строкой, чтобы глобально включить флаг трассировки. Это гарантирует, что если кто-то выключит их и т. Д., Они снова включатся. Этот шаг работы имеет довольно простой SQL:
DBCC TRACEON (4199, -1);
Где -1 указывает Глобальную часть в DBCC TRACEON. Для получения дополнительной информации см .:
https://msdn.microsoft.com/en-us/library/ms187329.aspx?f=255&MSPPError=-2147217396
«Перекомпилирование» планов запросов
В моей последней попытке мне пришлось включить 4199 глобально, а затем также удалить существующие кэшированные планы запросов :
sp_recompile 'dbo.SomeTable'
https://msdn.microsoft.com/en-us/library/ms181647.aspx?f=255&MSPPError=-2147217396
Где хранимая процедура перекомпиляции находит любые планы запросов, относящиеся к объекту базы данных (например, к таблице), и удаляет эти планы запросов, требуя следующей попытки выполнить аналогичный запрос для их компиляции.
Итак, в моем случае 4199 препятствовал созданию плохих планов запросов, но я также должен был удалить те, которые все еще были кэшированы с помощью sp_recompile. Выберите любую таблицу из известного затронутого запроса, и вы должны попытаться повторить этот запрос, предполагая, что вы теперь включили 4199 глобально и очистили план кэшированных запросов, нарушающий работу кэша.
В заключение 4199
Поскольку вы используете индексы, становится разумной оптимизация плана запросов, чтобы на самом деле использовать эти индексы разумно, и, предполагая, что со временем будет выпущено некоторое исправление для процесса оптимизации запросов, вы, как правило, находитесь в безопасной воде, чтобы просто работать с глобально включенным 4199, до тех пор, пока вы понимаете, что какое-то новое исправление может на самом деле не так хорошо работать с высокооптимизированной базой данных, которая была оптимизирована в предыдущей среде до упомянутого исправления. Но что делает 4199? Это просто позволяет все исправления.