DeepEdit!

Давайте подумаем о том, как эффективно проектировать базу данных для па­раллелизма, чтобы она работала оптимальным образом.

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

больше о конфигурации группы томов запоминающих устройств настраивае­мой системы. Реализация параллелизма, не опирающаяся на информацию о том, как ОС "видит" наши диски, может иметь катастрофические результаты и

привести к полной парализации системы.

Приведем пример, чтобы сделать все абсолютно понятным. Допустим, у нас имеется 16 дисковых устройств, поддерживаемых двумя контроллерами. любно настроенный к нам и к Oracle системный администратор UNIX (или наш дорогой        дискового массива) решает, что в интересах простоты управ-

ления имеет смысл построить всего одну группу логических томов, содержащую все 16 дисковыхустройств. ОС будет видеть эту группу томов как одно устройство.

Теперь рассмотрим еще одну конфигурацию. Если были построены четыре группы физических томов с четырьмя дисковыми устройствами в каждой груп­пе, то имеется четыре таких "устройства", которые будут видны операционной системе. Когда запустит несколько процессов для доступа к данным, послед­няя конфигурация обеспечит более высокую пропускную способность, чем пер­вая, и поможет закончить запрос гораздо быстрее. Дело в том, что установка

обеспечивает больше независимых устройств, на которых может работать каж­дый из подчиненных процессов параллельного запроса. В первой конфигура­ции, при условии, что ОС трактует всю группу томов как единое целое, несколько процессов, устроивших торги за это одно устройство, могут создать узкое место производительности и преумножить конкуренцию.

Теперь может показаться соблазнительной такая мысль: а почему бы не по­строить 16 групп томов по одному устройству в каждой, чтобы заставить все рабо­тать даже быстрее, создав еще больше подчиненных процессов? Дело в том, что

скорости нельзя достичь только за счет того, у нас больше устройств или под­чиненных процессов. Для этого необходимо, чтобы число процессов-рабов было

эффективно поддержано числом ЦП и достаточным объемом памяти системы. С
16 устройствами и процессами-рабами до тех пор, пока у нас не будет 16 (или бо-
льше) процессоров (кроме того их числа, что необходимы для работы обычных
транзакций), система будет испытывать зависание        приведет к  времени, требующегося для завершения запроса. Поэтому проверьте, что лучше всего работает для вашей системы. Чтобы узнать, как конфигурировать ди­сковые подсистемы, обратитесь, к главе "Настройка ввода/вывода".

Вы - администратор базы данных - являетесь лучшим судьей, лучшим знатоком нужд своей системы Oracle. Хотя большинство производителей аппаратных средств понимают, насколько их продукты подходят к Oracle, в конце концов вся ответственность за принятие решения все-таки ложится на АБД, потому что именно он знает свою среду лучше всех. Создание одной группы томов с 16 устройствами в ней это, конечно, совсем не то же самое, что создание четырех групп с четырьмя устройствами в каждой. Степень параллелизма, которую может поддерживать система, обычно выше для второй конфигурации, а все другие факторы остаются неизменными. Еще один фактор, который следует иметь в виду, - это потребности приложения и базы данных в секционировании. Если некоторые основные таблицы и индексы базы данных нуждаются в секционировании, разнесение разделов этих таблиц и индексов (по разным устройствам) служит важным фактором при проектировании параллелизма. При секционировании вам определенно придется еще раз переосмыслить конфигурациюсоднимтомом, состоящим из 1 бустройств.

Кроме конфигурирования запоминающих устройств    групп        необхо-

димо также оптимально устанавливать значение степени параллелизма. Спо­соб, которым конфигурируются группы томов, оказывает влияние и хранение таблицы индекса. Не забудьте проверить это, прежде чем принять реше­ние, какое значение будет работать лучше.

Мы рекомендуем устанавливать минимальную степень параллелизма для таб-
лицы        используя следующую формулу:

Минимальная степень параллелизма - Floor (двукратное число ЦП, число разделов таблицы, число независимых устройств или

для хранения таблицы или ее разделов).

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

этого правила в зависимости от используемой системы ввода/вывода и харак­теристик оборудования. Но есть еще много других факторов, которые необхо­димо принять в расчет для того, чтобы хорошо спроектировать параллелизм.

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

Соображения о параллельном DML

Ранее мы представили нашим читателям параллельный DML и показали, как.

им пользоваться. Очень большие базы данных обычно состоят из очень боль-
ших таблиц. PDML необходим для групповых операций DML с такими объекта-
ми. PDML дополняет архитектуру       но он полностью        для

секционированных таблиц. Однако параллельные вставки прямой загрузкой

для несекционированных таблиц могут быть        при        подсказ-

ки /*+ APPEND */. При использовании этой подсказки Oracle выполняет встав­ки выше максимальной точки таблицы, обеспечивая тем самым возможность прямой загрузки в пределах контекста приложения.