Флаг трассировки 4199 - Включить глобально?

Это может относиться к категории мнений, но мне любопытно, если люди используют флаг трассировки 4199 в качестве параметра запуска для SQL Server. Для тех, кто его использовал, при каких обстоятельствах вы испытывали регрессию запросов?

Это, безусловно, может показаться потенциальным выигрышем в производительности по всем направлениям, я рассматриваю возможность его глобального использования в нашей непроизводственной среде и оставлю на пару месяцев для решения любых проблем.

Исправлены ли ошибки в 4199 по умолчанию в оптимизаторе в 2014 году (или в 2016 году)? Хотя я понимаю, что не нужно вносить неожиданные изменения в план, кажется странным хранить все эти исправления скрытыми между версиями.

Мы используем 2008, 2008R2 и в основном 2012.

Лично, всякий раз, когда я создаю новый сервер для нового проекта, я всегда включаю TF4199 глобально. То же самое относится и к обновлению существующих экземпляров до более новых версий.

TF позволяет новые исправления, которые могут повлиять на поведение приложения, но для новых проектов риск регрессии не является проблемой. Для экземпляров, обновленных с предыдущих версий, различия между старой и новой версией сами по себе являются проблемой, и в любом случае ожидается необходимость иметь дело с планом регрессии, поэтому я предпочитаю бороться с ним с включенным TF4199.

Что касается существующих баз данных, есть только один способ узнать это: проверить это. Вы можете зафиксировать рабочую нагрузку на существующей установке и воспроизвести ее после включения флага. Утилиты RML могут помочь вам автоматизировать процесс, как описано в этом ответе .

Очевидно, что флаг влияет на весь экземпляр, поэтому вам придется протестировать все базы данных, которые там находятся.

Мой поиск по теме привел меня сюда, поэтому я просто хотел бы поделиться своим недавним опытом по этой теме.

Я работал под управлением 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? Это просто позволяет все исправления.

Я хотел поделиться своим опытом с трассировкой флага 4199.

Я только что закончил диагностировать проблему с производительностью в клиентской системе под управлением SQL Server 2012 SP3. Заказчик перемещал базу данных отчетов с рабочего OLTP-сервера на новый сервер. Целью заказчика было устранить конкуренцию за ресурсы с помощью запросов OLTP. К сожалению, клиент сказал, что новый сервер отчетов работает очень медленно.

Пример запроса выполняется в системе OLTP за 1,6 секунды. План запроса выполнил поиск индекса для таблицы строк размером ~ 200 миллионов, которая была частью представления.

На новом сервере тот же запрос выполнен за 10 минут 44 секунды. Он выполнил сканирование индекса для той же таблицы строк ~ 200 миллионов.

Данные сервера отчетов были копией данных OLTP, поэтому в данных не было разницы.

Я был в замешательстве, пока не вспомнил, что наше программное обеспечение (в котором работает их система OLTP) включало некоторые флаги трассировки при запуске. Один из них, 4199, я вспомнил, был исправлением оптимизатора запросов.

Я протестировал включение флага трассировки 4199 на новом сервере отчетов клиента, и запрос отчета был выполнен за 0,6 секунды. (Ух ты!) Я отключил флаг трассировки, и запрос вернулся к завершению через 10 минут 44 секунды. Включен флаг: обратно до 0,6 секунд. Очевидно, включение флага трассировки позволило оптимизатору использовать поиск по индексу в представлении таблицы 200 миллионов строк.

В этом случае оптимизация запросов, включенная с помощью флага трассировки 4199, имела огромное значение. Ваш опыт может отличаться. Тем не менее, исходя из этого опыта, мне определенно стоит дать мне возможность.