Index rebuild ms sql: Reorganize and Rebuild Indexes in the Database

Отказ от ежедневной дефрагментации / Хабр

В этой статье попытаемся понять, как изменились процедуры обслуживания индексов для таблиц Microsoft SQL Server в современных условиях: при размещении файлов данных и журнала транзакций на SSD-дисках, многократном увеличении числа процессорных ядер и в условиях, когда оперативная память сервера стала измеряться Терабайтами.Действительно, мир стал другим. С тех пор как появились первые версии SQL Server, многое изменилось и многие методики, основанные на старых компьютерных ресурсах, работают уже не так эффективно, как прежде, когда без них невозможно было обойтись. Одной из таких методик, которая с давних пор воспринимается чуть ли не «серебряной пулей», а на деле превратилась в миф, является обязательная дефрагментация индексов, если в данные индекса достаточно часто вносятся изменения. Цель статьи развеять этот миф.

В своей документации, Майкрософт обращает наше внимание на то, что не стоит выполнять обслуживание индексов, не убедившись, что это принесёт пользу. Вот цитата:

«Чтобы избежать ненужного использования ресурсов, что может негативно влиять на рабочие нагрузки запросов, корпорация Майкрософт рекомендует не применять обслуживание индекса без предварительной оценки. Следует опытным путем оценить повышение производительности от обслуживания индексов для каждой рабочей нагрузки, используя рекомендуемую стратегию, и сопоставить его с затратами ресурсов и влиянием на рабочую нагрузку, которые потребуются для достижения этих преимуществ.»

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

«Перестроение индекса дает еще одно важное преимущество: позволяет обновить статистику по ключевым столбцам индекса, сканируя все строки в индексе. Это эквивалентно операции UPDATE STATISTICS … WITH FULLSCAN, которая позволяет актуализировать статистику и иногда дает более точные данные, чем обычное обновление статистики по ограниченной выборке. При обновлении статистики заново компилируются все планы запросов, которые ее используют. Если прежний план запроса не был оптимальным из-за устаревшей статистики, недостаточного объема выборки для статистики или по любой другой причине, то после повторной компиляции многие планы дают лучшие результаты.»

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

В документации дано следующее определение фрагментации индекса:

«В индексах сбалансированного дерева (rowstore) фрагментацией называют такое состояние, когда для некоторых страниц индекса логический порядок, основанный на значении ключа, не совпадает с физическим порядком страниц индексов». Отмечается также, что: «Если подсистема хранения имеет более высокую производительность последовательных операций ввода-вывода по сравнению с произвольными операциями ввода-вывода, то фрагментация индекса может привести к снижению производительности, ведь для чтения фрагментированных индексов требуется больше случайных операций ввода-вывода».

Это замечание важно, поскольку фактически является отсылкой к СХД на основе SSD, у которых все операции ввода вывода, как мы покажем дальше, являются случайными.

Есть ещё одно определение другого типа фрагментации, который в документации переведён на русский язык как «плотность страниц». С этим типом фрагментации связан важный факт, который влияет на актуальность статистик таблицы, не связанных с индексами. Вот, что написано в документации:

«Когда оптимизатор запросов компилирует план запроса, он учитывает стоимость операций ввода-вывода для чтения необходимых этому запросу данных. При низкой плотности страниц потребуется считывать больше страниц, а значит, и стоимость ввода-вывода будет выше. Это может повлиять на выбор плана запроса. Например, с течением времени плотность страниц уменьшается из-за разбиений, и оптимизатор может скомпилировать для того же запроса другой план с другой профилем потребления ресурсов и другой производительностью».

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

В качестве резюме по типам фрагментации приведём тут выдержку из статьи: «Индексы. Теоретические основы»

Когда запись удаляется, в файле БД высвобождается место. Когда вставляется новая запись, это может привести к расщеплению страниц, что приводит к появлению пустого пространства на страницах данных. Когда данные обновляются, это может привести к изменению размера записи и к возникновению двух ранее упоминавшихся случаев. Все это приводит к фрагментации. В SQL Server рассматриваются два типа фрагментации: внутренняя и внешняя.1.Внутренняя подразумевает пустоты внутри страницы.2. Внешняя – непоследовательность связей страниц.Если страницы не полностью заполнены данными, это приводит к дополнительным операциям I/O и переиспользованию оперативной памяти. Помните, что страницы в оперативной памяти есть зеркальное отражение страниц на диске.В идеале страницы должны быть подлинкованы слева направо в порядке хранения данных. Вследствие расщепления страниц этот порядок может быть нарушен. Это приводит как к неполному заполнению страниц, так и к увеличению операций I/O вследствие непоследовательного положения цепочек страниц на диске – это вызывает дополнительные перемещения головок с цилиндра на цилиндр диска. А это одна из наиболее медленных дисковых операций.

В упомянутой только что статье были представлены методы обслуживания индексов, применяемые для SQL Server 2000. Обслуживание подразумевает две возможные операции: реорганизация индексов на уровне страниц для устранения внутренней фрагментации, или пересоздание индекса для устранения и внутренней и внешней фрагментации.

Давайте посмотрим, как с этим обстоит дело в современных версиях. Ещё в электронной документации к SQL Server 2005 было описано динамическое административное представление sys.dm_db_index_physical_stats. Тогда описание сопровождалось примерами использования, один из которых предлагал метод и правила автоматизации операций дефрагментации индексов в базе данных. Суть метода в том, что если значение avg_fragmentation_in_percent находится в диапазоне от 10 до 30, то в инструкции ALTER INDEX используется ключевое слово REORGANIZE, а если значение больше 30, то используется ключевое слово REBUILD.

В документе Разрешение фрагментации индекса путем реорганизации или перестроения индекса, предлагается использовать подобранные эмпирическим путём значения, взяв за основу данные из следующей таблицы:

¹ _{Эти значения дают примерное представление об определении точки, в которой необходимо переключаться между ALTER INDEX REORGANIZE и ALTER INDEX REBUILD. Однако фактические значения могут различаться в каждом конкретном случае. Важно определить наилучшее пороговое значение для используемой среды экспериментальным путем.}

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

Существуют и другие предложения процентных порогов, один из которых был подробно изложен в книге: “Microsoft SQL Server 2005. Реализация и обслуживание. Учебный курс Microsoft“. Вот выдержка из этой книги, со страницы 368:

«Исполняйте инструкцию ALTER INDEX … REORGANIZE, чтобы выполнить дефрагментацию индекса, при соблюдении следующих пороговых значений: значение avg_page_space_used_in_percent в диапазоне от 60 до 75 или значение avg_fragmentation_in_percent в диапазоне от 10 до 15. Исполняйте инструкцию ALTER INDEX … REBUILD, чтобы выполнить дефрагментацию индекса, при соблюдении следующих пороговых значений: значение avg_page_space_used_in_percent меньше 60 или значение avg_fragmentation_in_percent больше 15».

В документации Майкрософт подчёркивается, что наибольший выигрыш дефрагментация даёт при операциях просмотра всего индекса или диапазона строк индекса или кучи. На операции поиска уровень фрагментации большого влияния не имеет. Это происходит потому, что просмотр выбирает данные не по дереву сбалансированного индекса, а по ссылкам на последовательность страниц, которые расположены непосредственно на самих страницах. На жёстких дисках время доступа к фрагментированным данным сильно зависит от времени позиционирования головок между цилиндрами. Операции с данными, расположенными на одном цилиндре, происходят быстро. Т.е. на время операций влияет Геометрия магнитного диска, которая схематично показана на рисунке из Википедии:

Всего этого механического «безобразия» больше нет на SSD дисках. Дефрагментация была полезна только для HDD c механическим перемещением головок над поверхностью диска. Расположение данных так, что для последовательного чтения не нужны перемещения готовки между «цилиндрами» позволяло повысить производительность последовательных операций чтения и записи. Надёжность и долговечность жёстких дисков тоже определяется возможностью перемещения головок. Пока это происходит штатно, диск будет работать, и возможности записи или чтения будут ограничены только старением или неисправностью привода.

В SSD дисках доступ к любым данным осуществляется за почти одинаковое время. Но в отличие от жёстких дисков, твердотельные диски изнашиваются, Для увеличения времени службы накопителя, ограниченного числом циклов перезаписи ячеек памяти, в SSD дисках используются алгоритмы рассеивания записи (для выравнивания износа), что превращает все последовательные операция чтения/записи в псевдослучайные. Схематично, это показано на рисунке ниже, взятого из стати Надежность SSD-накопителей: развенчиваем мифы и страхи пользователей.

С учётом этой особенности размещения данных на SSD можно отказаться от частого перестроения индексов, ограничившись реорганизацией или делать перестроение/реорганизацию вручную, при необходимости (например, для ускорения очистки фантомных строк или для сокращения времени пересчёта статистики). Прична банальна, SSD диск последовательную нагрузку всегда превращает в случайную. На логическом уровне индекс не будет фрагментирован, а на физическом фрагментация может быть абсолютной.

Для настольных компьютеров выполняемая не часто дефрагментация диска не приводит к заметному сокращению срока службы. Пользовательские файлы офисных приложений тоже фрагментируются. Те файлы, которые обычно пользователи размещают на дисках, не подвержены частой и интенсивной фрагментации. Если пользователь дефрагментирует файлы на диске раз в месяц – это не будет проблемой, хотя и не приведёт к ожидаемому повышению производительности, например, при создании моментального системного снимка. В отличие от этого, данные внутри файлов SQL Server могут подвергаться интенсивной фрагментации, и эта фрагментация может очень быстро достигать тех порогов, которые были обозначены выше, чтобы определить необходимость дефрагментации.

Для обслуживания индексов и статистики часто используют процедуру, автором которой является Ola Hallengren. В соответствии с выбранным набором параметров запуска, процедура устраняет внешнюю и внутреннею фрагментацию страниц. Следует отметить, что Майкрософт рекомендует для этих целей использовать процедуру AdaptiveIndexDefrag. Однако ни одна из этих процедур не умеет определять, располагаются ли файлы, в которых размещены индексы, на дисках SSD.

Те индексы, для которых был выбран REBUILD, обновляют статистику только для этих индексов. Цитата из документации Майкрософт, посвящённой статистике, глава Условия обновления статистики:

«Такие операции, как перестроение, дефрагментация и реорганизация индекса, не изменяют распределение данных, и поэтому после выполнения операций ALTER INDEX REBUILD, DBCC DBREINDEX, DBCC INDEXDEFRAG и ALTER INDEX REORGANIZE не нужно обновлять статистику. Но оптимизатор запросов обновляет статистику, когда выполняется перестройку индекса для таблицы или представления с помощью инструкции ALTER INDEX REBUILD или DBCC DBREINDEX. Такое обновление статистики является побочным эффектом повторного создания индекса. Оптимизатор запросов не обновляет статистику после операций DBCC INDEXDEFRAG и ALTER INDEX REORGANIZE. »

Однако, для оптимизатора запросов важным является ещё и стоимость операций ввода-вывода, которая зависит от плотности страниц. Если плотность страниц (внутренняя фрагментация) значительно изменится, а статистика для колонок останется неизменной, это может потенциально ввести оптимизатор в заблуждение и стать причиной выбора оптимизатором неоптимального плана запроса. Следует учитывать эти риски планируя обслуживание индексов.

Для размещённых на SSD дисках файлов данных, в подавляющем большинстве случаев дефрагментация не приведёт к ожидаемому повышению производительности дисковых операций, а только сократит срок службы SSD дисков и может привести к появлению неоптимальных планов запросов. Для SSD лучше полностью отказаться от перестроений и реорганизаций индексов на регулярной основе (это перестанет «убивать» диски). Такое решение кажется на первый взгляд весьма рискованным, влияние мифа о необходимости дефрагментации на нас очень велико. Если шок от этого предложения преодолеть трудно, попробуйте хотя бы не делать дефрагментацию каждый день и понаблюдайте за временем исполнения запросов. Когда поймёте, что время не меняется – продолжайте снижать частоту такого обслуживания. Отказавшись от ежедневной дефрагментации совсем, не забывайте обслуживать статистики индексов. Чем актуальнее статистики, тем проще оптимизатору выбирать хорошие планы для запросов.

Также увеличение числа страниц после изменений можно попробовать снизить за счёт сжатия данных индекса на уровне строк или страниц, как это описано тут: SQL SERVER – Rebuilding Index with Compression

Отказ от частой дефрагментации приведёт к следующим улучшениям:

1. Сокращение потребления ресурсов сервера на дефрагментацию

2. Дефрагментация портит статистику по колонкам (стоимость операций ввода-вывода), не входящим в ключ индекса. Без неё станет лучше статистика, а значит повысится качество планов запросов и сократиться время затронутых запросов.

3. Изменения распределения данных при дефрагментации передаются на реплики, поэтому отказ от дефрагментации сократит очереди на передачу и применение таких изменений.

4. Увеличится время жизни дисков SSD из-за сокращения числа циклов перезаписи ячеек хранения.

Теперь давайте перечислим те минусы, которые наиболее очевидны:

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

2. Увеличится время пересчёта статистик (стоит подобрать минимальный SAMPLE).

3. Размер файлов данных может заметно прибавить в весе.

До сих пор мы говорили об обслуживании индексов только в целях дефрагментации внешней и внутренней. Но это не единственное её предназначение. Пересоздание индексов можно использоваться для переноса данных в другую файловую группу, но эта операция обычно выполняется редко, необходимость её может ограничиваться единичными случаями. Более интересно перестроение индекса для удаления фантомных строк, как это указано в статье документации: Руководство по процессу очистки фантомных записей. В тех случаях, когда фоновый процесс очистки фантомных строк не успевает их чистить, и не удаётся эффективно использовать системную процедуру sp_clean_db_free_space, перестроение индекса оказывается наиболее быстрым и эффективным решением проблем с производительностью.

Резонный вопрос, почему в документации Майкрософт нет рекомендаций отказаться от дефрагментации индексов на SSD? Похоже, мы являемся свидетелями консервативного подхода, ориентированного прежде всего на небольшие базы данных, где пересоздание индексов не принесёт большого и даже заметного вреда. Однако, представленные выше в цитатах из документации оговорки должны обратить наше внимание на то, что к этому вопросу стоит подойти с разумением.

SQL Server 2017: возобновляемое перестроение индексов

Перестроение индексов на критических БД зачастую может быть сложной операцией по ряду причин. Наверное, практически каждый администратор БД сталкивался с длительными блокировками по время обслуживания индексов и ростом журнала транзакций. Отчасти может помочь перестроение индексов в режиме ONLINE или же операция REORGANIZE, но в SQL Server 2017 также в помощь приходит такая возможность, как возобновляемое перестроение, которая позволяет обходить проблемы, которые до этого не решались стандартными способами.

Операция ALTER INDEX теперь может ставить перестроение на паузу или возобновлять его, что позволяет управлять процессом обслуживания индексов более гранулярно. Представьте ситуацию: вы обнаружили, что процесс перестроения большого индекса сильно нагружает диск или блокирует важные процессы, и, вместо того, чтобы его прервать, вы просто ставите его на паузу и возобновляете, когда снова появляется возможность.

Конечно, приходится чем-то жертвовать ради удобства. В данном случае в БД необходимо будет хранить обе копии индекса: старую и новую до тех пор пока операция не завершится успешно или не будет прервана. Еще одним неприятным моментом может стать то, что опция SORT_IN_TEMPDB не работает в паре с возобновляемым перестроением.

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

Итак, давайте посмотрим на примере, как это работает. Для того, чтобы инициировать процесс перестроения индекса, который затем можно будет прервать, необходимо указать опции ONLINE=ON и RESUMABLE=ON.

alter index pk_MyBigDemoTable on [dbo].[MyBigDemoTable] rebuild with (resumable = on, online = on)

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

select * from sys.index_resumable_operations

Очень удобно, что отображается, идет ли сейчас перестроение, когда началось, когда прерывалось, процент выполнения.

Во время выполнения этого перестроения в отдельной сессии вы можете управлять им с помощью следующих команд.

alter index pk_MyBigDemoTable on [dbo].[MyBigDemoTable] pause
alter index pk_MyBigDemoTable on [dbo].[MyBigDemoTable] resume
alter index pk_MyBigDemoTable on [dbo].[MyBigDemoTable] abort

PAUSE\RESUME позволяют останавливать и продолжать перестроение, в то время как команда ABORT может его полностью прервать, если вам вдруг это понадобилось.

При возобновление вы можете менять параметр MAXDOP.

alter index pk_MyBigDemoTable on [dbo].[MyBigDemoTable] resume with (maxdop = 4)

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

alter index pk_MyBigDemoTable on [dbo].[MyBigDemoTable] rebuild with (resumable = on, online = on, max_duration = 1)

Как мы видим, новая возможность довольно интересна и позволяет вывести обслуживание индексов на новый уровень. Также вы можете посмотреть следующее видео на YouTube, где есть более детальная демонстрация использования этой возможности.

Обслуживание индексов и статистики SQL Server

IndexOptimize — это хранимая процедура решения для обслуживания SQL Server для перестроения и реорганизации индексов и обновления статистики. IndexOptimize поддерживается в SQL Server 2008, SQL Server 2008 R2, SQL Server 2012, SQL Server 2014, SQL Server 2016, SQL Server 2017, SQL Server 2019, SQL Server 2022, базе данных SQL Azure и управляемом экземпляре SQL Azure.

Загрузить

Загрузить MaintenanceSolution.sql. Этот скрипт создает все объекты и задания, которые вам нужны. Вы также можете скачать объекты как отдельные скрипты. Решение для обслуживания SQL Server доступно на GitHub.

Лицензия

Решение для обслуживания SQL Server является бесплатным.

Параметры

Базы данных

Выберите базы данных. Поддерживаются ключевые слова SYSTEM_DATABASES, USER_DATABASES, ALL_DATABASES и AVAILABILITY_GROUP_DATABASES. Символ дефиса (-) используется для исключения баз данных, а символ процента (%) используется для выбора подстановочных знаков. Все эти операции можно объединить с помощью запятой (,).

FragmentationLow

Укажите операции обслуживания индекса, которые должны выполняться для малофрагментированного индекса.

