Имя: Пароль:
1C
 
Интересная ситуация в платформе, приводящая к замедлению
,
0 simol
 
15.11.14
20:29
Начал еще раз разбираться с медленным восстановлением последовательности. Все упирается в использовании виртуальной таблицы регистра накопления Остатки.
Выполняю запрос получение на нужную дату в середине месяца старого года по одному измерению и одному ресурсу. Запрос во вложении.
Смотрю во что превращается запрос в Sql. Во вложении.
Там соединяется таблица итогов и часть основной таблицы. Все логично. Но если посмотреть на запрос из основной таблицы, то там есть избыточное условие:
(_Period = @P6) AND (_Period < @P8)
где @P6 выбранная мною дата, а @P8 это начало следующего месяца. Из-за этой избыточности и происходит торможение.
Если убрать (_Period < @P8), то запрос существенно ускоряется.

http://ska4ay.com/@16k
1 ZOMI
 
15.11.14
20:39
О, cколько нам открытий чудных...
2 H A D G E H O G s
 
15.11.14
20:48
(0) nod говорит, что страница небезопасна.
3 H A D G E H O G s
 
15.11.14
20:49
(0) Запрос верен, надо из таблицы итогов на конец месяца отнять движения на промежутке от твоей даты до кона месяца.
4 H A D G E H O G s
 
15.11.14
20:54
Это мелочи при сравнении с полным сканированием таблицы движений при получении остатков на момент времени. Это было полтора года назад, счаст вроде поправили.


(0) indexscan есть?
5 Bober
 
15.11.14
21:36
(0) как выглядит весь запрос и как выглядит план запроса?
6 Reaper_1c
 
15.11.14
22:32
(4) Неа, одному товарищу на подпольном вообще предложили моментом времени не пользоваться. Опять обещали проанализировать проблему выбора оптимизатором неэффективного плана исполнения...
7 H A D G E H O G s
 
15.11.14
23:40
(6) Я не смог воспроизвести, у меня было 2 запроса к таблице движений, оба попали в индекс, на параметры не посмотрел.
8.2.19
8 Reaper_1c
 
15.11.14
23:53
Да там в общем-то и не ошибка. Текущая архитектура допускает ситуации при которых СУБД выбирает неоптимальный план. Это происходит не везде и не всегда, но случается. Разработчики чешут репу, пытаются придумать как исключить эти ситуации вовсе, но пока шанс поймать эту беду сохраняется.
9 Torquader
 
16.11.14
00:04
Если кто-то выбирает неоптимальный план, то нужно не ждать, когда он его выберет, а задавать самим план выполнения.
Но в 1С, видимо, твёрдо верят в волшебную силу Microsoft и целиком доверяют SQL-серверу.
10 rsv
 
16.11.14
00:19
К сожалению нельзя в языке запросов 1С использовать хинты.
11 Reaper_1c
 
16.11.14
00:21
(9) Открою тебе тайну - 1С работает не только с MS SQL.
12 rsv
 
16.11.14
00:22
Кстати в доках по скулю  пишут что с 2005 появилась возможность  динамически запросам   не меняя текст подсовывать подсказки но.. т.к.  1С ка крутит все с десятками временных таблиц #1....#24 это не прокатит
13 rsv
 
16.11.14
00:24
(11)  И также  не управляете планом выполнения из запроса
14 rsv
 
16.11.14
00:28
+(12) Окна объясняют эту опцию тем - что  закрытое приложение не всегда оптимально и дают возможность без привлечения разработчика приложения админу скуля порешать вопросы.
15 Torquader
 
16.11.14
01:49
(14) Так раньше для этого вместо таблиц приложению view и select function подсовывались, а уже в них писалось реальное выполнение запроса с оптимизацией.
Компьютеры — прекрасное средство для решения проблем, которых до их появления не было.