2009-06-23 2 views
0

Я борюсь со странной проблемой, используя Sql Profiler. При запуске скриптов тестирования производительности я запускаю профилировщик, чтобы найти узкие места. Одно конкретное заявление, по-видимому, занимает много времени - с CPU 1407, Reads 75668 и длительностью 175.Непрерывный SQL-запрос Profiler

Однако, когда я запускаю тот же оператор в Management Studio, SQL Profiler возвращает CPU 16, Reads 4 & Продолжительность 55.

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

Спасибо, Сьюзан.

+0

Возможно, вы ничего не делаете неправильно и видите результаты кеширования. Если вы снова проецируете, сокращается ли время? –

+0

Спасибо за отзыв, но я сначала очистил кеш. – 2009-06-23 13:36:54

ответ

3

У вас может быть скалярная пользовательская функция, имеющая доступ к таблице.

Используемые ресурсы собираются только профилировщиком: SSMS не будет отображать внутренний IO или CPU скалярного udf.

Пример:

CREATE FUNCTION dbo.MyUdf (
    @param int 
) 
AS 
RETURNS int 
BEGIN 
    RETURN (SELECT MAX(foo) FROM dbo.MyOtherTable WHERE Key = @param) 
END 
GO 


SELECT 
    col1, col2, dbo.MyUdf(col3) 
FROM 
    dbo.MyFirstTable 

Однако, это не может объяснить продолжительность ...

+1

+1 Я бы не подумал об этом. –

+2

Спасибо. Это общий прием и, фактически, CURSOR, если вы думаете об этом ... – gbn

+0

Я думаю, что это может быть использование курсора, поскольку я вижу это в sql, иногда трассируемом exec sp_prepexec – 2009-06-23 15:33:42

0

Был ява/спящий режим проблемы.

0

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

Если вы щелкните правой кнопкой мыши сервер в Enterprise Manager и выберите «Свойства», вы можете изменить объем доступной памяти для сервера. Если вы измените это число даже на один шаг, SQL-сервер очистит его кеш.