Как вы измеряете производительность хранимой процедуры?

Я использую версию SQL Server 2005, которая не поддерживает профилировщик, пытаясь выяснить, как лучше всего сравнить производительность двух хранимых процедур. Я запустил план выполнения для каждого из них, но мне не ясно, на какой из предоставленных метрик я должен сосредоточиться. Я должен пройти и сложить различные расходы? Каков наилучший подход?

спасибо заранее.

9
performance stored-procedures tsql

7 ответов

посмотрите на эту статью: измерение производительности SQL

Если вы не хотите регистрироваться на бесплатную учетную запись, вот решение 1:

DECLARE @start datetime, @stop datetime
SET @start = GETDATE()
EXEC your_sp
SET @stop = GETDATE()

2-я:

SET STATISTICS TIME ON
EXEC your_sp

3-я:

SET STATISTICS IO ON
EXEC your_sp

кстати, на этом сайте есть несколько хороших статей. Я бы рекомендовал зарегистрироваться. Это бесплатно.

18

вопрос в том, для чего вы оптимизируете? Это для скорости или используемых ресурсов?

Если скорость, то в анализаторе запросов я бы посмотрел на выполнение между несколькими прогонами, внес бы изменения и повторил их.

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

1

Если вы используете что-то вроде

УСТАНОВИТЬ SHOWPLAN_ALL НА

посмотрите на значение столбца TotalSubtreeCost для строки с EXE YourProcedureName

Это может помочь:

http://technet.microsoft.com/en-us/library/ms180765.aspx

1

Как и большинство вопросов, ответ зависит... В конечном счете, единственной мерой, которая имеет значение, является восприятие конечного пользователя,на которое может повлиять многое, включая не только хранимую процедуру, но и производительность сети, шаблоны использования (sProc называется 20x/day или 1000x/ second?), п., - и sProc не может быть определяющим фактором.

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

0

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

вы всегда можете запустить хранимую процедуру вручную в Query Analyzer и измерить результаты таким образом. Жгут .NET просто автоматизирует процесс для вас.

0

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

0

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

0