В какой-то момент в вашей карьере с SQL Server обнаружение параметров просто выпрыгивает и атакует?

Question

Сегодня я снова столкнулся с ОСНОВНОЙ проблемой, связанной с анализом параметров в SQL Server 2005.

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

Я добавляю критерий к своему предложению WHERE - оно генерируется кодом, поэтому это буквальная константа:

WHERE DATA_DT_ID = 20081231 - Это избыточно, потому что все DATA_DT_ID на данный момент 20081231.

Производительность идет в ногу. От 7 секунд сравнивать около 1,5м рядов до 2 часов и ничего не заканчивать. Запуск сгенерированного SQL прямо в SSMS - без SP.

Я использую SQL Server уже 12 лет, и у меня никогда не было такого количества проблем со сниффингом параметров, как у меня на этом производственном сервере с октября (сборка 9.00.3068.00). И в любом случае это не потому, что он был запущен в первый раз с другим параметром или изменена таблица. Это новая таблица, и она запускается только с этим параметром или без условия WHERE.

И, нет, у меня нет доступа к БД, и они не дали мне достаточно прав, чтобы увидеть планы выполнения.

Дело в том, что я не уверен, что смогу справиться с этой системой пользователям SQL Server с опытом работы всего пару лет.

ОБНОВЛЕНИЕ Оказывается, что хотя статистика утверждает, что она актуальна, запуск команды ОБНОВЛЕНИЕ СТАТИСТИКИ С FULLSCAN устраняет проблему.

ЗАКЛЮЧИТЕЛЬНОЕ ОБНОВЛЕНИЕ Даже при воссоздании SP с использованием WITH RECOMPILE и UPDATE STATISTICS оказалось, что запрос нужно было переписать другим способом, чтобы использовать NOT IN вместо LEFT JOIN с проверкой NULL .

Answer 1

Не совсем ответ, но я поделюсь своим опытом.

Изучение параметров заняло несколько лет, когда SQL Server пришел и укусил меня, когда я вернулся в Developer DBA после того, как перешел в основном к работе prod DBA. Я больше разбирался в движке, как работает SQL, что лучше оставить клиенту и т. Д., И я был лучшим SQL-кодером.

Например, динамический SQL или CURSOR или просто плохой код SQL, вероятно, никогда не будут испытывать перехват параметров. Но лучше настроить программирование или как избежать динамического SQL или более элегантного SQL, скорее всего.

Я заметил это для сложного кода поиска (множество условных выражений) и сложных отчетов, где параметры по умолчанию влияли на план. Когда я увижу, как менее опытные разработчики будут писать этот код, он не будет испытывать перехват параметров.

В любом случае, я предпочитаю маскировку параметров WITH RECOMPILE. Обновление статистики или индексов в любом случае вызывает перекомпиляцию. Но зачем перекомпилировать все время? В другом месте я ответил на один из ваших вопросов со ссылкой, в которой упоминаются параметры, которые прослушиваются во время компиляции, поэтому я тоже не верю в это.

Маскирование параметров - это издержки, да, но оно позволяет оптимизатору оценивать запрос в каждом конкретном случае, а не перекомпилировать все данные. Особенно с перекомпиляцией SQL Server 2005 на уровне операторов

Оптимизация для UNKNOWN в SQL Server 2008 также, по-видимому, делает то же самое, что и маскирование. Мой коллега по SQL Server MVP и я потратили некоторое время на расследование и пришли к такому выводу.

Answer 2

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

По сути, это не похоже на проблему с анализом параметров, а скорее на проблему с работоспособной базой данных.

В этой статье описывается, как вы можете определить время последнего обновления статистики: Время обновления статистики

Answer 3

Я второй комментирую о проверке статистики - я видел несколько случаев, когда производительность запроса падала со скалы именно потому, что статистика устарела.

В частности, если у вас есть дата в вашем ПК, и SQL Server считает, что существует только 10 или 100 записей, которые после определенной даты, когда на самом деле их тысячи, могут выбрать ужасно неэффективные планы запросов, поскольку считают, что набор данных намного меньше, чем на самом деле.

НТН,

• Andrew

Answer 4

У меня была проблема с производством, точно такая же. Вкладка в приложении, которая назвала сохраненный процесс, не будет отображаться. Я запустил трассировку для конкретного процесса и увидел вызов. Время ожидания приложения истекает через 30 секунд, и для завершения процесса потребуется около 40 - 50 секунд (процесс запускался точно так, как было вызвано из трассировки).

Следующим шагом было выяснить, какое утверждение вызывало сканирование, которое я замечаю при выполнении процедуры. Поэтому я написал сценарий процедуры, удалил синтаксис процедуры и объявил переменные и запустил анализатор запросов. Это РАН в 3 сек !!!

Я пишу это, чтобы любой, кто ищет ответы, знал, что это может происходить в SQL. Это связано с проблемой сниффинга параметров. Я не смог обойти эту тему, потому что указал причину в виде неверного плана кешированных запросов! Я читал посты, где говорится, что это происходит с одним конкретным пользователем / значением. Но это может произойти с любым значением, и как только оно начнется, оно может быть непрерывным.

Решением для меня было написать скрипт и запустить его снова. да уж. так просто. Алтер работает отлично. Не нужно сбрасывать и заново создавать. Это заставляет SQL обновлять кэшированный план, и все было в порядке. Я не понял, как отключить это на уровне сервера. Слишком громоздко убирать все процы. Надеюсь, это поможет