долго работает хранимая процедура

← →
SLP © (2007-01-16 12:02) [0]

Добрый день!
У меня хранимая процедура на сервере отрабатывает около 5 мин. Помещаю этот же самый запроc в QA и он отрабатывает за 2 сек. Сервер MSSQL2000, SP поставлен последний.
Помогите пожалуйста советом, куда смотреть ?

← →
stone © (2007-01-16 12:03) [1]

> Помогите пожалуйста советом, куда смотреть ?

на план выполнения запроса и команды в профайлере

← →
SLP © (2007-01-16 12:08) [2]

> на план выполнения запроса и команды в профайлере

Не знаю как в хранимой процедуре смотреть план выполнения запроса и команды...
Вот текст ХР

CREATE PROCEDURE [dbo].[ssd_delayed_period] (@d_mail datetime, @d_mail2 datetime ) AS

------EXEC DBO.SSD_DELAYED "20061205","20061215"

BEGIN
select rtrim(ves.iki_ves)+" "+ rtrim(ves.board_number)+" "+rtrim(ves.ves) as name_ves,cast(convert(char(10),
a.datetime,102) as datetime) as ssd_data,
datediff(day,a.datetime,cast(convert(char(10),a.ssd_mail,102) as datetime))-1 as day_r,a.id_ssd, a.id_ves, a.ssd_mail
from start_ssd a, start_ssd b
join ves on b.id_ves=ves.id_ves
where a.ssd_mail>=@d_mail
and a.ssd_mail<=@d_mail2
and a.id_ssd=b.id_ssd
and a.processstatus not in (1,11)
and a.mem in (21,31)
and a.id_ves<>0
and datediff(day,a.datetime,a.ssd_mail)>=2
and not exists
(select id_ssd
from start_ssd
where id_ves=a.id_ves
and datetime=a.datetime
and ssd_mail<a.ssd_mail)
order by a.ssd_data, a.id_ves

END
GO

← →
stone © (2007-01-16 12:19) [3]

> SLP © (16.01.07 12:08) [2]

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

← →
evvcom © (2007-01-16 12:25) [4]

> [2] SLP © (16.01.07 12:08)
> from start_ssd a, start_ssd b
> join ves

ты бы уж определился, то ли ты будешь использовать ключевое слово join, то ли не будешь. А так от твоего винегрета подташнивает.

> and not exists
> (select id_ssd
> from start_ssd

по сути получается, если оптимизатор не сможет ЭТО как то умно переделать, то получится, что для каждого a.id_ves надо серверу выполнить подзапрос, отсюда и тормоза. Попробуй
from start_ssd a left join start_ssd с on c.id_ves=a.id_ves and c.datetime=a.datetime and c.ssd_mail<a.ssd_mail where c.id_ves is null
Вместо многократного выполнения подзапроса только join и filter.

← →
SLP © (2007-01-16 14:40) [5]

> evvcom © (16.01.07 12:25) [4]

Попробовала Ваш запрос в QA.
declare @d_mail datetime,@d_mail2 datetime
set @d_mail="20070101"
set @d_mail2="20070115"
select rtrim(ves.iki_ves)+" "+ rtrim(ves.board_number)+" "+rtrim(ves.ves) as name_ves,
cast(convert(char(10),
a.datetime,102) as datetime) as ssd_data,
datediff(day,a.datetime,cast(convert(char(10),a.ssd_mail,102) as datetime))-1 as day_r,a.id_ssd, a.id_ves, a.ssd_mail
from start_ssd a
left join start_ssd c
on c.id_ves=a.id_ves and
c.datetime=a.datetime and
c.ssd_mail<a.ssd_mail
join ves on a.id_ves=ves.id_ves
where c.id_ves is null
and a.ssd_mail>=@d_mail
and a.ssd_mail<=@d_mail2
and a.processstatus not in (1,11)
and a.mem in (21,31)
and a.id_ves<>0
and datediff(day,a.datetime,a.ssd_mail)>=2
order by a.ssd_data,a.id_ves

Такой запрос, конечно, красивый. Но вот выполняется он в среднем на 2 сек дольше, чем с "and not exists". Мой 5 сек, Ваш - 7 сек. Запускала по очереди порядка 10 раз.
Но в любом случае, когда выполняешь его в ХП, все также медленно выполняется ХП, порядка 5 мин.

← →
Desdechado © (2007-01-16 15:44) [6]

а зачем нужна процедура из одного запроса?

← →
evvcom © (2007-01-16 15:50) [7]

> [5] SLP © (16.01.07 14:40)
> он в среднем на 2 сек дольше

значит оптимизатор нормально разруливал

> Но в любом случае, когда выполняешь его в ХП, все также
> медленно выполняется ХП, порядка 5 мин

значит план другой. Я с MS мало общался, но помню читал как-то советы по этому поводу. Есть в справке такое:
Creating a stored procedure that specifies the WITH RECOMPILE option in its definition ...
может это и не хороший совет (устранение последствий, а не причины), но тем не менее.

> cast(convert(char(10),a.ssd_mail,102) as datetime))

