DeepEdit!

Применение параллелизма для операций SQL всегда приводит к увеличению производительности.

Использование параллелизма для запросов или операторов DML (OracleS и бо­лее поздние версии) не всегда приводит к увеличению производительности. Ес­ли бы это было так просто, мы все бы уже давно использовали параллелизм для всего на свете, и все эти высокооплачиваемые эксперты и консультанты по на­стройке производительности Oracle искали бы себе другую работу. Однако если рассматривать параллелизм в благоприятной среде (а она проектировалась именно для того, чтобы быть благоприятной), то напрашивается вывод, что он мог бы существенно увеличить производительность. В противном случае име­ются все шансы Полностью вывести из строя систему-так, мы хотим использовать и настраивать параллелизм, но таким обра-
зом, чтобы не парализовать систему! В этой главе мы поделимся советами, как
это можно сделать. Пожалуйста, не запутайтесь в терминах: параллельные за-
просы (PQ, Parallel Query), параллельный сервер Oracle (OPS, Oracle Parallel
Server) или некое сегодняшнее название (в Oracle9i - Real Application Clusters?).
Все это абсолютно разные вещи. В этой главе речь пойдет о PQ. Несмотря на
то, что это звучит как название дополнительной опции, продаваемой за отдель-
ную плату (как это и было        на самом деле        частью Oracle
. Enterprise Edition (сервер базы данных Oracle масштаба предприятия в целом)
и инсталлируется одновременно с инсталляцией у заказчика        Oracle.

Когда Oracle выполняет оператор SQL, не использующий параллелизма, для
задачи        всего один процесс. Но когда этот же оператор выполня-

ется с использованием параллелизма, Oracle назначает для выполнения уже не­сколько процессов. После этого работа начинает делаться быстрее, но только в том случае, если среда благоприятствует параллелизму. Вот и вся стоящая за параллелизмом теория. Но оптимальная реализация PQ - как говорится, отдельная история.

Помните старую школьную задачу по математике: если один рабочий выпол­няет какую-то работу за восемь часов, сколько времени понадобится двум рабо­чим, чтобы выполнить ту же самую работу? Вы говорите, что ответ очевиден ­четыре часа? Ну, наверное, в теории так оно и есть. В реальной же жизни все
может сложиться совсем не так. Если рабочие прерывают друг друга, разговари-
вают о своих планах на выходные или о футболе, который показывали вчера ве-
чером, пытаясь в то же время        сделать, им может понадобиться даже
больше восьми часов, чтобы выполнить ту же самую работу. Это же справедливо
и для параллелизма. Для улучшения с его помощью общей производительности
необходимо соответствующее проектирование, адекватные ресурсы и встро-
енные элементы управления- Основная цель, стоящая за архитектурой Oracle
Parallel Query, заключается в том, чтобы заставить все подчиненные параллель-
ные запросы выполнять примерно равные объемы действий, чтобы все они за-
канчивали свою порцию работы примерно в одно и то же время.

Когда использовать параллельные запросы

Концепция параллельных операций базируется на делении работы между не­сколькими процессами. Предполагается, что множество небольших действий можно закончить намного быстрее, чем одну работу большого размера, причем и то и другое приводит к одному и тому же результату. Например, если полное сканирование таблицы выполняется несколькими процессами, имеется воз­можность (зависящая от проектирования и природы среды) возвратить данные намного быстрее, чем даже при сканировании индекса. Повторим, однако, что

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

нескольких процессов без конкуренции ввода/вывода. Для него также необхо­димы адекватные возможности ЦП и памяти, чтобы обрабатывать требования ресурсов параллельно выполняющихся подчиненных запросов. Для использо­вания      вовсе не обязательно иметь систему с несколькими ЦП. Не так

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

Параллельное выполнение операторов SQL полезно для операций, во время которых обрабатывается большое количество данных: полное сканирование

таблиц, соединение больших таблиц, большие поиски по диапазону индексов,

вставки значительных количеств данных в хранилище данных и т. д. PQ перепи­сывает лежащие в основе операторы SQL таким образом, чтобы разделить за­прос на несколько задач. Для охвата задач можно использовать несколько процессов, выполняющиеся одновременно, чтобы произвести желаемые вы­ходные данные. Эти процессы часто называют 

рабами (slaves) параллельныхзапро-сов, 

или 

серверами параллельны» запросов, 

действия которых контролируются и координируются процессом сервера, выступающим под новым именем: 

коорди­натор параллельного выполнения, 

или 

координатор параллельны* запросов 

(PQC, pa­rallel query coordinator).

Ключом к соответствующему использованию является предохранение подчиненных процессов параллельного запроса от взаимодействия друг с дру­гом. Например, слишком много рабов PQ не должны обращаться к одним и тем же внешним устройствам в одно и то же время или ожидать освобождения ЦП и других системных ресурсов. Если переоценить возможности сконфигури­ровав и запустив слишком много подчиненных процессов параллельных запро­сов и разрешив параллелизм для всех таблиц системы, это приведет к конкуренции в рамках всей системы, увеличению числа переключений контек­стов на уровне ОС и к деградации (ухудшению) общей производительности. Кроме того, эти процессы будут включены в общее число процессов Oracle. Ес­ли при этом превысится общий предел числа процессов, то станут невозможны­ми новые подключения к системе. Так что поосторожнее обращайтесь с и пользуйтесь этим средством!

Как использовать параллелизм

Попробуем разобраться, как параллелизм могут использовать операторы SQL. Количество подчиненных процессов (рабов) параллельного запроса назы­вается степенью параллелизма. Обычно PQ пытается использовать определен­ное количество рабов параллельного запроса в соответствии со 

степенью параллелизма. 

Но в случае использования оператора сортировки число процес­сов необходимо удвоить.

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

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

На уровне таблицы или индекса

На уровне оператора SQL с помощью подсказки 

parallel

Как значение по умолчанию, основанное на числе ЦП или на количестве внепшихнтройств. которые, по мнению системы Oracle, использует заказчик

•        -

Приведенный ниже пример показывает, каким образом установить степень параллелизма при создании новой таблицы. Фраза "parallel (degree 4)" задает для таблицы степень параллелизма, равную 4.

SQL> create table MYTABLE

(ColA number(2), ColB number(2)

)

' parallel (degree 4); Table created!

Значение степени параллелизма таблицы можно узнать, применяя колонку Degree представлений USER_TABLES, ALL_TABLES и DBA_TABLES:

□        SQL> select Degree

from USER_TABLES where Table_Name = 'MYTABLE';

DEGREE

Степень параллелизма таблицы можно изменить, используя команду alter table. В следующем примере степень параллелизма увеличивается до 6:

SQL> alter table MYTABLE parallel (degree 6); Table altered. SQL>select Degree

. from USER_TABLES

where Table_Name = 'MYTABLE';

DEGREE

Ниже дан пример кода, показывающего, как установить степень параллелиз­ма для индекса равной 4. В зависимости от используемой версии Oracle в одном из представлений словаря данных USERINDEXES, DBAINDEXE S и будет присутствовать столбец с именем Degree, в котором содер­жится значение степени параллелизма индекса.

SQL> create index MYINDEX

on MYTABLE (ColA) storage (initial 1M next 1M) parallel (degree 4);

Index createa. SQL> select Degree

from IJSER.INOEXES where Index_Name = 'MYINDEX';

DEGREE

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

Для изменения степени параллелизма индекса мы можем также применять

команду alter index, как это показано ниже:

alter index MYINDEX parallel (degree 6); Index altered. sql> SELECT Degree

from USER.INDEXES where Index.Name = MYINDEX';

DEGREE

Следующий пример кода показывает, как для таблицы установить степень па­раллелизма равной 6, применяя подсказку PARALLEL в операторе SQL. Заметь­те, что если используется алиас таблицы, то в подсказке необходимо ссылаться именно на алиас, как показано ниже. Приводятся только последние строки это­го примера:

 select /*+ PARALLEL  (CM,   6)   */ CuStanterJW Custid,   Last_Contract_Yr Ley from CUSTOMER_MASTER CM order by Customer_Id;

101119153        2000

101119164        2000

101119197        2000

5065192 rows        selected.

Поскольку в предыдущем примере используется фраза "order by" для сорти­ровки результатов, Oracle может попытаться выделить для этой операции по крайней мере 12 рабов параллельного запроса.

В приведенном ниже примере степень параллелизма таблицы устанавлива­ется равной значению параметра по умолчанию. В Oracle 7.3 и 8.0 эта степень по умолчанию определяется Oracle на основании таких различных факторов, как число ЦП или число устройств внешней памяти, на которых хранятся таб­лицы или индексы.

SQL> alter table MYTABLE parallel; Table altered. SQL> select Degree

from USER_TABLES where Table_Name = 'MYTABLE';

DEGREE

DEFAULT

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

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

Если установить степень параллелизма таблицы        индекса и при этом

специфицировать в подсказке в операторе SQL другое значение, какое из них

должен использовать Oracle? Запомните, Oracle всегда использует следующий порядок предпочтений:

Оператор SQL с подсказкой PARALLEL

Степень параллельности, установленная для таблицы или индекса

Принятая по умолчанию степень параллелизма

Замечание        

После того как степень параллелизма определена, она становится степенью параллелизма для всей операции.

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

пулом сервера 'парал­лельного выполнения.

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

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

□ SQL> alter table MYTABLE noparallel; Table altered.

SQL> select /*+ NOPARALLEL 

*/ 

count (*.) from CUSTOMER_MASTER;

COUNT (*) 5065192

Операторы SQL, выигрывающие от применения параллелизма

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

Начиная с Oracle 7.3, стало возможно использовать параллелизм для выпол­нения следующих типов операций:

Операторы выборки данных (select)

Подзапросы в операторах обновления и удаления (update и delete)

Подзапросы в операторах вставки и создания таблицы (insert и create table)

Операторы Create Table AS Select (CTAS)

Операторы создания индекса (параллельный DDL)

Кроме того, начиная с Oracle 8.0, можно применять параллелизм при выпол­нении таких типов операций DDL, как:

Перестройка индекса

Перестройка раздела индекса

Расщепление раздела

Перенос раздела

В дополнение к этим операциям DDL в        введен параллелизм для опе-

раторов вставки, обновления и удаления. Oracle использовал для обозначения таких операций термин параллельный DML (PDML), хотя в определение языка манипулирования данными (DML, Data Manipulation Language), разработанное ANSI (Американским национальным институтом стандартов), включены и опе­раторы запросов. PDML используется для ускорения объемных операций DML с большими таблицами. PDML может принести выгоду в системах поддержки принятия решений и хранилищах данных, которые, как правило, имеют дело с большим количеством данных. Для подобных систем производительность и масштабирование представляются очень важными аспектами. В то же время PDML может оказаться полезным в определенных операциях OLTP.

PDML можно использовать и для несекционированных таблиц. Однако в полной мере преимущества PDML становятся очевидными только в том случае, когда таблицы секционированы. Дело в том, что над не секционированными таблицами можно проводить лишь операции параллельной вставки. Но не за­бывайте, что параллелизм распространяется только на действия над разделами, а внутри разделов он отсутствует. Значит, для каждого из разделов может суще­ствовать только один подчиненный процесс параллельного запроса. Основным преимуществом от использования PDML является исчезновение необходимо­сти в "самодельном" (т. е. расписанном самим программистом. - 

Прим. пер.) 

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

Параллельный DML включается или отключается только на время сеанса. Перед тем как сеансу может быть разрешено (посредством использования команды alter session) использовать PDML, необходимо зафиксировать или от­катить все результаты проделанной ранее в рамках этого сеанса работы. Поско­льку сеанс PDML выполняет операторы SQL как автономную транзакцию, она не может быть частью предыдущей транзакции. Для включения или отключе­ния параллельного DML используйте команду alter session. Заметьте, что не по­явилось никаких новых параметров инициализации Oracle для установки базы данных и ее возврата в первоначальное состояние. После того как сеансу будет разрешено использовать параллельный DML, Oracle выполнит все следующие операторы сеанса в параллельном режиме. Необходимо специфицировать сте­пень параллелизма с помощью подсказки PARALLEL или же для всей таблицы будет использована принятая по умолчанию степень параллелизма.

Ниже приведен пример сеанса PDML. В нем попытка разрешить использова­ние параллельного DML закончилась аварийно с кодом завершения так как не была подана команда фиксации или отката результатов предыдущей транзакции. Обратите внимание, что для завершения транзакции, выполняю­щейся в параллельном режиме, тоже необходим оператор commit или rollback,

прежде чем будет дезактивирован сеанс параллельного DML.

[Л SQL> insert into MYTEST values (1);

1 row created.

SQL> alter session enable parallel dml; ERROR:

ORA-12841;  Cannot alter the session parallel DML state within a transaction SQL> commit; Commit complete.

SQL> alter session enable parallel dml; Session  altered.

SQL> update /*+PARALLEL (MYTABLE,   3)  */ MYTABLE set Num=Num+4;

4800000   rows updated.

SQL> alter session disable parallel dml;

ERROR:

ORA-12841:  Cannot alter the session parallel DML state within a transaction SQL> commit;

Commit complete.

SQL> alter session disable parallel dml; Session altered