Значение	Описание
INDEX_REBUILD_ONLINE	Перестроить индекс онлайн.
INDEX_REBUILD_OFFLINE	Перестроить индекс в автономном режиме.
ИНДЕКС_РЕОРГАНИЗАЦИЯ	Реорганизовать индекс.
INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE	Перестроить индекс онлайн. Перестроить индекс в автономном режиме, если оперативное перестроение не поддерживается для индекса.
INDEX_REBUILD_ONLINE, INDEX_REORGANIZE	Перестроить индекс онлайн. Реорганизуйте индекс, если он-лайн перестроение не поддерживается для индекса.
INDEX_REORGANIZE, INDEX_REBUILD_ONLINE, INDEX_REBUILD_OFFLINE	Реорганизовать индекс. Перестройте индекс онлайн, если реорганизация не поддерживается для индекса. Перестройте индекс в автономном режиме, если реорганизация и оперативное перестроение не поддерживаются для индекса.
ПУСТО	Не выполнять обслуживание индекса. Это значение по умолчанию для низкофрагментированного индекса.

Онлайновое перестроение индекса или реорганизация индекса не всегда возможны. Благодаря этому вы можете указать несколько операций обслуживания индекса для каждой группы фрагментации. Эти операции имеют приоритет слева направо: если для индекса поддерживается первая операция, то используется эта операция; если первая операция не поддерживается, то используется вторая операция (если поддерживается) и т.д. Если ни одна из указанных операций не поддерживается для индекса, то этот индекс не поддерживается.

IndexOptimize использует команду SQL Server ALTER INDEX: REBUILD WITH (ONLINE = ON) для перестроения индексов в оперативном режиме, REBUILD WITH (ONLINE = OFF) для перестроения индексов в автономном режиме и REORGANIZE для реорганизации индексов.

FragmentationMedium

Укажите операции обслуживания индекса, которые должны выполняться на среднефрагментированном индексе.

Значение	Описание
INDEX_REBUILD_ONLINE	Перестроить индекс онлайн.
INDEX_REBUILD_OFFLINE	Перестроить индекс в автономном режиме.
ИНДЕКС_РЕОРГАНИЗАЦИЯ	Реорганизовать индекс.
INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE	Перестроить индекс онлайн. Перестроить индекс в автономном режиме, если оперативное перестроение не поддерживается для индекса.
INDEX_REBUILD_ONLINE, INDEX_REORGANIZE	Перестроить индекс онлайн. Реорганизуйте индекс, если он-лайн перестроение не поддерживается для индекса.
INDEX_REORGANIZE, INDEX_REBUILD_ONLINE, INDEX_REBUILD_OFFLINE	Реорганизовать индекс. Перестройте индекс онлайн, если реорганизация не поддерживается для индекса. Перестройте индекс в автономном режиме, если реорганизация и оперативное перестроение не поддерживаются для индекса. Это значение по умолчанию для среднефрагментированного индекса.
ПУСТО	Не выполнять обслуживание индекса.

Онлайновое перестроение индекса или реорганизация индекса не всегда возможны. Благодаря этому вы можете указать несколько операций обслуживания индекса для каждой группы фрагментации. Эти операции имеют приоритет слева направо: если для индекса поддерживается первая операция, то используется эта операция; если первая операция не поддерживается, то используется вторая операция (если поддерживается) и т.д. Если ни одна из указанных операций не поддерживается для индекса, то этот индекс не поддерживается.

IndexOptimize использует команду SQL Server ALTER INDEX: REBUILD WITH (ONLINE = ON) для перестроения индексов в оперативном режиме, REBUILD WITH (ONLINE = OFF) для перестроения индексов в автономном режиме и REORGANIZE для реорганизации индексов.

FragmentationHigh

Укажите операции обслуживания индекса, которые должны выполняться для высокофрагментированного индекса.

Значение	Описание
INDEX_REBUILD_ONLINE	Перестроить индекс онлайн.
INDEX_REBUILD_OFFLINE	Перестроить индекс в автономном режиме.
ИНДЕКС_РЕОРГАНИЗАЦИЯ	Реорганизовать индекс.
INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE	Перестроить индекс онлайн. Перестроить индекс в автономном режиме, если оперативное перестроение не поддерживается для индекса. Это значение по умолчанию для высокофрагментированного индекса.
INDEX_REBUILD_ONLINE, INDEX_REORGANIZE	Перестроить индекс онлайн. Реорганизуйте индекс, если он-лайн перестроение не поддерживается для индекса.
INDEX_REORGANIZE, INDEX_REBUILD_ONLINE, INDEX_REBUILD_OFFLINE	Реорганизовать индекс. Перестройте индекс онлайн, если реорганизация не поддерживается для индекса. Перестройте индекс в автономном режиме, если реорганизация и оперативное перестроение не поддерживаются для индекса.
ПУСТО	Не выполнять обслуживание индекса.

Онлайновое перестроение индекса или реорганизация индекса не всегда возможны. Благодаря этому вы можете указать несколько операций обслуживания индекса для каждой группы фрагментации. Эти операции имеют приоритет слева направо: если для индекса поддерживается первая операция, то используется эта операция; если первая операция не поддерживается, то используется вторая операция (если поддерживается) и т.д. Если ни одна из указанных операций не поддерживается для индекса, то этот индекс не поддерживается.

IndexOptimize использует команду SQL Server ALTER INDEX: REBUILD WITH (ONLINE = ON) для перестроения индексов в оперативном режиме, REBUILD WITH (ONLINE = OFF) для перестроения индексов в автономном режиме и REORGANIZE для реорганизации индексов.

FragmentationLevel1

Установите нижний предел в процентах для средней фрагментации. По умолчанию 5 процентов. Это основано на рекомендации Microsoft в электронной документации.

IndexOptimize проверяет avg_fragmentation_in_percent в sys.dm_db_index_physical_stats для определения фрагментации.

FragmentationLevel2

Установите нижний предел в процентах для высокой фрагментации. Значение по умолчанию составляет 30 процентов. Это основано на рекомендации Microsoft в электронной документации.

IndexOptimize проверяет avg_fragmentation_in_percent в sys.dm_db_index_physical_stats для определения фрагментации.

MinNumberOfPages

