Вот очень приблизительное эмпирическое правило: для типичного приложения пакетной обработки или генерации отчетов, работающего автономно на сервере с процессорами средней производительности и быстродействующими дисками, мы рассчитывали бы получить не более чем следующие уровни использования ресурсов процессоров:

В десятипроцессорной системе один пакетный процесс будет использовать менее 50% ресурсов одного процессора, т.е. менее 5% общей мощности процессоров. Учитывая, что многие важные процессы в приложениях продолжают проектироваться как однопоточные пакетные задачи, мы видим, что использование параллельной обработки везде, где возможно, может дать значительные преимущества. Другими словами, вместо того чтобы заставлять одигг процесс использовать менее 50% ресурсов центрального процессора (который выполняет всю работу последовательно), мы рассчитывали бы на использование других центральных процессоров. Это позволит увеличить общую пропускную способность системы.

Создание и сопровождение индексов

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

А как быть, если требуется пересоздать три таких индекса для одной или нескольких таблиц? Если стрипинг таблиц организован при помощи менеджера логических томов, то почему бы не инициировать все операции пересоздания индексов параллельно? (Да, Oracle допускает построение одновременно нескольких индексов для одной таблицы, причем это возможно начиная с версии 6.)

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

хаотично. Мы советуем попробовать применить этот метод на своих аппаратных средствах и со своими данными. Наш опыт почти всегда был положительным.

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

Пакетная обработка

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

aged debts min age=30 level=4 offices=all connect=scott/tiger pick list print stores=all connect=scott/tiger

nohup aged debts min age=30 level=4 offices=all connect=scott/tiger S nohup pick list print stores=all connect=scott/tiger &

Тем, кто не знаком с Unix, поясняем: символ & в конце строки команды обеспечивает асинхронное ее выполнение, а команда nohup делает затребованный процесс независимым от скрипта, который его запустил. Выполнение этого задания продолжится даже в том случае, если запустивший его пользователь выйдет из системы, не дождавшись завершения задания.

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

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

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

nohup aged debts min age=30 level=4 offices=NY connect=scott/tiger & nohup aged debts min age=30 level=4 offices=LA connect=scott/tiger & nohup aged debts min age=30 level=4 offices=UK connect=scott/tiger 5 nohup aged debts min age=30 level=4 offices=HK connect=scott/tiger &

nohup pick list print stores=US connect=scott/tiger & nohup pick list print stores=UK connect=scott/tiger & nohup pick list print stores=HK connect=scott/tiger &

Если мы достаточно сообразительны, то на этом этапе начнем беспокоиться. Если добавится еще один офис или склад, то кто-то должен не забыть изменить скрипт, включив в него новый узел. Чтобы избежать этой проблемы, лучше организовать динамическое построение потока заданий:

rem must set define to avoid & being parsed be SQL*Plus

set echo off feedback off pagesize 0 define #

spool pick list print init

SELECT nohup pick list print stores =

I I STORE CODE

II connect=scott/tiger S FROM stores;

!pick list print init

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

каждый из параллельных потоков вносит свой вклад в таблицу результатов;

этап подведения итогов выполняется только после завершения предыдущей операции;

на этапе подведения итогов строится сводка. Этот процесс схематично изображен на рис. 14.4.