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

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

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

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

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

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

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

(5) да

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

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

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

(9)
Текст запроса (в отладчике):
ВЫБРАТЬ
    РегЗатраты.Затрата,
    РегЗатраты.ХарактеристикаЗатраты,
    РегЗатраты.СерияЗатраты,
    РегЗатраты.Подразделение,
    РегЗатраты.НоменклатурнаяГруппа,
    РегЗатраты.СтатьяЗатрат,
    РегЗатраты.Продукция,
    РегЗатраты.ХарактеристикаПродукции,
    РегЗатраты.СерияПродукции,
    РегЗатраты.Спецификация,
    РегЗатраты.Заказ,
     РегЗатраты.СчетУчета,
     РегЗатраты.НалоговоеНазначение,

    СУММА(ЕСТЬNULL(РегВыпуск.КоличествоВыпуск, 0)) КАК КоличествоВыпуск,
    СУММА(РегЗатраты.Количество) КАК Количество,
     СУММА(РегЗатраты.СуммаНУ) КАК СтоимостьНУ,
     СУММА(РегЗатраты.НДСВходящий) КАК НДСВходящий,
     СУММА(РегЗатраты.НДСКредит) КАК НДСКредит,
    СУММА(РегЗатраты.Сумма) КАК Стоимость
    
ИЗ
    РегистрНакопления.ЗатратыНаВыпускПродукцииБухгалтерскийУчет КАК РегЗатраты

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

        СГРУППИРОВАТЬ ПО
            РегВыпуск.Подразделение,
            РегВыпуск.Продукция,
            РегВыпуск.ХарактеристикаПродукции,
            РегВыпуск.СерияПродукции,
            РегВыпуск.Спецификация,
            РегВыпуск.НоменклатурнаяГруппа,
            РегВыпуск.Заказ,
             РегВыпуск.СчетУчетаНЗП,
             РегВыпуск.НалоговоеНазначение,
            РегВыпуск.Заказ

        ) КАК РегВыпуск
    ПО
        РегВыпуск.Подразделение = РегЗатраты.Подразделение
         И РегВыпуск.НоменклатурнаяГруппа = РегЗатраты.НоменклатурнаяГруппа
         И РегВыпуск.Продукция = РегЗатраты.Продукция
         И РегВыпуск.ХарактеристикаПродукции = РегЗатраты.ХарактеристикаПродукции
         И РегВыпуск.СерияПродукции = РегЗатраты.СерияПродукции
         И РегВыпуск.Спецификация = РегЗатраты.Спецификация
        И РегВыпуск.Заказ = РегЗатраты.Заказ
          И РегВыпуск.СчетУчетаНЗП = РегЗатраты.СчетУчета
  И ((РегВыпуск.НалоговоеНазначение = РегЗатраты.НалоговоеНазначение) ИЛИ
  (РегЗатраты.СтатьяЗатрат.СтатусМатериальныхЗатрат = ЗНАЧЕНИЕ

(Перечисление.СтатусыМатериальныхЗатратНаПроизводство.ПринятыеВПереработку)
  И РегЗатраты.НалоговоеНазначение = ЗНАЧЕНИЕ(Справочник.НалоговыеНазначенияАктивовИЗатрат.ПустаяСсылка)))


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

СГРУППИРОВАТЬ ПО
    РегЗатраты.Затрата,
    РегЗатраты.ХарактеристикаЗатраты,
    РегЗатраты.СерияЗатраты,
    РегЗатраты.Подразделение,
    РегЗатраты.Продукция,
    РегЗатраты.ХарактеристикаПродукции,
    РегЗатраты.СерияПродукции,
    РегЗатраты.Спецификация,
    РегЗатраты.ДокументВыпуска,
    РегЗатраты.СтатьяЗатрат,
    РегЗатраты.НоменклатурнаяГруппа,
     РегЗатраты.СчетУчета,
     РегЗатраты.НалоговоеНазначение,
    РегЗатраты.Заказ

УПОРЯДОЧИТЬ ПО
    РегЗатраты.Затрата,
    РегЗатраты.ХарактеристикаЗатраты,
    РегЗатраты.СерияЗатраты,
    РегЗатраты.Подразделение,
    РегЗатраты.Продукция,
    РегЗатраты.ХарактеристикаПродукции,
    РегЗатраты.СерияПродукции,
    РегЗатраты.Спецификация,
    РегЗатраты.ДокументВыпуска,
    РегЗатраты.СтатьяЗатрат,
    РегЗатраты.НоменклатурнаяГруппа,
     РегЗатраты.СчетУчета,
     РегЗатраты.НалоговоеНазначение,
    РегЗатраты.Заказ

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

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

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

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

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

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

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

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

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

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

с сетью чета

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

   ИЛИ РегЗатраты.СуммаНУ <> 0
     ИЛИ РегЗатраты.НДСВходящий <> 0
     ИЛИ РегЗатраты.НДСКредит <> 0

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

(22) ресурсы неиндексированы

чиво, чиво ???

(15)(23)(13)

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

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

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

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

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

(29) нет, как это?

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

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

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

(33) способы разные есть
один из - понять какой у тебя SPID и либо заранее накладывать фильтр на SPID либо потом просматривать

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

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

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

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

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

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

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

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

(0) Можно попробовать сделать дополнительные индексы средствами 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" (если нет - то уже есть необходимый индекс) и у тебя появляется текст запроса для создания индекса, который облегчит выполнение этого запроса.

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

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

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

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

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

для сбора плана проще всего воспользоваться
http://www.gilev.ru/querytj/

было бы интересно как этот запрос  обработал оптимизатор в 2014
http://www.brentozar.com/archive/2014/04/sql-2014-cardinality-estimator-eats-bad-tsql-breakfast/

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