http://blogs.technet.com/lyudmila_fokina/default.aspx
Людмила Фокина
Параллельное построение невыровненных секционированных индексов:
В одном из предыдущих постов я писала, что существуют две категории секционированных индексов:
- Выровненные (когда базовая
таблица и индекс используют одинаковые функции секционирования)
- Невыровненные (когда базовая
таблица и индекс используют одинаковые функции секционирования (включая
случай, когда базовая таблица вообще не секционирована, а индекс
секционирован).
Пришло время поговорить о втором случае – невыровненных секционированных индексах. Здесь существуют два возможных сценария:
- Базовая таблица не
секционирована, а индекс секционирован;
- Базовая таблица и индекс используют разные функции секционирования
Базовая таблица не секционирована, а индекс секционирован:
Пример:
Create Partition Function pf (int)
as range right for values (1, 100, 1000)
Create Partition Scheme ps as Partition pf
TO ([PRIMARY], [FileGroup1], [FileGroup1], [FileGroup1])
Create table t (c1 int, c2 int)
Create clustered Index idx_t on t(c1) on ps(c1) <--построение несекционированного индекса
План построения индекса в этом случае выглядит просто:
Построитель
|
Сортировка
|
Сканирование
Для каждой секции такого индекса создается одна промежуточная структура сортировки (в примере выше, создается четыре секции индекса – значит будут созданы четыре промежуточные структуры сортировки). По умолчанию, используется пользовательская база данных для записи промежуточных результатов сортировки. Как уже упоминалось, каждый экстент памяти использующейся для хранения промежуточных сортировочных структур освобождается, как только все данные из него будут добавлены в дерево индекса. Таким образом, общий объем дискового пространства (в случае, если сортировка в памяти невозможна), необходимого для построения индекса уменьшается с 3х («куча» + сортировочная стрктура + дерево индекса) до 2,2х (приблизительно).
Таким образом, в случае сортировки в пользовательской базе
данных сортировка происходит в каждой filegroup для каждой соответствующей секции. Это
означает, что каждая файловая группа должна иметь те же 2.2*(Размер секции)
свободного дискового пространства для того, чтобы можно было построить индекс.
А в случае сортировки в tempdb,
требуется 2.2*(Размер всего индекса) свободного пространства в tempdb.
Построитель индекса может начать добавлять данные в дерево индекса после того, как созданы промежуточные сортировочные структуры для всех секций. Таким образом, одновременно будут существовать сортировочные структуры для всех секций. Как уже говорилось, каждая такая структура требует как минимум 40 страниц памяти. В итоге, минимальная требуемая память составляет - №Секций * 40 страниц.
В случае параллельного построения, плана выглядит следующим образом:
X
|
Построитель
|
Сортировка
|
Сканирование
Каждый исполнитель получает для построения число секций равное
№Секций/DOP. Каждый исполнитель сканирует данные один
раз и считывает данные принадлежащие его секциям, которые затем будут добавлены
в соответствующие структуры сортировки.
После того, как все промежуточные структуры построены,
построитель начинает строить дерево индекса, выбирая одну за другой
промежуточные структуры сортировки и, строя b-дерево в файловой группе каждой секции. Одна секция не может
быть распределена между несколькими исполнителями.
Требования к памяти и дисковому пространству, в этом случае, точно такие же, как и для последовательного построения. Это происходит потому, что в обоих случаях мы не можем начать построение финального b-дерева, пока не построены все промежуточные структуры сортировки.
Комментариев нет:
Отправить комментарий