Производительность Sproc со временем ухудшается - PullRequest
3 голосов
/ 27 сентября 2010

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

Сведения о моем сервере следующие: - Windows 2008 Datacentre edition
SQL 2008 standard edition (10.0.1600)
12 ГБ ОЗУ
Четырехъядерный однопроцессорный компьютер

Проблема
У меня есть хранимая процедура, которая запускается, и когда я только запускаю SQL, это занимает около1/10 секунды на бег.По прошествии некоторого времени выполнение того же запроса занимает около 3 секунд.

Первоначально я предполагал, что именно индексы вызывают проблемы, но если я создаю точную копию sproc и запускаю эту скопированную версию, тогдаэтот запрос теперь занимает только 1/10 секунды, а исходный - 3 секунды.

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

То, что я до сих пор пробовал
В настоящее время у меня есть план обслуживания, который выполняется каждые 15 минут и переиндексирует небольшойтаблица и по какой-то причине времена выполнения на моих sprocs возвращаются к нормальным уровням, но затем времена внезапно возвращаются снова.

Создана копия sproc для проверки, которая работает с 1/10 секунды, а оригинал все еще занимает много времени.

Запустил sproc "update stats", чтобы убедиться, что вся статистика актуальна.

Запустил профилировщик запросов SQL, чтобы посмотреть, есть ли у него какие-либо предложения по другим индексам, которые должны быть в таблицах, в итоге он выдвинул некоторые предложения, которые увеличили мой индекс и размер базы данных до более чем 70 ГБ, а прирост производительности был незначительным.

Другая информация для примечания
БД распределена по двум БД в одном и том же экземпляре, один содержит информацию о продукте, другой содержит информацию о клиенте.

Одна из объединяющих таблиц имеет длину 130 миллионов строк.

БД - это обновление с 2005 по 2008 год.

Ответы [ 2 ]

4 голосов
/ 27 сентября 2010

Мне кажется, что это нюхает параметр.

Ваша 15-минутная переиндексация (вам это нужно !?) приведет к перекомпиляции зависимой процедуры. Иногда, когда это происходит, случается так, что значения параметров, переданные при следующем выполнении, являются субоптимальными для общего случая. Вы можете использовать OPTIMIZE FOR , чтобы этого не происходило.

1 голос
/ 27 сентября 2010

Похоже, что это вызвано сниффингом параметров.Вот хорошее объяснение:

Я пахну параметром!

Сборщик мусора SQL: анализ параметров и план выполнения хранимых процедур

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...