LCS Environment monitoring SQL Insights

[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.

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

[fed]

Цитата:

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

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

Нет. Более того - до недавнего времени этот построитель индексов временами просыпался и ломал длинные транзакции. Скажем - загружаешь ты какой-нибудь data entity в течениии 2-3-4 часов, в конце концов включается этот построитель индексов и чего-то там перестраивает. А у тебя импорт отваливается сообщением "schema changed" и тебе надо все перезапускать с ноля. При этом, в каких-то случаях импорт вообще никогда не мог закончится, потому что построитель индексов просыпался каждые 3 или 4 часа, обнаруживал что у тебя индекс по загружемой таблице фрагментирован, запускал переиндексацию, импорт ломался и так далее до бесконечности. Вроде бы в последних версиях мозги этому построителю индексов немного вправили, но подробностей не знаю.