Коллеги, проясните ситуацию. Имеем УТ 10.3 на 8.2.16.352. Включен партионный учет. Замером производительности определил, что при проведении расходных документов 98% времени висим на исполнении запроса к регистру партий по товарам.
Согласно типовому алгоритму параметр &Дат - это момент времени, если вместо него использовать дату, то запрос выполняется на два порядка быстрее. Что именно влияет на скорость выполнения при использовании момента времени и каким образом?
ВЫБРАТЬ
СписанныеТовары.НомерСтрокиДокумента КАК НомерСтрокиДокумента,
ПартииТоваровНаСкладах.Номенклатура,
ПартииТоваровНаСкладах.ДокументОприходования КАК ДокументОприходования,
ПартииТоваровНаСкладах.ДокументОприходования.Дата КАК ДокументОприходованияДата,
ПартииТоваровНаСкладах.Склад,
ПартииТоваровНаСкладах.ХарактеристикаНоменклатуры,
ПартииТоваровНаСкладах.СерияНоменклатуры,
ПартииТоваровНаСкладах.Качество,
ПартииТоваровНаСкладах.Заказ,
ПартииТоваровНаСкладах.КоличествоОстаток КАК Количество,
ПартииТоваровНаСкладах.СтоимостьОстаток КАК Стоимость,
ПартииТоваровНаСкладах.СтатусПартии,
ВЫБОР
КОГДА СписанныеТовары.СерияНоменклатуры = ПартииТоваровНаСкладах.СерияНоменклатуры
ТОГДА 0
ИНАЧЕ 1
КОНЕЦ КАК ЧислоСерияНоменклатуры,
ВЫБОР
КОГДА СписанныеТовары.ДокументПартии = НЕОПРЕДЕЛЕНО
ТОГДА 0
ИНАЧЕ ВЫБОР
КОГДА СписанныеТовары.ДокументПартии = ПартииТоваровНаСкладах.ДокументОприходования
ТОГДА 0
ИНАЧЕ 1
КОНЕЦ
КОНЕЦ КАК ЧислоДокументОприходования,
ВЫБОР
КОГДА СписанныеТовары.ЗаказПартии = НЕОПРЕДЕЛЕНО
ТОГДА 0
ИНАЧЕ ВЫБОР
КОГДА ПартииТоваровНаСкладах.Заказ = &ПустойЗаказ
ТОГДА 1
ИНАЧЕ 0
КОНЕЦ
КОНЕЦ КАК ЧислоЗаказ,
ВЫБОР
КОГДА ПартииТоваровНаСкладах.СтатусПартии = &НаКомиссию
ТОГДА 1
ИНАЧЕ 0
КОНЕЦ КАК ЧислоСтатусПартии
ИЗ
РегистрСведений.СписанныеТовары КАК СписанныеТовары
ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.ПартииТоваровНаСкладах.Остатки(
&Дат,
Номенклатура В
(ВЫБРАТЬ
РегистрСведений.СписанныеТовары.Номенклатура
ИЗ
РегистрСведений.СписанныеТовары
ГДЕ
РегистрСведений.СписанныеТовары.Регистратор = &Ссылка)
И (Склад В
(ВЫБРАТЬ
РегистрСведений.СписанныеТовары.Склад
ИЗ
РегистрСведений.СписанныеТовары
ГДЕ
РегистрСведений.СписанныеТовары.Регистратор = &Ссылка) ИЛИ Склад = &ПустойСклад)) КАК ПартииТоваровНаСкладах
ПО СписанныеТовары.Номенклатура = ПартииТоваровНаСкладах.Номенклатура
И СписанныеТовары.ХарактеристикаНоменклатуры = ПартииТоваровНаСкладах.ХарактеристикаНоменклатуры
И (ВЫБОР
КОГДА ПартииТоваровНаСкладах.Качество = &ПустоеКачество
ТОГДА ИСТИНА
ИНАЧЕ ВЫБОР
КОГДА СписанныеТовары.Качество = &ПустоеКачество
ТОГДА ПартииТоваровНаСкладах.Качество = &КачествоНовый
ИНАЧЕ ПартииТоваровНаСкладах.Качество = СписанныеТовары.Качество
КОНЕЦ
КОНЕЦ)
И (ПартииТоваровНаСкладах.Склад = СписанныеТовары.Склад ИЛИ ПартииТоваровНаСкладах.Склад = &ПустойСклад)
И (ВЫБОР
КОГДА СписанныеТовары.ДопустимыйСтатус1 <> &ПустойСтатус
ИЛИ СписанныеТовары.ДопустимыйСтатус2 <> &ПустойСтатус
ИЛИ СписанныеТовары.ДопустимыйСтатус3 <> &ПустойСтатус
ИЛИ СписанныеТовары.ДопустимыйСтатус4 <> &ПустойСтатус
ТОГДА ПартииТоваровНаСкладах.СтатусПартии = &ПустойСтатус
ИЛИ ПартииТоваровНаСкладах.СтатусПартии = &СтатусПартииПоОрдеру
ИЛИ ПартииТоваровНаСкладах.СтатусПартии = СписанныеТовары.ДопустимыйСтатус1
ИЛИ ПартииТоваровНаСкладах.СтатусПартии = СписанныеТовары.ДопустимыйСтатус2
ИЛИ ПартииТоваровНаСкладах.СтатусПартии = СписанныеТовары.ДопустимыйСтатус3
ИЛИ ПартииТоваровНаСкладах.СтатусПартии = СписанныеТовары.ДопустимыйСтатус4
ИНАЧЕ ИСТИНА
КОНЕЦ)
И (ВЫБОР
КОГДА СписанныеТовары.СписыватьТолькоПоЗаказу = ИСТИНА
ТОГДА ВЫБОР
КОГДА ПартииТоваровНаСкладах.Заказ <> СписанныеТовары.ЗаказПартии
ТОГДА ВЫБОР
КОГДА (НЕ СписанныеТовары.ЗаказПартии = НЕОПРЕДЕЛЕНО)
ТОГДА ЛОЖЬ
ИНАЧЕ ПартииТоваровНаСкладах.Заказ = &ПустойЗаказ
КОНЕЦ
ИНАЧЕ ИСТИНА
КОНЕЦ
ИНАЧЕ ВЫБОР
КОГДА ПартииТоваровНаСкладах.Заказ <> СписанныеТовары.ЗаказПартии
ТОГДА ПартииТоваровНаСкладах.Заказ = &ПустойЗаказ
ИНАЧЕ ИСТИНА
КОНЕЦ
КОНЕЦ)
И (СписанныеТовары.СерияНоменклатуры = ПартииТоваровНаСкладах.СерияНоменклатуры
ИЛИ ПартииТоваровНаСкладах.СерияНоменклатуры = &ПустаяСерияНоменклатуры
ИЛИ СписанныеТовары.КодОперацииПартииТоваров = &КодРезервирование)
ГДЕ
СписанныеТовары.Регистратор = &ОсновнойДокумент
УПОРЯДОЧИТЬ ПО
ЧислоСерияНоменклатуры,
ЧислоДокументОприходования,
ЧислоЗаказ,
ЧислоСтатусПартии,
ДокументОприходованияДата,
ДокументОприходования
ИТОГИ ПО
НомерСтрокиДокумента ПоказатьСогласно типовому алгоритму параметр &Дат - это момент времени, если вместо него использовать дату, то запрос выполняется на два порядка быстрее. Что именно влияет на скорость выполнения при использовании момента времени и каким образом?
По теме из базы знаний
- Сильное падение производительности MS SQL сервера из-за VMWare
- Решение нестандартных проблем производительности на реальных примерах
- Распространенные ошибки разработчиков, приводящие к проблемам производительности
- Почему не достигаются цели
- История одного админа в мире 1С. Как поиски причины тормозов 1С привели к созданию нового продукта
Найденные решения
(1) kotloff,
Есть 3 варианта решения:
1. Часто обновляйте статистику по регистру накопления ПартииТоваров и регистру сведений СписанныеТовары
(гарантирует на 90% уменьшение времени). При условии, что вы нормально переиндексацию этих таблиц делаете хотя бы раз в неделю.
2. Переписать запрос (гарантирует на 99,9%).
3. Делать отложенное проведение по партиям (не для всех подходит).
Почему возникает проблема:
слишком интенсивно изменяются данные в таблице и портится статистика.
Есть 3 варианта решения:
1. Часто обновляйте статистику по регистру накопления ПартииТоваров и регистру сведений СписанныеТовары
(гарантирует на 90% уменьшение времени). При условии, что вы нормально переиндексацию этих таблиц делаете хотя бы раз в неделю.
2. Переписать запрос (гарантирует на 99,9%).
3. Делать отложенное проведение по партиям (не для всех подходит).
Почему возникает проблема:
слишком интенсивно изменяются данные в таблице и портится статистика.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) kotloff,
Есть 3 варианта решения:
1. Часто обновляйте статистику по регистру накопления ПартииТоваров и регистру сведений СписанныеТовары
(гарантирует на 90% уменьшение времени). При условии, что вы нормально переиндексацию этих таблиц делаете хотя бы раз в неделю.
2. Переписать запрос (гарантирует на 99,9%).
3. Делать отложенное проведение по партиям (не для всех подходит).
Почему возникает проблема:
слишком интенсивно изменяются данные в таблице и портится статистика.
Есть 3 варианта решения:
1. Часто обновляйте статистику по регистру накопления ПартииТоваров и регистру сведений СписанныеТовары
(гарантирует на 90% уменьшение времени). При условии, что вы нормально переиндексацию этих таблиц делаете хотя бы раз в неделю.
2. Переписать запрос (гарантирует на 99,9%).
3. Делать отложенное проведение по партиям (не для всех подходит).
Почему возникает проблема:
слишком интенсивно изменяются данные в таблице и портится статистика.
И попробуйте упростить запрос, чтобы получилось что-то типа
ВЫБРАТЬ * ИЗ РегистрНакопления.ПартииТоваровНаСкладах.Остатки(&Дат,
Номенклатура В
(ВЫБРАТЬ
РегистрСведений.СписанныеТовары.Номенклатура
ИЗ
РегистрСведений.СписанныеТовары
ГДЕ
РегистрСведений.СписанныеТовары.Регистратор = &Ссылка)
ВЫБРАТЬ * ИЗ РегистрНакопления.ПартииТоваровНаСкладах.Остатки(&Дат,
Номенклатура В
(ВЫБРАТЬ
РегистрСведений.СписанныеТовары.Номенклатура
ИЗ
РегистрСведений.СписанныеТовары
ГДЕ
РегистрСведений.СписанныеТовары.Регистратор = &Ссылка)
(16) kotloff, Чтобы это имело значение, надо в отборе виртуальной таблицы указывать только фильтр по номенклатуре документа, а не этого монстра из 100500 условий. Перенесите массивные условия в секцию ГДЕ, а в отборе витр. табл. оставьте только тривиальные условия.
(17) gallam99, Как интенсивно должны меняться партии, чтобы статистика стала неактуальной? У них там что 6000 приходов и отгрузок в сутки? Это не о том, тут может быть просто tablescan, условия же не оптимизируемые.
(17) gallam99, Как интенсивно должны меняться партии, чтобы статистика стала неактуальной? У них там что 6000 приходов и отгрузок в сутки? Это не о том, тут может быть просто tablescan, условия же не оптимизируемые.
(20) Необходимо сделать следующую проверку: в трассе MS SQL выбрать тяжелый запрос (связанный с партионкой), дальше выполнить в Management Studio. Если будут тормоза такие же, то делаем обновление статистики и проверяем еще раз - запускаем запрос. Автор может это провести и скинуть информацию? По поводу интенсивности, насколько я помню интенсивно меняется регистр сведений - СписанныеТовары, в нем основная проблема. Поэтому (9) уже ответил - что запрос к этому регистру заменили на временные таблицы в следущих релизах и ситуация улучшилась. Учитывая, что обычно этот регистр сведений не маленький - из-за корявой статистики в момент выполнения запроса план неправильный, и длительность на несколько порядков больше (причем не факт что воспроизведется из MAnagement Studio).
P.S> Мной приведены не теоретические выводы, а реальное решение, которое подтверждено большим количеством проектов с проблемами запросов по партионке)))
P.S> Мной приведены не теоретические выводы, а реальное решение, которое подтверждено большим количеством проектов с проблемами запросов по партионке)))
(9) Walker.pro, соглашусь. У меня была ситуация когда замена запроса типа
"Номенклатура В
(ВЫБРАТЬ
РегистрСведений.СписанныеТовары.Номенклатура
ИЗ
РегистрСведений.СписанныеТовары
ГДЕ
РегистрСведений.СписанныеТовары.Регистратор = &Ссылка)"
разительно ускоряла выполнение запроса.
"Номенклатура В
(ВЫБРАТЬ
РегистрСведений.СписанныеТовары.Номенклатура
ИЗ
РегистрСведений.СписанныеТовары
ГДЕ
РегистрСведений.СписанныеТовары.Регистратор = &Ссылка)"
разительно ускоряла выполнение запроса.
(15) kotloff, если всё именно так, как вы рассказываете (а было бы всё-таки неплохо выдернуть именно интересующую часть запроса и проверить именно на ней), то скорее всего при преобразовании запроса в SQL-запрос в 1-м случае используются индексы, а во-втором - нет.
Это легко можно проверить, если запустить профайлер в MSSQL.
Однако, как я уже писал Walker.pro проблема скорее всего в дургом участке запроса. А ваше изменение влияет лишь на то, сможет оптимизатор SQL оптимизировать запрос или нет.
Это легко можно проверить, если запустить профайлер в MSSQL.
Однако, как я уже писал Walker.pro проблема скорее всего в дургом участке запроса. А ваше изменение влияет лишь на то, сможет оптимизатор SQL оптимизировать запрос или нет.
Раз запрос уже переписали.
Вдогонку советую посмотреть на какую дату рассчитаны итоги (Операции>Управление итогами), при необходимости пересчитать. Индексы добавить по измерениям, которые используются в условиях запроса.
Вдогонку советую посмотреть на какую дату рассчитаны итоги (Операции>Управление итогами), при необходимости пересчитать. Индексы добавить по измерениям, которые используются в условиях запроса.
(33) Vremin,
Не совсем согласен в Вами.
Если простой запрос на остатки, то действительно проблем нет - если дата документа меньше даты расчета (но только с запросом). Но теряется (в большинстве ситуаций не критично) время на обновление итогов будущих периодов (при перепроведении документа, насколько я понял в этом контексте вопрос), это тоже надо учитывать. К слову, без разделения итогов, может приводить к избыточным блокировкам на итогах.
Не совсем согласен в Вами.
Если простой запрос на остатки, то действительно проблем нет - если дата документа меньше даты расчета (но только с запросом). Но теряется (в большинстве ситуаций не критично) время на обновление итогов будущих периодов (при перепроведении документа, насколько я понял в этом контексте вопрос), это тоже надо учитывать. К слову, без разделения итогов, может приводить к избыточным блокировкам на итогах.
(36) Я на (30) ориентировался. Ведь в длительность перепроведения входит как запрос, так и изменение данных.
Вывод: дату расчета итогов надо выбирать очень взвешенно!!!, так как она влияет и на скорость запросов при проведении оперативных документов (текущий период), и на затраты времени для обновления итогов (если неоперативный документ и много итогов рассчитанных с датой, большей чем в документе).
Вывод: дату расчета итогов надо выбирать очень взвешенно!!!, так как она влияет и на скорость запросов при проведении оперативных документов (текущий период), и на затраты времени для обновления итогов (если неоперативный документ и много итогов рассчитанных с датой, большей чем в документе).
gallam99
пришли к:
при перепроведении палка о двух концах,
для работы пользователей лучше актуальные итоги
+ сталкивался с перепроведением базы за 3 года с сильно переписанной Торговлей, в итоге актуальные итоги ускоряли процесс проведения - возможно случай частный
пришли к:
при перепроведении палка о двух концах,
для работы пользователей лучше актуальные итоги
+ сталкивался с перепроведением базы за 3 года с сильно переписанной Торговлей, в итоге актуальные итоги ускоряли процесс проведения - возможно случай частный
Возможно есть куча документов, созданных при переносе и имеющие одинаковую дату(до секунды), при использовании Дата их последовательность не важна, при использовании МоментВремени они начинаются выстраиваться в логическую последовательность, что и несет доп.затраты серверного времени. Перепроведи такие кучи, если они есть и все пройдет.
Я тут попал в похожую ситуацию недавно. Мощный сервер, скуль. Простой запрос выполнялся два часа.
На партнерке ответили довольно сухо, ткнув носом в базу знаний, где первым пунктом настоятельно предлагалось исключить использование вложенных запросов.
Примечательно ,что этот-же запрос на файловой версии выполнялся мгонвенно, но завешивал скуль на два часа.
По факту переписывания на временные таблицы скорость возросла с 9000 секунд до 70. На два порядка.
Поэтому не стоит пологаться на статистику, итоги, и объем таблиц: скуль не всесильный, когда эска его раком ставит.
Все вложенные запросы должны быть переписаны через ВТ, без исключений.
На партнерке ответили довольно сухо, ткнув носом в базу знаний, где первым пунктом настоятельно предлагалось исключить использование вложенных запросов.
Примечательно ,что этот-же запрос на файловой версии выполнялся мгонвенно, но завешивал скуль на два часа.
По факту переписывания на временные таблицы скорость возросла с 9000 секунд до 70. На два порядка.
Поэтому не стоит пологаться на статистику, итоги, и объем таблиц: скуль не всесильный, когда эска его раком ставит.
Все вложенные запросы должны быть переписаны через ВТ, без исключений.
(43) amiralnar, Спасибо большое! Я ещё пока только учусь. Мне и франч тоже что-то говорил про использование временных таблиц в связи с тем, что база УПП может быть гигов 25 и выше. Теперь ясно для чего, что Эска оказывается умееет ещё и что-то "Раком ставить")))
(43) amiralnar,
не судьба студентам объяснить, что ВТ - это просто предварительная выборка, на порядки сокращающая объем обрабатываемых данных, чтобы не тянуть тысячу миллионов ненужных записей из SQL в противном разе, как у всех тут в первых случаях?!
(47) Bukaska,
поменьше верьте желтым книжкам и курсам, побольше думайте сами.
Все вложенные запросы должны быть переписаны через ВТ
не судьба студентам объяснить, что ВТ - это просто предварительная выборка, на порядки сокращающая объем обрабатываемых данных, чтобы не тянуть тысячу миллионов ненужных записей из SQL в противном разе, как у всех тут в первых случаях?!
(47) Bukaska,
Мне и франч тоже что-то говорил про использование временных таблиц в связи с тем, что база УПП может быть гигов 25 и выше.
поменьше верьте желтым книжкам и курсам, побольше думайте сами.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот