|
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 более правильней с точки зрения неявного преобразования типов. ну если так нравиться умножение то пиши в нем явное преобразование типов. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |