Комментарии 9
Не совсем понял, что имеется в виду. Оверинжениринг - это обслуживать индексы в принципе? Или оверинжениринг - это не использовать стандартные планы обслуживания?
Так может лучше вообще не трогать индексы на таких системах? Не насиловать регулярно диски, а лучше почаще выполнять checkdb?
Ну, т.е. пост же как раз об этом - перестройка индексов стандартными средствами может дать какой-то минимальный прирост производительности (если он вообще будет), но потребует кучу ресурсов, сгенерирует тонну логов, инвалидирует кучу планов и может вызвать блокировки (на не-Enterpise редакции).
В вашем примере как раз только процент заполненности страницы и может сыграть какую-то роль. Памяти же фрагментированные индексы, заполненные на 100 процентов будут занимать столько же, сколько и совсем не фрагментированные.
Можно немного посмотреть с другой стороны… залесть в sys.allocation_units и если есть большое расхождение между total_pages и used_pages, то это потенциальный кандидат для ребилда.
За опросник слезу пустил :) когда увидел кого перечислили в сторонних решениях. Честно рад что моим тулом пользуются.
Пример у нас база на 5GB, хостится на сервере с 128GB RAM
У нас 5 TB на сервере с 128GB RAM — так что без "оверинжениринга" никак. И там не доли процента из производительности индекса. Так что без ребилдинга не обойтись.
Не то, чтобы я активно топил за то, чтобы не делать ребилды индексов, но всё зависит, как минимум, от объёма активной порции данных. Если он не влезает в память, то похоже, что пора идти в магазин.
Более того, MS, оказывается, переписали свой whitepapper по перестройке индексов и там прямо пишут, что зачастую положительный эффект, наблюдаемый после ребилда - это следствие обновления статистики, а не ребилда как такого.
Тот же Озар, емнип, идёт ещё дальше и пишет, что зачастую и обслуживание статистики это "оверинжениринг", а эффект проявляется из-за того, что процедурный кэш инвалидируется.
Ваш скрипт, обслуживающий индексы, измеряет не то, что надо