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

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

Зачем нужен параллелизм?

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

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

процесс, использующий машину, решает передать управление - обычно потому, что ему требуется подождать ввода или вывода в той или иной форме;

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

Почти всем операциям обработки часто приходиться останавливаться и ждать ввода-вывода. При нормальной работе Oracle было бы очень странно, если даже такой процесс, как пакетный, использовал бы значительно больше, чем 50% ресурсов центрального процессора. Почему? Да потому, что остальное время он тратит на ожидание чтения блоков базы данных с диска и (в меньшей степени) на ожидание записи элементов журнала на диск.

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

SELECT sales region, COUNT(*), SUM(order value) FROM orders GROUP BY sales region;

И это еще не все, потому что при наличии нескольких дисковых контроллеров существует возможность выполнять несколько операций с диском параллельно. Если мы распределим указанную в примере таблицу на несколько дисков (этот процесс, называемый стрипингом, описан ниже), то при помощи средства мониторинга (например, PATROL фирмы ВМС) увидим, что центральный процессор практически простаивает, а все дисководы работают отнюдь не с полной нагрузкой. Без стрипинга (и при выполнении только одного запроса) вообще использовался бы только диск, содержащий таблицу, причем не на полную мощность, а процессор был бы задействован еще меньше. В этом случае центральный процессор и диск работают попеременно. Улучшить ситуацию поможет асинхронное чтение с упреждением, однако максимальная скорость, с которой центральный процессор сможет получать данные, будет ограничена возможностями одного диска.

Правило номер один узкоместологии гласит:

В любой момент времени у системы исчерпывается только один ресурс.

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

Поскольку мы стремимся получать ответы на наши запросы как можно быстрее, то хотим иметь возможность довести эффективность работы или центрального процессора, или операций обмена с диском до максимальной. В приведенном выше примере мы почти наверняка достигнем предела возможностей системы ввода-вывода до того, как выйдем на предельную эффективность даже одного процессора. Тем не менее, при других запросах (особенно тех, в которых используются функции и есть сложные условия) иногда получается, что ресурсы нескольких процессоров истощаются, а предельная эффективность системы ввода-вывода еще не достигнута. И, конечно, динамика использования аппаратных ресурсов на протяжении цикла выполнения запроса не остается постоянной: Oracle традиционно обрабатывает такой запрос GROUP BY, как в приведенном примере, в три этапа:

1. Полное сканирование таблицы для получения значений.

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

3. Агрегирование (фактически выполняется на заключительной фазе слияния этапа сортировки).

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

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

процессоры стали работать значительно быстрее, а на серверах, как правило, используется больше процессоров, чем раньше;

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

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

диски не стали работать значительно быстрее.

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

Стрипинг

Стрипинг (striping) - это метод распределения данных по дискам. Допустим, что у нас есть четыре таблицы, каждая из которых расположена на отдельном выделенном диске, как показано на рис. 14.1. Представим, что наступил конец месяца и все начальники отделов отчаянно пытаются получить месячные результаты, а бухгалтеры, так же отчаянно, их проанализировать. Все эти данные хранятся в нашей базе данных в таблице 1, к которой производится большое число обращений. Настолько большое, что идет непрерывное соперничество за доступ к диску и пользовательские процессы стоят в очереди, ожидая освобождения диска. Ясно, что такой сценарий идеальным не назовешь!