а это зачем? Если данные по сути дата или число не надо их хранить в строке! Аналогично с параметрами.

← →
clickmaker © (2007-01-16 15:53) [8]

> [6] Desdechado © (16.01.07 15:44)
> а зачем нужна процедура из одного запроса?

а что в этом криминального?

← →
Ega23 © (2007-01-16 15:54) [9]

> а это зачем? Если данные по сути дата или число не надо
> их хранить в строке! Аналогично с параметрами.

Это так округляется время и берётся предыдущий день.

← →
evvcom © (2007-01-16 15:58) [10]

> [9] Ega23 © (16.01.07 15:54)
> Это так округляется время и берётся предыдущий день

А, ну да... :)))
Только для этого есть спец.функция округления, но ты то знаешь это. Осталось автору это рассказать.

← →
SLP © (2007-01-16 17:03) [11]

> evvcom © (16.01.07 15:50) [7]

Почитала книжки по серверу, справку, запускала 2 варианта выполнения процедуры ( с "and not exists" и с left join) :

exec DBO.SSD_DELAYED_period1 "20070101","20070115" with recompile

- результат тот же. от 5 до 8 мин.

> evvcom © (16.01.07 15:58) [10]

Расскажите, пожалуйста.

← →
Павел Калугин © (2007-01-16 17:05) [12]

> [10] evvcom © (16.01.07 15:58)
> Только для этого есть спец.функция округления,

В MSSQL? какая?

← →
evvcom © (2007-01-16 17:13) [13]

> [12] Павел Калугин © (16.01.07 17:05)

Чего, нету что ль? Бардак.
Помнится перед Новым Годом как раз Ega23 в какой-то ветке и говорил об округлениях даты без конвертации к чару. Round дату принимает?

← →
Desdechado © (2007-01-16 17:23) [14]

clickmaker © (16.01.07 15:53) [8]
> а что в этом криминального?
Да ничего, если без фанатизма. Только зачем?

← →
Bless © (2007-01-16 17:23) [15]

А если выполнить в QueryAnalizer что-то в духе
declare @d_mail datetime, @d_mail1 datetime select rtrim(ves.iki_ves)+" "+ rtrim(ves.board_number)+" "+rtrim(ves.ves) as name_ves,cast(convert(char(10), a.datetime,102) as datetime) as ssd_data, datediff(day,a.datetime,cast(convert(char(10),a.ssd_mail,102) as datetime))-1 as day_r,a.id_ssd, a.id_ves, a.ssd_mail from start_ssd a, start_ssd b join ves on b.id_ves=ves.id_ves where a.ssd_mail>=@d_mail and a.ssd_mail<=@d_mail2 and a.id_ssd=b.id_ssd and a.processstatus not in (1,11) and a.mem in (21,31) and a.id_ves<>0 and datediff(day,a.datetime,a.ssd_mail)>=2 and not exists (select id_ssd from start_ssd where id_ves=a.id_ves and datetime=a.datetime and ssd_mail<a.ssd_mail) order by a.ssd_data, a.id_ves exec [ssd_delayed_period] @d_mail, @d_mail1

