Доброго времени суток.

Попался клиент, у которого падает служба 1с-сервера на выполнении тяжеленького запроса. Этот запрос многие годы эксплуатировали и эксплуатируем у многих других клиентов без проблем, но тут прямо никак не можем понять, что происходит у них. Может что не оптимально написано. Сервер у них 32х битный, но и у других 32 битных работает, а у этих - нет.

Ошибка - "На сервере 1С:Предприятие произошла неисправимая ошибка. Приложение будет закрыто"

Запрос вытаскивает ABC рейтинги товара.


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



ВЫБРАТЬ
    КлючиАналитикиУчетаНоменклатуры.Номенклатура КАК Номенклатура,
    КлючиАналитикиУчетаНоменклатуры.Характеристика КАК Характеристика,
    КлючиАналитикиУчетаНоменклатуры.Ссылка КАК Ссылка
ПОМЕСТИТЬ ВыборкаНомХар
ИЗ
    Справочник.КлючиАналитикиУчетаНоменклатуры КАК КлючиАналитикиУчетаНоменклатуры
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    ВыборкаНомХар.Номенклатура КАК Номенклатура,
    СУММА(ПродажиОбороты.СуммаВыручкиОборот) КАК СуммаВыручкиОборот,
    ВЫБОР
        КОГДА &ИспользоватьХарактеристики
            ТОГДА ВыборкаНомХар.Характеристика
        ИНАЧЕ ЗНАЧЕНИЕ(Справочник.ХарактеристикиНоменклатуры.ПустаяСсылка)
    КОНЕЦ КАК Характеристика
ПОМЕСТИТЬ выборка
ИЗ
    РегистрНакопления.ВыручкаИСебестоимостьПродаж.Обороты(&НачалоПериода, &КонецПериода, , Подразделение В (&Подразделение)) КАК ПродажиОбороты
        ЛЕВОЕ СОЕДИНЕНИЕ ВыборкаНомХар КАК ВыборкаНомХар
        ПО ПродажиОбороты.АналитикаУчетаНоменклатуры = ВыборкаНомХар.Ссылка

СГРУППИРОВАТЬ ПО
    ВыборкаНомХар.Номенклатура,
    ВЫБОР
        КОГДА &ИспользоватьХарактеристики
            ТОГДА ВыборкаНомХар.Характеристика
        ИНАЧЕ ЗНАЧЕНИЕ(Справочник.ХарактеристикиНоменклатуры.ПустаяСсылка)
    КОНЕЦ
;

////////////////////////////////////////////////////////////////////////////////
УНИЧТОЖИТЬ ВыборкаНомХар
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    СУММА(выборка.СуммаВыручкиОборот) КАК СуммаВсего
ПОМЕСТИТЬ тСуммаВсего
ИЗ
    выборка КАК выборка
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    выборка.Номенклатура КАК Номенклатура,
    МАКСИМУМ(ЕСТЬNULL(выборка.СуммаВыручкиОборот, 0)) КАК СуммаВыручкиОборот,
    выборка.Характеристика КАК Характеристика,
    СУММА(ЕСТЬNULL(выборка1.СуммаВыручкиОборот, 0)) КАК СуммаВыручкиОборотДляABC,
    ЕСТЬNULL(тСуммаВсего.СуммаВсего, 0) КАК СуммаВсего
ПОМЕСТИТЬ тСуммаОборотовСуммаВсего
ИЗ
    выборка КАК выборка
        ЛЕВОЕ СОЕДИНЕНИЕ выборка КАК выборка1
        ПО выборка.СуммаВыручкиОборот >= выборка1.СуммаВыручкиОборот
        ЛЕВОЕ СОЕДИНЕНИЕ тСуммаВсего КАК тСуммаВсего
        ПО (ИСТИНА)

СГРУППИРОВАТЬ ПО
    выборка.Номенклатура,
    выборка.Характеристика,
    ЕСТЬNULL(тСуммаВсего.СуммаВсего, 0)

Последний запрос, создающий временную таблицу тСуммаОборотовСуммаВсего - на нём всё валится.
Предыдущие отрабатывают нормально.

(0) и сколько записей в таблице выборка? Если больше 10к, то ничего удивительного

Важное уточнение. Падает именно на mssql версии БД.
Выгруженная в файловую ошибку не даёт.
Загружаем из дт в скл - опять ошибка.

