Большая разница во времени выполнения хранимой процедуры между Managment Studio и TableAdapter

Как может хранимая процедура запускаться через 10 секунд через Management Studio, но через 15 минут через адаптер таблицы для тех же входных данных? Он повторяемый, то есть я запускал его не менее трех раз в каждой среде, а Management Studio постоянно работает примерно в 100 раз быстрее.

Я использую .net 2.0 и SQL Server 2000

В SQL Server Management я выполняю это так:

EXEC    [dbo].[uspMovesReportByRouteStep]
    @RouteStep = 12000,
    @RangeBegin = N'12/28/08',
    @RangeEnd = N'1/18/9'

В TableAdapter я использую StoredProcedure CommandType и dbo.uspMovesReportByRouteStep для CommandText. Я вызываю адаптер таблицы со страницы ASP.NET, хотя время ожидания истекает через 30 секунд, если я также попытаюсь выполнить «Предварительный просмотр данных» локально.

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

Все остальные хранимые процедуры выполняются примерно в одно и то же время с использованием любого из этих методов. Как это возможно?


.net sql-server timeout stored-procedures tableadapter
person recursive    schedule 16.01.2009    source источник

Ответы (1)


arrow_upward
5
arrow_downward

Это, скорее всего, связано с «сниффингом параметров» и кешированным планом запроса, который не подходит для конкретных значений параметров, с которыми вы его вызываете. Как это случилось? Что ж, при первом вызове SP с одним набором значений будет сгенерирован, параметризован и кэширован план запроса. Если SP вызывается снова с другим набором значений параметров, что привело бы к другому плану запроса, но он использует кэшированный план запроса, это может снизить производительность.

Часто это происходит потому, что статистика устарела. Вы можете определить, так ли это, сравнив Предполагаемый план выполнения с Фактическим планом выполнения; если разные, то статистика, скорее всего, устарела.

Сначала я бы попытался восстановить индексы базы данных или, по крайней мере, обновить статистику (спросите своего администратора базы данных). Один из способов перестроить индексы (должен работать на всех версиях SQL Server):

exec sp_msforeachtable "dbcc dbreindex ('?')"

Если проблема не исчезла, попробуйте временно добавить оператор WITH RECOMPILE в определение хранимой процедуры. Если проблема исчезнет, ​​попробуйте использовать OPTIMIZE FOR, описанный в это сообщение блога.

person Mitch Wheat    schedule 17.01.2009
comment
Как ни странно, здесь у нас действительно нет администратора базы данных. Каким-то образом база данных продолжает работать без какого-либо вмешательства в течение многих лет. Но у меня есть привилегии делать что угодно на сервере, так что, может быть, я начну копаться в этом материале. Спасибо за указатели. - person recursive; 17.01.2009
comment
С RECOMPILE в определении sproc заставляет его работать быстрее, чем когда-либо. Я еще не перестраивал индексы. Но WITH RECOMPILE определенно решил проблему. - person recursive; 17.01.2009
comment
Обратите внимание: WITH RECOMPILE будет перекомпилировать ваш запрос каждый раз при его запуске (а компиляция является относительно дорогой, поэтому SQL Server пытается их кэшировать). Я рекомендую использовать это только временно и вместо этого использую OPTIMIZE FOR. - person Mitch Wheat; 17.01.2009
comment
Я проверю это на следующей неделе. Но я бы сказал, что это значительно дешевле, чем бездействие, о чем свидетельствует сокращение времени выполнения на несколько порядков. - person recursive; 17.01.2009