и сравнить планы выполнения?
Кстати, лучшие собаководы рекомендуют начинать процедуру с команды SET NOCOUNT ON (но это я так, к слову)

← →
Bless © (2007-01-16 17:25) [16]

@d_mail2 datetime

← →
SLP © (2007-01-16 17:31) [17]

> Bless © (16.01.07 17:25) [16]

Спасибо. уже запустила, крутится 5 минуту....
Не знаю как разрулить ситуацию, завтра уже напишу планы выполнения. Нужно идти домой.

← →
Bless © (2007-01-17 11:59) [18]

> SLP © (16.01.07 17:31) [17]
> крутится 5 минуту....Не знаю как разрулить ситуацию, завтра
> уже напишу планы выполнения. Нужно идти домой.

Ну и как все прошло?

← →
SLP © (2007-01-17 12:54) [19]

> Bless © (17.01.07 11:59) [18]

Отвлеклась на другую работу... А насчет ХП : выполняется около 7 мин, планы запросов select-а и ХП на экране смотрю одновременно, но что с чем и как сравнивать и как их понимать не знаю. На каждом этапе и в первом и во-втором случае указывается % от всего выполнения selеcta ли ХП. А время выполнения этого этапа, например там где 70% не указывается, вернее я не вижу
Индексы в табл меняла, не помогает. Сейчас индексы по ssd_mail, datetime, id_ves. PK по id_ssd.

← →
Ega23 © (2007-01-17 13:10) [20]

> Помнится перед Новым Годом как раз Ega23 в какой-то ветке
> и говорил об округлениях даты без конвертации к чару. Round
> дату принимает?
>

Я делаю
Declare @dt datetime Set @dt=getdate() Select @dt=Cast(Cast(@dt as int) as datetime)

← →
Павел Калугин © (2007-01-17 13:23) [21]

> [20] Ega23 © (17.01.07 13:10)

а я через строку привык гонять... Через целое быстрее разве?

← →
Ega23 © (2007-01-17 13:30) [22]

> а я через строку привык гонять... Через целое быстрее разве?
>
>

дык. DateTime ведь число.

← →
Павел Калугин © (2007-01-17 13:32) [23]

> [22] Ega23 © (17.01.07 13:30)

а конверту не пофиг?

← →
Ega23 © (2007-01-17 13:36) [24]

> а конверту не пофиг?

Шут его знает. Специально не проверял, но мне кажется, что через int быстрее будет.

← →
Ega23 © (2007-01-17 13:46) [25]

Шеф так делает
Set @Date=cast( Floor(cast(@DateTime as numeric(18,12))) as datetime)
Это, ИМХО, как-то мутновато...

← →
Павел Калугин © (2007-01-17 13:51) [26]

> [24] Ega23 © (17.01.07 13:36)

Олег, через округление числа - грабля...
declare @d datetime select @d=convert(datetime,"17 Jan 2007 23:59:59:01",13) select @d Select Cast(Cast(@d as int) as datetime) select convert(datetime,convert(varchar,@d,3),3)
и сравни результаты. иногда это ошибка.

← →
SLP © (2007-01-17 13:52) [27]

I>
> SLP © (17.01.07 12:54) [19]

А на [19] ничего не напишите?

← →
Павел Калугин © (2007-01-17 13:52) [28]

> [25] Ega23 © (17.01.07 13:46)

вот через флур - это верно. грабли не будет..

← →
Павел Калугин © (2007-01-17 13:53) [29]

> [27] SLP © (17.01.07 13:52)

а план запроса посмотреть дашь?

← →
Ega23 © (2007-01-17 13:58) [30]

