SQL Server inside

Построение индексов – часть 6: построение секционированного индекса (Продолжение - Параллельное построение)

Параллельное построение выровненных секционированных индексов 

В случае параллельного построения индекса, сканирование и сортировка секций осуществляется параллельно и реальное число промежуточных структур сортировки существующих одновременно зависит от числа исполнителей работающих одновременно. Секции выбираются для сканирования и сортировки одна за другой и, когда один исполнитель заканчивает работу с очередной секцией, он выбирает следующую секцию, еще не взятую ни одним исполнителем. Каждый исполнитель, таким образом, строит 0 – N секций (одна секция не может быть распределена между несколькими исполнителями).  Почему может быть 0? Если  DOP (уровень параллелизма) > числа секций,  то не все исполнители получат секцию для работы над ней. Над какой секцией будет работать определенный исполнитель?  Это не детерминистическое решение.

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

Для построения секционированного индекса не нужна финальная «сшивка»  - каждая секция таково индекса существует как отдельное b-дерево.

Как это влияет на требования к свободному дисковому пространству:

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

-         В случае сортировки в tempdb (SORT_IN_TEMPDB = ON) мы не получим того же преимущества в использовании дискового пространства как в случае последовательного построения, так как несколько промежуточных структур сортировки могут существовать одновременно. Кроме того, так как распределение данных между секциями изначально не известно, считаем, что нам может потребоваться все те же 2.2*(Размер индекса) свободного дискового пространства в tempdb.

Некоторые соображения об использовании памяти:

Так как в одно и тоже время существует несколько промежуточных структура сортировки (реальное количество, существующих одновременно, структур будет зависеть от #DOP (уровня параллелизма) и количества секций), и каждая структура требует 40 страниц памяти, чтобы начать построение индекса, минимальная необходимая память составит - #DOP*40страниц.

Общее объем памяти = минимально требуемая память + дополнительная память.

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

Читайте в следующих постах о построении не выровненного секционированного индекса J