LCS Environment monitoring SQL Insights

[MorpheusX]

Как в "LCS Environment monitoring SQL Insights" увидеть историю Expensive Queries, как в Performance Dashboard?

[fed]

Единственный известный мне способ - это скопировать данные из Prod в UAT/TEST и сразу после копирования врубить в БД режим Read_only
ALTER DATABASE <myAxDB>
SET QUERY_STORE (OPERATION_MODE = READ_ONLY);
После этого можно подключиться к БД в Tier2 instance и погонять запросы по Query Store и посмотреть чего из запросов сильнее всего систему грузило.
Как отправную точку можно использовать запросы из статьи. Кроме того, в стандарте SQL Management Studio есть несколько отчетов/диаграм по query store, которые тоже можно использовать.
Два примечания:
1. При переливке данных из Tier2 в Tier1 query store не копируется, так что анализировать его надо в вашем Tier2
2. Время от времени режим Read_Only у query store скидывается в Read Write. (Я пока так и не понял как и когда, но иногда это случается). Если ваш Sandbox/UAT не очень активно используется, свежая статистика (уже в Sandbox собранная) особо сильно картину не подпортит. Но если вы Sandbox активно гоняете, надо будет все время следить, не свалился ли у вас режим обратно в Read_Write и возвращать его на место.

[MorpheusX]

К своему удивлению обнаружил здесь, что List most expensive queries числится в списке Removed features по причине This query may not show the most concerning queries, just the most expensive query at the period of time.

[MorpheusX]

И вообще проблемы с производительностью мониторятся и автоматически исправляются платформой. Вот несколько промеров:

1. The platform will monitor and automatically employ self-healing mechanisms to reduce the resource consumption of the most expensive queries;

2. The platform will automatically tune and optimize individual queries, removing the need for manual interventio;

3. The system automatically tunes and manages indexes;

4. The platform optimizes workloads and environment to reduce the number of scenarios leading to unresolved process blocking.

[gl00mie]

Цитата:

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

И вообще проблемы с производительностью мониторятся и автоматически исправляются платформой. Вот несколько промеров:
1. The platform will monitor and automatically employ self-healing mechanisms to reduce the resource consumption of the most expensive queries;

Не надо "путать личную шерсть с государственной", здесь говорится об оптимизации нагрузки на СУБД, а не оптимизации производительности запросов. Вероятнее всего, на наиболее ресурсоемкие запросы просто науськивается функция классификации из resource governor, чтобы отделять их в песочницу пул с ограниченными вычислительными ресурсами. Тогда запросы будут выполняться еще медленнее, но не будут перенапрягать СУБД.

Цитата:

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

2. The platform will automatically tune and optimize individual queries, removing the need for manual intervention;

Прям искусственный интеллект... plan guide что ли прикручивается автоматом?

Цитата:

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

3. The system automatically tunes and manages indexes;

Хорошо, если отключает неиспользуемые. Потому что зная, как MS жадно относится к выделяемому в Azure SQL месту под базу, че-то слабо верится, что автоматом досоздаются "недостающие" по мнению оптимизатора запросов индексы.

Цитата:

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

4. The platform optimizes workloads and environment to reduce the number of scenarios leading to unresolved process blocking.

Периодически рубит долго висящие блокировки? Ну, тоже неплохо...

[skuull]

Цитата:

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

Потому что зная, как MS жадно относится к выделяемому в Azure SQL месту под базу, че-то слабо верится, что автоматом досоздаются "недостающие" по мнению оптимизатора запросов индексы.

А если просто проверить? Взять базу из прода, перенести в тир 2 и посмотреть, там их будет полно, они конечно не самые лучшие, к примеру индекс по всем полям на inventTrans

[fed]

Цитата:

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

А если просто проверить? Взять базу из прода, перенести в тир 2 и посмотреть, там их будет полно, они конечно не самые лучшие, к примеру индекс по всем полям на inventTrans

Раньше "оптимизатор" строил два бессмысленных индекса - по dataAreaId и partition. Где-то в декабре его от привычки строить индекс по partition отучили и даже включили построение относительно осмысленных индексов (судя по всему - полученных путем поиска информации об отсутствующих индексах в планах тяжелых запросов). По крйней мере у нас по inventTrans появилось три осмысленных индекса (и не со всеми полями, но с большим числом полей чем я бы сам включил) и для всех трех индексов я примерно понимаю, из за какого запроса они были построены.
Есть, правда, ощущение, что анализа "выигрыш по поиску/проигрыш по обновлению" они не выполняют и строят вообще все индексы по хинтам из top N запросов из query store.

[Logger]

Цитата:

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

Есть, правда, ощущение, что анализа "выигрыш по поиску/проигрыш по обновлению" они не выполняют и строят вообще все индексы по хинтам из top N запросов из query store.

А можно как-то подавить такое неуемное построение индексов ?

[MorpheusX]

Похоже, что Microsoft убрал большинство запросов из LCS > SQL Insights потому что партнеры не могли их интерпретировать для выполнения оптимизации и много жаловались. Microsoft "решил" проблему "автоматизировав" оптимизацию.

[fed]

Цитата:

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

Похоже, что Microsoft убрал большинство запросов из LCS > SQL Insights потому что партнеры не могли их интерпретировать для выполнения оптимизации и много жаловались. Microsoft "решил" проблему "автоматизировав" оптимизацию.

Мне кажется, эти запросы убрали в момент перехода на "Spartan" (то есть - пул Azure SQL Servers, между которыми наша БД может переезжать при повышении/понижении нагрузки). Хотя, возможно, это еще раньше случилось, когда сам D365FO перевели на технологию Azure Service Fabric (то есть - отвязали от конкретных виртуалок и отдали на откуп ПО управления контейнерами, который эти контейнеры создавать и убивать на разных физических машинах в сети может). В общем - процентов на 99 уверен что убрали эту функцию не потому что партнеры тупили, а потому что на новой технологической платформе их было тяжело реализовать.