> Олег, через округление числа - грабля...

Согласен. Это я не продумал.
Ну тогда [25] - та наверняка

← →
Павел Калугин © (2007-01-17 14:01) [31]

> [30] Ega23 © (17.01.07 13:58)

а select convert(datetime,convert(varchar,@d,3),3) чем не то?
ну да собстно результат то один и тот же...

> [27] SLP © (17.01.07 13:52)

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

← →
Bless © (2007-01-17 14:07) [32]

> SLP © (17.01.07 12:54) [19]
>

Я правильно понял, что или ХП или запрос занял 70% от общего времени выполнения?
Если так, то это как-то не согласуется с твоими 5 мин против 2 сек.
Или ты опечаталась и на самом деле 5 мин против 2 мин?
Впрочем, в любом случае неплохо бы глянуть план.
Я правильно понимаю, что ты не знаешь, как его в текстовом виде получить?
Если да, то выполни сначала в Query Analizer-е
set showplan_all on, а потом
еще раз то, что в [15]. Полученные планы выложи здесь.

← →
Bless © (2007-01-17 14:10) [33]

А на
http://sql.ru/forum/actualforum.aspx
спрашивать не пробовала?
Твой вопрос все же не к программированию баз в делфи, а чисто к MS SQL больше относится. Да и народу там поболе тусуется, шансы получить ответ выше.

← →
Ega23 © (2007-01-17 14:11) [34]

> а select convert(datetime,convert(varchar,@d,3),3) чем не
> то?

Ты по-аккуратнее с varchar без длины.

← →
Павел Калугин © (2007-01-17 14:21) [35]

> [34] Ega23 © (17.01.07 14:11)

:) но работает:) хотя если написать
declare @v varchar set @v=convert(varchar,getdate(),3)
то получим @v="1"
а если просто
select convert(varchar,getdate(),3)
то получим 17/01/07

← →
stone © (2007-01-17 14:35) [36]

> то получим @v="1"

по умолчанию при объявлении переменной размер варчар равен мин. кол-ву символов, т.е. 1

> select convert(varchar,getdate(),3)
> то получим 17/01/07

при конвертации размер по умолчанию = макс кол-ву символов конвертируемого типа

2 Ega23 © (17.01.07 14:11) [34]
так что тут все нормально :)

← →
SLP © (2007-01-17 14:43) [37]

> Bless © (17.01.07 14:10) [33]

Спасибо. Сделала план запросов через "set showplan_all on", но там черт ногу сломает: 45 записей, куча полей, я все это записала как .csv, потом открыла Excel-ем, во-первых, Вам не послать и не выложить здесь, а во-вторых, даже неудобно, что кто-то будет тратить свое время, чтобы в этом разбираться...

> Павел Калугин © (17.01.07 13:53) [29]
> > [27] SLP © (17.01.07 13:52)
>
> а план запроса посмотреть дашь?

Я бы дала посмотреть скриншоты, но выкладывать некуда.

← →
Павел Калугин © (2007-01-17 14:45) [38]

> [37] SLP © (17.01.07 14:43)

народ, рапида, и так далее..

← →
Павел Калугин © (2007-01-17 14:47) [39]

http://slil.ru/

← →
SLP © (2007-01-17 15:28) [40]

> Павел Калугин © (17.01.07 14:47) [39]

Послала файл со скриншотами : "Это план запроса для Select и ХП.doc"
Посмотрите, пож-та.

← →
Павел Калугин © (2007-01-17 15:41) [41]

> [40] SLP © (17.01.07 15:28)

куда?

← →
Bless © (2007-01-17 15:55) [42]

> SLP © (17.01.07 15:28) [40]
>
> Послала файл со скриншотами : "Это план запроса для Select
> и ХП.doc"
>

