Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 208 ошибка и оптимизация. Вопрос  [new]
nik_
Member

Откуда: EpicRus
Сообщений: 8
Суть вот в чем :
Пример упрощенный.
Имеем процедуру П1 из которой зовется процедура П2. При этом в П1 создается таблица #temp_P1, а в П2 создается таблица #temp_P2 и используется #temp_P1 для INSERT в #temp_P2. При этом этот INSERT происходит в цикле по записям из #temp_P1.
Так вот при выполнении всего этого хозяйства в Profiler -е вижу множество Exeption: 208. при каждом обороте цикла и на каждое такое сообщение тратится SQL-сервером около 1 сек., что приводит на больших обьемах данных к десяткам часов!
Как я понял из документации для оптимизатора запросов SQL сервера есть некий "порог срабатывания" при превышении которого он (оптимизатор) решает рекомпилировать процедуру("recompile threshold for a query"). И в процессе этой рекомпиляции он "невидит" обьектов, созданных ранее, и сыпит этими сообщениями!!! Так вот запретить ему это делать можно хинтом "KEEP PLAN".Т.е. получается, что рекомпиляция происходит не всей процедуры, а начиная с момента где произошло первышение этого "порога срабатывания" и до конца процедуры.
Вопрос вот в чем: Что это за "порог срабатывания" и как им можно управлять?
5 ноя 03, 11:17    [406944]     Ответить | Цитировать Сообщить модератору
 Re: 208 ошибка и оптимизация. Вопрос  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Сам подход не из лучших. Не использовать ли TABLE - переменную и не передавать ли открытый курсор на нее?
Это 100% уберет временную таблицу, созданную вне объекта как причину рекомпиляции.
Надеюсь, динамических запросов там нет? :)
5 ноя 03, 13:19    [407256]     Ответить | Цитировать Сообщить модератору
 Re: 208 ошибка и оптимизация. Вопрос  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Фигню спорол. Курсор можно только вернуть из процедуры, передать в нее - нельзя :( Одна рекомпиляция будет в любом случае. Чтобы их не было много, надо, действительно, использовать option (keep plan) при обращении к "внешней" таблице. Тогда - одна рекомпиляция на один вызов "внешней" (оберточной) процедуры (той, в которой создается таблица, по которой елозит вторая проца) :(

Вот мой пример, на котором смотрел:

alter procedure p1

as

create table #a ( id int )
insert into #a select top 10 id from sysobjects

exec p2
exec p2
exec p2
return

alter procedure p2

as

declare @i int

create table #b ( id int )

select @i = 0

while @i < 3 begin
select @i = @i + 1

truncate table #b

insert into #b select id from #a
option (keep plan)

end

select * from #b
return


Естественно, пример достаточно упрощен, но без option (keep plan) рекомпиляции при каждом обращении к #a.
5 ноя 03, 13:42    [407308]     Ответить | Цитировать Сообщить модератору
 Re: 208 ошибка и оптимизация. Вопрос  [new]
nik_
Member

Откуда: EpicRus
Сообщений: 8
Проблема в том , что иногда оптимизатор "пилюёт" на хинт KEEP PLAN, как и на другие. Когда это происходит мне непонятно... и вообще сложилось впечатление, что этот оптимизатор запросов - "черный ящик", точно понять, а тем более предсказать и управлять его рабоой нельзя. Обидно, млин...
13 ноя 03, 12:13    [416232]     Ответить | Цитировать Сообщить модератору
 Re: 208 ошибка и оптимизация. Вопрос  [new]
nik_
Member

Откуда: EpicRus
Сообщений: 8
Стиль программмирования принятый в моей компании не предполагает использования курсоров, кроме того, использование временных таблиц ускоряет работу процедур и запросов.
Далее...
Мои исследования показали, что превышение этого "порога срабатывания" оптимизатора запросов (после которого он рекомпилирует батч) каким-то образом связано с процессом накапливания статистики по полям таблиц. Кроме того, сбор этой статистики сам по себе также приводит с существенным потерям в производительности(сообщения в Profiler-е "SELECT STATMAN[....]". На них тратится от 10 до 1000 милисекунд. Отключить сбор статистики удавалось конструкцией "CREATE STATISTICS hist_stat1 ON #temp(поле) WITH NORECOMPUTE".
Просвятите, гуру, или ткните носом где прочитать про эти процессы.
(Шибко мешают на обьемах БД под 10 ГБ.)
13 ноя 03, 16:07    [416953]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить