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

SELECT
    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    Sum(ОстаткиТМЦОстатки.КоличествоОстаток) Количество
FROM (
select
rr405_vt.sp4062 as Фирма,
rr405_vt.sp408 as Номенклатура,
rr405_vt.sp418 as Склад,
rr405_vt.sp3117 as ЦенаПрод,
sum(rr405_vt.sp411) as КоличествоОстаток
from (
select
rg405_vt.sp4062,
rg405_vt.sp408,
rg405_vt.sp418,
rg405_vt.sp3117,
rg405_vt.sp411
from rg405 as rg405_vt (nolock)
where rg405_vt.period={d '2014-03-01'}
and ((rg405_vt.sp4062 = '     2   ')         AND (rg405_vt.sp418 = '     6   ')         AND (rg405_vt.sp408 IN (

            SELECT DISTINCT СтрокиДокумента.sp1599 [rg405_vt.sp408 $Справочник.Номенклатура]
            FROM dt1611 AS СтрокиДокумента With (NOLOCK)
            WHERE (СтрокиДокумента.IDDOC = ' 69AFN   ')
)))
union all
select
ra405_vt.sp4062,
ra405_vt.sp408,
ra405_vt.sp418,
ra405_vt.sp3117,
case ra405_vt.debkred when 0 then ra405_vt.sp411 else -ra405_vt.sp411 end
from ra405 as ra405_vt (nolock)
inner join _1sjourn as j405_vt (nolock) on j405_vt.iddoc = ra405_vt.iddoc
where j405_vt.date_time_iddoc > '20140401' and j405_vt.date_time_iddoc < '201404255ODW9C 69AFMЯЯЯ'
and j405_vt.rf405 = 0x1
and ((ra405_vt.sp4062 = '     2   ')         AND (ra405_vt.sp418 = '     6   ')         AND (ra405_vt.sp408 IN (

            SELECT DISTINCT СтрокиДокумента.sp1599 [ra405_vt.sp408 $Справочник.Номенклатура]
            FROM dt1611 AS СтрокиДокумента With (NOLOCK)
            WHERE (СтрокиДокумента.IDDOC = ' 69AFN   ')
)))
) as rr405_vt
group by
rr405_vt.sp4062,
rr405_vt.sp408,
rr405_vt.sp418,
rr405_vt.sp3117
having
sum(rr405_vt.sp411) <> 0
) as ОстаткиТМЦОстатки
GROUP BY
    ОстаткиТМЦОстатки.Номенклатура

Причем если убрать условие по списку номенклатуры из второго подзапроса, то выполняется за 2 сек, если оставить, то 53 сек. Подскажите что можно глянуть? Фрагментация индекса таблицы DT1611 0.01.

Сам запрос

SELECT DISTINCT СтрокиДокумента.sp1599 [ra405_vt.sp408 $Справочник.Номенклатура]
            FROM dt1611 AS СтрокиДокумента With (NOLOCK)
            WHERE (СтрокиДокумента.IDDOC = ' 69AFN   ')

формируется быстро

кто в итоге победил?

(51) 7 секунд ? Это непростительно долго.

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

(54) судя по всему, ОстаткиТМЦ

(55) там вообще всё мгновенно должно выполняться

самая "легкая" табличка регистра

И это, как и чем делается замер выполнения запроса ?..

(58) замер делается в СКЛ запросом, который выполняется в профайлере. Индекс скан по таблице _1SJourn. Если неделю назад документ проводился  за секунду в базе монопольно, то сейчас стал почти минуту. Остатки ТМЦ около 6-7 секунд, Партии 10-11. Как узнать закрывается регистр или нет? По ргистру остатков быстро данные получает, а вот обороты хромают.

(59) раньше работали в терминале, сейчас - локально...??? или м.б. посмотри как путь к базе в стартере прописан?