Куда послала-то? И еще выложи, если не трудно, еще и "неудобный" csv-файл.
По картинкам ориентироваться конечно удобнее, но я как-то подозреваю, что план в ширину у тебя не влез в один экран, что неудобно. Да и клацнув мышкой по пиктограмме на скриншоте, дополнительная информация у меня не всплывет, как у тебя в Analizer-е. А в "неудобном" файле это все есть. :)
Может, это и не понадобится, но паузы между твоими появлениями тут довольно велики, поэтому на всякий случай прошу все сразу.

И еще, напиши, сколько записей в каждой из таблиц, участвующих в запросе.

← →
SLP © (2007-01-17 15:56) [43]

зашла на http://slil.ru/ - получился http://zalil.ru/, набрала browse - выбрала свой файл - и Send. Куда ушел мой файл я не знаю. Может что не так сделала?

← →
SLP © (2007-01-17 15:59) [44]

> Bless © (17.01.07 15:55) [42]

Сейчас подготовлю. Спасибо. Паузы - это работы другой много...

← →
Bless © (2007-01-17 16:06) [45]

после того, как залила, у тебя вверху страницы (у меня в Опере в добавок и в адресной строке тоже) будет адрес типа
http://slil.ru/23762505
Вот его сюда и скажи

← →
SLP © (2007-01-17 16:16) [46]

> Bless © (17.01.07 16:06) [45]

http://slil.ru/23762556 - здесь .CVS
http://slil.ru/23762577 - десь док с скриншотами, выложила их по-порядку, поэтому понятно будет, т.к. не умещающиеся рисунки сделала с повторением по краям.
В табл start_ssd - около 270000 зап.
В табл ves- 1971 записей. Это справочник судов.

← →
Павел Калугин © (2007-01-17 16:44) [47]

> [46] SLP © (17.01.07 16:16)

гут вечерком дома попробую смоделировать

← →
SLP © (2007-01-17 16:51) [48]

> ел Калугин © (17.01.07 16:44) [47]

Спасибо. Только жаль Ваше время

← →
Bless © (2007-01-17 17:05) [49]

в CSV и на картинках - разные планы выполнения. В CSV они одинаковы и для запроса, и для хранимки. А на картинке - разные.
К тому же, на картинках у тебя написано, что хранимка выполняется 5-8 мин. А судя по плану она занимает 0.08% от времени выполнения. Т.е. выполняется ГОРАЗДО быстрее запроса. Так что я думаю, твое утверждение "хранимка -5 мин, запрос - 2 сек" - неверно.
Вероятнее, что ты выполняла запрос непосредственно сразу после хранимки, я прав?
Подозреваю, что выполни ты запрос первым, а хранимку - сразу вслед за ним, получила бы противоположный результат (о чем план в картинках и говорит).
Я хочу сказать, что 2 секунды, может быть, получились из-за того, что сервер кешировал данные или что-то в этом духе (я не шибко силен) и этот результат - "нечестный" и запорачиваться по поводу "почему большая разница" не стоит.
А вот по поводу, "почему аж 5 мин" - стоим, имхо.

Что касается запроса:
поле start_ssd.id_ssd случайно не ключевое? Если да, то тогда (если я не ошибаюсь) один start_ssd из запроса можно выбросить:
select rtrim(ves.iki_ves)+" "+ rtrim(ves.board_number)+" "+rtrim(ves.ves) as name_ves,cast(convert(char(10), a.datetime,102) as datetime) as ssd_data, datediff(day,a.datetime,cast(convert(char(10),a.ssd_mail,102) as datetime))-1 as day_r,a.id_ssd, a.id_ves, a.ssd_mail from start_ssd a join ves on a.id_ves=ves.id_ves where a.ssd_mail>=@d_mail and a.ssd_mail<=@d_mail2 and a.processstatus not in (1,11) and a.mem in (21,31) and a.id_ves<>0 and datediff(day,a.datetime,a.ssd_mail)>=2 and not exists (select id_ssd from start_ssd where id_ves=a.id_ves and datetime=a.datetime and ssd_mail<a.ssd_mail) order by a.ssd_data, a.id_ves

