Коллеги, проясните ситуацию. Имеем УТ 10.3 на 8.2.16.352. Включен партионный учет. Замером производительности определил, что при проведении расходных документов 98% времени висим на исполнении запроса к регистру партий по товарам.

```1c
    ВЫБРАТЬ
    СписанныеТовары.НомерСтрокиДокумента КАК НомерСтрокиДокумента,
    ПартииТоваровНаСкладах.Номенклатура,
    ПартииТоваровНаСкладах.ДокументОприходования КАК ДокументОприходования,
    ПартииТоваровНаСкладах.ДокументОприходования.Дата КАК ДокументОприходованияДата,
    ПартииТоваровНаСкладах.Склад,
    ПартииТоваровНаСкладах.ХарактеристикаНоменклатуры,
    ПартииТоваровНаСкладах.СерияНоменклатуры,
    ПартииТоваровНаСкладах.Качество,
    ПартииТоваровНаСкладах.Заказ,
    ПартииТоваровНаСкладах.КоличествоОстаток КАК Количество,
    ПартииТоваровНаСкладах.СтоимостьОстаток КАК Стоимость,
    ПартииТоваровНаСкладах.СтатусПартии,
    ВЫБОР
    КОГДА СписанныеТовары.СерияНоменклатуры = ПартииТоваровНаСкладах.СерияНоменклатуры
    ТОГДА 0
    ИНАЧЕ 1
    КОНЕЦ КАК ЧислоСерияНоменклатуры,
    ВЫБОР
    КОГДА СписанныеТовары.ДокументПартии = НЕОПРЕДЕЛЕНО
    ТОГДА 0
    ИНАЧЕ ВЫБОР
    КОГДА СписанныеТовары.ДокументПартии = ПартииТоваровНаСкладах.ДокументОприходования
    ТОГДА 0
    ИНАЧЕ 1
    КОНЕЦ
    КОНЕЦ КАК ЧислоДокументОприходования,
    ВЫБОР
    КОГДА СписанныеТовары.ЗаказПартии = НЕОПРЕДЕЛЕНО
    ТОГДА 0
    ИНАЧЕ ВЫБОР
    КОГДА ПартииТоваровНаСкладах.Заказ = &ПустойЗаказ
    ТОГДА 1
    ИНАЧЕ 0
    КОНЕЦ
    КОНЕЦ КАК ЧислоЗаказ,
    ВЫБОР
    КОГДА ПартииТоваровНаСкладах.СтатусПартии = &НаКомиссию
    ТОГДА 1
    ИНАЧЕ 0
    КОНЕЦ КАК ЧислоСтатусПартии
    ИЗ
    РегистрСведений.СписанныеТовары КАК СписанныеТовары
    ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.ПартииТоваровНаСкладах.Остатки(
    &Дат,
    Номенклатура В
    (ВЫБРАТЬ
    РегистрСведений.СписанныеТовары.Номенклатура
    ИЗ
    РегистрСведений.СписанныеТовары
    ГДЕ
    РегистрСведений.СписанныеТовары.Регистратор = &Ссылка)
    И (Склад В
    (ВЫБРАТЬ
    РегистрСведений.СписанныеТовары.Склад
    ИЗ
    РегистрСведений.СписанныеТовары
    ГДЕ
    РегистрСведений.СписанныеТовары.Регистратор = &Ссылка) ИЛИ Склад = &ПустойСклад)) КАК ПартииТоваровНаСкладах
    ПО СписанныеТовары.Номенклатура = ПартииТоваровНаСкладах.Номенклатура
    И СписанныеТовары.ХарактеристикаНоменклатуры = ПартииТоваровНаСкладах.ХарактеристикаНоменклатуры
    И (ВЫБОР
    КОГДА ПартииТоваровНаСкладах.Качество = &ПустоеКачество
    ТОГДА ИСТИНА
    ИНАЧЕ ВЫБОР
    КОГДА СписанныеТовары.Качество = &ПустоеКачество
    ТОГДА ПартииТоваровНаСкладах.Качество = &КачествоНовый
    ИНАЧЕ ПартииТоваровНаСкладах.Качество = СписанныеТовары.Качество
    КОНЕЦ
    КОНЕЦ)
    И (ПартииТоваровНаСкладах.Склад = СписанныеТовары.Склад ИЛИ ПартииТоваровНаСкладах.Склад = &ПустойСклад)
    И (ВЫБОР
    КОГДА СписанныеТовары.ДопустимыйСтатус1 <> &ПустойСтатус
    ИЛИ СписанныеТовары.ДопустимыйСтатус2 <> &ПустойСтатус
    ИЛИ СписанныеТовары.ДопустимыйСтатус3 <> &ПустойСтатус
    ИЛИ СписанныеТовары.ДопустимыйСтатус4 <> &ПустойСтатус
    ТОГДА ПартииТоваровНаСкладах.СтатусПартии = &ПустойСтатус
    ИЛИ ПартииТоваровНаСкладах.СтатусПартии = &СтатусПартииПоОрдеру
    ИЛИ ПартииТоваровНаСкладах.СтатусПартии = СписанныеТовары.ДопустимыйСтатус1
    ИЛИ ПартииТоваровНаСкладах.СтатусПартии = СписанныеТовары.ДопустимыйСтатус2
    ИЛИ ПартииТоваровНаСкладах.СтатусПартии = СписанныеТовары.ДопустимыйСтатус3
    ИЛИ ПартииТоваровНаСкладах.СтатусПартии = СписанныеТовары.ДопустимыйСтатус4
    ИНАЧЕ ИСТИНА
    КОНЕЦ)

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

    УПОРЯДОЧИТЬ ПО
    ЧислоСерияНоменклатуры,
    ЧислоДокументОприходования,
    ЧислоЗаказ,
    ЧислоСтатусПартии,
    ДокументОприходованияДата,
    ДокументОприходования
    ИТОГИ ПО
    НомерСтрокиДокумента
```

Согласно типовому алгоритму параметр &Дат - это момент времени, если вместо него использовать дату, то запрос выполняется на два порядка быстрее. Что именно влияет на скорость выполнения при использовании момента времени и каким образом?
---
kotloff,
Есть 3 варианта решения:
1. Часто обновляйте статистику по регистру накопления ПартииТоваров и регистру сведений СписанныеТовары
(гарантирует на 90% уменьшение времени). При условии, что вы нормально переиндексацию этих таблиц делаете хотя бы раз в неделю.
2. Переписать запрос (гарантирует на 99,9%).
3. Делать отложенное проведение по партиям (не для всех подходит).
Почему возникает проблема:
слишком интенсивно изменяются данные в таблице и портится статистика.
---
kotloff,
Есть 3 варианта решения:
1. Часто обновляйте статистику по регистру накопления ПартииТоваров и регистру сведений СписанныеТовары
(гарантирует на 90% уменьшение времени). При условии, что вы нормально переиндексацию этих таблиц делаете хотя бы раз в неделю.
2. Переписать запрос (гарантирует на 99,9%).
3. Делать отложенное проведение по партиям (не для всех подходит).
Почему возникает проблема:
слишком интенсивно изменяются данные в таблице и портится статистика.
---
gallam99, по п.1 - если честно, переиндексация и обновление статистики не делались ни разу, если не считать нескольких ТиИ за последние 2 года.
---
kotloff,
Возможно вы и сами нашли причину)))
---
gallam99, не сочтите за труд, подскажите, как это лучше сделать? какие скрипты и всё такое...
---
gallam99,
"переписал" запрос с использованием временных таблиц, помогло. Кстати, в последней УТ 10.3 запрос такой же, как у меня :( , пришлось взять из КА и немного доточить.
---
На 2 порядка - это за 1 секунду вместо 100?
---
artemka, именно
---
И попробуйте упростить запрос, чтобы получилось что-то типа
ВЫБРАТЬ * ИЗ РегистрНакопления.ПартииТоваровНаСкладах.Остатки(&Дат,
        Номенклатура В
            (ВЫБРАТЬ
                РегистрСведений.СписанныеТовары.Номенклатура
            ИЗ
                РегистрСведений.СписанныеТовары
            ГДЕ
                РегистрСведений.СписанныеТовары.Регистратор = &Ссылка)
---
artemka, не очень хочется ковырять типовые механизмы, больше интересует природа этого долгого исполнения. есть подозрение, что дело в границе последовательности "Партионный учет", хотелось бы от знающих услышать вердикт.
---
Граница последовательности тут не при чем. Граница последовательности - это, всего на всего, информация о гарантированном последовательном проведении документов, т.е. корректном учете с точки зрения партионного учета.
---
Kom-off, в чём же причина сего странного явления?
---
kotloff, и ещё: там у вас внутреннее соединение. При смене МоментаВремени на дату - размер полученной таблицы не меняется случайно?
---
Сколько в базе номенклатуры? База файловая или SQL? Есть сильное подозрение, что проседает где-то в другом месте, а не при срезе остатков из партий.
---
artemka, MSSQL2008R2 Standard, актуальных элементов номенклатуры около 20000.
проседает именно на этом запросе.
---
kotloff, а в документе сколько?
---
artemka, в документе не более 10-20 строк
---
kotloff, Чтобы это имело значение, надо в отборе виртуальной таблицы указывать только фильтр по номенклатуре документа, а не этого монстра из 100500 условий. Перенесите массивные условия в секцию ГДЕ, а в отборе витр. табл. оставьте только тривиальные условия.

(17) gallam99, Как интенсивно должны меняться партии, чтобы статистика стала неактуальной? У них там что 6000 приходов и отгрузок в сутки? Это не о том, тут может быть просто tablescan, условия же не оптимизируемые.
---
amiralnar, спасибо, попробую.
---
Необходимо сделать следующую проверку: в трассе MS SQL выбрать тяжелый запрос (связанный с партионкой), дальше выполнить в Management Studio. Если будут тормоза такие же, то делаем обновление статистики и проверяем еще раз - запускаем запрос. Автор может это провести и скинуть информацию? По поводу интенсивности, насколько я помню интенсивно меняется регистр сведений - СписанныеТовары, в нем основная проблема. Поэтому (9) уже ответил - что запрос к этому регистру заменили на временные таблицы в следущих релизах и ситуация улучшилась. Учитывая, что обычно этот регистр сведений не маленький - из-за корявой статистики в момент выполнения запроса план неправильный, и длительность на несколько порядков больше (причем не факт что воспроизведется из MAnagement Studio).
    P.S> Мной приведены не теоретические выводы, а реальное решение, которое подтверждено большим количеством проектов с проблемами запросов по партионке)))
