Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
ef1
Member

Откуда: Москва
Сообщений: 188
не подскажите есть две абсолютно аналогичные последовательности действий - 4 запроса
только одна из них оформлена в виде хп а другая просто в виде 4 запросов запускаемых из QA.

хп почему то жутко тормозит и выполняется в 4 раза медленнее чем просто последовательность запросов- смотрел планы - они примерно одинаковые но в хп идет какая то задержка между запросами - выявить ее никак не могу - не подскажите куда смотреть
9 июл 07, 14:14    [4367577]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
Glory
Member

Откуда:
Сообщений: 104760
они примерно одинаковые
Хм. Насколько примерно ?
9 июл 07, 14:17    [4367601]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
ef1
Member

Откуда: Москва
Сообщений: 188
один в один
9 июл 07, 14:22    [4367645]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
YellowMan
Member

Откуда: острова
Сообщений: 1047
Планы один в один?

Смотрите перекомпиляется ли ваша процедура каждый раз или нет. Смотреть профайлером или в кеше.
9 июл 07, 14:28    [4367679]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
ef1
Member

Откуда: Москва
Сообщений: 188
хп сохранена в базе, профайлер показывает ее вызов и все - значит она уже скомпилирована?.
При запуске хп из QA он задумывается на 4 сек потом начинает ее медленно выполнять - значит перекомпилируется? как настроить Profiler - чтобы точно это узнать?
9 июл 07, 14:43    [4367768]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
Glory
Member

Откуда:
Сообщений: 104760
ef1
один в один

Это называется совершенно однинаковые, а не примерно одинаковые
Вы может быть не все события отслеживаете в трассе ?
9 июл 07, 14:46    [4367794]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
YellowMan
Member

Откуда: острова
Сообщений: 1047
Посмотреть на событие SP:Recompile
9 июл 07, 14:58    [4367876]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
ef1
Member

Откуда: Москва
Сообщений: 188
а не подскажите какие именно ключевые события события нужно отметить в Profiler чтобы получить полную картину по моей хп (сейчас использую стандартный шаблон) пробовал и другие- но кроме одной строчки в вызовом exec... больше ничего нет (т.е. хп не раскрывается-одна строка и все)
9 июл 07, 15:01    [4367896]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
ef1
Member

Откуда: Москва
Сообщений: 188
показывает 4 перекомпиляции, но к чему они относятся не совсем ясно т.к. в Profiler строка TextData пустая, да и хп одна а не 4? правда в ней 4 запроса...
если это действительно моя перекомпиляция - то как ее отключить? - ведь хп уже записана в базе
9 июл 07, 15:08    [4367931]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
Ray D
Member

Откуда: from the middle of nowhere
Сообщений: 3598
Блог
компиляция это совсем не создание х.п. в БД
9 июл 07, 15:11    [4367956]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
KGP
Member

Откуда: Москва
Сообщений: 4557
Glory
ef1
один в один

Это называется совершенно однинаковые, а не примерно одинаковые
Вы может быть не все события отслеживаете в трассе ?


но сейчас выясниться, что в QA константы, а в xp параметры и т.д.
имхо - скрипты xp в студию
9 июл 07, 15:15    [4367990]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
ef1
Member

Откуда: Москва
Сообщений: 188
ну ладно а чего делать то?? еще одна странность что закладка Result в QA показывает выполнение каких то промежуточных операций между запросами которых по тексту нет т.е хп идет за 8 операций а свободные запросы за 4 как и должно быть.. в общем не знаю куда и смотреть? может сюда хп выложить? посмотрите опытным взлядом?
9 июл 07, 15:16    [4367995]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
YellowMan
Member

Откуда: острова
Сообщений: 1047
Было бы неплохо для начала:

1.Сообщить версию сервера.
2.Посмотреть и сравнить CPU,Reads,Writes для обоих случаев.
3.Почитать http://msdn2.microsoft.com/en-us/library/ms181055.aspx
9 июл 07, 15:20    [4368032]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
ef1
Member

