8.2.15.310 (64) + MS SQL 2006 (64) + Win 2008 (64)

Непонятка 1. Режим совместимости 8.1.
Запрос выполняется в привилегированном общем модуле.
под пользователем с полными правами 88 секунд, под обычным пользователем 660 секунд.

Непонятна 2. Одна и та же база. Уже другой запрос. В режиме совместимости 8.1 выполняется за 17 секунд. В режиме совместимости 8.2.13 и без режима совместимости 240 секунд. Проверялось на 4-х компьютерах. При любых манипуляциях перезагрузки серверов, очистки кешей. Очередности замера. Последовательных замеров ситуация проявляется стабильно одинаково.


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

(0) это RLS - он такой

(1)
Если это по непонятке 1, то привилегированный же модуль. RLS должно игнорироваться

где-то я видел консоль запросов с замером времени проведения по подзапросам

(2) что тебе мешает профайлером или тех.журналом посмотреть запрос ?

(4) Это да. можно посмотреть. А вот почему при разной совместимости более чем на порядок тормозить начивает

(5) пляжи от печки,т.е. от запроса

ни хрена он не игнорирует
точнее да, но условия проверки вставляет, ну... концептуально делает примерно так:

ГДЕ Ссылка В (<<ДоступныеПоRLS>>) ИЛИ Истина

кстати, в 8.1 такого не было, имхо

(7)угу, с первый разобрались, жаль что они не игнорируют RLS

(6)Так проблема не в одном запросе, а во всех. И из-за смены совместимости провал в 14 раз. Я не могу на столько ускорить любой запрос, чтобы вернуться в тоже время.

(3)Да я ее знаю, но см (9)

(10) ну, может там есть типовой косяк

(11) Тогда он очень старый, пробовал и на 8.2.13.202 и на 8.2.15.310

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

(13)Одна и таже конфа. Включил 8.1 быстро, выключил - медленно. включил - быстро и т.д.
ладно всегда долго, можно улучшать. а что по разному, да еще настолько по разному.

(14) т.е. текста запроса не будет?

(15)Я не прошу помощи в улучшении конкретного запроса, хочу понять почему один и тот же запросов в разных режимах совместимости по скорости отличается в 10 раз. еще раз обращу внимание, что такое поведение торможения наблюдается на всех запросах.

(16) я же говорю - может там во всех запросах есть косяк, который не влиял на 8.1 и стал влиять на 8.2

(16) ну, только на твоих запросах, как оказалось. Поэтому и просят запрос для примера. Что у вас там за чудные запросы? Самописка?

ну и применяемые шаблоны RLS :)

(17)(18)Сейчас выберу запрос, но проблема шире

(19)Тестилось под Полными правами

(21) -> (7)

(22)В (7) то про первую проблему, а после (8) разбирается вторая проблема. котоаря уже под полными правами

На данный момент ситуация следующая. Без режима совместимости 8.1 выполнение запросов с большой вложенностью деградирует.
Да, запросы кривые, но на лицо глюк платформы, жаль нет ИТС отписать разработчикам.

(24) проверь вот такую вещь (ну, подобную :) )

ВЫБРАТЬ
   ПоступлениеТоваровТовары.Номенклатура.Наименование
ИЗ
   Документ.ПоступлениеТоваров.Товары КАК ПоступлениеТоваровТовары

СГРУППИРОВАТЬ ПО
   ПоступлениеТоваровТовары.Номенклатура.Наименовани

в 8.1 - отсортировано получается, а в 8.2?

Вот замер в совместимости 8.1 http://screencast.com/t/vMkA6xdJIv25
Вот без него http://screencast.com/t/Wo5FNqvM

запрос в строке 827 как был 5 сек так и остался, а запрос в строке 1776 в 100 раз дольше делался

(26) так давай запрос из строки 1776 :)

(27) http://hostex.org/dl/94bffc0450

(28) эт что?

выложи на pastebin

(30)http://pastebin.com/dJD0JvQu

