Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 ПОМОГИТЕ!!! - Провал производительности  [new]
ShD
Member

Откуда: Киев
Сообщений: 31
Hi, All!
Столкнулся с явлением, которое ни объяснить ни побороть не могу :(
SP с ростом таблиц начали резко тормозить.
Обновление статистик, перестроение индексов не помогает

Запросы типовые :
select
d.cd_Good,
d.pr_doc,
depart.cd_depart,
sum(d.quantity ) as number
from header h
inner join document d on d.cd_header = h.cd_header
inner join stGood on stGood.cd_good = d.cd_good
inner join depart on depart.cd_depart = h.into_depart
where
h.dt_in between @dt_begin and @dt_end
and (stGood.cd_group=@group or @group = 0)
and h.from_depart <> h.into_depart
and h.cd_doc <> 15
and (depart.type_depart = 2 and (Depart.cd_depart=@depart or @depart = 0))
group by d.cd_good, d.pr_doc, depart.cd_depart

union all

........

Далее еще 3-4 аналогичных SELECT
Таблица document порядка 2 млн записей, остальные существенно меньше
Вся беда в том, что запрос, выдернутый из процедуры в QA выполняентся с приемлемой скоростью. Процедура тормозит в десятки раз. Перекомпиляция процедуры тоже ничего не дает. Железо слабое, получить план запроса от процедуры проблематично (из-за времени выполнения). На тесте с небольшим количеством данных все ОК! и планы приличные.

Подайте хоть какую то идею

Александр
12 май 03, 22:16    [196268]     Ответить | Цитировать Сообщить модератору
 Re: ПОМОГИТЕ!!! - Провал производительности  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Индексы?

Количество пользователей?

Блокировки?

Как со всем этим?
12 май 03, 22:20    [196270]     Ответить | Цитировать Сообщить модератору
 Re: ПОМОГИТЕ!!! - Провал производительности  [new]
ShD
Member

Откуда: Киев
Сообщений: 31
Индексы, блокировки ни при чем, из QA bce летает, пользователей раз-два и обчелся - база разработчиков
12 май 03, 22:24    [196271]     Ответить | Цитировать Сообщить модератору
 Re: ПОМОГИТЕ!!! - Провал производительности  [new]
AM
Guest
Такой дерзкий, но банальный вопрос, может надо сервак перегрузить? :)
12 май 03, 22:43    [196272]     Ответить | Цитировать Сообщить модератору
 Re: ПОМОГИТЕ!!! - Провал производительности  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Ну так план нужен - мало ои как в QA работает, процедура - это другое
12 май 03, 23:30    [196286]     Ответить | Цитировать Сообщить модератору
 Re: ПОМОГИТЕ!!! - Провал производительности  [new]
Lexis
Member

Откуда: Moscow
Сообщений: 1737
а в QA запрос выполняется с UNION ALL али без?
12 май 03, 23:39    [196292]     Ответить | Цитировать Сообщить модератору
 Re: ПОМОГИТЕ!!! - Провал производительности  [new]
rifat
Member

Откуда:
Сообщений: 6
Попробуй сделать индексированный вьюв, из всех селектов (или из самого большого) затем делай выборку из него по условию. Я получил примерно дестикратное увеличение скорости, но не увлекайся при увеличении кол-ва ИВ можно получить большие тормоза на вводе данных.
13 май 03, 07:30    [196355]     Ответить | Цитировать Сообщить модератору
 Re: ПОМОГИТЕ!!! - Провал производительности  [new]
Crimean
Member

Откуда:
Сообщений: 13148
2 rifat
А версия сервера часом у тебя не Етрерпрайз?
А то индексы на представления оптимизатором в стандарте не подхватываются.
13 май 03, 11:13    [196648]     Ответить | Цитировать Сообщить модератору
 Re: ПОМОГИТЕ!!! - Провал производительности  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
Железо слабое, получить план запроса от процедуры проблематично (из-за времени выполнения). На тесте с небольшим количеством данных все ОК! и планы приличные.

То есть не удается получить план выполнения на реальных данных??? Причем тут время выполнения, если ты тока план хочешь получить??? Если производительность зависит от объема данных, значит планы должны тоже отличаться. Наверняка оптимизатор сваливается на TableScan. Может попробовать вместо UNION ALL нескольких запросов создать временную таблицу, несколькими инсертами загнать туда то, что выбирается между UNION ALL и потом одним селектом вернуть клиенту.
13 май 03, 11:23    [196664]     Ответить | Цитировать Сообщить модератору
 Re: ПОМОГИТЕ!!! - Провал производительности  [new]
Crimean
Member

Откуда:
Сообщений: 13148
2 pkarklin

Очень часто план предположительный отличается от плана реального. А если есть временные таблицы, то предположительный план вообще не строится.
Так что лично я сторонник получения планов от выполнения.
А тормозит, скорее всего, из-за того, что нет высокоселективного критерия отбора данных и сервак с увеличением количества данных приходит в уныние от статистик и начинает тупо перемножать таблицы и сканить результат.
Плана можно и не дождаться в таком случае. Эт точно.
13 май 03, 11:48    [196701]     Ответить | Цитировать Сообщить модератору
 Re: ПОМОГИТЕ!!! - Провал производительности  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
2 Crimean

Очень часто план предположительный отличается от плана реального

Вот это вот можно по-подробней прокоментировать. Что значит
предположительный
план и план
реальный
?
13 май 03, 12:00    [196719]     Ответить | Цитировать Сообщить модератору
 Re: ПОМОГИТЕ!!! - Провал производительности  [new]
ziktuw
Member

Откуда:
Сообщений: 3552
вместо многократного union all делай многократный слив во временную таблицу с последующим селектом из неё. часто помогает. При этом во времянку можно сливать не готовые для показа данные, а только ключи и агрегаты, а при селекте сджойнить со справочными таблицами. Это позволит резко уменьшить кол-во данных, маслаемых в tempdb.
13 май 03, 12:08    [196730]     Ответить | Цитировать Сообщить модератору
 Re: ПОМОГИТЕ!!! - Провал производительности  [new]
ShD
Member

Откуда: Киев
Сообщений: 31
Hi!
Сейчас буду получать планы...
Перегрузка сервера не помогает, как ускорить выполнение запроса - я способ знаю, называется он динамический SQL, но запросов таких несколько десятков и все переписывать :( ?

Сервер у меня не ентерпрайз - индексированные представления не катят. Есть две версии - стандарт и МСДЕ - ведут себя одинаково. Обе без СП. Может ли установка СП помочь, может кто встречался с аналогичной проблемой?

Переделка запросов - самое нехорошее, кусочек который я привел, это всего лишь часть большой процедуры отчета (оборотка). Клиенту в итоге приходит пара десятков строк. Вопрос не в этом - почему оптимизатор так промахивается. Что мне теперь, хинты распихивать во все процедуры? Так я окончательно поседею за этим занятием :(

52 минуты уже крутится один вырезанный SELECT - из QA - 31 СЕК !!!

Александр
13 май 03, 12:22    [196757]     Ответить | Цитировать Сообщить модератору
 Re: ПОМОГИТЕ!!! - Провал производительности  [new]
Crimean
Member

Откуда:
Сообщений: 13148
2 pkarklin

Говоря терминами QA есть Ctrl/K (реальный план выполнения) и Ctrl/L (ожидаемый план выполнения)
Они ОЧЕНЬ часто не совпадают.

2 ShD

Я бы начал все же с установки СП3. Потом - попробовать найти разницу между запросом в QA и запросом в процедуре. К слову

declare @value mytype

select @value = ...
select * from mytable where field = @value


и

select * from mytable where field = ...


это совсем разные запросы.
И оптимизатор обрабатывает их по-разному.
13 май 03, 12:36    [196786]     Ответить | Цитировать Сообщить модератору
 Re: ПОМОГИТЕ!!! - Провал производительности  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74925
2 Crimean

Ладно, понаблюдаю. Я этого не замечал. А может не предавал значения. Но вот тока в BOL в описании SET SHOWPLAN_ALL я не нашел упоминания, что план выполнения приблизительный.

И тогда как же работает оптимизатор. Ну послали мы ему запрос, построил он план выполнения (если стоит SET SHOWPLAN_ALL, то здесь все и закончилось), начал его выполнять и что, он теперь начинает менять план, раз ты говоришь что планы отличаются. Ткни, пожалуйста, меня носом в BOL, где это написано. Или ты под приблизительными данные имеешь ввиду EstimateRows, EstimateIO, EstimateCPU, EstimateExecutions? Если так, то да. Эта статистика приблизительная. Но и без этих цифр (без SET STATISTICS...) можно увидеть в каком месте тормоза, TableScan, например, если дождаться выполнения нет возможности.
13 май 03, 12:59    [196833]     Ответить | Цитировать Сообщить модератору
 Re: ПОМОГИТЕ!!! - Провал производительности  [new]
Crimean
Member

Откуда:
Сообщений: 13148
2 pkarklin

По поводу ожидаемого и реального планов. Я давно перестал ориентироваться на ожидаемый. Сначала - из-за использования временных таблиц, потом - из-за несоответствия реальному.
Почему они отличаются - не знаю, но факт остается фактом. Возможно, не у всех, запросто может быть, что все определяет характер распределения данных и способ построения статистик...
13 май 03, 13:46    [196952]     Ответить | Цитировать Сообщить модератору
 Re: ПОМОГИТЕ!!! - Провал производительности  [new]
ShD
Member

Откуда: Киев
Сообщений: 31
Ну вот, дождался все таки :)

Планы совершенно разные, другой порядок соединения таблиц, другие способы соединения, другие размеры промежуточных выборок - все другое.
Это то я понимаю, я не понимаю, как с этим бороться :(
@^!$#@&*$@# MS и БГ

Ну, не расставлять же мне туевы кучи хинтов во все запросы
13 май 03, 13:47    [196955]     Ответить | Цитировать Сообщить модератору
 Re: ПОМОГИТЕ!!! - Провал производительности  [new]
Курков Михаил
Member

Откуда: Москва
Сообщений: 34
Можно попробовать обернуть запросы в процедуре в Exec("select ...").
На версии 6.5 по-крайней мере помогало.
13 май 03, 14:28    [197039]     Ответить | Цитировать Сообщить модератору
 Re: ПОМОГИТЕ!!! - Провал производительности  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Ну, не расставлять же мне туевы кучи хинтов во все запросы

Как раз именно это и делать - а ты думал, сервер за тебя работать будет? А программист на что? :)
13 май 03, 14:41    [197070]     Ответить | Цитировать Сообщить модератору
 Re: ПОМОГИТЕ!!! - Провал производительности  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Ну, не расставлять же мне туевы кучи хинтов во все запросы

Как раз именно это и делать - а ты думал, сервер за тебя работать будет? А программист на что? :)
13 май 03, 14:41    [197071]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить