Как измерять ключевые поисковые запросы в секунду на SQL Server

Я работаю над уменьшением количества транзакций, выполняющих ключевые поиски на наших серверах SQL.

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

Проблема, с которой я столкнулась, - это найти правильный счетчик либо на perfmon или SQL DMV для получения данных.

Я посмотрел на очевидный объект SQL Server, Объект методов доступа , я не нашел конкретного. Я также пробовал другие счетчики или представления SQL, но не смог найти его.

Любые предложения будут очень оценены!

7 голосов | спросил Salvador L 7 Jam1000000amThu, 07 Jan 2016 08:48:10 +030016 2016, 08:48:10

2 ответа


7

Я не знаю полностью точного и надежного способа отслеживания этого.

Один из способов получить как минимум что-то потенциально полезно - сохранить моментальные снимки sys.dm_db_index_usage_stats , в частности столбец user_lookups для index_id 0 (поиск RID) и 1 (Key Lookup ). Этот DMV может быть сброшен по многим причинам, включая перезагрузку базы данных или экземпляра. Восстановление (но не реорганизация) и индекс также очищают связанную запись DMV на SQL Server 2012 и более поздних версиях, что может усложнить ситуацию. Вам нужно будет регулярно фиксировать информацию и использовать эвристику, чтобы решить, будет ли сброс DMV между захватами.

Статистика использования индекса DMV также возвращает только количество попыток выполнения плана, содержащего Lookup. План, содержащий один ключевой поиск, будет увеличивать счетчик на 1, независимо от количества реально выполненных запросов. Он также увеличится, даже если Lookup не будет выполнен вообще.

sys.dm_db_index_operational_stats DMV записывает количество однотонных поисков на самом деле выполняется, но не различает односторонние запросы по индексу напрямую, а также те, которые возникают в результате поиска ключа или RID, поэтому это не полезно для вашей цели.

Синглтон ищет другое имя для сканирования проб, как сообщает объект методов доступа. Невозможно различать «нормальный» однотонный поиск по уникальному индексу, а односторонний поиск - в результате поиска. Это означает, что счетчик сканирования датчиков доступа не полезен для вас. Счетчики AM очень шумны в любом случае, и нет возможности сопоставить счетчики с определенным индексом.

ответил Paul White 7 Jam1000000amThu, 07 Jan 2016 10:04:30 +030016 2016, 10:04:30
0

Хорошая запись Майкла Дж. Сварта кажется чтобы указать, что ключевой поиск будет отсчитываться по счетчику Probe Scans/sec в методах доступа:

  

Поиск ключа ( Документация оператора Showplan )

     

Этот оператор также   известный как оператор поиска по закладкам. Он всегда учитывает   Счетчик сканирования /сек. Интересно, что хотя   он получает одну запись за раз, этот оператор часто рассматривается как   симптом плохой работы. Это потому, что количество казней   может стать большим. Многие исполнения могут убить производительность запроса. Если   вы фокусируетесь на счетчиках производительности, вы заметите, что каждый из   эти казни будут учитываться в отношении производительности сканирующего зонда   счетчик.

Хотя использование счетчика производительности только даст вам номер. Вам все равно придется копаться в кеше плана, чтобы найти конкретные запросы, которые имеют ключевой поиск. Что возможно .

Примечание . Ссылка выше на оператор showplan связана с Майклом, но мне удалось найти текущую документацию в MSDN, которая предоставляет немного более актуальную информацию: Справочник по логическим и физическим операторам Showplan

ответил Shawn Melton 7 Jam1000000amThu, 07 Jan 2016 10:16:12 +030016 2016, 10:16:12

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132