Установить размер в страницах; индексы с меньшим количеством страниц пропускаются для обслуживания индекса. По умолчанию 1000 страниц. Это основано на рекомендации Microsoft.

IndexOptimize проверяет page_count в sys.dm_db_index_physical_stats, чтобы определить размер индекса.

MaxNumberOfPages

Установить размер в страницах; индексы с большим количеством страниц пропускаются для обслуживания индекса. По умолчанию нет ограничений.

IndexOptimize проверяет page_count в sys. dm_db_index_physical_stats, чтобы определить размер индекса.

SortInTempdb

Использовать базу данных tempdb для операций сортировки при перестроении индексов.

Параметр SortInTempdb в IndexOptimize использует параметр SORT_IN_TEMPDB в команде SQL Server ALTER INDEX.

MaxDOP

Укажите количество ЦП, которое будет использоваться при перестроении индексов. Если это число не указано, используется глобальная максимальная степень параллелизма.

Параметр MaxDOP в IndexOptimize использует параметр MAXDOP в команде SQL Server ALTER INDEX.

FillFactor

Указывает в процентах, насколько заполненными должны быть страницы при перестроении индексов. Если процент не указан, используется коэффициент заполнения в sys.indexes.

Параметр FillFactor в IndexOptimize использует параметр FILLFACTOR в команде SQL Server ALTER INDEX.

PadIndex

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

Параметр PadIndex в IndexOptimize использует параметр PADINDEX в команде SQL Server ALTER INDEX.

LOBCompact

Компактные страницы, содержащие столбцы больших объектов (LOB), при реорганизации индексов.

Значение	Описание
Д	Компактные страницы, содержащие столбцы больших объектов, при реорганизации индексов. Это значение по умолчанию.
Н	Не сжимайте страницы, содержащие столбцы больших объектов, при реорганизации индексов.

Параметр LOBCompaction в IndexOptimize использует параметр LOB_COMPACTION в команде SQL Server ALTER INDEX.

UpdateStatistics

Обновить статистику.

IndexOptimize использует команду SQL Server UPDATE STATISTICS для обновления статистики.

OnlyModifiedStatistics

Обновлять статистику, только если какие-либо строки были изменены с момента последнего обновления статистики.

Значение	Описание
Д	Обновлять статистику, только если какие-либо строки были изменены с момента последнего обновления статистики.
Н	Обновлять статистику независимо от того, были ли изменены какие-либо строки.

IndexOptimize проверяет счетчик модификации в sys.dm_db_stats_properties, в SQL Server 2008 R2, начиная с пакета обновления 2, и в SQL Server 2012, начиная с пакета обновления 1. В более ранних версиях он проверяет rowmodctr в sys.sysindexes. Для инкрементной статистики он проверяет модификационный_счетчик в sys.dm_db_incremental_stats_properties.

StatisticsModificationLevel

Укажите процент измененных строк, когда статистика должна быть обновлена. Статистика также будет обновляться, когда количество измененных строк достигнет уменьшающегося динамического порога SQRT (количество строк * 1000).

IndexOptimize проверяет столбцы «modification_counter» и строки в sys.dm_db_stats_properties в SQL Server 2008 R2, начиная с пакета обновления 2, и в SQL Server 2012, начиная с пакета обновления 1. В более ранних версиях он проверяет столбцы rowmodctr и rowcnt в sys. sysindexes. Для инкрементной статистики он проверяет столбцы modification_counter и строки в sys.dm_db_incremental_stats_properties.

StatisticsSample

Указывает в процентах, какая часть таблицы собирается при обновлении статистики. Значение 100 эквивалентно полному сканированию. Если значение не указано, SQL Server автоматически вычисляет требуемую выборку.

Параметр StatisticsSample в IndexOptimize использует параметры SAMPLE и FULLSCAN в команде SQL Server UPDATE STATISTICS.

StatisticsResample

Обновить статистику самой последней выборкой.

Параметр StatisticsResample в IndexOptimize использует параметр RESAMPLE в команде SQL Server UPDATE STATISTICS.

Нельзя комбинировать параметры StatisticsSample и StatisticsResample.

Раздел Уровень

Поддерживать секционированные индексы на уровне секций. Если для этого параметра задано значение Y, уровень фрагментации и количество страниц проверяются для каждого раздела. Затем для каждого раздела выполняется соответствующее обслуживание индекса (реорганизация или перестроение).

MSShippedObjects

Поддерживать индексы и статистику по объектам, созданным внутренними компонентами SQL Server.

Значение	Описание
Д	Поддерживайте индексы и статистику по объектам, созданным внутренними компонентами SQL Server.
Н	Не вести индексы и статистику по объектам, созданным внутренними компонентами SQL Server. Это значение по умолчанию.

IndexOptimize проверяет is_ms_shipped в sys.objects, чтобы определить, был ли объект создан внутренним компонентом SQL Server.

Индексы

Выберите индексы. Если этот параметр не указан, выбираются все индексы. Ключевое слово ALL_INDEXES поддерживается. Символ дефиса (-) используется для исключения индексов, а символ процента (%) используется для выбора подстановочного знака. Все эти операции можно объединить с помощью запятой (,).

Значение	Описание
ВСЕ_ИНДЕКСЫ	Все индексы
Дб1.Схема1.Тбл1.Идкс1	Индекс Idx1 по объекту Schema1.Tbl1 в базе данных Db1
Db1.Schema1.Tbl1.Idx1, Db2.Schema2.Tbl2.Idx2	Индекс Idx1 на объекте Schema1.Tbl1 в базе данных Db1 и индекс Idx2 на объекте Schema2.Tbl2 в базе данных Db2
Дб1.Схема1.Тбл1	Все индексы объекта Schema1.Tbl1 в базе данных Db1
Дб1. Схема1.Тбл1, Дб2.Схема2.Тбл2	Все индексы объекта Schema1.Tbl1 в базе данных Db1 и все индексы объекта Schema2.Tbl2 в базе данных Db2
Дб1.Схема1.%	Все индексы в схеме Schema1 в базе данных Db1
%.Схема1.%	Все индексы в схеме Schema1 во всех базах данных
ALL_INDEXES, -Db1.Schema1.Tbl1.Idx1	Все индексы, кроме индекса Idx1 объекта Schema1.Tbl1 в базе данных Db1
ALL_INDEXES, -Db1.Schema1.Tbl1	Все индексы, кроме индексов объекта Schema1.Tbl1 в базе данных Db1

