(D365FO) огромная разница времени выполнения запроса на SQL консоли и на AOS

[AnGor]

Всем привет!
Вопрос по производительности.
Есть одна кастомная вьюха, на консоли выполняется за секунду, на AOS (в коде дата-провайдера, на первом вызове qr.next()) почти минута.
Почему такая большая разница?
D365FO, Update26 (7.0.5257.35417)
Забыл сказать - всё выполняется на OneBox VM

[raz]

В тему https://denistrunin.com/devvm-perfv10/

[AnGor]

Цитата:

Сообщение от raz

В тему https://denistrunin.com/devvm-perfv10/

ни слова о запросах
почему в тему?

[raz]

Цитата:

Сообщение от AnGor

ни слова о запросах
почему в тему?

Потому что скорость может зависить от конфигурации "железа".

[AnGor]

Цитата:

Сообщение от raz

Потому что скорость может зависить от конфигурации "железа".

OneBox VM, железо одно и тоже.
Выполняю запрос в консоли этой же VM - 1с
Алгоритм выполняет такой же запрос (посмотрено в Trace parser) - время выполнения 1 минута.

[Logger]

Вот хорошая статья по вашей проблеме.
http://www.queryprocessor.ru/fast-in...-in-app-part1/
А при чем тут курсоры, не курсоры? кардинальное отличие во времени могут дать только разные планы

[raz]

Цитата:

Сообщение от AnGor

OneBox VM, железо одно и тоже.
Выполняю запрос в консоли этой же VM - 1с

OK. Не понял этого.

[fed]

Еще в SQL Server 2016 появилась очень медитативная тулза - Live Query Statistics Можно во время исполнения длинного запроса посмотреть, на какой части плана исполнения сейчас находится SQL Server.

[AnGor]

получается, что sp_cursoropen берёт очень не оптимальный план.
пробовал через sp_executesql, как в статье советовали - всё быстро и с оптимальным планом
можно курсору как-то хороший план подсунуть?

[Vadik]

После

DBCC FREEPROCCACHE

время выполнения прежнее / лучше / хуже ? Навязать исполнение с ForceLiterals (в X++, свойствах Query, еще как-то) - пробовали? У нас же отчет, оверхед от рекомпиляции минимальный

[Владимир Максимов]

Цитата:

Сообщение от AnGor

получается, что sp_cursoropen берёт очень не оптимальный план.

Оптимальный. Но для курсора. А для курсора принципиально важно быстро вынуть одну (первую) запись, а не весь список. Как следствие, и план запроса по другому строится. Просто "побочная" цель немного отличается

Как уже неоднократно упоминал, очень сильно исказить план выполнения может использование Exists в запросе. Если такая связка в запросе есть, то лучше ее заменить на Inner Join, если это возможно по логике запроса

Собственно, если Вы тестируете план выполнения напрямую в SQL Manager, то для запросов Axapta надо тестировать примерно такую конструкцию

declare MyCursor for select ... from ...
open MyCursor
fetch next from MyCursor

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

В некоторых случаях может помочь обновление статистики. Но обновление статистики вещь "сиюминутная". Если эта вьюха будет выполняться относительно редко, то оптимальная для нее статистика будет "похоронена" под статистикой более часто выполняемых запросов

[Logger]

https://habr.com/ru/post/313998/

[AnGor]

Цитата:

Сообщение от Logger

https://habr.com/ru/post/313998/

В моём случае DBCC FREEPROCCACHE не помогла, та и не хотел прибегать к этой процедуре.
Денис, вот, не советует злоупотреблять DBCC FREEPROCCACHE
https://denistrunin.com/performance-audit/

[AlexeyS]

Цитата:

Сообщение от AnGor

получается, что sp_cursoropen берёт очень не оптимальный план.
пробовал через sp_executesql, как в статье советовали - всё быстро и с оптимальным планом
можно курсору как-то хороший план подсунуть?

Сегодня столкнулся с подобным плохим подбором плана.
Один хороший человек подсказал использовать на DS firstFast(false), помогло.

[AnGor]

Цитата:

Сообщение от AlexeyS

Сегодня столкнулся с подобным плохим подбором плана.
Один хороший человек подсказал использовать на DS firstFast(false), помогло.

попробовал - не помогло