Попробуй запрос из [49]. Результат работы должен быть таким же, как и старого запроса. А вот скорость... неуверен, но уж точно не медленнее.

> Bless © (17.01.07 17:05) [49]

Нет, первым я выполняла запрос, вторым ХП. На самом деле запрос -= 2 сек, ХП - вертится от 5 до 8 мин.
id_ssd - ключевое. С Вашим вариантом согласна.
Завтра с утра еще посмотрю планы запросов, но по - моему я все правильно послала. Сейчас домой надо идти.

SLP © (17.01.07 17:22) [51]

> Bless © (17.01.07 17:05) [49]

Нет, первым я выполняла запрос, вторым ХП. На самом деле запрос -= 2 сек, ХП - вертится от 5 до 8 мин.
id_ssd - ключевое. С Вашим вариантом согласна.
Завтра с утра еще посмотрю планы запросов, но по - моему я все правильно послала. Сейчас домой надо идти.

> Нет, первым я выполняла запрос, вторым ХП.

Я имел ввиду не когда ты проверяла текст из [15], а когда создавала ветку
У меня хранимая процедура на сервере отрабатывает около 5 мин. Помещаю этот же самый запроc в QA и он отрабатывает за 2 сек.

тут ты сначала выполняла запрос, а вторым ХП?

> На самом деле запрос -= 2 сек, ХП - вертится от 5 до 8
> мин.

Судя по плану, все с точностью до наоборот:
на 1-ом скриншоте:
Query3: Query cost (relative to the batch): 99.92% Query text: select rtrim(ves.iki_ves)+" "+ rtrim(ves.board_number)+....

на 4-ом скриншоте:
Query 4: Query cost (relative to the batch): 0.08% Query text: exec [ssd_delayed_period] @d_mail, @d_mail2

И раз уж согласна с моим вариантом, то выполни новый запрос (только запрос, без ХП) и скинь план пожалуйста (уже завтра, конечно).

<OFFTOP>
Ничего, что я "Ты-каю"?
</OFFTOP>

← →
b z (2007-01-17 18:03) [54]

попробуйте так

http://dotnetslackers.com/SQL/re-38060_SQL_Server_Query_Analyzer_Runs_Fast_Stored_Procedure_Runs_Slow.aspx

> Bless © (17.01.07 17:36) [53]

Приготовила Вам планы запросов с одним start_ssd. Хотела послать, но перед этим решила проверить как будет работать ХП с одним start_ssd.
Время выполнения 1 Сек!!!!
Так что дело в запросе, а не в сервере.
Виталий, большое Вам спасибо за внимание и помощь!
Павел! Вам тоже большое спасибо!

> SLP © (18.01.07 10:23) [55]
>
> Время выполнения 1 Сек!!!!

Откровенно говоря, даже не рассчитывал, что так легко все разрешится. :)
Ну да хорошо все, что хорошо кончается.

Да вроде не за что. Хорошо то, что хорошо кончается...

> Bless © (17.01.07 17:36) [53]

Окончательный вариант ХП сделала такой:
CREATE PROCEDURE [dbo].[ssd_delayed_period2] (@d_mail datetime, @d_mail2 datetime ) AS
-----Опоздавшие ССД за конкретный период
-----ССД, пришедшие на замену, опоздавшими не считаются.
------EXEC DBO.SSD_DELAYED_period2 "20070101","20070115"

BEGIN
select * into #start_ssd from start_ssd where mem in (21,31) and id_ves<>0
select rtrim(ves.iki_ves)+" "+ rtrim(ves.board_number)+" "+rtrim(ves.ves) as name_ves,cast(convert(char(10),
a.datetime,102) as datetime) as ssd_data,
datediff(day,a.datetime,cast(convert(char(10),a.ssd_mail,102) as datetime))-1 as day_r,a.id_ssd, a.id_ves, a.ssd_mail
from #start_ssd a
join ves on a.id_ves=ves.id_ves
where a.ssd_mail>=@d_mail
and a.ssd_mail<=@d_mail2
and a.processstatus not in (1,11)
---and a.mem in (21,31)
---and a.id_ves<>0
and datediff(day,a.datetime,a.ssd_mail)>=2
and not exists
(select id_ssd
from #start_ssd
where id_ves=a.id_ves
and datetime=a.datetime
and ssd_mail<a.ssd_mail)
order by a.ssd_data, a.id_ves

