Выполнение запроса в клиент серверном варианте в сотни раз длительнее файлового #704641

Один и тот же запрос выполняемый в файловом варианте меньше чем за 1 минуту - в клиент серверном варианте выполняется больше трех часов. Запрос вызывается при проведении документа Расчет себестоимости. Запрос типовой. Обслуживание базы данных средствами SQL выполняется ежедневно - перестроение индекса, обновление статистики.

Прошу помочь найти причину

УПП 1.3 для Украины MS SQL 2012 1С:Предприятие 8.2 (8.2.19.83)

Я вряд ли помогу, но точно ли именно запрос? Отладчик в каких местах показывает такое дикое время?

РезультатЗапроса = Запрос.Выполнить;

И в копии тоже?

да

А нас самом скуле статистику не смотрел?

сформировал встроенный отчет "Физическая статистика индекса"- изучаю, есть некоторые рекомендации по перестроению индекса. Попробую отпишусь. Что еще посмотреть?

давай текст запроса

Текст запроса (в отладчике): ВЫБРАТЬ     РегЗатраты.Затрата,     РегЗатраты.ХарактеристикаЗатраты,      РегЗатраты.НалоговоеНазначение,              РегВыпуск.СчетУчетаНЗП,         ГДЕ             РегВыпуск.Период МЕЖДУ &НачДата И &КонДата             РегВыпуск.Заказ ГДЕ     РегЗатраты.Период МЕЖДУ &НачДата И &КонДата     И РегЗатраты.Активность     И РегЗатраты.КодОперации В (&КодыОпераций)     И (РегВыпуск.КоличествоВыпуск = 0 ИЛИ РегВыпуск.КоличествоВыпуск Есть NULL)     И (РегЗатраты.Количество <> 0 ИЛИ РегЗатраты.Сумма <> 0     РегЗатраты.Заказ

Очистка процедурного кэша-перестроение индексов-обновление статистики делал? Какая модель базы? Шринк и все такое....

Скуль по памяти как настроен?

+ запрос типовой, пробовал переделать на временные таблицы - ждал более часа, запрос не выполнился.

Отлавливай запрос в том виде, как его исполняет sql, и смотри план запроса. Скорее всего, там что-то вроде nested loop при соединении с большой неселективной выборкой..

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

шринк и Очистка процедурного кэша не делается, остальное по расписанию ежедневно

попробую с индексом, отпишусь

сколько памяти сжирает при этом? индекс тут по ходу не причём

Запусти по сети запрос в файловом варианте

странный запрос не использующий виртуальные таблицы при этом у одного регистра фильтруются записи по Активности, у второго нет

с сетью чета

и вот такие условия по неиндексированным полям гарантируют полный скан таблицы (я так понимаю ресурсы неиндексированы)

запрос чуть поправить нужно, вложенный запрос из левого соединения во времянку нужно

ресурсы неиндексированы чиво, чиво ???

что конкретно смущает?

Скулю может оперативы не хватает, как ктото выше писал, Помню у меня с этим проблема была, правда разница не с минуты в 3 часа, а с 0.2 сек до 1.5 сек)

В итоге добавили оперативы (и физически и в скуле) и стало < 0.1

план запроса пробовал строить?

оперативы хватает, 40 гб скулю

нет, как это?

в профайлере во время выполнения запроса нужно отловить событие Perfomance/Showplan statictic profile и Perfomance/Showplan text (который ты можешь показать здесь)

трассировку с указанными событиями запустил, как отловить нужные? их там очень много

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

способы разные есть один из - понять какой у тебя SPID и либо заранее накладывать фильтр на SPID либо потом просматривать один из простых способов получить SPID выполнить в консоли что то типа ВЫБРАТЬ    11222333 найти строку 11222333 и посмотреть какой там SPID

я по имени базы обычно фильтрую, ибо такой садомией занимаюсь на тестовых базах, там окромя меня никого нет)

+ только это можно увидеть в событиях RPC:Completed или SQL:BAtchCompleted

ну я грю, что способы зависят от ситуации

Переделал все типовые тормозящие запросы на запросы с временными таблицами с индексированием всех полей временных таблиц, проблема производительности запросов в СУБД MS SQL исчезла. Насколько я понял, проблема была в том, что оптимизатор запроса SQL не может корректно составить план выполнения запроса в котором используются соединения с подзапросами. Использование в запросах временных таблицы с индексированием полей решают эту проблему

Именно про это недавно на курсах говорили: скуль не может оценить объем данных вложенного запроса и строит неверный план запроса. С временной таблицей скулю проще.

По идее, здесь должна платформа 1с подключаться. Ввели бы опцию на уровне сервера 1с "по возможности подавлять nested loop", чтобы сервер 1с выдавал нужные хинты при формировании запросов к sql-серверу..

Ну или эвристику придумать какую-нибудь..

Можно попробовать сделать дополнительные индексы средствами sql сервера 1. В SQL server management studio открываешь activity monitor 2. Разворачиваешь recent expensive queries 3. Сортируешь по полю average duration 4. На самом длительном запросе нажимаешь правой кнопкой и выбираешь show execution plan 5. Ищешь действия у которых большая стоимость (cost) 6. Нажимаешь на них правой кнопкой и там обычно есть "missing index detail" (если нет - то уже есть необходимый индекс) и у тебя появляется текст запроса для создания индекса, который облегчит выполнение этого запроса.

просто у разрабов платформы И у разрабов конфиг непонятки друг с другом

видимо, там дело не в индексах было, а в левом соединении походу он как-то в трансляции жахнул не на левое а на В (Таблица)

индексы в целом не так страшно, как кривая трансляция

КодКонвертации,  Организация - есть индексы?

при нажатии show execution plan SQL management studio сначала "задумывается секунд на 10", затем завершается ошибкой. Наверное очень огромный план

для сбора плана проще всего воспользоваться

было бы интересно как этот запрос  обработал оптимизатор в 2014

" Расчет себестоимости. Запрос типовой." что-то не припомню расчет себестоимости "за минуту". Сколкьо документов? Какой период? Точно уверены, что в файловом себестоимость рассчитывает, а не иммитирует загрузку процессора?