Откуда: Москва
Сообщений: 188
Да тут параметры - там константы - но не в 4 же раза длиннее??
ниже хп (та ветка по которой идет обсуждение), если выбросить из нее все объявления и if - будет то что запускал в QA
программа делает следующее 4 действия
1.очищает существующую таблицу
2.создает временную таблицу в одну кидает туда первичные ключи из существующей таблицы
3.создает временную таблицуи кидает туда результаты запроса
4.помещает все это в существующую таблицу


ALTER          Procedure [LSDBO].[Ric_RefreshArray]
        (@d_atr numeric(18,0) Output,  	--ID массива (атрибута) для записи значений
         @NSelect integer=0,			--номер Select
         @ObjID numeric(18,0)=0,      	--ID объекта
         @ObjType char(256),       		--Тип объекта
         @ObjAttr1ID numeric(18,0)=0,  	--ID Атрибута1 Объекта
         @ObjAttr1Value sql_variant=0,  --Значение Атрибута1 Объекта
         @ObjAttr2ID numeric(18,0)=0,  	--ID Атрибута2 Объекта
         @ObjAttr2Value sql_variant=0	--Значение Атрибута2 Объекта
         )As

 Begin
  SET CONCAT_NULL_YIELDS_NULL OFF		--отключить проверку NULL значений

  Declare @ID numeric(18,0),			--переменная для ID	
          @Value varchar(255),          --переменная для значения массива
          @CountID integer,				--количество свободных ID				
          @CountArray integer			--количество запрашиваемых ID

  if @NSelect>100						--<100 выбор >100 поиск
   Begin
  --Очистить массив
     Update lsdbo.value_string Set 
              value ='',				--обнулить все строки
              filial_id=1				--запретить отражение атрибутов
       From lsdbo.value_string
      Where lsdbo.value_string.attrib_id=@d_atr
 
  --Прочитаем текущую длину массива
    Select @CountArray=@@rowcount

  --Создать и заполнить первую временную таблицу результатами запроса
     Create table #t1 (id numeric(18,0) identity(1,1) primary key, value char(255) not null ,filial_id int not null )

     If @NSelect=101
      Begin
       Insert #t1(filial_id,value)
        Select TOP 25--(@CountArray)
                0 as filial_id,
                left (rw.description + space(200),200)+
                    --форма собственности 
                    '|'+(SELECT vv.value
                             FROM lsdbo.attrib_value_view av,
                                  lsdbo.value_string_view vv 
                            WHERE av.value_id = vv.id 
                                  AND av.object_id = rw.id
                                  AND av.treelink_id = 0 
                                  AND av.attrib_id = @ObjAttr1ID)+'|' +  
                    STR(rw.id,15) as value 
           From lsdbo.object_reference_view rw,
                lsdbo.object_type_view tw
          Where (rw.type_id = tw.id) 
                 AND (tw.mnemo = @ObjType)
                 and(rw.description like CAST(@ObjAttr1Value AS varchar(256))); 
      End

  --Создать и заполнить вторую таблицу id номереми массива
 Create table #t2 (id numeric(18,0) identity(1,1) not for replication primary key,Free_id numeric(18,0) not null )
 Insert #t2(Free_id)
       Select lsdbo.value_string.id
         From lsdbo.value_string
        Where lsdbo.value_string.attrib_id=@d_atr

  --Записать результаты запроса через двойную перепривязку в массив
      Update vs Set 
                 vs.value=t1.value,
                 vs.filial_id=t1.filial_id
        From lsdbo.value_string vs
             join #t2 t2
             on t2.Free_id=vs.id
             join #t1 t1
             on t1.id=t2.id

  --Удалить временные таблицы
      Drop table #t1
      Drop table #t2

    Set @d_atr=0
   End

  Else

   Begin
    ..... процедуры если @NSelect<100
   End 

    SET CONCAT_NULL_YIELDS_NULL ON		--включить проверку NULL значений
 End
9 июл 07, 15:31    [4368138]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
ef1
Member

Откуда: Москва
Сообщений: 188
YellowMan
1.Сообщить версию сервера.
2.Посмотреть и сравнить CPU,Reads,Writes для обоих случаев.

MSSQL2000 SP4
Duration/CPU/Reads/Writes практически одинаковые для двух вариантов разброс +/- 5%
9 июл 07, 15:36    [4368183]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
YellowMan
Member

Откуда: острова
Сообщений: 1047
А вы попробуйте сделать абсолютно так-же как как и запросы: уберите всяческие ветвления.
И признайтесь что не читали про причины, вызывающие перекомпиляцию.
9 июл 07, 15:48    [4368255]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
ef1
Member

Откуда: Москва
Сообщений: 188
ветвления убрать не могу - это достаточно длинная процедура в которой в первой части в зависимости от номера идут разные запросы результаты которых пишутся в существующие таблицы фиксированной длины а во второй через курсоры также в зависимости от номера пересоздаются существующие таблицы по длине данных от запросов.
Ветвления по моему никак не должны влиять на скорость - кроме того здесь ничего динамического - все забито сразу - только значения переменных разные.

а что вызывает перекомпиляцию - я даже не знаю где про это прочитать :(
9 июл 07, 15:56    [4368317]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
YellowMan
Member

Откуда: острова
Сообщений: 1047
Ну кроме той ссылки что я послал можно еще вот тут - http://www.sqlservercentral.com/columnists/RDyess/ospr.asp

И уберите создание временной таблицы из if - не уверен что это единственная причина перекомпиляции, но одного этого вполне хватит.
9 июл 07, 16:17    [4368509]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
YellowMan
Member

Откуда: острова
Сообщений: 1047
Ветвления кстати убрать можно всегда - для этого есть клиент. вот на нем и ветвите.
9 июл 07, 16:18    [4368523]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
KGP
Member

Откуда: Москва
Сообщений: 4557
YellowMan
Ветвления кстати убрать можно всегда - для этого есть клиент. вот на нем и ветвите.


лучше сделать 3 хранимки, чтоб клиента не переписывать
1-я Ric_RefreshArray, принимает входящие и опционно вызывает 2-ю или 3-ю
9 июл 07, 16:44    [4368739]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
Ray D
Member

Откуда: from the middle of nowhere
Сообщений: 3598
Блог
а ветвления-то зачем убирать??
9 июл 07, 16:49    [4368777]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
YellowMan
Member

Откуда: острова
Сообщений: 1047
Потому что например стоит вам объявить переменную или создать таблицу в ветке и будет рекомпиляция.

А во многих случаях, напимер когда запросы в ветках разные, то перекомпиляция будет и без объявлений. Откуда бедному серверу знать по какой ветке поедет выполнение?
9 июл 07, 17:36    [4369119]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
Ray D
Member

Откуда: from the middle of nowhere
Сообщений: 3598
Блог
YellowMan
А во многих случаях, напимер когда запросы в ветках разные, то перекомпиляция будет и без объявлений. Откуда бедному серверу знать по какой ветке поедет выполнение?

Это вы откуда такое взяли? можно репро или ссылку на документацию?
9 июл 07, 17:41    [4369148]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
YellowMan
Member

Откуда: острова
Сообщений: 1047
автор
Это вы откуда такое взяли? можно репро или ссылку на документацию?


Не дам, похоже вы правы - зато я вспомнил откуда у меня такое заблуждение: из-за пары SP:CacheMiss и SP:cacheInsert ивентов в профайлере после каждого ветвления.
Но это немного другая тема.
9 июл 07, 18:19    [4369368]     Ответить | Цитировать Сообщить модератору
 Re: почему запросы в хп работают медленнее аналогичных свободных запросов  [new]
ef1
Member

Откуда: Москва
Сообщений: 188
не знаю в чем было дело - но выделив свою ветку в отдельную (независимую) процедуру я получил тоже быстродействие что и на свободных запросах.
Может действительно в ветвлениях т.к. пока было 2-3 варианта запроса - все работало быстро - когда вариантов добавилось до 10 - стало резко хуже - похоже придется перестроить логику работы этого куска
10 июл 07, 07:53    [4370285]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить