Безбожно тормозит запрос СрезПоследних #806982

база УТП для Украины (аналог КА) после перехода на клиент-серверный вариант работы стали долго (6-10 минут) проводиться некоторые документы "Отчет о розничных продажах" Замер производительности показывает что очень долго выполняется запрос: Запрос простой до безобразия, на скрине показаны замеры на двух "соседних" документах, но проблема в том что документ, который перед этим провелся нормально, при перепроведении так же тупит :( 1С 8.3.10.2561. Пробовал на 8.3.9.2233 MS SQL 2012 SP2 пробовал на боевом сервере (Сервер 1С на виртуалке, SQL на железе) и на тестовом сервере (все на железе, на одном сервере, я во время теста на сервере был один) - разницы нет, так что дело не в железе ТиИ прогонял. Не помогло SELECT TOP 10 *   FROM [MyBase].[dbo].[_InfoRg13775]   WHERE _Period IS NULL пустой (InfoRg13775 - Регистр сведений ЦеныАТТ) куда еще посмотреть???? :( На файловой, ожидаемо, летает...

Всё на Украине не слава богу...

составной тип значения в измерениях есть?

Давайте без политики, пожалуйста. Склад, Номенклатура, ХарактеристикаНоменклатуры, все с типами соответствующих справочников. Не составные. Больше измерений нет

профайлер, планы запроса что говорят? Украина без политики - это фантастика.

мошт скуль тупит регламентные операции на скуле настроены?

А статистику обновляли?

Проиндексируй измерения Номенклатура и Склад

а что в списках складов и номенклатуры, мошт там треш?

Список номенклатуры, склад во временную таблицу, проиндексировать в виртуальной (Склад, Номенклатура) В (Выбрать ВрТаб.Склад, ВрТаб.Номенклатура ИЗ ВрТаб) Если организация есть, ее тоже добавить

мошт скуль тупит вполне возможно, даже скорей всего. Но одинаково тупят 2 скуля  на двух серверах... А статистику обновляли? Да, забыл указать. После обновления статистики один-два документа проводятся норм. дальше тупняк даже при перепроведении тех же. Но не обновлять же статистику после каждого документа... Нет там треша. Да и один и тот же документ в одной и той же базе проводится то пару сек. то 10 мин. Прямо в регистре? или для начала как в . Кстати Номенклатуру в регистре индексировать не дает (Стоит галка "Ведущее")

Утром с этого начну. Сейчас нужно бежать, если есть еще мысли - кидайте

Прямо в регистре

Вы не победите, пока план запроса в xml не соберете. Вот и все мысли.

если вариант (Склад, Номенклатура) то номенклатуру можно не индексировать - там уже есть индекс по набору измерений

В складах ровно 5 элементов, стоит индексировать? А Номенклатуру, напомню, индексировать не дает

Убери отбор по складу

Нужно попробовать убрать отбор по номенклатуре в условии формирования среза, а уже итоговую таблицу отфильтровать соединением с временной таблицей по полю номенклатура. Индексировать временную не надо. Отбор по складам в срезе оставить - их должно быть относительно мало.

ИЗ     РегистрСведений.ЦеныАТТ.СрезПоследних(&Дата

периодические таблицы всегда тормозят при использовании отборов или в соединениях, просто нужно понять что это вирт.таблица не самым простым способом расчета последних. Самый оптимальный вариант, сделать вирт.таблицу - реальной. делаете второй непериодический регистр сведений копию нужного с таким же названием и приставкой например Текущие, (БлаБла_Текущие). Добавляете подписку на запись периодического регистра пример для ЦеныНоменклатуры ---- ---- Правите нужны запросы на новую таблицу. Делаете первичное заполнение и наслаждаетесь необыкновенно высокой скоростью

Откройте для себя ИтогиПоСрезуПоследних. Вылезайте уже из каменного века.

или вот более универсальный пример, добавляем в модуль периодического регистра Процедура ПриЗаписи(Отказ, Замещение)     Если Не Отказ Тогда

Ну и вспомните, что нужны и неоперативные записи.

Но у автора - другая проблема. Проблема с SQL

Особенно позабавил вариант . Образчик прям ядского треша.

а вы сравнивали  скорость работы ИтоговПоСрезуПоследних и регистра сведений с расчетом среза последних  при записи? В особо клинических случаях, помогает даже с регистрами накоплений. в базах большим количеством изменений разница ОЧЕНЬ существенна.

+ регистры сведений позволяют присоединять их через ПВХ как характеристики товаров, т.е. к примеру присоедениить все виды цены или остатки по складам к номенклатуре как свойства. А затем легко использовать их в дин.списках и отчетах

"а вы сравнивали  скорость работы ИтоговПоСрезуПоследних и регистра сведений с расчетом среза последних  при записи? " Нет. Не сравнивал, так как это - одно и тоже, только 1 вариант - это платформенная фишка и как бы нет необходимости самому пилить костыль. А что - вы сравнивали? Про РегНакопления - нифига не понял.

Я так понимаю провели замеры ? Или так - пальцы покидать

Конечно провели.

1. Запустить реиндексацию базы. Чтобы привести в порядок индексы. Вы дергали галочки индексации или ведущих измерений? Они сами не встанут, только после переиндексации. Может вы и порядок измерений меняли? Возможно, кластерный индекс перестроился при обновлении конфигурации ИБ, возможно нет. 2. Что характеристика номенклатуры вообще делает в регистре??? Если она еще и измерением является - совсем плохо. Используй конструкцию "Выразить". Это облегчит агонию ИБ. 3. PS я б ничего не индексировал, если номенклатура со складом первые 2 измерения регистра. Если это не так - подвинуть их в начало. 4. Уволиться.

Сколько сотен тысяч записей в РС? Помню, на подобную ситуацию натыкался - в РС: 600К записей, всего 3 измерения. Делаем срез с отбором по одному измерению - занимает 20 минут. Делаем срез без отбора - работает быстро. Я так и не разобрался в чем проблема. Прямо интересно

план запроса разный

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

стыдно сказать, 8321

Скорее всего нужно переиндексировать и/или пересоздать итоги.

как определил что это постгри?

Можно создать ещё один регистр, который назвать ЦеныСрезПоследних. При записи основного регистра (или с какой-то регулярностью) обновлять второй. Запрос ко второму регистру сведений будет моментальный.

Ну он же сказал "Постгри не виноватый" Сделал то, что очень не рекомендуют авторы всех книжек по запросам: Перенес условие из параметров виртуальной таблицы в обычное условие                    |    ЦеныПродажные.Номенклатура В(&СписокНоменклатуры)"; Что-то похожее рекомендовали выше но с ВТ и индексами. Летает. Все равно остается вопрос как скуль заставить строить здравые планы не только при первом проведении после Update statistics, но и весь день...

лучше внутри скобок оставь отбор по номенклатуре

Дополнять список номенклатуры пустыми позициями до 1000 штук. тогда Номенклатура В(&СписокНоменклатуры) всегда будет конвертироваться в _field IN (&P1,...&P1000) и план для таких запросов будет один.

Но тогда включаются тормоза :( а так 00000000221 Время проведения - 4 00000000222 Время проведения - 5 00000000225 Время проведения - 4 00000000217 Время проведения - 5 00000000218 Время проведения - 4 00000000219 Время проведения - 4 00000000220 Время проведения - 5 00000000221 Время проведения - 3 00000000222 Время проведения - 4 00000000223 Время проведения - 5 Неидеально, но далеко не 10-15 минут Теперь заставить бы скуль здраво строить планы с отбором в скобках...

Сделай в регистре измерение Номенклатура первым.

Если список номенклатур большой, то IN работает плохо и возможно стоит сделать примерно так:

+ план будет одинаковый

Интересно было бы посмотреть результат запроса в PostgreSQL 10, там они с планом запроса плотно поработали. Как раз подходит для 1С. Бартунов видео выложил. Только когда новую версию под 1с выпустят?

Помогло Возвращаю порядок измерений назад - тормоза возвращаются Оставлю пока так Всем спасибо не то чтоб большой. в проблемных документах приблизительно по 150 строк Поэкспериментировал с документом на 20 строк - проводится влет, в профайлере при этом один запрос с трудночитаемым для меня планом :(, но одним При проведении обычного документа на 150 строк в профайлере огромная куча мелких запросов, в которых я просто теряюсь :( Соответственно и планов куча...

Я надеюсь 4-5 - это секунды :-)

Одной проблемой на Украине меньше... :)

конструкция В равносильна вроде как отбору по условию ИЛИ. Чем больше элементов в массиве, тем труднее. Потому я взял за правило, что если в массиве не ограниченное и, как правило, не прогнозируемое число элементов, делать через ВТ и последующее соединение большой таблицы с отбором из ВТ. Алгебра множества она такая....

А статистику смотрели по запросу? Может у вас там в регистре до сего дня было 10 записей, а сегодня 50 млн, и запрос всю таблицу сканит (Index scan использует в sql). Смотрели запрос в профайлере? Если план "трудночитаемый" то поставьте в профалере отбор по настройке "SHOWPLAN_XML STATISTICS PROFILE" или как-то так, на память не помню. Он план в xml показывает. После того как покажет вас будет интересовать ожидаемая выборка и действительная в операторе и сами операторы. Запрос в ветке не нашел но проблемы основные могут быть: 1)При связи будет оператор "Nested loops" 2)При поиске в таблице будет "Table scan"или еще какой скан.