Имя: Пароль:
1C
1C 7.7
v7: Долго выполняется прямой запрос
, ,
0 art_id
 
28.04.14
10:00
Стали долго проводится документы, в районе минуты на прямых запросах. Томоза на получениях остатков и партий. Начал смотреть на примере остатков, в скуль передается вот такой запрос

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   ')

формируется быстро
1 mikecool
 
28.04.14
10:01
тыб лучше просто запрос привел
2 Ёпрст
 
28.04.14
10:01
как минимум, выкинуть DISTINCT везде, это для начала
3 mikecool
 
28.04.14
10:02
и так еще - нафейхоа выбирать во вложенном запросе полей больше, нежели требуется в результате?
4 Ёпрст
 
28.04.14
10:02
во вторых, выкинуть типизацию из подзапроса..
5 xXeNoNx
 
28.04.14
10:02
Вообще вложенные вопросы и IN работает медленнее чем временные ьаблицы
6 mikecool
 
28.04.14
10:03
(5) сравнивать надо
7 an-korot
 
28.04.14
10:03
странно почему до сих пор нет группы sql для таких случаев?
8 Ёпрст
 
28.04.14
10:03
потом, установить галку "быстрая обработка движений" у регистра и из текста запроса выкинуть соединение с
_1sjourn
9 Ёпрст
 
28.04.14
10:04
(5) брехня
10 art_id
 
28.04.14
10:07
(8)Если я установлю галку то 1С не будет джойнить таблицу регистра с журналом когда запрос передает? Или мне самому как-то надо будет указать?
11 Ёпрст
 
28.04.14
10:11
(10) ты этот запрос откуда взял то хоть ?
Исходный текст запроса в студию.
12 Mikeware
 
28.04.14
10:12
(10) у тебя позиция уже в самом регистре будет, в движениях. поэтому джойнить не нужно будет.
13 Mikeware
 
28.04.14
10:12
(11)из профайлера у него запрос.
а в исходном - это ВТОстатки.
14 art_id
 
28.04.14
10:13
(11)ТекстЗапроса = "
    //|SET @Номенклатура = ?
    |SELECT
    |    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    |    Sum(ОстаткиТМЦОстатки.КоличествоОстаток) Количество
    |FROM $РегистрОстатки.ОстаткиТМЦ(:КонДата~,,
    |        (Фирма = :Фирма)
    |        AND (Склад = :Склад)
    |        AND (Номенклатура IN (
    |            SELECT DISTINCT $СтрокиДокумента.Номенклатура [Номенклатура $Справочник.Номенклатура]
    |            FROM $ДокументСтроки." + "Реализация" + " AS СтрокиДокумента With (NOLOCK)
    |            WHERE (СтрокиДокумента.IDDOC = :Конт)
    |)),,
    |        Количество) AS ОстаткиТМЦОстатки
    |GROUP BY
    |    ОстаткиТМЦОстатки.Номенклатура
    |";
15 Ёпрст
 
28.04.14
10:13
(13) это понятно, просто он туда еще соединений своих напихал..
16 art_id
 
28.04.14
10:14
Причем так быстрее
17 Ёпрст
 
28.04.14
10:14
(14)
выкини дистиникт и типизацию!
18 art_id
 
28.04.14
10:15
|SELECT
    |    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    |    Sum(ОстаткиТМЦОстатки.КоличествоОстаток) Количество
    |FROM $РегистрОстатки.ОстаткиТМЦ(:КонДата~,,
    |        (Фирма = :Фирма)
    |        AND (Склад = :Склад)
    |        AND (Номенклатура IN (Select Val FROM #СписокНоменклатуры
    |)),,
    |        Количество) AS ОстаткиТМЦОстатки
    |GROUP BY
    |    ОстаткиТМЦОстатки.Номенклатура
19 art_id
 
28.04.14
10:16
(17)выкинул, не помогло
20 ADirks
 
28.04.14
10:33
Я бы условие наружу вытащил, серверу так проще будет.
21 art_id
 
28.04.14
10:35
(20)Не в параметрах ВТ чтоли условие наложить? Просто через Where?
22 Ёпрст
 
28.04.14
10:37
воткнуть галку быстрая обработка движений, в параметрах ВТ воткнуть только измерение (Номенклатура), выкинуть GROUP BY из текста запроса
23 ADirks
 
28.04.14
10:37
(21) да
когда оно в параметрах ВТ, то этот запрос будет гарантировано 2 раза выполняться
24 art_id
 
28.04.14
10:43
(22) На тестовой поставлю галку, посмотрим сколько будет обрабатываться регистр

Сделал так, не утешительно тоже.

|SELECT
    |    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    |    (ОстаткиТМЦОстатки.КоличествоОстаток) Количество
    |FROM $РегистрОстатки.ОстаткиТМЦ(:КонДата~,,
    |        (Фирма = :Фирма)
    |        AND (Склад = :Склад)
    |,Номенклатура,
    |        Количество) AS ОстаткиТМЦОстатки
    |Where    ОстаткиТМЦОстатки.Номенклатура IN (        SELECT  $СтрокиДокумента.Номенклатура
    |            FROM $ДокументСтроки.Реализация AS СтрокиДокумента With (NOLOCK)
    |            WHERE (СтрокиДокумента.IDDOC = :Конт))";
25 Ёпрст
 
28.04.14
10:46
помимо галки можно еще ускорить
26 art_id
 
28.04.14
10:47
(25)как?
27 art_id
 
28.04.14
10:48
+(26)я так понимаю можно еще поменять порядок измерений в регистре, сильно поможет?
28 Ёпрст
 
28.04.14
10:49
(26) изменить периодичность хранения итогов. Выставить 5 дней.
29 Z1
 
28.04.14
11:23
(26) если речь идет об остатках текущего дня
то вместо
остаки на начало периода + оствтки до документа

надо считать
остатки след период - (остатки от тек документа до конца месяца )



не знаю вроде это должно быть заложено в вирт функции но точно сказать не могу.
30 viktor_vv
 
28.04.14
11:29
"Стали долго проводится документы" - а после каких действий стали проводится долго ? Я так понял, что было все хорошо и внезапно стали проводится долго.
31 viktor_vv
 
28.04.14
11:30
*проводиться
32 НеБорис Нуралиев
 
28.04.14
11:34
(27) С изменением порядка осторожнее. Стандартные функции получения остатков из регистров могут перестать работать.

Вообще запрос у тебя нормальный в (24) стал. Перезагрузи SQL, или очисти процедурный кеш. После этого советую план запроса посмотреть - там ты и увидишь узкие места.
33 НеБорис Нуралиев
 
28.04.14
11:38
(24) Еще лучше всего фильтр делать в порядке измерений регистра. Тогда попадешь в индекс. Попробуй поменять условия склада и номенклатуры местами. Должно помочь.
34 Mikeware
 
28.04.14
11:39
(29) в виртуальной таблице это есть....
35 art_id
 
28.04.14
11:56
(32)Порядок в фильтре поменял. План выполнения показывает что 46% уходит на Clustered Index Scan. Чистка кеша на тестовой базе помогла немного. Видимо людей выгонять надо из базы чтобы почистить чтоли. Делаю командой  DBCC FLUSHPROCINDB(@DatabaseID)
36 НеБорис Нуралиев
 
28.04.14
12:07
(35) Если порядок фильтров по измерениям, то должен быть Index Seek.

Статистика обновлена?
37 viktor_vv
 
28.04.14
12:09
(35) Порядок в фильтре в запросе до лампочки. Важен порядок измерений регистра в конфигураторе.
Но изменение чревато (32).
38 Z1
 
28.04.14
12:11
(34) ну там по моему сравнение идет по 15 число
но в данно м случае лучше переписать как в (29) без вирт функции ,чтобы всегда так считалось

(10) непонятно галку на отбор по движению товаров поставил ?



Как бы ставь галку на движение товаров
и пиши (29) сам руками с учетом что тебе не нужна _1sjourn - и будет тебе счастье.
(но с другой стороны галка немного замедлит перепроведение
документа)  должен решить что важнее тебе решать.
39 viktor_vv
 
28.04.14
12:12
(35) Напиши сюда порядок измерений регистра из конфигуратора.
40 viktor_vv
 
28.04.14
12:13
(37)+ Хотя на какой таблице идет "Clustered Index Scan" ?
41 DrZombi
 
гуру
28.04.14
12:13
(35) В запросе (24) добавь отбор по нужной тебе номенклатуре :)
42 DrZombi
 
гуру
28.04.14
12:14
+(41) Ведь твой документ же двигает только мелкую долю номенклатуры, а не всю БД за 1 сек :DDD
43 viktor_vv
 
28.04.14
12:16
(41) В пероначальном варианте у него и было в параметрах ВТ условие на номенклатура.
44 art_id
 
28.04.14
12:16
(38)Галку поставил на тестовой, но пока регистр обрабатывает, записей там не мало
45 art_id
 
28.04.14
12:19
(39)Фирма, Номенклатура, СКлад, ЦенаПрод
(40)На таблице _1SJourn. Сейчас выполнил запрос на рабоей к регистру партий, показывает ПОиск ключа по таблице _1SJourn 51%. Index Scan по таблице RA405(Регистр Партии) 23%
46 viktor_vv
 
28.04.14
12:34
(44) Галку какую поставил ? Быстрая обработка движений для регистра или Отбор движений на измерении Номенклатура?
Первый вариант должен точно помочь.
47 art_id
 
28.04.14
12:37
(46)Быстрая обработка движений, но регистр еще обрабатывается. Ночью поставлю на рабочей базе, посмотрим сколько будет обрабатывать.
48 leshikkam
 
28.04.14
13:00
Надо добавить самому индекс по IDDOC+sp1599 для табличной части документа.
49 DrZombi
 
гуру
28.04.14
13:04
(43) >>> Номенклатура IN (
    |            SELECT DISTINCT $СтрокиДокумента.Номенклатура [Номенклатура $Справочник.Номенклатура]
    |            FROM $ДокументСтроки." + "Реализация" + " AS СтрокиДокумента With (NOLOCK)
    |            WHERE (СтрокиДокумента.IDDOC = :Конт)

Ты про это?
Это же кто так пишет?
Он же Тупо отбирает все из Документа Реализации, по Табличной части :)
При этом, это скорей всего Тот же самый документ, который и проводится.
А если он Новый и еще не записан? :)
50 viktor_vv
 
28.04.14
15:04
(49) Да, это.
Ему как бы и нужна вся табличная часть в условие. Что быстрее, создать временную таблицу или отобрать по индексу спорный вопрос. Хотя сам склоняюсь к УложитьОбъекты().
Этот код, скорее всего, в модуле документа выполняется при проведении, он никак не может быть НЕ записан к этому моменту.
51 art_id
 
28.04.14
15:22
(50)Уложить объекты немного быстрее работает, использую его. Да, код выполняется при проведении.
ПРоставил галки Быстрая обработка движений у Остатков и Партий на тестовой базе.
Запрос на получение остатков стал выполняться 7 сек, План выполнения говорит что Clustered index scan в таблице регистра 88%. Фрагментация индексов у регистра не указана вобще.
52 dk
 
28.04.14
15:30
кто в итоге победил?
53 Ёпрст
 
28.04.14
15:59
(51) 7 секунд ? Это непростительно долго.
54 Ёпрст
 
28.04.14
16:02
регистры поди еще и не закрыты.. 7 секунд, это по останкам на складах или по партиям ?
индекс скан по какой табличке ?
55 Mikeware
 
28.04.14
16:03
(54) судя по всему, ОстаткиТМЦ
56 Ёпрст
 
28.04.14
16:14
(55) там вообще всё мгновенно должно выполняться
57 Ёпрст
 
28.04.14
16:15
самая "легкая" табличка регистра
58 Ёпрст
 
28.04.14
16:19
И это, как и чем делается замер выполнения запроса ?..
59 art_id
 
28.04.14
19:36
(58) замер делается в СКЛ запросом, который выполняется в профайлере. Индекс скан по таблице _1SJourn. Если неделю назад документ проводился  за секунду в базе монопольно, то сейчас стал почти минуту. Остатки ТМЦ около 6-7 секунд, Партии 10-11. Как узнать закрывается регистр или нет? По ргистру остатков быстро данные получает, а вот обороты хромают.
60 Злопчинский
 
