Построение индексов – Часть 6. (План для индексирования представления без гистограмм)

http://blogs.technet.com/lyudmila_fokina/archive/2006/12/21/565167.aspx

Людмила Фокина

Если гистограммы не доступны на момент построения индекса (например, при построении индекса для представления) – т.е. мы не можем получить статистику о распределении данных (собрать статистику возможно только для «реального» объекта, и пока кластерный индекс для представления не построен, ее нет, поэтому выбирается другой план) – SQL Server не может воспользоваться планом построения индекса описанном в раньше (см. ноябрьские посты об интервальном секционировании). SQL Server выбирает в данном случае план с обычным параллельным сканированием, который ничего не знает о распределении данных.

     Построитель …  

                   |                

                   Х

/                  |                 \

Сортировка… Сортировка …  Сортировка …

|                  |                 |

Сканирование  Сканирование  Сканирование

Как это работает.

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

Почему этот план может быть относительно медленным. SQL Server строит дерево индекса последовательно, плюс некоторые дополнительные издержки на операцию ‘merge exchange’ (слияние промежуточных структур сортировки в одну). 

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

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

Для расчета требуемой памяти учитывается 1) необходимая память, 2) дополнительная память.

Каждая структура сортировки требует 40 страниц памяти (необходимая память). 

Например, если уровень параллелизма – DOP = 2, строятся 2 структуры сортировки и требуется 80 страниц (каждая страница – 8KB) памяти, в то время как общая дополнительная память остается такой же, независимо от DOP (это происходит потому, что общее число строк не зависит от DOP).

Например, если последовательный план требует 500 страниц дополнительной памяти, то и параллельный план получит 500 страниц дополнительной памяти, а каждый исполнитель – 500/DOP страниц дополнительной памяти + 40 страниц необходимой памяти.

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