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

[AnGor]

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

[raz]

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

[AnGor]

Quote:

Originally Posted by raz

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

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

[raz]

Quote:

Originally Posted by AnGor

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

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

[AnGor]

Quote:

Originally Posted by raz

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

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

[Logger]

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

[raz]

Quote:

Originally Posted by 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, еще как-то) - пробовали? У нас же отчет, оверхед от рекомпиляции минимальный

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

Quote:

Originally Posted by 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]

Quote:

Originally Posted by Logger

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

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

[AlexeyS]

Quote:

Originally Posted by AnGor

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

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

[AnGor]

Quote:

Originally Posted by AlexeyS

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

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