28.04.14
21:42
(59) раньше работали в терминале, сейчас - локально...??? или м.б. посмотри как путь к базе в стартере прописан?
61 КонецЦикла
 
28.04.14
22:07
(59) Ну и что произошло за эту неделю? Перепроводили, меняли сеть, сервер, терминал-локально, ... ?
Закрываются или нет легко проверить - выгрузи итоги или отчетом универсальным посмотри
Может быть надо переиндексировать, смахнуть пыль
62 art_id
 
29.04.14
03:09
(60)Большая часть работает в терминале
(61)Документы проводятся каждый день массово, сервер не меняли. Реиндексация каждое воскресенье делается, но в этот раз с ошибкой вывалилась. ПОпробую попросить время запустить чтобы.
63 art_id
 
29.04.14
03:49
(61)А по весу табличек регистров не смогу определить закрыт он или нет?
Где то в инете натыкался, но там для ДБФ было вроде.
А как отчетом универсальным посмотреть, подскажи пжл, ато не соображу?
64 ADirks
 
29.04.14
06:48
(62) Кстати, для обслуживания индексов и статистик есть такой замечательный скрипт  http://infostart.ru/public/256292/
В рабочее время можно запустить его в режиме сбора статистик.

Что касается незакрываемости регистров, то врядли это твой случай - тогда пухнет табличка RG, а у тебя что-то странное с RA/_1sjourn. Типа, вдруг резко увеличилось количество движений.
Ещё кстати: а что там с "degree of parallellism"? оно иногда весьма неожиданный эффект даёт.
65 art_id
 
29.04.14
07:11
(64)Вобщем выставил галку Быстрая обработка движений у регистров Остатки и Партии.
Переписал условие по списку номенклатуры через MetaDataWork чтобы исключить временные таблицы и джойн с журналом. В итоге запрос по остаткам выполняется 5 сек.
Узкое место все также показывает Индекс скан.
Максимальная степень параллелизма - 1.
Скрипт скачаю, запущу, посмотрим что покажет. Только какие параметры там выставлять надо? Как на примере?
66 ADirks
 
29.04.14
07:26
(65) на самом деле я наврал про проблемы с RA - расклад в процентах нормальный, в RA действительно данных больше. Ради интереса посмотрел расклад и время на тестовой базе (около 10тыс. движений в мес.)  - в процентах расклад похожий, время - меньше секунды.
5 сек - это правда что-то запредельное.
67 art_id
 
29.04.14
07:31
(66)Вот уже не знаю куда копать. Скрипт запущу на тестовой, посмотрю что выдаст.
68 Ёпрст
 
29.04.14
09:05
(65) индекс скан по какой табличке ?
69 art_id
 
29.04.14
09:22
(68)по таблице RA и у Остатков и у Партий
70 Ёпрст
 
29.04.14
10:17
Текст запроса сейчас какой хоть ?
71 art_id
 
29.04.14
10:29
(70)Который в профайлере или в 1С?
72 Ёпрст
 
29.04.14
10:35
lf lfdfq b njn b njn
73 art_id
 
29.04.14
10:38
ТекстЗапроса = "
    |SELECT
    |    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    |    Sum(ОстаткиТМЦОстатки.КоличествоОстаток) Количество
    |FROM $РегистрОстатки.ОстаткиТМЦ(:КонДата~,,
    |        (Фирма = :Фирма)
    |        AND (Номенклатура IN (Select Val FROM #СписокНоменклатуры))
    |        AND (Склад = :Склад),,
    |        Количество) AS ОстаткиТМЦОстатки
    |GROUP BY
    |    ОстаткиТМЦОстатки.Номенклатура
    |";
74 art_id
 
29.04.14
10:39
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
    ОстаткиТМЦОстатки.Номенклатура
75 Ёпрст
 
29.04.14
10:42
Выкинь гроупбай из текста запроса и сумму, воткни (Номенклатура) в параметры виртуальной таблицы + условия в ВТ задай в том же порядке, что и измерения в регистре
76 Ёпрст
 
29.04.14
10:45
и.. странно, что примитив с debkred  в ВТ реализован через case, а не просто через умножение.
Это, 1cpp какой хоть версии у тебя ?
77 art_id
 
29.04.14
10:48
(75) не тот видимо копировал запрос, вот текущий
ТекстЗапроса = "
    |SELECT
    |    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    |    (ОстаткиТМЦОстатки.КоличествоОстаток) Количество
    |FROM $РегистрОстатки.ОстаткиТМЦ(:КонДата~,,
    |        (Фирма = :Фирма)
    |        AND (Номенклатура IN (Select Val FROM #СписокНоменклатуры))
    |        AND (Склад = :Склад)
    |,Номенклатура,
    |        Количество) AS ОстаткиТМЦОстатки
    |";

(76)Версия DLL 2.5.0.8
78 trad
 
29.04.14
10:50
(76) debkred через case в любой версии 1cpp
79 Ёпрст
 
29.04.14
11:18
(78) странно, а чего так ?
80 trad
 
29.04.14
11:22
(79) есть существенная разница?
81 trad
 
29.04.14
11:25
еще, чтобы вместо условий
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)
82 Ёпрст
 
29.04.14
11:28
(80) ага, религиозные убеждения :)
83 trad
 
29.04.14
11:34
я бы на месте автора воткнул быструю обработку движений по измерению Номенклатура и вернул фильтр по $ДокументСтроки
84 Ёпрст
 
29.04.14
11:36
(83) слушай, лень профайлер открывать, при указании конкретного измерения в параметрах ВТ, вт же не разворачивается в запрос, как в (74) , т.е по всем измерениям ?..
85 Mikeware
 
29.04.14
11:37
(84) ага. Там и профайлера не надо, достаточно select *
86 trad
 
29.04.14
11:38
(84) нет, не разворачивается
(74) не соответствует (77)
87 Ёпрст
 
29.04.14
11:39
(86) я так и знал :)
88 Ёпрст
 
29.04.14
11:39
что одна из черепашек врёт.
89 Ёпрст
 
29.04.14
11:40
ну и про выполнение запроса в 5 секунд.. тоже не верится, не ясно, как автор делал замер.
90 Ёпрст
 
29.04.14
11:41
сдаётся, что это не время выполнения запроса, а время еще чего - например, показа тз через выбратьстроку, еще чего.. хз в общем
91 Mikeware
 
29.04.14
11:41
(90) типизация 100500 строк номенклатуры?
92 Ёпрст
 
29.04.14
11:45
(91) ну не знаю, всё равно не 5 секунд :)
93 art_id
 
29.04.14
11:45
(90)
пЗапрос = СоздатьОбъект("ODBCRecordSet");
    ТекстЗапроса = "
    |SELECT
    |    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    |    (ОстаткиТМЦОстатки.КоличествоОстаток) Количество
    |FROM $РегистрОстатки.ОстаткиТМЦ(:КонДата~,,
    |        (Фирма = :Фирма)
    |        AND (Номенклатура IN (Select Val FROM #СписокНоменклатуры))
    |        AND (Склад = :Склад)
    |,Номенклатура,
    |        Количество) AS ОстаткиТМЦОстатки
    |";

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

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
95 КонецЦикла
 
29.04.14
11:47
_GetPerformanceCounter() точнее
Тут все может быть по-разному, т.к. кешируется
А вообще посмотри план выполнения
Но думаю лучше навести порядок как я писал ранее
96 trad
 
29.04.14
11:48
(89)индекс-скан по индексу DATETIME на периоде в месяц при большом количестве движений может и 5 и более секунд делаться
97 art_id
 
29.04.14
11:54
(95)4 раза выполнил запрос с _GetPerformanceCounter, выполняется все дольше и дольше: 8141, 8818, 12616 и 14724
98 Ёпрст
 
29.04.14
11:54
(96) а чего скан ?
99 Ёпрст
 
29.04.14
11:54
(97) порядок измерений в регистре какой хоть ?
100 art_id
 
29.04.14
11:55
(99) Фирма, Номенклатура, Склад, ЦенаПрод
101 Mikeware
 
29.04.14
12:00
(97)чой-то у тебя неправильно. по идее, закэшироваться должно, и в ближайшее время выполняться моментально....
102 Ёпрст
 
29.04.14
12:01
Так, сколько ?

    ТекстЗапроса = "
    |SELECT
    |    ОстаткиТМЦОстатки.Номенклатура [Номенклатура $Справочник.Номенклатура],
    |    (ОстаткиТМЦОстатки.КоличествоОстаток) Количество
    |FROM $РегистрОстатки.ОстаткиТМЦ(:КонДата~,,
    |        (Фирма = :Фирма)
    |        AND (Склад = :Склад)
    |,Номенклатура,
    |        Количество) AS ОстаткиТМЦОстатки
    | where Номенклатура IN (Select Val FROM #СписокНоменклатуры)
    |";
103 Ёпрст
 
29.04.14
12:06
+102 ну и совет с ОбратныйРасчетОтТА(1) сделал ?
104 Ёпрст
 
29.04.14
12:07
ну и это, воткни turbomd наконец (чтоб на лету модули править) и  обнови 1cpp до последней.
105 art_id
 
29.04.14
12:08
(102)Выполнил 4 раза также: 15072, 11102, 11421, 10420
(103)Если у меня ТА на 30 число, а док на 25 это не помешает?
(104)Щас база восстановится тестовая, буду там пробовать.
106 Ёпрст
 
29.04.14
12:11
>>> у меня ТА на 30 число

Нахрена ты её туда задвинул ?!
107 Mikeware
 
29.04.14
12:11
(105) задвинь ТА на конец года. а лучше - лет на 100....
108 art_id
 
29.04.14
12:12
(106)Иначе доки не проводятся, много документов на 23:59:59
109 trad
 
29.04.14
12:13
(106)не существенно, мы же рассматриваем проведение не актульного документа.
110 Ёпрст
 
29.04.14
12:15
(109) ? та ну ? у него щас все доки в заднем числе :) ну и шерстить ra как то не очень.. тем более, записи целого месяца.
111 Ёпрст
 
29.04.14
12:16
а так, в потоке бы проводил и привет
112 trad
 
29.04.14
12:16
(110) "у него щас все доки в заднем числе :)"
кто сказал?.. не факт
113 Ёпрст
 
29.04.14
12:16
(108) зачем ты их туда задвинул ?
114 Ёпрст
 
29.04.14
12:17
(112) ну как это не факт ? ТА то он вперёд толканул, в 30 число, а проводит 25-е
115 Ёпрст
 
29.04.14
12:18
+ расчет не от ТА стоял, целый месяц напрягать ра приходится запросу.
116 trad
 
29.04.14
12:18
(111) проводил бы в потоке - не дергалась бы ra вообще - не возникло бы проблемы, не пришлось бы исследовать
117 Ёпрст
 
29.04.14
12:18
ну , точнее 25 дней :)
118 Ёпрст
 
29.04.14
12:18
(116) я за то и говорю, нахрена он та задвинул вперёд ?
:))
119 trad
 
29.04.14
12:19
(114) ааа я тебя не правильно понял
"у него щас все доки в заднем числе :" - я подумал, ты про то, что все доки 30
120 Ёпрст
 
29.04.14
12:19
А так, период 5 дней.. и можно вообще забыть, где там ТА..
121 art_id
 
29.04.14
12:22
(113)Если у текущего непроведенного документа дату поменять на 5 дней вперед, то время меняется же? Либо при записи ставить время документа?
122 trad
 
29.04.14
12:23
у мну тоже доки разрешено проводить будущей датой.
и текущее проведение всегда неактуальное
живу спокойно, все проводится моментально
(периодичность итогов - месяц)
123 art_id
 
29.04.14
12:29
Поменять периодичность можно, но неизвестно сколько она будет обрабатывать регистр. Попробую сегодня на ночь поставлю на тестовой.
124 Ёпрст
 
29.04.14
12:30
(123) для начала, (81) и (103) сделай...
125 art_id
 
29.04.14
12:39
(124)Попробовал в обработке: 302, 298, 297, 317. Конт указал просто ссылку на документ.
Только какие могут быть последствия?
126 art_id
 
29.04.14
12:40
+(125)Я только не пойму, если у меня нет итогов еще на 1 мая, как результат то корректный получается?
127 Ёпрст
 
29.04.14
12:43
(126) че ?..
128 trad
 
29.04.14
12:44
(125) "Только какие могут быть последствия?"
никаких, кроме ускорения
Но замечу, что ОбратныйРасчетОтТА можно применять только в модуле проведения, либо в иной транзакции с блокировкой проведения документов
129 trad
 
29.04.14
12:46
(126) итоги на начало 1 мая = итогам на конец 30 апреля. Логично же.
А итоги на конец апреля как раз таки записаны тут period={d '2014-04-01'}
130 art_id
 
29.04.14
12:49
(128)Т.е. в глобальнике при проведении можно смело использовать?
(129)Не пойму, тогда зачем движения еще с 25 по 30 апреля?
131 trad
 
29.04.14
12:49
art_id, sql сервер какой версии?
132 art_id
 
29.04.14
12:50
(131)2005
133 trad
 
29.04.14
12:52
(130) глобальник не причем. при проведении - да

Движения 25-30 _вычитаются_ из итогов на конец 30апр
Иначе, движения 1-25 прибавляются к итогам на начало 1апр
Посмотри внимательно в отладочные запросы. Обрати внимание на даты и знаки
134 trad
 
29.04.14
12:53
+ на знаки в этом выражении case ra405_vt.debkred when 0 then ra405_vt.sp411 else -ra405_vt.sp411 end
135 art_id
 
29.04.14
12:55
(133)Увидел, спс
136 Mikeware
 
29.04.14
12:55
(129) только одно непонятно - почему для итогов на конец месяца выбрано первое число....
137 Ёпрст
 
29.04.14
12:56
(130)
2. останки не на ТА вычисляются как предыдущий остаток + (приход - расход до нужной даты), либо останки на ТА - движения до документа..
138 Mikeware
 
29.04.14
12:56
(134) а почему все-таки кейс, а не умножение?
139 trad
 
29.04.14
12:58
(136) наверно потому что первое во всех месяцах первое, а последнее - разное
140 trad
 
29.04.14
12:59
(138) выше сказано - религия наверно
141 art_id
 
29.04.14
13:00
(137)НЕ обратил внимание что в первом случае складываются, а во втором вычитаются.
Попробую сегодня скрипт запустить из (64), странно что ни с того ни с сего вдруг стал долго выполняться запрос.
142 Ёпрст
 
29.04.14
13:00
надо бы как-нить померить скорость с кейсом и без..
143 Mikeware
 
29.04.14
13:01
(139) Ну, фактически же это остатки на начало следующего? я бы взял первое число следующего....
хотя твоя логика тоже
144 ADirks
 
29.04.14
13:01
(138) это реально вопрос религии: я проверял на несколькоих миллионах записей - разница в рамках статистической погрешности.
145 Ёпрст
 
29.04.14
13:01
(141) нехрен ТА вперёд загонять.
Раньше документы в "потоке" проводились и запрос просто обращался к одной табличке - к RG.. а сейчас молотит еще и тяжелую RA
146 trad
 
29.04.14
13:02
(140) другая (моя) версия, автор ВТ подсмотрел это у самих одинесовцев
147 Ёпрст
 
29.04.14
13:02
(143)ага, а что брать для периодичности 5 дней, к примеру ? :)
148 Mikeware
 
29.04.14
13:02
(144) ок, спасибо. я не проверял на больших объемах.
Хотя кейс - он читабельнее для человека, поэтому раз не быстрее - значит, правильнее.
149 Mikeware
 
29.04.14
13:03
(147) убил.
150 art_id
 
29.04.14
13:09
(145)всегда ТА была на 7 дней макс вперед установлена
151 Z1
 
29.04.14
15:16
(142) ничего не выявишь.даже померить проблематично.
как бы case более правильней с точки зрения неявного преобразования типов. ну если так нравиться умножение то пиши
в нем явное преобразование типов.
Проблемы невозможно решaть нa том же уровне компетентности, нa котором они возникaют. Альберт Эйнштейн