SQL Server воссоздает планы каждый день

У нас есть эта проблема в нашей производственной среде.

Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) - Enterprise Edition (64-разрядная версия) в Windows NT 6.1 (сборка 7601: пакет обновления 1).

SQL Server отбрасывает все (почти 100%) старые планы выполнения и воссоздает их каждый день в одночасье (с 11:00 до 8:00). Это даже происходило, когда «статистика автоматического обновления» была в отключенном состоянии. Мы включили «автоматическое обновление статистики» за последние 2-3 недели. Но это все еще происходит.

Мы на самом деле не знаем, что вызывает это повторное создание планов, но мы уверены, что мы не будем делать это вручную.

Единственное, что действительно совпадает со сроками создания планов, это работа по обслуживанию БД, которая у нас есть: реорганизация ежедневного индекса (при фрагментации 5-30%) и перестройка ежедневного индекса (при фрагментации более 30% ) работа. Обычно эта ежедневная работа по обслуживанию выполняет только реорганизацию (поскольку фрагментация индекса не превышает 30% в день).

Влияние:

Эти недавно созданные планы заставляют некоторые вызовы / запросы UDF (которые вызываются из пользовательского интерфейса / веб-страниц) занимать намного больше времени (в отличие от минут, а не 1 секунды), и поэтому сессии просто накапливаются, загружая ЦП почти на 90%. ,

Проблема исчезает в тот момент, когда эти застрявшие сеансы принудительно удаляются (на стороне БД), и 1) когда все соответствующие планы выполнения очищаются вручную (для запросов) или 2), когда изменяются пользовательские функции (для функций). Любые новые планы, созданные SQL-сервером с этого момента, работают безупречно в течение дня, пока на следующее утро не возникнет та же проблема. Кроме того, это поведение не на все 100%, мы не видим его каждое утро. Но были периоды времени, когда мы видели это последовательно в течение 4-5 дней подряд.

Проблема случается по утрам в бизнесе, то есть, когда пользовательский интерфейс / веб-страницы становятся доступнее, кажется.

У кого-нибудь есть подсказка, что вызывает это и как решить эту проблему? Любая помощь приветствуется.

Ну, у меня есть некоторые идеи, которые могут вызвать такое поведение.

1. Контролируете ли вы давление памяти? Возможно, ваши запросы поднимают определенный лимит, что приведет к очистке кэша плана. Я не знаю ваше приложение, но поддерживает ли этот корреспондент ваши журналы с ваших внешних серверов? Есть ли давление в это время?
2. У вас есть выделенный SQL-сервер, или сервер совместно использует свое оборудование с другими процессами / службами? Если нет, попробуйте вместо этого перенести ваш SQL Server на выделенный компьютер. Это уменьшит побочные эффекты от других услуг.
3. Вы можете использовать его optimize for ad hoc workloads, который просто сохранит заглушку плана и скомпилирует ее, если это необходимо. Это уменьшит нагрузку на ваш Plancache, что снизит вероятность сброса Plancache. Вы можете включить его, используя sp_configure 'optimize for ad hoc workloads',1; reconfigure. Это можно сделать, если вы включили advanced optionsиспользование sp_configure 'show advanced options',1; reconfigure.
4. Еще одна идея может быть резервное копирование. Просто простые резервные копии. Если они агрессивны, может случиться так, что ваша машина тоже окажется под давлением. Время, когда вы упоминаете, звучит как хороший промежуток времени для планирования резервного копирования.
5. Может быть, это довольно простая ошибка в вашем сценарии обслуживания. Вы проверили, есть ли логическая проблема, которая заставляет ваш скрипт перестраивать все индексы, а не только те, которые соответствуют критериям. Возможно, это тоже может быть причиной.

Просто у всех этих возможностей, это может быть полезно проверить лог - файлы для некоторых изменений параметров affinity mask, affinity I/O maskи их партнеров 64. Еще одна вещь может быть изменение MAXDOPварианта вашего экземпляра. Пожалуйста, проверьте журналы для них тоже. Им нужно будет также очистить планшет.

И последнее, но не менее важное: вы все равно можете запустить трассировку на стороне сервера (просто настройте ее с помощью профилировщика, запустите, остановите и используйте команду sql, чтобы снова запустить ее на стороне сервера). Кроме тогоperfmon твой друг. Он может наблюдать и контролировать ваши показатели производительности в течение некоторого времени. Возможно, вы можете увидеть параллели с определенными действиями на вашем сервере, которые могут вызвать их сброс.

Надеюсь, это поможет вам, даже если ответ придет чуть позже.