TimeLimit

Установите время в секундах, по истечении которого никакие команды не выполняются. По умолчанию время не ограничено.

Задержка

Установите задержку в секундах между командами индекса. По умолчанию задержки нет.

WaitAtLowPriorityMaxDuration

Время в минутах, в течение которого оперативная операция перестроения индекса будет ожидать блокировки с низким приоритетом.

Параметр WaitAtLowPriorityMaxDuration в IndexOptimize использует параметры WAIT_AT_LOW_PRIORITY и MAX_DURATION в команде SQL Server ALTER INDEX.

WaitAtLowPriorityAbortAfterWait

Действие, которое будет выполнено после того, как оперативная операция перестроения индекса ожидает блокировки с низким приоритетом.

Параметр WaitAtLowPriorityAbortAfterWait в IndexOptimize использует параметры WAIT_AT_LOW_PRIORITY и ABORT_AFTER_WAIT в команде SQL Server ALTER INDEX.

Resumable

Укажите, можно ли возобновить онлайн-операцию с индексом.

Значение	Описание
Д	Операция с индексом может быть возобновлена.
Н	Операция с индексом не может быть возобновлена. Это значение по умолчанию.

Параметр Resumable в IndexOptimize использует параметр RESUMABLE в команде SQL Server ALTER INDEX.

Группы доступности

Выберите группы доступности. Ключевое слово ALL_AVAILABILITY_GROUPS поддерживается. Символ дефиса (-) используется для исключения групп доступности, а символ процента (%) используется для выбора подстановочных знаков. Все эти операции можно объединить с помощью запятой (,).

LockTimeout

Установите время в секундах, в течение которого команда ожидает снятия блокировки. По умолчанию время не ограничено.

Параметр LockTimeout в IndexOptimize использует оператор установки SET LOCK_TIMEOUT в SQL Server.

LockMessageSeverity

Установите серьезность тайм-аутов блокировки и взаимоблокировок.

StringDelimiter

Укажите разделитель строк. По умолчанию разделителем строк является запятая.

DatabaseOrder

Укажите порядок базы данных.

DatabasesInParallel

Параллельная обработка баз данных.

Вы можете обрабатывать базы данных параллельно, создавая несколько заданий с одинаковыми параметрами и добавляя параметр @DatabasesInParallel = ‘Y’.

ExecuteAsUser

Изменить контекст выполнения на пользователя. Пользователь может быть dbo или любым другим пользователем. Пользователь должен существовать во всех базах данных, с которыми вы работаете.

Параметр ExecuteAsUser в IndexOptimize использует команду EXECUTE AS в SQL Server.

LogToTable

Записывать команды в таблицу dbo.CommandLog.

Значение	Описание
Д	Записывать команды в таблицу.
Н	Не записывать команды в таблицу. Это значение по умолчанию.

Выполнить

Выполнить команды. По умолчанию команды выполняются нормально. Если для этого параметра установлено значение N, то команды печатаются только.

Примеры

A. Перестроить или реорганизовать все индексы с фрагментацией во всех пользовательских базах данных

ВЫПОЛНИТЬ dbo.IndexOptimize
@Databases = ‘USER_DATABASES’,
@FragmentationLow = NULL, 902 41 @FragmentationMedium = ‘INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE’,
@FragmentationHigh = ‘INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE’,
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30 90 003

B. Перестроить или реорганизовать все индексы с фрагментацией и обновить измененную статистику во всех пользовательских базах данных EX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE’,

@FragmentationHigh = ‘INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE’,
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30,
@UpdateStatistics = ‘ALL’,
@ Толькомодифиедстатистикс = ‘Д’

C.

Обновить статистику по всем пользовательским базам данных

ВЫПОЛНИТЬ dbo.IndexOptimize
@Databases = ‘USER_DATABASES’,
@FragmentationLow = NULL,
@FragmentationMedium = NULL,
@FragmentationHigh = NULL, 9 0241 @UpdateStatistics = ‘ALL’

D. Обновить измененную статистику по всем пользовательским базам данных

EXECUTE dbo.IndexOptimize
@Databases = ‘USER_DATABASES’,
@FragmentationLow = NULL,
@FragmentationMedium = NULL, 90 241 @FragmentationHigh = NULL,
@UpdateStatistics = ‘ALL’,
@OnlyModifiedStatistics = ‘Y’

E. Перестроить или реорганизовать все индексы с фрагментацией во всех пользовательских базах данных, выполняя операции сортировки в tempdb и используя все доступные процессоры

EXECUTE dbo.IndexOptimize
@Databases = ‘USER_DATABASES’,
@FragmentationLow = NULL,
@FragmentationMedium = ‘INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE’,
@FragmentationHigh = ‘INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE’,
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30,
@SortInTempdb = ‘Y’,
@MaxDOP = 0

F.

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

ВЫПОЛНИТЬ dbo.Index Оптимизация
@Databases = ‘USER_DATABASES’,
@FragmentationLow = NULL,
@FragmentationMedium = ‘INDEX_REORGANIZE, INDEX_REBUILD_ONLINE, INDEX_REBUILD_OFFLINE’,
@FragmentationHigh = ‘INDEX_REBUILD_ONLINE, INDEX_RE BUILD_OFFLINE’,
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30,
@PartitionLevel = ‘Y’

G. Перестроить или реорганизовать все индексы с фрагментацией во всех пользовательских базах данных с ограничением по времени, чтобы никакие команды не выполнялись через 3600 секунд

EXECUTE dbo .IndexOptimize
@Databases = ‘USER_DATABASES’,
@FragmentationLow = NULL,
@FragmentationMedium = ‘INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE’,
@FragmentationHigh=’INDEX_REBUILD_ONLINE,IND EX_REBUILD_OFFLINE’,
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30,
@TimeLimit = 3600

H.

Перестроить или реорганизовать все индексы с фрагментацией в таблице Production.Product в базе данных AdventureWorks

EXECUTE dbo.IndexOptimize 902 41 @Databases = ‘AdventureWorks’,
@FragmentationLow = NULL,
@FragmentationMedium = ‘INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE’,
@FragmentationHigh = ‘INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE’,
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30,
@Indexes = ‘AdventureWorks.Production.Product’

I. Перестроить или реорганизовать все индексы с фрагментацией, кроме индексов таблицы Production.Product в базе данных AdventureWorks

EXECUTE dbo.IndexOptimize
@Database s = ‘USER_DATABASES’,
@FragmentationLow = NULL,
@FragmentationMedium = ‘INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE’,
@FragmentationHigh = ‘INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE’,
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30,
@Indexes = ‘ALL_INDEXES, -AdventureWorks. Production.Product’

J. Перестроить или реорганизовать все индексы с фрагментацией во всех пользовательских базах данных и записать результаты в таблицу

EXECUTE dbo.IndexOptimize
@Databases = ‘USER_DATABASES’,
@FragmentationLow = NULL,
@FragmentationMedium = ‘INDEX_REORGANIZE, INDEX_REBUILD_ONLINE, INDEX_REBUILD_OFFLINE’,
@FragmentationHigh = ‘INDEX_REBUIL D_ONLINE,INDEX_REBUILD_OFFLINE’,
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30,
@LogToTable = ‘Y’

Выполнение

Вы можете выполнять хранимые процедуры из шагов задания T-SQL или из шагов задания CmdExec с помощью sqlcmd и параметра -b.

В SQL Server 2005, 2008 и 2008 R2 существует проблема, заключающаяся в том, что шаг задания T-SQL перестает выполняться после первой ошибки. Используйте шаги задания CmdExec с sqlcmd и параметром -b в этих версиях.

Для создания заданий можно использовать сценарий MaintenanceSolution.sql. Он создаст шаги задания CmdExec с помощью sqlcmd в SQL Server 2005, 2008 и 2008 R2 и шаги задания T-SQL в более поздних версиях.

Как реорганизовать и перестроить индекс в SQL Server All Version

Нилеш Кумар |
Изменено: 27 августа 2022 г. | SQL-сервер | 10 минут чтения

Сводка: Когда ваш индекс SQL Server становится фрагментированным, ваш сервер избегает его использования. Совершенно очевидно, что фрагментация приводит к снижению производительности запросов и параллелизма данных. В этой статье мы собираемся реорганизовать и перестроить индекс в SQL Server, выполнив операции дефрагментации.

Загрузить сейчас Купить сейчас

Однако, даже если операция дефрагментации индекса SQL Server необходима, она все равно может привести к повреждению файлов данных. Загрузка идеального решения для устранения повреждений может помочь с немедленным эффектом.

Вышеприведенное изображение имеет индексную структуру B-дерева. Здесь B означает сбалансированный. Это многоуровневый структурированный индекс, имеющий различные уровни: корневой, промежуточный и конечный.

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

• Фактические физические данные размещены в кластеризованном индексе.
• Логический порядок таблицы определяется кластеризованными индексами.

Если мы посмотрим на некластеризованный индекс, он тоже очень похож, но указывает на кластеризованный индекс своих собственных данных. Далее мы собираемся выполнить скрипт дефрагментации индекса SQL Server, обратите внимание, статья будет немного технической. Таким образом, вы можете легко выполнять задачи SQL Server Reorganize SQL Server Rebuild.

Читайте также: Узнайте, как исправить отсутствующие индексы в SQL Server — восстановить недостающие данные

Как перестроить и реорганизовать индексы в SQL Server? – Основы

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

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

Проще говоря, индекс B-дерева может быть фрагментирован, если существует несоответствие между логическим и физическим порядком страниц индекса. Например, когда мы добавляем строки в таблицу, индекс становится фрагментированным. База данных SQL быстро изменяет все связанные с ней индексы. Теперь существующие страницы можно разделить, чтобы освободить место для новых строк.

Добавление строки на страницу с недостаточным пространством приводит к созданию новой страницы. Однако новая страница может быть последней по порядку, но может содержать данные с предыдущих страниц. Это создает путаницу для базы данных и увеличивает время обработки. Следовательно, приводит к деградации производительности. Вот почему пользователи выполняют операции реорганизации индекса SQL Server.

Теперь мы можем сказать, что существует два типа фрагментации данных. Для выполнения дефрагментации всех индексов SQL Server нам нужно знать об этом больше. Ниже приведены типы:

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

Пользователям необходимо научиться определять и устранять фрагментацию индекса SQL Server, чтобы решить эту проблему. Однако это непростая задача, поскольку она содержит риск повреждения базы данных SQL . У нас есть несколько решений для решения этой проблемы, таких как перестройка и реорганизация баз данных SQL.

Реорганизация и перестроение индекса в SQL Server — это решение

Реорганизация задач — это первый вариант, доступный пользователям. Он просто упорядочивает страницы указателя более упрощенным образом. Для выполнения этого ниже приведены инструкции:

• Попробуйте объединить строки индекса и освободить некоторые страницы.
• Изменяйте оставшиеся страницы небольшими транзакциями, пока все страницы не вернутся в порядок. К концу ваш логический порядок индексов сможет реплицировать физический порядок индексов.

ИТ-специалисты рассматривают этот метод для экономии места, поскольку он эффективен. Для этого требуется временная страница хранения размером всего 8 КБ. Итак, вот как безопасно реорганизовать индекс в SQL Server.

В случае высокой фрагментации эта задача может занять довольно много времени, фактически дольше, чем задача переиндексации. Хотя ваш стол не будет заблокирован во время операции. Так что это облегчение для пользователей, если им нужна быстрая дефрагментация индекса SQL Server.

Если мы выполняем очень длительную задачу реорганизации, мы можем приостановить ее для обычной работы, а затем возобновить. На данный момент это кажется хорошей функцией для пользователей. Кроме того, не забудьте составить план RTO и RPO в SQL Server for Disaster Recovery & Management 9.1041 .

Как перестроить и реорганизовать индексы в SQL Server — подробно

Теперь, после задачи реорганизации, пришло время для задачи по перестроению для пользователей. Эта задача полностью отличается от предыдущей. Он просто создает новый индекс в базе данных, а затем стирает старый. Независимо от фрагментации в старом индексе, это может произойти. Пользователи должны убедиться, что в их базе данных достаточно места для этого нового индекса. Это может помочь нам в дефрагментации всех индексов SQL Server.

