Pull to refresh

Comments 26

Вот тут вопрос созрел…
А оно будет работать поверх тонких и ненадежных каналов? Тонких — ладно, а вот ненадежных?
А то у меня сервера и, скажем так, на Чукотке и в Магадане есть.
Нет, конечно, с интернетом там всё сильно лучше стало.
Сильно, да.
В коде предусмотрен функционал если разрывается соединение, то команду пробуем заново выполнять. Но это не для всех запросов предусмотрено.

в коде есть просто обработка исключений, однако не предусмотрено кусками передавать инфу, что для нестабильных сетей кстати сказать существенно. Думаю стоит взять на заметку AlanDenton

Ну не совсем так. Реализован механизм частичного дескрайба. То есть все тянется не одним большим запросом, а вначале получаются все мелкие индексы за раз, а потом в цикле добирается точечными запросами большие по размеру индексы (если что настраивается).

И что будет если по середине произойдет обрыв сети? Если обрывы будут постоянными до 35 сек каждую минуту?

Это я к тому, что всё обслуживание, всё, что длится дольше пары минут — приходится делать одноразовыми джобами на той стороне.

Если обрывы будут постоянными до 35 сек каждую минуту?

Тут as design. Если обрывается соединение, то и запрос будет откатываться. Для таких целей есть функционал копирования сгенерированного скрипта и его запуск со стороны сервака.

Да, это решает проблему. Спасибо

Эмм… Я не DBA, объясните, пожалуйста, а чем он отличается от стандартного Tuning Advisor'а?
Формально это два разных продукта. Tuning Advisor с помощью гипотетических индексов создает недостающие индексы. Второй эти индексы обслуживает.
Есть вполне авторитетное мнение что фрагментация индексов не нужна и как правило приносит больше проблем чем пользы(что я лично наблюдал на нескольких проектах), так что цель данной программы не очень понятна
youtu.be/iEa6_QnCFMU?t=700 (Why Defragmenting Your Indexes Isn’t Helping with Brent Ozar) и www.brentozar.com/archive/2017/12/index-maintenance-madness

Нужно две вещи определять:
1) использование индексов
2) какие индексы будут использоваться
Чем больше фрагментация, тем больше операций чтения.
А авторитетные мнения могут говорить что угодно-важно не отключать свое критическое мышление и все перепроверять, ставя под сомнение любое мнение даже авторитетное (даже от самого Microsoft)

Посмотрите видео — там как раз объясняется популярное заблуждение — «Чем больше фрагментация, тем больше операций чтения.». Если у вас данные в памяти, то какая там фрагментация к примеру — это все равно и т.д.

А всегда данные в памяти будут?
Автор не учитывает российских реалий, что в большинстве будет стоять не Enterprise редакция, да и обьемы ОЗУ не так велики

так что цель данной программы не очень понятна

Цель предоставить функционал, а то как ним пользоваться уже дело пользователя. Зачастую ребилд индексов и вправду смысла не имеет. А вот обновление статистики, сжатие индексов и прочии перки — это да.
Попробовал как раз пару недель тому назад. Тулза практически не работает. Из базы с более 1500 индексов с трудом притаскивает около сотни, из базы с 600+ индексами притаскивает те же… около 100. И базы в принципе не большие, по сегодняшним меркам, ~1.5ТБ и вторая ок. 500ГБ, Причём как-то странно более половины индексов на таблице не видит т.е. из 12 тянет 3-5 и всё. Не говоря уже о том что считать эти индексы уходит аж несколько (5-7) минут. В общем покрутил минут 20 и снёс. В принципе тулза интересная, но подождём пока допилят до приемлимого функционала, ибо на сейчас оно для моих баз никакое.

Странно, но на БД от 100 до 1200 ГБ на 10-ки БД на сервере норм работает.
По 1С правда загибается (долго), но выводит в итоге, а там 10-ки тысяч индексов

Она же не показывает индексы, у которых фрагментация ниже установленного в настройках порога (в настройках есть и другие фильтры)

Из базы с более 1500 индексов с трудом притаскивает около сотни

Все настройками устанавливается. По дефолту не тянутся индексы тяжелее 8Гб.

Не говоря уже о том что считать эти индексы уходит аж несколько (5-7) минут

Скажем за это спасибо Microsoft. Данные о фрагментации индекса не кешируется на постоянной основе, потому происходит частичный скан индекса если его нет в буффер пуле (потому ограничение по размеру и делал).

>>Все настройками устанавливается. По дефолту не тянутся индексы тяжелее 8Гб.
Я пробовал, у меня не заработало. И какая разница при первом то скане сколько там этот индекс весит. Наиболее интересны как раз большие индексы, мелкие гораздо менее интересны.
Скриптом я вытягиваю все индексы с их статистикой за пару минут и это с анализом на каждой таблице на дупы, миссинг и т.д, чуть менее 2 сек на таблицу на тестовом сервере (на продакшене, десятки-сотня мс). Ожидал чего то лучшего. Вытянуть всё тоже, но в более удобной форме на той же базе готов ждать 5-10 мин. Хочется иметь инструмент отдельный от SSMS.
В любом случае спасибо, тулза интересная будет инетерсно посмотреть опять через некоторое время
Странно что прога работает медленнее чем ваши скрипты. Можете постучаться в личку? Скажем в телеграмм или по скайпу (в профиле линки есть). Хочется разобраться в ситуации и пофиксить если это реально косяк с моей стороны.
Плюс можно будет попросить у вас скрипты которыми данные вытягиваете о которых в своем комментарии написали. Заранее спасибо.
Извините ни скайпа ни телеги. Скрипты погуглите Brent Ozar sp_BlitzIndex.
А для MS SQL работает? Есть готовый exe-шник?

Конечно, ссылка в публикации на git проект приложена в том числе и в конце статьи

Исправил много косяков в билде 1.0.0.47, поэтому если что не работает попробуйте новую версию. Описание что поменял тут. Скачать можно тут.

Всем спасибо за отзывы.
Only those users with full accounts are able to leave comments. Log in, please.

Articles