Большая разница во времени выполнения хранимой процедуры между Managment Studio и TableAdapter - PullRequest
2 голосов
/ 17 января 2009

Как может хранимая процедура работать через 10 секунд через Management Studio, но через 15 минут через TableAdapter для тех же входных данных? Это повторяется, что означает, что я запускаю его как минимум три раза в каждой среде, а 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 строк с зависимостями от ряда других пользовательских функций и представлений в той же и других базах данных.

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

1 Ответ

5 голосов
/ 17 января 2009

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

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

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

exec sp_msforeachtable "dbcc dbreindex ('?')"

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

...