Вопросы по запросу и скорости выполнения
 

Добрый день.
УТ типовая 10.3
1С 8.3.6
SQL 2008 (так же пробовал файловый вариант)
В типовой УТ10, при списании партий по сериям выполняется запрос, в котором выбираются записи из РС Списанные товары и внутренним соединением цепляется остатки по РН Партии товаров на складах.
Выполнение этого запроса в консоле запросов длится 17 сек.
По отдельности запрос по РС и по РН выполняются моментально. В результате выполнения запроса по РС - пару десятков строк, по РН - около 7К строк.
Почему так много по РН лучше не спрашивать, знаю что это не нормально, но в данный момент это не играет роли, вопрос о другом.
Так как запросы по РС и РН выполняются моментально, следовательно тормозит внутреннее соединение.

По началу пытался сделать через левое соединение - результат по прежнему 17-18 сек.
Тут зачем то я решил запрос по РН вынести в отдельные временные таблицы и только после этого присоединить ее к РС. Скорость выполнения 3 сек!!!
Все равно долго, но уже в 6 раз быстрее чем было
По замера производительности, общая скорость перепроведения реализаций с начала года стало в два раза меньше.

Кто сможет объяснить мне, почему так происходит.

Сам запрос, если кого интересует, то его можно посмотреть в УТ10.3 в общем модуле УправлениеЗапасамиПартионныйУчет в процедуре: ЗаполнитьЗапросПартийНаСкладахУпр

Вопрос что там с RLS в типовой. Я в свое время полностью их перелопачивал, чтоб убрать самые явные тормоза. И еще, при записи и простом чтении конструкции В и СОЕДИНЕНИЕ работают с разной скоростью. При чтении В быстрее, при записи наоборот.

РЛС не использую, точнее они прописаны местами но отключены в константах, так что думаю это сильно не должно повлиять на чтение. Да и к тому же по отдельности запросы к каждому из этих РС и РН выполняются моментально, проблема только в соединении.
Так же заметил, что в некоторых случаях, намного быстрее отрабатывает запрос, если соединение строится не к самой таблице с огромным количество данных, а к временно таблице, в которую предварительно делается выборка из нужной таблицы.

Например запрос ниже выполнится быстрее, если выборку по номенклатуре и выборку по остаткам выбрать в 2 разные временные таблицы, а затем уже эти таблицы соединить.

Выборка Спр.Ссылка, РН.КоличествоОстаток
из Справочник.Номенклатура КАК Спр
Левое соединение РегистрНакоплений.ПартииТоваровНаСкладах(&Дата,Номенклатура в (&КакойТоСписок) и склад=&склад) КАК РН
По Спр.Ссылка=РН.Номенклатура
Где КакоеНибудьУсловиеПоНоменклатуре

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

пакетные запросы вам в помощь! много нового узнаете, посмотрите видео от Павла Чистова про запросы например.

глянь получившиеся запросы и их планы в профайлере

[quote=angro;40906396]глянь получившиеся запросы и их планы в профайлере[/quote]
Ага, такое впечатление, что сперва вся таблица соединяется с целой таблицей, а потом только результат фильтруется. А не наоборот.

Такое чувство что тупит сам скуль.
Копию базы дома развернул на 12 скуле.
Теперь запрос выполняется доли секунды.
На серваке, ночью, когда ни кто не работает, на сотню документов при восстановлении партий было порядком 60-65 выполненных запросов и по времени все это занимало около 60-65 сек(34%)
На домашнем компе то же самое восстановление партий: выполнение запроса - около 2, на первом месте запись регистров.
Так что думаю надо скуль на сервере шевелить, проблема лишь в том, что тут крутится множество семерочных баз, которые должны быть доступны чуть ли не 24 часа в сутки :-(

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

Скачал тест Гилева.
Результат плачевный, 14.66, производительность ниже плинтуса, скуль 2008, рейд 10 на wd RE
На домашнем компе тест выдал чуть больше 30, скуль 2012, файловая система - wd синенький.
Частота памяти и объем совпадают, частота процессора почти совпадает, на серванте в двое больше ядер.
Куда рыть то, где смотреть. Не уж то и правда со скулем что то сделали на сервере, что он так тупит на выборках?
Переустанавливать скуль на сервере как бы не хотЦа, т.к. во первых это придется делать ночью, а во вторых 2008 скуль подружили с 1С77, и яне уверен что у меня все гладко получится сделать с 2012 скулем, что бы 1С 77 взлетела. А если за ночь скуль не взлетит, то меня утром просто вздернут на рее.

[quote=Jimbo;40918096] есть рекомендуемые регламентные операции, делаешь план обслуживания и выбираешь для каких баз. [/quote]
Планы обслуживания ежедневно стартуют по ночам для всех БД. К тому же восьмерочная база, с которой я сейчас вожусь, она только-только залита на скуль из DTшника.

ДА, забыл упомянуть, разные версии самой платформы, на сервере 8.3.6, на домашнем 8.3.7
Сейчас попробую накатить последнюю версию платформы на сервер и попробовать по новой тестирование запустить, но думаю результат это вообще ни как не изменит.

изучать блокировки SQL - кто то же тупит

Переходите на 1С77. SQL.

почему 8.3?
8.2 ставь

Таки (4) сделано? Что в планах?

В планах (12).