Вот и настало моё время приобщиться к легендарному желтому форуму...

В общем, в чем суть: есть запрос в УТ 11.5, который получает последнюю установленную цену на серию и группирует по номенклатуре. Используется в отчете, спокойно себе работает... но только на серверной базе. При использовании файловой ложится в бесконечный запрос. Пробным путем было выяснено, что база в целом зависает намертво при наличии одной простой связи, где цепляется серия номенклатуры из справочника по полю "СерияНоменклатурыДляЦенообразования" и "СерияЦО" регистра "ЦеныНоменклатуры25" соответственно. В обеих таблицах записей не то что бы много, все корректно заполнены, нет серий без серийЦО и установок без серий ЦО.

Кусок запроса, на котором всё ложится:
        |ВЫБРАТЬ
        |    ЦеныНоменклатуры25.Номенклатура КАК Номенклатура,
        |    МАКСИМУМ(ЕСТЬNULL(СерииНоменклатуры.Партия.Дата, ДАТАВРЕМЯ(1, 1, 1))) КАК ДатаВводаСерии,
        |    МАКСИМУМ(ЦеныНоменклатуры25.Период) КАК Период
        |ПОМЕСТИТЬ втМаксимальныеДаты
        |ИЗ
        |    РегистрСведений.ЦеныНоменклатуры25 КАК ЦеныНоменклатуры25
        |        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.СерииНоменклатуры КАК СерииНоменклатуры
        |        ПО (ЦеныНоменклатуры25.СерияЦО = СерииНоменклатуры.СерияНоменклатурыДляЦенообразования)
        |ГДЕ
        |    ЦеныНоменклатуры25.ВидЦены.Наименование = ""Закупочные (ССР)""
        |    И ЦеныНоменклатуры25.Цена <> 0
        |{ГДЕ
        |    (ЦеныНоменклатуры25.Период <= &ОкончаниеПериода)}
        |
        |СГРУППИРОВАТЬ ПО
        |    ЦеныНоменклатуры25.Номенклатура
        |
        |ИНДЕКСИРОВАТЬ ПО
        |    Номенклатура,
        |    Период
        |;

Думал сначала, что дело в индексации и банальном медленном поиске, но нифига. Просто при наличии подобной связи в любой конструкции запроса, независимо от использования, все намертво виснет. На сервере отрабатывает секунды за две, генерируя 700+ строк в итоге.
Есть ли какой-нибудь вариант посмотреть, что может вызывать подобный казус?
ТиИ прогнал полностью - бесполезно
Посмотрел через Тулс_1СД - ничего аномального на первый взгляд не увидел
Развернул локально, чтобы был только один сеанс (мало ли от нагрузки на боевой не справляется) - тоже не помогло

Ну и запрос

(1) Да, запрос никчемный, но всё же интересно, почему он ложится
Как и писал ранее, даже если там будет выбрано одно поле без условий, но вот с этой связью - всё виснет

(0) > Есть ли какой-нибудь вариант посмотреть, что может вызывать подобный казус?

Установка цен будущей датой есть?

ЦеныНоменклатуры25.ВидЦены.Наименование = ""Закупочные (ССР)""

Вот это уродство я бы убрал

(4) Это правильно пишется с 3-мя буквами "С" и  с большой буквы, причем стоя перед экраном монитора гордо вскинув голову вверх.
Уже убрали 33 года назад...и поимели все что имеем....

ТИИ сделать уже предлагали?

Очень может быть, что проблема не в запросе, а в ошибках в базе...

(0) Самое просто - очистку кэша, делали? Встречал бесконечное ожидание выполнения в файловой базе из-за кэша.

Сама первичная выборка данных запроса, до "ГДЕ" выходит большая? Поведение на 32х и 64х битном клиенте одинаково?

Попробуйте без строк с индексированием

(7) Делал, полное тестирование прошло, база реиндексирована

(8) Кэш чистить не пробовал, может и поможет, но база начинает так себя вести даже с чистой развертки на другом ПК
Первичная выборка выходит в рамках разумного, в ценах примерно 800 записей, серий номенклатуры 13000 записей.
"Попробуйте без строк с индексированием" - имеется ввиду не выбирая их в поля выборки данных, или же выключенное индексирование?

