sitox Jul 9 2015 at 05:22

Сможет ли Microsoft Azure найти такой индекс, который не смог найти ваш DBA?

2 min

4.6K

Microsoft SQL Server*Microsoft Azure*

Comments 15

diamond3 Jul 9 2015 at 09:13

Для обычного, не-облачного SQL Server такое появится?

vladimirkolyada Jul 9 2015 at 10:12

Уже давно есть Tuning Advisor идущая в комплекте. Работает по тому же принципу, от туда наверняка и взято ядро. Профайлинг — анализ — результаты. Причем стандартный умеет не только индексы. И уверен, что есть миллион других приложений, из разряда редгейтов и так далее.

minamoto Jul 13 2015 at 11:03

Скорее используется общее ядро — системные DMV sys.dm_db_missing_index_groups, sys.dm_db_missing_index_group_stats, sys.dm_db_missing_index_details.
Возможно, используется расширенная оценка для определения, насколько индекс ухудшит производительность вставки и сколько места займет.

sitox Jul 13 2015 at 11:06

Индекс действительно создаётся, и наблюдается в течении некоторого времени, если производительность падает, то он удаляется.

leschenko Jul 9 2015 at 11:28

База данных которая использовалась в течении некоторого времени.

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

sitox Jul 9 2015 at 12:19

Телеметрия собирается после создания базы данных, включение Index Advisor на это не влияет. (так же как она не влияет на производительность)
Так может случиться, что ваша схема не требует улучшения в данный момент, тогда IA ничего не будет рекомендовать. (Поздравляю!)

Когда IA обнаружит постоянную нагрузку, которую можно уменьшить с помощью индекса, вы увидите новую рекомендацию.
Процесс ожидания зависит от вашей нагрузки, и IA должен быть уверен, прежде чем рекомендовать. Могу сказать, что пару часов будет точно недостаточно.

Вероятно, в будущем, модель оповещения о рекомендации измениться от pull (когда вы проверяете каждую базу данных) на push, когда вам приходит скажем письмо о новой рекомендации.

leschenko Jul 9 2015 at 13:40

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

sitox Jul 9 2015 at 14:06

Да, удалять индексы не стоит.
Надеюсь в следующий раз, Index Advisor поможет вам сэкономить время и силы на наблюдении за запросами.

RedQuark Jul 9 2015 at 16:24

Index Advisor видит хинты в запросах? Наблюдал как заблуждается стандартный Index Advisor на БД Sharepoint (там в процедурах куча хинтов понаписано).

sitox Jul 9 2015 at 16:56

Нет, Index Advisor не смотрит на текст запроса. Он смотрит на характер доступа к данным и нагрузку. Если нагрузка постоянная и есть место для улучшения, он рекомендует индекс.

Насколько я понимаю, подсказки в запросах, говорят какой план выполнения запроса выбрать. И скорее всего этот план уже достаточно хороший.
(В этом SharePoint очень строг, разработчики предпочитают все контролировать сами)

RedQuark Jul 9 2015 at 17:19

Просто поделюсь наболевшим: из-за прибитых планов к запросу, анализатор постоянно советует создать бесполезные индексы(у вас, я так понял, случиться откат, раз есть наблюдение после). Разработчики SharePoint творят странные вещи, создают табличную функцию с параметрами и по этим параметрам прибивают план в запросе функции. Это гениальное решение идеально пока не встречается запрос использующий это идеальное творение в своих целях: select * from dbo.zzz(flag1,flag2) where Field2='1'. План не перестраивается оптимально и БД ложится. Запрос системный.

sitox Sep 23 2015 at 17:51

К сожалению не знаком с SharePoint насколько глубоко, чтобы помочь. Могу только посоветовать описать очень подробно проблему на сайте вроде Stackoverflow. Может кто-нибудь из команды SharePoint следит за этим. :)

RedQuark Jul 9 2015 at 17:06

1) Можно чуть подробней про анализ характер доступа к данным? Сотни индексов не будет создавать на таблицах где идут постоянные IUD?
2) Есть прогнозный показатель размера индекса скажем через год? (После старта проекта он 10 MB, а через год уже 10GB)
3) В алгоритме оценки участвует параметр степени влияния времени выполнения запроса на другие запросы? Если бы Index Advisor умел ускорять индексами запросы которые долго блокируют ресурсы это было бы явным шагом вперед по сравнению со стандартным анализом CPU, read, duration.
4) Рекомендовать удалить индекс умеет? Скорей всего будут появляться индексы покрывающие предыдущие.
Было бы интересно видеть сколько секунд времени будет экономиться в день от ввода индекса. (пожелания, мысли в слух)

sitox Sep 23 2015 at 17:44

Лучше поздно, чем никогда :)

1) Index Advisor рекомендует те индексы, которые помогают конкретным запросам. (так же оценивает предполагаемое влияние). Так может случиться, что созданный индекс, не будет таким эфективным. (в основном потому что характер нагрузки изменился). Для этого существует этап верификации, когда оценивается общая картина нагрузки, и если созданый индекс ухудшает её, он автоматически удаляется.
2) Это интересная идея, но пока Index Advisor не может предсказать как будет себя вести только что созданный индекс. Во многом потому что тут много переменных,(нагрузка, использование и т.д.) для того что бы дать предсказание хорошего качества.
3) Это очень интересная идея, на данный момент Index Advisor не рассматривает влияние индекса на продолжительность запросов, кол-во блокировок. Но это то, на что бы обязательно обратим внимание в следующих версиях.
4) Сейчас нет, но мы рабоает над этим функционалом. Скоро мы будем выдавать рекомендации, какие индексы не используются и их можно удалить. Stay tuned, как говорится ;)

sitox Sep 23 2015 at 17:43

Не туда

Show the best of all time