1С8.3 При применении отбора в СКД сильно тормозит вывод в Табличный документ #752681

Доброго времени суток. Есть отчет написанный на СКД, без указания отборов формируется достаточно быстро, при указании отбора - время формирования увеличивается в 10 раз (40 минут против 30-40 секунд), причем на другом сервере 1С все отрабатывается нормально и с отбором и без Что выяснил - сам запрос из СКД формируется 5-7 секунд - при выставлении одного конкретного отбора начинаются дичайшие тормоза и занятие SQL сервером 100% процессорного времени Количество строк к выводу порядка 30 тысяч предполагаю на ночь запустить тестирование и исправление. непонятки начались после перехода с 8.2.19 на 8.3.6 Вопрос, может подскажите, в какую еще сторону порыть?

40 минут против 30-40 секунд — это в 10 раз, да, так и есть.

Ты, главное, не вздумай здесь сам запрос писать.

в 10 - имелось в виду в 10ки раз. А запрос сам, весьма простой. По существу подскажете что-нибудь?

Мда, кто бы мог подумать. По существу думаю, что проблема весьма простая. Решение, кстати, уверен, тоже весьма простое.

Слушай ты как маленький. Если хочешь разобраться - смотри профайлером план запроса, сразу понятно будет что грузит скуль

Вам ребят что, язвительности в детстве прелелили что ли? Нет ответов - топайте мимо, не засоряйте эфир. Вопрос был к тем, кто с подобным сталкивался, а не к тем, у кого свободного времени много.

Что такое прелелили? Ответов при твоем партизанском поведении не будет. Телепаты нынче дороги.

для начала посмотреть какой получается текст запроса после наложния фильтров. Например, через zaprosnik.skd

Можно еще обслуживание базы провести

ИС-2 сенкс за конструктив, обслуживание в ночь будет.

Чем тебе не конструктив?

Попробуйте пригласить специалиста 1с

надо еще смотреть, что за отбор. А то вдруг имеет конструкцию Реквзит.Реквзит1.Реквзит2 и т.д, где Реквзит имеет составной тип

Да все что угодно может быть. Может статистика не обновляется и т.д. Если нужно разобраться ток план запроса в этом поможет

На сколько я помню, отборы на уровне СКД, если оптимизатор не перенесет в запрос (если запрос компановки сложный, то он этого не делает), делаются уже не на сервере БД, а на сервере приложения, те построчно сравнивается детальная запись и условия. МБ просто сервер слабый? Или реально составной тип или много отборов. или все вместе.

1. Сам запрос в консоли запросов по времени формируется нормально. 2. Ситуация с тормозами существует только в одном офисе, в другом такой проблемы нет и все отрабатывает быстро. 3. Отборов класса Реквизит.Реквизит.Реквизит ... в СКД нет 4. Если надо выложить текст запроса - то могу и выложить, но он крайне простой вида Выбрать * ИЗ, просто по значительному объему данных 5. Возможности скачать zaprosnik.skd, к сожалению нет, на инфостате доступа не имею.

какая каша у тебя в голове

то, что я выяснил - это то, что без отборов отчет выполняется меньше чем за минуту с установленным отбором (в результате получается 30 000 строк) выполняется 40 минут и появилось все это после перевода с 8.2 на 8.3, до этого этот же отчет работал нормально. PS кэш почистил в первую очередь

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

про профайлер понял уже, ковыряюсь спасибо

В частности длительное выполнение может быть вообще не связано с самим текстом запроса, например может быть не выполняются регламентные операции обновление статистики, реиндексация и т.д.

Вопрос решился тестированием и исправлением, как и предполагалось