---
В последней версии УТ этот запрос должен быть переделан на использование временных таблиц, попробуйте, может новая версия запроса будет работать быстрее...
---
Walker.pro, соглашусь. У меня была ситуация когда замена запроса типа

"Номенклатура В
            (ВЫБРАТЬ
                РегистрСведений.СписанныеТовары.Номенклатура
            ИЗ
                РегистрСведений.СписанныеТовары
            ГДЕ
                РегистрСведений.СписанныеТовары.Регистратор = &Ссылка)"

разительно ускоряла выполнение запроса.
---
artemka, не спорю, но почему именно параметр типа МоментВремени() так влияет на скорость?
---
kotloff, если всё именно так, как вы рассказываете (а было бы всё-таки неплохо выдернуть именно интересующую часть запроса и проверить именно на ней), то скорее всего при преобразовании запроса в SQL-запрос в 1-м случае используются индексы, а во-втором - нет.
Это легко можно проверить, если запустить профайлер в MSSQL.
Однако, как я уже писал Walker.pro проблема скорее всего в дургом участке запроса. А ваше изменение влияет лишь на то, сможет оптимизатор SQL оптимизировать запрос или нет.
---
artemka, понятно, попробую рыть в сторону изменения запроса.
---
Walker.pro, да, конфа очень старая, была мысль глянуть в новой, руки не дошли.
---
А какая дата и какой момент?
Сдается мне, итоги отключаются.
---
amiralnar, момент времени этого документа, или его же дата. конкретный случай - 02.01.2012 г.
---
Раз запрос уже переписали.
Вдогонку советую посмотреть на какую дату рассчитаны итоги (Операции>Управление итогами), при необходимости пересчитать. Индексы добавить по измерениям, которые используются в условиях запроса.
---
Vremin, как дата итогов повлияет на неоперативное перепроведение документов в прошлых периодах?
---
Если дата получения остатков по регистру накопления больше даты рассчитанных итогов, то запрос будет выполняться дольше
---
Vremin, да, это я понимаю, а обратный случай?
---
Если дата получения остатков по регистру накопления меньше даты рассчитанных итогов, то все ок
---
Vremin, ага, спасибо.
---
Vremin,
Не совсем согласен в Вами.
Если простой запрос на остатки, то действительно проблем нет - если дата документа меньше даты расчета (но только с запросом). Но теряется (в большинстве ситуаций не критично) время на обновление итогов будущих периодов (при перепроведении документа, насколько я понял в этом контексте вопрос), это тоже надо учитывать. К слову, без разделения итогов, может приводить к избыточным блокировкам на итогах.
---
gallam99, я про запрос писал. Пересчет итогов при проведении документа - согласен занимает время.
---
Я на (30) ориентировался. Ведь в длительность перепроведения входит как запрос, так и изменение данных.
Вывод: дату расчета итогов надо выбирать очень взвешенно!!!, так как она влияет и на скорость запросов при проведении оперативных документов (текущий период), и на затраты времени для обновления итогов (если неоперативный документ и много итогов рассчитанных с датой, большей чем в документе).
---
gallam99
пришли к:
при перепроведении палка о двух концах,
для работы пользователей лучше актуальные итоги

