Sproc-характеристики ухудшаются с течением времени

Question

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

Мои данные сервера заключаются в следующем: - Windows 2008 центров обработки данных издание
SQL 2008 Standard Edition (10.0.1600)
12GB Ram
Quad ядра одного процессора машина

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

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

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

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

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

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

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

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

Один из соединительных столов - 130 миллионов строк.

БД является обновлением с 2005 по 2008

Answer 1

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

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

Answer 2

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

I Smell a Parameter!

SQL Garbage Collector: Parameter Sniffing & Stored Procedures Execution Plan