(31) непонятно, почему в 8.1 не тупило :) замени все вложенные запросы на временные таблицы, особенно места с виртуальными таблицами типа                    РегистрНакопления.ЗаданияНаВыпуск.Остатки(, ) КАК ЗаданияНаВыпускОстатки
                           ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений._ВременныеНормыПроизводства.СрезПоследних КАК _ВременныеНормыПроизводстваСрезПоследних
                           ПО ЗаданияНаВыпускОстатки.ЗаданиеНаПроизводство.Подразделение = _ВременныеНормыПроизводстваСрезПоследних.Подразделение
                                   И ЗаданияНаВыпускОстатки.Номенклатура = _ВременныеНормыПроизводстваСрезПоследних.Номенклатура
                                   И ЗаданияНаВыпускОстатки.ХарактеристикаНоменклатуры = _ВременныеНормыПроизводстваСрезПоследних.ХарактеристикаНоменклатуры
                           ЛЕВОЕ СОЕДИНЕНИЕ Справочник.СпецификацииНоменклатуры КАК СпецификацииНоменклатуры
                           ПО ЗаданияНаВыпускОстатки.Спецификация.Код = СпецификацииНоменклатуры.Код
                                   И (ПОДСТРОКА(СпецификацииНоменклатуры.КодВерсии, 2, 4) = ПОДСТРОКА(ЗаданияНаВыпускОстатки.Спецификация.КодВерсии, 2, 4))
                                   И (ПОДСТРОКА(СпецификацииНоменклатуры.КодВерсии, 1, 1) <> "9")
                                   И ((НЕ СпецификацииНоменклатуры.ПометкаУдаления))


Лучше получение данных из виртуальных таблиц пихнуть отдельно во временные, а потом их уже слеплять

ну и сначала отбирать по первой таблице, а потом к ней уже лепить

судя по всему - тяжелое наследие 8.0

(34)спасибо конечно, но вопрос не в помощи оптимизации запроса, а понять почему деградация при отмене совместимости

(35) поменяли способ получения виртуальных таблиц из физических, например

(36) от чего оптимизатор заплющило

(36) Потому что 1С!

Хреново, что в обоих случаях сделали хуже, а не лучше

(39) может оно стало работать быстрее, просто скуль вложенные запросы совсем не любит и в данном случае его стало срубоать на тэйбл скан

сравни скорость получения среза последних в 8.1 и 8.2

(25)Кстати нормально выполнился

(41) нормально - в смысле результат отсортирован (опбрати внимание - у меня получаются наименования)?

(42)Там же нет сортировки почему должно быть отсортировано?

(43) а это я туплю :) оно только на файловой так

Я нашел геморой, который медленно работает.
один запрос соединяется с регистром сведений Значения свойств объектов и там одно из условий соединения (ЗначенияСвойствОбъектов.Объект ССЫЛКА Документ.ЗаказПоставщику)
которое в контексте к тому же бессмысленное

кто-то может объяснить почему в совместимости 8.1 и без нее такая проверка работает по разному?

да, а уменьшение вложенности с помощью временных таблиц ситуацию не изменило

(45) видимо в 8.1 это поле входит в индекс, а в 8.2 - нет

(47) я имею ввиду _tref в скуле

Но с режима совместимости 8.1 в режим совместимости 8.2.13 переключается без реструктуризации. даже динамически может. а уже тормозит

а покажи запрос с уменьшенной вложенностью?

вообще - если скорость запроса не устраивает, то нужно разбить его на маленькие части и курить индексы. данные о них можно получить через ПолучитьСтруктуруХраненияБазыДанных()

(50)Вложенность не минимальна. Но скорость уже устраивает и нужно переходить к следующему запросу.

(51)Это я умею. неожиданно, что разное поведение 1с

(45) А может быть все-таки не Объект Ссылка ... виновато,
а именно разименование Объект.Реквизит ?
например, вот у человека была проблема с RLS http://www.miko.ru/blogs/metalblog/129/ из-за составного типа.

(54)У тестового пользователя только полные права, других ролей нет, в роли Полные права RSL не настроены

(54) да нет, корень всех зол в том, что оптимизатор растаращило, а в 8.1 способ получения вирт. таблиц был другой, видимо, проще и оптимизатор по совокупности переваривал. надо просто сравнить запросы в скуле ипланы выполнения через профайлер скульный

Я разобрался с непоняткой 1

Высказывание (7) имеет место быть, только если в привилегированном режиме в тексте выполняемого запроса есть слово РАЗРЕШЕННЫЕ.

Если РАЗРЕШЕННЫЕ нет, то RSL игнорируются