нет
нет

в тему

если бы там были еще и "что и когда выполнялось", "какие запросы не выполнились", "у какого запроса какие планы" - цены бы им не было

например, что выполнялось сегодня с утра в период с 8 до 9 утра
сколько раз, использованные ресурсы, tempdb и прочее

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

зачем плодить сущности, когда данные уже собираются и аггрегированы с достаточной гранулярностью?
предпочитаю использовать то что есть, тем более что в Azure SQL db, с чем я в данный момент работаю, инструментарий ограничен

кстати, Data Collector на нагруженных локальных серверах показал себя не блестяще

спасибо, не знал, запишу на будущее

ну, это тот самый случай, когда "your milage may vary", т.е. у каждого свой опыт и своя среда эксплуатации


Я не говорил, что QS панацея и лучший инструмент.
Имею ввиду, что в QS много ценной информации как по потребленным ресурсам (sys.query_store_runtime_stats и столбцы *_cpu_time, *_logical_io_reads/writes, , *_physical_io_reads, *_query_max_used_memory, *_log_bytes_used, *_tempdb_space_used), так и по ожиданиям (sys.query_store_wait_stats) для каждого выполненного запроса, который был отловлен QS.
Безусловно, данные агрегированы, но и интервал агрегирования настраивается (по умолчанию, 1 час).

Под блокировками я имел ввиду ожидания ресурсов (waits) и в частности Resource_semaphore.
Статистика по дискам мной не упоминалась.