сделанных в памяти на другом узле. Для достижения этой цели два (или более) экземпляра используют менеджер распределенных блокировок (Distributed Lock Manager, DLM). Этот менеджер, как правило, сигнализирует о запросах блокировок по локальной сети, которая обычно строится по технологии коммутируемых Etiiernet-соединений.

Самый простейший случай выглядит так. Каждый раз, когда экземпляр хочет обратиться к чему-то, что находится в памяти и может быть изменено другим экземпляром, он устанавливает на этот ресурс разделяемую блокировку (share lock). Если экземпляр хочет изменить область в памяти, например блок базы данных в буферном пуле, он устанавливает эксклюзивную блокировку (exclusive lock). Если один экземпляр узнает, что другой экземпляр хочет установить блокировку на буфер базы данных, который был изменен первым экземпляром, то делается следующее. Экземпляр, изменивший блок, должен записать блок на диск и снять установленную им эксклюзивную блокировку. Эта процедура называется пингингом {pinging). Одна из главных особенностей Oracle Parallel Server с точки зрения проектирования состоит в том, что распределенные блокировки совершенно не зависят от транзакций и границ транзакций. Они принадлежат экземпляру, а не транзакции.

Впервые встречаясь с Parallel Server, большинство пользователей интуитивно предполагают, что пингинг может вызвать конкуренцию между экземплярами. В частности, они начинают беспокоиться по поводу объема дисковых операций при перемешении блоков из одного экземпляра в другой. К несчастью, эту проблему вряд ли можно назвать самой серьезной из тех, которые встречаются при работе с Parallel Server. Действительной проблемой является то, что каждый раз, когда экземпляр намеревается что-то просмотреть или изменить, он должен обеспечить правильную распределенную блокировку. Одно только это означает, что в режиме разделения экземпляр работает, как правило, приблизительно на 10% медленнее, чем в обычном режиме. Кроме того, если необходимая экземпляру блокировка отсутствует, он должен по локальной сети дать сигнал всем остальным экземплярам, а они должны ответить. Поэтому даже при отсутствии операций обмена с диском создается достаточно интенсивный сетевой трафик, связанный с распределенными блокировками. Однако, как мы видели в главах И и 12, существуют весьма реальные пределы скорости, с которой узел может передавать и принимать сообщения по сети Ethernet.

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

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

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

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

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

Как же спроектировать систему, чтобы не нарушить это ограничение и пользоваться возможностями ЦП кластера?

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

2. Попробуйте воздействовать на пользователей, разъясните им, что кластеры и Oracle Parallel Server - не волшебство, а просто умная технология, которая старается работать как можно лучше в несовершенном мире.

Системы с лшссовыт параллелизмом: попытка изменить правила

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

Поскольку в ближайшем будущем вряд ли многие из вас столкнутся с необходимостью проектировать приложения для СМП, мы просто заметим, что СМП-архитектуры, помимо колоссального шума в расчете на каждый вложенный доллар, создают определенные выгоды для OPS:

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

мы видели опытный образец СМП, который справлялся менее чем с сотней операций блокировки в секунду!

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

Мы видим все больше и больше машин с архитектурой NUMA (Non-Uniform Memory Architecture), позволяющих держать большие кэши в поле памяти, которое находится между оперативной памятью, расположенной на процессорной плате, и дисками. Простая машина с такой архитектурой схематично показана на рис. 14.8.

Некоторые мечтатели (в том числе Ларри Эллисон, основатель и руководитель Oracle Corporation) полагают, что при такой архитектуре дискам можно поручить роль резервных носителей. Однако для большинства приложений полностью резидентные базы данных являются пока еще чем-то недоступным.