Запросто больше 10к, даже скорее всего больше.
Но у всех работает, годами. А тут особенный какой то попался.
А что за 10к, что почитать по теме?

(4) Не было оборотов за период - вот у тебя получилось n*n записей согласно условию
выборка.СуммаВыручкиОборот >= выборка1.СуммаВыручкиОборот

я бы тоже упал

(4) соединение "По выборка.СуммаВыручкиОборот >= выборка1.СуммаВыручкиОборот" дает в результате полуквадрат количества записей. Т.е. на 10к исходных записей получишь 50 млн результурующих, на 100к - 5 млрд...
Ну и общий вывод: считать нарастающий итог в запросе при таком количестве записей очень рискованно

Ну и кто то пользует характеристики, кто -то нет.

Кстати нарастающий итог в запросы 1с так и не завезли? Вроде там какой-то прогресс был на этом направлении

(8) Слава Богу нет

Запрос должен быть простой, как автомат. Вернуть максимально отфильтрованные данные, которые потом нужно обработать кодом. В волшебном и презираемом мною мире СКД, это конечно не работает.

(10) ну тут мнения расходятся))) Всё что можно посчитать запросом (без ущерба для производительности), я посчитаю запросом.

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

(11) Ну вот потом вот такую ситуацию и словишь

(10) Это конечно.Только черт возьми,как же удобно все в запросе посчитать , и нагляность тоже на высоте.
Поэтому ищу альтернативу запросам на 20 и более страниц, но не нахожу.

(13) не словлю, в данном случае всё очевидно и без ущерба для производительности здесь не работает.
Раньше например просто для нумерации записей такой фокус иногда приходилось делать, а сейчас есть Автономерзаписи - применимость многих приемов резко возросла. Завтра допилят нарастающий итог и это будет следующий шаг

(3) А файловая как и mssql тоже в 32-битной системе?

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

(3)Так может у них ограничение MS SQL по использованию памяти стоит..

(12) а какое у скд в данном случае будет преимущество? запрос то всё равно отработает, скорее всего, с вылетом. Кстати надо попробовать, интересно

(16) да, на том же серваке, на 32х битной платформе.
Вообще ситуация там такая:ос - 64х, mssql - 64х, 1с и клиент и сервер - 32х

(19) Посчитать нарастающий итог - это сложность O(N), а твоим способом в запросе O(N^2) ещё и с соответсвующим расходом памяти.

(17) техжурнал смотрели только на сбор ошибок, пока ничего не поняли. Надо ковырнуть подробнее попробовать. опыта нет в этом вопросе

ну и запросы у вас! - сказал сервер и упал

(18)  Ограничение есть, конечно, но меньше чем у других клиентов. Попробуем, однако, увеличить. Для теста, вечерком, после выхода пользователей

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

(0) Может на кластере ограничение на тяжелые запросы стоит, проверяли?

https://v8.1c.ru/platforma/upravlenie-potrebleniem-resursov/?

(26) ничего лишнего нет, все по умолчанию

(25) Ограничение в сервере на расход памяти. Ограничение скуль на темп.
Но я бы еще посмотрел на качество данных. Попробуй отбором по подразделениям сделать. По одному.
Один раз было, битая запись и на нем запрос падал в скуле. Причем в файловой все хорошо.

(28) ВыборкаНомХар - сколько записей в таблице?

+29 Если упадет на одном конкретном подразделении. Смотреть выборку меньше и тд

Может в этой базе косяк с ключами аналитики, может они задублированы N раз и таблица пухлая, по сравнению с другими базами, где у вас все норм выполняется.

(29) "Но я бы еще посмотрел на качество данных."
Тоже думал в этом направлении. Пробовал из dt загружать обратно в mssql и формировать еще раз(грубые ошибки при загрузке из dt обычно фиксятся) - не помогло.
Попробую еще отборы.

По остальному - ограничений не нашли

(33) Попробуйте на 64х серваке 1с выполнить на копии этой базы, отработает?

(33) У меня было, что выгрузка загрузка тии все ок.
А там в измерении то ли пусто было, то ли битая ссылка. Помогло перепроведение

(34) да! на 64х сервере и в файловой 32х - работает.

(35) понял, подумаем в этом направлении

(24)Если сервер 1с 32х, то может процесс банально рушиться..