2. Внутризапросный параллелизм
В отличие от межзапросного параллелизма ([14]), означающего одновременное выполнение разных запросов на нескольких потоках (threads) операционной системы, внутризапросный (intraquery) параллелизм был реализован в SQL Server 7.0 впервые. Внутризапросный параллелизм, как следует из его названия, есть возможность распараллеливания процесса обработки одного запроса по нескольким потокам, что позволяет эффективно использовать многопроцессорные архитектуры при обработке сложных запросов. Использование внутризапросного параллелизма не требует специального разбиения данных при их хранении, а также внесения каких-либо изменений в их структуру или текст запроса. Процессор запросов рассматривает параллелизм наряду с другими этапами стратегии построения оптимального плана. Основными критериями при принятии решения о паралельном выполнении запроса выступают количество активных пользователей, доступная память и предположительный объем данных, обрабатываемых запросом. Очевидно, что параллельное выполнение простого запроса по сравнительно небольшому числу записей невыгодно, так как потребует больше памяти, нежели последовательное. При этом приходится забирать потоки, которые в противном случае могли бы быть использованы для поддержки большего числа пользователей. Общее правило можно сформулировать так: в OLTP-системах, характеризующихся большим количеством пользователей, обстреливающих SQL Server многочисленными короткими транзакциями, он будет отдавать предпочтение последовательным планам, расходуя поточный пул (см. опцию max worker threads) на пользовательские соединения. В OLAP-приложениях, для которых, напротив, характерны массивные долгоиграющие транзакции, а число пользователей относительно невелико, процессор запросов прибегнет к параллельным планам. Например, запрос
select * from sales_fact_1997 union select * from sales_fact_1998 (количество записей в таблице, как мы помним, 86837) выполняется по следующему плану:
/-Parallelism(Gather Streams)
/-Hash Match(Union)
/-Parallelism(Repartition Streams, PARTITIONCOLUMNS:
(sales_fact_1997.product_id, sales_fact_1997.time_id, sales_fact_1997.customer_id,
sales_fact_1997.promotion_id, sales_fact_1997.store_id, sales_fact_1997.store_sales,
sales_fact_1997.store_
/ /-Table Scan(FoodMart..sales_fact_1997)
/-Sort(DISTINCT ORDER BY: (sales_fact_1998.product_id asc, sales_fact_1998.time_id asc,
sales_fact_1998.customer_id asc, sales_fact_1998.promotion_id asc,
sales_fact_1998.store_id asc, sales_fact_1998.store_sales asc,
sales_fact_1998.store_cos
/-Parallelism(Repartition Streams, PARTITIONCOLUMNS: (sales_fact_1998.product_id,
sales_fact_1998.time_id, sales_fact_1998.customer_id, sales_fact_1998.promotion_id,
sales_fact_1998.store_id, sales_fact_1998.store_sales, sales_fact_1998.s
/-Table Scan(FoodMart..sales_fact_1998)
Лист.2.1
Параллельное выполнение запроса достигается введением в план специальных операторов параллелизма, к которым относятся Distribute (произвести разбиение данных на несколько потоков (streams)), Gather (собрать результаты обработки данных c предыдущих шагов на нескольких потоках) и Repartition (перераспределить данные по потокам). Запросы на обновление (UPDATE / INSERT / DELETE) выполняются последовательно, однако подчитка данных в них может производиться в параллельном режиме. Специфика динамических курсоров предполагает строго последовательный план выполнения. В то же время для заполнения статических и keyset-курсоров может использоваться межзапросный параллелизм.
В смешанных приложениях может возникнуть необходимость провести количественную грань между понятиями простого и сложного запроса. Это делается с помощью конфигурационного параметра cost threshold for parallelism, который характеризует пороговую стоимость запроса, начиная с которой оптимизатор начинает рассматривать возможность использования параллельного плана выполнения. Запросы, чья стоимость не превышает пороговой величины, всегда будут выполняться последовательно. Значение этой опции по умолчанию равно 5. Ее также можно модифицировать из меню Server Properties (закладка Processor) в SQL Enterprise Manager.
Ключевым понятием параллельного выполнения является степень параллелизма (Degree of Parallelism, или DOP), иными словами, количество процессоров, которые будут задействованы для одновременной обработки запроса. Отметим, что эффект внутризапросного параллелизма будет проявляться только на машинах, где для работы SQL Server отведено два и более процессоров (см. опцию affinity mask ([1])). Для настройки DOP используется конфигурационный параметр max degree of parallelism, который может принимать значения от 0 до 32: 1 запрещает внутризапросный параллелизм, 0 (по умолчанию) означает, что при построении параллельных планов процессор запросов будет использовать максимально доступное на данный момент число процессоров. Количество потоков, на которых начинается выполнение запроса в параллельном режиме запрос, остается неизменным до момента его окончания. Вместе с тем, необходимо иметь в виду, что оптимальный план может изменяться в зависимости от конфигурации и загрузки SQL Server, так что тот же самый запрос через некоторое время может выполняться с другой DOP, в частности, последовательно. Просмотр DOP осуществляется при помощи соответствующего подкласса события в SQL Profiler.
Наряду с обычными потоками SQL Server 7.0 обладает возможностью использовать волокна (fibers) Windows NT - особый вид легковесных потоков, из которых может состоять thread. Легковесность заключается в особенностях планирования (scheduling). Переключение между потоками требует перехода в режим ядра операционной системы, что само по себе является довольно дорогостоящей операцией, в то время как переключение волокон происходит в контексте приложения. SQL Server использует волокна вместо потоков, если конфигурационный параметр lightweight pooling установлен в 1.