Базы данных Oracle - статьи


Поддержка параллельных систем. - часть 3


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

Однако было бы нечестно утверждать, что при применении OPS не возникает никаких проблем. Собственно говоря по сравнению с SMP-системами возникает одна, но достаточно неприятная, проблема: синхронизация кэшей в оперативной памяти узлов. В самом деле, каждый узел системы кэширует данные БД в своей оперативной памяти и может держать их там достаточно долгое время без переписывания на диск. Если один из узлов модифицировал некую запись БД, но не переписал ее на диск, то при обращении к той же записи другой узел не имеет права ни пользоваться ее копией в своей памяти (она уже не актуальна), ни даже считать ее с диска. Для разрешения этой проблемы вводятся т.н. блокировки параллельного кэша: при модификации данных узел параллельной системы как бы вешает на них свой “замок”, так что любой другой узел при обращении к этим данным должен сначала “снять замок”, что включает в себя передачу ему актуальных данных. Ясно, что если различные узлы будут часто модифицировать одни и те же данные, то блокировки параллельного кэша могут заметно снизить производительность сервера в целом.

К сожалению данная проблема является принципиальной, т.е. от нее нельзя полностью избавиться ни с помощью технических ухищрений, ни с помощью альтернативных решений* . К счастью проблема не столь страшна, как может показаться: во всяком случае понятно, как можно с нею бороться. Если пользователи, работающие с разными узлами, редко модифицируют одни и те же записи, то и блокировки параллельного кэша возникают редко. Такой режим легко обеспечивается, если, например, на разные узлы сервера “назначаются” пользователи, работающие с разными приложениями, или работающие с данными различных отделов (филиалов) и пр. Приложения, осуществляющие “хаотичные” обращения к большой БД также имеют слабую тенденцию к порождению блокировок параллельного кэша. Тем не менее, распределение пользователей между узлами сервера должно осуществляться не наобум, а с учетом того, с какими данными и в каком режиме они работают *. Как бы то ни было, OPS уже достаточно давно и успешно используется - особенно в инсталляциях, требующих повышенной надежности системы. Нелишне заметить, что и рекорд в тестах TPC-C поставлен с использованием OPS на кластере (Digital Alpha 8400)* . Конечно рекорд рекордом, но для пользователей важно найти систему, отвечающую масштабам их задач. Надо сказать, что до последнего времени понятия “кластер” и “параллельный сервер” ассоциировались только с весьма мощными и дорогостоящими конфигурациями аппаратуры. Отчасти это было связано с реальными потребностями рынка, а отчасти с тем фактом, что поддержка кластерного режима работы требует весьма значительных системных ресурсов. Одним из первых пожирателей ресурсов является т.н. менеджер распределенных блокировок (Distributed Locks Manager - DLM). Это программная компонента (реализованная обычно в виде набора процессов), обычно поставляемая фирмой-разработчиком ОС, задача которой - управление доступом к разделяемым ресурсам на уровне системы в целом. Именно с помощью DLM Oracle реализует блокировки параллельного кэша и вообще синхронизацию работы узлов. Универсальность DLM в сочетании с тем, что он является “внешней составляющей” OPS, приводит к тому, что общее количество блокировок параллельного кэша становится критичным ресурсом. Чтобы снизить потребность в нем, в Oracle 7.3 введен ряд усовершенствований в управлении выделением этих блокировок, но для радикального решения проблемы безусловно требовался другой подход к реализации DLM. В частности по этой причине уже в версии 7.3 Oracle постепенно переходит к реализации DLM собственными средствами в составе ядра сервера - окончательно этот процесс будет завершен с выходом Oracle8. Как бы то ни было уже в ближайшем (“весеннем”) релизе Oracle 7.3.3 ожидается поставка параллельного сервера для кластеров, функционирующих под управлением таких “легковесных” ОС, как SCO UnixWare и Windows NT (последней - как для платформы Intel, так и для DEC Alpha).




Начало  Назад  Вперед



Книжный магазин