(59) Ну и что произошло за эту неделю? Перепроводили, меняли сеть, сервер, терминал-локально, ... ?
Закрываются или нет легко проверить - выгрузи итоги или отчетом универсальным посмотри
Может быть надо переиндексировать, смахнуть пыль

(60)Большая часть работает в терминале
(61)Документы проводятся каждый день массово, сервер не меняли. Реиндексация каждое воскресенье делается, но в этот раз с ошибкой вывалилась. ПОпробую попросить время запустить чтобы.

(61)А по весу табличек регистров не смогу определить закрыт он или нет?
Где то в инете натыкался, но там для ДБФ было вроде.
А как отчетом универсальным посмотреть, подскажи пжл, ато не соображу?

(62) Кстати, для обслуживания индексов и статистик есть такой замечательный скрипт  http://infostart.ru/public/256292/
В рабочее время можно запустить его в режиме сбора статистик.

Что касается незакрываемости регистров, то врядли это твой случай - тогда пухнет табличка RG, а у тебя что-то странное с RA/_1sjourn. Типа, вдруг резко увеличилось количество движений.
Ещё кстати: а что там с "degree of parallellism"? оно иногда весьма неожиданный эффект даёт.

(64)Вобщем выставил галку Быстрая обработка движений у регистров Остатки и Партии.
Переписал условие по списку номенклатуры через MetaDataWork чтобы исключить временные таблицы и джойн с журналом. В итоге запрос по остаткам выполняется 5 сек.
Узкое место все также показывает Индекс скан.
Максимальная степень параллелизма - 1.
Скрипт скачаю, запущу, посмотрим что покажет. Только какие параметры там выставлять надо? Как на примере?

(65) на самом деле я наврал про проблемы с RA - расклад в процентах нормальный, в RA действительно данных больше. Ради интереса посмотрел расклад и время на тестовой базе (около 10тыс. движений в мес.)  - в процентах расклад похожий, время - меньше секунды.
5 сек - это правда что-то запредельное.

(66)Вот уже не знаю куда копать. Скрипт запущу на тестовой, посмотрю что выдаст.

(65) индекс скан по какой табличке ?

(68)по таблице RA и у Остатков и у Партий

Текст запроса сейчас какой хоть ?

(70)Который в профайлере или в 1С?

lf lfdfq b njn b njn