В консоли запросов тоже виснет?
Движок файловой БД - черный ящик, можно конечно поиграться добавляя ПЕРВЫЕ N, сделать простейший запрос с этим соединением, чтобы локализовать проблему. ЦеныНоменклатуры25.СерияЦО - индекс есть?

(3) Не, всё раньше текущего периода

Вот здесь криво, может быть причина
МАКСИМУМ(ЕСТЬNULL(СерииНоменклатуры.Партия.Дата

целых две точки

(11) Да, в том-то и дело. Если бы сам отчет просто повисал, можно было бы списать на кривость запроса в СКД, а тут просто с ничего всё падает. С конструкцией "Первые N" эффект аналогичный. Индекса на поле "СерияЦО" нет
Забыл упомянуть, кстати. В более ранней копии базы подобной проблемы не наблюдается. Может ли быть такое, что где-то в таблицах сидит битая запись?

(13) Без этого поля ситуация аналогична, увы

(14) попробуй на копии еще прогнать chdbfl.exe но то такое

(0)
        |ВЫБРАТЬ
        |    ЦеныНоменклатуры25.Номенклатура КАК Номенклатура,
        |    МАКСИМУМ(ЕСТЬNULL(СерииНоменклатуры.Партия.Дата, ДАТАВРЕМЯ(1, 1, 1))) КАК ДатаВводаСерии,
        |    МАКСИМУМ(ЦеныНоменклатуры25.Период) КАК Период
        |ПОМЕСТИТЬ втМаксимальныеДаты
        |ИЗ
        |    РегистрСведений.ЦеныНоменклатуры25 КАК ЦеныНоменклатуры25
        |        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.СерииНоменклатуры КАК СерииНоменклатуры
        |        ПО (ЦеныНоменклатуры25.СерияЦО = СерииНоменклатуры.СерияНоменклатурыДляЦенообразования)
        |        И ЦеныНоменклатуры25.ВидЦены.Наименование = ""Закупочные (ССР)""
        |        И ЦеныНоменклатуры25.Цена <> 0
        |ГДЕ
        |    ЦеныНоменклатуры25.ВидЦены.Наименование = ""Закупочные (ССР)""
        |    И ЦеныНоменклатуры25.Цена <> 0
        |{ГДЕ
        |    (ЦеныНоменклатуры25.Период <= &ОкончаниеПериода)}
        |
        |СГРУППИРОВАТЬ ПО
        |    ЦеныНоменклатуры25.Номенклатура
        |
        |ИНДЕКСИРОВАТЬ ПО
        |    Номенклатура,
        |    Период
        |;


(16) Посвяти невежу, пожалуйста, в чем разница между chdbfl и ТиИ для файловой базы?

я бы еще попробовал разбить на ВТ, а соединение делать между ВТ, но это тоже гадание

(17) О, а вот тут интересно. Оно выполнилось, но аномально долго. 32 секунды, 714 записей в итоге

(20) Попробуй без МАКСИМУМ и без СГРУППИРОВАТЬ

(21) Ну и ЦеныНоменклатуры25.ВидЦены.Наименование = ""Закупочные (ССР)"" переделай на ЦеныНоменклатуры25.ВидЦены = &ВидЦены

(21) 2000 записей всего вышло, время такое же практически

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

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

chdbfl это своего рода dbcc checkdb

И еще, сейчас вообще пальцем в небо, но у реквизитов ЦеныНоменклатуры25.СерияЦО и СерииНоменклатуры.СерияНоменклатурыДляЦенообразования индексирование включено?

+ ТИИ базу вряд ли убьет (если не реструктуризация, и  там не было критических проблем изначально, но это и выгрузка/загрузка так же убьет) а chdbfl - легко

(25) *невежду)
Понял, учту. В таком случае действительно есть смысл прогнать и так. Не знаешь, случаем, показывает ли Tools_1CD последней версии (для баз нового формата) ошибки в структурной целостности, или просто дает читать данные внутри?

Просто выборка из РегистрСведений.ЦеныНоменклатуры25 с отбором по какому-нибудь ЦеныНоменклатуры25.СерияЦО работает быстро?
Просто выборка из Справочник.СерииНоменклатуры с отбором по какому-нибудь СерииНоменклатуры.СерияНоменклатурыДляЦенообразования работает быстро?

(26) у обоих выключено

(28) Tools_1CD писал человек, awe вроде, который уже много лет как умер

(29) Да, молниеносно

А (22)?

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

(22) +100

(33) Аналогично, 30 секунд
Выборка по регистру цен без отборов и условий, судя по трекеру консоли запросов, выполняется менее чем за полсекунды

(28) не знаю, это все гадание. Ну кстати, если нештатная проблема, то можно попробовать "копию" развернуть через выгрузка/загрузка. Если штатная только локализация через экспериментирование, (29) например

Ставлю всё-таки на то, что проблема именно со структурной целостностью базы, только вот интересно то, что на mssql данной проблемы нет вовсе

(37) Пробовал, бесполезно

А, ну по ходу причина в "СерииНоменклатуры.Партия.Дата"
Партия же составной тип?
И туда неявно куча говна подтягивается

Проверь

        |ВЫБРАТЬ
        |    ЦеныНоменклатуры25.Номенклатура КАК Номенклатура,
        |    МАКСИМУМ(СерииНоменклатуры.Партия) КАК ДатаВводаСерии,
        |    МАКСИМУМ(ЦеныНоменклатуры25.Период) КАК Период
        |ПОМЕСТИТЬ втМаксимальныеДаты
        |ИЗ
        |    РегистрСведений.ЦеныНоменклатуры25 КАК ЦеныНоменклатуры25
        |        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.СерииНоменклатуры КАК СерииНоменклатуры
        |        ПО (ЦеныНоменклатуры25.СерияЦО = СерииНоменклатуры.СерияНоменклатурыДляЦенообразования)
        |        И ЦеныНоменклатуры25.ВидЦены.Наименование = ""Закупочные (ССР)""
        |        И ЦеныНоменклатуры25.Цена <> 0
        |ГДЕ
        |    ЦеныНоменклатуры25.ВидЦены.Наименование = ""Закупочные (ССР)""
        |    И ЦеныНоменклатуры25.Цена <> 0
        |{ГДЕ
        |    (ЦеныНоменклатуры25.Период <= &ОкончаниеПериода)}
        |
        |СГРУППИРОВАТЬ ПО
        |    ЦеныНоменклатуры25.Номенклатура
        |
        |ИНДЕКСИРОВАТЬ ПО
        |    Номенклатура,
        |    Период
        |;


(31) awa

(38) Не ищи сложных объяснений там, где причина в обыкновенной рукожопости

(38) проблемма в том, что SQL умеет сам кешировать некоторые вещи, в твоем случае тип цен

(40) Вообще нет, там жесткий тип - ДокументСсылка.ПриобретениеТоваровУслуг (Дописка мелочная)
Этот вариант запроса так же отработал за 30 секунд

(41) А, ну да

Может ли данная ситуация как-то быть связана с тем, что поле "Партия" в справочник было добавлено через расширение?

(46) может если не индексировано

(44) О, а вот это уже странно
А так?

        |ВЫБРАТЬ
        |    ЦеныНоменклатуры25.Номенклатура КАК Номенклатура,
        |    СерииНоменклатуры.Партия КАК ДатаВводаСерии,
        |    ЦеныНоменклатуры25.Период КАК Период
        |ИЗ
        |    РегистрСведений.ЦеныНоменклатуры25 КАК ЦеныНоменклатуры25
        |        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.СерииНоменклатуры КАК СерииНоменклатуры
        |        ПО ЦеныНоменклатуры25.СерияЦО = СерииНоменклатуры.СерияНоменклатурыДляЦенообразования
        |        И ЦеныНоменклатуры25.ВидЦены = &ВидЦены
        |        И ЦеныНоменклатуры25.Цена <> 0
        |ГДЕ
        |    ЦеныНоменклатуры25.ВидЦены = &ВидЦены
        |    И ЦеныНоменклатуры25.Цена <> 0
        |;


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

(48) Тоже 31 секунда

(49) А (48)?

А просто выборка из Справочник.СерииНоменклатуры сотбором по фиксированному СерииНоменклатуры.Партия?

(51) А, уже (50), не увидел

(52) Выборка с отбором - менее секунды
Выборка полей "Ссылка, СерияНоменклатурыДляЦенообразования" и "Партия" без отборов - тоже менее секунды

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

(55) Вполне возможно. Как сделаю - отпишусь

Да, индексирование СерииНоменклатурыДляЦенообразования и СерияЦО помогли)

Всем спасибо за советы!