drop table #start_ssd

END
GO

Запустила последний раз в 9-00,в самое напряженное время, когда start_ssd эксплуатируется оч. напряженно, в нее постоянно добавляются и редактируются записи. ( эта табл весь раб день так занята операторами).
С вариантом, сначала временной табл., ХП отрабатывает за 10 сек.
С вариантом напрямую к start_ssd - крутится более 3 мин и я снимаю, чтобы не тормозить работу операторов.

> [58] SLP © (19.01.07 09:39)

ребята из Диасофта очень любят, дабы избежать блокировок, использовать конструкцию from table_name (NOLOCK), и так далее при выборке данных. Помогает, однако..

QA ВСЕГДА выполняет запрос быстрее, чем "обертка"+Jet
И было бы странно, если бы было наоборот ;)

> MsGuns © (20.01.07 13:12) [60]

Да. Но у меня эта ХП вставлена и в прогр на Delphi (компонент ADOStoredProc1). Так же долго выполнялась. Но посл. вариант через # стала выполняться в 3 раза быстрее...Пока так.

> Запустила последний раз в 9-00,в самое напряженное время,
> когда start_ssd эксплуатируется оч. напряженно, в нее постоянно
> добавляются и редактируются записи. ( эта табл весь раб
> день так занята операторами).
> С вариантом, сначала временной табл., ХП отрабатывает за
> 10 сек.
> С вариантом напрямую к start_ssd - крутится более 3 мин
> и я снимаю, чтобы не тормозить работу операторов.
>

хранимка, запущенная в 9-00 и просто запрос из QA, запущенный в это же время, отрабатывают одинаково долго? Или запрос, как и раньше, на пару порядков быстрее и имеет другой план выполнения?
Если все, как и раньше, то:

1)
может быть, совет из [54] - то, что нужно?
Более подробно этот вопрос (из [54]) освещен в статье
http://www.sql.ru/articles/mssql/2005/070704TechniqueForEnsuringPlanStabilityInSQLServer2000.shtml

2) сделай exec sp_recompile ssd_delayed_period и опять выполни запрос и хранимку с одинаковыми параметрами. Желательно делать это на копии базы, чтоб быть уверенным, что между sp_recompile и твоим вызовом хранимки не было вызова хранимки, инициированного каким-то пользователем (хотя если сделать все в одном батче ...exec sp_recompile... exec ssd_delayed_period... select, то вероятность этого будет невысокой наверное). Если и теперь планы выполнения будут разными, то я даже не знаю...
Если же планы стали одинаковыми, то, видимо, совет из [54] - таки хорош.

Если все вышесказанное - не подходит, то еще вопрос:
хранимка, запущенная не в час пик, отрабатывает так же долго?

По поводу хранимки со временной таблицей:

Может быть, я ошибаюсь, но я не вижу причин, по которым введение временной таблицы ускоряет выполнение твоей хранимки, состоящей из одного запроса. Не должно быть такой огромной разницы между вариантами с временной таблицей и без нее.
И блокировки таблицы start_ssd из-за активной работы тут ни при чем, имхо.
(Соответственно, опять же имхо, NOLOCK проблему не решит).
Ведь если запрос без # не может быстро отработать из-за блокировок, то заполнить временную таблицу ты тоже не смогла бы по причине этих же самых блокировок. А раз с этим проблем нет, то, видимо, дело не в блокировках start_ssd.

> Bless © (22.01.07 12:17) [62]