+ сталкивался с перепроведением базы за 3 года с сильно переписанной Торговлей, в итоге актуальные итоги ускоряли процесс проведения - возможно случай частный
---
Vremin,
Частный и очень вырожденный)
Нелогично, наверняка влияли какие-то другие скрытые факторы.
---
Возможно есть куча документов, созданных при переносе и имеющие одинаковую дату(до секунды), при использовании Дата их последовательность не важна, при использовании МоментВремени они начинаются выстраиваться в логическую последовательность, что и несет доп.затраты серверного времени. Перепроведи такие кучи, если они есть и все пройдет.
---
mymyka, тоже к этой мысли склоняюсь. спасибо.
---
Все возможно, поэтому доверяю только фактам )
---
база большая? видимо таблица регистров по партиям сильно засорена...
---
ПиН, да не маленькая, гигов около 20. свёртка 2 года не делалась...
---
Я тут попал в похожую ситуацию недавно. Мощный сервер, скуль. Простой запрос выполнялся два часа.
На партнерке ответили довольно сухо, ткнув носом в базу знаний, где первым пунктом настоятельно предлагалось исключить использование вложенных запросов.

Примечательно ,что этот-же запрос на файловой версии выполнялся мгонвенно, но завешивал скуль на два часа.
По факту переписывания на временные таблицы скорость возросла с 9000 секунд до 70. На два порядка.

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

Все вложенные запросы должны быть переписаны через ВТ, без исключений.
---
amiralnar, да, надо это не забывать.
---
amiralnar, Спасибо большое! Я ещё пока только учусь. Мне и франч тоже что-то говорил про использование временных таблиц в связи с тем, что база УПП может быть гигов 25 и выше. Теперь ясно для чего, что Эска оказывается умееет ещё и что-то "Раком ставить")))
---
amiralnar,
Все вложенные запросы должны быть переписаны через ВТ
не судьба студентам объяснить, что ВТ - это просто предварительная выборка, на порядки сокращающая объем обрабатываемых данных, чтобы не тянуть тысячу миллионов ненужных записей из SQL в противном разе, как у всех тут в первых случаях?!
(47) Bukaska,
 Мне и франч тоже что-то говорил про использование временных таблиц в связи с тем, что база УПП может быть гигов 25 и выше.
поменьше верьте желтым книжкам и курсам, побольше думайте сами.