Создание клиентских частей SQL-баз данных под Win95 и WinNT


    d8ef8794     

Опция Oracle Parallel Server позволяет


Опция Oracle Parallel Server позволяет нескольким узлам системы (фактически всем, функционирующим в данный момент времени) параллельно работать с одной БД, находящейся на общих дисках (в MPP-системе это будут "виртуальные" общие диски, поддерживаемые ОС). Пользовательские сессии взаимодействуют каждая со своим узлом, но при этом фактически работают с одними и теми же данными (помимо возможности использования полной мощности параллельной системы для работы с БД). Можно заметить, что в 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 собственными средствами в составе ядра сервера - окончательно этот процесс завершен в Oracle 8. Как бы то ни было, уже в релизе Oracle 7.3.3 существует параллельный сервер для кластеров, функционирующих под управлением таких "легковесных" ОС, как SCO UnixWare и Windows NT (последняя - как для платформы Intel, так и для DEC Alpha).


Содержание  Назад  Вперед