Я запускала ХП, когда таблицу уже никто не дергал. Отрабатывает также долго, как и в час пик. С # отрабатывает быстро, в час пик около 1 мин.
Дело в том, что start_ssd связана по id_ssd c 25 таблицами, которые в свою очередь связаны с справочниками. И получается, что когда я делаю сначала #start_ssd, а потом выполняется select, то #start_ssd уже чистенькая, без наследства в виде 25 табл + справочники.... Она забыла все свои связи.
Выходит так...
Всем спасибо.

SLP © (22.01.07 14:58) [63]

> Я запускала ХП, когда таблицу уже никто не дергал. Отрабатывает
> также долго, как и в час пик.

А просто запрос в Query Analizer-е тоже медленно работает? Или быстро? Меня очень интересует, осталась ли старая проблема, с которой начиналась эта ветка?

> С # отрабатывает быстро, в час пик около 1 мин.
> Дело в том, что start_ssd связана по id_ssd c 25 таблицами,
> которые в свою очередь связаны с справочниками. И получается,
> что когда я делаю сначала #start_ssd, а потом выполняется
> select, то #start_ssd уже чистенькая, без наследства в виде
> 25 табл + справочники.... Она забыла все свои связи.
> Выходит так...

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

В общем, тебе, конечно, решать, оставить все как есть или нет.
Но, имхо, эта ситуация (когда с # быстрее чем без) странная, и ее бы надо разрулить, а не обойти, всяко полезно на будущее.
Кроме того, 1 мин для запроса к таблицам твоих объемов - это неоправданно долго, на мой взгляд.

Скорей всего без # идет полное сканирование таблицы, а при выборке в # используется более простое условие, поэтому возможно работают уже и индексы. Из-за меньшего объема данных в # запрос работает тоже быстрее, даже невзирая на полное отсутстви индексов у #.

> Bless © (22.01.07 15:40) [64]
> Меня очень интересует, осталась ли старая проблема, с которой
> начиналась эта ветка?

Проблема осталась, причем старая процедура (без #) работает также долго как в час пик, так и тогда когда табл никто не дергает уже. Единственный раз, когда админ перезагружал сервер и были сняты все задачи, я неск раз запустила ХП (без #) и она отработала за 1 сек.
Сейчас с # отрабатывает быстро, в час пик около мин, в ост время 15 сек.
После всех этих практических проб, я все таки пришла к выводу, что при select-e такие обремененные табл тянут за собой все связи, лучше делать с #. Но я нигде этого не читала, это чисто практически, может я не права...

> После всех этих практических проб, я все таки пришла к выводу,
> что при select-e такие обремененные табл тянут за собой
> все связи, лучше делать с #. Но я нигде этого не читала,
> это чисто практически, может я не права...

Я на 99% уверен, что ты ошибаешься (1 % оставляю на "в мире нет ничего невозможного", на "человеку (мне) свойственно ошибаться" и на непредсказуемое влияние пятен на солнце на земную жизнь).

Посуди сама: раз старая проблема осталась (т.е. просто запрос в QA выполняется быстро, а аналогичная ХП - медленно), то как твой вывод с этим согласуется? Почему просто select быстро отрабатывает? Все связи ж остаются.

Совет из [54] пробовала?

> ess [67]

Хорошо, что я не выбрал себе ник Blass :)

> Bless © (23.01.07 09:50) [67]

54 попробовала. Сделала параметры так как в http://www.sql.ru/articles/mssql/2005/070704TechniqueForEnsuringPlanStabilityInSQLServer2000.shtml Сделала все как в статье, запускала и первоначально с 2007 годом, с параметрами определенными внутри ХП.
Не помогло, все также, ХП (из QA) без # работает около 6 мин. Запускала подряд неск раз. Это среднее время.
Из QA одновременно запускала select, отрабатывал 10-15 сек, ХП с # тоже около 15 сек. Так что не знаю, что там думает оптимизатор, но может новая версия SP к MSSQL поможет.

долго работает хранимая процедура Найти похожие ветки