Тормозит обработка ПодборНоменклатуры УПП 1.2 + SQL Server 2008 R2 #789260

Доброго дня. Нужна помощь. Имеется УПП 1.2 2007 года. Переписанная. Работает на sql server 2008 r2 developer/enterprise x64. 16 ядер / 32 потока, 192 Гбайт рама. Проц не грузит, память всю не ест. Тормозит обработка ПодборНоменклатуры для самописного документа, самописной подсистемы. Текст запроса:     Справочник.Номенклатура КАК НоменклатураСправочник     НоменклатураСправочник.Родитель = &Родитель     И НЕ НоменклатураСправочник.ИсключитьИзПрайсов ИНДЕКСИРОВАТЬ ПО     НЕ ЕдиницыИзмерения.ПометкаУдаления     И ЕдиницыИзмерения.Владелец В             (ВЫБРАТЬ                 втНоменклатура.Номенклатура                 И Номенклатура В                     (ВЫБРАТЬ                         втНоменклатура.Номенклатура                 И Номенклатура В                     (ВЫБРАТЬ                         втНоменклатура.Номенклатура                     ИЗ                 И Номенклатура В                     (ВЫБРАТЬ                         втНоменклатура.Номенклатура                     ИЗ                 И Номенклатура В                     (ВЫБРАТЬ                         втНоменклатура.Номенклатура                     ИЗ             Контрагент = &Контрагент                 И Номенклатура В                     (ВЫБРАТЬ                         втНоменклатура.Номенклатура                     ИЗ     втНоменклатура.Номенклатура.ЕдиницаХраненияОстатков КАК ЕдиницаИзмерения, Проблема вот в чем: При выборе &Родитель — достаточно большая группа товаров. Первый раз выполняется 25 секунд (в копии, в боевой базе от 25 до 90-120 и более, если совсем не повезет). Второй раз и все последующие (даже через час или два) Время- 2.165, Время- 2.146, Время- 2.156. Или группа поменьше. Первый Время- 25.905. Дальше Время- 1.546, Время- 1.538 и т.д. Маленькая группа Время- 11.067, Время- 0.873, Время- 0.877, Время- 0.879. Продолжу на примере первой группы. Таблицы ВТ строк: Убираем выборку из ВТ (со всеми некрасивыми соединениями через точку) Время- 2.065, то есть не меняется вообще. Убираем ТоварыВРезерве Время- 1.806, что уже немного получше. Убираем ТоварыНаСкладах Время- 1.665. То есть обрезанием этих регистров можно сэкономить 1/8 запроса, что не особо чувствительно. Возвращаем все взад, убираем запрос к РегистрСведений.ЦеныНоменклатуры.СрезПоследних имеем Время- 0.489/0.490 стабильно. Попробовал выбрать РС.ЦеныНоменклатуры &Дата, ТипЦен = &ТипЦен (без отбора по номенклатуре. ВЫШЛО 3422 СЕКУНДЫ. Номенклатуры порядка 160 000 позиций. Начал изучать таблицы в скуле. N    Имя метаданных    Назначение метаданных    Данные (КБ)    Индексы (КБ)    Свободно (КБ)    Зарезервировано всего (КБ)     Имя таблицы SQL    Кол-во строк                 7    РегистрНакопления.ТоварыВРезервеНаСкладах    Основная    4 695 104    4 835 200    11 664    9 541 968     _AccumRg13980    32 834 054                 16    РегистрНакопления.ТоварыНаСкладах    Основная    2 158 328    1 247 600    728    3 406 656     _AccumRg14040    14 022 291                 20    РегистрСведений.ЦеныНоменклатуры    Основная    1 557 512    2 829 728    4 440    4 391 680     _InfoRg12489    10 116 446                 Затем запустил несколько скриптов с SQL сервер 2008: обслуживание, анализ производительности Результаты Степень фрагментации индексов Первый запрос показывает текущую фрагментацию индексов базы Было у всех трех регистров в районе 22%-24%, после отработки скриптов Реорганизация/Перестроение индексов из данной статьи (поменял только 30 на 20, чтобы нужным мне регистры тоже перестроились). Вышло 1,2%-1,4%. НО! Заметно скорость не поменялась. Все так-же первый запрос выполняется на порядок медленнее последующих. DatbaseName    TableName    IndexName    type_desc    Fragmentation    page_count    partition_number    sql    Records count copy20160627    _InfoRg12489    _InfoR12489_ByRecorder_RN    NONCLUSTERED    1,21    45 302    1    alter index [_InfoR12489_ByRecorder_RN] on [dbo].[_InfoRg12489] REBUILD with(maxdop = 4,  SORT_IN_TEMPDB = on)    1 copy20160627    _AccumRg14040    _Accum14040_ByRecorder_RN    NONCLUSTERED    1,28    62 976    1    alter index [_Accum14040_ByRecorder_RN] on [dbo].[_AccumRg14040] REBUILD with(maxdop = 4,  SORT_IN_TEMPDB = on)    1 copy20160627    _AccumRg13980    _Accum13980_ByDims14581_RTRN    NONCLUSTERED    1,56    232 920    1    alter index [_Accum13980_ByDims14581_RTRN] on [dbo].[_AccumRg13980] REBUILD with(maxdop = 4,  SORT_IN_TEMPDB = on)    1 Скачал последнюю УПП. Настройки РС. ЦеныНоменклатуры такие-же. В частности Измерение Номенклатура — Ведущее, Не индексировать. Тогда из той-же статьи прогнал  Отсутствующие индексы, вызывающие высокие издержки:                                          Результат запроса ADODB: 29 записей     Из интересующих регистров только: TotalCost    avg_user_impact    TableName    EqualityUsage    InequalityUsage    IncludeCloumns    Records count 428 603    72,7    [copy20160627].[dbo].[_InfoRg12489]    [_Active], [_Fld12490RRef]        [_Period], [_RecorderTRef], [_RecorderRRef], [_LineNo], [_Fld12491RRef], [_Fld12492RRef]    1     На четвертой позиции. Выше (на первых трех) не интересные мне пока регистры подсистему интеграции с АТС. Что можете подсказать в данной ситуации?

Убрать Индексировать везде

Цены получать одинм запросом

убедиться, что indexscan по ценам номенклатуры, почесать лоб и 1) махнуть рукой 2) перепилить ценыноменклатуры по методике Ненавижу1С и отказаться от СрезПоследних

"Убрать Индексировать везде" не влияет никак. "Цены получать одинм запросом" сделаю, чуть попозже, т.к. и один запрос тормозит. И тормозит в первый раз в 10 более раз сильнее, чем при повторных. "перепилить ценыноменклатуры по методике Ненавижу1С и отказаться от СрезПоследних" можно не разжевать, но хоть направить в нужном направлении. Т.к. и сам думаю в эту сторону. Думал их копировать раз/два в день в отдельный регистр. Но нужны оперативные данные.

есть же консоль запроса с временем выполнения по каждой ВТ. Туда закидываешь запрос и смотришь, что конкретно тормозит. "Инструменты разработчика" - вот это посмотри, и других консолей тоже полно.

Без последнего запроса тоже тормозит?

РегистрСведений.ЦеныНоменклатуры тормозит. Почему при первом запросе тормозит в 10 и более раз сильнее? "Убираем выборку из ВТ (со всеми некрасивыми соединениями через точку) Время- 2.065, то есть не меняется вообще. " в

вопрос " Отсутствующие индексы, вызывающие высокие издержки". Может это затормаживать? И нужно ли с этим бороться?

Там еще и SELECT через точку, а не только соединение.

последний запрос ничего не занимает. Номенклатура + ЕдиницыИзмерени + Последний = ничего. В любой раз. Остатки и Резервы ~ 1/8 времени. Остальное ЦеныНоменклатуры.

План запроса в XML зафотай по Ценам.

а дата в срезе последних по ценам реально нужна?

Чем получить? К скулю на сервере доступа нет. С локального компа к серверу доступа нет. Есть логин и пароль скуля к моей базе с копией.

Как? Без даты быстрее будет?

Без даты в 8.3 можно сключить хранение итогов по СрезуПоследних

Должно. И обычно цены нужны только последние.

включить и использовать. Оперативный СрезПоследних, "расчитанный" и хранящийся в базе в отдельной табличке.

Вот выбрал другую группу: Имя таблицы    Количество строк    Результат запроса втНоменклатура    41    ТаблицаЗначений втУпаковки    37    ТаблицаЗначений втЦены    24    ТаблицаЗначений втЦеныОптовые    33    ТаблицаЗначений Первый раз 6,5 секунды. 2,3,4,5,6 выполняется 0,45-0,46 с.

Платформа (8.2.19.130). На 8.3 переехать не взлетело.

У тебя IndexScan к гадалке не ходи. А еще страшнее - какой-нибудь lazyspool

Собирай план запроса. Получай доступ к SQL, хотя бы пусть дадут доступ к Enterprise manager/ ms sql profiler

Ну или пилить Я у себя в продакшн использовал - все работает на сотнях предприятий по всей России матушке.

С консоли вытянуть нельзя? Есть Консоль запросов MS SQL v02-01 Автор: Селюкин Александр Юрьевич (sau) Чтобы на локальном компе втянуть и разбираться?

Не знаю. У меня всегда есть доступ к SQL.

Спасибо. Буду думать, может поможет.

Ну я на новое место пришел, недели не прошло. Еще нету.

Например, так: 1) При открытии родителя работает простой запрос (без цен и других тяжелых частей). 2) Подключаем в форме ОбработкуОжидания("ПолныйРасчет", , 1) 3) В функции "ПриПолученииДанных" постоянно собираем товары в массив и запоминаем, когда в последний момент это делали. 4) В процедуре "ПолныйРасчет" - как только видим, что прошло больше 1 секунды с момента последнего обращения к процедуре ПриПолученииДанных, выполняем тяжелый запрос по товарам из собранного массива. Результат - в ТЗ, и выводим его на экран (если табполе связано с ТЗ или ТЧ - просто заполняем нужные строки, иначе делаем ТабПоле.ОбновитьСтроки - и в той же ПриПолученииДанных выводим всю нужную информацию). Тогда при быстром листании никаких задержек не будет, остановились - выполнился расчет.

Тормозит не листание, а первый вход в группу.

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

Понял, спасибо. Без срезаПоследних работает быстрее 0,1 секунды. Но 1 выбирает тысячи значений вместо пары десятков. Это с них еще последнее вылавливать надо. НО 2! первый выбор по группе все равно больше 2 секунд для группы в 71 позицию. Больше 4 секунд, при 190 позициях. Может можно эти жалкие 5 гигабайт вручную в кеш скуля поднять, что-бы регистр все время висел и не подгружался.

Подняли мне свежую копию. Было РегистрСведений.ЦеныНоменклатуры 10 млн записей. Через 6 месяцев уже 21 млн записей. Все стало в 4 раза грустнее. Потерянных индексов и фрагментации нет.

а они нужны?может в сторонку старые убрать,не?

Доступ к профайлеру дали?

К сожалению нет. А на локальном компе база не вместится.

Скачал какую-то студенческую поделку ExpressProfiler22wAddinSigned. Ее xml profiler есть отказывается. Может так можно понять? Остатки и резервы почти не тормозят. Запрос в ВТ цен: Первый заход по группе. exec sp_executesql N'INSERT INTO #tt5(_Q_001_F_000RRef, _Q_001_F_001)SELECT#V8TblAli1_Q_001_T_001._Fld12491RRef AS _Q_001_F_000RRef,#V8TblAli1_Q_001_T_001._Fld12494 AS _Q_001_F_001FROM(SELECT_InfoRg12489_IR12._Fld12491RRef AS _Fld12491RRef,_InfoRg12489_IR12._Fld12494 AS _Fld12494FROM(SELECT#V8TblAli1_IR1._Fld12490RRef AS _Fld12490RRef,#V8TblAli1_IR1._Fld12491RRef AS _Fld12491RRef,#V8TblAli1_IR1._Fld12492RRef AS _Fld12492RRef,#V8TblAli1_IR1._MAXPERIOD AS _MAXPERIOD,SUBSTRING(MAX(_InfoRg12489_IR2._RecorderTRef + _InfoRg12489_IR2._RecorderRRef), 1, 4) AS _MAXRECORDERTRef,SUBSTRING(MAX(_InfoRg12489_IR2._RecorderTRef + _InfoRg12489_IR2._RecorderRRef), 5, 16) AS _MAXRECORDERRRefFROM(SELECT_InfoRg12489._Fld12490RRef AS _Fld12490RRef,_InfoRg12489._Fld12491RRef AS _Fld12491RRef,_InfoRg12489._Fld12492RRef AS _Fld12492RRef,MAX(_InfoRg12489._Period) AS _MAXPERIODFROM_InfoRg12489 WITH(NOLOCK)WHERE_InfoRg12489._Period <= AND _InfoRg12489._Active = @P2 AND _InfoRg12489._Fld12490RRef = @P3 AND _InfoRg12489._Fld12492RRef = @P4 AND _InfoRg12489._Fld12491RRef IN (SELECT#T04155dafe3644984966d2fbc5545c695_Q_002_T_001._Q_000_F_000RRef AS _Q_002_F_000RRefFROM#tt1 #T04155dafe3644984966d2fbc5545c695_Q_002_T_001 WITH(NOLOCK))GROUP BY_InfoRg12489._Fld12490RRef,_InfoRg12489._Fld12491RRef,_InfoRg12489._Fld12492RRef) #V8TblAli1_IR1INNER JOIN _InfoRg12489 _InfoRg12489_IR2 WITH(NOLOCK)ON #V8TblAli1_IR1._Fld12490RRef = _InfoRg12489_IR2._Fld12490RRef AND #V8TblAli1_IR1._Fld12491RRef = _InfoRg12489_IR2._Fld12491RRef AND #V8TblAli1_IR1._Fld12492RRef = _InfoRg12489_IR2._Fld12492RRef AND #V8TblAli1_IR1._MAXPERIOD = _InfoRg12489_IR2._PeriodWHERE_InfoRg12489_IR2._Active = @P5 AND _InfoRg12489_IR2._Fld12490RRef = @P6 AND _InfoRg12489_IR2._Fld12492RRef = @P7 AND _InfoRg12489_IR2._Fld12491RRef IN (SELECT#T04155dafe3644984966d2fbc5545c695_Q_002_T_001._Q_000_F_000RRef AS _Q_002_F_000RRefFROM#tt1 #T04155dafe3644984966d2fbc5545c695_Q_002_T_001 WITH(NOLOCK))GROUP BY#V8TblAli1_IR1._Fld12490RRef,#V8TblAli1_IR1._Fld12491RRef,#V8TblAli1_IR1._Fld12492RRef,#V8TblAli1_IR1._MAXPERIOD) #V8TblAli1_IR11INNER JOIN _InfoRg12489 _InfoRg12489_IR12 WITH(NOLOCK)ON #V8TblAli1_IR11._Fld12490RRef = _InfoRg12489_IR12._Fld12490RRef AND #V8TblAli1_IR11._Fld12491RRef = _InfoRg12489_IR12._Fld12491RRef AND #V8TblAli1_IR11._Fld12492RRef = _InfoRg12489_IR12._Fld12492RRef AND #V8TblAli1_IR11._MAXPERIOD = _InfoRg12489_IR12._Period AND #V8TblAli1_IR11._MAXRECORDERTRef = _InfoRg12489_IR12._RecorderTRef AND #V8TblAli1_IR11._MAXRECORDERRRef = _InfoRg12489_IR12._RecorderRRef) #V8TblAli1_Q_001_T_001 CREATE INDEX TmpInd5 ON #tt5 (_Q_001_F_000RRef)',N' datetime2,@P2 varbinary,@P3 varbinary,@P4 varbinary,@P5 varbinary,@P6 varbinary,@P7 varbinary','2017-01-13 00:00:00',0x01,0xAB5D4061862E59BA11E46E70F2A5FC2C,0x00000000000000000000000000000000,0x01,0xAB5D4061862E59BA11E46E70F2A5FC2C,0x00000000000000000000000000000000 go Время выполнения 35 151 мс, 174 216 чтений. Время второго захода 328 мс, 129 359 чтений. Последующие +- как второй. Даже если через пару часов зайти в базу другим пользователем. Второй заход. exec sp_executesql N'INSERT INTO #tt5(_Q_001_F_000RRef, _Q_001_F_001)SELECT#V8TblAli1_Q_001_T_001._Fld12491RRef AS _Q_001_F_000RRef,#V8TblAli1_Q_001_T_001._Fld12494 AS _Q_001_F_001FROM(SELECT_InfoRg12489_IR12._Fld12491RRef AS _Fld12491RRef,_InfoRg12489_IR12._Fld12494 AS _Fld12494FROM(SELECT#V8TblAli1_IR1._Fld12490RRef AS _Fld12490RRef,#V8TblAli1_IR1._Fld12491RRef AS _Fld12491RRef,#V8TblAli1_IR1._Fld12492RRef AS _Fld12492RRef,#V8TblAli1_IR1._MAXPERIOD AS _MAXPERIOD,SUBSTRING(MAX(_InfoRg12489_IR2._RecorderTRef + _InfoRg12489_IR2._RecorderRRef), 1, 4) AS _MAXRECORDERTRef,SUBSTRING(MAX(_InfoRg12489_IR2._RecorderTRef + _InfoRg12489_IR2._RecorderRRef), 5, 16) AS _MAXRECORDERRRefFROM(SELECT_InfoRg12489._Fld12490RRef AS _Fld12490RRef,_InfoRg12489._Fld12491RRef AS _Fld12491RRef,_InfoRg12489._Fld12492RRef AS _Fld12492RRef,MAX(_InfoRg12489._Period) AS _MAXPERIODFROM_InfoRg12489 WITH(NOLOCK)WHERE_InfoRg12489._Period <= AND _InfoRg12489._Active = @P2 AND _InfoRg12489._Fld12490RRef = @P3 AND _InfoRg12489._Fld12492RRef = @P4 AND _InfoRg12489._Fld12491RRef IN (SELECT#T10b5d97408f042f8a9e6106aa4203a94_Q_002_T_001._Q_000_F_000RRef AS _Q_002_F_000RRefFROM#tt1 #T10b5d97408f042f8a9e6106aa4203a94_Q_002_T_001 WITH(NOLOCK))GROUP BY_InfoRg12489._Fld12490RRef,_InfoRg12489._Fld12491RRef,_InfoRg12489._Fld12492RRef) #V8TblAli1_IR1INNER JOIN _InfoRg12489 _InfoRg12489_IR2 WITH(NOLOCK)ON #V8TblAli1_IR1._Fld12490RRef = _InfoRg12489_IR2._Fld12490RRef AND #V8TblAli1_IR1._Fld12491RRef = _InfoRg12489_IR2._Fld12491RRef AND #V8TblAli1_IR1._Fld12492RRef = _InfoRg12489_IR2._Fld12492RRef AND #V8TblAli1_IR1._MAXPERIOD = _InfoRg12489_IR2._PeriodWHERE_InfoRg12489_IR2._Active = @P5 AND _InfoRg12489_IR2._Fld12490RRef = @P6 AND _InfoRg12489_IR2._Fld12492RRef = @P7 AND _InfoRg12489_IR2._Fld12491RRef IN (SELECT#T10b5d97408f042f8a9e6106aa4203a94_Q_002_T_001._Q_000_F_000RRef AS _Q_002_F_000RRefFROM#tt1 #T10b5d97408f042f8a9e6106aa4203a94_Q_002_T_001 WITH(NOLOCK))GROUP BY#V8TblAli1_IR1._Fld12490RRef,#V8TblAli1_IR1._Fld12491RRef,#V8TblAli1_IR1._Fld12492RRef,#V8TblAli1_IR1._MAXPERIOD) #V8TblAli1_IR11INNER JOIN _InfoRg12489 _InfoRg12489_IR12 WITH(NOLOCK)ON #V8TblAli1_IR11._Fld12490RRef = _InfoRg12489_IR12._Fld12490RRef AND #V8TblAli1_IR11._Fld12491RRef = _InfoRg12489_IR12._Fld12491RRef AND #V8TblAli1_IR11._Fld12492RRef = _InfoRg12489_IR12._Fld12492RRef AND #V8TblAli1_IR11._MAXPERIOD = _InfoRg12489_IR12._Period AND #V8TblAli1_IR11._MAXRECORDERTRef = _InfoRg12489_IR12._RecorderTRef AND #V8TblAli1_IR11._MAXRECORDERRRef = _InfoRg12489_IR12._RecorderRRef) #V8TblAli1_Q_001_T_001 CREATE INDEX TmpInd5 ON #tt5 (_Q_001_F_000RRef)',N' datetime2,@P2 varbinary,@P3 varbinary,@P4 varbinary,@P5 varbinary,@P6 varbinary,@P7 varbinary','2017-01-13 00:00:00',0x01,0xAB5D4061862E59BA11E46E70F2A5FC2C,0x00000000000000000000000000000000,0x01,0xAB5D4061862E59BA11E46E70F2A5FC2C,0x00000000000000000000000000000000 go

Сравнение  текстов показывает одинаковые различие в трех местах. SELECT#T10b5d97408f042f8a9e6106aa4203a94_Q_002_T_001. в быстром.

выгрузка в хмл

Периодичность - по позиции регистратора штоле?

ДА, я на где-то написал, а тут забыл.

Странно, это нетиповая хрень. Зачем? Цены меняются по несколько раз в секунду?

включи срез последник по регстру цен ну и дату всегда передавай пустую

У него 8.2 пез вариантов

тогда руками делать таблицу итогов

На скуле писал Я писал "Скачал последнюю УПП. Настройки РС. ЦеныНоменклатуры такие-же. В частности Измерение Номенклатура — Ведущее, Не индексировать." На самом деле есть отличие. В стандартной УПП периодичность "В течение дня". У меня периодичность по позиции регистратора. Цены ставятся автоматом по документам прихода и еще по чем-то. С приходом работает несколько человек. Плюс там еще какие-то навороты. Документы Документ.н01_УстановкаИндивидуальныхСкидокКонтрагента.ТабличнаяЧ занимают больше 8 гиг, Документ.УстановкаЦенНоменклатуры.ТабличнаяЧасть.Товары больше 5 гиг. Записей в регистре ЦеныНоменклатуры на начало года больше 21 млн.

Чьими руками? Цены в подборе должны быть актуальными на текущий момент.

Отдельный регистрсведений с теми же измерениями, непериодический. В него надо в ПриЗаписи регистра ЦеныНоменклатуры переписывать изменяющиеся цены

И, первоначально, заполнить СрезПоследним без фильтров. Как раз работка серверу на выходные

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

ПриЗаписи в модуле набора записей регистра ЦеныНоменклатуры

Пока можно просто скорировать этот регистр, назвать копию ЦеныНоменклатурыАктуальные в конфигурации, убрать подчиненность регистратору в этом новом регистре и заполнить его СрезомПоследних из основного регистра. И попробовать выполнить к нему запрос без всяких срезов последних.

Не было и нету там ПриЗаписи. В смысле в Процедура ВыполнитьДвижения Экспорт добавить? Копирование записываемой записи в свой регистр. Тогда там будет по каждому измерению только одна запись. Так штоле?

Летать будет, что пробовать?

**facepalm

забей

Попробую конечно оно не трудно. На кого? Спасибо. я в не так написал что?

ПриЗаписи ты должен добавить сам.

Вот проще самому сделать за 5 минут, чем объяснить.

Я тут

РС цены победил. Создал новый непериодический РС ЦеныНоменклатурыТекущие забил в них текущие цены через корректировку записей регистра. Добавил в ПриЗаписи РС ЦеныНоменклатуры запись в этот регистр. Большое спасибо Теперь тормозит РегистрНакопления.ТоварыВРезервеНаСкладах.Остатки. Без него 0,2 секунды. С ним 6,5-7 секунд. Какие есть идеи на эту тему?

эээ, брать оперативные остатки.

Набор измерений этого регистра, в том порядке, в котором они идут в конфигураторе - скинь.

ТоварыВРезервеНаСкладах.Период,     ТоварыВРезервеНаСкладах.Регистратор, Измерения     ТоварыВРезервеНаСкладах.СерияНоменклатуры Ресурсы     ТоварыВРезервеНаСкладах.Количество

exec sp_executesql N'INSERT INTO #tt3(_Q_001_F_000RRef, _Q_001_F_001)SELECT#V8TblAli1_Q_001_T_001._Fld13983RRef AS _Q_001_F_000RRef,#V8TblAli1_Q_001_T_001._Fld13985Balance AS _Q_001_F_001FROM(SELECT#V8TblAli1_T._Fld13983RRef AS _Fld13983RRef,CAST(SUM(#V8TblAli1_T._Fld13985Balance) AS NUMERIC(33,3)) AS _Fld13985BalanceFROM(SELECT_AccumRgT13988._Fld13983RRef AS _Fld13983RRef,CAST(SUM(_AccumRgT13988._Fld13985) AS NUMERIC(27,3)) AS _Fld13985BalanceFROM_AccumRgT13988 WITH(NOLOCK)WHERE_AccumRgT13988._Period = AND _AccumRgT13988._Fld13981RRef = @P2 AND _AccumRgT13988._Fld13984RRef = @P3 AND _AccumRgT13988._Fld20783RRef = @P4 AND _AccumRgT13988._Fld13983RRef IN (SELECT#T6efccf4913724000aa161161263761a0_Q_002_T_001._Q_000_F_000RRef AS _Q_002_F_000RRefFROM#tt1 #T6efccf4913724000aa161161263761a0_Q_002_T_001 WITH(NOLOCK))GROUP BY_AccumRgT13988._Fld13983RRefHAVINGCAST(SUM(_AccumRgT13988._Fld13985) AS NUMERIC(27,3)) <> CAST(@P5 AS NUMERIC(1,0))UNION ALLSELECT_AccumRg13980._Fld13983RRef AS _Fld13983RRef,CAST(CAST(SUM(CASEWHEN _AccumRg13980._RecordKind = CAST(0. AS NUMERIC(1,0))THEN - _AccumRg13980._Fld13985ELSE _AccumRg13980._Fld13985END) AS NUMERIC(21,3)) AS NUMERIC(28,3)) AS _Fld13985BalanceFROM_AccumRg13980 WITH(NOLOCK)WHERE_AccumRg13980._Period >= @P6 AND _AccumRg13980._Period < @P7 AND _AccumRg13980._Active = @P8 AND _AccumRg13980._Fld13981RRef = @P9 AND _AccumRg13980._Fld13984RRef = 0 AND _AccumRg13980._Fld20783RRef = 1 AND _AccumRg13980._Fld13983RRef IN (SELECT#T6efccf4913724000aa161161263761a0_Q_002_T_001._Q_000_F_000RRef AS _Q_002_F_000RRefFROM#tt1 #T6efccf4913724000aa161161263761a0_Q_002_T_001 WITH(NOLOCK))GROUP BY_AccumRg13980._Fld13983RRefHAVINGCAST(SUM(CASEWHEN _AccumRg13980._RecordKind = CAST(0. AS NUMERIC(1,0))THEN - _AccumRg13980._Fld13985ELSE _AccumRg13980._Fld13985END) AS NUMERIC(21,3)) <> CAST(2 AS NUMERIC(1,0))) #V8TblAli1_TGROUP BY#V8TblAli1_T._Fld13983RRefHAVINGCAST(SUM(#V8TblAli1_T._Fld13985Balance) AS NUMERIC(33,3)) <> CAST(3 AS NUMERIC(1,0))) #V8TblAli1_Q_001_T_001 CREATE INDEX TmpInd4 ON #tt3 (_Q_001_F_000RRef)',N' datetime2,@P2 varbinary,@P3 varbinary,@P4 varbinary,@P5 numeric,@P6 datetime2,@P7 datetime2,@P8 varbinary,@P9 varbinary,0 varbinary,1 varbinary,2 numeric,3 numeric','3999-11-01 00:00:00',0x97320013D4C1378811DC230B3208A700,0x00000000000000000000000000000000,0x00000000000000000000000000000000,0,'2017-01-24 00:00:00','3999-11-01 00:00:00',0x01,0x97320013D4C1378811DC230B3208A700,0x00000000000000000000000000000000,0x00000000000000000000000000000000,0,0 go

N    Имя метаданных    Назначение метаданных    Данные (КБ)    Индексы (КБ)    Свободно (КБ)    Зарезервировано всего (КБ)     Имя таблицы SQL    Кол-во строк                 РегистрНакопления.ТоварыВРезервеНаСкладах    Итоги    1 382 736    2 318 584    248    3 701 568 _AccumRgT13988    11 926 040

РегистрНакопления.ТоварыВРезервеНаСкладах    Основная    5 095 960    5 186 256    344    10 282 560 _AccumRg13980    35 671 670

передвинуть Измерение Номенклатура на позицию выше БЫ, НО.... ХЗ, как это отыграется на других запросах. Но можно ткнуть палкой.

И в УПП1.3 они так и сделали, передвинув Номенклатуру и Характеристику выше ДокументаРезерва, но, в УПП1.2 могли быть кривые запросы, завязанные на то, что ДокументРезерва выше, однако, в те далекие времена на это никто не морфировал. Поэтому я бы передвинул. Вместе с характеристикой.

Хотя, с другой стороны, если в группе 100500 номенклатур, sql сделает mergejoin и наша телодвижуха окажется бессмысленна.

Спасибо. Буду думать.

ткнуть! ткнуть! ткнуть! писсофкэйк!

Больше 100500 в два раза сейчас пока. Но быстро растет.

ДокументаРезерва составной. Ссылки на 10 документов.

Вопрос СвободныеОстатки в новых УППхах шустро работают? Кто нибудь переносил этот механизЪм в старые УПП?

Не проще перейти на УПП1.3 ?

"Имеется УПП 1.2 2007 года." 3 программиста денно и ношно 10 лет её пилили. Думаю не проще. Хотя такие мысли слышал. В любом случае не завтра.