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 дней подряд.

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

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

— peter.petrov
источник

Plancache может быть освобожден либо, когда машина находится под давлением памяти, или если вы измените настройки ob db level. (изменить БД). Так как вы сказали, что не удаляете их "вручную", я предполагаю, что это может быть нехватка памяти. Сколько памяти у машины? каковы ваши максимальные настройки памяти? у вас есть виртуальная среда и, возможно, перераспределенная оперативная память?

— RayofCommand

Почему ты на SP1. Прежде чем что-либо делать, примените SP3. SQL Server может форсировать планы, если он обнаруживает нехватку памяти и ему нужно больше памяти для размещения страниц, особенно при перестроении индекса, особенно если у вас большие таблицы. Перестроение индекса будет пытаться принести как можно больше страниц. Что вы можете сделать, это прекратить использовать MP и использовать решение Ola Hallengren и посмотреть, поможет ли это. Что такое максимальная память сервера?

— Шэнки

Ребята, я не администратор баз данных, а только разработчик SQL. Я просто спрашиваю все это, поскольку это происходит в течение достаточно долгого времени. Спасибо за ваши комментарии, я постараюсь ответить на все из них, хотя сейчас мне трудно следовать (и для вас все это кажется довольно очевидным). Что такое МП?

— peter.petrov

@ peter.petrov Мы пытаемся помочь вам, познакомившись с вашей средой. MP = планы обслуживания.

— Кин Шах

Настоящая проблема в том, что ваши планы запросов настолько хрупки. Перекомпиляции могут произойти в любое время, даже в течение дня. Нет гарантий. Исправьте ваши запросы, чтобы планы стали стабильными. OPTION RECOMPILE или OPTIMIZE FOR UNKNOWN - это подходы кувалдой, которые могут быть уместны и могут быть быстро исправлены.

— USR

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

Контролируете ли вы давление памяти? Возможно, ваши запросы поднимают определенный лимит, что приведет к очистке кэша плана. Я не знаю ваше приложение, но поддерживает ли этот корреспондент ваши журналы с ваших внешних серверов? Есть ли давление в это время?
У вас есть выделенный SQL-сервер, или сервер совместно использует свое оборудование с другими процессами / службами? Если нет, попробуйте вместо этого перенести ваш SQL Server на выделенный компьютер. Это уменьшит побочные эффекты от других услуг.
Вы можете использовать его 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.
Еще одна идея может быть резервное копирование. Просто простые резервные копии. Если они агрессивны, может случиться так, что ваша машина тоже окажется под давлением. Время, когда вы упоминаете, звучит как хороший промежуток времени для планирования резервного копирования.
Может быть, это довольно простая ошибка в вашем сценарии обслуживания. Вы проверили, есть ли логическая проблема, которая заставляет ваш скрипт перестраивать все индексы, а не только те, которые соответствуют критериям. Возможно, это тоже может быть причиной.

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

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

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

— ионный
источник