Пользователи могут увидеть два варианта операции восстановления. Один из них находится в сети, а другой – офлайн. Однако только корпоративная версия SQL Server поддерживает онлайн-тип. С другой стороны, стандартная версия поддерживает только автономный тип.

Если ваш индекс будет оставаться в сети во время операции, это называется онлайн-режимом. В противном случае это автономный режим, когда он сохраняется в системе. Мы можем выполнять индексы дефрагментации SQL Server на обоих.

Перестроить SQL-индексы в автономном режиме:

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

Перестроить индексы SQL Онлайн:

• Эта процедура точно такая же, как и в автономном режиме. Просто у него очень незначительные отличия.
• Онлайновое перестроение просто блокирует базовую таблицу или индекс.

Как определить и устранить фрагментацию индекса SQL Server?

Мы все должны знать степень фрагментации перед началом любой процедуры. Это может помочь нам решить проблемы с максимальным совершенством. Чтобы получить степень дефрагментации, мы можем использовать DMF по sys.dm_db_index_physical_stats . На изображении ниже вы можете увидеть, как узнать процент степени фрагментации.

Выбор правильной процедуры дефрагментации можно выполнить в соответствии с онлайн-книгами Microsoft. Сценарий индекса дефрагментации SQL Server может потребоваться позже. Так что пользователи должны быть готовы.

• Дефрагментация не требуется, если степень фрагментации менее 5%.
• Реорганизация является советом в случае фрагментации от 5% до 30%.
• Если уровень фрагментации превышает 30 %, идеальным выбором является перестроение.

Пользователи должны понимать, что изучение перестроения так же важно, как и изучение того, как реорганизовать все индексы в SQL Server. Пользователи должны принимать мудрые решения.

Реорганизация и перестроение индекса в SQL Server с помощью команды T-SQL

Давайте начнем изучение индексов дефрагментации SQL Server с помощью ручного метода запроса. Здесь мы собираемся использовать сценарий SQL Server для безопасного перестроения фрагментированных индексов. Теперь мы собираемся понять этот метод с помощью примера. Допустим, у нас есть таблица OrdTes с индексом 9.1040 IDX_OrdTes_DateDoc в нашей базе. Вы можете воспользоваться помощью изображения ниже, чтобы лучше понять.

Теперь нужно либо перестроить индексы, либо реорганизовать. Таким образом, мы можем просто организовать индекс SQL, используя первый синтаксис T-SQL, а затем, используя второй, мы можем легко использовать второй.

Если нам нужно узнать, как реорганизовать все индексы в SQL Server сразу, эта команда поможет нам в этом. Давайте перейдем к следующему разделу, чтобы узнать еще больше.

Как реорганизовать все индексы в SQL Server — метод SSMS

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

Реорганизация с помощью SSMS

1. Перейдите в обозреватель объектов >> Развернуть базу данных , имеющую таблицу с фрагментированным индексом.
2. Открыть таблица Папка >> Развернуть таблицу >> Щелкните правой кнопкой мыши index Папка >> Выберите параметр Реорганизовать .
3. Проверить , что индекс содержит все правильные индексы >> Теперь Выберите Индекс и Щелкните на кнопке Удалить .
4. Включите флажок «Сжать данные столбца больших объектов» здесь.
5. Нажмите на кнопку Ok .

Перестроение с использованием SSMS

1. Перейдите в обозреватель объектов >> Развернуть базу данных , имеющую таблицу с фрагментированным индексом.
2. Открыть таблицу Папка >> Развернуть таблицу >> Щелкните правой кнопкой мыши индекс Папка >> Выберите параметр Восстановить .
3. Проверить , что в индексе есть все правильные индексы & Нажмите на кнопке Ok .
4. Включите флажок «Сжать данные столбца больших объектов» здесь.
5. Нажмите на кнопке Ok .

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

SQL Server Дефрагментация всех индексов в плане обслуживания

Как мы знаем, важность стратегии дефрагментации довольно высока. Давайте составим для него план обслуживания. Поскольку мы знаем, как реорганизовать индекс в SQL Server, теперь нам просто нужно настроить план. Таким образом, мы можем автоматически выполнить необходимую операцию без особых хлопот.

Чтобы составить новый план, Перейдите к в меню управления , Щелкните правой кнопкой мыши на элементе обслуживания . Теперь просто Нажмите в опции New Maintenance Plan .

Теперь просто Перетащите «Реорганизация задачи индекса» и «Реконструкция задачи индекса» в центр экрана. Кроме того, внимательно следуйте сценарию индекса дефрагментации SQL Server в предыдущем разделе, чтобы выполнить эти шаги.

После добавления обеих задач нам просто нужно установить их соответствующим образом. Вы можете проверить это ниже.

Установить задачу реорганизации SQL в плане обслуживания:

• Выделить базу данных, в которой будет выполняться операция.
• Выберите операцию реорганизации только для необходимой базовой, пользовательской или системной базы данных.
• Выберите условия, при которых вы хотите реорганизовать индексы. Например: после фиксированного процента фрагментации.

Установить задачу Rebuild Rebuild Index SQL Server в плане обслуживания:

• Выделить базу данных, в которой будет выполняться операция.
• Выберите операцию перестроения только для необходимой базовой, пользовательской или системной базы данных.
• Выберите условия, при которых вы хотите перестроить индексы. Например: после фиксированного процента фрагментации.

Наконец, сохраните план обслуживания , нажав кнопку OK . Кроме того, запланируйте его работу на определенной частоте. Вот как мы можем научиться реорганизовывать индекс в SQL Server, а также перестраивать его.

Заключение

Наконец, мы можем сказать, что знаем, как реорганизовать и перестроить индекс в SQL Server. Теперь нам просто нужно позаботиться об одном. Когда мы выполняем задачи дефрагментации индексов SQL Server, наши файлы подвергаются максимальному риску. Мы должны быть готовы к худшему сценарию.

Инструмент восстановления базы данных SQL является одним из таких инструментов, который может восстанавливать и восстанавливать поврежденные и потерянные файлы данных в таких ситуациях.