ТекстЗапроса = "
    |SELECT
    |    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    |    Sum(ОстаткиТМЦОстатки.КоличествоОстаток) Количество
    |FROM $РегистрОстатки.ОстаткиТМЦ(:КонДата~,,
    |        (Фирма = :Фирма)
    |        AND (Номенклатура IN (Select Val FROM #СписокНоменклатуры))
    |        AND (Склад = :Склад),,
    |        Количество) AS ОстаткиТМЦОстатки
    |GROUP BY
    |    ОстаткиТМЦОстатки.Номенклатура
    |";

SELECT
    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    Sum(ОстаткиТМЦОстатки.КоличествоОстаток) Количество
FROM (
select
rr405_vt.sp4062 as Фирма,
rr405_vt.sp408 as Номенклатура,
rr405_vt.sp418 as Склад,
rr405_vt.sp3117 as ЦенаПрод,
sum(rr405_vt.sp411) as КоличествоОстаток
from (
select
rg405_vt.sp4062,
rg405_vt.sp408,
rg405_vt.sp418,
rg405_vt.sp3117,
rg405_vt.sp411
from rg405 as rg405_vt (nolock)
where rg405_vt.period={d '2014-03-01'}
and ((rg405_vt.sp4062 = '     2   ')         AND (rg405_vt.sp408 IN (Select Val FROM #СписокНоменклатуры)))
union all
select
ra405_vt.sp4062,
ra405_vt.sp408,
ra405_vt.sp418,
ra405_vt.sp3117,
case ra405_vt.debkred when 0 then ra405_vt.sp411 else -ra405_vt.sp411 end
from ra405 as ra405_vt (nolock)
where ra405_vt.date_time_iddoc > '20140401' and ra405_vt.date_time_iddoc < '201404298FCZV4 6AIESЯЯЯ'
and ((ra405_vt.sp4062 = '     2   ')         
AND (ra405_vt.sp408 IN (Select Val FROM #СписокНоменклатуры))
)
) as rr405_vt
group by
rr405_vt.sp4062,
rr405_vt.sp408,
rr405_vt.sp418,
rr405_vt.sp3117
having
sum(rr405_vt.sp411) <> 0
) as ОстаткиТМЦОстатки
GROUP BY
    ОстаткиТМЦОстатки.Номенклатура

Выкинь гроупбай из текста запроса и сумму, воткни (Номенклатура) в параметры виртуальной таблицы + условия в ВТ задай в том же порядке, что и измерения в регистре

и.. странно, что примитив с debkred  в ВТ реализован через case, а не просто через умножение.
Это, 1cpp какой хоть версии у тебя ?

(75) не тот видимо копировал запрос, вот текущий
ТекстЗапроса = "
    |SELECT
    |    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    |    (ОстаткиТМЦОстатки.КоличествоОстаток) Количество
    |FROM $РегистрОстатки.ОстаткиТМЦ(:КонДата~,,
    |        (Фирма = :Фирма)
    |        AND (Номенклатура IN (Select Val FROM #СписокНоменклатуры))
    |        AND (Склад = :Склад)
    |,Номенклатура,
    |        Количество) AS ОстаткиТМЦОстатки
    |";

(76)Версия DLL 2.5.0.8

(76) debkred через case в любой версии 1cpp

(78) странно, а чего так ?

(79) есть существенная разница?

еще, чтобы вместо условий
period={d '2014-03-01'}
date_time_iddoc > '20140401' and date_time_iddoc < '201404298FCZV4 6AIESЯЯЯ'

было что то типа:
period={d '2014-04-01'}
date_time_iddoc > '201404298FCZV4 6AIESЯЯЯ' and date_time_iddoc < '20140501'

в модуле проведения допускается использовать
ОбратныйРасчетОтТА(1)

(80) ага, религиозные убеждения :)

я бы на месте автора воткнул быструю обработку движений по измерению Номенклатура и вернул фильтр по $ДокументСтроки

(83) слушай, лень профайлер открывать, при указании конкретного измерения в параметрах ВТ, вт же не разворачивается в запрос, как в (74) , т.е по всем измерениям ?..

(84) ага. Там и профайлера не надо, достаточно select *

(84) нет, не разворачивается
(74) не соответствует (77)

(86) я так и знал :)

что одна из черепашек врёт.

ну и про выполнение запроса в 5 секунд.. тоже не верится, не ясно, как автор делал замер.

сдаётся, что это не время выполнения запроса, а время еще чего - например, показа тз через выбратьстроку, еще чего.. хз в общем

(90) типизация 100500 строк номенклатуры?

(91) ну не знаю, всё равно не 5 секунд :)

(90)
пЗапрос = СоздатьОбъект("ODBCRecordSet");
    ТекстЗапроса = "
    |SELECT
    |    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    |    (ОстаткиТМЦОстатки.КоличествоОстаток) Количество
    |FROM $РегистрОстатки.ОстаткиТМЦ(:КонДата~,,
    |        (Фирма = :Фирма)
    |        AND (Номенклатура IN (Select Val FROM #СписокНоменклатуры))
    |        AND (Склад = :Склад)
    |,Номенклатура,
    |        Количество) AS ОстаткиТМЦОстатки
    |";

пЗапрос.УстановитьТекстовыйПараметр("КонДата", СформироватьПозициюДокумента(Конт.ТекущийДокумент(), -1));
    пЗапрос.УстановитьТекстовыйПараметр("Фирма", Фирма);
    пЗапрос.УстановитьТекстовыйПараметр("Склад", Склад);
    
    СписокНоменклатуры = СоздатьОбъект("СписокЗначений");
    Конт.ВыгрузитьТабличнуюЧасть(СписокНоменклатуры, "Номенклатура");
    пЗапрос.УложитьСписокОбъектов(СписокНоменклатуры, "#СписокНоменклатуры", "Номенклатура");
    
    пЗапрос.Отладка(1);
    Сообщить(ТекущееВремя());
    пТЗ = пЗапрос.ВыполнитьИнструкцию(ТекстЗапроса);
    Сообщить(ТекущееВремя());

Выдает

11:44:54

SELECT
    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    (ОстаткиТМЦОстатки.КоличествоОстаток) Количество
FROM (
select
rr405_vt.sp408 as Номенклатура,
sum(rr405_vt.sp411) as КоличествоОстаток
from (
select
rg405_vt.sp408,
rg405_vt.sp411
from rg405 as rg405_vt (nolock)
where rg405_vt.period={d '2014-03-01'}
and ((rg405_vt.sp4062 = '     2   ')         AND (rg405_vt.sp408 IN (Select Val FROM #СписокНоменклатуры))         AND (rg405_vt.sp418 = '     6   '))
union all
select
ra405_vt.sp408,
case ra405_vt.debkred when 0 then ra405_vt.sp411 else -ra405_vt.sp411 end
from ra405 as ra405_vt (nolock)
where ra405_vt.date_time_iddoc > '20140401' and ra405_vt.date_time_iddoc < '201404255IQX5S 69A9KЯЯЯ'
and ((ra405_vt.sp4062 = '     2   ')         AND (ra405_vt.sp408 IN (Select Val FROM #СписокНоменклатуры))         AND (ra405_vt.sp418 = '     6   '))
) as rr405_vt
group by
rr405_vt.sp408
having
sum(rr405_vt.sp411) <> 0
) as ОстаткиТМЦОстатки

11:45:01

_GetPerformanceCounter() точнее
Тут все может быть по-разному, т.к. кешируется
А вообще посмотри план выполнения
Но думаю лучше навести порядок как я писал ранее

(89)индекс-скан по индексу DATETIME на периоде в месяц при большом количестве движений может и 5 и более секунд делаться

(95)4 раза выполнил запрос с _GetPerformanceCounter, выполняется все дольше и дольше: 8141, 8818, 12616 и 14724

(96) а чего скан ?

(97) порядок измерений в регистре какой хоть ?

(99) Фирма, Номенклатура, Склад, ЦенаПрод

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

Так, сколько ?

    ТекстЗапроса = "
    |SELECT
    |    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    |    (ОстаткиТМЦОстатки.КоличествоОстаток) Количество
    |FROM $РегистрОстатки.ОстаткиТМЦ(:КонДата~,,
    |        (Фирма = :Фирма)
    |        AND (Склад = :Склад)
    |,Номенклатура,
    |        Количество) AS ОстаткиТМЦОстатки
    | where Номенклатура IN (Select Val FROM #СписокНоменклатуры)
    |";

+102 ну и совет с ОбратныйРасчетОтТА(1) сделал ?

ну и это, воткни turbomd наконец (чтоб на лету модули править) и  обнови 1cpp до последней.

(102)Выполнил 4 раза также: 15072, 11102, 11421, 10420
(103)Если у меня ТА на 30 число, а док на 25 это не помешает?
(104)Щас база восстановится тестовая, буду там пробовать.

>>> у меня ТА на 30 число

Нахрена ты её туда задвинул ?!

(105) задвинь ТА на конец года. а лучше - лет на 100....

(106)Иначе доки не проводятся, много документов на 23:59:59

(106)не существенно, мы же рассматриваем проведение не актульного документа.

(109) ? та ну ? у него щас все доки в заднем числе :) ну и шерстить ra как то не очень.. тем более, записи целого месяца.

а так, в потоке бы проводил и привет

(110) "у него щас все доки в заднем числе :)"
кто сказал?.. не факт

(108) зачем ты их туда задвинул ?

(112) ну как это не факт ? ТА то он вперёд толканул, в 30 число, а проводит 25-е

+ расчет не от ТА стоял, целый месяц напрягать ра приходится запросу.

(111) проводил бы в потоке - не дергалась бы ra вообще - не возникло бы проблемы, не пришлось бы исследовать

ну , точнее 25 дней :)

(116) я за то и говорю, нахрена он та задвинул вперёд ?
:))

(114) ааа я тебя не правильно понял
"у него щас все доки в заднем числе :" - я подумал, ты про то, что все доки 30

А так, период 5 дней.. и можно вообще забыть, где там ТА..

(113)Если у текущего непроведенного документа дату поменять на 5 дней вперед, то время меняется же? Либо при записи ставить время документа?

у мну тоже доки разрешено проводить будущей датой.
и текущее проведение всегда неактуальное
живу спокойно, все проводится моментально
(периодичность итогов - месяц)

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

(123) для начала, (81) и (103) сделай...

(124)Попробовал в обработке: 302, 298, 297, 317. Конт указал просто ссылку на документ.
Только какие могут быть последствия?

+(125)Я только не пойму, если у меня нет итогов еще на 1 мая, как результат то корректный получается?

(126) че ?..

(125) "Только какие могут быть последствия?"
никаких, кроме ускорения
Но замечу, что ОбратныйРасчетОтТА можно применять только в модуле проведения, либо в иной транзакции с блокировкой проведения документов

(126) итоги на начало 1 мая = итогам на конец 30 апреля. Логично же.
А итоги на конец апреля как раз таки записаны тут period={d '2014-04-01'}

(128)Т.е. в глобальнике при проведении можно смело использовать?
(129)Не пойму, тогда зачем движения еще с 25 по 30 апреля?

art_id, sql сервер какой версии?

(131)2005

(130) глобальник не причем. при проведении - да

Движения 25-30 _вычитаются_ из итогов на конец 30апр
Иначе, движения 1-25 прибавляются к итогам на начало 1апр
Посмотри внимательно в отладочные запросы. Обрати внимание на даты и знаки

+ на знаки в этом выражении case ra405_vt.debkred when 0 then ra405_vt.sp411 else -ra405_vt.sp411 end

(133)Увидел, спс

(129) только одно непонятно - почему для итогов на конец месяца выбрано первое число....

(130)
2. останки не на ТА вычисляются как предыдущий остаток + (приход - расход до нужной даты), либо останки на ТА - движения до документа..

(134) а почему все-таки кейс, а не умножение?

(136) наверно потому что первое во всех месяцах первое, а последнее - разное

(138) выше сказано - религия наверно

(137)НЕ обратил внимание что в первом случае складываются, а во втором вычитаются.
Попробую сегодня скрипт запустить из (64), странно что ни с того ни с сего вдруг стал долго выполняться запрос.

надо бы как-нить померить скорость с кейсом и без..

(139) Ну, фактически же это остатки на начало следующего? я бы взял первое число следующего....
хотя твоя логика тоже

(138) это реально вопрос религии: я проверял на несколькоих миллионах записей - разница в рамках статистической погрешности.

(141) нехрен ТА вперёд загонять.
Раньше документы в "потоке" проводились и запрос просто обращался к одной табличке - к RG.. а сейчас молотит еще и тяжелую RA

(140) другая (моя) версия, автор ВТ подсмотрел это у самих одинесовцев

(143)ага, а что брать для периодичности 5 дней, к примеру ? :)

(144) ок, спасибо. я не проверял на больших объемах.
Хотя кейс - он читабельнее для человека, поэтому раз не быстрее - значит, правильнее.

(147) убил.

(145)всегда ТА была на 7 дней макс вперед установлена

(142) ничего не выявишь.даже померить проблематично.
как бы case более правильней с точки зрения неявного преобразования типов. ну если так нравиться умножение то пиши
в нем явное преобразование типов.